Online-invoice: OSZv3: Kell-e és ha igen, akkor hogyan kell adatot szolgáltatni az adószám nélküli nem magánszemélyes számlákról?

[HWKF]

Idézet a Changelog 3.0-ból:
_2021.01.01-től kötelező adatot szolgáltatni a közösségi export számlákról, illetve a nem ÁFA alanyok számára kiállított számlákról is. Ezeknek a fogadásához a customerInfo csomópont átalakul, ennek segítségével elkülöníthetők a belföldi, közösségi valamint harmadik országos számlák illetve a magánszemély vevőknek szóló számlák is. Szintén változás, hogy a 3.0-ban a magyar, közösségi és harmadik országos adószámok nem írhatók fel egymás mellé, kizárólag egyet lehet közülük megadni. (technikailag a korábbi sequence choice stuktúrává alakul) A magánszemélynek (ide nem értve az adószámos magánszemélyt, illetve az egyéni vállalkozót) kiállított számla adatszolgáltatása nem tartalmazhat név-és címadatokat, ezért a sémában ezen elemek opcionálissá váltak. A fenti szabálynak nem megfelelő adatszolgáltatásokat a rendszer blokkoló validációval elutasítja. (a nem magánszemélynek szóló adatszolgáltatásokon pedig továbbra is kötelező elem a név és a cím)_
_A vevő adatainak felírását már úgy kell kezdened, hogy a privatePersonIndicator tagban megadot hogy a számla vevője magánszemély-e. A tag helye sorrendben legelől van a customerInfo tagen belül. Javasoljuk, hogy ennek az információnak a bevitelére legyen UI beviteli funkció (amennyiben más üzleti logika alapján ez nem derül ki) és ezt a számlát készítő felhasználó adja meg, mert a vevő adószámának a hiánya nem feltétlen jelenti azt hogy a vevő egyben magánszemély is, nehéz az algoritmizáció. (pl egyéni vállalkozó vevők számlái)
Minden nem magánszemélyes számlánál a vevői adószámot új Xpath alatt, a customerInfo/customerVatData alatt lehet megadni, ezt kezeld le magadnál. Figyelj rá, hogy nem lesz feltétlenül minden nem magánszemélyes számlánál adószám (pl. gazdasági tevékenységet nem folytató társasház, egyesület stb.)
Építs kitöltési logikát a vevői adatok XML-ben történő szerepeltetésére:
ha a vevő nem magánszemély akkor
a magyar (plusz opcionálisan az ÁFA csoport) adószám (customerTaxNumber+groupMemberTaxNumber), a közösségi adószám (communityVatNumber) és a harmadik országos adószám (thirdStateTaxId) közül kizárólag egyet lehet megadni
ha a vevő magánszemély akkor
sem név (customerName), sem cím (customerAddress), sem pedig vevő adószámot (customerVatData) tartalmazó csomópont nem adható meg_

Az én olvasatomban akkor 5 kategória van:

• magánszemély (bel- és külföldi): privatePersonIndicator=True
• belföldi adóalany adószámmal: privatePersonIndicator=False, customerTaxNumber (+groupMemberTaxNumber)
• adószám nélküli jogi személy (adószám nélküli nem magánszemély): privatePersonIndicator=False. Ez önmagában elegendő?
• közösségi adózás alá eső adóalany: privatePersonIndicator=False, communityVatNumber
• harmadik országbeli adóalany: privatePersonIndicator=False, thirdStateTaxId

[KMGY100]

"""Kell-e és ha igen, akkor hogyan kell adatot szolgáltatni az adószám nélküli nem magánszemélyes számlákról?"""
Címadatok : küldendő
Adószámok: nincsenek

[KMGY100]

Fentiekkel kapcsolatban kérdésem a következő:
Ha a számla kiállítója a magánszemélynek címzett számlát úgy küldi be, hogy
a számla XML tartalmazza a címzett nevét és címét, akkor mi a helyzet ?
Retorzió, büntetés várható ?

Mert:
A 2.0-ban csak ADÓALANY és NEM ADÓALANY elkülönítés szerepelt.
A 3.0 - ban belépett a MAGÁNSZEMÉLY kategória .
Kezdetben (vagy hosszabb időn keresztül) szinte biztos hogy a számla kiállítója
akaratlanul (vagy tudatlanul) megcseréli a MAGÁNSZEMÉLY és a NEM ADÓALANY kategóriát,
még akkor is ha felhívjuk a figyelmet , hogy a NEM ADÓALANY definíció pontos meghatározása:
NEM ADÓALANY DE NEM IS MAGÁNSZEMÉLY

[NTCA-developer]

Sziasztok!

@HWKF

adószám nélküli jogi személy (adószám nélküli nem magánszemély): privatePersonIndicator=False. Ez önmagában elegendő?

Nem, nem elég. Ahogy @KMGY100 is mondja, privatePersonIndicator = false esetén kötelező a név és címadat.

@KMGY100

Ha a számla kiállítója a magánszemélynek címzett számlát úgy küldi be, hogy a számla XML tartalmazza a címzett nevét és címét, akkor mi a helyzet ?

ERROR-t fog kapni rá és nem fog bemenni az adatszolgáltatás. Szóval implicit igen, lesz retorzió, de az elmaradt adatszolgáltatás miatt. Olyan adatot amit nem kezelhetünk, azt nem engedjük be.

