INVALID_LINE_OPERATION Miért került bevezetésre? [Q&A] about online-invoice HOT 22 OPEN

Mit jelent az, hogy nem feltétlenül van kihatása? Ha átírom az összes helyen a lineoperation-t CREATE-re, akkor minden esetben sikeres adatszolgáltatást fogok kapni? Ha mindenki átírja a modify-t create-re, akkor miért nem tudja az elemző szoftver úgy értelmezni? Attól tartok, hogy megint komoly logikába, összefüggésekbe kell belenyúlni, ami majd hozza magával a support növekményt is... Nem tartom korrektnek, hogy egyből error-t dob a rendszer, lehetett volna ezt első körben figyelmeztetéssel kezelni. (nem beszélve, hogy a jelenlegi projektek tesztelése kuka, mert nem egy esetben INVALID_LINE_OPERATION-t kapok)

from online-invoice.

@omachtandras Ez teljesen jó indoklás a warning mellett. Ezt gyorsan meg is futtatom a kollégákkal :)

Egyébként mind érintett szoftver darabszámban, mind érintett számlaszámban nem jelentős a nagyság, de ettől az érintettek számára 100%-os a hatás.

@EPluribusUnum Nem több információt akarunk, hanem jó minőségű és működő szolgáltatásokat építeni. Ezt akár még úgy is, hogy hamut szórunk a fejünkre és mondogatjuk közben a mea culpa-t, hogy akár 2018-ban is láthattuk volna ezt ... Ugyanakkor a végeredményen nem változtat, egyszer ezt meg kell lépnünk és tudom, hogy ez nem túl szimpatikus lépés a NAV oldaláról.

from online-invoice.

@NTCA-tax Azzal a feltételezéssel élve, hogy a változások május 15-én az éles rendszerbe kerülnek, rövid távon szükséges lenne elindítsuk az ügyfél kommunikációnkat, valamint a telepítéseket, de erőforrás allokáció szempontjából nem mindegy számunkra a változás formája. Az utolsó kommunikációdban ezen a ticketen jelezted, hogy talán lehetséges elsőre figyelmeztető üzenetként beállítani az INVALID_LINE_OPERATION üzenetet. Meg tudod kérlek mondani, hogy ezzel az opcióval kapcsolatban mikor várható hivatalos döntés? Azzal kapcsolatban is szeretnék kérni visszajelzést, hogy az élesítésnek a dátuma már eldöntött tény, vagy még alakulhat? Rengeteg ügyfélnél kell a változásokat telepíteni, ami gondos tervezést és koordinációt igényel a részünkről és szintén elengedhetetlen információ számunkra. Azoknál az ügyfeleinknél, ahol jelenleg több hónapon átívelő, előre betervezett rendszer frissítés zajlik, ott nem is vagyok benne biztos, hogy a határidő tartható lesz.

from online-invoice.

A tesztelés és kiadási terv kigondolása közben felmerült bennem még egy probléma az error-ral kapcsolatban. Jelenleg az API teszten az új funkcionalitás van kint. Ez oké, meg tudjuk csinálni a változtatásokat. Viszont! Hogy adjam ki az élesre X határidőre úgy, hogy biztos legyek abban, hogy a "régi" verzión lévő éles rendszeren működnek a változtatásaim? Magyarul biztosan csak akkor tudnám kiadni, ha Ti már kiadtátok. Viszont mivel rengeteg ügyfélről beszélünk, biztos, hogy sokan nem fognak azonnal frissíteni, rengeteg error lesz. Biztos, hogy ez igen nagy terhelést tenne ránk és a NAV-ra is. Nagyon indokoltnak tartanám, hogy warn legyen első körben. Ha csak 1 hónapig, már az is oké.

from online-invoice.

