Online-invoice: Stornószámlák - VatRateType kezelése 2.0 vs. 3.0 [FEATURE]

Created on 19 Oct 2020 · 18Comments · Source: nav-gov-hu/Online-Invoice

Az igény összefoglalása / Summary of the request
A VatRateType típusban a 2.0 verzióban 6 elem megadására van lehetőség, ez a 3.0 verzióban 8-ra nő. Így a 2.0 verzióval beküldött olyan számlák stornózása esetén, amelyek pl. adómentes tételt tartalmaznak, a 3.0 verzióban lehet, hogy más értéket kell megadni (pl.: "alanyi adómentes" helyett "AAM", "tárgyi adómentes" helyett "TAM", stb.). Mivel a korábbi verzióban nem volt kötelező a rövidítés használata, ezért a 3.0 verzió (valószínűleg) hibaüzenetet ad, ha a megadott érték (pl. "alanyi adómentes") nem tartozik bele az értékkészletbe.

Az általam javasolt megoldás / The solution I propose
A 3.0 verzióban, a VatRateType elem használata során a rendszer fogadja be a korábbi verzióban beküldött számlák stornózása esetén az itt megadott értéket akkor is, ha az nem esik bele az új típusban használt értékkészletbe, és ne adjon vissza hibaüzenetet. Magyarul legyen visszafelé kompatibilis.

Elfogadható alternatívák / Acceptable alternatives
Jelen tudásunk szerint nem ismert.

Egyéb tartalom / Additional content
Amennyiben a fenti kérés nem megvalósítható, akkor két NAV verzió szerint működő programot kellene mindenkinek készítenie. Abban az esetben, ha 2.0 szerint küldtek be egy számlát, akkor 2.0 szerint kellene stornózni, ha pedig 3.0 szerint küldtek be, akkor 3.0 szerint kellene stornózni. Ez aránytalanul nagy erőfeszítést kívánna és hibázásra adna lehetőséget mindenki részéről. Mert vagy a fejlesztőknek kellene egy valamilyen algoritmus alapján elvégezni a szükséges párosítást (pl. "alanyi adómentes" --> "AAM"), vagy a végfelhasználónak a számlázáskor adott esetben.

Arról nem beszélve, hogy egy stornózási művelet általában 1 gomb megnyomásával kivitelezhető, aminél max. annyit kellett megadni, hogy miért történt a stornózás. Ha ezek után a program tételenként megjeleníti a képernyőn a következő kérdést: "Kérjük, válassza ki, hogy az "alanyi adó mentes" _(a példában szándékosan 3 szót használtam, mert így, hibásan rögzítette manuálisan 2 évvel korábban az ügyintéző)_ minek feleltethető meg a következők közül: "AAM, TAM, stb.?" - ez esetben egészen biztosan hívogatni fogja a fejlesztő céget, hogy "Ez most mégis micsoda"? Borítékolható, hogy ez problémákat fog okozni.

A NAV részéről ugyanakkor egyszerűen megvalósítható, és mivel a korábbi, 2.0-val beküldött számla már a rendszerben van, ezért ezen számlák stornózása is rögzíthető kellene, hogy legyen a rendszerben. Ugyanakkor, ha idővel megszűnik a 2.0 szerinti beküldési lehetőség, akkor lehetetlenné válik a korábbi számlák stornózása.

Mivel még nem volt lehetőségünk tesztelni a 3.0-t, ezért a dokumentáció alapján jutottunk a fenti következtetésre, és ha ez valóban így van, akkor a fenti megoldást javasolnánk. Ha esetleg nyitott kapukat döngetünk, és a NAV rendszere a 2.0-val készített számlák stornózásánál, ha 3.0-val küldjük be, pontosan a fentiek szerint jár el, és befogadja, az egy szuper jó hír lenne. :-) Előre is köszönjük.

enhancement

Source

Rossi73

👍2 👀1

Most helpful comment

Egyeztettünk ebben a kérdésben, és a következő javaslathoz kérném a véleményeteket.