[KMGY100]

Pontosítom a kérdésemet:
Ha a számla kiállítója a magánszemélynek címzett számlát úgy küldi be, hogy a NEM ADÓALANY DE NEM IS MAGÁNSZEMÉLY opciót választotta (akaratlanul vagy tudatlanul) akkor számla XML tartalmazza a címzett (magánszemély) nevét és címét.
Ekkor mi a helyzet ?

Ez a helyzet előfordulhat és állítom hogy elő is fog fordulni, mert a 2.0-ban hozzászokott a számla kiállítója hogy a magánszemély a NEM ADÓALANY kategóriába tartozott.

Tehát:
Ha elő fog fordulni a vázolt helyzet retorzió, büntetés várható ?

[NTCA-developer]

Értem már. Elnézést hogy elsőre nem erre válaszoltam. Kérek segítséget @NTCA-tax -tól.

[veerede]

Biztosan hosszasan meg lett fontolva (GDPR) de azért megkérdezem: Miért nem küldhető fel a magán személy neve, címe is?
A számla kötelező eleme. A számlát a számla térben a számla kibocsátója, vevője illetve a NAV láthatja.
Mivel a magánszemély (nem adóalany) nem láthatja a saját számláit sem (nincs hozzáférése), így magánszemélynek szóló számlák esetén betekintésre csak a NAV-nak, illetve a számla kibocsátójának van lehetősége.

Üdv
Ede

[HWKF]

A kérdésem csak a privatePersonIndicator-ra és a CustomerVatDataType-ra hegyezte ki a dolgot, ezért sem írtam név és cím adatot sehova sem. De akkor pontosítom:
Akkor jól látom, hogy az alábbi 5 kategória lefedi a lehetőségeket?

• magánszemély (bel- és külföldi): privatePersonIndicator=True, nincs CustomerVatDataType, nincs név és nincs címadat
• adószám nélküli jogi személy (adószám nélküli nem magánszemély): privatePersonIndicator=False, nincs CustomerVatDataType, név, címadat
• belföldi adóalany adószámmal: privatePersonIndicator=False, customerTaxNumber (+groupMemberTaxNumber), név, címadat
• közösségi adózás alá eső adóalany: privatePersonIndicator=False, communityVatNumber, név, címadat
• harmadik országbeli adóalany: privatePersonIndicator=False, thirdStateTaxId, név, címadat

Adószám nélküli jogi személy esetén, akkor elegendő a név és címadat mellett a privatePersonIndicator=False megadása és a CustomerVatDataType csomópont elhagyása?

[HWKF]

@KMGY100 A v2-ben nem "ADÓALANY" és "NEM ADÓALANY" elkülönítés szerepelt, hanem "BELFÖLDI ADÓALANY" és "NEM BELFÖLDI ADÓALANY".
Ami a v3-ban szerintem így változott:

• MAGÁNSZEMÉLY (adószámmal nem rendelkező, azaz nem adóalany bel- és külföldi természetes személyek)
• BELFÖLDI ADÓALANY (belföldi adószámmal rendelkező adóalany jogi és természetes személyek)
• KÜLFÖLDI ADÓALANY (közösségi vagy harmadik országbéli adószámmal rendelkező adóalany jogi és természetes személyek)
• NEM ADÓALANY (adószámmal nem rendelkező bel- és külföldi jogi személyek)

Így azt a vevőt, akit eddig "nem belföldi adóalany" kategóriába soroltak, azt át kell soroltatni a "magánszemély", "külföldi adóalany" és a "nem adóalany jogi személy" kategóriákba.

[KMGY100]

@HWKF
Köszönöm reagálásod de:
""Így a felhasználó sem fogja összekeverni."" aha.... ahogy azt te gondolod.
@NTCA-tax -tól várom a kérdésemre a választ.

[HWKF]

@KMGY100 Közben javítottam a hozzászolásomat. Másrészt tényleg a NAVtól várjuk a válaszokat.

[NTCA-tax]

A kezdeti időszakban biztosan lesznek ebben még keveredések, hiszen 2020. július 1-jén azt is sokaknak meg kellett magyarázni, ki az adóalany. Ez is egy folyamat lesz, ahogy eljutnak a számlakiállítók a megfelelő gyakorlatig.

Alapvetően jó a meglátásotok a vevői csoportokkal kapcsolatban. Kizárólag áfa törvény oldaláról a következő csoportokat lehet létrehozni:

• Magánszemély (belföldi, közösségi és harmadik országos is): név és a cím kötelező a számlán, de az adatszolgáltatásban nem lehet benne. Amennyiben a privatPersonIndicator=true és az adatszolgáltatásban van név, cím, akkor megy az error.
• Belföldi adóalany: név, cím, belföldi adószám kötelező a számlán és az adatszolgáltatásban is.
• Közösségi adóalany: név, cím, közösségi adószám kötelező a számlán és az adatszolgáltatásban is.
• Harmadik országbeli adóalany: név, cím kötelező, a harmadik országbeli adószám nem kötelező, de ha szerepel a számlán, megvan a dedikált helye az adatszolgáltatásban is.
• Nem magánszemély és nem adóalany: név, cím kötelező a számlán és az adatszolgáltatásban, adószámuk nincsen.

