Online-invoice: Érvénytelenítő számla 0%-os áfakulcs

[sinick2]

Az igény összefoglalása / Summary of the request

1. évben közösségi vevőnek készült egy közösségi értékesítésről szóló teljes adattartalmú számla 0%-os áfakulccsal. Adatszolgáltatásba a számlát nem kellett még beküldeni, így nem is lett beküldve. 2021. évben a számla érvénytelenítésre került. Ezt már be kell küldeni adatszolgáltatásba. Az adatszolgáltatás elutasításra került "A számlában megadott áfakulcs vagy áfaérték nem engedélyezett (érték=0.0000)" hibával, mivel a vatPercentage nem tartalmazhat nulla értéket.

Az általam javasolt megoldás / The solution I propose
Hasonlóan az áfamentes és áfakörön kívüli kulcsok kezeléséhez 2021 év előtt készült alapszámla érvényteleníthető legyen az eredeti adattartalommal, azaz 0%-os áfakulccsal.

[nbeeps2]

A 2021-es számla (program) esetén már ismerned kéne a 0%-os ÁFA kulcs adómentességi okát, ami valahol az ÁFA kulcshoz (pl. törzsben) a felhasználó által meg van adva. Stornó számla esetén vehetnéd onnan az adatot és akkor tudod küldeni a vatPercentage helyett.

[sinick2]

Ezzel két problémám van.
1) Nem tudom, hogy mentes vagy áfakörön kívüli az a 0%.
2) Online Számla specifikációban nincs ilyen esetre eljárás, amire hivatkozni lehet.

[nbeeps2]

@sinick2 : Nem neked kell tudnod, a felhasználó hozzá kellett valamit rendeljen ehhez az ÁFA kulcshoz a 2021-es programverziódban.

[sinick2]

Szerintem ezt utólag nem szabad. Ha így lenne, akkor mentes/ákk esetén nem kellene az unknown jelölés, mert ott is lehetne utólag hozzárendelni.

[nbeeps2]

Nem a 2020-as számlára gondolok, hanem amit most akar kiállítani stornót az ügyfél! Én nem engedném addig stornózni (tehát új számlát kiállítani), ameddig a 0-ás ÁFA kulcsokhoz nem rendelt adómentességi okot.

[sinick2]

Mindegy, hogy 2020 vagy 2021, akkor is utólag rendeled hozzá. Ilyen alapon az unknown sem kellene, mert lehet hozzárendelni. Ennek tipikus esete a korábbi THK. Gondolom azt sem rendelgetik most, hanem az érvénytelenítőjét beküldik unknow-nal. Nyilván megállapítható lenne a mentesség/áfa körön kívüliség oka módosító számla esetén is, viszont ezt a NAV nem kényszerítette ki valamiért, hanem helyette bevezették az unknown tagot.

Ugyanez kéne arra, hogy ha 2020-ban 2.0 a vatPercentage hibás (ráadásul a számla nincs is beküldve), akkor 2.0-ra hivatkozó módosító számlán 3.0-ban vatPercentage lehessen az eredeti.

[nbeeps2]

Nem vagyok benne biztos, de szerintem a 2.0-ban sem lehetett a vatPercentage 0.

[sinick2]

Nem, nem lehetett, de mint írtam, az alapszámla nem volt jelentésköteles, mert közösségi számla, így nem is lett beküldve.

[Macskafarka]

@sinick2 -nek az okoz gondot, hogy azért nem jó ötlet az áfa kulcshoz való fix "adómentességi ok" rendelés, mert lehet, hogy korábban a 0%-ot többféle adómentességi ok esetén is használták. Nem volt jó akkor sem, de senki nem vette észre, és mivel nem is kerültek a NAV felé feladásra, ezért ott sem tüttyent ki. Azt hiszem erre a stornó/érvénytelenítő/helyesbítő esetre van a vatExemption/case UNKNOWN. v3.0 speci 119-120. oldala

[sinick2]

Csak az a baj, hogy vatOutOfScope-ra meg vatAmountMismatch-ra is van. Ebből az következik, hogy a NAV szándéka szerint mindegyiket a helyén kell kezelni. Eddig 2.0 vatOutOfScope="true" volt akkor 3.0 érvénytelenítve vatOutOfScope="unknown", vagy eddig 2.0 vatExemption="THK" vagy egyszerűen csak "adómentes" vagy "kiskutyafüle" volt akkor 3.0 érvénytelenítve vatExemption="unknown". Ebből legalább az tudható, hogy áfa jellege, azaz mentesség vagy áfa körön kívüliség szerint legalább minden a helyén maradt és nullára kiütötte egymást. De ha a vatPercentage-t elkezdjük keresztbe-kasul sorolgatni mentesnek vagy áfa körön kívülinek, holott az alapszámla egyenes áfás csak nullás, abból nem tudom mi lesz. (Szerk.: 2.0-ban a különbözetisek sem voltak kódolva, csak logikai adat volt, ráadásul kétféle, 3.0-ba érvénytelenítve abból is gond lehet.)

