1310. INCORRECT_HEAD_DATA_EXCHANGERATE_EXTREME

[NTCA-tax]

Kedves Fejlesztők!

Az 1310. INCORRECT_HEAD_DATA_EXCHANGERATE_EXTREME validációs feltétel szeptember 15-től error-rá válik. Köszönjük az összes észrevételeiteket az EXCHANGERATE-hez kapcsolódó feltételekkel kapcsolódóan. Egy kis hátteret írok a szakmai elvárásokkal, valamint a működési változásokkal kapcsolatban.

Ennek a feltételnek az a célja, hogy ha egy folyamat félremegy, és valami nagyon hibás érték kerülne bele (pl. 40000 HUF/EUR), akkor jelezzen. Sajnos ténylegesen és viszonylag sok olyan esettel találkozunk, amikor messze nem egy árfolyam, vagy valamilyen nagyon hibás árfolyam kerül bele az adatszolgáltatásba, és a mi oldalunkról ezzel számolunk. Tehát ezek nem olyan esetek, hogy valaki más időszaki valós árfolyamot ad meg, hanem adott pénznem árfolyamaként értelmezhetetlen az adat.

A felvetéseiteknek megfelelően egyrészt a feltétel currencyCode listáját szűkítettük az általunk jelenleg legproblémásabbakra, másrészt a tartományt kibővítettük. Amennyiben bármikor is előfordul, hogy ezen intervallumba valósan nem fér bele egy pénznem, akkor ezt az intervallumot bővítjük, ez NAV oldali feladat.

currencyCode	Minimum	Maximum
EUR	250	600
USD	200	600
GBP	250	720
CHF	200	600
BGN	120	360
RON	50	180
PLN	50	180
SEK	20	72
NOK	20	72
CZK	5	48
ILS	40	240
DKK	20	120
BAM	100	360

A fenti logikai miatt kapcsoltuk ki az 1301-es validációt, mivel az 1310-es validáció egyébként is errorra küldené azokat az eseteket, amikor valaki 1 HUF/EUR árfolyamot adna meg. Mivel számunkra ezek a legfájóbbak, ezért jelenleg ezt az intézkedést megfelelőnek gondoljuk és remélhetőleg a fenti listában szereplő egyik pénznem és a magyar forint sem fog olyan hektikusan változni, hogy túl gyakran bele kelljen nyúlni ebbe a paramétertáblába.

A fenti paramétereket azonban nem akarjuk API-n keresztül lekérdezhetővé tenni. Kerülni akarunk minden olyan szoftverműködést, amelynek a célja csupán az, hogy ezen intervallumokba csak beleférjen az árfolyam. Az adózó feladata ugyanis, hogy az áfatörvénynek megfelelő árfolyamot tüntessen fel és nem az, hogy egy adatszolgáltatási intervallumba férjen bele. Ugyanakkor túl sem akarjuk bonyolítani, hiszen a kereskedelmi banki, MNB, EKB napi árfolyamokat kellene figyelnünk. Az olyan extrém adatokat, amelyek biztosan nem megfelelőek, ki akarjuk viszont zárni.

Remélem a fenti háttérrel érthetőbbek a döntéseink, és az is, miért lesz error az 1310-es validáció és miért változnak a fentieknek megfelelően a paraméter értékei.

[omachtandras]

@NTCA-tax köszönjük a leírást. Értem az okot, de továbbra is azt gondolom, hogy ha hibázott is az adatrögzítő, akkor is a számla elkészült és be kellene tudni küldeni. Mert ha észreveszi a hibát, akkor majd sztornóz. Ha nem, akkor meg lehet levelet / ellenőrzést küldeni rá, és akkor majd figyel. Vagy tényleg megcsináltatja a programjába, hogy az ne "kézi" árfolyamokkal dolgozzon, hanem mondjuk töltse le az MNB-től és használja azt...

Mindenesetre mi most megpróbáljuk beépíteni a programjainkba ezeket a határokat, változtatható módon, mert az biztos nem működik, hogy ha változás van, akkor majd az ügyfél verziót vált ez miatt.

Viszont az nagyon fontos lenne, hogy ha változnak a határok, akkor előre, itt is kapjunk róla értesítést, hogy mi magunk tudjuk értesíteni az ügyfeleket, hogy figyeljenek, teendő van. Plusz feladat, de még mindig kevésbé fájdalmas előre foglalkozni vele, mint amikor jön a telefon, hogy "nem tudok számlázni, mert a program nem engedi", de a felhasználónak nincs joga állítani ezeket a paramétereket, keresni kell valakit, akinek van, a vevő / kamion / bármi meg ott áll és értékesíteni kellene...

