Online-Invoice
Online-Invoice copied to clipboard
nav-gov-hu
[Q&A] 2010-es dátum korlát
Kiállításra került a számlázó rendszerben egy 2007-es teljesítési dátumú módosító számla. Beküldeném modifywithoutmaster-el, de az xsd validáció nem engedi a 2010.01.01 előtti dátumot. Adatszolgáltatási kötelezettség van rá, a könyvelés szerint indokolt a 2007-es teljesítési dátum, meghamisított adatokkal meg nem kéne adatszolgáltatást teljesíteni. Mi a teendő ilyenkor?
Előre is köszönöm a segítséget.
Én is várom a konstruktív választ. Szerintem az ilyen esetekre lenne való az INFO üzenet. Fölösleges olyan szigorításokat használni a NAV OSZ 3-ban, ami szembe megy a valósággal. Ha mégsem lenne pozitív válasz, akkor én a számlakibocsátó adószámával írnék egy levelet a NAV-nak, jelezve az általad jól összefoglalt problémát. Elvégezném az adatszolgáltatást, és lementeném a kapott választ. Az adatszolgáltatás megkísérelve, de szabotázs miatt meghiúsult a befogadása. Ennyi.
Nyilván elég ritka az ilyen, de nem tudok róla hogy jogszabályba ütköző lenne 2010 előtti teljesítési dátumú számlát kiállítani. Ha az xsd constraint célja az elgépelt dátumok elleni védelem, akkor azért ennél korábbi (pl. 1990) kéne legyen az alsó korlát. Jó lenne NAV részről útmutatás, hogy kell helyesen eljárni.
Én is kíváncsi vagyok a válaszra. Nálunk egy ügyfélnél kb. 2 éve volt ilyen. Akkor az lett a végső megoldás, hogy a webes felületen felrögzítette a számlát, az engedte bevinni a 2010 előtti dátumokat.
A 2010-es időkorlát bevezetésének alapvetően az volt az oka, hogy viszonylag látható számoságú nagyon hibás teljesítési dátummal találkoztunk. Volt Krisztus születése környékén teljesült ügylet, 1920-as ügyletek, 2021 helyett 2001, de nagyon jövőbemutató dátumok is. Bár értjük, hogy optimista a vállalkozó, szerinte még több száz év múlva is működni fog, és akkor is teljesíteni akar egy ügyletet, de ez nyilvánvaló adathiba.
A 2010-es megkötés úgy született, hogy megvizsgáltuk azokat az adatszolgáltatásokat, amelyek nem feltétlenül adathibásak, de elévülési időt megelőző ügylettel kapcsolatosak. Akkor egy jó nyeregpontnak látszott a 2010 azzal, hogy lehetnek olyan nagyon-nagyon-nagyon extrém esetek, amikor elvileg lehetséges lenne korábbi teljesítési ügyletről kiállítani módosító számlát, de ezek már túlmutatnak az adózási kérdéseken. Azért messze nem egy normál eset, amikor elévülési időn túli számla kerül korrigálásra...
Éppen a fentiek miatt született ez a technikai megkötés. Az adatszolgáltatást amennyiben megpróbálja a program, akkor error-ra fog futni, és ezt az error-t mi is mentjük. Ezekre a számlákra technikailag nem lehet sikeres az adatszolgáltatás, de ez NAV oldali megkötés. Nem szabad megváltoztatni csak azért a számla adattartalmát, hogy az adatszolgáltatás teljesülni tudjon. Erről a számláról nem lehet technikailag sikeres adatszolgáltatást teljesíteni, ugyanakkor az error-ig a számlázó programnak el kell jutnia.
Szia @NTCA-tax! Nem erre lennének a warningok? Nem tudjuk 100%osan, hogy elgépelés van, lehet valós ügylet, mégis az ügyfél azzal szembesül, hogy egy jó számla adatszolgáltatása error-os, amitől vérmérséklettől függően meglepődik <-> pánikba esik. De egyébként is, ha elgépelte az adatot és kiállította úgy a számlát, akkor is kötelessége beküldeni a NAVhoz, hogy aztán tudja javítani és a javítást is beküldeni, nem?
Nálam is volt ilyen eset, de akkor még nem volt adatszolgáltatás. 25 évre visszamenőleg. Az ügylet valamilyen erdőtelepítési ügylet volt időtartamra 25 éves szerződéssel és a végén módosító számlát csináltak.
Ha csak warning lenne, akkor ugyanúgy tovább nyelné be a rendszer a temérdek hibás adatú számlát. Az ilyen típusú számláknak adózás tekintetében nincs kihatása a teljesítés időpontjára. Mivel nem lehet egy egzakt időpontot meghatározni (mi az elévülést vettük alapvetően alapul), ezért mindig lehetnek olyan (nem győzőm hangsúlyozni, nagyon-nagyon-nagyon) ritka eset, amikor mégis kiállításra kerül ilyen számla és tegyük fel valamilyen szempontból még helyes lenne (bár ez nem áfa törvény lesz). Ezt jól mutatja @sinick2 hozzászólása, hogy több mint négy évvel ezelőtt talált az ügyfélkörében egy ilyen esetet...
Amikor ilyen típusú vágást csinálunk, akkor azt mérlegeljük, hogy mi az az időpont, ami áfa törvény szempontjából egyáltalán fontos és ezen túl mi az adózói gyakorlat. Ne feledjük azért el, hogy az áfa törvény írja elő az adatszolgáltatási kötelezettséget, tehát logikailag mindig az áfa törvény játékterén belül kell mozognunk.
A 2010-et megelőző dátumú teljesítési időpontnál már annyira rossz az adatminőség, hogy ezzel esetleg levágjuk azt az évente teljes adózói körben előforduló megfelelőnek gondolt 1 vagy 2 esetet azért, hogy a több ezres hibás adatszolgáltatást már nem fogadjuk be és új adatszolgáltatásra kényszerítjük az adózót. Amikor pedig mégis jogosnak látja az ügyfél ezt a teljesítési időpontú számlát, akkor azt áfa szempontjából teljesen másképpen kell intézni, nem az eredeti teljesítési időpontra önellenőrizni.
Értem @NTCA-tax aggódását és érveit., az adatbázis minőségéért felelős gondolkodás ez. Azonban ez addig nem fogadható el, ameddig KÖTELEZŐ az adatszolgáltatás. Ha a jogszabálynak megfelel a számla, akkor az be kell fogadni. Az elévülés fogalmát is helyre kell tenni: azt szabályozza a polgárjogi elévülés, hogy bírósági úton a követelés nem hajtható be a vevőtől.. Azonban önkéntesen ki lehet fizetni ezt! A válaszban ide keveredett az ADÓJOGI elévülés, amely más dolog. Az adóhatóság nem kérheti az adójogilag elévült bizonylatot, és arról nem tehet joghatást kiváltó megállapításokat. Azonban ez adójogi elévülés az áfa bevallástól számít. Ráadásul gördülő dolog, újrakezdődik az elévülés a számlát módosító okirattal. Tehát ha egy számla benne volt az ÁFA bevallásban, és az 5 éves elévülés előtt egy nappal módosító okiratot állítanak ki rá, akkor onnantól kezdve újraindul az 5 éves elévülés. Ha nem így lenne, akkor az elévülés előtt 1 nappal a számlakibocsátó egy módosító okirattal csökkenthetné az áthárított áfát, majd visszaigényelné, és arra hivatkozna, hogy letelt az 5 év elévülés. Szóval nekem az a bajom, hogy az adatszolgáltatást törvénynek kell szabályoznia, és abban nincs benne, és nem is lehet benne a NAV adatbázis építő érdeke.
Az ilyen számlák (már amivel találkoztam) mind elhúzódó peres eljárások kapcsán jöttek létre.
Középutas megoldásként javasolnám hogy az XSD-be (ha nem is 1982-re), de 1990-ig csökkenteni a korlátot, és figyelmeztetést beépíteni arra ha a számla kelte a napi dátum -X év (pl. 10). Szerintem ez nem rontana érdemben az adatminőségen.
Fentebb ez szerepel: "Erről a számláról nem lehet technikailag sikeres adatszolgáltatást teljesíteni, ugyanakkor az error-ig a számlázó programnak el kell jutnia." Viszont a 23/2014. (VI. 30.) NGM rendelet 13/A. § (3) szerint "A számlázó programmal történő adatszolgáltatás akkor minősül teljesítettnek, ha az (1) bekezdés szerint történt a benyújtása, és a sikeres feldolgozást az állami adó- és vámhatóság rendszere visszaigazolta." Ha a fenti hibával lezárult sikertelen beküldési kísérlet teljesítettnek minősül akkor ezt bele kéne venni a rendelet szövegébe, hiszen esetünkben nincs ilyen visszaigzolás. tehát "de jure" nincs teljesítve a kötelezettség.
Szintén elhúzódó perek végén kiállított számlák esetén láttam ilyet. Mi azt javasoltuk eddig az ügyfélnek, hogy rögzítse fel kézzel a gépi számlát az error ellenére. Legutóbb, amikor ilyen volt a felület még engedte felvinni az adatot.
Jól értem hogy a webes felületen megkerülhető az xsd validáció? Ott nem merülnek fel a fent említett adatminőségi aggályok?
Előfordulhat, hogy összesen nem született ilyen számla, mint amennyi hozzászólás van már itt...
Amit látnotok kell, hogy ezek a számlák nem az áfajogból erednek, hanem polgári jog, peres eljárás stb., Viszont kötelezettséget kizárólag az áfa törvény szerint kiállításra kötelezett számlára írhatunk elő. Itt épp kell foglalkoznunk az elévüléssel, és azzal, hogy egy számlát meddig lehet az áfa rendszerében módosítani. No most nekiugorhatnánk jogszabály elméleti kérdésekbe, vagy lenne egy egyszerűbb megoldás is. Amennyiben nem a teljesítési időpontot érinti a módosítás, akkor azt nem kötelező a módosító számlán feltüntetni. Ha az ügyfél így jár el, akkor sehol nem akad fenn az adatszolgáltatása. Persze azt nem mondhatjuk, hogy ha feltüntetni a teljesítési időpontot, akkor az hibás lenne... Akkor jön a jogászkodás...
A webes felületen is ugyanaz a validáció, mint M2M-ben. @omachtandras olyan esetről írt, amikor még nem volt ez a validáció. Most már ne próbáljátok, vagy ha kipróbáltátok és átment rajtunk, akkor szóljatok, mert akkor az hibás működés...
A fenti megoldással meg tudtok békélni, vagy menjünk át jogászkodásba?
Tapasztalatom szerint igen. Illetve egyszer egy háttérbeszélgetésen volt róla szó, hogy ez feature, mert a kézi számla esetén nincsen semmilyen validáció, amit szoftver végezne, így pl. lehet, hogy alap + adó <> bruttó, de ezt is be kell tudni rögzíteni a felületen a usernek.
Részemről elengedhetjük a dolgot, egy ideje már sok helyen olvasható az a NAV álláspont, hogy az error is lehet teljesített adatszolgáltatás...
Kétségeim vnnak azt illetően hogy a kezdő dátum korábbra vitele tényleg annyira rongálná az adatminőséget, de ha így van, akkor részemről is elengedhetjük.
Részemről is elengedhetjük, Én azért izgultam rá most erre, mert tegnap volt egy olyan tapasztalatom, ahol kötelező bevallást kellett benyújtanom. de sajnos nem ÁNYK nyomtatványon, hanem webes ügysegéden, és megtagadta a bevallás benyújtását, mert szerinte a KSH szám hibás volt. Pedig helyes volt. Üres nem lehetett a mező, és a helyes adatot meg nem fogadja el. Leírás nincs + a hibaüzenet semmitmondó. 2 órás telefonos várakozás után a support közölte, hogy nem foglalkozik ezzel. Kinyomtatni nem lehetett, bizonyítani sem tudom, hogy megpróbáltam benyújtani a bevallást. Ennek a mentalitásnak kellene mindenkorra véget vetni. hogy egy szoftver hibája, vagy annak a logikája megakadályozhassa, hogy eleget lehessen tenni a bevallási kötelezettségnek. A Skynet felé haladunk.
A kollégám nagyon gyors volt: jelenleg a kézi rögzítő nem engedi meg már a felületen sem rögzíteni a 2010. előtti dátumot. Így el sem tud jutni oda a felhasználó, hogy error-ra fusson a kézi adatszolgáltatása. Az egyébként egy szakmai elvárás volt a kézi rögzítővel szemben, hogy error-os adatszolgáltatásra ne futhasson a felhasználó.
Az a baj, hogy minden dátumra ráhúzták ezt az évszám ellenőrzést. Így aki gépjárművet ad el és meg kell adnia az első üzembe helyezés dátumát az sem adhat meg ennél kisebb dátumot, bár vannak korábban forgalomba helyezett járművek... Ilyenkor azt szoktuk mondani adja meg a 2010 január 1-i dátumot, mert a NAV-soknak biztos nincs öregebb járművük :)