[Macskafarka]

Értem. Akkor erre az NTCA-tól kell a megoldás

[DrotosTot]

Mi arra jutottunk, hogy a mostani érvénytelenítő számlán megadott áfa mentességi kód az alapszámlára is érvényes (hiszen azt érvényteleníti) kell legyen.
Így, ha egy, @sinick2 által vázolt számlát akar érvényteleníteni az ügyfél, a 3.0-s sémához hiányzó adatokat pótolnia kell.
Emellett egyetértek azzal, hogy rendezni kellene ennek az egyértelmű szabályozását is.

[sinick2]

Tisztelt NTCA-tax! Mikor várható tájékoztatás a nyitó hozzászólásban leírt problémával és javaslattal kapcsolatban? Köszönöm.

[NTCA-tax]

Amennyiben nulla százalékkal lett kiállítva az érvénytelenítő számla, akkor adatszolgáltatásban nem húzogathatod, hogy a felhasználó mire gondolhatott. Adatszolgáltatásnál nem kellene a számla adattartalmát átírnod, tehát a programod 0%-os adókulcsot fog ebben az esetben szerepeltetni. Erre előre tudhatóan error lesz az Online Számla válasza, mert az adatszolgáltatás nem dolgozható fel. Ennek ellenére neki kell futnia a programnak, tehát nem válogathat a program úgy, hogy ha már előre ismerten error, akkor nem küldi meg az adatszolgáltatást. Ez az érvénytelenítő számla tehát technikailag nem feldolgozható adatszolgáltatású számla lesz, de ez még nem jelenti azt, hogy az adatszolgáltatását keresnénk.

Alapvetően az a probléma, hogy az eredeti számla is hibás adattartalmú. Nem attól hibás, mert az adatszolgáltató rendszer nem fogadja el, hanem attól, hogy az áfa törvény nem ismer 0%-os adókulcsot és nem is volt létező adókulcs a számla kiállításakor sem. Amikor az adatszolgáltatás feldolgozása során láttuk a tömérdek 0%-os adókulcsot, akkor kényszerítettük ki, hogy legalább ne szemeteljék össze a rendszert ezek a számlák, az adózók pedig szép lassan leszoktak a belföldi ügyleteknél a 0% alkalmazásáról. Nagyjából ez várható a közösségi és export számlák esetén is. Bele fog telni némi időben, hogy ott is leszoknak arról, hogy 0%-kal állítanak ki számlákat...

[bakter80]

Hát mi ezt nem bonyolítottuk túl.
Amelyik számla eddig nem ment be, az már nem is fog.
A módosítója modifyWithoutMaster = true.
Az UNKNOWN-oknak az az egyetlen értelme, hogy nem tudod besorolni, de mégis fel tudod küldeni a módosítót.
Annak mondjuk semmi értelme, hogy 3 helyre is be lehet írni, ezért fogtuk az elsőt (vatExemption), és az lett UNKNOWN.
Ha ez így nem jó, akkor az egész UNKNOWN-osdi tökéletesen felesleges volt.
És senki ne jöjjön azzal, hogy az ÁFA törvény nem ismeri a 0%-os kulcsot, mert az ÁFA törvény az UNKNOWN-t se ismeri.
Mivel az alapszámlának nem kell bemennie, és a sztornó meg a módosító se különbözik ÁFA törvényileg, nem kell a sztornónak ugyanolyan rossznak lennie, mint az alapszámlának.

Én NTCA-tax válaszában azt nem értem, hogyha az adatszoláltatás úgyis UNKNOWN, akkor, miért nem lehet 0%-os kulcs a háttérben, vagy akkor ez azt jelentené, hogy azt kell írni a számlára, hogy UNKNOWN%? Vagy mégis hogyan egyezne ilyenkor a számla adattartalma az adatszolgáltatás adattartalmával?
Mi értelme az egész UNKNOWN-nak, ha ezt nem lehet megtenni?

És eszembe jutott valami, ami lehet, hogy hiba:
Amikor próbálgattam a sok ismeretlent, akkor csináltam egy olyan számlát, ahol különböző nem besorolható mentességeket sztornóztam.
A CASE elemben ugye mindenütt UNKNOWN volt, de ha a REASON elemben nem egyforma értékeket adtam, akkor az összesítő hibát dobott, mert több UNKNOWN csomópont volt a summaryByVatRate-ben, hiába volt más a REASON.
A megoldás az lett, hogy UKNOWN CASE és UNKNOWN REASON.