Köszönöm

[NTCA-tax]

Értem az érveidet, és nagyon sokat is vitatkoztunk erről a feltételről, valamint az adatszolgáltatásokat is elemezgettük. Éppen azért, hogy ne nagyon legyen szükség gyakori változásokra, tágítottuk az intervallumokat és töröltünk validációt. Ugyanakkor adatminőség és adathasznosítás szempontjából azok az adatszolgáltatások, amely nagyon valótlan árfolyamértéket tartalmaznak nagy károkat okoznak. Minden eset mellé pedig nem tudunk ellenőrt állítani. Csak tavaly több mint 150 ezer ilyen adatszolgáltatás érkezett 3 ezer adózótól, 88 ezer esetben pedig úgy volt 1 az árfolyam, hogy nem forint volt a számla pénzneme. A warningok ellenére az elmúlt években jelentősen nem csökkent ezen adatszolgáltatások száma.

Az árfolyam intervallum eddig is része volt a specifikációnak a validáció bevezetése óta. Tehát ha valaki az általad leírt elővalidációs működést szerette volna megvalósítani, eddig is megtehette. Természetesen az új működés szerinti specifikációba is közzé tesszük az árfolyam intervallumokat, nem csak innen fogjátok látni.

Továbbra sem vizsgáljuk az árfolyam pontosságát, csak ezen néhány pénznem esetén az extremitást. Tehát attól, hogy egy árfolyam belefér ebbe a sávba, attól még előfordul, hogy nem helyes, nem felel meg a jogszabályi követelménynek.

Fontos megjegyzés marad, hogy szükség esetén előzetes értesítés nélkül is módosíthatjuk az intervallumot. Csak remélni tudom, hogy erre nem fog sor kerülni, hiszen ez egy pénznemnek a jelentős problémáját jelentené. De nyilván ha nem ilyen esetről beszélünk, akkor egyrészt előre jelezzük. Az intervallumok azonban annyira tágak, hogy erre azért túl sűrűn nem kell számítani.

[Macskafarka]

Ezzel nem tud egy számlázó program, sem egy ügyfél mit kezdeni: "előzetes értesítés nélkül is módosíthatjuk az intervallumot". Levonható belőle az a következtetés is (ügyfél oldali elvárásként is megjelenhet), hogyha ERROR-t kapott a számla, akkor 5 perc múlva újra meg lehet próbálni, vagy 2 nap múlva, vagy 6 hónap múlva, mert BÁRMIKOR változhat a kapuőr kedve és akár el is fogadhatja a számlát. Ez kezelhetetlen. Ebben éppen a bizonytalanságot érzem, mert a NAV is tisztában van azzal, hogy nincs semmi, de semmi jogszabályi alapja. A jogszabálynak nem ellentmondó számla befogadásának megakadályozása. történik, és az indoklás az, hogy nem tetszik valakinek az adatminőség, és ő tudni véli, hogy mi a helyes árfolyam. Ugyanakkor semmi nem írja elő az árfolyamnak a szerepeltetését a számlán, az ÁFA tv. csak a megfelelő árfolyam ALKALMAZÁSÁT tartalmazza, vagyis a számlabizonylat egészén összesen áthárított ÁFA Ft összegét kell a megfelelő árfolyamon kiszámolni és a számlára ráírni. Ha ez teljesül, akkor a számlát be kell fogadni. Fordított áfás belföldi devizás számlán eleve nincs áthárított ÁFA, és nem is kell a törvény alapján semmiféle árfolyam rá, de ha nem jó az árfolyam, akkor simán ERROR-t ad a NAV, vagyis teljesen indokolatlanul. Ez nonszensz.

[Macskafarka]

Elmondtuk az érveinket, és elhiszem, hogy a NAV tényleg átgondolta, majd ismét átgondolta, hogy miért vezeti be erre az ERROR-t. Itt nem tudunk tovább lépni ebben a kérdésben. Jó lenne, ha a jogalkotó oldaná meg a helyzetet, mert mi is, a NAV is jogalkalmazó.

[NTCA-tax]

