Online-invoice: [A vevő nem adóalany, magánszemély nem rendelkezik adószámmal.

[NyBela]

Tisztelt Fejlesztők!
A mai napon a specifikációban megjelent a 7. vevői customerVatStatus = OTHER
Szeretném megkérdezni, hogy ez kire vonatkozik?
Gondoltunk egyesületre, Dr. xy ügyvéd, társasház stb. de mindnek van adószáma.
Akkor kik azok, akik nem magánszemélyek, nem adóalanyok és nincs adószámuk.
Egy-két példát, ha kérhetnénk.
Ma próbáltunk érdeklődni a NAV-nál, de nem jutottunk előbbre, nem tudtak ilyen esetet mondani,
viszont nagyon sok emberrel tudtunk beszélgetni a rengeteg ide-oda kapcsolás következtében.
Kaptunk olyan választ, hogy akkor magánszemély, illetve inkább külföldi, de inkább
hívjuk az informatikát, de nem lehet kapcsolni...
December 7-én, amikor telepíteni kellene az új verziót és egy 20000-es partnertörzsben meg kellene tenni a beállításokat, hogy probléma nélkül indulhasson a rendszer, ez már egy kicsit rosszul esik.
De továbbra is a kérdés: melyek azok a vevők, akik ebbe a paraméterezésbe tartoznak?
De sajnos a teszt rendszerben a "customerVatStatus" miatt ERROR jön vissza.
Köszönöm.

[EnokhSys]

Na, erre én is kíváncsi vagyok. Van egy olyan sanda gyanúm, hogy az adószám 9-ik számjegyéhez köze van az OTHER értéknek.

[NyBela]

Először nekem az volt az ötletem, hogy az '1'-es, de hát nincs adószáma!
"7. eset: A vevő nem adóalany, ugyanakkor nem is magánszemély
customerVatStatus = OTHER
customerInfo/customerVatData egyik eleme sem adható meg, mivel a vevő nem rendelkezik adószámmal. "

[topybear]

Társasház tipikusan lehet, nem kötelező nekik az adószám:
http://www.tarsashazipolgar.hu/tarsashazi-kozos-kepviselo/

[nbeeps2]

A válasz nagyon egyszerű, 3 típus van:

1. DOMESTIC: Belföldi adóalany, tehát magyar adószámmal rendelkező cég
2. PRIVATE_PERSON: magánszemély, aki lehet belföldi és külföldi
3. OTHER: Mindenki más, aki nem tartozik a fenti két csoportba. Tehát: belföldi nem ÁFA alany (gazdasági tevékenységet nem folytató társasház), és minden külföldi cég, aki mindegy, hogy ÁFA alany vagy sem vagy EU-s vagy nem EU-s

[EnokhSys]

Szerintem ez így tiszta sor: ha belföldi és nincs adószáma, akkor csak "OTHER" jöhet szóba és értelemszerűen az adószám sem adható meg, ha pedig van belföldi adószáma, akkor "DOMESTIC", függetlenül attól, hogy az ügyvédi iroda, társasház, sportegyesület stb. Ennyi.

[NyBela]

Ennél egy cseppet bonyolultabb, de nem az online küldés oldalról, hanem input ellenőrzés oldalról.
Olyan, hogy nincs adószáma adat felvitelkor egy partnernek ki dönti el? Itt nem arról beszélek, hogy van 50-100 vevője egy cégnek, hanem 20-30-40000. Hogyan döntöd el, hogy az adatrögzítő elfelejtette, vagy nem akarta megadni az adószámot?
És ne mond, hogy az ő felelőssége, mert nem az, mert a cég felel a dolgozójáért. Egy nagyvállalati rendszerben nincs ilyen. Akkor fel kell venni egy külön állapotot, hogy "nem magán és nincs adószáma" azért mert....(hogy az adatrögzítő tudja) , ez esetben nem ellenőrizzük az adószám kitöltést, különben kötelező. De mivel eddig ez nem volt, végig kell ellenőriztetni az összes partnert. Beletenni az ellenőrzéseket a számlák készítésébe (van 9 féle számla indítási lehetőség) (normál, szállítóból automatikus, szerződéses automatikus, nem sorolom stb.). Most ellenőrzi, hogy ha magánszemély, ha közösségen belüli, ha közösségen kívüli, ha belföldi adóalany most akkor ez is kell. Nem egy nagy csoda a programozása, csak idő. Foglalkozni kell vele, és el kell magyarázni a felhasználónak, hogy mi ez. Megjegyzem, a számlázás egy vállalatirányítási rendszernek a töredéke.
Szóval, igen, tudni kellene, hogy pontosan mik az esetek, hátha a meglévő adatokból kinyerhető.

[KMGY100]

Az elmúlt több mint két évben hogy oldottad meg , amikor
csupán két kategória volt.

1. ADÓALANY
2. NEM ADÓALANY
   Az adóalanyokat eddig is adószámmal kellet megadni.

[EnokhSys]

Olyan, hogy nincs adószáma adat felvitelkor egy partnernek ki dönti el? Itt nem arról beszélek, hogy van 50-100 vevője egy cégnek, hanem 20-30-40000. Hogyan döntöd el, hogy az adatrögzítő elfelejtette, vagy nem akarta megadni az adószámot?

Kedves @NyBela, nézd, először is az adatrögzítő kapja valahonnan/valakitől a rögzítendő partner adatait. Tehát a felelősség onnan indul, akitől az adatokat kapja a rögzítő.

Másodsorban, informatikailag több finom "noszogató-módszer" is rendelkezésre áll. Mivel évtizedek óta én is ezen a területen mozgok, több fajta megoldást ki lehet dolgozni, és onnantól már igenis a rögzítő felelőssége. Ha most nekem kellene megoldanom, akkor az egyik az lenne, hogy amennyiben üresen hagyja az adószámot, először rákérdeznék, hogy nem felejtette-e el kitölteni. Amennyiben a válasz nem, akkor a partner típusának kiválasztását kényszeríteném ki, méghozzá úgy, hogy nem választhatná ki a "Belföldi adóalany"-t (ami az alapértelmezett érték új partner rögzítésénél). Olyat pedig, hogy "nem magánszemély és nincs adószáma" nem kínálnék fel lehetőségként, hanem a "Magánszemély", a "Külföldi adóalany" és "Nem adószám-köteles egyéb vevő"-t.

De mivel eddig ez nem volt, végig kell ellenőriztetni az összes partnert.

Persze. Viszont ebben nagy segítség a NAV OnLine Számla-ban az adószám lekérdezése funkció, így egy elég nagy halmazt ki lehet szűrni. A maradékot pedig a felhasználók/ügyfelek kell leellenőrizzék. Tehát itt nincs mese, ha elhanyagolt a partnertörzs, akkor az a felhasználó/ügyfél felelőssége, és ő kell rendbe tegye. Persze, amennyire informatikailag lehetséges, segítséget kell nyújtani, de ez akkor is "emberi-munka", amit a gép nem tud elvégezni.

Beletenni az ellenőrzéseket a számlák készítésébe (van 9 féle számla indítási lehetőség) (normál, szállítóból automatikus, szerződéses automatikus, nem sorolom stb.). Most ellenőrzi, hogy ha magánszemély, ha közösségen belüli, ha közösségen kívüli, ha belföldi adóalany most akkor ez is kell. Nem egy nagy csoda a programozása, csak idő.

Ezt azért nem egészen értem, hiszen az ellenőrzést csak a partnertörzsbe történő rögzítésekor kell betenni. Amikor pedig megtörténik a NAV felé a számlafeladás, akkor gondolom nem 9 feladóprogram van.

Megjegyzem, a számlázás egy vállalatirányítási rendszernek a töredéke.

Ez így igaz. :-)

