invoiceDeliveryPeriod

[FerencKrisztina]

Sziasztok!

Egy kis vitába keveredtem a Fejlesztőnkkel, kérlek, segítsetek, kinek van igaza. :-)

Számláink jelentős része gyűjtőszámla (ÁFA-törvény 164.§). Egy adott gyűjtőszámla szállítólevelekből készül, mely szállítólevelek mögött önálló, független teljesítések vannak, tehát nem folyamatos, nem időszakos teljesítésről beszélünk, nem ÁFA-törvény 58.§. Fejlesztőnk a gyűjtőszámla alapját képező legrégebbi, illetve legújabb szállítólevél dátumával beteszi XML-be az invoiceDeliveryPeriodStart, illetve invoiceDeliveryPeriodEnd elemeket.

Véleményem szerint ez hiba (illetve valótlan adat), Őszerinte nem. Szerintem, ha ez a két elem bekerül, akkor egyértelmű, hogy adott számla időszakos teljesítésű, azaz ÁFA-törvény 58.§, tehát periodicalSettlement=true.

Mert ugye a periodicalSettlement=true az egyértelműen ÁFA-törvény 58.§? (Amúgy a periodicalSettlement elemet nem teszi be Fejlesztőnk az XML-be.)

Kinek van igaza?

Tudom, nem tehetitek kötelezővé ezeket az elemeket, de abban az esetben, ha nekem van igazam, (és mindhárom elem kizárólag ÁFA-törvény 58.§,) arra sincs lehetőség, hogy invoiceDeliveryPeriodStart, illetve invoiceDeliveryPeriodEnd csak periodicalSettlement=true esetén kerülhessen be?

Köszönöm!

[Macskafarka]

Kedves @FerencKrisztina! Szerintem Neked van igazad, és nagyon jól le is vezetted ezt. Egzaktan ugyan nincs kimondva a jogszabályban az, hogy egymást kizárja a gyűjtőszámla és a határozott időszakonkénti elszámolás, de több jelből is erre lehet következtetni. Az áfa tv. 58.§ (1) bek.-ben szereplő időszaki elszámolás a "teljesítés" napját határozza meg a felek megállapodása alapján. Ugyanakkor a gyűjtőszámlának épp az a lényege, hogy minden egyes tételsora mögött önálló gazdasági esemény található, amit az általad jelzett szállítólevelek támasztanak alá. Következésképpen minden tételsornak önálló teljesítési dátuma (és ezáltal önálló árfolyama) van. A gyűjtőszámla számlafejében szereplő teljesítési dátum mezőbe a tételsorokban szereplő teljesítési dátumok közül a legnagyobb kell bekerüljön, ez törvényi előírás. Ez az előírás ellentmond az időszaki elszámolás teljesítési dátumának, ebből következik, hogy egymást kizáró dolgok.

[FerencKrisztina]

Szia @Macskafarka! Köszönöm a megerősítésed!

Bocs, de ebben vitatkoznék Veled, ezt írod: „A gyűjtőszámla számlafejében szereplő teljesítési dátum mezőbe a tételsorokban szereplő teljesítési dátumok közül a legnagyobb kell bekerüljön, ez törvényi előírás.” Szerintem ez nem törvényi előírás, csak egy technikai lépés. Jogszabályilag a gyűjtőszámla fejében nincs teljesítési időpont (pl. NAV 18-as információs füzet): „….A gyűjtőszámla tekintetében nem értelmezhető teljesítési időpont, csak a gyűjtőszámlán szerepeltetett egyes ügyleteknek van teljesítési időpontja. A gyűjtőszámlán az egyes ügyletek teljesítési időpontja mindig szerepeltetendő….”

Ami engem "kissé" zavar, hogy a NAV által adott mindkét gyűjtőszámlás példában (Gyujtoszamla 1.xml, és Gyujtoszamla 2.xml) benne vannak a szóbanforgó elemek: „….

<invoiceCategory>AGGREGATE</invoiceCategory>
<invoiceDeliveryDate>2021-05-13</invoiceDeliveryDate>
<invoiceDeliveryPeriodStart>2021-05 02</invoiceDeliveryPeriodStart>
<invoiceDeliveryPeriodEnd>2021-05-13</invoiceDeliveryPeriodEnd>
<periodicalSettlement>true</periodicalSettlement>

….”

[Macskafarka]

