Online-invoice: [Q&A] V3.0 summaryByVatRate kód és leírás kezelése több tétel esetén
A kérdés, amire választ szeretnék kapni / The question I would like to be answered
Rövid és tömör leírása a kérdésnek. / A clear and concise description of the question.
Egy számlán több, adó hatályán kívüli tétel szerepel. A felhasználó minden tételhez a megadott értékkészletből választható kódot és tételenként _eltérő_ leírást rögzít.
A számlán az összesítésnél ezek a tételek logikusan egy közös (esetünkben az "ÁHK") gyűjtőbe kerülnek (az adómentesek pedig az "AM"-be).
Viszont a 3.0-ás summaryByVatRate elvárja a kód mellett a leírás megadását is.
Ezek alapján a számla ÁFA összesítőjében és az adatszolgáltatásban is kódonként és leírásonként csoportosított gyűjtőben kell szerepeltetni a tételeket? Azaz, négy különböző leírás esetén, hiába "ATK" a kód, négy külön sorban kell feltüntetni?
DrotosTot
All 21 comments
Szia!
Ha több tételhez azonos case érték tartozik, ezekhez elegendő 1 darab összesítő.
Üdv
NTCA-supporter
on 21 Oct 2020
@NTCA-supporter: ok, de négy külön reason kerül megadásra a tételeknél, ezek közül melyik kerüljön az összesítőbe?
DrotosTot
on 21 Oct 2020
@NTCA-supporter: ok, de négy külön reason kerül megadásra a tételeknél, ezek közül melyik kerüljön az összesítőbe?
Lehetséges olyan, hogy négy tétel négy különböző ok miatt lesz adómentes ugyanazzal az adókulccsal? Pl.: "AAM"-hez négy különböző leírás tartozik... Máshol is kérdeztem már: nem megfelelő esetleg ilyen esetben az, hogy ami a NAV doksiban szerepel, azt adjuk meg a reason mezőben (pl. "AAM" mellé "alanyi adómentes")? Ez esetben ugyebár a usernek nem is kellene "törődnie" a magyarázattal, hiszen az fix... Lehet, hogy az "általánosság" elve miatt ez így nem jó, bár NTCA javaslatában az szerepel, hogy lehet fix listából is választani. Ha ez így van, akkor a fix listát én határozom meg, ehhez pedig venném a NAV által felkínált lehetőségeket, és mást nem engednék. De lehet, hogy nincs igazam...
Rossi73
on 21 Oct 2020
Osztom @Rossi73 által leírt működési logikát.
Macskafarka
on 21 Oct 2020
Sziasztok!
Ez így szerintem teljesen működőképes.
Arról már van nyitott issue, hogy a reason tag-be jelenleg nem fér el a doksiban szereplő leírás. Emiatt fogjuk majd bővíteni 200 hosszra a reason mezőt.
Ha van hozzáfűznivalód @NTCA-tax kérlek tedd meg, vagy zárd az issuet.
Üdv
NTCA-supporter
on 26 Oct 2020
Mi örülünk, egyel több user error-t lehet kiküszöbölni.
Nem szeretnék pofátlan lenni, de akkor lehetne kérni, hogy a doksiban is ez a megoldás szerepeljen?
DrotosTot
on 26 Oct 2020
Lehetőségként mindenképp beleírjuk.
NTCA-supporter
on 26 Oct 2020
Egy helyesbítő számlánál előfordulhat a következő szituáció:
1/2020 (sima számla):
- sor: 1 db 1000 Ft,
ÁFA kulcs felhasználó által használt neve: "EXP",
CASE: "EAM"
REASON: Termékexport harmadik országba
A felhasználó később rájön, hogy rossz szöveget rendelt az EXP (tök mind1, mi a neve az ÁFA kulcsnak...) ÁFA kulcshoz és mást állít be hozzá. Ezt követően kiállít egy helyesbítő számlát:
2/2020 (1/2020 helyesbítése), CREATE mindkét sort (mert én így használom)
- sor: -1 db x 1000 Ft
ÁFA kulcs felhasználó által használt neve: "EXP",
CASE: "EAM"
REASON: Termékexport harmadik országba
- sor: 1 db x 1500 Ft (tegyük fel az árat is elrontotta)
ÁFA kulcs felhasználó által használt neve: "EXP",
CASE: "HO"
REASON: Harmadik országban teljesített ügylet
Nos, ez esetben ez a számlán szemmel leolvashatóan így fog kinézni az összesítésben:
ÁFA: EXP Nettó: 500 Ft
A summaryByVatRate-nél pedig mivel mindkettőnek azonos az ÁFA kulcsa (EXP), ezért a helyesbített CASE és REASON fogszerepelni, tehát:
500 Ft
CASE: "HO"
REASON: Harmadik országban teljesített ügylet
Ez így megfelelő?
(u,.i.: a reason is bármikor meg tud változni, mert sokszor paragrafus hivatkozás van benne és ha mondjuk a 37§ , 38§-ra változik akkor is fennállhat, hogy a helyesbítő emiatt azonos ÁFA kulcs mellett eltérő REASON-eket tartalmaz. A fenti eset annyiban speciális, hogy ott azonos ÁFA kulcshoz nem csak a REASON , hanem a CASE is eltérő)
nbeeps2
on 4 Nov 2020
A fenti esetben INCORRECT_SUMMARY_DATA_VAT_EXEMPTION hibát kapok, nem örülök...
nbeeps2
on 4 Nov 2020
@nbeeps2 Gondolkodtál azon, hogy törzsesíted a Reason-t? Na adhassa meg szabadon az ügyfél bizonylatonként.
Macskafarka
on 4 Nov 2020
@Macskafarka : Törzsesítettem, viszont a módosítás engedélyezett. Tehát az EXP áfakulcshoz kiválasztotta az "EAM" CASE-t, kiállította a számlát. Később rájött, hogy elcseszte. Módosította a törzsben az EXP áfakulcshoz tartozó CASE-t "HO"-ra, majd elvégzi a helyesbítést. A helyesbítő számlán így az EXP áfakulcshoz fog tartozni "EAM" és "HO" CASE is és így sajnos, ahogy látom ezeket külön kell összesíteni. A számlán tehát hiába az EXP áfakulcshoz összesítek, a NAV-nak a CASE alapján kell összesítenem hiába volt azonos az ÁFA kulcs elnevezése.
nbeeps2
on 4 Nov 2020
@nbeeps2 : le kell tárolni a számla minden sorához, hogy milyen értékkel ment be a NAVhoz és akkor a helyesbítés esetén vissza lehet nyúlni ehhez az értékhez. Ha ügyesen csinálja az ember és itt is "törzsesít", akkor egy kapcsoló mezővel megoldható soronként.
omachtandras
on 4 Nov 2020
@omachtandras Igen, ezért írtam, hogy nem örülök, mert ez sokkal nagyobb módosítás, mint amivel eredetileg számoltam...
nbeeps2
on 4 Nov 2020
Igen, vagy másképpen úgy is meg lehet oldani, hogy az EXP áfakulcshoz fixen hozzárendeled a CASE értéket, és nem engeded változtatni.
Macskafarka
on 4 Nov 2020
@Macskafarka Ezen is gondolkodtam, de nem mertem meglépni, mert mivel a CASE meghatározása a felhasználó számára koránt sem lesz egyszerű, nem akarom, hogy utána nálam reklamáljon, hogy miért nem lehet ezt utólag állítani, ha már kiállított egy ilyen számlát, ami erre hivatkozott...
nbeeps2
on 4 Nov 2020
@nbeeps2 A lehetséges CASE értékek végesek. Nem kell állítani, hanem áfakulcsot cserél, ami maga után vonja a CASE cserét is.
Macskafarka
on 4 Nov 2020
így képzelem el:
a 2. sor: 1 db x 1500 Ft (tegyük fel az árat is elrontotta)
ÁFA kulcs felhasználó által használt neve: "EXP2",
CASE: "HO"
REASON: Harmadik országban teljesített ügylet
Macskafarka
on 4 Nov 2020
Ez mondjuk eddig is így volt, de például vigyázni kell azzal is, ha valamiért két különböző nevű, de azonos ÁFA kulcsú (nem 0%-os) ÁFA van a számlán.
Pl.
ÁFA kulcs neve: 27A, kulcs 27%
ÁFA kulcs neve: 27B, kulcs 27%
A számlán mivel ez 2 ÁFA kulcs, külön fog szerepelni az összesítőben, de a summaryByVatRate-nél meg össze kell őket vonni, ellenkező esetben INCORRECT_SUMMARY_CALCULATION_VAT_RATE_NET_AMOUNT_LINE WARN jön.
nbeeps2
on 4 Nov 2020
Százalékos kulcsoknál nem engedném meg, hogy két különböző legyen a kulcs neve. Ha a 27% már a 27A-hoz tartozik, akkor nem lehetne 27B-hez rendelni.
Macskafarka
on 4 Nov 2020
Summa summarum a lényeg, hogy míg a számlázó programok ÁFA kulcsban gondolkoznak (ahol ennek van egy konkrét string neve) és ÁFA kulcsonként összesítenek a számlán, addig a NAV adatszolgáltatás százalékban (0% esetén pedig azon belül CASE-be) gondolkozik és e szerint kell elvégezni a summaryByVatRate képzését.
nbeeps2
on 4 Nov 2020
Sziasztok!
Ez az issue zárható? Van még kérdés?
Üdv
NTCA-supporter
on 7 Dec 2020
Related issues
kaptast
·
5Comments
DrotosTot
·
5Comments
mnkpmg
·
3Comments
EnokhSys
·
6Comments
Amn3s1a2018
·
5Comments
Most helpful comment
Lehetséges olyan, hogy négy tétel négy különböző ok miatt lesz adómentes ugyanazzal az adókulccsal? Pl.: "AAM"-hez négy különböző leírás tartozik... Máshol is kérdeztem már: nem megfelelő esetleg ilyen esetben az, hogy ami a NAV doksiban szerepel, azt adjuk meg a reason mezőben (pl. "AAM" mellé "alanyi adómentes")? Ez esetben ugyebár a usernek nem is kellene "törődnie" a magyarázattal, hiszen az fix... Lehet, hogy az "általánosság" elve miatt ez így nem jó, bár NTCA javaslatában az szerepel, hogy lehet fix listából is választani. Ha ez így van, akkor a fix listát én határozom meg, ehhez pedig venném a NAV által felkínált lehetőségeket, és mást nem engednék. De lehet, hogy nincs igazam...