[NyBela]

Annyit hozzátennék: A partnertörzs bővül az alábbi módokon: Partnertörzsbe adatfelvitellel, Központi partnertörzs kezeléssel (cégcsoportos egységesítés), Adatimport file.ból pl. XLS, WEB oldali WEBSHOP rendelés, Mobil Számlázás alkalmazás, stb..... Nem sorolom tovább, ezek mind partner input adatok, amit ellenőrizni kell. Nyilván a NAV felé már egységes a küldés. De megakadályozzuk a számla kiállítását, ha hibás az adatkitöltés. Sőt már a számla elkezdésekor megkapja a felhasználó az üzenetet, hogy ne is folytassa. De nem a programozási rész érdekel, mert az megoldható egyszerűen, hanem az alapkérdésre a válasz. Kik ezek a vevők? "topybear" válasza, amivel kezdeni tudok valamit, csak kérdés, hogy melyik vevőcsoport még ilyen?

[EnokhSys]

De nem a programozási rész érdekel, mert az megoldható egyszerűen, hanem az alapkérdésre a válasz. Kik ezek a vevők? "topybear" válasza, amivel kezdeni tudok valamit, csak kérdés, hogy melyik vevőcsoport még ilyen?

Kedves @NyBela, tegnap, amikor olvastam a topiknyitó hozzászólásodat, azt hittem, hogy valami új adó-csoportosítást vezetett be a NAV a vevőknél. Aztán később, amikor fejlesztés közben utánaolvastam a NAV dokumentációnak, láttam, hogy valójában a korábbi "privatePersonIndicator" került lecserélésre ill. kibővítésre, és ezt ma reggel @nbeeps2 meg is erősítette.

Az általad leírtak szerint így is elég bonyolult a munkád, szóval kicsit úgy érzem, hogy ezt még tovább bonyolítod, hiszen a megoldás szempontjából irreleváns, hogy kik azok a vevők, akik nem is magánszemélyek és nem is rendelkeznek adószámmal. És ez független attól, hogy 100-as, 1000-es vagy 10000-es partnertörzsről beszélünk. Persze, pusztán érdekességként ki lehet deríteni...

[omachtandras]

Azt hiszem én érteni vélem @NyBela problémáját és szerintem ez sok szoftverben létező dolog.
Eddig nem volt szükség annak megkülönböztetésére, hogy valaki miért adószám nélküli.
Lehetett ő magánszemély, lehetett nem ÁFA alany jogi személy, számlázás szempontjából ugyanolyan volt.
Rákerült a számlára a neve, címe, és nem került rá adószám.
Most viszont a NAV felé ezt a "csoportot" kétféleképpen kell jelenteni.
Egyik esetben kell nevet és címet, a másik esetben pedig nem.

Ezzel mi is megküzdöttünk, és végül bevezettünk egy új típust, ami konkrétan nevesíti, hogy ő egy nem ÁFA alany jogi személy.
Nálunk is, ahol előfordulhat, hogy a törzsben ilyen partner van az ügyfélnek végig kell menni, és be kell kapcsolni ezt a flag-et minden érintett rekordon.

Nincs szerintem jobb és egyszerűbb megoldás ennek a problémának a megoldására törzs - és adatszolgáltatás - szinten.

(Nem tudom, hogy a NAVnak mi a terve az így kapott név és cím adatokkal, hiszen ezek a számlák sosem fognak levonásba kerülni egyetlen adóalanynál sem, így igazából ez egy olyan bontás, amit nem látok indokoltnak az ÁFA bevallások elkészítéséhez. Persze, lehet, hogy csak a másik irányból közelítettek és minden adatot be akartak kérni, csak a GDPR meg a profilozási vád elkerülése miatt a magánszemélyeknél gondolták csak, hogy ne jöjjön név és cím, nem gondoltak bele, hogy máshol is esetleg felesleges adat.)

[KMGY100]

Csak egy gondolat:
említett @NyBela WEBSHOP -os rendelést.
Ebben az esetben a vevőnek önmagának kell valamelyik vevői kategóriába besorolnia saját magát.
Ez azért nehezebb mint hogyha az eladó sorolja be a vevőjét valamelyik kategóriába.

Egy másik jegyzetben már javasoltam:
Az alapkategóriákat tovább lehet bontani és ezt
tárni a vevő elé, hogy pontosan meghatározhassa önmagát.
Van 3 alapkategória:

1. BELFÖLDI ADÓALANY
   ez rendben van, ezzel nem kell semmit tenni (CÍM VAN ADÓSZÁM VAN XML-ben)
2. MAGÁNSZEMÉLY
   ezt mér tovább lehet bontani
   a. magyar (CÍM NINCS, ADÓSZÁM NINCS)
   b. külföldi (itt országlistából választhat a vevő) (CÍM NINCS, ADÓSZÁM NINCS XML-ben)
3. EGYÉB
   ezt pláne tovább lehet bontani
   a. MAGYAR JOGI SZEMÉLY AKINEK NINCS ADÓSZÁMA (CÍM VAN, ADÓSZÁM NINCS XML-ben)
   (pl. adószám nélküli társasház, egyesület...)
   b. EU tagállamú cég (CÍM VAN, ADÓSZÁM vagy VAN vagy NINCS XML-ben)
   ( közösségi adószámot vagy kitölt vagy nem)
   c. NEM EU tagállamú cég (CÍM VAN, ADÓSZÁM vagy VAN vagy NINCS XML-ben)
   ( adószámát vagy kitölt vagy nem)

De felbonthatod 25 elemre is, csak az XML tagok helyes töltésére kell figyelni.
És arra, hogy pl. a vevő önmagát MAGÁNSZEMÉLY-ként jelölte
akkor ne lehessen pl. közösségi adószám mezőt kitölteni.

[EnokhSys]

@KMGY100 ez is egy jó megoldás. Én picit szerencsésebb helyzetben vagyok, mert a partnertörzsben már a kezdetek óta "Belföldire" és "Külföldire" osztottam a partnereket, ez a kiindulópont. Ezek után adható meg a partner típusa, hogy az adóalany (cég) vagy magánszemély vagy egyéb szervezet/jogi személy. A kettő alapján vezérlem az adószámok kitöltését és a NAV feladást.
Igaz, hogy nálam nincs webshop, de ha lenne, akkor is ugyanezt a rögzítési sorrendet tartatnám be a webes felhasználóval. (Persze, ha a webshop-os felületet egy másik informatikai cég csinálja, akkor azt ők kell megoldják, viszont a partnertörzs-interfészt hozzá kell igazítani az új NAV követelményeknek.)

[EnokhSys]

