[Q&A] Ellentmondásos warn: INCONSISTENT_MODIFICATION_DATA_STORNO_ALREADY_EXISTS

[laladisc]

Sziasztok!

A 3.11-es verzióval bevezetett warn-ok közül, az INCONSISTENT_MODIFICATION_DATA_STORNO_ALREADY_EXISTS szembe megy az eddigi gyakorlattal, amely szerint amennyiben úgy javítunk egy számlát, hogy az eredetit érvénytelenítjük és új számlát állítunk ki, a 3. számla szintén az eredeti számla módosító okirata kell hogy legyen.

A dokumentáció is több ponton kitér erre az esetre pl a 153.oldalon: "Széles körben elterjedt gyakorlat, hogy téves adattartalmú számlák esetén először egy érvénytelenítő számlát bocsátanak ki, majd újabb számla kerül kiállításra, immár helyes adattartalommal. (Ezt a gyakorlatot a 2007. december 31-ig hatályban levő Áfa törvény kifejezetten előírta a számlázó programmal kiállított számlák módosítása esetére.) Megjegyzendő, hogy ebben az esetben a helyesen kibocsátott számla is az eredetileg kibocsátott számla módosító okiratának tekintendő, mivel az azon bizonylatolt gazdasági esemény(ek)re vonatkozik. Így a helyes adattartalommal rendelkező második módosító okiratnak az eredeti számlára kell hivatkoznia"

Amennyiben a WARN feltételei közül kikerülne a MODIFY operáció figyelése, úgy már megállná a helyét.

[sinick2]

Éles kiadás mikor várható? Ha még nincs időpont, akkor mi a terv? Köszönöm!

[omachtandras]

Nem nyitnék rá új issue-t, itt jelzem, hogy a INCORRECT_LINE_DATA_VAT_STATUS_VAT_DATA_MISMATCH_EUFADE warn meg van említve, de nincs kifejtve az "AZ ONLINE SZÁMLA RENDSZER ÁLTAL KÜLDÖTT FIGYELMEZTETŐ ÜZENETEK" részben, hogy pontosan hogy működik, mire ellenőriz.

[NTCA-supporter]

@omachtandras maradt benne egy szóköz sajnos, ha az 584-re keresel akkor ott lesz. Hamarosan javítjuk, köszi a jelzést. A fentiekre @NTCA-tax válaszát várjuk szakmai oldalról. Köszi

[Macskafarka]

@laladisc -javaslata helyes, mert a "WARN/INCONSISTENT_MODIFICATION_DATA_STORNO_ALREADY_EXISTS : A hivatkozott alapszámlára korábban már érkezett sztornó okirat " értelmezhetetlen hibás szöveg. Ugyanis "sztornó" fogalom NINCS az áfa tv-ben, továbbá nem érvénytelenítő számlaként kerül feladásra, hanem MODIFY. Tehát nemcsak nem kell WARN a Modify esetre, de az üzenet szövegét is módosítani kell az ÁFA tv. által használt fogalomra.

[omachtandras]

@laladisc : az élesen most indult karbantartás, félek, hogy kikerül ez is...

[NTCA-supporter]

Sziasztok! Nem kerül ki, pontos időpont még nincs. Szándékosan az új hibákra való felkészülés lehetősége miatt rakjuk ki egyelőre csak teszt környezetre. Üdv

[NTCA-supporter]

Sziasztok! Ezt a választ kaptam: "Ha a számla módosítására a kétlépéses (nullázás + új teljes adattartalom) módszert választja az adózó, akkor a „nullázó” számlát és az új, teljes adattartalmú számlát is invoiceOperation=”MODIFY” művelettel kell beküldeni. Az invoiceOperation=”STORNO” művelet a tényleges érvénytelenítő számlák beküldéséhez használandó."

Jeleztem, hogy az interfész dokumentáció kissé ellentmond ennek, felülvizsgálat folyamatban. Üdv

[laladisc]

Kedves @NTCA-supporter !