A jogszabály teljesen egyértelmű. Az áfatörvény 10. számú melléklete előírja, hogy a külföldi pénznemben kiállított számlák esetén a 80. § és 80/A. § szerinti árfolyamról köteles az adóalany adatot szolgáltatni. Az adóhivatal egy validációs feltételt alkalmaz, hogy a megadott érték lehet-e egyáltalán árfolyam egy tág intervallum alapján. Amennyiben nem, akkor az adatszolgáltatás olyan adatot tartalmaz, amely az áfatrövény ezen rendelkezésének ellent mond, ezért adunk error üzenetet.

Az előzetes értesítés nélküli változtatásra még egyszer ráfordulok akkor. Az árfolyamok változását nem áll módunkban befolyásolni, mi is követjük azokat. Az előző bejegyzésembe írt eset az, amikor egy pénznem elkezd összeomlani, és nem lesz időnk előzetesen több hónapos átállási idővel meghirdetni az intervallumok változását, vagy egy pénznem kikerülését a táblából. Nyilván ez vészforgatókönyv, de arról szerintem fontos szólnunk (specifikációba foglaltan, mint eddig), hogy ekkor ezt fogjuk csinálni.

[Macskafarka]

Kedves @NTCA-tax! Megértetem az érveket. Azt kellene valahogy feloldani, hogy a számlakibocsátónak törvényi kötelezettsége a már kiállított számlát beküldeni az adatszolgáltatásba, és ha ez nem jut el a befogadásig, akkor bünti lehet a következmény. Ha ERROR miatt a befogadás elutasításra kerül, akkor lehetetlen az adatszolgáltatást teljesíteni. Mondja ki valaki akkor, hogy ebben az esetben NEM kell teljesíteni az adatszolgáltatást egy papírom már létező számláról. Ha lenne korrekciós lehetőség, vagy megoldás erre, akkor nem lenne ekkora gond egy új ERROR validáció bevezetése. Azt várom, hogy kimondásra kerüljön, hogy csak a JÓ számlákat kell betenni az adatszolgáltatásba, mert a NAV csak a helyes számlákat gyűjti, nem minden számlát. :)

[NTCA-tax]

A helyes folyamat az lenne, hogy minden kiállításra került számla eljut az Online Számla rendszerig. Attól, hogy egy adatszolgáltatás errort kap, nem jelent automatikus szankciót. Egy erős figyelem felhívás, hogy valami nagy baj van a számlával és/vagy az adatszolgáltatással, amivel kell valamit kezdeni. A szankciót akkor jöhet, ha az adózó nem foglalkozik az egésszel és főleg ha tömeges a nem javított hiba. Tehát nem a hibamentesség a követelmény, hanem ha adunk hibajelzést, akkor foglalkozzon vele az adózó.

Csak megjegyzem, hogy mulasztási bírságot a NAV nem az error esetén szabja ki, hanem a hibás adatszolgáltatás esetén. A hibás adatszolgáltatás lehet warning jelzésnél is, sőt akár hibajelzés nélkül is lehet egy adatszolgáltatás hibás. De én is látom, hogy más az ügyfelek érzékenysége, ha egy adatszolgáltatásra errort adunk, mintha "csak" warningot.

Visszatérve az eredeti kérdésedre és nnnél a validációnál maradva: 400,15 HUF/EUR árfolyam helyett 40015 HUF/EUR árfolyamot üt be az ügyintéző, amely eredményeként kiállításra kerül egy nyilván helytelen adattartalmú számla. Ennek automatikusan be kell mennie a NAV-hoz és megkapja az errort (legalább is szeptember 15-től). Ennek sztornója is megkapja az errort, hiszen az is ezt a helytelen árfolyamadatot fogja nagy valószínűséggel tartalmazni. Ezt követően kiállítja helyesen a számlát és azt már befogadja a NAV. Ez egy teljesen jó folyamat, hiszen hibázni lehet, de látja a hibát az ügyintéző, és javítja a számlát. Nagyjából ez lenne az elvárt működés, és ebben az esetben a két error nem jelent semmilyen bírság kockázatot.

A NAV célja, hogy az Online Számla rendszerben a feldolgozott adatszolgáltatások adatminősége olyan legyen, hogy tudjon azokkal jó elemzéseket végezni, megfelelő szolgáltatásokat építeni akár épp az ügyfelek számára. Az utolsó mondatodat annyiban finomítanám, hogy csak jó számlákat dolgoz fel az adóhivatal. Adatot szolgáltatni minden kiállított számláról kell, csak lesznek olyanok, amelyeket nem enged be az adóhivatal a rendszerbe és erről értesíti az ügyfelet.