[omachtandras]

Mi is arra jutottunk, amire @bakter80-ék.
Reményeink szerint hamarosan kifutnak a <3.0 bizonylatokkal kapcsolatos változások és ezzel együtt a problémakör is.

[NTCA-tax]

Az UNKNOWN értéken én is gondolkoztam, de azért vetettem el, mert ha 0%-os az adókulcs, akkor a számlán nem túl valószínű, hogy szerepel mentességi vagy hatályon kívüliségi hivatkozás. Ráadásul azt sem lehet pontosan tudni, hogy adómentes vagy hatályon kívüli ügyletről történt a számla kiállításra, tehát ez is egy bizonytalansági tényező.

Technikailag persze járható, hogy ráböksz arra, hogy adómentes, beküldöd UNKNOWN case és reason értékkel, de ekkor az adatszolgáltatásnál módosítottál a számla adattartalmán. A számlán nincs rajta, hogy adómentes, nincs rajta mentességi ok megjelölés sem. Ennél jóval tisztább, hogy ERROR-al bukik az adatszolgáltatás, a felhasználó pedig tudja ennek az okát.

Az UNKNOWN értéket azért vezettük be, hogy ha a számla a jogszabályoknak megfelelően lett kiállítva, de nem 3.0-ban történt az adatszolgáltatás, akkor egy szöveges tartalomból nehezen lehet a case értéket visszavezetni.

@omachtandras véleményével egyetértek, ki fognak futni ezek a számlák és ezzel ezek a problémák is.

[Macskafarka]

@NTCA-tax Lehet., hogy abból a székből, ahol Te vagy, tisztább az ERROR, de egy számlázó program kidolgozója mindenáron el akarja kerülni az ERROR-t.
Egyszerűen nem a mi dolgunk az ügyfelek felé azt mondani, hogy ne pánikoljon, nem a program hibája, hanem a NAV-nak így lesz "tiszta".

[NTCA-tax]

@Macskafarka csak ebből a székből végzünk ellenőrzéseket, és azt kell például megítélnünk, hogy az adatszolgáltatás a számla adatait tartalmazza-e. Amennyiben egyértelműen látszik, hogy nem, akkor az adatszolgáltatás nem megfelelő, annak minden következményeivel együtt.

[bakter80]

aha, és ha szövegesen van rá írva, hogy nulla százalék, akkor már lehet UNKNOWN?
meg hát mindenképpen módosítottál a számla adattartalmán, ha így nézzük.már PIECE-szel is.
azt hittem ezeken a hülyeségeken már túlvagyunk.
erre pont a nav kezdi...
gyakorlatilag feleslegesen csináltátok az unknown-t.
egy szövegről szegény program nem tudja megállapítani az adómentességet, de azt majd meg fogja tudni, hogy melyik unknown ág, meg hogy törvényesen volt e kiállítva az eredeti számla, és majd inkább úgy dönt, hogy dobat egy errort a navval?
komoly?

[bakter80]

már fenyegetőzünk virág elvtárs?
erről jut eszembe:

• te miért vagy börtönben?
• közérdekű adatigénylés taoról, ste?
• unknown használata számlázáskor

és ezentúl senki ne küldjön PIECE-t, mert lehet hogy adatbázis volt, vagy decibel?

[RvPSc]

Nézzük más szemszögből a dolgot. Mi a sztornó? Érvénytelenítő okirat, amelynek a tartalma megegyezik az eredetiével. Ha én 1234 adószámot adtam meg rajta, akkor az nem megfelelő, le kell sztornóznom. De a sztornón nem adhatok meg 12345678 adószámot, hiszen akkor eltérne az eredetitől. Ez teljesen ekvivalens eset az áfakulccsal.

Ez megint egy tátongó lyuk a rendszeren, amit nem ismertek el, a számlázó szoftver fejlesztőket, vagyis a konkurenciát a végletekig leterhelitek vele. Nem lehet egyébként ezzel a temérdek hibával akár a GVH-hoz fordulni? Ugyanis a NAV is számlázó szoftver fejlesztő és gyakorlatilag ahhoz igazítja a rendszer működését, amit kvázi kényelmesebb lefejleszteniük.

[bakter80]

csinálni kell egy alapítványt, összedobni a pénzt, és mindenért elmenni strasbourgig.

[RvPSc]