@NTCA-tax : ettől függetlenül az élesen lehet, hogy mégis warninggal kellene indítani. Mert abból látni fogjátok, hogy mennyien nem foglalkoztak a kérdéssel. Biztos vagyok benne, hogy sok fejlesztő nem olvassa a bejelentéseket, és nem tesztel folyamatosan a teszt rendszeren.
És meg is tudom őket érteni. Van millió más dolog, legtöbbjüknek ez a számla adatbeküldés csak úgy a nyakába esett, mert számláz, ami a szoftverének 0.1%át sem teszi ki. Számára ez egy szükséges rossz.
Nem tudom, hogy a szoftverek hány százaléka használ most MODIFY-t, de nem csodálkoznék, ha 99%uk nem nyúlna hozzá az előtt, mielőtt az élesben majd kijön neki, hogy nem tud adatot szolgáltatni.
És akkor megint kapkodás lesz és nagyon rossz lesz az egész visszhangja.

from online-invoice.

@NTCA-tax : az elsőkörben történő warning mellett tudnék érvelni azzal is, hogy nagyon sok ügyfélnél ,egy transzport élesbe rendszerbe történő engedélyeztetése ,nem 2 nap. Ha most azonnal kezdenénk el az engedélyeztetést sem biztos, hogy átmenne, azért mert ez nem egy jó előre eltervett, beharagozott módosítás.

RvPSc-vel egyetértek teljes mértékben, hogy aki követte a specifikációban leírt követelményt a Create és Modify alkalmazására, annak nem feltétlenül csak egy tollvonás a módosítás, logikailag többfele ágazik. És bár '' Kizárólag a számlamódosítás adatszolgáltatását szükséges megváltoztatni'', ez nem biztos, hogy kivitelezhető egy május 15.-ei időpontra.
Bármennyire szeretnénk megfelelni a NAV követelményeinek, nem feltétlenül van külön egy csapat a NAV program módosításokra és holnaptól nem tudunk rögtön ezzel foglalkozni, más, folyamatban lévő dolgainkat be kell fejezni.
Igyekszünk mindig eleget tenni a követelményeknek, és, ahogy látom, ''ezt egyszer meg kell lépni'', nincs menekvés....de lehet szerencsésebb lenne egy warningos éles kezdés.

from online-invoice.

Sziasztok, @NTCA-tax és @NTCA-developer

2 gyors kérdésem lenne:

• Tudnátok nekem segíteni abban, hogy mikortól lehet az éles rendszerben az új verzió szerint küldeni a számlákat? Mikortól mehet leghamarabb élesbe a Modify nélküli verzió? Fontos lenne tudni az ütemezés miatt.  Lesz átmeneti időszak most is, amikor a 2 verzió egyszerre fut az élesen?
• Bármi tudható már arról, hogy warning vagy error üzenettel fog az új verzió futni a bevezetéskor?

Köszönöm!

from online-invoice.

Tévedés... Még olyan ajánlást is tudnék előtúrni (sőt szerintem még itt github-on is fent van), amiben pont az ellenkezőjéről van szó. Mármint hogy a create a megtűrt és módosítás esetén modify-t kell használni...

Szerk.: CREATE-tel nagyjából tizedannyi munkánk lett volna anno, de hogy ne legyen senkinek rossz szájíze, átalakítottuk a logikákat a MODIFY-nak megfelelőre.

from online-invoice.

@RvPSc Én is így 'emlékszem'. És teljesen egyetértek abban, hogy a nehezebb utat választottuk, de ez szerintem nem választás kérdése volt.

from online-invoice.

A bevezetésnek az oka, hogy számos esetben az adóhivatal oldalán automatizáltan nem értelmezhetők az ilyen típusú módosító számla adatszolgáltatások. Ezt látjuk mind az elemzéseinknél, mind pedig az épülő eÁFA rendszerünkben.

Fontos kiemelni, hogy itt nem számlázó program oldalán hibás működésről beszélünk, hanem egy olyan számlamódosítás adatszolgáltatásának a megváltozásáról, amely kezdetektől fogva adott volt a rendszerben. Adóhivatali oldalról 2018-ban még nem látszódott, hogy milyen problémákat fog okozni a későbbiekben.

Azt látnod kell még, hogy a számla adattartalmára ennek a módosításnak nem feltétlenül van hatása. Kizárólag a számlamódosítás adatszolgáltatását szükséges megváltoztatni.