Felhasználói oldalon az első és az utolsó közötti elkülönítésnél lehetnek problémák. Az utolsó kategória például a gazdasági tevékenységet nem végző egyesület, alapítvány, kizárólag közhatalmi tevékenységet végző szervezet stb. sorolható bele. A magánszemély kategória pedig a gazdasági tevékenységet nem végző (vagy az adott vásárlásnál nem ekként fellépő) természetes személyi kört jelenti.

Egyébként a magánszemély és egyéni vállalkozó közötti elkülönítés eddig is probléma volt, de jelenleg is az az alapvető elvárás, hogy legalább legyen valamilyen logikus elválasztás a két csoport között. A magánszemély és a nem adóalany nem magánszemély között is ez lehet az alapvető elvárás. Nem az egyedi hibáknál érzünk problémát, hanem a rendszerszerű hibáknál (például az adózó vagy annak rendszere nem is akar különbséget tenni a két kategória között).

Remélem a fentiek segítséget tudnak nyújtani a megfelelő eligazodásban. Ha valamire nem tértem ki, akkor jelezzétek.

[pvmon]

Azt nem értem, hogy ebben miért nem kell, sőt nem szabad beküldeni a magánszemély név cím adatát, amikor a PTGSZLAH ÁNYK nyomtatványon pedig kötelező, a nyugta helyett magánszemélyeknek kiállított számla esetében? Pedig mind a kettő a NAV-hoz kerül be.

[NTCA-tax]

A PTGSZLAH nyomtatvány nem kapcsolódik az Online Számla rendszerhez és erre a kérdésre nem is fogok tudni egzakt választ adni.

[NTCA-tax]

Csak beleakadtam az issue zárása gombba... Ha van valami kérdésetek a vevői adatkörről, azokat ezen az issue-n belül megbeszélhetjük.

[alaplap]

@NTCA-tax Már korábban egy másik topikban volt róla szó, hogy szoftveresen nehéz eldönteni, hogy milyen kategóriába esik az adott vevő a felsorolt 5 kategória közül, különös tekintettel az 1. és 5. opciók esetén. Sok szoftverben az eddigi gyakorlat (a mi programunkban is és vevőként ezt tapasztaltam máshol is) az volt, hogy ha nem adott meg a vevő adószámot, akkor kérdést tett fel a program/felhasználó, hogy a vevő adóalany-e?
Ha a jövőben is szeretnénk a szoftverben segítséget adni a felhasználónak ahhoz, hogy helyes kategóriába sorolja be a vevőjét, akkor jó lenne, ha egységes terminológiát használna mindenki a szoftverében, a NAV számlázó programjában, stb.

Ez a "nem magánszemély és nem adóalany" elég katyvaszos, mert az 1. pontban lévő magánszemély sem adóalany, mégis az 1. és az 5. pont eltérő adatot kér az adatszolgáltatásba.

@NTCA-tax Milyen terminológiákat fog használni az NAV-os Online Számlázó Rendszer a vevő megfelelő kategóriába való besorolásához?
@NTCA-developer Fog-e "próbálkozni" a NAV-os Online Számlázó Rendszer valamilyen "algoritmus" alapján eldönteni, hogy a vevő melyik kategóriába esik? Ha igen, akkor szívesen venném, ha megosztásra kerülne az algoritmus lényege.

[pvmon]

A PTGSZLAH nyomtatvány nem kapcsolódik az Online Számla rendszerhez és erre a kérdésre nem is fogok tudni egzakt választ adni.

Nem is választ vártam, csak felhívtam a figyelmet egy visszásságra amivel nekünk együtt kell élni és két irányba fejleszteni.
A NAV által kért adathalmaz, egyszer kötelező, máskor meg tilos megadni.

[HWKF]

Tényleg jó volna, ha NAV adna a "nem magánszemély és nem adóalany" opcióra egy egységes megfogalmazást.
Ha jól jött ki a sakkozás, akkor viszont csak azok a jogi személyek esnek ebbe a csoportba, akiknek nincs adószámuk. Ezért nálunk a "Adószám nélküli jogi személy" merült fel ötletként.

[HWKF]

_Harmadik országbeli adóalany: név, cím kötelező, a harmadik országbeli adószám nem kötelező, de ha szerepel a számlán, megvan a dedikált helye az adatszolgáltatásban is._
Ha a harmadik országbéli adószámot nem adják meg, akkor az adatszolgáltatásban létre kell hozni "thirdStateTaxId" elemet, de üresen kell hagyni?
Mert különben összekeverhető a "Nem magánszemély és nem adóalany" kategóriával.

[KMGY100]

@NTCA-tax
""_Harmadik országbeli adóalany:_ név, cím kötelező, a harmadik országbeli adószám _nem kötelező_, de ha szerepel a számlán, megvan a dedikált helye az adatszolgáltatásban is.""
Ez biztos ?
Hiszen:

1. customerTaxNumber
2. communityVatNumber
3. thirdStateTaxId

[Macskafarka]