Szerintem ebben nem csak a fejlesztő cégek, hanem lassan a könyvelők, de most már a végfelhasználók is benne lennének (lásd: eddig a vállalkozó végezte a saját munkáját, majd számlázott, amellyel kvázi benyelte a plusz adminisztrációs költségeket. Ezután jött a könyvelő, aki rászólt, hogy ez így nem lesz jó... Most gyakorlatilag adóügyi továbbképzésekre járhat, hogy ugyanmár hogy is kellene kiállítania a számlát. Kössék akkor jogszabályhoz, hogy gazdasági végzettség kell a számlakiállítási képességhez. Ilyen elvárások mellett ez lenne tiszta)

[renced42]

Nézzük más szemszögből a dolgot. Mi a sztornó? Érvénytelenítő okirat, amelynek a tartalma megegyezik az eredetiével. Ha én 1234 adószámot adtam meg rajta, akkor az nem megfelelő, le kell sztornóznom.

Kedves @RvPSc sajnos itt kezdődnek a problémák.
Ebben az esetben ugyanis neked nem stornózni kell, hanem módosítani, mert a gazdasági esemény megtörtént azt nem semmissé akarod tenni, hanem csak egy adatot szeretnél javítani.
A stornó számla pedig nem ugyanolyan adattartalmú, mivel eleve a tételeket is negatív előjellel kell ellátni.

[Macskafarka]

GVH-hoz fölösleges fordulni. Bírósághoz szintén fölösleges, mert a jogászok alapból félnek gazdasági kérdésekben önállóan állást foglalni, a bírók ezért inkább szakértőt kérnek a felperes költségén. Az a szakértő valszeg amúgy adóalany valahol. és nem nagyon akar ellenkezni a NAV álláspontjával. Ha mégis, akkor a NAV -nak joga van ellenszakértőt felkérni. Ha a NAV által hozott szakértő mégis a NAV ellen foglalt állást, akkor egy újabb szakértő kell. És akkor még csak első fokon vagyunk. Másodfokon ugyanezt el lehet játszani. Aztán jöhet a Kúria, ahol név szerint lehet tudni a tanács tagjait, kikhez kerülhet. Ha ott bukta, akkor lehet menni az AB-hez, amelynek nincs határideje a döntés meghozatalára. Ha mégis dönt, és elveszted, akkor, de csak akkor lehet menni Strasbourgba, ahol megint nincs határidőhöz kötve a döntés. Ha ott mégis nyersz (van hivatalos magyar kormánydelegált ott is), addigra a jogszabályt megváltoztatják akként, hogy a számodra esetleges pozitív döntéssel se tudj nagyon mit kezdeni.
Közben eltelt X év. és belekerült Y millió Ft-ba.

[Macskafarka]

Piszkosul ki van ez találva.....

[RvPSc]

Kedves @RvPSc sajnos itt kezdődnek a problémák.
Ebben az esetben ugyanis neked nem stornózni kell, hanem módosítani, mert a gazdasági esemény megtörtént azt nem semmissé akarod tenni, hanem csak egy adatot szeretnél javítani.
A stornó számla pedig nem ugyanolyan adattartalmú, mivel eleve a tételeket is negatív előjellel kell ellátni.

Látom sikerült megfogni a lényeget...

1. Akkor sztornózok, amikor akarok. Nem biztos, hogy megtörtént a gazdasági esemény. A lényeg, hogy az adószám nem változhat sztornózással, ahogy az áfa kulcs sem.
2. A fenti hibával kapcsolatban írtam, ahol is a sztornózásról volt szó. Bármit hozhattam volna példaként, de akkor vegyük az Ön által említett példát. Ha negatív előjellel küldöm 0%-kal, akkor be fogja fogadni a rendszer? A sztornózás csak nem módosíthat áfa kulcsot....

[RvPSc]

Piszkosul ki van ez találva.....

Igen, sajnos tudom, ez a rezsim lényege. És ők is nagyon jól tisztában vannak azzal, hogy megtehetnek bármit.

[jozanesz]

neked nem stornózni kell, hanem módosítani, mert a gazdasági esemény megtörtént azt nem semmissé akarod tenni, hanem csak egy adatot szeretnél javítani

Ez érdekes filozófia kérdés. Ha a kedves ügyintéző elírta a vevőt is és a számlatételeket is, akkor is megtörtént a gazdasági esemény, csak nem azzal és nem úgy? Fura.

És javított adószám esetén mind az eredetileg feltüntetett adószámú vevő, mind az újonnan feltüntetett letöltheti a számlát módosító okiratotokkal együtt? Vagy amint módosítva lett az adószám, onnantól az eredetileg megjelölt adószámú vevő már nem fér az adatokhoz, de az új le tudja kérdezni az eredeti számlát is? Vagy egyéb?

[topybear]