A vatExemption, vatOutOfScope és a vatAmountMismatch csomópontok case elemeire bevezetünk egy 'UNKNOWN' értéket. Ezt az értéket kizárólag a STORNO és MODIFY operációk esetén engedélyezzük, melyre üzleti blokkoló validációt vezetünk be. A validációban ellenőrizhetjük azt is, hogy a hivatkozott számla 2.0 vagy 1.x-el került beküldésre.
A reason elemnél pedig azt a szöveget kell feltüntetni, amit a számla tartalmaz. Tehát ez lehet akár az "alanyi adó mentes", akár az "AAM", ami magyarázza az egyes mentességet, hatályon kívüliséget stb.

A fenti megoldással egyet értetek, vagy van olyan eset, amire ez nem jelent megoldást?

NTCA-tax on 21 Oct 2020

👍3

All 18 comments

Amennyiben egy számlán van valamilyen adómentes tétel, akkor az adómentesség okát a számlán szerepeltetni kell. Ez lehet akár a felhasználó által beírt szöveg, de a számlázó program is adhat valamilyen előre elkészített szöveget, vagy rövidítést. Ennek a szövegnek kell mennie a reason elembe. Ehhez kapcsolódik egy kód, amely a case elem. A kérdésed ha jól értelmezem, akkor kizárólag a case elemmel kapcsolatos. Jelenleg egy adómentes tételsorban mi jelenik meg a számlán, illetve mi kerül tárolásra a számlázó programban az adókulcs mezőben?

NTCA-tax on 21 Oct 2020

@NTCA-tax
""ha idővel megszűnik a 2.0 szerinti beküldési lehetőség, akkor lehetetlenné válik a korábbi számlák stornózása.""
Rossi73 kérdése erre irányult.
Pontosan olvasd el Rossi 73 bejegyzését.

KMGY100 on 21 Oct 2020

@KMGY100 pontosan elolvastam a bejegyzést, de én a megoldást keresem. Az nem megoldás, hogy valamit nem lehet megcsinálni és feltesszük a kezünket. Ha pontosabban látom a probléma forrását én is, akkor tudunk közösen kidolgozni egy jó megoldást.

NTCA-tax on 21 Oct 2020

@NTCA-tax A gond az, hogy ha kiállított egy számlát, ami v2 szerinti volt, akkor v3 szerint a stornóját nem fogja tudni beküldeni bizonyos esetekben, mivel megváltoztattátok a VatRateType-ot.

nbeeps2 on 21 Oct 2020

Amennyiben egy számlán van valamilyen adómentes tétel, akkor az adómentesség okát a számlán szerepeltetni kell. Ez lehet akár a felhasználó által beírt szöveg, de a számlázó program is adhat valamilyen előre elkészített szöveget, vagy rövidítést. Ennek a szövegnek kell mennie a reason elembe. Ehhez kapcsolódik egy kód, amely a case elem. A kérdésed ha jól értelmezem, akkor kizárólag a case elemmel kapcsolatos. Jelenleg egy adómentes tételsorban mi jelenik meg a számlán, illetve mi kerül tárolásra a számlázó programban az adókulcs mezőben?

Ahogy @nbeeps2 összefoglalta, az a gondom, hogy ha van 2 számla, ami NAV 2.0-val készül, és az egyiken ez az 1 számlatétel szerepel:

egységár: 2000 Ft
mennyiség: 1 db
nettó: 2000 Ft
áfa kulcs: AAM
bruttó: 2000 Ft

míg a másikon pedig ez az 1 számlatétel szerepel:

egységár: 2000 Ft
mennyiség: 1 db
nettó: 2000 Ft
áfa kulcs: alanyi adó mentes
bruttó: 2000 Ft

és mindkét számlát stornózni kell majd NAV 3.0-val, akkor az első esetben ez jó eséllyel megtörténik, míg a második esetben hibaüzenetet kaphat a felhasználó, mert az "alanyi adó mentes" karaktersorozat nem esik bele a VatRateType értékkészletébe.

Arra voltam kíváncsi, hogy a NAV 3.0 kezeli-e ezt, és a 2.0-val készített számlák esetén is megköveteli, hogy a 3.0-val beküldött stornószámlán "fordítsa át" a program/kezelő az eredetileg "alanyi adó mentes" karaktersorozatot "AAM"-re, vagy nem kell vele foglalkoznia. Ha a 3.0 ragaszkodik a VatRateType értékkészlethez, akkor hibát fog produkálni, de ha a stornó esetén befogadja a korábbi értéket (karaktersorozatot) annak ellenére, hogy az nem része az új értékkészletnek, akkor mindenki boldog lesz.