@NTCA-tax meghatározásai _"vevői csoportokra"_ vonatkoznak, azonban a számlákról és a módosító okiratokról kell eldönteni azt, hogy belföldi, vagy közösségi, vagy 3. országbeli.
Ehhez az ÁFA törvényben elég bonyolult és különös szabályok vannak meghatározva, olyanok, amelyek sok minden körülményt figyelembe vesznek, többek között a teljesítés helyét, hogy csak a legegyszerűbbet említsem.
Azt akarom ezzel jelezni, hogy pusztán a "vevői csoport" alapján nem lehet mindig eldönteni a bizonylat belföldi, közösségi, vagy 3. országbeli mivoltát.
Ha egy belföldi adóalanynak terméket értékesítenek, és a teljesítés helye 3.ország, akkor az a számla 3. országbelinek számít.
Ha egy DE adóalany a vevő, de a termékértékesítés helye 3. ország, akkor az a számla 3. országbelinek számít.
Ha egy belföldi adóalanynak értékesítek, de CZ-ben van a teljesítés helye, akkor az közösségi értékesítésnek számít. stb.
Ezek csak egyszerűsített példák, a valóság ennél sokkal-sokkal bonyolultabb (ki a szállítmányozó, az kinek a megbízásából jár el, megmunkálásra került-e oda a termék stb.).
Közelebb vinne a valósághoz annak a vizsgálata, hogy milyen adószám alatt történik az értékesítés.
Akkor viszont ki fog derülni az a helytelen gyakorlat, hogy hibás az, ha egy belföldi számlán szerepeltetnek EU adószámot, akár az eladói, akár a vevői oldalon.

[NTCA-tax]

A "nem magánszemély és nem adóalany" kategória elnevezésére ha vannak jó ötleteitek, azt szívesen várjuk. Az adószám nélküli jogi személy egy fokkal biztosan jobb megközelítés, de azt nekem is végig kellene gondolni, hogy ténylegesen csak jogi személyek vannak ebben a kategóriában.

@KMGY100 -nek igaza van, hogy a három elem közül az egyiket kötelező megadni, viszont vegyétek figyelembe, hogy a felette lévő customerVatData opcionális.

@Macskafarka véleményét osztom, hogy kizárólag a vevői csoportok felosztását jelenti, ugyanakkor a vevői csoport meghatározza a teljesítés helyét is. Az a tény, hogy egy adatszolgáltatásnál egy vevő csak egy zászló alatt hajózhat rákényszeríti a számlakiállítókat a precízebb munkára. Így el lehet kerülni az olyan számlákat, ahol a vevőnek például a belföldi adószáma és a német áfa regisztrációja is fel van tüntetve, vagy a vevőnél több áfa regisztrációt látunk. Ez biztosan a kezdetekben sok adózói problémát fog szülni, ugyanakkor egy kicsit hosszabb távon a helyes és egyértelmű számlakiállítás irányába fog vezetni.

[Macskafarka]

A korábbi bejegyzésemben arra próbáltam utalni, hogy aki a vevőit törzsesítve kezeli, és több adószáma van a vevőnek és saját magának is, (pl. belföldi, közösségi1, közösségi2, stb) annak fel kell készülnie arra, hogy a számla készítéskor a megfelelőt kell bekínálnia, vagy a felhasználóval kiválasztatnia.
Én is érzem azt, amit @NTCA-tax írt, hogy a felhasználóknál sok problémát fog okozni az, hogy csak egyetlen adószám szerepelhet a számlán mind kiállítói, mind vevői oldalon. Ugyanakkor, ha mi (a számlázó programok készítői) kezdünk keménykedni az ügyfeleknél és az ő jogértelmezésüket figyelmen kívül hagyva (pl. ha tévesnek gondoljuk a több adószám szerepeltetését) a saját jogértelmezésünket követve csupán egyetlen adószámot szerepeltetünk, akkor nekünk kellene adótanácsokat osztogatni, ami meghaladja a lehetőségeinket, és a felelősségünket.
Nagyban segítené a tisztázódást az, ha törvényi előírás szabályozná azt, hogy milyen és hány adószám szerepelhet egy számlán a felek mellett. Enélkül nem fog menni.

[HWKF]

Lehet, hogy a customerVatData opcionális, de akkor az keveredést okoz.

• harmadik országbeli adóalany, van adószám: privatePersonIndicator=False, customerVatData , thirdStateTaxId, név, címadat
• harmadik országbeli adóalany, nincs adószám: privatePersonIndicator=False, nincs CustomerVatDataType, név, címadat
• adószám nélküli jogi személy: privatePersonIndicator=False, nincs CustomerVatDataType, név, címadat

Így nincs különbség az utolsó kettő között!!!

[HWKF]

@Macskafarka A kiállítói oldalon nincsenek lekorlátozva az adószámok. Csak a vevői oldal változott, hogy 1 lehet.

[Macskafarka]

@HWKF Pedig úgy lenne logikus, hogy a kibocsátó adószámai közül is csak a gazdasági esemény típusának megfelelő egyetlen adószám szerepeljen a számlán (és az adatszolgáltatásban is). Minek legyen rajta a belföldi számlán a kibocsátó EU adószáma, vagy a közösségi számlán minek legyen rajta a kibocsátó belföldi adószáma? Ezek csak zavart okozhatnak.

[HWKF]

@NTCA-supporter @NTCA-tax
Hogyan tudjuk egymástól megkülönböztetni az adatszolgáltatásban az "adószám nélküli harmadik országbéli adóalanyt" és a "nem magánszemély és nem adóalanyokat" (adószám nélküli jogi személy)?
Kell-e ilyen megkülönböztetés? A NAV elvárja-e a megkülönböztetést?
Ha igen, akkor hogyan milyen adatokat kell megadni?

[NTCA-tax]

