Online-Invoice
Online-Invoice copied to clipboard
nav-gov-hu
MI a teendő sikertelen (ABORTED) adatszolgáltatás és sztornója esetén?
Sziasztok!
Nem az első ügyfelünknél fordul elő az alábbi eset:
- Kiállításra kerül egy számla, melynek az adat tartalma hibás és az adatszolgáltatás is ennek megfelelően ABORTED lesz.
- A számla kiállítója észreveszi és érvényteleníti (magyarán sztornózza). Mivel a sztornó az eredeti számlával megegyező, de ellenkező előjelű tételeket tartalmaz, így ez a számla adatszolgáltatása is ABORTED lesz.
- Majd kiállítja a helyes számlát és azt adja/küldi a vevőnek.
Ezek után van két ABORTED adatszolgáltatásunk, ami tulajdonképpen a valós folyamatot írja le, de erről soha nem lesz automatikusan helyes adatszolgáltatás - a hibás adattartalom miatt.
Kérdésem: Mi a teendő?
- Összecsatoltan lefűzni a két hibás bizonylatot (papír alapú) és esetleg egy jegyzőkönyvben leírni a történteket és mellé fűzni. Ezzel lezárult ez az esemény. Nem szükséges ezekről a számlákról adatot szolgáltatni.
- Mindenképpen adatszolgáltatást kell produkálni, akár úgy is, hogy nem a valós számla tartalmat és folyamatot írja le.
Próbáltam keresni választ a korábbi felvetésekben, de így konkrétan nem találtam választ.
Köszönöm előre is!
Üdv konyisoft! A legelején amikor ilyen hibám volt, akkor megállapítottam, hogy az adattartalom hibája milyen jellegű. Nálam pl. a productCodeCategory = OWN-nal volt baj, a productCodeOwnValue értéke rövid volt (000 helyett 0). Ez semmilyen formában nem érintette a számlát, így kijavítottam a 0-t 000-ra, újraküldtem először az eredeti számlát, majd a sztornóját is. Ezzel helyreállt a rend. Amúgy az online felületen lehet érvényteleníteni a feladást (ezt még nem próbáltam). üdv István
A számlázó program nem végezhet olyan folyamatot, melynek eredményeként eldönti, mely számlákról ad adatszolgáltatást, melyekről nem. Tehát a számlázó programnak akkor is neki kell futnia az adatszolgáltatásnak, ha az akár előre láthatóan sikertelen lesz. Tehát mind a hibás számlának, mind annak az érvénytelenítésének az adatszolgáltatását be kell küldenie, melynek eredménye error lesz. Ezt követően kiállításra kerül a helyes adattartalommal a számla, mely remélhetőleg már DONE-t kap.
Az error-t kapott adatszolgáltatásokkal kapcsolatban nincs további teendő. Amit nem szabad, hogy a hibás számlaadatot az adatszolgáltatásban kijavítja a felhasználó, hogy az adatszolgáltatás formailag teljesüljön. Továbbá azt sem szabad megtenni, hogy a hibás adatszolgáltatással érintett számla érvénytelenítésének az adatszolgáltatása ne kerüljön feladásra.
Kedves @NTCA-tax ,
hasonló témában kérdezem a véleményed:
Mi a helyzet abban az estben, ha a manageinvoice után a funccode-ban ERROR keletkezik, tehát a számla nem került befogadásra? Itt a probléma a következő: A számla lezárva, nem lehet módosítani. Stornózni lehetne, de mivel azt is be kell küldeni, az is ERROR-al fog visszapattanni. Ha ezeket (sem) kell (lehet) újra beküldeni, mi lesz a helyzet a hiányzó számlaszámokkal? Érvényteleníteni nem lehet, mert nem szerepel a befogadott számlák között.
Vizsgálja/szankcionálja ezt a NAV?
Tehát hiányozhat számlaszám a tömbből (lehet kihagyás) az érvényes beküldések közül? Értelmezésünk szerint, ha ERROR volt a beküldés, tehát üzleti feldolgozásra nem került a számla, akkor a NAV adatbázisban nem is létezik.
Valóban jó ez így?
Előre is köszönöm a választ.
Amennyiben hibás egy kiállított, de ki nem bocsátott számla, akkor azt is érvényteleníteni szükséges. Ez független attól, hogy az adatszolgáltatás sikeres-e vagy sem. A hibás számla érvénytelenítése nem adatszolgáltatási kérdés.
Az előzőtől független kérdés a számlasorszámok sorfolytonossága. Az adatszolgáltatásból számos ok miatt hiányozhat számlasorszám, ezért a sorszámozás folyamatosságát nem vizsgáljuk. Ilyen ok lehet, hogy egy számlasorszám tartományban kiállításra kerülnek például hibás számlák, számviteli bizonylatok, adatszolgáltatásra nem kötelezett bizonylatok. De ettől függetlenül a számlázó programnak a sorszámozás folyamatosságát kell teljesítenie, de ez az adatszolgáltató rendszerben nem fog látszódni.
Kedves @NTCA-tax,
csak az adatszolgáltatás oldaláról megközelítve: Ha egy számla a beküldést követően "Súlyos üzleti hibát" tartalmaz, attól még csak és kizárólag adatszolgáltatás szempontjából teljesítettnek tekinthető-e?
@NTCA-tax: Hasonló kérdésem van nekem is. A felhasználó nem online számlázó programot használ. Kiállított az egyik telephelyen egy 1/2021-est és egy 2/2021-es számlát. Mindkettő bement a NAV-hoz, adatszolgáltatás sikeres. Egy másik telephelyen is használni kezdik a programot, de hanyagságból nem állítanak be előtagot. Kiállítanak itt is egy 1/2021-es számlát, aminek az adatszolgáltatása sikertelen lesz, mivel már van ilyen bizonylatszám a NAV-nál.
Ilyenkor mi a helyes eljárás?
- Állítson be egy előtagot és szimplán állítson ki egy új számlát (pl. B1/2021)? De akkor, mi lesz a második 1/2021-es számlával, az csak lóg a levegőben? VAGY
- Állítson be egy előtagot, majd stornózza a számlát. Az így kiállított B1/2021-es érvénytelenítő számla az első telephelyen kiállított 1/2021-es számlát fogja stornózni az adatszolgáltatásban, ami nem jó (ha mindkét 1/2021-es számla azonos tételből állt, akkor a stornózás adatszolgáltatása sikeres lesz). Emiatt a B1/2021-es érvénytelenítő számla adatszolgáltatását technikailag érvényteleníteni kell. Majd B2/2021-es sorszámmal kiállítható az új számla. Ez így megfelelő?
@NTCA-tax : "ezért a sorszámozás folyamatosságát nem vizsgáljuk" ez is felvet egy kérdést: Az ügyfél kiállított 17 db számlát márciusban, 17 számla van fent a NAV-nál. Ezt követően adatvesztése történt, újratelepítette a gépét, visszatöltött egy régi mentést (amiről azt hitte, minden számlát tartalmazott, de nem...). Ismét számlázni kezdett, sőt stornózott is. Bizonyos számlákat az ügyfél tecnikailag érvénytelenít és újraküld. Az eredmény pedig a NAV rendszerében: 13-14 márciusi számla, 15 áprilisi, 16-17 ismét márciusi. Minden számla fent van NAV-nál, a sorszámok folyamatosok, de mivel "trükközött" az ügyfél az adatszolgáltatás érvénytelenítésével, így beszúrt 15-ös sorszámnak egy április számlát. Ezt se veszi észre a NAV? A programban adatbázisában persze minden szépen sorrendben van, vagyis a sorszámok a dátummal együtt emelkednek, de a technikai érvénytelenítéssel és újraküldéssel ezen a ponton a NAV rendszere megkeverhető.
@nbeeps2 , miből venné észre ezt a NAV? Revíziónál tud ez kiderülni hogy xml és papír nem egyezik. Illetve akkor hogyha két cég is visszaigénel ugyanarra a számlára hivatkozva. Szerintem egy kockázatelemző bejelezhet erre NAV oldalon és reviziót kezdeményezhetnek miatta, ha ilyen szintű ellenőrzések futnak már. (Nem tudom hogy az ilyen szintű ellenőrzésekkel hogy állnak ez csak feltételezés) Ez olyan jellegű probléma hogy a queryInvoice nem tudja jelenteni mert nincs meg hozzá az információja. Max egy WARN-t dobhatna hogy annul után erősen eltérő adatok jönnek az előző verzióhoz képest, de semmiképp sem lehet ebből ERROR, hiszen lehet pont azért volt annul, mert eredetileg tök más adat lett lejelentve.
Kedves @NTCA-tax,
csak az adatszolgáltatás oldaláról megközelítve: Ha egy számla a beküldést követően "Súlyos üzleti hibát" tartalmaz, attól még csak és kizárólag adatszolgáltatás szempontjából teljesítettnek tekinthető-e?
Erre a kérdésemre szeretnék választ kapni. Köszönöm.
Az adatszolgáltatást úgymond teljesítetted azzal, hogy megpróbáltad beküldeni, de mindenképp sztornóznod kell - ami értelemszerűen ugyanúgy ABORTED lesz. Olyan számlád nem lehet, ami "élő", de nincs pozitívan visszaigazolt adatszolgáltatása.
Ha ABORTED a számla feladás, akkor azt kézzel fel kell vinni a NAV honlapján? Vagy az csak arra vonatkozik, amikor a számla kiállító oldalán x napon túli üzemzavar áll fent, és így a kiállított számlákat a kiállító kézzel kell, hogy rögzítse a honlapon.
Kedves @SimplifiedSzamla Ha aborted a számlaadatszolgáltatásod akkor nézd meg mi a hiba és ne töltsd fel kézzel. Ki kell javítani vagy a számlát vagy az adatszolgáltatást.
Ha a számlát nem sikerült jól kiállítani akkor stornózni kell azt is be kell küldeni (Az is Aborted lesz, mert a hivatkozott számla sincs bent) Ha a számla jó csak az adatszolgáltatás nem akkor azt javítsd ki és add fel az API-n.
Kedves @renced42, köszönöm a gyors választ!
Tehát ha céges vevő és rossz adószám volt a számlán - ekkor ezt stornózni kell és újra kiállítani. A stornó is ABORTED, az új számlánál pedig remélhetőleg a jó adószámot adták meg, nincs további teendő.
Kedves @renced42, köszönöm a gyors választ!
Tehát ha céges vevő és rossz adószám volt a számlán - ekkor ezt stornózni kell és újra kiállítani. A stornó is ABORTED, az új számlánál pedig remélhetőleg a jó adószámot adták meg, nincs további teendő.
Ezen szituáció kezelése, amit @SimplifiedSzamla írt, akkor végülis helyes?
Illetve az eredeti kérdésekre/szituációkra nem látok egyértelmű konklúziót, hogy akkor mi a teendő. Valaki igen/nem vagy tőmondattal le tudná írni egyértelműen, egyszerűen, hogy akkor az ABORTED számlát kell-e sztornózni (nyilván ABORTED számlával) vagy sem?
igen; de szerintem ezt már NTCA-tax egyszer megerősítette, hogy sztornózni kell, arra ugyanúgy aborted lesz a válasz - viszont ezzel dokumentáltad, hogy eleget tettél az azonnali jelentési kötelezettségnek - és utána mehet a jó számla szvsz érdemes jegyzőkönyvezni, hogy miért lett ABORTED az eredeti adatszolgáltatás
Próbálok végigmenni a felmerült kérdéseken:
Két telephely azonos sorszámtartomány probléma: az áfa törvény alapján a számlának az adott adóalany esetén egyértelműen kell azonosítania a számlát. Tehát helytelen az a gyakorlat, hogy 1/2021-es sorszámmal előáll ugyanannak a vállalkozásnak két telephelyén számla. Ekkor megoldás lehet a prefix vagy szuffix használata is. Amennyiben előállt az eset, akkor az 1/2021-es sorszámú számlát vagy az egyik, vagy akár mindkét telephelyen érvényteleníteni szükséges. Ezt követően pedig áttérni vagy eltérő sorszámtartományra, vagy pedig a prefixre, szuffixre.
@nbeeps2 által felvetett adatvesztési kérdés nem adatszolgáltatást érint, hanem ellenőrzési kérdéseket. Az adatszolgáltatási rendszer nem fog visszaadni hibaüzenetet, de ettől egy ellenőrzésen a revizor érdeklődését felvetheti.
@kpistvan128 által felvetett súlyos üzleti hibát tartalmazó adatszolgáltatás: maga az adatszolgáltatás teljesített, ugyanakkor vagy a számla hibás, vagy pedig az adatszolgáltatás adattartalma. Egyébként pont ugyanazon Art. pont alapján szankcionálhatunk nem teljesült és nem megfelelően teljesült adatszolgáltatás miatt.
@SimplifiedSzamla Amennyiben egy adatszolgáltatás aborted-ra fut, akkor meg kell vizsgálni miért. Amennyiben a számla adattartalma hibás, akkor a számlát, amennyiben az adatszolgáltatás a hibás, az adatszolgáltatást kell javítani. Amennyiben a számla adattartalmi hiba miatt adtunk aborted-et, akkor nem megfelelő gyakorlat az, hogy a helyes adatokat a felületen rögzíti a felhasználó. Amennyiben az adatszolgáltatás nem megfelelő, akkor persze lehet az is egy út, hogy manuálisan történik meg az adatszolgáltatás, de ekkor a gépi hibát manuális adatrögzítéssel javítja a felhasználó. Feltételezve, hogy a számla adattartalmával van a probléma, akkor és ezért futott aborted-ra, akkor a számlát érvényteleníteni kell (ez is aborted-ra fut), majd helyes adattartalommal előállítani a számlát és teljesíteni az adatszolgáltatást (ez remélhetőleg már nem fut aborted-ra).
@NTCA-tax
Feltételezve, hogy a számla adattartalmával van a probléma, akkor és ezért futott aborted-ra, akkor a számlát érvényteleníteni kell (ez is aborted-ra fut), majd helyes adattartalommal előállítani a számlát és teljesíteni az adatszolgáltatást (ez remélhetőleg már nem fut aborted-ra).
Ha jól értem, akkor ebben az esetben az új helyes számlát úgy kell kiállítani, hogy nem hivatkozik az első eredeti számlára? Mert ha hivatkoznék az eredeti számlára, akkor az új helyes számlám is hibára futna, mivel az eredeti számla nincs bent az adatszolgáltatásban,
Köszönöm a válaszokat