Egyébként, eszembe jutott egy gyakorlati kérdés magánszemély esetén. Amikor a magánszemély számlát kér és nem nyugtát, akkor azt is kérheti, hogy a számlán szerepeljen a személyes neve és lakcíme. Megtagadhatom-e tőle ezt a kérést? Például azzal, hogy mivel a NAV sem fogadja be a személyes adatokat, ezért a számlán vevőként csak annyit tüntetek fel, hogy "Magánszemély".

Tehát, tulajdonképpen a kérdés az, hogy van-e valamilyen törvényi kötelezettség amelynek alapján a magánszemély vevőnek teljesítenem kell azt a kérését, hogy a számlán szerepeljenek az általa közölt személyes adatok?

[KMGY100]

@EnokhSys hasonlóan oldottam meg én is, csak betettem egy
egy teljes országlistát mely tartalmazza az országkódot, az ország nevét
és az EU tagoknál egy jelet.
Az a hármas állapotbesorolás és az országlista pontosan megmutatja
hogy mely adószám mezőt kell/lehet kitölteni (magyar,EU-s, 3. állam)

Így oldottam meg, annak ellenére hogy Afganisztáni vevője tuti nem lesz
a prg használómnak.

[renced42]

Tehát, tulajdonképpen a kérdés az, hogy van-e valamilyen törvényi kötelezettség amelynek alapján a magánszemély vevőnek teljesítenem kell azt a kérését, hogy a számlán szerepeljenek az általa közölt személyes adatok?

Ha a gazdasági eseményt számlával kell igazolni és azt ki kell állítani akkor azt kell ráírni ami az Áfa tv. 169. §. szerint kötelező és amit az ügyfél kér. A vevő neve és címe kötelező elem így azt rá kell írni, mindegy, hogy magánszemély vagy sem.

[KMGY100]

A számlán kötelezően szerepelni e kel a vevő címének, akkor is ha a vevő
magánszemély.
Az XML-ben nem szerepelnek címadatai.

[EnokhSys]

@EnokhSys hasonlóan oldottam meg én is, csak betettem egy
egy teljes országlistát mely tartalmazza az országkódot, az ország nevét
és az EU tagoknál egy jelet.
Az a hármas állapotbesorolás és az országlista pontosan megmutatja
hogy mely adószám mezőt kell/lehet kitölteni (magyar,EU-s, 3. állam)

Igen, én is. (Annyi különbséggel, hogy az országkódot a székhely cím megadásakor lehet kiválasztani.)

Így oldottam meg, annak ellenére hogy Afganisztáni vevője tuti nem lesz
a prg használómnak.

:-)) Soha nem tudhatod... lehet, hogy a HM megveszi a programodat és most, hogy jönnek a Leopard 2-esek, leselejtezik a régi T-72-eseket és rásózzák óccsóért az afgánokra. :-)

[EnokhSys]

Kedves @renced42 és @KMGY100, köszi a magánszemélyes vevőszámla tisztázást. Ezt eddig is így csináltam, csak gondoltam, hogy ebben valami változás állt be a törvényben, és ezért nem fogadja be a NAV az XML-ben.

[NyBela]

Hát fiúk köszönöm a sok hasznos hozzászólást. Nálunk is van belföldi/külföldi, magán/jogi személy és országkódlista ami alapján EUs/nem EUs. Meg a létező összes adószám féle. Én is azt szerettem volna, hogy ezeknek a kombinációjából kinyerjük. Ezért szerettem volna választ kapni arra, hogy kik ezek a vevők? Mihez köthető? De még mindig nincs konkrét válasz az egy társasházon kívül. Nem bízhatom a felhasználókra a besorolást, mert ha nem teszik meg, pedig nem fogják megtenni január 1-ig, a számlák rosszul fognak bemenni, utána meg azzal küzdhetünk, és magyarázkodhatunk, hogy miért "rossz" a program. Ezt meg kell akadályoznom. Itt sok ezer számláról van szó. És most ne jöjjön senki a szankció mentes időszakkal. Sokra megyek vele. A 3.0-t be fogjuk vezetni, mert az elmúlt időszakban nagy előfeszítés volt, hogy a bejövő számlák automatikus iktatását-könyvelését bevezessük a NAV-tól lekérve a számla adatokat, ami szépen működik is. Ha nem vezetjük be, akkor nem tudom letölteni és automatikusan könyvelni azokat a számlákat amiket már 3.0-val küldenek be más fejlesztők. Akkor meg a könyvelés panaszkodik, hogy most meg mi van? Eddig működött most meg nem. Már azon gondolkodom, hogy ketté veszem (igazából már működik is) beküldés 2.0, könyvelés 3.0. Ha addig a 3.0 rendeződik, akkor perszer mind a kettő 3.0. Tulajdonképpen készen volt, leteszteltünk ha jól számolom 288 féle esetet, ami az ügyfélkörben előfordul. Egészen eddig....

[KMGY100]

@NyBela abban igazad van, hogy kérhetnénk itt a @NTCA-developer -től vagy a @NTCA-tax -tól
egy bővebb listát a
MAGYAR NEM MAGÁNSZEMÉLY de NEM IS ADÓALANY szereplőkről.

Eddig csak annyit tudunk hogy adószám nélküli társasház és egyesületek és ennyi

@NTCA-tax ! Tudnál picit bővebb felsorolást adni ?
(például: egyházak ? pártok ? )
Nekünk is segítség lenne hogy az ügyfeleinket tudjuk tájékoztatni.

[topybear]

Mi inkább bevezettük az adószámot kiadó ország fogalmát, így ha az afgán cég magyar adószámot kérve veszi meg a T-72-eseket, akkor sem fogunk kardunkba dölni :)
Már találkoztunk amerikai céggel, aki kért magának magyar adószámot, szerencsére akkor ÁFA határ alatt volt a számlája, így nem kellett beküldeni.

[EnokhSys]

Mi inkább bevezettük az adószámot kiadó ország fogalmát, így ha az afgán cég magyar adószámot kérve veszi meg a T-72-eseket, akkor sem fogunk kardunkba dölni :)

Mármint úgy érted, hogy az afgán cég Mo-n létesít kirendeltséget/leányvállalatot és magyar adószámot vált ki? Ez így teljesen okés, és mivel értelemszerűen a T-72-eseket kiviszi az anyavállalatnak, a nemzetközi szerződések értelmében ez adómentességet élvez, ezért a "vatExemption/case=EAM"-el kell beküldeni a számlát a NAV-nak. :-)

Már találkoztunk amerikai céggel, aki kért magának magyar adószámot, szerencsére akkor ÁFA határ alatt volt a számlája, így nem kellett beküldeni.

Nahát, nem tudtam, hogy a NASAMS rakéta-pajzs beszerzésben is benne vagy... mondjuk nem csodálkozom, mert ahogy véget ért az örmény-azeri egy hónapos, októberi háború, a HM-nek ez egy nagyon meggyőző érv volt arra nézve, hogy egy ellenséges drónhadsereg milyen végzetes pusztítást tud véghez vinni. Jut eszembe: olcsó izraeli csapásmérő drónokra nincs szükségetek? Most akciósan kínálják, kettőt veszel és bónuszként adnak mellé egy lopakodó tevét... hasznos állat, mert úgy idomították, hogy az ellenség vonalai mögé lopakszik, és a púpjáról indítják a drónt. :-)

[omachtandras]

