Online-invoice: 3.0 XSD / számla XML adataival kapcsolatos kérdés

[KMGY100]

a vatExemption vatOutOfScope vatAmountMismatch helyeken
a case egyértelmű, a nagybetűs kódot kell rögzíteni , de
a reason helyen mit ?

a specifikációban jelölt leírást vagy a user írja be szabadon ?
ha a specifikációban jelölt leírás megfelelő akkor a max 100 karakter kevés.

Másik kérdésem:
A TAM : "tárgyi adómentes" ill. a tevékenység közérdekű vagy speciális jellegére tekintettel adómenteség
kizárólag a _belföldi_ értékesítésre vonatkozik ?

Merthogy a FAD vatDomesticReverseCharge fordított adózás -nál
megkapta a _belföldi_ jelzőt

[NTCA-tax]

Az Áfa törvény alapján a számlán vagy jogszabályhivatkozással, vagy szövegesen jelölni kell, hogy miért mentes az adott termék/szolgáltatás értékesítése. A reason itt a számlán szereplő szöveget jelenti. Számlázó programtól függ, hogy ezt a felhasználónak saját magának kell begépelnie, vagy pedig a szoftver valamilyen előre definiált szöveget helyez el. Adatszolgáltatás oldaláról ez nem releváns, a számlán szereplő szövegnek kell itt szerepelnie.

A tárgyi adómentesség az Áfa törvény 85-86. §-aiban szereplő szolgáltatásokra vonatkozik. A fordított adózásnál azért került kiemelésre a "belföldi" jelző, mivel szoktunk közösségi fordított adózásról is beszélni. Ezért az egyértelműség kedvéért szerepel az elem elnevezésében is, hogy itt a belföldi fordított adózású tételeket kell feltüntetni.

[KMGY100]

Köszönöm a választ.
További kérdésem:
NO_VAT CHARGE: nincs felszámított áfa a 17.$ alapján
_ez rendben, itt nincs áfa_

REFUNDABLE_VAT: az áfa felszámítása a 11. vagy 14.$ alapján történt és az áfát a számla
címzettjének meg kell térítenie
_itt van áfa ? ( ha igen nem lehet vat_Percentage )_

NONREFUNDABLE_VAT: az áfa felszámítása a 11. vagy 14. $ alapján történt és az áfát a számla
címzettjének nem kell megtérítenie
_itt mi a helyzet ? van áfa felszámítás , áfa kulcs és bruttó érték ?_ (ha igen nem lehet vat_Percentage)

[KMGY100]

@NTCA-tax !
Mi a véleményed az előző kérdésről ?

[KMGY100]

@NTCA-supporter válaszát is várom a fenti kérdésemre.
Előre is köszönöm.

[KMGY100]

vatAmountMismatch 3 lehetséges adata:

NO_VAT CHARGE: nincs felszámított áfa a 17.$ alapján
ez rendben, itt nincs áfa

REFUNDABLE_VAT: az _áfa felszámítása_ a 11. vagy 14.$ alapján történt és az áfát a számla
címzettjének meg kell térítenie
itt van áfa ? ( _ha igen nem lehet vat_Percentag_e )

NONREFUNDABLE_VAT: az _áfa felszámítása_ a 11. vagy 14. $ alapján történt és az áfát a számla
címzettjének nem kell megtérítenie
és itt ? van áfa felszámítás , áfa kulcs és bruttó érték ? (_ha igen nem lehet vat_Percentag_e)

Van _felszámított áfa_ vagy nincs ?

[NTCA-tax]

Elnézést, hogy erre még nem válaszoltam. Egy nagyon jó kérdést tettél fel, mellyel kapcsolatban felmerült egy olyan alkérdés, melyről több kollégával kell konzultálnom. A teljes válaszomig a türelmedet kérném.

[KMGY100]

Köszönöm várom a választ türelmesen.

[laladisc]

A témával kapcsolatban lenne egy felvetésem. Ugye az köztudott, hogy 2020.07.01.-től a NAV áfa bevallás tervezetet fog készíteni. Ebben az esetben elengedhetetlen, hogy a megfelelő áfa kódokkal történjen a számlák kiállítása. A dokumentációt esetleg még ki lehetne egészíteni az egyes áfa kódokhoz tartozó magyarázattal, példákkal, ahol nincs törvényi hivatkozással, annak érdekében, hogy a fejlesztőknek könnyebb legyen megfeleltetni a saját áfa kódjaikat a NAV által megadott értékkészlettel.

