Online-invoice: [DEV support] INVOICE_NUMBER_NOT_UNIQUE újratöltve, hogyan kerülhető el?

[nbeeps2]

Korábban már volt erről szól (https://github.com/nav-gov-hu/Online-Invoice/issues/78) , akkor az alapján le is fejlesztettem, tesztelve működik is, de élesben a gyakorlatban rendszeresen előjön. Hogy lehetne ezt megszüntetni?

Tehát a felállás a következő:

1. Elkészül a számla
2. Beküldésre kerül a NAV-hoz
3. A NAV ezt be is fogadja, de válasz már nem érkezik a manageinvoice operációra, így tranzakció azonosító sincs.

Ha ilyet tapasztalok, akkor így járok el jelenleg:

1. queryIncoiceData-val megpróbálom megállapítani a korábbi beküldés tranzakció azonosítóját számlaszám alapján
2. Ha ez sem hozott eredményt, akkor a queryTransactionList operációval listázom a tranzakciókat, majd a queryTransactionStatus ReturnOriginalRequest használatával megállapítom, hogy tényleg a megadott számlához tartozik-e a tranzakció azonosító.
3. Ha a 4-es vagy 5-ös pont sikerrel jár, akkor meg van a tranzakció azonosító és minden szép, ha nem járt sikerrel, akkor a manageInvoice operációt megismétlem.

A fenti eseményt úgy tudom tesztelni, hogy a teszt rendszerben a manageinvoice-ot hagyom lefutni, de utána megszakítom a program futását, hogy az ne tudja letárolni a tranzakcióazonosítót, ezzel előidézve/szimulálva egy esetleges NAV üzemszünetet. Viszont valahogy mégse 100% ez a tesztelési módszer,mert ilyen esetben már a 4-es pont is mindig sikerrel jár, igaz azt is felül tudom bírálni teszt jelleggel, hogy sikertelen legyen, viszont ebben az esetben is sikeresen lesz az 5-ös pont.

Látszólag tehát tökéletesen megoldottam az INVOICE_NUMBER_NOT_UNIQUE elkerülését a gyakorlatban azonban mind a saját számlázásunkban, mind az ügyfeleknél tömegesen fordul elő ilyen üzenet egy NAV üzemszünet esetén? Hogy fordulhat ez elő? Mi lehet a gond? Hogy tudom elkerülni?

[nbeeps2]

Egy olyan megoldást kérnénk szépen a problémára, ami ELKERÜLI ezt a problémát és nem utólag orvosolja. Célzok itt arra, hogy a legtöbben úgy oldották meg ezt a kérdést, hogy utólag az így kapott hibát megpróbálják elsikálni, én viszont be sem szeretném küldeni újra a számlát, hogy ne is kapjak ilyen üzenetet és akkor az ügyfél sem kap róla e-mailt.

[szako]

Egy kis tapasztalat-megosztás: Mi is pontosan a te általad felvázolt lépésekkel keresünk tranzakcióazonosítót, mivel arra jutottunk, hogy ez a legjobb megoldás. A manageinvoice beküldés időbélyege utáni 1 perces intervallumra kértük le a tranzakció azonosítókat és kerestünk benne, de a legutóbbi NAV szolgáltatáskiesés kapcsán jöttünk rá arra, hogy a beküldés után előfordul, hogy több perccel képződik meg a tényleges beszúrás, így pl. nem volt találatunk és ABORTED lett az újra beküldés. Ezt az intervallumot felemeltük 10 percre, meglátjuk mi sül ki belőle.

[nbeeps2]

Köszi, én +/- 4 perces időablakot nézek, már én is gondoltam rá, hogy lehet esetleg ezt kellene feljebb venni...

[DrotosTot]

Nálunk ugyanez a megoldás.
Viszont!
Mi úgy értelmezzük a jogszabályt, hogy az adatszolgáltatás akkor tekinthető sikeresnek és befejezettnek, ha visszakapjuk a DONE státuszt a feldolgozásról. Értelemszerűen, ha a számla a megadott értékhatáron felüli, akkor ennek _aznap_ meg kellene történnie. Ez, tapasztalatunk szerint sem -mindig- jön össze.
Ezért, szeretnénk, ha ez stabilan, az adózó oldaláról kézi beavatkozás nélkül, kiszámítható módon történne meg. Például, szerver oldali hiba esetén, ha nem tudja a rendszer visszaigazolni az adatszolgáltatást, akkor be se fogadja.
Jelenleg egy rendszerhiba esetén az adózó (vele pedig a szoftverfejlesztő) nyakába varrható az egész azzal, hogy nem kérdezte le a státuszt.
Tekintsünk el attól, hogy a felületen kézzel lekérhető a státusz, elsődlegesen azért, mert a lekérdezést nem ugyanaz a (technikai) felhasználó végzi, mint aki az adatszolgáltatást teljesítette.
Abba pedig már ne menjünk bele, hogy mivel igazolja az adózó, hogy a kötelezettségét rendszerhiba miatt nem tudta teljesíteni vagy abba, hogy a jogszabály nem tiltja, hogy egy számláról többször történjen adatszolgáltatás.

A lényeg: a klienshibákat kliensoldalon, a szerverhibákat szerveroldalon kell orvosolni.

[gajzi]

Korábban már volt erről szól (#78) , akkor az alapján le is fejlesztettem, tesztelve működik is, de élesben a gyakorlatban rendszeresen előjön. Hogy lehetne ezt megszüntetni?

Tehát a felállás a következő:

1. Elkészül a számla
2. Beküldésre kerül a NAV-hoz
3. A NAV ezt be is fogadja, de válasz már nem érkezik a manageinvoice operációra, így tranzakció azonosító sincs.

Ha ilyet tapasztalok, akkor így járok el jelenleg:

1. queryIncoiceData-val megpróbálom megállapítani a korábbi beküldés tranzakció azonosítóját számlaszám alapján
2. Ha ez sem hozott eredményt, akkor a queryTransactionList operációval listázom a tranzakciókat, majd a queryTransactionStatus ReturnOriginalRequest használatával megállapítom, hogy tényleg a megadott számlához tartozik-e a tranzakció azonosító.
3. Ha a 4-es vagy 5-ös pont sikerrel jár, akkor meg van a tranzakció azonosító és minden szép, ha nem járt sikerrel, akkor a manageInvoice operációt megismétlem.

A fenti eseményt úgy tudom tesztelni, hogy a teszt rendszerben a manageinvoice-ot hagyom lefutni, de utána megszakítom a program futását, hogy az ne tudja letárolni a tranzakcióazonosítót, ezzel előidézve/szimulálva egy esetleges NAV üzemszünetet. Viszont valahogy mégse 100% ez a tesztelési módszer,mert ilyen esetben már a 4-es pont is mindig sikerrel jár, igaz azt is felül tudom bírálni teszt jelleggel, hogy sikertelen legyen, viszont ebben az esetben is sikeresen lesz az 5-ös pont.

Látszólag tehát tökéletesen megoldottam az INVOICE_NUMBER_NOT_UNIQUE elkerülését a gyakorlatban azonban mind a saját számlázásunkban, mind az ügyfeleknél tömegesen fordul elő ilyen üzenet egy NAV üzemszünet esetén? Hogy fordulhat ez elő? Mi lehet a gond? Hogy tudom elkerülni?

A #378-as Issue-ban tapasztalt kommunikáció alapján sosem fog megvalósulni, de milyen egyszerű lenne, ha a INVOICE_NUMBER_NOT_UNIQUE hiba mellé odatennék a Tranzakciós ID-t, amin korábban fel lett töltve ez a számla és ez a két lépés, ami vagy megy, -vagy mint múlt héten is láttuk- vagy nem, feleslegessé válna. De valószínűleg ennek a tagnek a beszúrása (ami az egyediség megállapításakor rendelkezésre áll) hatalmas performancia gondokba ütközne. :-)

[HWKF]

Az a gond, hogy a 2. pont többször fut le, mert nem kap választ és mire a 3.-hoz érsz már legalább 2-szer elküldted.

[HWKF]

A jó megoldás az lehetne, hogy ha már egyszer próbáltad elküldeni, akkor a következőt addig nem kezded el, amíg vagy nem kapsz választ, vagy le nem csekkoltad, hogy van-e már adatszolgáltatás beküldve.
Ez utóbbi ellenőrzést a queryInvoiceCheck operációval lehet a legegyszerűbben megtenni. Mert ez annyit ad vissza, hogy igen vagy nem, és ez így nem terheli a rendszert adatokkal. Eddig nem sok értelmét láttam ennek az operációnak, de így ebben a helyzetben ez a legideálisabb.

Egyébként ha a queryInvoiceData nem ad eredményt, akkor milyen tranzakciót tudsz találni a queryTransactionList-tel?

Nálunk egyelőre marad a NOT UNIQUE hiba kezelése, mert egyelőre nincs idő átírni a megelőző módszerre.

[gajzi]

A jó megoldás az lehetne, hogy ha már egyszer próbáltad elküldeni, akkor a következőt addig nem kezded el, amíg vagy nem kapsz választ, vagy le nem csekkoltad, hogy van-e már adatszolgáltatás beküldve.
Ez utóbbi ellenőrzést a queryInvoiceCheck operációval lehet a legegyszerűbben megtenni. Mert ez annyit ad vissza, hogy igen vagy nem, és ez így nem terheli a rendszert adatokkal. Eddig nem sok értelmét láttam ennek az operációnak, de így ebben a helyzetben ez a legideálisabb.

Egyébként ha a queryInvoiceData nem ad eredményt, akkor milyen tranzakciót tudsz találni a queryTransactionList-tel?

Nálunk egyelőre marad a NOT UNIQUE hiba kezelése, mert egyelőre nincs idő átírni a megelőző módszerre.

Múlt héten úgy tűnt, hogy a queryInvoiceData egy darabig le volt állítva, ez esetben volt megoldás szerintem a queryTransactionList, már ha az működött.

[szako]

Ha a queryInvoice* hívások nem adnak vissza számlaszámot, akkor honnan tudod, hogy azért, mert:
a, nem jutott el a kérés a NAV-ig vagy ABORTED lett
b, még feldolgozás alatt van náluk és később fog bekerülni DONE státusszal?

[lvitya586]

Szerintem a queryInvoiceCheck operációt kéne úgy bővíteni, hogy ne csak true vagy false értéket adjon vissza, hanem azt is lehessen látni, ha már bent van a számla, de még nem került feldolgozásra. Ezzel a módszerrel el lehetne kerülni a dupla küldést, mert akkor csak ezt a hívást kell addig ismételnem, amíg "valódi" false vagy true értéket nem kapok vissza.

[szako]

Ezzel szerintem az a gond, hogy a NAV oldalán nem tudják a beküldéshez (TransationId+Index) tartozó számlaszámot, csak egy bizonyos pont után.

[szako]

A #378-as Issue-ban tapasztalt kommunikáció alapján sosem fog megvalósulni, de milyen egyszerű lenne, ha a INVOICE_NUMBER_NOT_UNIQUE hiba mellé odatennék a Tranzakciós ID-t, amin korábban fel lett töltve ez a számla és ez a két lépés, ami vagy megy, -vagy mint múlt héten is láttuk- vagy nem, feleslegessé válna.

Ez egész jó ötlet! @NTCA-developer: megvizsgáljátok, hogy ez megvalósítható-e? Vagy volt már erről szó?

[HWKF]

@NTCA-supporter @NTCA-tax
A queryInvoiceCheck/Data operációk melyik státusztól kezdve látják az adatszolgáltatást?
Ha e kettő nem ad vissza választ, akkor van-e értelme a queryTransactionList operációt használni?

[NTCA-supporter]

Sziasztok!

Engedjétek meg, hogy röviden válaszoljak.
Az ötletet, hogy valahogyan visszadjuk azt, hogy az ismételten beküldött számla melyik tranzakcióban lett befogadva, megnézzük és jelzek majd.
A számlalekérdező operációk a SAVED státusz után tudják csak visszaadni a létezőség jelzést/az adatokat, így valóban "csak egy bizonyos pont után" kapod vissza.
Üdv

[lvitya586]

A számlalekérdező operációk a SAVED státusz után tudják csak visszaadni a létezőség jelzést/az adatokat, így valóban "csak egy bizonyos pont után" kapod vissza.

Ez rendben is van, de pont ezért lett volna előnyösebb, ha a számlaszám is átkerült volna magasabb szintre, hiszen kliens oldalon ez kulcs adat. Mindenesetre köszönjük, ha visszaadjátok a transactionid-t, mert ez mindenképpen segítség. Bár ez is csak a tünetek kezelésére szolgál, a gyökérok nem lesz megszüntetve ezáltal.

[lvitya586]

@NTCA-developer @NTCA-supporter ,
Nem lenne értelme a 3.0-ban a számlaszámot is belefoglalni a requestSignature-be? Így azonnal megjelenne a NAV oldalán a számlaszám, amit aztán a queryInvoiceCheck-kel le lehetne kérdezni, hogy beküldtem-e már egyszer.

[NTCA-supporter]

Szia @lvitya586!
Egy requestben nem csak 1 számlát tudsz beküldeni, hanem max. 100-at. Az hogy a requestSignature számolásába még azt is belevegyük, semmi értelme.
Az, hogy egy számlát beküldesz, még nem garantál semmit, nem véletlenül csak a SAVED után adunk vissza információt egy számláról, hiszen akkor futott meg az összes blokkoló üzleti és technikai validáció.
Ahogy ígértem, utánajárunk a dolognak.
Üdv

[lvitya586]

Szia @lvitya586!
Egy requestben nem csak 1 számlát tudsz beküldeni, hanem max. 100-at. Az hogy a requestSignature számolásába még azt is belevegyük, semmi értelme.
Az, hogy egy számlát beküldesz, még nem garantál semmit, nem véletlenül csak a SAVED után adunk vissza információt egy számláról, hiszen akkor futott meg az összes blokkoló üzleti és technikai validáció.
Ahogy ígértem, utánajárunk a dolognak.
Üdv

Köszönöm, hogy utánajártok ennek.
A requestSignature-nél nyilván lehetne 100 db számlaszám, mint ahogy jelenleg is lehet 100 db invoiceOperation, csak ez utóbbi kliens oldalról érdektelen és csak a NAV oldaláról jelent valamit, ugyanakkor a számlaszám meg a kliensek részére lenne fontos.

Mivel legalább egyszer úgyis vissza kell kérdezni a számla állapotára, hiszen csak akkor teljesült az adatszolgáltatás, ha DONE státuszom van, ezért a mi oldalunkról teljesen mindegy, hogy a NAV oldalán éppen milyen egyéb státuszban van és milyen validáció fut rá, ill. garantálni sem kell semmit. Csak annyit kell tudnom először, hogy adott számlaszámmal már elkezdtem az adatszolgáltatást vagy nem, és a válasz(ok) függvényében újra kell-e küldenem vagy nem.

[nbeeps2]

@HWKF > Az a gond, hogy a 2. pont többször fut le, mert nem kap választ és mire a 3.-hoz érsz már legalább 2-szer elküldted.

Nem ez a gond. A számla küldés hiba miatt nem ment be (vagy nincs hozzá letárolva nálam tranzakciós azonosító, akkor a queryIncoiceData és a queryTransactionList lép életben (eredeti témaindító 4-es, 5-ös pontja). Tehát nem küldöm be újra a számlát csak akkor, ha a fenti két operáció alapján is az jön ki eredményül, hogy nincs bent a számla...

Ezért is írtam, hogy elméleti szinten én megoldottam ezt az INVOICE_NUMBER_NOT_UNIQUE kérdést, ami a tesztrendszerbe, a kiritikus pontban megszakítva a program futását tökéletesen szimulálhatóan tök kól működik, de éles környezetben egy üzemszünetnél/bizonytalan működésnél egyszerűen valamiért nem segíti ezt a hiba kiszűrését és a probléma továbbra is jelentkezik...

Közben megvizsgáltam hátha a queryTransactionList-et túl szűk időablakra kérdezem le, de kiderült, hogy nem, mert az időablak nyitó időpontja a számla készítésének kelte (mínusz 2 perc, ha esetleg a kliens órája valamiért másképp járna) és a záró időpontja, az utolsó küldési kísérlet időpontja + 2 perc. A saját számlázási rendszerünkben is keletkezett 7 ilyen számla és az online NAV rendszerben belépve pontosan látom, hogy melyik beküldés lett a sikeres mondjuk abból a például 12 próbálkozásnál, ami egy rövidebb üzemszünet során keletkezett. Az eredmény teljesen véletlenszerű. Volt, amikor már az első beküldés sikeres volt, volt amikor csak az 5. vagy a 10., éppen, amikor a rendszer elérhető volt. Mindegyik esetben válasz már nem jött, tehát nem volt tranzakció azonosító és a következő küldéskor a rendszer queryIncoiceData operációja azt adta vissza, hogy még NINCS BENT a számla, illetve a queryTransactionList is hatástalan volt...

[nbeeps2]

Továbbra is egy olyan módszer részletes ismertetését várom a NAV-tól válaszként, ami a hibaüzenetet ELKERÜLI és nem kezelni próbálja, így nem értek egyet azzal, hogy az lenne a megoldás, hogy a INVOICE_NUMBER_NOT_UNIQUE üzenetbe tegyük bele az eredeti tranzakciósID-t, mivel ez eső után köpönyeg megoldás, ráadásul a felhasználó is fog róla kapni egy e-mailt, mint tudjuk...

[HWKF]

@nbeeps2
Az a gond, hogy az adatszolgáltatás lekérdezés csak a SAVED státusztól láthatod. Tehát, amíg a queryInvoiceData operációval lekérdezed, de még nem jutott el a SAVE státuszba, akkor azt fogod kapni, hogy nincs. Ezért próbálod elküldeni, de közben az eredeti küldés eljut a SAVED státuszba, sőt tovább. Azaz hamarabb megy be, mint amit másodjára küldtél.
És ezen nem segít a queryTransactionList sem, mert hiába látod a tranzakciókat az ellenőrzés pillanatában. Mert a tranzakciókban nincs benne a számlaszám. A tranzakcióknak max az állapotát tudod megszerezni, de ezt még így nem tudod számlához kötni.
Tehát még meg kell szerezned a számlaadatot. Ezt max a queryInvoiceDigest operáció tudja megadni, mert az tud tranzakció ID alapján számlaadatot visszaadni. De ha túl gyors vagy vagy a NAV éppen belassult, akkor ez az ellenőrzés még mindig a SAVED státuszba kerülés előtt fog megtörténni. Így megint azt fogod hinni, hogy nem ment be.
@NTCA-supporter @NTCA-tax Szerintetek jól látom a folyamatot?

[nbeeps2]

Így van, a queryInvoiceData - val nem fogom látni egy adott pontig, itt jött be a képbe a queryTransactionList, amiben visszakapom egy megadott időablakban a tranzakcióazonosítókat. Ezeken végig megyek és megnézem, hogy van-e közte olyan azonosító, ami nincs benne a számlázó programban, mert akkor az tartozik az eredeti beküldéshez. A queryTransactionStatus RETURNORIGINALREQUEST-el pedig kinyerem a számla adatokat és összevetem a számlával, hogy valójában hozzá tartozik-e.

[nbeeps2]

Pontosan úgy, ahogy itt (https://github.com/nav-gov-hu/Online-Invoice/issues/78) NTCA-developer írta 2019, október 30-án.

[HWKF]

Bocs. A RETURNORIGINALREQUEST beállításról lemaradtam valahogy. Anno még januárban elkezdtünk foglalkozni a queryTransactionList operációval, de végül időhiányában le kellett állítani a megvalósítást. Igaz akkor még a Technikai érvénytelenítések kapcsán merült fel a használata.
De így látva a problémákat az OSZ v3 megvalósítása kapcsán ezt is meg kell valósítani.
Akkor elsiklottunk a RETURNORIGINALREQUEST beállításon. És enélkül nagyon bonyolultnak tűnt a számlainformáció levadászása, de ez "jóval egyszerűbbé" teszi a használatát.

[nbeeps2]

Szerintem a fő gond az lehet, hogy ilyen durva leállásnál, mint ami legutóbb volt, annyira a feje tetejére áll a rendszer, hogy ezek az operációk SEM működnek megfelelően és ebből eredhet a hiba.

[HWKF]

Akkor nem marad más, mint amit egy a másik rendszernél ajánlanak, ha hibára futsz várj egy órát, ha megint hibára futsz, akkor várj valamivel többet, ha megint....

[lvitya586]

Továbbra is egy olyan módszer részletes ismertetését várom a NAV-tól válaszként, ami a hibaüzenetet ELKERÜLI és nem kezelni próbálja, így nem értek egyet azzal, hogy az lenne a megoldás, hogy a INVOICE_NUMBER_NOT_UNIQUE üzenetbe tegyük bele az eredeti tranzakciósID-t, mivel ez eső után köpönyeg megoldás, ráadásul a felhasználó is fog róla kapni egy e-mailt, mint tudjuk...

Pont ezért javasoltam, hogy a számlaszám kerüljön feltüntetve magasabb szinten is (ha nem is a requestSignature-ben, de legalább a boríték XML-ben), továbbá a NAV oldali feldolgozás során az egyik legkorábbi lépés legyen a számlaszám tárolása az XML validáció után, ill. a queryInvoiceCheck funkció legyen kibővítve, hogy magáról a számláról (nem a tranzakcióról) adjon vissza státuszt és ne csak annyi legyen, hogy true vagy false.

Ezekkel a módosításokkal szerintem el lehetne kerülni a not unique hibát, hiszen ha nincs transactionId-m a manageInvoice híváskor, akkor nem küldeném újra az egész tranzakciót, hanem lekérdezném a sikertelen tranzakcióban lévő számla(k) státuszát.

[DrotosTot]

@nbeeps2, @lvitya586: sokat beszéltünk erről tegnap a kollégákkal és alapvetően elhibázottnak tartjuk, hogy a beküldött adatszolgáltatás státusza számlaszám alapján nem kérdezhető le adózói oldalról.
A számlaszámmal szemben támasztott követelmény jogszabályi szinten jelenik meg ("kihagyás és ismétlés nélküli, folyamatos sorszámozást biztosítson"), a számla egyediségét biztosítja, ezen feltétel teljesítése nélkül a számlázóprogram alkalmatlan a használatra.
Ezzel szemben a transactionId egy belső azonosító. Értem és megértem a transactionId szükségességét a feldolgozás során (hiszen globális szinten akármennyi 1/2020-as sorszámú számla lehet), de adózói oldalon semmilyen beszédes információt sem hordoz, ellentétben a számla egyedi sorszámával.

[bcdel]

Nehéz-nehéz...

A probléma gyökere valahol itt lakik:

https://github.com/nav-gov-hu/Online-Invoice/issues/78#issuecomment-547816486

Az INVOICE_NUMBER_NOT_UNIQUE hiba az idézett eseményt, tehát hogy valójában két számla kapta ugyanazt a sorszámot, hivatott jelezni.

Ennek a beküldő oldali ellenőrzésére gyakorlatilag nincs megfelelő eszköz a protokol alapján.

A requestId, illetve a requestSignature-ban használt timestamp érdemben alacsonyabb layeren van, a token sem releváns és visszakérdezhető. A token alapján beküldött tranzakcióhoz a tranzakcióID el tud veszni.

A számlához a saját belső rendszerben (elvileg könnyedén generálható és ) elérhető számla létrehozás timestamp csak a helyesbítő/storno esetén releváns adat.

A hibaüzenet képzésére a számlaszám egyediségének ellenőrzése elegendő, de egy számlaszám alapján annak eldöntése, hogy ezt most mi küldtük-e be vagy sem (feltéve egy adózónál több számlázóprogram, netán hibás működés, konfigurálás esetét), sajnos nem elegendő.

A számla xml tartalmának ellenőrzése 2.0-ig bezárólag az esetenkénti nagybetűsítés (meg talán whitespacetelenítés) miatt szintén nemtriviális feladat. A számla adattartalmába betenni olyan adatot ami a számlán nem szerepel (tehát valami metaadat) szintén gyanús, hogy nem támogatott/engedett. (Ha ezen a ponton tévedek és belefér, akkor ez megoldást és választ adhat)

Az összes valamire esetleg használható releváns audit adat ebből a szempontból a insCurUser lehetne. Ha azt sikerül garantálni, hogy egy Technikai usert csak egy számlázó program használ.
A insDate itt sem használható ilyen célból.

Ha valahol, akkor itt az audit adatok között kellene lennie egy lekérdezhető mezőnek, amit a beküldő ad meg, eléggé egyedi (véletlenszerű, alacsony valószinűséggel előforduló, timestamp, vagy hash stb...) adat, ami alapján be tudja azonosítani, hogy a számlaszám alapján a számla ehhez a beküldő programhoz vagy egy másikhoz kötődik-e. És persze a lekérdezhető mezőt valahol meg is kellene/lehetne adni a számlabeküldő tranzakcióban, amit aztán boldogan használhatnánk.

Azért csak a számla alapadatait felhasználva, majd amikor névtelen magánszemélyek tucatjai 1 mosoly=5 Ft egyenszámlákat kapnak, nem lehet majd beazonosítani.

[nbeeps2]

@bcdel > A számla adattartalmába betenni olyan adatot ami a számlán nem szerepel (tehát valami metaadat) szintén gyanús, hogy nem támogatott/engedett. (Ha ezen a ponton tévedek és belefér, akkor ez megoldást és választ adhat)

Az additionalInvoiceData taggal ez megvalósítható. ;)

[NTCA-developer]

Sziasztok!

Az eredeti kérdésre a válasz: timeout után csak 5 perc múlva kérdezd le a tranzakciók listáját. A DB-ben 5 perc van a kommitra, ezért a 4 perces időtartam még adhat fals eredményt.

Az @nbeeps2 által használt módszerben a 4-es kvázi felesleges, az 5-ös lesz a nyerő akkor, ha kellően későn (a /,manageInvoice-hoz képest legalább 5 perc múlva) történik a kérés.

[gajzi]

Sziasztok!

Az eredeti kérdésre a válasz: timeout után csak 5 perc múlva kérdezd le a tranzakciók listáját. A DB-ben 5 perc van a kommitra, ezért a 4 perces időtartam még adhat fals eredményt.

Az @nbeeps2 által használt módszerben a 4-es kvázi felesleges, az 5-ös lesz a nyerő akkor, ha kellően későn (a /,manageInvoice-hoz képest legalább 5 perc múlva) történik a kérés.

Szia,

A legnagyobb jóindulattal kérdezem: sokadszorra kerülnek elő ilyen aknák, mint ez az 5 perces feldolgozás. Az országban rengeteg fejlesztő, üzemeltető kínlódik nap, mint nap ezekkel a problémákkal, próbál sokadik nekifutásra leprogramozni valamilyen megoldást, hiszen ahogy pl.: a #378 -as issuet zártátok,
"Az INVOICE_NUMBER_NOT_UNIQUE hiba kapcsán azt szögezzük le, hogy nekünk kötelességünk az egyediséget ellenőrizni minden esetben, akkor is ha ugyanattól a technikai felhasználótól jön a beküldés, akkor is ha lassulás van, mindig. A vevő oldali lekérdezések kapcsán éppen a kliens oldal kampányol a 100%-os, garantált egyediség mellett. (ezt egyébként a következő telepítés meg is valósítja, felfutó jelleggel) Nem fogadjuk el azt kritikaként, hogy a duplikált adatbeküldés a mi hibánk lenne. (már a nevében is benne van, hogy beküldés, mi pedig nem küldünk magunknak adatot) A hibakezelés minden aszinkron folyamat része kell hogy legyen, akkor is ha a szerver leterhelt. Attól még hogy nem kaptál időben választ a beküldésre, nem feltétlen jelenti azt hogy a beküldés sikertelen, ezt már többször, több helyen tárgyaltuk. Ha ettől függetlenül valaki így működik, az viselje annak a következményeit. A 2.0 óta van lehetőség ennek az esetek a szép kezelésére, ez pedig a tranzakció listázás. Ugyan ezen okból kifolyólag visszautasítjuk azokat a megjegyzéseket is, amik azt implikálják hogy ezzel mi plusz költséget generálunk bárkinél is."
ennek kezelése a mi dolgunk, de ha ilyen meglepetések jönnek fél, egy év után, ez nem megvalósítható.
Valahol le vannak kommunikálva ezek a "specialistások", vagy így morzsákban kapjuk őket?

[nbeeps2]

@NTCA-developer "Az eredeti kérdésre a válasz: timeout után csak 5 perc múlva kérdezd le a tranzakciók listáját."

Az 5 perc kapcsán nekem nem egyértelmű, hogy

• magát a queryTransactionList operációt futtassam 5 perccel a timeout után ÉS/VAGY
• a queryTransactionList-ben szereplő től-ig időablakot állítson 5 perccel a timeout után?

Például: Ha a ManageInvoice 11:25-kor történt, akkor mi lenne a javasolt időablak, amire le kéne kérnem a tranzakciók listáját?
11:25-11:30?

[jozanesz]

@NTCA-developer

Az eredeti kérdésre a válasz: timeout után csak 5 perc múlva kérdezd le a tranzakciók listáját. A DB-ben 5 perc van a kommitra, ezért a 4 perces időtartam még adhat fals eredményt.

Ennek figyelembe vételével kérem az _1.6.6 Válaszidő, timeout_ fejezetet átfogalmazni érthetőre.

A szerver jellemzően 200ms alatti válaszidőkkel szolgál ki. A szinkronhívások blokkoló timeout értéke 5000 ms. Kérjük, hogy kliens oldalon a fenti értéket meghaladó válaszidőt kezeljék csak időtúllépésként!
Az abszolút timeout értéke 60 sec. Ha egy adatszolgáltatásra nem érkezik válasz a 60 másodperces timeout miatt, még nem jelenti a beküldés sikertelenségét.

1. Mit jelent a blokkoló timeout?
2. Mivel a küldő szolgáltatás is bármilyen okból megszakadhat, fontos, hogy a ManageInvoice megkezdéséhez _is_ tudjuk viszonyítani szükség esetén. Persze ez sem triviális az alkalmazott protokollok miatt, mert figyelembe kellene venni pl. DNS és proxy általi lehetséges késleltetéseket. Jól értem-e, hogy az említett 5 percet a 60 sechez kell hozzáadni, így ha a ManageInvoice kérés NAV gatewayéhez (?) érkezése után 6 perccel kezdeményezett QueryInvoiceData nem ad vissza tranzakcióazonosítót adott számlaszámra, akkor az később sem fog (az adott ManageInvoice kéréshez)?

[NTCA-developer]

Sziasztok!

@nbeeps2 Az első opciót mondom. Tehát úgy néz ki a folyamat, hogy hívtál a /manageInvoice végpontra, már vársz 1 perce, amikor a határvédelem elterminálja a TCP kapcsolatod. A szolgáltatásnak innentől még 4 perce van (mivel a tranzakció timeout 5 perces) elmenteni a beérkező számla adatot ami ott vár a memóriában, hogy aztán majd elindulhasson a feldolgozása. Ha ez sikeres, akkor a szerver válaszol ugyan, de ezt te már sosem kapod meg, mivel a kapcsolatod amin figyeltél korábban bezárult. Ekkor, tehát a /manageInvoice hívás kezdeményezésétől számított 5 perc végeztével már hívhatod a /queryTransactionStatus lekérdezést. Hogy ebben mi legyen a lekérdezési intervallum, tőled függ. Én ökölszabályként ráhagynám a dupláját, tehát az elmúlt 10 percet nézném.

@jozanesz A blocking timeout értéknek a szinkron hívásban van jelentősége. Azt az intervallumot jelöli, amennyi idő az adott szálnak rendelkezésre áll, hogy a JDBC poolból kivegyen egy használható kapcsolatot. Ha már tele van a pool és senki sem enged el egyetlen kapcsolatot sem 5000 ms-ig, akkor lép fel a blocking timeout. (eddig ilyen az éles működésben nem is volt egyébként, a pool már volt telített de mindig szabadult fel elég erőforrás hogy megkezdődhessen a DB művelet) A második kérdésedre igyekeztem a fenti részben válaszolni. Kérlek jelezd ha nem sikerült.

@gajzi kritikájával a legteljesebb mértékben egyetértek. Ennek szerintem is abszolút az interfész dokumentációban volna a helye, feketén-fehéren, csakhogy. (mert csakhogy mindig van, és már vagy tizedjére próbálom megfogalmazni, hogy PC maradjak) Szóval ez ingoványos terep, ugyanis ennek az IF doksiban történő leírásához meg kellene találni azt a jogszabályi értelmezést, amivel mindenki egyetért. Historikusan ez az oka, hogy ezt még mind a mai napig nem ugrottuk meg. Neki fogok futni újból, csak adjatok egy kis időt.

[nbeeps2]

@NTCA-developer : rendben így módosítottam a kódot, remélem a következő üzemszünet esetén már nem lesz ilyen üzenetem vagy jóval kevesebb, meglátjuk. Köszönöm. Részemről (mint indító) zárható a topik.