[topybear]

A rossz számlákat nem gyűjti, mert be sem engedi őket! :)
Az ügyfeleinknél az a gyakorlat, hogy az ilyen számlákat sztornózzák - természetesen az sem tud bemenni, Utána megcsinálják jól a számlát, a szornózott-sztornó párosról meg felvesznek egy jegyzőkönyvet, hogy mi történt.
Kb. hasonló a helyzet, mint amikor ugyan kiáll a számla, de már a beküldés észreveszi, hogy nem jó és meg sem próbálja beküldeni (mert ügysem menne be). Tipikusan az szokott lenni, hogy valahogy csak sikerül nem megengedett karaktert bevarázsolniuk valahová - jellemzően pdf-ből bemásolnak valamit, ott mindenféle vicces, láthatatlan karakterek szoktak lenni a szövegben. A copy-paste miatt a rögzítő felület karaktermaszkolásán simán átmegy. Szerencsére ezek egyre rtkábbak, mert a legtöbb helyen már utólagos ellenőrzésekkel, automata adattisztításokkal levédtük, de a felhasználói kreativitás határtalan (miután a kézi számlázó felület teljesen le lett védve, továbbszámlázott tételekkel ütöttek rajtunk, mikor ezt a kiskaput is bezártuk , akkor az áfa törzs karbantartóján át a mentesség szöveges leírásán keresztül támadtak! :D

[omachtandras]

@NTCA-tax mi a helyzet akkor, ha nem stornóz, hanem egy tekintet alá eső okirattal próbál javítani? Akkor az eredeti ugye nem ment és az okirat sem, pedig már a kettő együtt elvileg jó kellene, hogy legyen, mégsem lesz bent a rendszerben.
Ez a befogadó oldalnak sem jó, ha feldolgozásra használná az online számla adatait, mert SEMMIT nem lát abból, hogy készült számára számla. És ide venném még, hogy elektronikus számlaként a hasht is be szerette volna küldeni a kiállító, de ugye ez sem sikerült.

Az ügyfélkörünkben "szerencsére" az a gyakolat, hogy stornóznak, de arról meg ugye az volt a mondás, hogy stornózni akkor kell és szabad, ha a gazdasági esemény nem történt meg. Remélem ez a mondás nem lesz még jó ideig véresen komolyan véve. :)

[NTCA-tax]

Az árfolyam nem számla adattartalmi, hanem adatszolgáltatás adattartalmi elem. Elvileg a számlán nem is kell feltüntetni, csak adatszolgáltatásban. Ha nagyon jogszabályszerűen kellene eljárni, akkor nem is a számlát kellene korrigálni, hanem kizárólag az adatszolgáltatást, hiszen számla adattartalma nem változik meg. De gondolom ennek a levezetésnek a végrehajtatását Te sem szeretnéd... Úgyhogy maradjunk az utolsó mondatodnál :)

[Macskafarka]

Kedves @NTCA-tax! Erre reagálok: "mulasztási bírságot a NAV nem az error esetén szabja ki, hanem a hibás adatszolgáltatás esetén" Én mást olvasok ki a jogszabályból: A számla adatszolgáltatás elmulasztása miatt kiszabható bírságtétel számlánként 1.000 000 Ft.
Az Áfa tv. 10.sz. mellékletének 4. pontja kötelezően előírja a számlázó programmal kiállított számláról az adatszolgáltatás TELJESÍTÉSÉT:
„4. A számlázási funkcióval rendelkező programmal kiállított számla, számlával egy tekintet alá eső okirat esetében az adóalany külön jogszabályban meghatározott elektronikus módon teljesít adatszolgáltatást a számla, számlával egy tekintet alá eső okirat e törvény szerinti adattartalmáról, továbbá az adó alapjának meghatározásakor használt pénznemről, külföldi pénznem esetén a forintra átszámított adatokról és a forintra történő átszámításhoz alkalmazott, 80. § és 80/A. § szerinti árfolyamról. Nem adóalany természetes személy részére kibocsátott számla, számlával egy tekintet alá eső okirat esetében az adatszolgáltatás nem terjed ki a termék beszerzőjének, szolgáltatás igénybevevőjének nevére és címére.”