[KMGY100]

vatAmountMismatch 3 lehetséges adata:

NO_VAT CHARGE: nincs felszámított áfa a 17.$ alapján
ez rendben, itt nincs áfa

REFUNDABLE_VAT: az áfa felszámítása a 11. vagy 14.$ alapján történt és az áfát a számla
címzettjének meg kell térítenie
itt van áfa ? ( ha igen nem lehet vat_Percentage )

NONREFUNDABLE_VAT: az áfa felszámítása a 11. vagy 14. $ alapján történt és az áfát a számla
címzettjének nem kell megtérítenie
és itt ? van áfa felszámítás , áfa kulcs és bruttó érték ? (ha igen nem lehet vat_Percentage)

Van felszámított áfa vagy nincs ?

[Rossi73]

vatAmountMismatch 3 lehetséges adata:

NO_VAT CHARGE: nincs felszámított áfa a 17.$ alapján
ez rendben, itt nincs áfa

REFUNDABLE_VAT: az áfa felszámítása a 11. vagy 14.$ alapján történt és az áfát a számla
címzettjének meg kell térítenie
itt van áfa ? ( ha igen nem lehet vat_Percentage )

NONREFUNDABLE_VAT: az áfa felszámítása a 11. vagy 14. $ alapján történt és az áfát a számla
címzettjének nem kell megtérítenie
és itt ? van áfa felszámítás , áfa kulcs és bruttó érték ? (ha igen nem lehet vat_Percentage)

Van felszámított áfa vagy nincs ?

Azt mi alapján, és ki tudja eldönteni, és hol, mihez kapcsolódva lehet/kell(ene) tárolni a rendszerben, hogy a fenti 3 esetből melyik lesz a valós?

• Mancika minden számla/számlatétel rögzítésekor kérdezze meg a vevőt?
• Lehet ez számlatételenként eltérő adat (pl. egyik: NO_VAT CHARGE, másik: REFUNDABLE_VAT, harmadik: NONREFUNDABLE_VAT)?
• A vevőhöz a maga teljességében rögzíthető a vevőtörzsben?
• Ha rögzítettük a vevőtörzsben, akkor attól el lehet térni a számla kiállításakor?

Tehát, ki, mikor, és milyen feltételek alapján tudja meghozni azt a döntést, hogy a programnak a REFUNDABLE_VAT vagy a NONREFUNDABLE_VAT értéket kell használnia, ha az 5%, 18%, 27%, K7% vagy K12% kulccsal állítunk ki egy számlatételt? Nyilván az lenne a célravezető, ha ennek a kezelése automatikusan történhetne, de akkor pontosan ismerni kell a feltételeket. (A NO_VAT CHARGE egyértelműen választható, ha nem a fenti körbe tartozó kulcsról van szó.)

[Rossi73]

Az Áfa törvény alapján a számlán vagy jogszabályhivatkozással, vagy szövegesen jelölni kell, hogy miért mentes az adott termék/szolgáltatás értékesítése. A reason itt a számlán szereplő szöveget jelenti. Számlázó programtól függ, hogy ezt a felhasználónak saját magának kell begépelnie, vagy pedig a szoftver valamilyen előre definiált szöveget helyez el. Adatszolgáltatás oldaláról ez nem releváns, a számlán szereplő szövegnek kell itt szerepelnie.

A "valamilyen előre definiált szöveg" lehet a NAV dokumentáció alapján megjeleníthető szöveg, amit be is küld a program?

Tehát pl.:
vatExemption/case = "AAM"
vatExemption/reason = "Alanyi adómentes"

vagy:
vatExemption/case = "EUFADE"
vatExemption/reason = "Másik tagállamban teljesített, nem az Áfa tv. 37. §-a alá tartozó, fordítottan adózó ügylet"