Rossi73 on 21 Oct 2020

Egyeztettünk ebben a kérdésben, és a következő javaslathoz kérném a véleményeteket.

A fenti megoldással egyet értetek, vagy van olyan eset, amire ez nem jelent megoldást?

NTCA-tax on 21 Oct 2020

👍3

ok, és akkor mi fog történni ha az adott számla nem volt beküldve?
köszi

white420 on 3 Nov 2020

Egyeztettünk ebben a kérdésben, és a következő javaslathoz kérném a véleményeteket.

A vatExemption, vatOutOfScope és a vatAmountMismatch csomópontok case elemeire bevezetünk egy 'UNKNOWN' értéket. Ezt az értéket kizárólag a STORNO és MODIFY operációk esetén engedélyezzük, melyre üzleti blokkoló validációt vezetünk be. A validációban ellenőrizhetjük azt is, hogy a hivatkozott számla 2.0 vagy 1.x-el került beküldésre.
A reason elemnél pedig azt a szöveget kell feltüntetni, amit a számla tartalmaz. Tehát ez lehet akár az "alanyi adó mentes", akár az "AAM", ami magyarázza az egyes mentességet, hatályon kívüliséget stb.

A fenti megoldással egyet értetek, vagy van olyan eset, amire ez nem jelent megoldást?

Csak hogy biztosan jól értsük:

Stornózáskor megvizsgáljuk a számlán lévő áfa kulcsot:

Ha az áfa kulcs beleesik a NAV által elvárt értékkészletbe (1. számla a fenti példában), akkor a case mezőben meghagyjuk a kulcsot ("AAM"), míg a reason mezőben megadjuk az áfa kulcsnak a NAV által megadott szöveges leírását, pl.: "alanyi adómentes" (2 szó).
Ha az áfa kulcs nem esik bele a NAV által elvárt értékkészletbe (2. számla a fenti példában), akkor a case mezőben az UNKNOWN értéket adjuk át, a reason mezőben pedig magát az eredeti áfa kulcsot "alanyi adó mentes" (3 szó).

Ha így gondoltad, ez elfogadható alternatív megoldásként.

Rossi73 on 3 Nov 2020

ok, és akkor mi fog történni ha az adott számla nem volt beküldve?
köszi

Lehet, hogy csak én nem értem, de ez hogy kapcsolódik ehhez az issue-hoz? Valószínűleg ugyanaz történik, mint most, mivel a számla ellenőrzése - ha nincs bent az eredeti számla - már korábbi szinten elhasal, és nem fogja a tételeket ellenőrizni semmilyen rutin. Persze lehet, hogy rosszul gondolom...

Rossi73 on 3 Nov 2020

Én úgy értelmeztem, h csak akkor fogadják el az UNKNOWN értéket ha az előzőleg v1 vagy v2 vel beküldött számlát visszaellenőrzik (A validációban ellenőrizhetjük azt is, hogy a hivatkozott számla 2.0 vagy 1.x-el került beküldésre.), h valóban v1 vagy v2 vel lett beküldve ha v3-al már nem fogadják el de mi van akkor ha a stornózandó számla nem lett beküldve ellenőrizni sem tudják (viszont a "ellenőrizhetjük" szó van írva tehát nem feltétlenül ellenőrzik, viszont így nehéz eldönteni, h nem-e v3 al lett beküldve)

white420 on 4 Nov 2020

Én úgy értelmeztem, h csak akkor fogadják el az UNKNOWN értéket ha az előzőleg v1 vagy v2 vel beküldött számlát visszaellenőrzik (A validációban ellenőrizhetjük azt is, hogy a hivatkozott számla 2.0 vagy 1.x-el került beküldésre.), h valóban v1 vagy v2 vel lett beküldve ha v3-al már nem fogadják el de mi van akkor ha a stornózandó számla nem lett beküldve ellenőrizni sem tudják (viszont a "ellenőrizhetjük" szó van írva tehát nem feltétlenül ellenőrzik, viszont így nehéz eldönteni, h nem-e v3 al lett beküldve)

Ez elvileg nem lehet gond, hiszen ha jól írjuk meg a programot, akkor a 3.0-val beküldött számlák esetén már kizárólag a megadott értékkészletbe tartozó áfa kulcsot fogjuk beküldeni (mert ha nem azzal küldöd be, az be sem fog menni), így annak stornózása esetén nem lehet gond. Ahol tehát bement más áfa kulcs, az az 1.x vagy 2.0 volt, ott meg mehet az UNKNOWN + leírás...