@HWKF
A két vevői csoportot az adójogszabályok alapján nem lehet megkülönböztetni, hanem a számla adattartalma alapján. Mindkét csoportnál az elvárt jogszabályi minimum a név és cím feltüntetése a számlán és az adatszolgáltatásban, a harmadik országos adózónál az adószám opcionális, de attól még megadható. A teljesítési hely egyébként annál bonyolultabb, minthogy a vevő letelepedése alapján meg lehessen állapítani. Önmagában a vevőadat ehhez kevés, a vevői szerepkörök adatszolgáltatásban való megkülönböztetése ezért nem történt meg. Ugyanakkor számlázó program oldalán a felhasználó számára lehet praktikus megoldás, de ezt Nektek kell eldöntenetek.

@Macskafarka
Teljesen egyetértek azzal, hogy egy közösségi ügyletnél kiállítói oldalon a számlán kizárólag a közösségi adószámnak van helye. Ugyanakkor az adatszolgáltatás során a belföldi adószám az a közös azonosító, amelyre egy rendszert fel lehet építeni. De ennek nem kell idegennek lenni, hiszen nem kell külön bevallást beadni a belföldi adószám és a közösségi adószám alatt bonyolított ügyletekről sem.
A vevői oldalon az adószám szerepeltetését az Áfa törvény írja elő. A 169. § d) egyértelműen leírja az egyes eseteket, hogy mikor milyen adószámot kell feltüntetni a számlán. Így az általad kért jogszabályi rendelkezés adott. Itt nem a jogszabállyal van alapvetően a probléma, hanem a gyakorlattal, amely nem ehhez igazodott. Persze ettől mindenki fogja érteni a belföldi adószám - magyar közösségi adószám szerepeltetését egy számlán, csak éppen az utóbbi felesleges, hiszen nem beszélhetünk közösségi ügyletről. A nagyobb problémákat azok az esetek jelentik, amikor a vevőről annyira mindent akar közölni az értékesítő, hogy felsorol négy-öt közösségi adószámot. Itt azonban el kell dönteni, mely entitásnak történt az értékesítés. A közösségi adószám szerepe egyébként is felértékelődött az irányelvi változásokkal, így egyre komolyabbnak kell(ene) tekinteni, hogy mivel jár annak szerepeltetése, milyen adózói egyéb kötelezettségek fűződnek hozzá.
A fentiekkel újra hangsúlyozom, hogy az adózói problémák nem a 3.0 bevezetésével fognak egy varázsütésre megoldódni, hanem inkább a 3.0 fogja felhívni arra a felhasználók figyelmét, hogy a korábbinál sokkal átgondoltabbak legyenek a számla kiállításakor.

[nbeeps2]

@NTCA-tax
Nekem a határidők keveredése és a PTGSZLA kapcsán van kérdésem: 2021. január 1-től a magánszemélyeknek kiállított számlát is kéne küldeni a NAV-hoz, erről szól a 3.0, 2021. március 31-ig küldhető adat 2.0-val vagyis a 3.0 csak 2021. április 1-től kötelező. Mi a helyzet e kapcsán a PTGSZLA vonatkozásában? Vagyis, ha a számlákat 2021.01.01-2021.03.31 között 2.0-val küldöm és továbbra sem küldöm a magánszemély számlákat, akkor kell PTGSZLA-t töltenem? Vagy ez hogy lesz? Ezt már kéne lassan tudni, mert nem mindegy, hogy 2021-től ki kell-e kötni a programból a PTGSZLA funkciót vagy sem. Ha január 1. lenne az egyetlen határidő, akkor nem lenne kérdés, de így az átmeneti idővel nekem ez zavaros.

[alaplap]

A "nem magánszemély és nem adóalany" kategória elnevezésére ha vannak jó ötleteitek, azt szívesen várjuk. Az adószám nélküli jogi személy egy fokkal biztosan jobb megközelítés, de azt nekem is végig kellene gondolni, hogy ténylegesen csak jogi személyek vannak ebben a kategóriában.

@NTCA-tax
A 2007. évi CXXVII. törvény az általános forgalmi adóról (azaz ÁFA törvény :wink:) számos ponton "nem adóalany jogi személy" kifejezést használ, például a Számlakibocsátási kötelezettség című fejezet 159. § (2). bekezdés a) pontjában.

Ha ez elfogadott, akkor a már általad is összegzett kategóriák és megnevezései lehetnének az alábbiak:

• Magánszemély (belföldi, közösségi és harmadik országos is): név és a cím kötelező a számlán, de az adatszolgáltatásban nem lehet benne. Amennyiben a privatPersonIndicator=true és az adatszolgáltatásban van név, cím, akkor megy az error.
• Belföldi adóalany: név, cím, belföldi adószám kötelező a számlán és az adatszolgáltatásban is.
• Közösségi adóalany: név, cím, közösségi adószám kötelező a számlán és az adatszolgáltatásban is.
• Harmadik országbeli adóalany: név, cím kötelező, a harmadik országbeli adószám nem kötelező, de ha szerepel a számlán, megvan a dedikált helye az adatszolgáltatásban is.
• Nem adóalany jogi személy: név, cím kötelező a számlán és az adatszolgáltatásban, adószámuk nincsen.

Ha ez így jó, már csak az kellene, hogy legyen egy felsorolás (akár a teljesség igénye nélkül), hogy kik is tartoznak ebbe az ominózus utolsó kategóriába. Korábban ezt írtad:

Az utolsó kategória például a gazdasági tevékenységet nem végző egyesület, alapítvány, kizárólag közhatalmi tevékenységet végző szervezet stb. sorolható bele

[HWKF]

Az API 3.0 doksiban a 83. (93.) oldalon lévő táblázatból hiányzik ez a "Nem magánszemély nem adóalany" / "Adószám nélküli jogi személy" / "Nem adóalany jogi személy" lehetőség kifejtése.

[bcdel]

Ugyanitt (API doksi 3.0) 83. (93) oldalon, irva ez van:

1. pont: .../communityVatNumber vagy .../thirdStateTaxId töltése kötelező.

A changelog, de még ez a issue is nem elég jogalap, hogy lehagyjam a harmadikországbeli adózó adószámát, ha a doksi szerint kötelező. Tehát ezt IS javitani kellene a doksiban.

[NTCA-developer]

@bcdel

Kérlek, hogy erről csinálj egy új ticketet invalid taggel, ezt pedig zárjuk le. Hamarosan megy egy újabb javító kör a doksira, akkor pedig már jó lenne ha ez is benne lehetne.

Köszönjük szépen!

[HWKF]

Azt hiszem zárható lenne az issue.
Már talán csak erre a kérdésre várnánk a választ:
_A "nem magánszemély és nem adóalany" kategória elnevezésére ha vannak jó ötleteitek, azt szívesen várjuk. Az adószám nélküli jogi személy egy fokkal biztosan jobb megközelítés, de azt nekem is végig kellene gondolni, hogy ténylegesen csak jogi személyek vannak ebben a kategóriában._

• Adószám nélküli jogi személy?
• Nem adóalany jogi személy?
• Egyéb?

[Macskafarka]

@HWKF Tetszik a "Nem adóalany jogi személy".

[nbeeps2]

@NTCA-supporter @NTCA-tax az én igen fontos kérdésemre még nem érkezett válasz, megköszönném, ha addig nem lenne lezárva:

Nekem a határidők keveredése és a PTGSZLA kapcsán van kérdésem: 2021. január 1-től a magánszemélyeknek kiállított számlát is kéne küldeni a NAV-hoz, erről szól a 3.0, 2021. március 31-ig küldhető adat 2.0-val vagyis a 3.0 csak 2021. április 1-től kötelező. Mi a helyzet e kapcsán a PTGSZLA vonatkozásában? Vagyis, ha a számlákat 2021.01.01-2021.03.31 között 2.0-val küldöm és továbbra sem küldöm a magánszemély számlákat, akkor kell PTGSZLA-t töltenem? Vagy ez hogy lesz? Ezt már kéne lassan tudni, mert nem mindegy, hogy 2021-től ki kell-e kötni a programból a PTGSZLA funkciót vagy sem. Ha január 1. lenne az egyetlen határidő, akkor nem lenne kérdés, de így az átmeneti idővel nekem ez zavaros.

[alaplap]

@NTCA-tax

1. Ha lehet, továbbra is szeretné(n)k felsorolást vagy definíciót, hogy kik minősülnek belföldi nem adóalany jogi személynek. (A Changelog 3.0 csak ennyit ír erről a kategóriáról: "pl. gazdasági tevékenységet nem folytató társasház, egyesület stb.").

1. Továbbá az lenne a kérdésem, hogy van-e közösségen belüli illetve harmadik országbeli nem adóalany jogi személy (azaz nem adóalany magánszemély, de nincs adószáma)? _(frissítve: 2020.11.26 8:30)_

2. Az ado.hu-n az alábbi cikk szerint a közösségen belüli nem adóalany jogi személy is vásárolhat ÁFA mentesen, viszont ellentmondásba ütközik, mivel közösségen belüli adószámot kell feltüntetni a számlán, ha ÁFA mentesen akar közösségen belülről (Magyarországon kívülről) vásárolni valaki. Akkor a közösségen belüli nem adóalany jogi személynek is kell közösségen belüli adószámának lennie ÁFA mentes vásárláshoz? Cikk: https://ado.hu/ado/az-eu-afa-rendszerenek-atfogo-reformja-a-kozosseg-ertekesites-adomentessegenek-feltetelei-2020-tol-2-resz/

3. _Frissítve (2020.11.25 14:05):_ A specifikáció szerint: "A három adószám közül az adatszolgáltatásban csak egy adható meg. Ha a számlán esetlegesen több vevői adószám szerepel (pl. belföldi adószám, közösségi adószám), akkor az adatszolgáltatásnál azt az adószámot kell kiválasztani, amit Áfa törvény szerint a számlán egyébként fel kell tüntetni." A kérdésem az lenne, hogy van olyan eset, amikor két magyar adóalany közti ügyletnél a vevő közösségi adószámát kell feltüntetni a számlán?

Köszönöm a válaszokat előre is.

[HWKF]

@NTCA-tax
A customerVatStatus bevezetése a jelenlegi értékeivel mennyiben pontosítja a vevő típusának egyértelműsítését?

• A magánszemélyt eddig is egyértelműen jelezte a PrivatePersonIndicator
• A belföldi adóalanyt eddig is egyértelműen jelölte customerVatData/customerTaxNumber megadása.
• Az OTHER értékkel a többi problémás eset továbbra is ugyanolyan problémás marad, főleg hogy az adószámot nem kötelező kitölteni.