Ezt ugye ti sem gondoljátok komolyan? Amikor készít egy storno számlát az ügyfél a számla véglegesítése után azonnal beküldjük a NAV OSZ rendszerbe (azonnaliság elve). És mivel érvénytelenítő számlát csinál, az invoiceOperation=”STORNO” kell hogy legyen. Abban a pillanatban amikor a STORNOT beküldöm, még nem tudom, hogy későbbiekben az ügyfél szeretne e helyette új számlát készíteni, vagy azért készített érvénytelenítő számlát mert az ügylet meghiúsult. Kíváncsi vagyok hogy a fejlesztő társak mit fognak ehhez a megoldáshoz szólni, de szerintem ez így ebben a formában nem életszerű.

[omachtandras]

@NTCA-supporter, @laladisc : nálunk tesztelték a kollégák, CREATE + MODIFY + MODIFY-ra tegnap jött a warn. (Mi nem STORNO-val adunk fel, mert nem láncolatot lehet stornózni a programban, hanem (helyesbítő)számlát, így minden stornónak hívott számla modify a NAV felé.)

[NTCA-supporter]

Szia @omachtandras ! Ez a CREATE + MODIFY + MODIFY-ra jött WARN ezt kaptad? INCONSISTENT_MODIFICATION_DATA_STORNO_ALREADY_EXISTS Mert az elég furcsa lenne. Ha igen, akkor kérlek küldd el, hogy ránézhessünk. Üdv

[omachtandras]

@NTCA-supporter Tranzakció azonosítók: 3L6939LBVQSF5NHW – 32/VBEA/2021 3L695HDM4ZJF3BU4 - 33/VBEA/2021 3L697J2SD0P82BA7 – 34/VBEA/2021

Business validation : WARN/INCONSISTENT_MODIFICATION_DATA_STORNO_ALREADY_EXISTS : A hivatkozott alapszámlára korábban már érkezett sztornó okirat (Számla fej : InvoiceData/invoiceMain/invoice/invoiceReference/originalInvoiceNumber = 32/VBEA/2021)

[NTCA-supporter]

@omachtandras a 3L695HDM4ZJF3BU4 - 33/VBEA/2021 STORNO-ként lett beküldve, azért kapod a WARN-t. Üdv

[omachtandras]

@NTCA-supporter : upsz, tényleg, nem voltam up-to-date. Csatlakozom @laladisc -hez, a programunk nem gondolatolvasó, nem tudjuk előre, hogy az ügyfél akar-e arra a gazdasági eseményre majd új számlát kiállítani vagy sem. Mi legyen? Álljunk rá modify-ra minden esetben? Vagy felülvizsgáljátok ezt a warningot?

[NTCA-supporter]

Sziasztok! A felvetést/hozzászólást már reggel továbbítottam az illetékesek felé, visszajelzésig türelmeteket kérjük. Üdv

[NTCA-tax]

Megjöttem illetékesként :)

A számlaadat-szolgáltatás indulásától próbáljuk folyamatosan kommunikálni, hogy a számlamódosításra két megoldás létezik: egylépcsős módosítás és kétlépcsős módosítás. Az egylépcsős módosítás tiszta sor, kiállít az értékesítő egy módosító bizonylatot, amelyben leírja mi változott az eredeti számlához képest. A kétlépcsős módosításnál létezik egy olyan módosító bizonylat, amely az eredeti számlát lenullázza, majd ezt követően kiállításra kerül egy újabb módosító bizonylat, amely a valóságban megtörtént gazdasági eseményt egy bizonylatként tükrözi. Mindkét megoldás teljesen jó, azonban arra figyelni kell, hogy a kétlépcsős módosításnál mind a két bizonylat modify.