Srácok! Nekieshettek a NAV-os kollégáknak, de azért lássuk be, annak a bizonyos szerszámnak ők is a rosszabbik végén vannak. A törvényalkotó teremtett egy környezetet, melynek ők is, mi is próbálunk megfelelni. Annyi előnyük van talán (bár ugyanakkor ez nehézség is), hogy a törvény értelmezésében nyilvánvalóan a NAV álláspontja a mérvadó. És azt látom is, hogy ez nem önkényes, a vitás esetekben igyekeznek elmagyarázni a gondolatmenetet is, hogy hogyan jutottak el a törvény betűjétől a gyakorlati alkalmazásig.
Lehet ezzel egyetérteni vagy sem, de a törvényi környezetet akkor sem ők alkották, szerintem nem kellene őket rugdalni azért, ha valami nem tetszik. Pláne, hogy szerintem nagyon segítőkészek - sőt ezen felül sokszor olyasminek is utánamennek, amit simán elpasszolhatnának -, igyekeznek párbeszédi alapon kezelni a fejlesztéseket, nem hatóságként. Maximális respect részemről!

PS: A teljes NAV-ot illetően meg az a személyes tapasztalatom, hogy míg régen hideglelése volt az embernek, ha meghallotta az adóhatóság szót, az utóbbi években sokat változott az egész: segítőkészek, nem büntetnek rögtön midenért, ha valamit elfelejt az ember, akkor nem "ötvenezerrel" kezdődik a mondat, hanem egy udvarias figyelmeztetéssel, hogy "úgy látjuk elfelejtette, kérem pótolja". Nagyon-nagyon más, mint mondjuk tíz éve...

[RvPSc]

Ne kezdjük már ezt a "védjük meg a navos-t" dumát... Lássák el a feladatukat normálisan. Adjanak egy olyan rendszert ami univerzális, minden esetre működik, ha már ők találták ki az egész rendszert. Ha valamire nincs megoldásuk, ne lekotorják a felhasználói, végfelhasználói szintre, hogy "majd oldja meg az, akit érdekel", hanem tüntessék el az anomáliákat, mielőtt kijönnek a tervükkel.

PS: Az hogy a revizorokban van egy kis "nyugatiasodás" ne legyen már olyan nagy csoda... Ne aggódj, nem engedik el a büntetést, csak akkor, ha az ő rendszerükben van a hiba. Esetleg... Jujj de rendesek.

[Macskafarka]

A jelenlegi ÁFA tv.-t a maga teljességében lehetetlen algoritmizálni, lehetetlen egzaktul leprogramozni. Ráadásul ha változik a jogszabály, akkor gondolni kell a helyesbítésre, érvénytelenítésre.
Súlyos mulasztásban van a jogalkotó, ha olyan jogszabályt alkot, amit lehetetlen algoritmizálni.
Ugyanakkor a NAV-nak az a sara, hogy mivel neki már algoritmusokban kell gondolkodnia a számla adatszolgáltatás miatt, ezért neki kell KIHAJTANIA a jogalkotóból azt, hogy olyan jogszabályt alkosson, amelyet meg is lehet érteni, és lehet algoritmizálni.
Ha ez nincs, akkor meg kell tagadnia a végrehajtást, és nem tákolgatni és értelmezgetni, passzírozni az adóalanyokat.

[NTCA-tax]

Most tértem vissza átolvasni a bejegyzéseiteket ebben az issue-ban. Térjünk vissza szerintem az eredeti kérdésre, mert attól kezdtek eltávolodni.

Alapvetően az a problémátok, hogy van egy olyan érvénytelenítő számla, melynek az áfa kulcsa 0%. Nos ilyen számláról már 1.1 óta nem lehet érvényes adatszolgáltatást adni. Most ezt akarjátok úgy áttolni az adatszolgáltatási rendszeren, hogy elkerüljétek az ERROR-t, inkább módosítjátok adatszolgáltatásban a számla adattartalmát. Ez biztosan rossz irány, ráadásul még a jogszabályban lefektetett szankcionálási eset is. Ezt ne fenyegetésnek lássátok, hanem következménynek.

Amit Ti leírtatok, akkor annak alapján két szcenárió lehet:

• Módosítjátok az adatszolgáltatásban a számla adattartalmát, melyet ha az adóhivatal neheztel, akkor ezt majd valahogyan meg kell magyaráznotok az ügyfélnek.
• Bekülditek 0%-kal, és az ERROR miatt magyarázhattok az ügyfélnek.

Amennyiben van más ötletetek, akkor írjátok meg, de így átolvasva a hozzászólásaitokat nem látok.