Ez által marad-e a fentebb definiált 5 vevő típus vagy bővült a lehetőség?
Szeretném ha pontosítanák a fentebb közölt listát, hogy mely esetekben mely adatok megadása kötelező: _Adószámok közül (customerVatData) a háromból egy megadható, de nem kötelező._
A changelogot tovább olvasva kicsit még bizonytalanabb lett az ismertető:
_A vevő adatainak felírását már úgy kell kezdened, hogy a customerVatStatus tagban megadod, hogy a számla vevője belföldi ÁFA alany/nem ÁFA alany természetes személy/ egyéb._ (itt már más jelentések jelennek meg, mint a fentebbi kiemelésnél 2.8.1)

Szerintem ha már bevezetésre került a customerVatStatus, akkor az OTHER érték helyett miért nem lehet itt egyértelműen megadni a lehetőségeket?
Új értékek bevezetésével a további mezők kitöltése is egyértelművé válhatna. Azaz OTHER helyett legyen értéke:

• a közösségi adóalanynak (_külföldi ÁFA alany_ 1): így a közösségi adószám megadása kötelező lehetne
• a harmadik országbéli adóalanynak (_külföldi ÁFA alany_ 2): így a harmadik országbéli adószám megadása kötelező lehetne
• a magyar adószám nélküli jogi személynek (gondolom ez a "_belföldi nem ÁFA alany, nem természetes személy_"): adószámuk nincsen, így az adószám megadása tilos lehetne
• és a _külföldi nem ÁFA alany, nem természetes személy_-nek (vagy az utóbbi kettő ugyanaz? ): adószámuk nincsen, így az adószám megadása tilos lehetne

Remélem minden lehetőséget felsoroltam.
Szerintem a NAV szemszögéből megfogalmazható minden lehetőség és az OTHER lehetőség elfelejthető.

[KMGY100]

Tiisztelt @HWKF elnézésedet kérem hogy kéretlenül írok.
A per pillanatnyi állapot szerint:
_DOMESTIC_: cím és magyar adószám kötelező
_PRIVATE_PERSON_: minden magánszemély, akár EU-s akár 3. állam beli
(címet tilos az XML-be adószám természetesen nincs)
_OTHER_:
belföldi, adószámmal nem rendelkező szervezet
( cím kötelező adószám természetesen nincs)
Külföldi, EU-s vagy 3. állambeli adószámmal nem rendelkező szervezet
(merthogy ez is lehetséges. cím kötelező adószám nincs)
külföldi EU-s vagy 3. állambeli cég (nevezzük adóalanynak)
(cím kötelező adószám ha ismert XML-be beírni
ha nem ismert üresen marad)

Bárhogy csoportosít a NAV a végeredmény ugyanez.
Szétbonthatnák 15-20 tételre is , de ezzel a három fő csoporttal is
kitölthető az XML, pont úgy mint az előző csoportosítással,
Egyébként az előző szerintem jobb volt.
Még egyszer elnézést és válaszoljon @NTCA-tax

[HWKF]

@KMGY100 Az előző szerintem is jobb volt (részben), ez a mostani sokkal bizonytalanabb, azaz lazább. Így a módosítás bevezetése nem javított a dolgokon. De javíthatna ha tovább pontosítanák.

Azt írják, hogy _Több jelzés érkezett githubon és egyéb fórumokon, hogy az eddigi privatePersonIndicator magánszemély jelölővel nem minden üzleti eset megkülönböztethető_ Hát az újjal szerintem nem valósult meg ,hogy minden üzleti eset megkülönböztethető legyen.

A régi definíció szerint EU-s vagy 3. országbéli esetben kötelező volt az adószám megadása. Akkor itt a kötelezőség egyértelműen csak lehetőséggé válik?

Másrészt ők javasolják, hogy _Javasoljuk, hogy ennek az információnak a bevitelére legyen UI beviteli funkció (amennyiben más üzleti logika alapján ez nem derül ki) és ezt a számlát készítő felhasználó adja meg_
Ezt valamire építeni kéne, amit a felhasználónak el lehet magyarázni, hogy miért is szükséges ezt neki megadnia. Szeretnénk egyértelmű listát megjeleníteni a számára.

Harmadrészt a 3.2.1 pontban a következő állítások sem egyértelműek:

• _ha a vevő nem ÁFA alany (belföldi vagy külföldi) természetes személy, akkor_
  sem név (customerName), sem cím (customerAddress), sem pedig vevő adószámot (customerVatData) tartalmazó csomópont nem adható meg
• _ha a vevő egyéb (belföldi nem ÁFA alany, nem természetes személy, külföldi Áfa alany és külföldi nem ÁFA alany, nem természetes személy), akkor_
  a magyar (plusz opcionálisan az ÁFA csoport) adószám (customerTaxNumber+groupMemberTaxNumber), a közösségi adószám (communityVatNumber) és a harmadik országos adószám (thirdStateTaxId) közül kizárólag egyet lehet megadni, de azt nem kötelező.

Azaz ugyanazon OTHER érték mellett egyszer kötelezően meg kell adni az adószámot, a másikban pedig csak lehet.

Valamint a magyar adószám megadása miért szerepel lehetőségként az OTHER érték megadása mellett? Nem mindegyik magyar adószámmal rendelkező cég/szervezet minősül belföldi adóalanynak?

[HWKF]