Továbbá: a számlán jelenleg is kötelező ennek a mentességnek a feltüntetése? Én épp ma kaptam egy olyan számlát egy telekom-cégtől, ahol egy tételnél ÁHK az ÁFA kulcs, de sehol sincs jelölve, hogy mi az az ÁHK...

[KMGY100]

"""Én épp ma kaptam egy olyan számlát egy telekom-cégtől, ahol egy tételnél ÁHK az ÁFA kulcs, de sehol sincs jelölve, hogy mi az az ÁHK..."""
Vigyázz, ezt a telekom számlát 2.0 - val kaptad,
a kérdésünk a 3.0 - ra vonatkozik.

Várjuk, várjuk és várjuk és még mindig várjuk immár 2 hete
a NAV válaszát.

[jozanesz]

Az áfa törvény szerint a kötelező ez:

m) adómentesség esetében jogszabályi vagy a Héa-irányelv vonatkozó rendelkezéseire történő hivatkozás vagy bármely más, de egyértelmű utalás arra, hogy a termék értékesítése, szolgáltatás nyújtása mentes az adó alól;

Úgy rémlik, hogy a héairányelvben is ilyen pongyola. Meg is van:

adómentesség esetén az ezen irányelv alkalmazandó rendelkezésére vagy a megfelelő nemzeti rendelkezésre történő hivatkozás, illetve bármilyen más utalás arra, hogy a termékértékesítés vagy szolgáltatásnyújtás adómentes;

Ha odaírom, hogy „mentes az adó alól”, rövidebben „adómentes”, akkor megfeleltem ennek (a kb. három betűs jelölések egyértelműsége sokkal vitathatóbb), és hacsak nem találtok rá más paragrafust, akkor a NAV ezzel is olyan adatot kér, amely a törvény alapján nem kötelező. Szerintem elegánsabb, ha előbb a törvény változik, és csak utána az adatszolgáltatás kötelező elemei.

[nbeeps2]

@KMGY100 @Rossi73 ahogy @jozanesz is írja ez már "1000 éve" így van, szóval valahogy eddig is jelölni kellett, hogy miért mentes és ezt a szöveget kell feladni az adatszolgáltatásban. Ezzel nincs is gond, azzal már sokkal inkább, hogy ezt az értékkészletet hogy lehet összhangba hozni a számlázó programmal, hogy abból ne legyen lázadás a felhasználók részéről. Ez durván túl lett bonyolítva...

[NTCA-tax]

Visszamennék az eredeti kérdésre. Köszönjük a jelzéseteket, ennek alapján láttam problémát a vatAmountMismatch kapcsán. Ezt a sémában javítottuk, a dokumentációban pedig részletes magyarázatot próbáltunk adni. Ezzel sajnos a séma egy kicsit bonyolultabbá vált, ugyanakkor talán egyértelműbb, hogyan kell ezekben az esetekben az adatszolgáltatást teljesíteni.

A mentesség okával kapcsolatos beszélgetéshez adóhivatali nézőpontot tudnék hozzátenni, hátha ez segítséget ad a megértésben. A case-reason párokat éppen az általatok is leírtak miatt alkottuk meg a sémában. Nagyon sokszor látjuk, hogy az adómentességi hivatkozás nagyon gyengére sikerül a számlán, amely alapján maximum csak találgatni lehet, miért is lehet mentes az adott ügylet. A számlázó programban használt adómentességi ok kódja és az Online Számla case párosítása néhány esetben lehet, hogy nehézségekkel jár, ugyanakkor egyértelműsíti azt a mi oldalunkon, miért volt mentes az adott ügylet. Így annak ellenére, hogy nincs olyan előírás, milyen adókódok szerepelhetnek egy számlázó programban egységesített kódlistának való megfeleltetést követően akár gépileg is értelmezhetővé válik.

[kurucza]

@NTCA-tax
Felmerült egy kérdés az egyik ügyfelünknél és kérném a segítségeteket annak megválaszolásában.
Ha a számlán szereplő szöveggel kell megegyezni a reason szövegezésének, akkor a nyelv mennyire számít? Ha angol a nyomtatványom, akkor a reason is angol kell, hogy legyen vagy lehet a kiküldött xmlben magyar reason szöveg is megadva?
Betűre pontosan meg kell, hogy egyezzen a nyomtatvány szövegén szereplő reasonnek az xmlbeli szöveggel? (200 karakter miatt nem biztos, hogy sikerül) vagy csak értelmileg kell azonosnak lennie.