@KMGY100 ez is egy jó megoldás. Én picit szerencsésebb helyzetben vagyok, mert a partnertörzsben már a kezdetek óta "Belföldire" és "Külföldire" osztottam a partnereket, ez a kiindulópont. Ezek után adható meg a partner típusa, hogy az adóalany (cég) vagy magánszemély vagy egyéb szervezet/jogi személy. A kettő alapján vezérlem az adószámok kitöltését és a NAV feladást.
Igaz, hogy nálam nincs webshop, de ha lenne, akkor is ugyanezt a rögzítési sorrendet tartatnám be a webes felhasználóval. (Persze, ha a webshop-os felületet egy másik informatikai cég csinálja, akkor azt ők kell megoldják, viszont a partnertörzs-interfészt hozzá kell igazítani az új NAV követelményeknek.)

@EnokhSys - az az izgalmas az egészben, hogy egy közösségi adószámos partner simán megjelenhet olyan ügyletben, amikor ő nem ÁFA alany jogi személy.
Kollégám kedvenc példája, hogy egy magyar adószámmal nem rendelkező uniós adószámú partnerem itt eszi meg nálam az étteremben a pizzát és erről számlát kér.

Ebből látszik, hogy nem lehet vakon a törzsadatokban bízni és az alapján eldönteni, hogy ez majd milyen ügylet lesz.

(Ahogy az is simán lehet, hogy egy közösségi partnernek van magyar adószáma IS és hol ez, hol a közösségi adószáma jelenik meg a számlán, attól függően hol a teljesítés helye.)

[NyBela]

Hát Uraim az alapkérdéssel nem jutunk előbbre. Mert nem az informatikai megoldás a kérdés, mert az mindannyian meg tudjuk oldani, hanem, hogy segítsük a programjainkat felhasználó cégek munkáját. Tőlünk fognak legelőször kérdezni. Átadjuk a 2021-es változásokról a felhasználói útmutatót és nem tudom beleírni, hogy mi a kitöltési szabály. Fel fog hívni a számlázó és nem tudok mit mondani neki. Ez elég kellemetlen. Csak ez után fog nyomozni máshol. Ja és közben persze elküld vagy száz számlát mert ugye számlázni meg kell. Átállítja közösségen kívüli magánszemélyre, vagy mit tudom én mire, de addig kísérletezik, amíg a számla elmegy. Azt, hogy nem jó, nem érdekes. Aztán az jön, hogy Ő aztán nem így csinálta. Csak hát naplózva van. Többször találkozunk azzal a mentalitással, hogy amit a számlázó program megenged azt lehet. Az, hogy vannak paraméterek egy partnernél az nem érdekes. "Én csak az ENTER-t ütöm" a válasz.
Ezért régóta az a meggyőződésem, hogy szinte semmit sem lehet a felhasználóra bízni. Azt, hogy "figyelmezteted" felejts el. Engeded/vagy tiltod ezek az opciók.
Ott tartunk, hogy talán társasház, egyesület. (alapítvány?) pl. Ezekből százával vannak a kérdéses partnertörzsben.

[NTCA-tax]

Az általatok felvetett kérdéseket adóhivatalon belül is nagyon hosszan rágtuk át, és ennek eredményeként jutottunk a sémában szereplő felbontáshoz. Menjünk sorba, hogy melyik kódnál pontosan mi lehet a számla adattartalma, milyen ügyletekről beszélünk:

1. Magánszemély vevő: a magánszemély nem áfaalany, amennyiben nem végez gazdasági tevékenységet (vagy ha végez is, de az adott ügyletnél nem mint adóalany jár el). Tehát itt a legfontosabb, hogy a vevő magánszemély minőségben jár el. Fontos, hogy itt nem csupán a magyar magánszemélyre kell gondolni, hanem a külföldi magánszemélyekre is.

2. Belföldi adóalany vevő: ebben az esetben gazdasági tevékenységet végző társaság, egyéni vállalkozás, adószámos magánszemély, társasház, egyesület, alapítvány. Itt a lényeg a gazdasági tevékenység végzésén van. Ebben az esetben a vevőnek rendelkeznie kell adószámmal, mivel gazdasági tevékenységet csak bejelentkezést követően végezhet (legalábbis elviekben). A vevő a vásárlásnál ekkor megadja az adószámát, melyet szerepeltetnie kell az értékesítőnek a számlán (kivéve, ha az értékesítő áfa regisztrált adóalany). Azt érdemes tudni, hogy például társasház úgy is rendelkezhet adószámmal, hogy nem végez gazdasági tevékenységet, de értékesítőnek ezekről nem kell feltétlenül tudni. Szoftver oldalról annyit lehet segíteni a felhasználónak, hogy ha van egy belföldi adóalany jelölő, akkor erre felhívja a felhasználó figyelmét. Azt fontos tudnotok, hogy ha belföldi adóalany jelölővel érkezik be az adatszolgáltatás (és az értékesítő nem áfaregisztrált), akkor error validáció fut le az adószámra vonatkozóan. Tehát szoftver oldalról érdemes ebben az esetben ténylegesen kikényszeríteni a felhasználótól az adószám megadását.

3. Minden egyéb: ide tartoznak a közösségi adóalanynak történő értékesítések, export ügyletek, nem adóalany szervezeteknek kiállított számlák. Az utolsó esetén még lehet egyértelmű szabályt alkotni, mivel ekkor a vevő nem rendelkezik adószámmal. Olyanok tartoznak bele, mint például a gazdasági tevékenységet nem folytató egyesületek, alapítványok, társasházak, kizárólag közhatalmi tevékenységet végző szervezetek. Amennyiben ilyen vevőre történik meg a számla kiállítása, akkor értelem szerűen csak a nevet, címet lehet megadni, mivel adószámmal nem rendelkeznek (most a kivételes eseteket ne vegyük ide). A többi esetnél viszont adattartalom szempontjából nem lehet egyszerű szabályt alkotni. Adóhivatali oldalon is belekezdtünk ebbe, ugyanakkor annyi kivétel szabály van, ami már nem elvárható egy szoftver tudásától, ezt a felhasználónak kell tudnia. Például egy német adóalanynak teljesített értékesítés lehet közösségi fordított adózású ügylet (ekkor az adószám szerepeltetése kötelező), ugyanakkor vannak olyan esetek, amikor a jogszabály alapján nem szabadna a közösségi adószámát feltüntetni. Export ügyletnél pedig vagy van adószám, vagy nincs, vagy van áfa-hoz hasonló adózás, vagy nincs. Ezek nagyon nehezen algoritmizálható esetek, és ha nagyon jól akartuk volna megoldani, akkor most fognátok a fejeteket. Így költség-haszon elemzést követően jutottunk el arra, hogy ebbe séma szinten nem megyünk bele, utólag pedig tudunk erre elemezni, ha nagyon akarunk.