A Számlaadat-szolgáltatás REST API interfészleírás és fejlesztői dokumentáció 4. oldalán ez áll:
„Az adatszolgáltatás addig nem tekinthető teljesítettnek, amíg a kliens az aszinkronfeldolgozás sikerességéről meg nem győződött és az adott számlához tartozó nyugtaüzenetet meg nem kapta.” Tehát én úgy értelmezem, hogy a nem teljesített adatszolgáltatás miatt bünti lehet, és az ERROR az nem teljesítésnek számít. Azt nem tudom, hogy a NAV jogkövető-e ebben, vagy mikor bűntet, de ezek vannak leírva.

[NTCA-tax]

Az Art. 229. § a következőt tartalmazza: "Az általános forgalmi adó összesítő jelentés szerinti adatszolgáltatási kötelezettség elmulasztása, késedelmes, hiányos, hibás vagy valótlan adattartalmú teljesítése esetén a kiszabható mulasztási bírság felső határa az érintett számlák, illetve számlával egy tekintet alá eső okiratok számának és az általános bírságszabály szerinti bírság adózóra egyébként vonatkozó legmagasabb mértékének szorzata."

Az a megjegyzésem, hogy a mulasztási bírságot nem error esetén szab ki az adóhivatal, hanem hibás adatszolgáltatás esetén, ebből következik. Tehát ha egy adatszolgáltatásra warningot adunk, akkor is szankcionálható az adatszolgáltatás, amennyiben hiányos, hibás vagy valótlan adattartalmú volt. Az error is hiányos, hibás vagy valótlan adattartalmú, de olyan problémás, hogy fel se akarjuk dolgozni, mert elemzésre, további felhasználásra teljesen alkalmatlan. Nagyjából ez a két hibaüzenet között a fő különbség, de ugyanúgy szankcionálható mindkét hibaüzenet esetén az adatszolgáltatás. Sőt, ha nem adunk vissza hibaüzenetet, akkor is lehet hibás az adatszolgáltatás. Előfordulhat, hogy teljesen rendben van az adatszolgáltatás logikailag, csak éppen a számla adatokhoz nincs sok köze (pl. az összegeknél a tizedes vesszőt minden esetben odébb helyezi). Nyilván ez utóbbit nehéz kiszűrni még adózói oldalon is.

A adatszolgáltatás teljesítettsége ettől egy kicsit eltérő kérdés. Az előző példánál maradva a 40015 HUF/EUR árfolyamadatú adatszolgáltatással rendelkező számla beküldése azzal zárul, hogy errort fog adni a rendszer. Ekkor a visszaigazoló nyugta error lesz, mivel a rendszer működése szempontjából nem fogadható be ilyen adattartalommal adatszolgáltatás. De az adatszolgáltatást ettől be kell küldeni, nem nyelheti le a számlázó program (már ha eljutott a számla kiállításáig a folyamat). Nem lesz nyilván feldolgozott az adatszolgáltatás, hiszen erről szól az error üzenet, és ekkor jön vagy az adatszolgáltatás javítása vagy pedig sztornó és új számla. Ez attól függ, hol történt a hiba.

Az általad kiragadott mondat arról szól, hogy a nyugtaüzenetet le kell kérdezni. Ez szerepel egyébként a rendeletben is egy kicsit máshogy megfogalmazva. Nyilván ez a mondat a pozitív esetet írja le, amikor feldolgozható, befogadható az adatszolgáltatás az adóhivatal oldalán is. De ugyanúgy egy nyugtaüzenet az error is, ugyanúgy le kell kérdezni. Ettől még teljesített az adatszolgáltatás, az más kérdés, hogy az hiányos, hibás vagy valótlan adattartalmú. Az error erre hívja fel a figyelmet, nem pedig arra, hogy az adatszolgáltatási kötelezettséget elmulasztotta volna a szoftver.

A fentiek alapján az errort úgy kellene tekintened, hogy az adatszolgáltatási kötelezettség teljesült, de nyilvánvaló módon súlyos hibákkal. Az adóhivatal ebben az esetben nem az adatszolgáltatás elmulasztása miatt szankcionál, hanem a helytelen adattartalom miatt, amennyiben persze nem kerül kijavításra. Persze a felhasználóknak nehéz elmagyarázni, hogy bár nem látja az adóhivatali oldalon, de teljesült az adatszolgáltatás. Az adóhivatali oldalon pedig ugyanazon mondatnak egy másik része alapján történik szankcionálás... De a végcél mindenképpen az, hogy egy erroros adatszolgáltatás esetén valamit javítson az ügyfél, bármennyire is érti ezt a levezetést.

[Macskafarka]

Köszönöm!