INVALID_LINE_OPERATION bevezetésével_lineNumberReference értéke [Q&A]

[kurucza]

SZiasztok, Kedves @NTCA-tax ,@NTCA-supporter

Szeretném kérni a segítségeteket egy kis értelmezésben. INVALID_LINE_OPERATION error üzenet bevezetésével nem teljesen egyértelmű, hogy a lineNumberReference tag milyen értéket vesz fel. Az eddigi működésben, ha egy módosító számlát küldtünk be, ahol a módosító számla tétele módosított egy korábban beküldött számla tételt, a lineOperation: MODIFY mellett, a lineNumberReference: az eredeti számla tételét tartalmazta, ezzel szépen nyomon követve, hogy az eredeti számla adott tételén történt a változtatás. lineOperation: CREATE esetén a lineNumberReference egy folytonosan növekvő, összes módosítást figyelembe vevő sorszám volt.

Akkor, ha a MODIFY, mint lineOperation megszűnik és átveszi a szerepét a CREATE, a lineNumberReference tag értéke mostmár mindig egy folytonosan növekvő, módosításokat figyelembe vevő sorszám lesz, ugye?

Egyszerű példán keresztül: Készül egy Számla :123456789, amely 2 tételt tartalmaz 123456789 számla első tételére készül egy módosító számla Ebben az esetben az új szemlélet szerint a NAV felé küldött info:

Minden egyes esetben ezt a leegyszerűsített logikát kell használni majd? Nem baj, hogy elveszítjük a NAV felé küldött adatokban az az infót, hogy az eredeti számla első tételén történt a módosítás?

Ami miatt ezt kérdezem, az a specifikáció. Amit levezettem az előzőekben logikusnak tűnhet, ha nem nézem a leírást tüzetesen. A csatolt részletben látszik, hogy bár az új validáció szerepel benne, de a CREATE és MODIFY nincs elkülönítve.( csillagozva…Lehet csak véletlenül maradt így )

Kukacoskodásnak tűnhet a kérdésem, pedig nem annak szánom. Elég sok időt és energiát jelentett a mostani működés beállítása, hogy a MODIFY és CREATE a leírtak szerint működjön és a linenumberreference értéke is helyes legyen. Így szeretnénk csak akkor hozzányúlni az egészhez, ha teljesen tiszta mi a feladat.

Tudtok nekem ebben segíteni?

Köszi,

Andi

[NTCA-supporter]

Szia @kurucza !

Mindent jól értettél, a validáció bevezetése után minden esetben ezt a folytatólagos logikát kell alkalmazni. Az interfész dokumentációban szándékosan lett meghagyva mindkét opció, hiszen jelenleg még mindkét megoldás elfogadott.

Üdv

[kurucza]

Köszönöm szépen a választ! Nem fogom lezárni a kérdésem, ha nem gond, mert útközben tuti lesznek még aggályaim és én is szeretem a folytatólagosságot.

[TNMarton]

Szia @NTCA-supporter!

A válaszodban az szerepel, hogy a mindkét opció jelenleg még elfogadott. Tudsz azzal kapcsolatban információt adni, hogy a közeljövőben, akár májusig bezárólag, várhatunk-e további módosulást a logikában / specifikációban a módosító számlák kezelésének tekintetében? Bármi további módosítást terveztek a májusban esedékes új verzió élesítése előtt?

Üdv

[NTCA-supporter]

Szia @TNMarton !

Nem várható egyéb változás.

Üdv

[Meme660]

Szia @NTCA-supporter!

Az INVALID_LINE_OPERATION validációhoz kapcsolódó módosításhoz kapcsolódóan az alábbi kérdéseim merültek fel:

1. Jól értettem kurucza-nak írt válaszodat, miszerint mindkét megoldás elfogadott? Vagyis ha a módosított feladással elkészültünk, azt az éles rendszer jelenleg is képes fogadni hibaüzenet nélkül? (Nem kell NAV oldalon verziót váltani ahhoz, hogy a módosított módon küldjük be a módosító okiratokat?)
2. Napi szinten sok számla feladás történik rendszerünkből, illetve visszatérítések miatt sok módosító, esetleg sztornó számla. Miután egy adott eredeti számlának több módosító számlája is lehet, okoz-e problémát, ha az átállás előtt az első módosító számla még a korábbi logikával került feladásra, az átállás után pedig az új logikával?

Üdv