from online-invoice.

Én is látom, hogy ezt az adatszolgáltatási logikát alkalmazó szoftvereknek nagyobb változást jelent. Ezért építettük fel úgy az átállást, hogy januárban már jeleztük ezt a változást, februárban pedig tesztkörnyezetbe tettük bele. Az éles környezetben pedig a jelenlegi tervek szerint május közepén fogjuk alkalmazni, függően attól, mekkora probléma lesz akkor még az átállás.

A számla adattartalmára nincs feltétlenül hatása az adatszolgáltatási logika megváltozásának. Ezt persze szoftverfejlesztő dönti el, hogyan szeretné implementálni, de megteheti azt is, hogy a számlakép változatlan marad, azonban az adatszolgáltatásban CREATE-eket alkalmaz.

Az adatelemzésnél a fő problémánk, hogy a MODIFY az eredményt mutatja, ugyanakkor az áfa logikája a számla módosításnál a változásra épül. Tehát például ha egy tétel adókulcsa 5%-ról 27%-ra változik, akkor a MODIFY egyszerűen felülírja az értékeket és nem látszódik a változás. A CREATE esetén ez -5%, +27%, tehát egyértelmű a hatásváltozás bármilyen hosszú is a számlalánc. No ennek adóhivatalon belül is hosszú története van és napokon keresztül lehetne vetíteni azt a filmet, amit ennek a megvitatásával töltöttünk... Ugyanakkor elérkezett az az idő, hogy egyértelműen lássuk, ez így nem fenntartható.

Abban lehet vitatkozni, hogy május 15-ig elégséges az idő, vagy sem, milyen időpont lenne elég ehhez. Ezt viszont nem tudjuk úgy megmondani, ha nem látjuk a fejlesztők megalapozott álláspontját. A warning bevezetését azért nem látom jónak, mivel ügyfél oldalon nagyobb problémát okoz, ha éles környezetben egyszer csak bekapcsoljuk. Nem látom magam előtt azt a beszélgetést, hogy az ügyfél kap warningot és a fejlesztő győzködi őt arról, hogy ez nem olyan warning, attól még tökéletes az adatszolgáltatás, mivel csak májustól kell változtatni... A tesztrendszerben az error viszont sokkal figyelemfelhívóbb, mint bármely más kommunikációnk. Még akkor is, ha nagyobb hullámokat gerjeszt, amire talán többen felfigyelnek és nem május 15-én jönnek a problémajelzések.

from online-invoice.

@NTCA-tax . A "MODFY" NEM azt jelenti hogy a NAV szerver oldalon házon belül is update-elni kell, hanem azt hogy a számlán módosítást történt. Semmi nem gátolja meg a NAV-ot hogy "MODIFY" esetén ne update legyen, hanem insert, mert neki kell a historikus adat. Teljesen felesleges volt emiatt kilens oldalra kitolni ezt a módosítást, mikor minden információ bejön server oldalra és lekezelhető.

from online-invoice.

@EPluribusUnum Ezt a kört megfutottuk, és láttuk, hogy ez nem fenntartható. Nem arról van szó, hogy technikailag megvalósítható-e vagy sem, hanem a hosszú távú fenntarthatóság.

from online-invoice.

@NTCA-tax Ez a mostani csak FORMAI módosítás, tartalmilag semmi sem változik, ettől nem fog több információ rendekezésre állni a NAV számára. Akkor meg mindek kell ez? Az hogy a NAV eddig kukázott adatot az a NAV problémája, nem az adatbeküldőé. Kezelje a NAV házon belül a problémát.

from online-invoice.

Pedig meg lehetett volna látni... Többek között én is tettem javaslatot, miszerint feleslegesen van túlbonyolítva ez a rész (és nem egyedül voltam ezzel). Hónapok munkája volt illeszteni a működést, most kukázhatjuk a belefektetett időt, újabb ráfordítással.

from online-invoice.

Sziasztok!