Amúgy Te mit várnál, mi történjen akkor, ha stornózni akarsz egy számlát, és az eredeti nem lett beküldve? Miben változna a 3.0 bevezetésétől e tekintetben bármi?

Rossi73 on 4 Nov 2020

"validációban ellenőrizhetjük azt is, hogy a hivatkozott számla 2.0 vagy 1.x-el került beküldésre"

Elvileg így jónak kellene lennie mert ha régi ÁFA kulcsokkal készült beküldetlen számlák sztornózása esetében a modifyWithoutMaster true lesz így a NAV azokat nem fogja ellenőrizni

white420 on 4 Nov 2020

Az "ellenőrizhetjük" kitétel csak azért szerepel, mert ezen az ellenőrzésen jelenleg még gondolkozunk, de attól a megoldás alapjait nem érinti. Az elvárás az, hogy ha 2.0-val, 1.x-el volt az eredeti számla beküldve, csak akkor lehessen alkalmazni az UNKNOWN értéket.

NTCA-tax on 5 Nov 2020

Sziasztok,

ez az új 'UNKNOWN' áfakód, a fent leírt esetben, már használható?
A múlt héten frissített dokumentációban nincs semmi nyoma ennek, de ha már használható, akkor érdemes lenne egy kis fejezet erejéig ezt az esetet (adómentes 2.0 tétel módosítása/stornója 3.0 verzió alatt) és az ehhez kapcsolódóan bevezetett WARNING/ERROR-okat röviden leírni.

Köszi

gzoltan2 on 20 Nov 2020

de hát nincs ilyen új 'UNKNOWN' _áfakód_
A számla megjelenési formájára vonatkozik.
Nem ?

KMGY100 on 20 Nov 2020

@KMGY100 :

Fentebb ezt írta NTCA-tax, október 21-én:

Egyeztettünk ebben a kérdésben, és a következő javaslathoz kérném a véleményeteket.

A vatExemption, vatOutOfScope és a vatAmountMismatch csomópontok case elemeire bevezetünk egy 'UNKNOWN' értéket. Ezt az értéket kizárólag a STORNO és MODIFY operációk esetén engedélyezzük, melyre üzleti blokkoló validációt vezetünk be. A validációban ellenőrizhetjük azt is, hogy a hivatkozott számla 2.0 vagy 1.x-el került beküldésre.

Az áfamentességet jelölő VatRateType típusokra, a case ágra a 'AAM', 'TAM', 'THK' stb. mellé bevezetnének egy 'UNKNOWN' kódot is, amit csak és kizárólag akkor használhatnánk, ha olyan 2.0-ás számlát kell módosítani/stornózni 3.0 alatt, amin volt ilyen, vatExemption vagy vatOutOfScope elem.

(Lehet hogy rosszul fogalmaztam, ez nem áfakód, hanem a "case" elemek elfogadott értékkészletének része)

gzoltan2 on 20 Nov 2020

mi már belefejlesztettük az 'UNKNOWN' megoldást de sajnos úgy látom NAV-os oldalon még nem oldották meg :(
még mindig

invoiceStatus: ABORTED
validationResultCode: ERROR
validationErrorCode: INVALID_LINE_VAT_OUT_OF_SCOPE_CODE
message: Érvénytelen ÁFA törvény határán kívüliséget jelölő kód!
tag: InvoiceData/invoiceMain/invoice/invoiceLines/line/lineAmountsNormal/lineVatRate/vatOutOfScope/case
value: UNKNOWN
validationResultCode: ERROR
validationErrorCode: INVALID_LINE_VAT_EXEMPTION_CODE
message: Érvénytelen adómentességi kód!
tag: InvoiceData/invoiceMain/invoice/invoiceLines/line/lineAmountsNormal/lineVatRate/vatExemption/case
value: UNKNOWN

kb. mikorra várható a probléma orvoslása?

white420 on 22 Nov 2020

Sziasztok!
Zárom az issuet. Az interfész dokumentáció már tartalmazza az UNKNOWN értéket, az alkalmazás a hét második felétől lesz elérhető teszt környezeten, ami már elfogadja.
Üdv