Fejlesztői oldalról ami talán tanulsága lehet a fentieknek, hogy a felhasználóra kell bízni bizonyos esetekben a számla helyes kitöltését. A szoftver nem fog tudni minden kivétel szabályt helyesen lekövetni, a kiállítónak a felelőssége, hogyan állítja ki a számlát.
Ezzel kapcsolatban az egyik kedvenc példám, hogy ha egy magánszemély vásárlásának esetei. Amennyiben magánszemélyként vásárol, akkor a név és a cím a számla kötelező adattartalma (no ez az, ami adatszolgáltatásban nem szerepelhet, de a számlán igen). Amennyiben a magánszemélynek van egy egyéni vállalkozása és vállalkozási célú a beszerzése, akkor ugyanaz a név, cím szerepel, viszont a belföldi adószám kötelező adattartalma a számlának. Amennyiben az egyéni vállalkozónak van egy szlovák áfa regisztrációja és az ügylet az áfa regisztrációt érinti, akkor a közösségi adószámot kell a számlán feltüntetni, de ettől a név, cím ugyanaz marad.
Tehát sokkal inkább az adott ügylet dönti el a vevő státuszát, amit a felhasználónak kell tudnia, a szoftver nem fogja tudni kitalálni. Persze lehet terelni a felhasználót, különböző figyelmeztetéseket, akár megkötéseket a szoftverbe beépíteni, de meg kell hagyni egy bizonyos szintű szabadságot is. Az a kérdés, hogy a felhasználó ezt a szabadságot hogyan használja már sokkal inkább felhasználói felelősség.

[EnokhSys]

@EnokhSys - az az izgalmas az egészben, hogy egy közösségi adószámos partner simán megjelenhet olyan ügyletben, amikor ő nem ÁFA alany jogi személy.
Kollégám kedvenc példája, hogy egy magyar adószámmal nem rendelkező uniós adószámú partnerem itt eszi meg nálam az étteremben a pizzát és erről számlát kér.

Ez teljesen rendben van, mert ezt külföldi partnerként rögzítem, belföldi ügyletű számlát készítek 27%-os ÁFA-val, és a partnertől megkérdezem, hogy kétnyelvű számlaképpel nyomtassam-e ki, amelyen rajta van a külföldi adószám is, vagy magyar számlaképpel, amin ez nincs rajta. A NAV feladáskor pedig eleve OTHER-rel adom fel, a külföldi volta miatt.

Ebből látszik, hogy nem lehet vakon a törzsadatokban bízni és az alapján eldönteni, hogy ez majd milyen ügylet lesz.

Én ezt sehol nem állítottam, csupán azt mondtam, hogy ez alapján vezérlem a NAV feladást. Nyilvánvaló, hogy a rendszeremben a számla kiállítás menete - akár egy folyamat részeként, akár kézileg -, ügylet szempontjából nincs bekorlátozva.

(Ahogy az is simán lehet, hogy egy közösségi partnernek van magyar adószáma IS és hol ez, hol a közösségi adószáma jelenik meg a számlán, attól függően hol a teljesítés helye.)

Itt azért álljunk meg egy picit: tudtommal ahhoz, hogy egy külföldi cégnek magyar adószáma legyen, kell hozzá mo-i telephely. Ebben az esetben viszont belföldi cégként is berögzítem, mo-i telephellyel.

[omachtandras]

"Itt azért álljunk meg egy picit: tudtommal ahhoz, hogy egy külföldi cégnek magyar adószáma legyen, kell hozzá mo-i telephely. Ebben az esetben viszont belföldi cégként is berögzítem, mo-i telephellyel."
De miért kell ennek két partnernek lenni? Egy folyószámlája van, ugyanarról a cégről van szó, stb. stb.
(Ha Nálad a folyószámla lehet több partner között közös, akkor a kérdésem tárgytalan.)

[NTCA-tax]

"Itt azért álljunk meg egy picit: tudtommal ahhoz, hogy egy külföldi cégnek magyar adószáma legyen, kell hozzá mo-i telephely. Ebben az esetben viszont belföldi cégként is berögzítem, mo-i telephellyel."

Az áfa regisztráció éppen erről az esetről szól. A másik közösségi tagállamban letelepedett vállalkozásnak nincs Magyarországon gazdasági letelepedettsége, de van magyar adókötelezettsége. Ekkor bejelentkezik hozzánk és kap magyar adószámot. De ettől a külföldi társaság neve, címe marad.

[NyBela]

Kedves NTCA!
Köszönöm szépen a választ! Mint már írtam, a programban való lekezelés nem probléma, de
nem lesz könnyű majd a felhasználókkal megértetni.
Tudom, hogy egy törvény, rendelet, előírás stb. betartása, betartatása nem szempont a létrehozásakor, megalkotásakor.
De figyelembe kellene venni a végrehajthatóságot is. Nagyon sok helyen a számlázásnál nem számviteli szakemberek ülnek, hanem a sok éve a cégnél dolgozó raktárosok, kereskedők, stb. Értem, hogy ez a törvény betartása szempontjából ez nem szempont, rendben is van, de mi viszont, mint fejlesztők, ezzel szembesülünk. Ezért keresünk olyan eljárásokat, beállításokat, paramétereket stb. hogy ezeknek a felhasználóknak ne kelljen dönteni, hanem a programmal tudjuk segíteni őket. Lehetőség szerint ne kövessenek el hibát. Ez a felvetett kérdés is azt a célt szolgálta, hogy behatárolhassunk egy meglévő több tízezres partner állomány szűrését, besorolását, valamint az új vevők megfelelő paraméterezését. Sajnos ezzel nem vagyunk előbbre.
Üdv.

[EnokhSys]

"Itt azért álljunk meg egy picit: tudtommal ahhoz, hogy egy külföldi cégnek magyar adószáma legyen, kell hozzá mo-i telephely. Ebben az esetben viszont belföldi cégként is berögzítem, mo-i telephellyel."

Az áfa regisztráció éppen erről az esetről szól. A másik közösségi tagállamban letelepedett vállalkozásnak nincs Magyarországon gazdasági letelepedettsége, de van magyar adókötelezettsége. Ekkor bejelentkezik hozzánk és kap magyar adószámot. De ettől a külföldi társaság neve, címe marad.

Ezt nem tudtam, de mindig tanul valami újat az ember. Ezidáig erre még nem volt szükség, de végül is csak annyiból áll az egész, hogy kiveszem a tiltást a partnertörzs rögzítésekor, és megengedem hogy a felhasználó kitöltse a magyar adószámot is külföldi cég esetében.

[EnokhSys]

"Itt azért álljunk meg egy picit: tudtommal ahhoz, hogy egy külföldi cégnek magyar adószáma legyen, kell hozzá mo-i telephely. Ebben az esetben viszont belföldi cégként is berögzítem, mo-i telephellyel."
De miért kell ennek két partnernek lenni? Egy folyószámlája van, ugyanarról a cégről van szó, stb. stb.
(Ha Nálad a folyószámla lehet több partner között közös, akkor a kérdésem tárgytalan.)

@omachtandras Nálam sem lehet közös két partnernek a folyószámlája. Egyébként meg jogos az észrevételed, ahogy @NTCA-tax -é is, úgyhogy ahogy fentebb is írtam, meg fogom engedni, hogy külföldi cégnek is lehessen kitölteni a belföldi adószámát. Köszi, mindig tanul valamit az ember.

[EnokhSys]