Én csak technikai oldalról tennék megjegyzést: jelenleg a CREATE és a MODIFY is elfogadott élesen, tehát ha valaki ma lefejleszti azt, hogy mostantól csak lineOperation = CREATE-tel küldi be az adatszolgáltatást (természetesen a megfelelő lineNumberReference számítással), az mehet élesbe, hiszen ez most is egy elfogadott módszertan.
Az error/warn és a bekapcsolás időpontjáról majd @NTCA-tax nyilatkozik.

Üdv

from online-invoice.

@NTCA-developer, köszönöm szépen.
Megj.: Ez azért bosszantó részemről, mert minek állítottunk MODIFY-t, ha nem is volt kötelező? A dokumentáció szerint, így volt a helyes, ha nem CREATE-el küldjük az adott számlákat...
Köszönöm a gyors válaszod !

from online-invoice.

@kurucza , Én nem láttam a dokumentációban, hogy csak a MODIFY lett volna a helyes. Én eleve a CREATE-tal csináltam a számlakorrekciókat, a MODIFY-t számszakilag követhetetlennek tartottam. Már az Online Számla előtt is a CREATE módszert használtam.
Az online számla bevezetése előtt láttam érdekes megoldásokat a számlakorrekcióra. Az adóhivatal által korábban "kétlépcsős számlamódosítás"-nak nevezett lehetőség is elég érdekes (volt). Ez a stornózom majd módosítom és mindkét esetben az alapszámlára hivatkozom módszer. Egy érvénytelenített számlát miért lehet módosítani? Jelenleg ez a WARN jön rá: INCONSISTENT_MODIFICATION_DATA_STORNO_ALREADY_EXISTS

from online-invoice.

@betasofthu
Én nem azt írtam, hogy csak az volt a jó, hanem azt, hogy szépen meg volt fogalmazva a specifikációban, mely esetekben CREATE és mely esetekben MODIFY az elvárt érték. pl:

Sokkal könnyebb lett volna csak CREATEként küldeni a lineokat, de a specifikáció nem ezt mondta. Én csak arra utaltam, hogy igyekeztünk megfelelni a specifikációban leírt követelményeknek és csak abban az esetben ment CREATE-el a line egy módosító számlában, ha arra szükség volt. Minden más esetben követtük a leírtakat. Nem volt egyszerű , de megcsináltuk.

from online-invoice.

@betasofthu Én nem azt írtam, hogy csak az volt a jó, hanem azt, hogy szépen meg volt fogalmazva a specifikációban, mely esetekben CREATE és mely esetekben MODIFY az elvárt érték. Sokkal könnyebb lett volna csak CREATEként küldeni a lineokat, de a specifikáció nem ezt mondta. Én csak arra utaltam, hogy igyekeztünk megfelelni a specifikációban leírt követelményeknek és csak abban az esetben ment CREATE-el a line egy módosító számlában, ha arra szükség volt. Minden más esetben követtük a leírtakat. Nem volt egyszerű , de megcsináltuk.

Már elnézést, hogy beleszólok, de nem volt olyan eset, ahol csakis MODIFY-al kellett volna küldeni. Úgy volt meghatározva a speckó, hogy lehet CREATE-el is meg MODIFY-al is. Nem volt olyan, hogy csak egyik vagy csak másik használható.

Amúgy már a legelső nyilvános egyeztetéskor elhangzott, hogy a CREATE a preferált és a MODIFY az a megtűrt módszer. Aki az utóbbit választotta, az most kellemetlen helyzetbe került.

from online-invoice.

Köszönjük a visszajelzést! (ennyit a számlázó fejlesztőkkel való konzultációról, jó kommunikációról és kapcsolattartásról -> ha jól látom kiment a NAV tájékoztatás az ügyfeleknek, hogy minden marad és május 15 a határidő)

from online-invoice.

Tisztelt Fejlesztők!
Az Online Számla rendszer új, blokkoló ERROR-üzenetét („INVALID_LINE_OPERATION”) a NAV a korábban tervezett 2023. május 15. helyett szeptember 18-án élesíti.
További információk ezen a linken találhatók: #1067

from online-invoice.