Persze sok mindenkit lehet hibáztatni az ilyen számlák adatszolgáltatása miatt, viszont azt is látni kellene, hogy az áfa törvényben már nagyon régen nincs 0%-os adókulcs. Végső soron egy számla adattartalmi problémát, mint egy döglött ló próbáljátok meg átdobni a kerítésen. Miközben elfeledkeztek arról, hogy ez a ló már rég megdöglött, tehát bármit csinálunk, a lovat már nem fogjuk tudni megmenteni.

Ebben az esetben nem az érvénytelenítő számlával, hanem a számlával van a probléma. Attól kezdve, hogy annak áfa kulcsaként 0% került feltüntetésre már nem lehet technikailag helyes adatszolgáltatást adni sem a számláról, sem annak érvénytelenítésről. Ezt adóhivatali oldalon elfogadjuk, nem is akarunk 0%-os adókulcsú számlákkal foglalkozni. Ha a jogszabályoknak megfelelően készíti el a program az adatszolgáltatást, akkor az nem lesz feldolgozható. Ugyan ezt a kört lefutottuk az 1.1 esetében is, és kivesztek a 0%-os adókulcsú számlák belföldi adóalany vonatkozásában. Most ugyan ez fog bekövetkezni az újonnan bekerült számlakör esetén is.

[bakter80]

Nem változtatjuk meg a számla adattartalmát, hanem azt mondjuk, hogy UNKNOWN.
Ami arra van, hogy elvileg nem tudjuk megállapítani az eredeti számlából.
De általánosítsunk el egy kicsit a 0%-os kulcstól (mert gyakorlatilag az összes mentes és hatályon kívüli kulcs 0%-os lesz kb. mindenki adatbázisában kiegészítve NAV kóddal, mert az ÁFA törvénynek nincs hatalma az SQL vagy a matematika felett).
Szóval nem 0%-os kulcsunk van, hanem van a számlán kinyomtatva, vagy PDF-ben, vagy bárhogy egy tetszőleges szöveg az ÁFA mentességről.
Ebből nem tudjuk megállapítani, hogy milyen NAV-os kód kell.
Ezért UNKNOWN-t alkalmazunk.
Ezzel úgy járunk el, ahogy a NAV leírta a doksiban.
Nem értem mi a probléma ezzel.

[Macskafarka]

Az @NTCA-tax által jelzett két lehetőség igazából csak egy, mert az ERROR, az nem teljesített adatszolgáltatás, ami alapból büntit von maga után. Miközben a NAV-nál megjelenik információként, hogy ki, milyen számláról nem teljesítette az adatszolgáltatást.
Ugye épeszű ember ezt elkerüli.
Marad a számla adattartalmának módosítása. Indokolás: csak így lehet tejesíteni az adatszolgáltatási kötelezettséget, mert a NAV visszautasítja a számla tényleges tartalmának befogadását.
Bele kell tenni a számlázó programba egy ilyent: "Erről a számláról lehetetlen valós tartalmú adatszolgáltatást sikeren teljesíteni. Válasszon az alábbi lehetőségek közül:
1: Nem adjuk fel (ez nem teljesített adatszolgáltatás, amit szankció követhet -ezt nem javasoljuk)
2: Eredeti tartalom szerint adjuk fel, és a NAV vissza fogja utasítani (ez nem teljesített adatszolgáltatás, amit szankció követhet -ezt nem javasoljuk)
3: Úgy adjuk fel, hogy a NAV befogadja, de akkor az adattartalom hozzá lesz igazítva a sikeres beküldés lehetőségéhez (Ezt a NAV sem, és mi sem javasoljuk)
Kb ez a 3 db nem javasolt eset van.

[Macskafarka]

Ja, amúgy pedig elméletileg igenis lehet 0%-os áfakulcs. Volt 0% anno régen, ha azt az elévülési időn belül helyesbítették, akkor az elévülés újra indult, ahányszor helyesbítették. Tehát pusztán elméletileg lehet 0%-os kulcsú adatszolgáltatás.
Gyakorlatilag alig van persze erre esély.

[NTCA-tax]

@Macskafarka a 2. esetnél nincs szankció adatszolgáltatás elmulasztása miatt. Volt adatszolgáltatási kísérlet, de az az Online Számla működése miatt nem feldolgozható. A NAV mondja azt, hogy nem akar az adatszolgáltatási rendszerében látni 0%-os adókulcsot. De ha ez van a számlán, akkor nem fogsz mást adni, nem módosítod adatszolgáltatásban a számlaadatot. Amennyiben nagyon szankcionálni szeretnénk, akkor számla adattartalom miatt szankcionálhatunk, nem adatszolgáltatás miatt.

[omachtandras]