Köszönöm, Andi

[NTCA-tax]

A reason a számlán megjelenő szöveg, a case pedig annak az adatszolgáltatási kódmegfelelője. Így ha a számlán angolul, németül vagy szuahéliül van a mentesség szövege megjelölve, akkor azt a szöveget kell behúzni az adatszolgáltatásba. A case a számítógépnek szól, a reason pedig az embernek. Amennyiben több mint 200 karakter, akkor 200 karakternél levágod a szöveget. Nagyon extrém esetben fordul elő, hogy az első 200 karakterből nem derül ki a mentesség oka.

[nbeeps2]

"Nagyon extrém esetben fordul elő, hogy az első 200 karakterből nem derül ki a mentesség oka."
Hát a case-ből már kiderül, így a reason-nek nincs is nagyon értelme...

[NTCA-tax]

@nbeeps2 akkor a programod jól működik :) Egyébként olyan esetekben hasznos a reason, amely mélységet a case-el nem tudunk vagy nem hatékony lefedni. Másrészt ha a program rosszul határozza meg a case-t, és egy elemzésünk félrefut, akkor is jól jön, ha látjuk a reason mezőt és nem egyből ugrunk az adózóra.

[kurucza]

A reason a számlán megjelenő szöveg, a case pedig annak az adatszolgáltatási kódmegfelelője. Így ha a számlán angolul, németül vagy szuahéliül van a mentesség szövege megjelölve, akkor azt a szöveget kell behúzni az adatszolgáltatásba. A case a számítógépnek szól, a reason pedig az embernek. Amennyiben több mint 200 karakter, akkor 200 karakternél levágod a szöveget. Nagyon extrém esetben fordul elő, hogy az első 200 karakterből nem derül ki a mentesség oka.

Köszönöm a választ @NTCA-tax . Akkor a számlán lévő szöveges hivatkozást is meg kell vizsgálni néhány esetben, hogy tényleg az van-e ott, aminek kell :-) Ugye eddig az export számlák ennyire nem voltak terítéken.....

[NTCA-tax]

Mivel március 31-ig van export számlákra (is) moratórium, így adatminőségi problémák még bőven beleférnek addig.

[kurucza]

@NTCA-tax , ismételten kérdésbe ütközem a magyarázat kapcsán.
Azt mondtuk a fentiekben, hogy a számlán szereplő szöveget kell a reasonben megadnunk. Abban az esetben ha szuahéliül, akkor azon a nyelven, ha angolul, akkor azon a nyelven.....200 karakterbe kell beleférni, tudom, hogy extrém eset ha nem fér bele.....DE:
Ha egy számla 2 nyelvű, így a számlán 2 nyelven szerepel az indok, akkor melyik nyelvet tegyem be az xmlbe? Nem tudom mind a kettőt, mert ez az extrém eset, amikor nem fér bele 200 karakterbe a 2 nyelv. Mikor fogok helyesen eljárni? Ilyenkor mindegy melyiket teszem xmlbe, csak legyen benne a helyes hivatkozás bármely nyelven?
Köszönöm,
Andi

[NTCA-tax]

Erre nincs pontos jogszabályi és adatszolgáltatási szabály. A két nyelv közül az egyiket kellene elhelyezni. Számunkra könnyebb lenne, ha ez nem a szuahéli, hanem a magyar lenne :)

Bármilyen megoldást is választasz, érdemes ezt a számlázó program adatszolgáltatási funkciójának leírásában rögzíteni.

[kurucza]

Erre nincs pontos jogszabályi és adatszolgáltatási szabály. A két nyelv közül az egyiket kellene elhelyezni. Számunkra könnyebb lenne, ha ez nem a szuahéli, hanem a magyar lenne :)

Bármilyen megoldást is választasz, érdemes ezt a számlázó program adatszolgáltatási funkciójának leírásában rögzíteni.

Köszönöm:-)

[NTCA-tax]

Zárható ez az issue vagy még maradt nyitott kérdés?