Online-Invoice
Online-Invoice copied to clipboard
nav-gov-hu
[Q&A] QueryInvoiceDataResponse téves választ ad ütemzavar esetén. Hogyan lehet elkerülni vagy mit használjak helyette?
A kérdés, amire választ szeretnék kapni / The question I would like to be answered Rövid és tömör leírása a kérdésnek. / A clear and concise description of the question. 2021.06.28-án üzemzavar volt az éles rendszerben. Lassan és problémásan mentek be a számlák. 1.) A ManageInvoice által kapott tranzakció azonosítóval indítottam QueryTransactionStaus-t, ami megszakadt. 2.) 10 perc várakozás után ráindult egy QueryInvoiceData ami jelentette, hogy nincs bent a számla, ugyanis a válaszban üres volt az invoiceDataResult. 3.) Ráindítottam egy MangeInvoice-ot, az viszont hibára futott: INVOICE_NUMBER_NOT_UNIQUE.
A queryTransactionList-tet nem használom, ezzel akartam megoldani. Az ajánlott 10 percet is ki vártam. Úgy tűnik a QueryInvoiceData lassulás esetén nem megbízható. Hogyan kellet volna csinálnom, vagy mit kellet volna helyette tennem?
1.)Az első tranId: 3F261HNNZSD39PBL Az első requestId: UjXmzMpQEEe8PsTQfRTjWg 2.) A queryInvoicedata requestId: uToU05pdGk6ZYRZAGgwIzg 3.)A hibára futott tranId: 3F26EVG9FYLHXHZR
Szia @betasofthu ! A fenti eset akkor fordulhat elő, ha elsőre befogadtuk az adatszolgáltatást, azonban az aszinnkron feldolgozása nem történt meg 10 perc alatt. Ilyenkor a queryInvoiceData nem adja vissza a számlát mert nem dolgoztuk fel. Viszont a queryTransactionStatus ilyenkor visszaadná, hogy feldolgozás alatt. Így szerintem azzal kellett volna próbálkozni, amíg az végállapotba nem kerül. Üdv
Köszönöm a választ! A queryTransactionStatus megszakadt 503 GENRAL ERROR hibával. A 10 percet biztosan kivártam, mert ezt már tudtam, hogy ki kell várni. Ennek ellenére nem adta vissza a számlát a queryInvoiceData. Valószínűleg 10 perc után sem volt feldolgozva. Sajnálom mert a queryInvoiceData egyszerű volt, de ezek szerint üzemzavar esetén nem használható.
Sziasztok!
Tudom, hogy itt nincs éles rendszer support, de szeretném, ha nyoma lenne a mai esetnek. Az éles support felé nem fogunk fordulni, mert legutóbb is kétszer egy hónap válaszidő után sem jutottunk még oda el, hogy megkaptuk volna azokat az információkat, ami alapján talán kiderülhetett volna, hogy mi történt, és ha mi hibázunk annak ellenére, hogy a NAV által kommunikált elvárások szerint próbáljuk kezelni ezt az esetet, akkor mit kellene máshogy csinálnunk.
Ma 9.30kor egyik ügyfelünknél nagyobb mennyiségű számla került kiállításra. A beküldés során a számlák nagy része gond nélkül beküldésre került, néhány beküldésre azonban Connection timeout volt a válasz. 10 perccel a beküldés után rákérdezve az általunk ismer TR azonosítóra már azt a választ kaptuk, hogy INVOICE_NUMBER_NOT_UNIQUE. Visszakérdezve a számlaszámra az egy teljesen másik tranzakción került rögzítésre, olyan tranzakcióval, ami a mi logunk szerint nem általunk indított. :) De a számla az, amit mi küldtünk be, így átálltunk arra a tranzakció számra lekértük, hogy legyen nyoma a NAV oldalán is a visszakérdezésnek és zártuk az ügyet.
Hónapok óta nem volt ilyen (vagy nem jelezte felénk ügyfél), de ismét kiderült, hogy Connection timeout esetén biztosan előfordulhat az INVOICE_NUMBER_NOT_UNIQUE, csak nem tudjuk miért. :)
Tuti hogy NAV-nak az infrastruktúrája egy rétegében van request repeat, erre utaló jel már itt is volt : https://github.com/nav-gov-hu/Online-Invoice/issues/870 Azaz egyetlen kliens kérés hatására is lehet REQUEST_ID_NOT_UNIQUE vagy INVOICE_NUMBER_NOT_UNIQUE hiba.
Sziasztok!
Azért ez nekem nagyon érdekesnek tűnik: "Visszakérdezve a számlaszámra az egy teljesen másik tranzakción került rögzítésre, olyan tranzakcióval, ami a mi logunk szerint nem általunk indított. :)" Ha ilyen előfordulhatna, akkor nagyon nagy lenne a baj. Ez a tuti, hogy van request repeat nem tudom honnan jön, de nem is akarom továbbvinni ezt a szálat. Próbáljatok meg hasonlóan nagy mennyiségű számlát beküldeni tesztrendszerbe, hátha sikerül reprodukálni. Többet nem tudok tenni ezügyben. A témaindítóra továbbra is annyit tudok, hogy ha van transactionId és azt lekérdezve még nincs végállapotban a számla, akkor addig hiába kérdezed queryInvoiceData operációval.
Üdv
Úgy tudom, hogy lesz valamikor a hónapban egy nagyobb teszt számlázás és beküldés, majd meglátjuk. De sok reményt nem fűzök hozzá, a teszt nem szokott úgy szakadni, mint az éles (szerencsére mostanában az éles sem gyakran).
Sziasztok! Ezzel kapcsolatban van még hibajelenség? Ha nincs, kérlek zárjátok. Üdv
Sziasztok! Zárom az issut. Ha van még probléma, kérlek nyissatok újat. Üdv