Ja és közben persze elküld vagy száz számlát mert ugye számlázni meg kell. Átállítja közösségen kívüli magánszemélyre, vagy mit tudom én mire, de addig kísérletezik, amíg a számla elmegy. Azt, hogy nem jó, nem érdekes. Aztán az jön, hogy Ő aztán nem így csinálta. Csak hát naplózva van. Többször találkozunk azzal a mentalitással, hogy amit a számlázó program megenged azt lehet. Az, hogy vannak paraméterek egy partnernél az nem érdekes. "Én csak az ENTER-t ütöm" a válasz.

@NyBela Ezt most ugye nem mondod komolyan??

[KMGY100]

@NTCA-tax
""""Az áfa regisztráció éppen erről az esetről szól. A másik közösségi tagállamban letelepedett vállalkozásnak nincs Magyarországon gazdasági letelepedettsége, de van magyar adókötelezettsége. Ekkor bejelentkezik hozzánk és kap magyar adószámot. De ettől a külföldi társaság neve, címe marad."""

Ebben az esetben a DOMESTIC-et úgy határoznám meg hogy:
Magyar adószámmal rendelkező társaság és nem szűkíteném le a kizárólag BELFÖLDI ( MAGYAR ) társaságokra.

[NyBela]

EnokhSys : Volt ilyen! Igaz nem egy nagy cégnél (bár milliárdos forgalmuk van), de a tulaj édesanyja nekiállt számlázni....
Neki lehet, az fia a tulaj! Neki aztán ne mondja meg senki....
De én nem ilyen esetre szeretnék felkészülni, mert ezt már tényleg a felhasználói hülyeség magasiskolája, ez az ő tésztája, egye is meg.
Én a jóhiszemű, értelmes, de nem számviteli szakembert szeretném támogatni. Ezért írunk több féle cél feladatot ellátó számla modult a rendszerbe, ahol nem kell dönteni a kezelőnek. Automatikus ÁFA kód átfordítások BELFÖLDI/EU/nemEU stb. nem sorolom úgy is ismeritek .

[KMGY100]

@NTCA-tax
"""Ebben az esetben a DOMESTIC-et úgy határoznám meg hogy:
Magyar adószámmal rendelkező társaság és nem szűkíteném le a kizárólag BELFÖLDI ( MAGYAR ) társaságokra."""

Ezt az átdefiniálást én magam is megtehetem vagy
felveszek egy negyedik kategóriát

• MAGYAR ADÓSZÁMMAL RENDELKEZŐ KÜLFÖLDI TÁRSASÁG

[EnokhSys]

@NyBela tökéletesen egyetértek azzal, hogy a felhasználót segíteni kell a munkájában. De mindig is azt vallottam, és ezt mindannyiszor el is mondom a felhasználóknak, hogy a számítógépes program pont olyan mint az autó: értelmesen, felelősséggel kell kezelni. Ha rükvercbe teszi és betolat a kerítésbe, az már az ő felelőssége. Mint ahogyan az is, ha kopott gumiabronccsal jár és jó esetben csak megbünteti a rendőr, rossz esetben kicsúszik a kanyarban, ami lefordítva azt jelenti, hogy:
"_4.3 Megbízó felelőssége, hogy a számlázási előírások mindenkor hatályos jogszabályait, rendelkezéseit
megismerje, és az abban foglaltakat betartsa, azt dolgozóival betartassa. A számla-interfész 2.0-ás verzió használata
csupán elősegíti, meggyorsítja a számlázási előírásokban foglalt kötelezettségek teljesítését..._"

[NyBela]

Lehet hogy nem kísérletezek tovább:
Felveszek a partner mellé egy "Adószám szerepeltetése" állapotot default 0 -val (vagy null, mindegy) és minden más beállítás (külföldi/belföldi eu/nemeu magán/jogi stb.stb. a küldés szempontból közömbös lesz, csak ennek a kitöltését segíti)
(ennek az állapot jelzőnek a feltöltését megoldom a jelenlegi beállításokkal, (várhatóan 95%-ban fel tudom tölteni), ami 0 vagy null az hiba, azt kell besorolni a felhasználónak)
Tehát:
0 = (nincs kitöltve (hiba lista)
1-7 az interface specfikációból és ha a bővül, az sem probléma.
Számlázáskor = ha 0 = hiba (nem számlázhat)
Küldéskor csak az 1-7 alapján össze van válogatva a küldendő adat. Oszt' ennyi.

A vevő adószámának szerepeltetésére vonatkozóan egyes jellemző eseteket az alábbi táblázat mutatja be. Adószám szerepeltetése és customerVatStatus töltése
1.
Vevő Magyarországon nyilvántartásba vett csoportos áfaalany és a számlán kötelező szerepeltetni az adószámát.
customerVatStatus = DOMESTIC
A csoportazonosító számát (áfakódja: „5”) kell a customerInfo/customerVatData/customerTaxNumber/taxpayerId elemben szerepeltetni, míg a csoport tag „saját” adószámát (áfakódja: „4”) a customerInfo/customerVatData/customerTaxNumber/groupMemberTaxNumber/taxpayerId elemben kell megadni.
2.
Vevő Magyarországon nyilvántartásba vett (nem csoportos) áfaalany és a számlán
customerVatStatus = DOMESTIC
Az adószám legalább első nyolc számjegyét (törzsszám) kell a customerInfo/customerVatData/customerTaxNumber elemben szerepeltetni.
NAV Online Számla rendszer 86. oldal
kötelező szerepeltetni az adószámát.
3.
Vevő magánszemély
customerVatStatus = PRIVATE_PERSON
A customerVatData csomópontot ilyenkor nem szabad tölteni.
4.
Vevő a Közösség másik tagállamában nyilvántartásba vett adóalany és közösségi adómentes termékértékesítés az ügylet
customerVatStatus = OTHER
customerInfo/customerVatData/communityVatNumber töltése kötelező.
5.
Vevő a Közösség másik tagállamában nyilvántartásba vett adóalany, és az ügyletet belföldi 27, 18 vagy 5%-os áfa terheli.
customerVatStatus = OTHER
customerInfo/customerVatData/communityVatNumber töltése nem kötelező, de lehetséges megadni.
6.
A vevő harmadik országban letelepedett és az ügyletben nem másik tagállami adóalanyi minőségében vesz részt.
customerVatStatus = OTHER
customerInfo/customerVatData/thirdStateTaxId töltése nem kötelező, de lehetséges megadni.
7.
A vevő nem adóalany, ugyanakkor nem is magánszemély
customerVatStatus = OTHER
customerInfo/customerVatData egyik eleme sem adható meg, mivel a vevő nem rendelkezik adószámmal

[EnokhSys]

@NyBela Erről van szó, ez a legjobb megoldás. :-)

[szecsenyizoltan]

@NTCA-developer @NTCA-supporter @NTCA-tax

Jól látom, hogy ezt a dolgot lehetne azzal egyszerűsíteni, hogy a NAV nem mindent a kliensre terhel, hanem egy részét ő végezné el?
Pl.: Mindenki implementálja a magyar adószám 9. digitje alapján számos logikát miközben pl ez is simán lehetne nálatok.

[NTCA-tax]

@szecsenyizoltan Milyen logikára gondolsz az áfakód alapján? Mindegy, hogy milyen áfakód szerepel az adószámban, belföldi áfaalanyról beszélünk. Az alanyi mentes egyéni vállalkozó (akinek az áfakódja 1) is belföldi adóalany, függetlenül az adóelszámolási módszerétől.