Szia @FerencKrisztina! Persze, lehet a Teljesítési dátumot pusztán technikainak tekinteni, mivel nincs benne az Áfa tv. 169.§-ban a számla kötelező elemei között, hanem csak speciális esetben kell szerepeltetni. Azonban már régen nem a törvények számítanak a számla kibocsátásakor, hanem a NAVOnline adat éhsége! Próbálj meg gyűjtőszámlát átadni a számlafejben lévő teljesítési dátum nélkül. Ha meg a NAVOnline-nak kell a teljesítési dátum, azt én mindenképpen megjeleníteném a számlaképen is. Ezért jutottam el oda, hogy kell a számlafejben a teljesítési dátum is gyűjtőszámlán. A NAV példái szerintem sántítanak, mert ha az időszaki számlázásra való megállapodás számítana, akkor az az egyes elkülönült ügyletekre is értelmezhető lenne, amelyek a gyűjtőszámla tételsoraiban találhatók, Vagyis tételsor "Line" adatnak kellene lennie a "DeliveryPeriodStart" és a "DeliveryPeriodEnd" elemeknek gyűjtőszámla esetén. Ez belefér magába a törvénybe, csak nem adható át így a NAVOnline rendszernek. Nem vitatom azt, hogy normál számla esetén a fenti mezők számlafej szintűek kell legyenek, ahogy most is elvárják.

[kabelnet2]

Volt egy levelezésem a témában még 2018 májusában: "Az adatszolgáltatást leíró xsd-ben szolgáltatás esetén a szolgáltatás kezdő és végdátuma (invoiceDeliveryPeriodStart - End) számla szinten adható meg. Gyűjtőszámla esetén viszont ezek az adatok az egyes tételekhez tartoznak: pl. több autóhoz vásárolnak egy éves garancia kiterjesztést, akkor azok kezdő dátuma az adott autó garanciájának lejárati dátumától függ. Ez mindig, minden tételnél más." Válasz: "Köszönjük a jelzést. Rövid távon (júliusig) biztosan nem várható ilyen változtatás, azt követően fontolóra vesszük." Ennyiben maradtunk, additianalLineData-ban adom meg az adatokat azóta is.

[nbeeps2]

És mi van akkor, ha én, mint számlakiállító user a "SIMA" számlát állítok ki és a számla sorokhoz tartozó tételes megjegyzésben írom a teljesítés dátumát (szabad szöveges megadás). Ha a számlaképet nézzük úgy fog kinézni, mint egy gyűjtőszámla, de a NAV-hoz, mint "SIMA" számlaként fog bekerülni... A számlakiállító helyesen járt el, mert előállított egy minden tekintetben kifogásolhatatlan számlát. A vevő az egészből nem vesz észre semmit, mert a számlakép alapján pont úgy néz ki majd, mint egy gyűjtőszámla, sőt a kiállító még a gyűjtőszámla fogalmát is használhatja a számla megjegyzésében... A számlázó program is helyesen jár el, hiszen nem tudja érzékelni, ki mit ír egy szabad szöveges megjegyzésben és "SIMA" számlaként adja fel a számlát. Ilyenkor mi a helyzet? Hol okozhat ez problémát és kinek?

[Macskafarka]

@nbeeps2 kérdésednek a lényege, hogy okoz-e gondot az, ha gyűjtőszámla helyett normál számlát állítasz ki.

1. A gyűjtőszámla kiállítása nem kötelező, hanem csak lehetőség. Helyette minden "számlakibocsátásra jogalapot teremtő ügyletet"-ről elkülönült számlával is megoldható. Vagyis minden teljesítési napra vonatkozóan külön számlát készítesz.
2. Ha mégis egy normál számlán (nem AGGEGATE) szerepeltetsz különböző teljesítési dátumú ügyeteket, az helytelen. Egyrészt a számlát a teljesítéstől számítva X napon belül kell kibocsátani, tehát a vevő megtagadhatja erre hivatkozva a befogadását. Másrészt a számla egy polgárjogi aktus is, és ha több ügylet szerepel rajta, akkor a vevő az egész számlát visszautasíthatja, ha az azon szereplő valamelyik ügylettel nem ért egyet.
3. Az általad jelzett számlázási mód beleütközik az ÁFA tb. 164.§-ába, mert a jogszabály alapján ha egy számlát "ugyanannak a személynek, szervezetnek több, számlakibocsátásra jogalapot teremtő ügyletet" szerepel akkor azt gyűjtőszámlaként kell kezelni. A leírt módszert nem használnám, de ez nyilván függ a számlakiállító adóalany kockázatvállaló képességétől, valamint a lebukás veszélyétől, a büntetés várható összegétől, továbbá a az adott vállalkozás jogérvényesítő képességétől és lobbi erejétől stb.