A cégek közötti adat átadások miatt is hasznos lenne, ha lenne egy egyértelmű lista.
A mi rendszerünkbe is érkezhetnek külső (esetleg külföldi) cégektől partneradatok, amelyre később számlázni kell. Ilyenkor ugyebár nem nálunk van UI beviteli funkció, azaz kérnünk kell tőlük, hogy már úgy küldjék az adatokat, hogy a vevő típusát egyértelműsítették. Utólag nem igazán dönthető el, hogy melyik micsoda, ezért ajánlja a NAV is, hogy a számlát készítő adja meg.

Jó lenne, ha nem nekünk kéne összeállítani, hogy kit hova kell sorolni és mikor mit kell megadni, hogy egyértelműen összeállítható legyen az OSZ xml tartalma.
Sokat segítene ezen, ha a NAV egyértelmű besorolást ajánlana ki, ahol pontosan meg van adva, hogy melyik típusnál melyik adat kötelező vagy nem kötelező.

Jelenleg van a rendszerben olyan személy, aki kiállítja a számlát és itt ő még tud az adatokon változtatni. De később tervezzük a számlázást automatizálni és ilyenkor már tényleg pontosnak kéne lennie a kapott adatoknak.

És tegyük hozzá, hogy a lánc legelején lévő UI felületen végül nem olyan ember fogja az adatokat beállítani, aki számláz, hanem esetlegesen maga a vevő alanya fogja megadni a saját adatait, ahol neki kéne egyértelműen megadnia (illetve tőle kell egyértelműen bekérni), hogy ő melyik eset. És ha nem jól határozta meg saját magát, akkor utólag kellene bekérni, vagy meg kell tagadni az automata számlázás lehetőségét.

A jelenlegi other érték mellett úgy érzem túl sok lesz az üres adószám mező, mivel nem kötelező.

[HWKF]

Javasolt értékek a customerVatStatus beállításához (csak magyarul):

• MAGÁNSZEMÉLY: ez azt hiszem egyértelmű (_nem ÁFA alany (belföldi vagy külföldi) természetes személy_)
• ADÓALANY: (_belföldi/külföldi ÁFA alany_) a 3 adószám közül egy kitöltése kötelező, így egyértelmű, hogy melyik adóalanyról beszélünk (belföldi, közösségi vagy 3. országbéli). Ha a 3 lehetőség esetén valamelyiknél a kötelezőség nem teljesül, akkor az adott alany legyen külön érték a customerVatStatus-ban (pl. Harmadik országbéli adóalany).
• _belföldi nem ÁFA alany, nem természetes személy_: adószám nem adható meg
• _külföldi nem ÁFA alany, nem természetes személy_: adószám nem adható meg. (hogy pontosítani lehessen, hogy miért nem szerepel az adószám a külföldi partner esetén: azaz hogy nem ismert vagy nincsen)
• "egyéb" pontosítandó nevesített esetek (ha vannak), ami elkülöníthető a többitől: Ha vannak ilyenek, jó volna ha egyértelműek lennének, hogy ezen értékek esetén mit kell megadni, elkerülve az _OTHER_ értéket és a _lehet_ szócskát. Mert ezek az automatizálás ellenségei.

Szándékosan lazult fel a korábbi szabály, amelynek alapján a korábbi 5 lehetőséget belőttük?
Milyen elvárásai vannak a NAV-nak az OTHER érték megadása esetén?

Szeretnék pontosítást kérni, hogy a _belföldi/külföldi nem ÁFA alany, nem természetes személy_ az többet vagy mást jelent-e a következőknél:

• Adószám nélküli jogi személy
• Nem magánszemély és nem adóalany

Fontos-e, hogy most szerepel az ÁFA szó a megfogalmazásban, mikor korábban nem szerepelt?

[KMGY100]

@HWKF továbbra is elnézésedet kérem
most van három csoport (én is magyarul írom)
-BELFÖLDI (magyar) ADÓALANY
-MAGÁNSZEMÉLY
-EGYÉB

Értem, hogy nálad a vevőnek kell önmagát besorolni valamelyik kategóriába
Ezért én az EGYÉB kategóriát a saját programomban tovább bontanám és a
partnerem elé már csak a bővített bontást teszem (például):

• EU tag ADÓALANY
  (a közösségi adószámát kérheted kötelezően vagy nem kötelezően
  és itt lép be a LEHET kifejezés))
• 
  
  1. állambeli ADÓALANY
     
     (a 3. állami adószámát kérheted kötelezően vagy nem kötelezően)
  
  
• BELFÖLDI (magyar), NEM ADÓALANY és NEM MAGÁNSZEMÉLY
• KÜLFÖLDI ,NEM ADÓALANY és NEM MAGÁNSZEMÉLY

És ezt illesztem az XML-hez az adószám tagok kitöltésével vagy
üresen hagyásával , ahogy a partner önmagát jelölte.

Szerintem bárhogy, ízlés szerint bontható az EGYÉB kategória
csak illeszteni kell az XML adott mezőihez.

Még egyszer elnézést.
Tudom, választ @NTCA-tax -tól vársz

[NTCA-tax]

Az issue vége felé feltett kérdéseket ebben az issue-ban tárgyaljuk mélyebben: https://github.com/nav-gov-hu/Online-Invoice/issues/582 Amennyiben a vevői státusszal kapcsolatban lenne kérdésetek, akkor ott folytassuk a beszélgetést.