[EnokhSys]

@NyBela Azért annyi megjegyzésem lenne, hogy figyelj oda az általad felsorolt 4-es és 5-ös pontra. Ez ugyanis ügyletfüggő, tehát a partnertörzsben meghatározni egy EU-s partnerről, hogy az konkrétan a 4-es vagy konkrétan az 5-ös csoportba tartozik, nem lenne célszerű.

[EnokhSys]

2. Belföldi adóalany vevő: ebben az esetben gazdasági tevékenységet végző társaság, egyéni vállalkozás, adószámos magánszemély, társasház, egyesület, alapítvány. Itt a lényeg a gazdasági tevékenység végzésén van. Ebben az esetben a vevőnek rendelkeznie kell adószámmal, mivel gazdasági tevékenységet csak bejelentkezést követően végezhet (legalábbis elviekben). A vevő a vásárlásnál ekkor megadja az adószámát, melyet szerepeltetnie kell az értékesítőnek a számlán (kivéve, ha az értékesítő áfa regisztrált adóalany).

@NTCA-tax Ez a "kivéve, ha az értékesítő áfa regisztrált adóalany" mit is jelent pontosan? Ha pl az értékesítő KATA-s és nincs benne az ÁFA körben, akkor nem kötelező feltüntetnie a vevő adószámát? De ettől még nem tilos feltüntetnie a számlán és beküldenie a NAV-nak, vagy igen?

[szecsenyizoltan]

@NTCA-tax pl: groupMemberTaxNumber ezt ti is tudjátok az adószámból. Feltéve, ha egy adószám nem lehet két csoport tagja.

[KMGY100]

@NTCA-tax !
Külföldi telephelyű regisztrált áfaalanyiság az adószámból kiderül ?
Például megyekódnál valami egyedi adat szerepel ?
vagy ?

[NTCA-tax]

@szecsenyizoltan A felvetésed akkor lenne jó, ha az áfaalany a csoporttag lenne. Ugyanakkor az áfaalany a csoport, és a csoport azonosítót kell a számlán feltüntetni. A csoporttag adószámának feltüntetésére pedig nincs jogszabályi kötelezettség sem. Így mi is csak a beküldött adatok alapján tudunk validálni.

@KMGY100 az áfa regisztráltaknak a megyekódja 51-es. Ugyanakkor az 51-es megyekódhoz nem csak ők tartoznak, hanem az összes különös hatásköri szervezet is.

@EnokhSys Áfaalany mindenki, aki Magyarországon gazdasági tevékenységet végez. Ezért nincs jelentősége annak, hogy ezt milyen formában, milyen áfa elszámolási módon teszi meg. Áfa regisztráltaknak (egészen pontosan gazdasági letelepedettséggel nem rendelkező belföldi áfa alanyoknak) azokat tekintjük, amely társaságoknak külföldön van a székhelyük, gazdasági letelepedettségük, de Magyarországon végeznek magyar áfa törvény hatálya alá tartozó tevékenységet.

[EnokhSys]

@NTCA-tax köszi,

[KMGY100]

@NTCA-tax
Az külföldi telephelyű áfa regisztrált vevő kezelése akkor lenne tökéletes
ha az adószám lekérdezés válaszában a megyekód is benne lenne (nem csak esetlegesen),
vagy az incorporation tag bővülne ÁFA REGISZTRÁLT elemmel

[NTCA-tax]

@KMGY100 az áfa regisztráció nem a vevőnél érdekes, hanem az eladónál. Amennyiben az eladó áfa regisztrált, akkor nem köteles feltüntetni a belföldi vevő adószámát. A számlakibocsátó már csak tudja magáról, hogy kicsoda, bár lehet, hogy tudtok olyan történeteket, amikor ezt sem tudta...

[KMGY100]

@NTCA-tax
A következő miatt:
DOMESTIC == BELFÖLDI ADÓALANY
A BELFÖLDI == Magyarországi telephellyel rendelkezik.
Ezért a DOMESTIC-nél nem engedek csak HU országkódú vevőt.

Ha tudom hogy a vevő áfa regisztrált akkor engednék külföldi címet is bevinni
a magyar adószám mellé.

[NTCA-tax]

Az áfa regisztrált is belföldi adóalanynak minősül, csak a székhelye van külföldön. De ettől még magyar adószáma van, Magyarországon van adókötelezettsége.

[KMGY100]

@NTCA-tax
Értem én.
Fogalmam sincs ki miképpen oldja meg a saját programjában
de az biztos, hogy ha valahogy tudtunkra adjátok hogy
xxx vállalkozás áfa regisztrált az nagy segítség lenne.

[peacefuldev]

@NTCA-tax jól értem akkor, hogy nem helyes a #572 ticketben leírt megoldásunk?
Tehát muszáj ezt a legördülő menüt megvalósítani a programban?

Csak azt nem értem, hogy ezt miért nem tudták időben kommunikálni. Hogy várhatják el, hogy az egyszeri fejlesztők karácsony előtt 2 héttel teljesen átprogramozzák az addig követelményeknek megfelelő rendszert?
Maguknak nincs családjuk, nem pihennek az ünnepek között?
Agyrém ez az egész, és immár az online számlázás bevezetése óta ez megy, menetrendszerűen. Egy kicsit lehetnének tekintettel a fejlesztői oldalra is.

[EnokhSys]

@NTCA-tax és @NTCA-developer , kapcsolódva az előzőekhez, én azt látom, hogy ez a "customerVatStatus" számos esetben hibásan lesz kitöltve a bonyolultsága okán.

Ahogy @NTCA-tax a magánszemélyes példájánál leírta, a számla kiállításkor az ügyintéző kell eldöntse a vevő kérése alapján, hogy ő most "PRIVATE_PERSON", vagy "DOMESTIC". (A harmadik változatot, amikor van szlovák adószáma, csak azért nem említem, mert nem hiszem. hogy annyira gyakori lenne.)
Ezt még tovább bonyolítja az az eset, amikor egy külföldi cégnek van magyar adószáma is (és jellemzően magyar telephelye is). Ezért vásárláskor kérhet belföldi számlát a magyar adószámára, vagy kérhet export számlát az EU-s adószámára. Habár nem túl gyakori, hogy az ilyen típusú vevő ugyanattól az eladótól vásároljon egyszer belföldi adószámra, egyszer meg külföldi adószámra, ezt mégsem lehet kizárni.

Tehát, itt nem csupán a számlázókra raktatok plusz terheket, hanem a programozókra is, hiszen ehhez nem csupán a partnertörzs kell - ami önmagában egyszerű lenne, és senki nem háborodna fel rajta -, hanem mindenképp kell hozzá a számlázandó ügylet típusa is, amit viszont már a felhasználónak kell felkínálni valamilyen formában, hogy válassza ki; - a webes felületről nem is beszélve.

Szerintem vissza kellene térni az eredeti koncepcióhoz, hogy ez a szegmens csak a belföldi/külföldi céges vevőt (és nem adóalanyt!), a belföldi/külföldi magánszemélyt és az egyéb vevőt jelentse. Ha pedig a NAV elemezni akarja a csalásra gyanút adó ügyleteket, akkor ezt megteheti az ÁFA kód és ennek a szegmensnek a relációjával.