@NTCA-tax : és ilyen esetben mi a teendő? Semmi vagy pedig az ügyfélnek fel kell rögzítenie kézzel a webes felületre a számlát, mint nem teljesített gépi adatszolgáltatást?

Mi utóbbit javasoltuk pl. olyan esetben, amikor peres ügy végén kiállítottak egy számlát, aminek a teljesítési dátuma 2010. előtti volt és nem tudtuk interface-en átadni. De ha erre sincs szükség ilyenkor, az lenne a legjobb.

[sinick2]

@NTCA-tax

Először is köszönöm a tájékoztatást.

"Amennyiben van más ötletetek, akkor írjátok meg, de így átolvasva a hozzászólásaitokat nem látok."

Ötletem a nyitóban van. Be kell engedni 0-val, ha a 3.0-ás számla módosító (modify/strorno) számla és az előzmény nélküli, vagy előzménye 1.0-es vagy 1.1-es számla. Ld. unknown logika! Mindenki boldog lesz, mert az adózó nem kap errort és NAV sem fog error miatt számlát keresni. Több nullás alapszámla már úgysem nem lesz.

"2. Bekülditek 0%-kal, és az ERROR miatt magyarázhattok az ügyfélnek." és "a 2. esetnél nincs szankció adatszolgáltatás elmulasztása miatt. Volt adatszolgáltatási kísérlet, de az az Online Számla működése miatt nem feldolgozható."

Akkor ezt mondjuk az ügyfeleknek.

[NTCA-tax]

@sinick2 Igazad van, erre nem tértem ki. Az UNKNOWN logika akkor működhet, ha egyértelműen tudod, hogy a 0%-os kulcs egyébként például adómentes értékesítéshez tartozik. Erre azonban nem látok semmilyen garanciát, hacsak a programodban valahol ez az információ nincs eltárolva. Amennyiben lehet akár adómentes, akár hatályon kívüli is, akkor ez a logika nem lesz működőképes.

[bakter80]

Akkor gyakorlatilag az UNKNOWN úgy ahogy van használhatatlan.
Letiltom a sztornó funkció az olyan számláknál, ahol ez felmerül.
Marad a módosító, ahol kézzel be tudja állítani a konkrét kulcsot.

[NTCA-tax]

@bakter80 Ott van értelme, ahol a számlán szerepel az az infó, hogy adómentes, de nem tudod, miért és a felhasználó érvényteleníti ezt a számlát. Abban az esetben, amikor még csak azt sem tudod eldönteni, hogy adómentes vagy hatályon kívüli, ott tényleg nem fogod tudni használni az unknown értéket.

[bakter80]

értem, erre írtam, hogy gyakorlatilag használhatatlan.

[EPluribusUnum]

@NTCA-tax , nem kellene akkor az API-t bővíteni? Kellene lehetőség arra hogy egy ERROR-os számlát utólag megjelölhessünk hogy tudjuk hogy ERROR, de nem lesz rá soha annul és újra beküldés, mert a papír úgy készült el hogy nem lehet másképp beküldeni. A folyamat végállapot ne ERROR vagy WARN legyen mert ezektől a felhasználók rettegnek és generájlák a supportot a mi oldalunkon és a NAV oldalára is. Kellene kapni eszközt arra hogy jelezzék a NAV felé hogy igen, tudják hogy problémás, de nincs mit tenni, a @Macskafarka által említett 2. eset áll fent. A felhasználót is megnyugtatnál hogy jelzett a NAV-nak és NAv oldal is kapna egy újabb flaget szűrésre és nem ugrana árnyékra feleslegesen.

[Macskafarka]

Nagyon félre mentünk szerintem mindkét oldalon.
Bele sem merek gondolni, hogyha komolyan venném @NTCA-tax alábbi szavait:
"a 2. esetnél nincs szankció adatszolgáltatás elmulasztása miatt. Volt adatszolgáltatási kísérlet, de az az Online Számla működése miatt nem feldolgozható"
-akkor minden számlát ERROR-ra futtatnék, mert azt nem szankcionálják, de adatszolgáltatás teljesítésének minősül.
:D Azért megvárom, amíg a NAV honlapján hivatalosan is közzé teszik, hogy az ERROR az teljesített, szankciómentes adatszolgáltatás, nem kell vele tovább küzdeni.... :D

[bakter80]

Én a biztonság kedvéért megalkottam hónap hibaüzenetét:
0%-os ÁFA kulcsnak nincs NAV-kód megadva!
Tétel ID: 280313
A NAV hibájából ez a számla nem sztornózható (vagy módosítható) az ÁFA mentes, vagy hatályon kívüli kulcsok megadása nélkül!
Sorolja be a kulcsokat a számla módosításakor.