[FerencKrisztina]

Szia @nbeeps2 ! Én biztosan nem használnék egy ilyen számlázó programot. :-) Ha csak arra gondolok, így semmi lehetőség listák, kimutatások készítésére, hogy az ÁFA-bevalláshoz szükséges infókról ne is beszéljünk.... Megjegyzésből például hogy szűrsz teljesítés dátumra? Kiteszed Excelbe, és kibogarászod? :-)

[nbeeps2]

@Macskafarka nem, igazából nem ez lett volna a kérdésem lényege. A kérdésem lényege az volt, hogy a fenti módon a számlázó programmal úgy állítok ki gyűjtőszámlát, ami tartalmi és külalaki tekintetben is minden tekintetben úgy néz ki, mint a gyűjtő számla, tegyük fel a dátumok is rendben vannak, viszont a számlázó program NEM TUD RÓLA, hogy ez éppen egy gyűjtőszámla és sima számlaként adja fel a NAV-nak.

[nbeeps2]

@FerencKrisztina A te általad használt/fejlesztett programmal is ki tudnék állítani ilyen számlát... A kérdésem tehát nem arra vonatkozik, hogy én így akarnám megoldani a programban a gyűjtőszámlázást, hanem, hogy mi a helyzet ezzel, ha valaki úgy állít ki gyűjtőszámlát a programmal, hogy a számlázó program nem tud róla. Megtiltani nem tudod, a kiállító helyesen jár el és a program is helyesen jár el, amikor sima számlaként adja fel, hiszen nem ember, hogy felismerje, hogy ez egy gyűjtőszámla...

[Macskafarka]

Igaza van @nbeeps2 -nek. Olyan számlát szinte bármilyen számlázóval ki lehetne állítani. Amúgy simán lehet olyan számlázót használni, amely képtelen gyűjtőszámlát kezelni, mert gyűjtőszámla egyszerűen kiváltható normál számlával is. Ahogyan az egyszerűsített számla helyett is lehet normál számlát készíteni. Nem a számlázó program felelőssége az, ha a felhasználó másra használja, mint amire való. Ebbe beleértem az @nbeeps2 által leírt esetet is, hogy normál számlába "betuszkolja" azt, amit gyűjtőszámlaként kell kezelni. Amelyik számlázó program nem tud gyűjtőszámlát készíteni, az írja le a felhasználói doksijába, hogy NORMÁL számlaként kerül minden beküldésre, ezzel le van fedve a felhasználója felé jogilag.

[FerencKrisztina]

@nbeeps2 , @Macskafarka Annak ellenére, hogy a NAV az XML-be technikailag kéri, a gyűjtőszámlának nincs önálló teljesítés dátuma, tehát az a fejben üres. Így amennyiben adott programban nem kötelező a teljesítés dátum (tehát pl. nem tölti alapból a kiállítás dátummal), akkor igen, igazatok van, bele tudja tuszkolni normál számlába a gyűjtőszámlát.

[NTCA-tax]

A dokumentáció 101. oldalán éppen ez szerepel:

"Gyűjtőszámla (invoiceCategory=AGGREGATE) esetén az egyes tételekhez tartozó teljesítési dátumok a tételeknél szerepelnek. Technikailag gyűjtőszámla esetén is meg kell adni a számla teljesítési dátumát (invoiceDeliveryDate), ami gyűjtőszámla esetén az egyes tételekhez tartozó teljesítési dátumok (lineDeliveryDate) közül a legnagyobb (legkésőbbi)."

A gyűjtőszámlának nincs önálló teljesítési dátuma, azonban egy technikai teljesítési dátumnak az adatszolgáltatásban szerepelnie kell az invoiceDeliveryDate mezőben. Ez az adat a számlán nem szerepelhet, ez csupán adatszolgáltatás technikai adat.

[kabelnet2]

@NTCA-tax : kérlek azt is írd le, hogy mi a jelentése a deliveryPeriod-nak gyűjtőszámla esetén, számla szinten, mert valahonnan innen indult az egész issue..

[FerencKrisztina]

@NTCA-tax , köszi szépen, de a teljesítés dátum szerintem egyértelmű. Kérlek, az én eredeti, kiinduló kérdésemre válaszolj, ahogy @kabelnet2 is írja. Köszönöm!

[NTCA-tax]