Látjuk a számlázó programok és/vagy felhasználók gyakorlatát, hogy a kétlépcsős módosításnál először egy stornó számla kerül kiállításra, majd ezt követően vagy egy új normál számla, vagy pedig egy módosító számla. Ezt a kialakult gyakorlatot akarjuk a jogszabályi követelményekhez igazítani, hogy a stronó számla ténylegesen csak az érvénytelenítésről szóljon, ne pedig a kétlépcsős módosítás első számlájáról. Ne felejtsük el, hogy számlát akkor érvénytelenítünk, ha nem történt meg a gazdasági esemény vagy nem a két fél között történt meg. Tehát ha megtörtént a gazdasági esemény, csak éppen egy kicsit más adattartalommal, akkor számlát módosítunk.

Kérlek ne lövöldözzetek vissza azzal, hogy stornó nincs a jogszabályban. Egy kicsit nehezebben lenne érthető a mondanivalóm, ha érvénytelenítésről kiállított számlával egy tekintet alá eső okiratot helyettesítettem volna be...

Tehát lefordítva, create után jöhet bármennyi modify, azonban ha az adatszolgáltatási láncban van egy storno, akkor ott véget ér a lánc, nem következhet újabb modify.

Nem elvárás, hogy a program gondolatolvasó legyen, de ha létezne ilyen alkalmazásotok, akkor szóljatok, nagy hasznát vennénk mi is :) A felhasználó számára kellene tudatosítani, mit jelent az érvénytelenítés és módosítás közötti különbség, és ezt az adott programban hogyan tudja elvégezni.

[laladisc]

A számlázó program felhasználóit elég volt rávezetni arra a gyakorlatra, hogy a stornó után készülő új számla hivatkozzon az eredetire (több kevesebb sikerrel). Ha warningot fog kapni az így készült számláira, akkor inkább nem fog hivatkozni a 3. számlában, mivel Ő azt tanulta, hogy ha warn-t kap egy adatszolgáltatásra, akkor valami nincs renden és talán változtatnia kell a számlázási gyakorlatán. Nem beszélve arról, hogy a 3. számla kiállítása van hogy nem is azonnal történik meg, lehet hogy eltelik közben 1-2 nap, de attól még az ügylet nem hiúsult meg, tehát hivatkoznia kell(ene) az eredeti bizonylatra.

[laladisc]

Kedves @NTCA-tax !

Ha minden módosítót (legyen az érvénytelenítő vagy helyesbítő) MODIFY-al küldünk ezentúl, akkor az megfelelő?

[omachtandras]

@NTCA-tax : ha ez az egész arra megy ki, hogy tudni akarjátok, hogy mely gazdasági események nem valósultak meg, akkor miért nem elég, ha azt nézitek, hogy 0-ra futott egy láncolat? Ezzel az egésszel azt fogjátok csak elérni, amit @laladisc írt. Mindenki át fogja írni modify-ra (nálunk is egyből ez merült fel a kollégák részéről), és még annyi infotok sem lesz, mint ami most van (nevezetesen, hogy a 2. számla mutatja, hogy itt aztán tényleg 0-zni akartak, hogy aztán újat állítsanak ki). Nálunk is az a tapasztalat, hogy a felhasználók egy része már azt sem csinálja, hogy kiválassza a korábbi stornózott számlát, nem érti mire kell ez az egész, elfelejti, kisebb gondja is nagyobb ennél, stb. stb. Nagyon marginális dolognak tűnik ez ahhoz, hogy még arra is oktatni kelljen őket, hogy mikor lehet/KELL stornózni, mikor helyesbíteni 0-ra és folytatni a számlázást előzménnyel...

[omachtandras]

Sziasztok!

Lehet, hogy ez 12.16-án az éles rendszerre telepítve lett?

(Éles rendszerre hivatkozva jelentette be egy ügyfél, szóval 99%, hogy élesítve lett. Akkor mi átírjuk, hogy minden modify legyen, mert előre nem tudható, hogy fog-e hivatkozni rá az ügyfél, vagy sem....)

[bakter80]

erre valóban két válasz lehetséges:

• nem használjuk többet a STORNO-t
• sztornó után nem hivatkozunk többet az eredeti számlára

egyik sem fog javítani az adatok minőségén. más értelmes lehetőséget nem látok.