[EPluribusUnum]

@Macskafarka, ilyen hozzáállás nem megfelelő ha a szankcitól félnek és pont annak az elkerülése a cél, mert ellenőrzésnél a papír számlakép és xml nem egyezik és jön a bünti.

[jozanesz]

Volt adatszolgáltatási kísérlet, de az az Online Számla működése miatt nem feldolgozható

Pont olyan jó érv, mint hogy volt kísérlet, de a saját rendszerünk működése (pl. az OS-ével azonos! XSD-validáció) miatt nem feldolgozható. Ahogy Macskafarka írja, egyik sem felel meg az NGM-rendeletnek, így felesleges az ilyen megkülönböztetés.

[Macskafarka]

1. Előbb készül el a számla, azt követi az adatszolgáltatás.
2. Az adatszolgáltatás az törvényi kötelezettség.
3. Akkor számít sikeresnek az adatszolgáltatás, ha a NAV befogadta, és visszaérkezett a befogadási igazolás
4. Az ERROR az nem számít befogadásnak
5. Az adatszolgáltatás nem minősül teljesítettnek, ha a NAV ERROR-ral megtagadta a befogadást.
6. Ha valaki ERROR-t kap, akkor addig kell küzdenie, ameddig valahogy el tudja érni, hogy befogadja a NAV

Ez az én logikám, szóljatok, ha valamiben tévedtem volna.
Ebből következik, hogy NEM mondhatom azt az ügyfélnek, hogy van komolyan veendő ERROR, és van, amit figyelmen kívül kell hagyni.
A fenti logika szerint MINDEN számlát fel kell tudni adni, vagyis be kell fogadni a NAV-nak! Érdekes, ezt az elvet simán megvalósítják kézi számla rögzítésnél.
Ha a korábbi számla stornója nem térhet el az eredetitől az ÁFA kulcsában, akkor azt fel is kell tudni adni.
Ha a NAV nem fogadja be, akkor azzal megszegi a törvényi kötelességét.
Ha a felhasználó tudja, hogy a NAV elutasítja a befogadást ERROR-ral, akkor jóhiszeműen dönthet úgy, hogy olyan módon korrigálja a számla adatszolgáltatást, hogy eleget tudjon tenni az adatszolgáltatási kötelezettségének a NAV kötelességszegése ellenére is.
Szóval simán nyerhető ez a logika.
A másik lehetőség, hogy elrugaszkodunk a hagyományos megközelítéstől, amiben számla tételsorokban gondolkodunk érvénytelenítés (stornó) esetén. Inkább kiállítunk egy tételsor nélküli érvénytelenítő bizonylatot, amiben csak a lánckezdő számlaszámra hivatkozva érvénytelenítjük a számla láncolatot. Ezt a NAV el fogja fogadni, és nem kell semmilyen áfa kulccsal bíbelődni.
Ennek jó eséllyel az lesz a következménye, hogy a vevő azt érvényteleníti, ami nála az érvénytelenítés befogadásakor van, a NAV is azt, amil épp akkor nála van. így Lehet, hogy 3-féle módon fogják kezelni. Hát ezt hozta össze a jogalkotó.

[JimTudeski]

...és akkor ehhez még vedd oda a világ legnagyobb baromságát, a feldolgozott, de WARN-nal jelölt adatszolgáltatást, ami bizonyos warn-ok esetén nem számít adatszolgáltatásnak, pl hibás adószám megadása...
Ez a baj a NAV-val, nem képesek fehéren-feketén kezelni a dolgokat. Nincs minden egyes esetre hogy mit lehet és mit nem. Innentől kezdve fejre áll az egész ahogy van. Kedvencem a doksiban "ha releváns" kifejezések... Kinek?? Nekem nem, akkor ha nem küldöm jól van az úgy? Valamiért kötelező valami nem, valami csak akkor ha, ez bement, de ha ez és ez a warn akkor nem jó, stb stb stb... Elmásztunk a számla kötelező adattartalmát előíró ÁFA tv-től, mert a NAV-nak más tervei vannak és már minden adatot IS akar látni és megkapni. Egy egyszerű adatszolgáltatást - ki, mikor, mekkora összegben vásárlást - 300+ oldalas specifikáció ír le. RÖHEJ!
Természetesen kérdéses esetek százai, amire nem tudnak konkrét kielégítő választ sem adni sok esetben. De hát ez ilyen. Ha kérsz állásfoglalást akkor sem adnak 100%-os választ. Sőt ha egy másik megyében kérdezed ott még más választ is kaphatsz. Na ezek fényében mi csináljunk egy rendszert, ami megfelel mindenkinek...