Amennyiben a számlán van teljesítési időszak, akkor azt lehet az invoiceDeliveryStart és invoiceDeliveryEnd dátumként feltüntetni. Amennyiben tehát a gyűjtőszámlán fel van tüntetve ilyen időszak, akkor itt lehet, de nem kötelező feltüntetni. Amennyiben a gyűjtőszámlán nincs ilyen időszak feltüntetve, akkor az adatszolgáltatásban nem szabad elhelyezni. Fontos különbség a gyűjtőszámla teljesítési dátumával szemben, hogy a teljesítési időszaknak számlaadatnak kell lennie, míg addig a teljesítési dátum egy számlán fel nem tüntetett adat (tehát adatszolgáltatás technikai adat).

A teljesítési időszaknak akár gyűjtőszámlán is lehet helye, ugyanakkor adózás szempontjából a folyamatosan nyújtott szolgáltatások esetén fontosabb, mivel ott a teljesítési időpont kalkulációban fontos szerepe van a teljesítési időszak utolsó napjának.

[NTCA-tax]

Még egy apró kiegészítés:

Attól, hogy az invoiceDeliveryStart és invoiceDeliveryEnd elemek kitöltöttek, attól nem jelenti azt, hogy az periodicalStatment-nek true-nak kell lennie. Ezek a mezők egymástól függetlenek.

[kabelnet2]

@NTCA-tax: Köszönöm a választ, de úgy érzem, még nem teljes. Én arra szeretnék választ kapni, hogy mire gondolt a NAV, amikor gyűjtőszámla fejlécébe betette a teljesítés kezdetét és végét? Milyen adatot gondolt elhelyezni ebben? A gyűjtőszámla attól gyűjtőszámla, hogy különböző ügyletek adatait tartalmazza. Egy ilyen számlán (nálunk) minden egyes sornak van teljesítési időszaka, amely azonban minden sorban más és más, mert az egyedi paraméterektől függ. Ezek az adatok (mi a szolgáltatás, egyedi azonosító, tól-ig) minden sorban szerepel a számlán, erre szüksége van a vevő könyvelésének és dokumentációs okból is. De ebből nem lehet egyet kiemelni és a számla fejlécébe írni, mint a teljesítési dátumnál a legnagyobbat, mert annak nem lenne semmi értelme. Azt V1 óta tudjuk, hogy nem kötelező kitölteni a teljesítési időszakot az adatszolgáltatásban, mi egyéb adatként adjuk meg soronként a teljesítési időszakot. Csak minek van ott az a paraméter a fejlécben? (És miért nem a sorokban, ha a NAV-nak is fontos) Ezt 2018 óta szeretném megtudni.

[FerencKrisztina]

@NTCA-tax , köszönöm válaszod, de ebben az esetben véleményem szerint mindkét Általatok adott példaszámla (Gyujtoszamla 1.xml, és Gyujtoszamla 2.xml) szabálytalan. Részben azért, mert a számlákon nem szerepel időszak, az adatszolgáltatásban mégis elhelyeztétek az invoiceDeliveryStart és invoiceDeliveryEnd elemeket, részben pedig azért, mert periodicalStatment mindkét számlánál true, így a teljesítés dátum valamennyi számlatétel esetén hibás, mivel nem az ÁFA-törvény 58.§ alapján van meghatározva, és ugye időszak sem szerepel a számlán, mely alapján a helyes teljesítés dátum meghatározható lenne. Számomra alapból necces a folyamatos teljesítésű gyűjtőszámla....

[nbeeps2]

Elnézést, de ez most nem lesz túl konstruktív hozzászólás, de szerintem ez az egész gyűjtőszámlás dolog egy felesleges bonyolítás, én kompletten megszüntetném, mint fogalmat és technikai megoldást. Ha valaki valamit elvégzett számlázza ki és ennyi, minek ezt így görgetni, hogy mindenkinek komplikáltabb legyen az élete? Senki nem hal bele, ha 1 számla helyett lesz 4 számla, na bumm. Mindkét félnek (kiállító és vevő) is csak nehezíti az áttekintést.

[kabelnet2]

Ez mindig a körülményektől, forgalomtól függ függ. Nálunk az arány 1 helyett néhány 100, ami már nem mindegy. Arról nem beszélve, hogy pénzügyileg is egyszerűbb egy átutalást ellenőrizni, mint több száz kifizetését. A módosító gyűjtőszámláról már ne is beszéljünk, amikor egy negyedév összes számláját módosítjuk. De nem kötelező használni, dönthetsz úgy, hogy te nem használod.