Szóval ezt gondoljátok át, mert megint magatokra húzzátok a könyvelői népharagot, és Dózsa György programozó unokáit a kiegyenesített kaszákkal. :-)

[KMGY100]

@EnokhSys
Nem, ne most már ne állítsák vissza szerintem.

Nekem a áfa regisztrált külföldi zavart be (mint számomra teljesen új dolog)
de megküzdök vele.

Biztos vagyok abban, hogy Te is megoldod amit problémának látsz.

[EnokhSys]

@KMGY100
Nem is azt gondoltam, hogy most állítsák vissza, hanem, hogy majd gombolják újra a kabátot, mert ez így túl van bonyolítva a felhasználóknak, hogy megértsék mikor milyen számla-ügyletet kell kiválasztani a számlához.

Nekem is új volt ez a "külföldi partner belföldi adószámmal" de nálam sem okoz gondot, mert már évek óta külön menüpontban van a belföldi számlázás és az export számlázás. Így csak annyit kellett tennem, hogy a partnertörzsben megengedjem a külföldi cégeknél a magyar adószám kitöltését is, így belföldi számlát is ki lehet állítani nekik.

[nbeeps2]

Én úgy látom, hogy nem történt bonyolítás, csak leginkább felesleges volt a privatePersonindicator-t megszüntetni és behozni a helyére a customerVatStatus-t.

A név, cím, és a három adószám (belföldi, EU, 3. ország) variációkkal tökéletesen le lehetett fedni mindent, ehhez a customerVatStatus semmit nem tesz/tett hozzá. Bocs a sorrendért (ahogy eszembe jut):

1. Magánszemély: korábban privatePersonindicator True, cím nélkül küldve csak a név. Új rendszer szerint: PRIVATE_PERSON
2. Belföldi adóalany: korábban privatePersonindicator False, név és cím küldve, magyar adószámmal. Új rendszer szerint: DOMESTIC

MINDEN MÁS ESETET AZ ÚJ RENDSZER SZERINT: OTHER

1. Nem adóalany, de nem magánszemély: privatePersonindicator False, név és cím küldve, adószám nélkül.
2. EU-s külföldi cég: privatePersonindicator False, név és cím küldve, EU adószámmal.
3. Nem EU-s külföldi cég: privatePersonindicator False, név és cím küldve, 3. országbeli adószámmal

Szóval, teljesen felesleges volt a customerVatStatus bevezetése, mert ez a korábbi adatokból a feldolgozó oldalról egyértelműen megállapítható lett volna. Ez már a sokadik ilyen változtatás volt az XSD-ben...

Feldolgozói oldalról:
HA privatePersonindicator = True akkor PRIVATE_PERSON
HA False, akkor megnézi, hogy ki van-e töltve magyar adószám és akkor DOMESTIC, minden más esetben OTHER. Ennyi....

[NyBela]

Leszűrve a tanulságot a sok hozzászólásból, a jelenlegi Eu/Nem Eu , Magán/jogi beföldi/külföldi, országkód, stb. kapcsolók mellett bevezettünk egy küldéskor használatos besorolást, ami minden beállítást vezérel. (Az online számla spec. tartalmazza ezeket az eseteket) (könnyű lesz bővíteni is, ha majd kell.)
Ezek az esetek

Tehát: (mind)
[0] Nincs besorolva
[1]-[2] Magyarországon nyilvántartásba vett áfaalany
[3] Magánszemély
[4]-[5] Közösség másik tagállamában nyilvántartásba vett adóalany
[6] Harmadik országbeli tagállam
[7] A vevő nem adóalany és nem magánszemély és nincs adószáma
megjegyzés:
az 1-2 csoportos, nem csoportos, nem kell külön venni, azt a kitöltésből úgy is tudjuk
a 4-5 pedig ügylet függő, azt a számla tartalma dönti el

De először az ország kerül kitöltésre. Az országkód törzsben jelölve vannak az EU-s országok.
Ez után már csak így lehet a felsoroltakból választani.

Ha az országkód "HU'
[1]-[2] Magyarországon nyilvántartásba vett áfaalany
[3] Magánszemély
[7] A vevő nem adóalany és nem magánszemély és nincs adószáma

ha EU-s
[3] Magánszemély
[4]-[5] Közösség másik tagállamában nyilvántartásba vett adóalany

• Nem EU-s
  [3] Magánszemély
  [6] Harmadik országbeli tagállam

Lehet, hogy még csiszolni kell a beállításokat, hogy melyik esetben mi jelenjen meg, de a logika a lényeg.
A kiválasztások pedig kitöltik, hogy Eu/Nem Eu , Magán/jogi beföldi/külföldi

Így a felhasználó, csak országot és az adott országhoz tartozó esetekből választ, nem kapcsolgat semmi mást.
A küldés és annak ellenőrzése pedig egyszerű. Ami nincs besorolva = nem számlázható.

A vevő adat kitöltés pedig az XML-ben, hogy melyik eset, már könnyen eldönthető, nem kell mindenféle agyafúrt feltételeken gondolkodni.
Amúgy kész. Ma teszteltem is. Működik szépen, és kezelni is könnyű.

[bcdel]

[6] Harmadik országbeli tagállam

Szerintem ezt az ügyfeleid érdekében nevezd át, mert nekem úgy tűnik, hogy a közösségen belül vannak tagállamok, azon kívül a harmadik országok vannak. Azért vannak kívül mert nem tagállamok. (Remélem jól látom, ma már semmiben sem vagyok biztos)

A többi bontás jónak tűnik, remélem más is bólogat és akkor importálható a gondolat.

[NyBela]

Kedves bcdel! Igazad van, már át is írtam.
Amúgy ez csak egy alap logika, mert pl. ha azzal kezdi a felhasználó felvitelt, hogy beírja az adószámot, akkor meg kitöltünk mindent, nem kell semmit sem választani.
Persze vannak olyan beállítások, amelyeket nem lehet kitölteni. pl. ilyen az ÁFA mód, amit mi arra használunk, hogy be lehet állítani, hogy külön EU-s vagy NEM EU-s értékesítésnél milyen ÁFÁ-ról milyen ÁFA-ra váltson át automatikusan a program és szeretné-e az adott partner esetében ezt az átváltást.
pl.
Osztrák cég vásárol és mindig kiviszi (postázzák, külföldre fuvarozzák) a terméket és az alap 27%-helyett a megfelelő mentes ÁFÁ-t használja, akkor nincs más teendő, mint ezt beállítani és a raktáros, vagy kereskedő csak rakja a számlára a tételeket és más dolga nincs. (itt kötelező az EU adószám)
De van olyan is, hogy Osztrák cég mindig ÁFÁ-val vásárol. (nem tudja bizonyítani, hogy kivitte az országból stb.), akkor nála az van beállítva, hogy NE váltsa át az ÁFÁ-t, így meg fogja fizetni az ÁFÁ-t. (itt sincs semmi más dolga a kezelőnek)
Lehet persze vegyes is, akkor pedig az értékékesítéskor, számlázáskor dől el, hogy éppen milyen számlát kér.
pl. Mindig postázva volt, de most eljön személyesen. (ezt nem szeretem, mert a felhasználónak kell dönteni. Jobban szerettem, ha előre beállítható, de hát van ilyen eset is.)