Online-invoice: Néha elérhetetlen a NAV-os szerver?!

[robozb]

Úgy tűnik :(

[connorhu]

Érdemes néha ránézni a főoldalra: https://onlineszamla.nav.gov.hu/home
"Online Számla rendszer karbantartása
2020-09-23 09:43
Az Online Számla rendszer rendkívüli karbantartási munkálatok miatt 2020. szeptember 23-án 9:49 óra óta nem elérhető. A karbantartás végeztével frissítést teszünk közzé.

Szíves megértését és türelmét köszönjük."

[gajzi]

Érdemes néha ránézni a főoldalra: https://onlineszamla.nav.gov.hu/home
"Online Számla rendszer karbantartása
2020-09-23 09:43
Az Online Számla rendszer rendkívüli karbantartási munkálatok miatt 2020. szeptember 23-án 9:49 óra óta nem elérhető. A karbantartás végeztével frissítést teszünk közzé.

Szíves megértését és türelmét köszönjük."

Az a baj, hogy nem érdemes. Már korán reggel sem volt elérhető, nem tudták kiszolgálni a kéréseket a saját 1 perces timeoutjukon belül, így minden kérés "504 Gateway Time-out" vagy "503 Service Unavailable" válasszal pattant le 60 másodperc várakozás után, így belassítva minden próbálkozót. Majd 9:49-kor ki is lőtték le a kiszolgálást, így onnantól kezdve, egész nap (12:30 és 12:45 között volt egy időszak, amikor részlegesen teljesítették a kéréseket) lepattantak a kérések. Ezt a bejegyzést, ami 9:43-as időponttal került fel, valójában 12:43 körül tették fel. Addig a 9:23-as bejegyzés élt, ami szerint lassulás van, pedig nem is üzemelt a szolgáltatás. Ezeknek a tájékoztatásoknak a nagyközönség felé nem sok értelmük van, inkább olyan szaguk van, mintha valaki a főnöke felé akarná lefedni magát.
A legszebb az egészben, hogy minden frissítés, karbantartás után ugyanez van, mi már eleve terveztünk pont ezért egy hibaüzeneteket begyűjtő napot 09.22-23-ra és be is jött a tervünk. Azért ez valahol elég szomorú.

[pvmon]

Mi is ezt tapasztaltuk, Ráadásul egy ügyfél azt mondta, hogy ne kábítsuk, mert felhívta a NAV ügyfélszolgálatát és szerintük minden rendben üzemel...
Mindez az után, amikor már ki is volt írva valóban jókora késéssel hogy nem megy, de így legalább mondhattuk neki, hogy nézze már meg a kiírást...

[DrotosTot]

Minket az zavar, hogy nincs egy olyan felület, ahol az interfész adatszolgáltatás _előtt_ lekérdezheti a rendszer állapotát és ha nem megy, akkor meg se próbál adatot szolgáltatni.
Ehelyett a NAV befogadja, fel is dolgozza az adatokat, csak senki sem tud róla. Másnap meg megy a mazsolázás a duplikált adatszolgáltatások tranzakciói után...

[pvmon]

Pont erről írtam egy másik topikban, jó lenne a támogatás, legalább ilyenkor e-mailt ne küldjenek már az ügyfélnek, aki utána minket hívogat.
https://github.com/nav-gov-hu/Online-Invoice/issues/377

[connorhu]

Azért szerintem a queryServiceMetrics endpointból lehet látni ha probléma van.

[nbeeps2]

Ez ugye most nem komoly, hogy munkaidőben telepítitek a frissítést???

[nbeeps2]

Szerintem Nemzetbiztonsági szempontból igen aggályos ez az egész NAV Online szerver így ahogy van. Ez most egy tudatos leállás, de lehetett volna egy külső támadás is, ami megbénítja az egész ország gazdasági működését. Szörnyű.

[EPluribusUnum]

Szerintem Nemzetbiztonsági szempontból igen aggályos ez az egész NAV Online szerver így ahogy van. Ez most egy tudatos leállás, de lehetett volna egy külső támadás is, ami megbénítja az egész ország gazdasági működését. Szörnyű.

Elárulnád hogy egy NAV OSZ leállás hogy bénítaná meg a gazdaságot? Semmilyen téren nem függ a számlázás a NAVtól. Még a doksiba is beleírták hogy tilos olyan megoldás szállítani ami függne tőle. Tudni kell számlát kiállítani ha nem megy a rendszer. Nincs sem törvényi, sem technológiai függőség a NAV OSZ rendszertől.

[nbeeps2]

Használtad a NAV ingyenes online számlázót? ;) Na ugye... Pár százezer felhasználó hoppon...

[EPluribusUnum]

Használtad a NAV ingyenes online számlázót? ;) Na ugye... Pár százezer felhasználó hoppon...

A kézi számlatömb továbbra is használható ha nem megy a rendszer. Magyarán nem marad hoppon, hanem szimplán felkészületlen. Vagy mondhatjuk azt is hogy visszatér arra, ahogy NAV OSZ előtt számlázott.
Ez ugyanolyan eset mintha a szamlazz.hu esne ki, vagy az internet szolgáltatás szűnne meg kábel vágás vagy karbantartás miatt. A kézi/papír alap továbbra is használható, arra kell visszatérni.

[nbeeps2]

Kézi számla? ezt most Te sem gondoltad komolyan...

[fzoli15]

Inkább azért aggályos nemzetgazdaságilag ez az egész, mert nemzetgazdasági szinten iszonyatos mennyiségű értékes erőforrást pazarlunk el minden egyes ilyen üzemzavarnál arra, hogy kliens oldalon, a saját rendszereinkben ellenőrizzük és javítgassuk az adatokat, magyarázkodjunk az ügyfeleinknek, stb. Ez már nagyon sokadik ilyen eset. Rengeteg számlát befogadott most is a rendszer bőven az interfész specifikációban meghatározott timeout időn túl. Persze ők ezzel nem tudnak mit kezdeni (https://github.com/nav-gov-hu/Online-Invoice/issues/178), ezért oldjuk meg mi összességében 1000-szer vagy 10000-szer nagyobb költségből, amit senki nem fog megfizetni, mert semmilyen értéket nem teremtünk vele, csak kidobjuk az ablakon.
A másik hasonlóan bosszantó dolog az állandó verzióváltások, amihez újra és újra rengeteg szoftvert kell kliens oldalon átírni, sok-sok munkaórával, ami helyett értékteremtő munkát is végezhetnénk.

[HWKF]

Mi egyszerűen lekezeltük az INVOICE_NUMBER_NOT_UNIQUE hibaüzenetet. Ekkor automatikusan lekérdezzük a számla adatait és összehasonlítjuk a beküldött számla XML és lekérdezésben kapott számla XML néhány fontosabb elemét. Ha egyezik, akkor bejegyezzük a számla lekérdezésben visszakapott adatszolgáltatás státusz adatokat. Ha az rendben, akkor a számla adatszolgáltatása is rendben van.

[omachtandras]

Mi is ezt csináljuk, általában. Jól is működik, de most én úgy látom, hogy HTTP/1.0 404 Not Found jön rá tegnap este 21:10től, vagyis amikorra elvileg helyreállítottak mindent. Lehet, hogy a megoldás része volt, hogy ezt meg lekapcsolták?

(Ez egyébként magával vonja azt is, hogy nem tudjuk a szállító számlákat letölteni és feldolgozni sem...)

Más is tapasztalja ezt a problémát?

Mi egyszerűen lekezeltük az INVOICE_NUMBER_NOT_UNIQUE hibaüzenetet. Ekkor automatikusan lekérdezzük a számla adatait és összehasonlítjuk a beküldött számla XML és lekérdezésben kapott számla XML néhány fontosabb elemét. Ha egyezik, akkor bejegyezzük a számla lekérdezésben visszakapott adatszolgáltatás státusz adatokat. Ha az rendben, akkor a számla adatszolgáltatása is rendben van.

[gajzi]

Mi egyszerűen lekezeltük az INVOICE_NUMBER_NOT_UNIQUE hibaüzenetet. Ekkor automatikusan lekérdezzük a számla adatait és összehasonlítjuk a beküldött számla XML és lekérdezésben kapott számla XML néhány fontosabb elemét. Ha egyezik, akkor bejegyezzük a számla lekérdezésben visszakapott adatszolgáltatás státusz adatokat. Ha az rendben, akkor a számla adatszolgáltatása is rendben van.

Milyen módszerrel kérdezitek le a számlát? Amikor mi ennek korábban nekifutottunk, valamelyik elem (pl.: tranzakciós log) sosem működött belőle.

[connorhu]

@HWKF Az INVOICE_NUMBER_NOT_UNIQUE hibaüzenet létrejöttének folyamatát felderítettétek? Mi a pontos folyamat amivel előáll? Az ügyfelek nálam is szoktak panaszkodni rá (1 havonta kb 1 számlánál), de én eddig azt hittem, hogy a software stackemben előforduló hiba ami a NAVnál lévő terhelt időszakok alatt fordul elő. Ezek szerint lehet, hogy rajtam kívülálló a probléma.

[EPluribusUnum]

@gajzi lényegében ilyesmi :

`
case STATUS_ABORTED: {

if (isInvoiceNumberNotUnique(res)) {
    QueryInvoiceDataResponse dataResponse = queryInvoiceData(null, invoiceNumber, OUTBOUND);
    InvoiceDataResultType inv = dataResponse.getInvoiceDataResult();
    if (inv != null) {
        byte[] navInvoiceXml = inv.getInvoiceData();
        try {
            InvoiceHead navHead =
                getInvoiceHead(navInvoiceXml, inv.getAuditData().getOriginalRequestVersion());
            if (invoiceHead.equals(navHead)) {
                String navInvoiceTransId = inv.getAuditData().getTransactionId();
                transactionId = navInvoiceTransId;
                String msg = getString("transactionSwitch", Client.class, getDefaultLocale(null));
                logMsg = getMsg(resp) + "\n\n(" + msg + ")";                    
                state = QUERY_FAILED;//kérdezzen újra a feldolgozást, de már új tranzaciozn_id-vel legközelebb                                      
            }
            else {
                String msg =
                    getString("transactionSwitchNotPossible", Client.class, getDefaultLocale(null));
                String diff = "" +
                    "NAV:\n" + objectToString(navHead, false) + "\n\n" +
                    "xml:\n" + objectToString(invoiceHead, false) + "\n\n";
                logMsg = getMsg(resp) + "\n\n(" + diff + msg + ")";
            }
        }
        catch (RuntimeException e) {
            error(e);
            String msg = getString("invoiceXmlProcessError", Client.class, getDefaultLocale(null));
            logMsg += "\n\n(" + msg + ": " + e.getMessage() + ")";
        }
    }
    else {
        //technikai felhasználónak nincs joga a számla adat lekérdezéshez
        String msg =
            getString("transactionSwitchNotPossible", Client.class, getDefaultLocale(null));
        String diff = "" +
            "NAV:-\n\n" +
            "xml:\n" + objectToString(invoiceHead, false) + "\n\n";
        logMsg = getMsg(resp) + "\n\n(" + diff + msg + ")";
    }
}
break;`

[HWKF]

Ha a queryTransactionStatus lekérdezés visszakapja ezt a hibát a válaszban, akkor automatikusan indít egy queryInvoiceData lekérdezést, abban benne van a számla XML tartalma és az érvényes adatszolgáltatás tranzakciós adatai. Ha a lekérdezett XML és beküldött XML főbb adatai egyeznek, akkor a queryInvoiceData-ban visszakapott TransactionID alapján lekérdezzük a státuszt a queryTransactionStatus operációval. Az így visszakapott státuszt rögzítjük be a számla adatszolgáltatásához.
Próbálkoztunk a queryTransactionList operáció megvalósításával, de az egyelőre félbemaradt.

[EPluribusUnum]

Mi a pontos folyamat amivel előáll?

@connorhu . Beküldesz egy számlát. Timeout időn belül nem válaszol a NAV. Így a kliens oldal sikertelennek tekinti a beküldést és újra megpróbálja később. Viszont a timeout ellenére a NAV befogadja az első kérést. A későbbi ismételt feladásra jön az INVOICE_NUMBER_NOT_UNIQUE válasz.

Magad is tudod "reprodukálni" debugban. Sikeres NAV válasz van, a válasz megérkezés után, de anak feldolgozása előtt kilövöd a programodat, majd újraindítod azt. Elvileg ekkor még a programod nem tud a beküldésről és próbálja újra és ekkor jün a unique hiba.

[pvmon]

Igen megkapod a INVOICE_NUMBER_NOT_UNIQUE üzenetet lekezeled, de a kedves NAV újabban küld egy e-mailt a adózónak, hogy kétszer szolgáltatott adatot a program azonos számlaszámmal.
Az ügyfélszolgálatuk meg azt mondja, hogy ez a program hibája...

[HWKF]

@pvmon Mondjuk szerintem NAV oldalon is lehetne kezelni, hogy két különböző tranzakcióban érkező, karakterről karakterre (kis nagybetű eltérések figyelembevétele nélkül) megegyező XML az nem két adatszolgáltatás, főleg ha ugyanazon technikai felhasználó ugyanazon módon küldi be. Az ügyfél felé e-mailben szerintem csak akkor kéne jelezni, ha a két adatszolgáltatás tartalmilag eltér egymástól vagy másik technikai felhasználó küldi be.

[nbeeps2]

HWKF megfogalmazta a lényeget. Megint elérkeztünk ahhoz a témához, hogy a NAV-nak kellene a fogadó oldalon egy csomó mindent megoldania, ahelyett, hogy a számlázó program fejlesztők egyesével hekkeljék a programot az INVOICE_NUMBER_NOT_UNIQUE elkerülésével...

[EPluribusUnum]

@HWKF , @nbeeps2 : Ezt már mi is felvetettük NAVnak egy korábbi jegyben. Az válaszolták hogy túlzott performance penalty lenne ez a rendszerüknek, és kénytelenek kitolni így a kliensre az esetleges unique-ból adodó problémák kezelését.

[HWKF]

@EPluribusUnum Én csak az email kiküldésre írtam. Az INVOICE_NUMBER_NOT_UNIQUE hibaüzenet nem zavar minket, mert automatikusan lekezeljük. A saját logból, meg a lekérdezett tranzakciós adatokból meg szépen látszik, hogy mi történik.
Azt nem tudom, hogy az ügyfeleknek mit kell tenniük, mit kell reagálniuk a levélre.
A NAV oldalára bejelentkezve a számlaszámra rákeresve meg tudják nézni az adatszolgáltatás állapotát. Amely a mi esetünkben meg fog egyezni azzal amit a programunkban mutatunk a felhasználóink felé.

[pvmon]

@HWKF , @nbeeps2 : Ezt már mi is felvetettük NAVnak egy korábbi jegyben. Az válaszolták hogy túlzott performance penalty lenne ez a rendszerüknek, és kénytelenek kitolni így a kliensre az esetleges unique-ból adodó problémák kezelését.

Oké tolják ki a kliensre ami meg is oldja DE NE küldjenek emailt az adózónak. Azt nem volt gond lefejleszteniük, pedig régen nem volt ilyen email.

[EPluribusUnum]

Email küldés lekapcsolással én is egyet értek. Épp most beszéljük meg hogy milyen igényekkel nyissunk issue-t ezügyben.

[nbeeps2]

Így van, teljesen szükségtelen az e-mail. Az INVOICE_NUMBER_NOT_UNIQUE üzenetnek akkor van igazán jelentősége, ha két (vagy több) telephelyen használják a programot nem hálózatosan és nem állítanak be nyitósorszámot és mindketten mondjuk kiállítanak 1-es sorszámú számlát más tartalommal. Ilyenkor a számlázó programokban sikertelen lesz a feldolgozás, mivel nem fog átmenni a számlázó programok épített ellenőrzésen, így is úgy is tudomást szerez tehát erről az ügyfél magából a programból, így felesleges neki e-mailt küldeni. Én semmire se vagyok előrébb, ha meghekkelem az üzenetet, de az ügyfél ugyanúgy felhív a kapott e-mail miatt...

[nbeeps2]

Kicsit visszatérve a témaindításhoz, én javaslom, hogy az összes frissítés telepítést ÉJJEL VÉGEZZÉK! Ez már a sokadik olyan üzemszünet volt, hogy éjjel minden rendben volt, majd amikor bejött reggel a fejlesztő emberke és miután kényelmesen megette a kis szendvicsét elkezdte faragni a szervert és frissítgetett. Tessék az ilyet ÉJJEL csinálni!

[pvmon]

Email küldés lekapcsolással én is egyet értek. Épp most beszéljük meg hogy milyen igényekkel nyissunk issue-t ezügyben.

Én már nyitottam egyet még ez előtt a topik előtt "Email üzeneteik intelligenssé tétele" címen, hogy legalább akkor ne küldjenek emailt amikor tudják, hogy haldoklott a szerverük. Tettem ezt azért mert a heti ügyfélszolgálati telefonok a NAV szerver nem működéséről szólnak a jövő heti meg a NAV által küldött emailekről fog szólni és ez nagyon fárasztó számunkra és felesleges,
Legalább egy kis intelligenciát vihetnének bele, ha m nem is akarják kikapcsolni. A felőlük érkező hibát ne tolják már ki másokra.

[EPluribusUnum]

@nbeeps2, Éjjel végzik a frissítést, de a terhelés reggel indul be, akkor fekszenek meg.

[Macskafarka]

Nagyon zavar, hogy a NAV a mi erőforrásainkat használja ingyen arra, amit ő magának kellene kezelnie.
Lehet nekünk is kellene küldenünk e-maileket az ügyfeleknek arról, hogy a NAV e-mailje félrevezetően és alaptalanul rossz színben tünteti fel a számlázó programokat.
Persze nem fogunk, mert ennél intelligensebbek vagyunk.
A NAV simán ránk tolta az ügyfelekkel való értelmes kommunikációt, az ügyfelek azért felénk jeleznek, mert releváns válaszokat várnak ésszerű időn belül.

[nbeeps2]

"Éjjel végzik a frissítést, de a terhelés reggel indul be, akkor fekszenek meg."

Én nem így látom. Nézd meg a NAV oldalán, kint vannak a karbantartási idők visszamenőleg. 2020.06.25-én dolgoztak egyedül éjjel, az összes többi alkalommal nem éjjel történtek az updatek... Ahogy tegnap sem...

[topybear]

"Éjjel végzik a frissítést, de a terhelés reggel indul be, akkor fekszenek meg."

Én nem így látom. Nézd meg a NAV oldalán, kint vannak a karbantartási idők visszamenőleg. 2020.06.25-én dolgoztak egyedül éjjel, az összes többi alkalommal nem éjjel történtek az updatek... Ahogy tegnap sem...

18 órakor szokták kezdeni, aztán tart ameddig tart. Szvsz nincs ezzel jelenleg semmi gond, ilyenkor már kevés számla készül. A mi rendszerünkben a tömeges számlázást éjszaka szokták futtatni az ügyfelek, ha így nézzük akkor nekünk meg az éjszakai karbantartás nem jó :) Mostanra megszokták, hogy ránéznek előre, hogy mikorra van beütemezve karbantartás

[gajzi]

"Éjjel végzik a frissítést, de a terhelés reggel indul be, akkor fekszenek meg."
Én nem így látom. Nézd meg a NAV oldalán, kint vannak a karbantartási idők visszamenőleg. 2020.06.25-én dolgoztak egyedül éjjel, az összes többi alkalommal nem éjjel történtek az updatek... Ahogy tegnap sem...

18 órakor szokták kezdeni, aztán tart ameddig tart. Szvsz nincs ezzel jelenleg semmi gond, ilyenkor már kevés számla készül. A mi rendszerünkben a tömeges számlázást éjszaka szokták futtatni az ügyfelek, ha így nézzük akkor nekünk meg az éjszakai karbantartás nem jó :) Mostanra megszokták, hogy ránéznek előre, hogy mikorra van beütemezve karbantartás

Ez a 18 óra júliusig volt igaz, mert azóta addig online számlát szinte sosem küldő cég is tömegével küldi akár este 9-kor is, apróságokról, munkaruházatról, papíráruról... a számlákat és pont az ott lévő kasszások nem nagyon tudnak kezelni egy ilyen összevisszaságot, ami a napokban is volt. Januártól meg aztán főként indul a show.

[NTCA-developer]

Úgy gondolom ez a téma nem a githubra való, de ezzel együtt is van pár téma, amiről érdemes beszélni.

Az új verziók telepítését, esetleges karbantartásokat ahogy eddig is, mindig munkaidőn kívül végezi a NAV, általában 18:00 után. Tegnap és tegnap előtt nem várt incidens történt, nem a telepítés folyományaként. Ilyenkor a rendszer stabilizálása a legfőbb kérdés, ilyenkor nem lehet tekintettel lenni munkaidőre, gondolom ebben egyetértünk. Ezekben nekünk fejlesztőknek az a szerepünk, hogy mindenben segítsük az üzemeltető kollégákat, de a tájékoztatásokat nem mi végezzük, mint ahogy az ütemezésben sem mi döntünk.

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.

Erre pont jó példa az email kezelés, #377. Az email értesítés egyébként pont a duplikált adatszolgáltatás miatt történt a konkrét esetben, azonban ez az értesítés bármikor kikapcsolható (ez egy adózói profilbeállítás a felületen, amit bármelyik elsődleges felhasználó beállíthat), nem kötelező használni. Eleve azért megy email, mert az elsődleges felhasználó előzetesen azt kérte, hogy ABORTED számla esetén legyen értesítve. De erről beszéljünk a másik szálon.

A jövőbeni 3.0-ás performancia miatti aggódást köszönjük, de ettől tartanotok nem kell, most sem ez volt a probléma.

Az issuet zárom, releváns kérdésekkel/kérésekkel lehet újat nyitni és állunk rendelkezésre.

[Takika]

Email küldés lekapcsolással én is egyet értek. Épp most beszéljük meg hogy milyen igényekkel nyissunk issue-t ezügyben.

Nem ismerem teljesen az email-küldés folyamatát, de nekem az jött le, hogy csak akkor küld a rendszer levelet, ha kétszer próbálsz küldeni valamit. Ez meg a legtöbb helyen akkor van, ha a küldésnél valamilyen timeout hiba van, a kliens nem kapja meg a tranzakció azonosítót, ezért újra próbálja küldeni a számlát. Erre az a jó, és sokak által használt megoldás, hogy a számla sorszáma alapján lehet lekérdezést végezni tranzakcióazonosító nélkül is. Ha ekkor (működő NAV rendszer esetén) nem kapsz vissza számla adatot, akkor beküldheted újra. Ilyenkor nagyon jó eséllyel nem fogsz hibát (és emailt sem) kapni.

[fzoli15]

A jövőbeni 3.0-ás performancia miatti aggódást köszönjük, de ettől tartanotok nem kell, most sem ez volt a probléma.

Akkor kérjük, hogy oldjátok meg (ti = fejlesztők, üzemeltetők, NAV, akárki) véglegesen ezt a problémát, mert mindig előjön újra és újra. Ma reggel ismét elkezdődött az éles rendszerben... Tájékoztatást nem láttam, talán NAV oldalon észre sem vette senki a problémát.
Kliens oldalon kialakítjuk a javasoltak alapján a hibakezelést, ehhez köszönjük a tanácsokat. Bár talán a specifikációban is megemlíthetnétek ezt, ha már tervezetten benne van a rendszerben ez a hibalehetőség.

[fzoli15]

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.

A kollégák tapasztalatai alapján a gyakorlatban mégsem működik ez a szép megoldás: https://github.com/nav-gov-hu/Online-Invoice/issues/386
Várjuk az egzakt útmutatást, hogy mit kell tennünk kliens oldalon a probléma elkerüléséhez.

[gajzi]

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.

A kollégák tapasztalatai alapján a gyakorlatban mégsem működik ez a szép megoldás: #386
Várjuk az egzakt útmutatást, hogy mit kell tennünk kliens oldalon a probléma elkerüléséhez.

Igen, mi is ezt tapasztaljuk, akkor üzemelhetne a fejlesztő által leírt módszer, ha az üzemeltetés oldalán minden rendben lenne és mindig minden funkció működne. Nem nagyon lehet NAV független számlázást csinálni, hiszen ha éppen nem tudunk feltölteni egy számlát, akkor nem engedhetjük helyesbíteni, hiszen ezekhez plusz időbélyeg is van és a helyesbítőben jelezni kell, hogy az eredeti számla fel van-e töltve. Ez így pedig bukó. Nem tud működni a számlázás anélkül, hogy tudnánk mi a helyzet az eredeti számlával, amit pl. helyesbítenének. De szerintem ezzel nem fogunk jutni semmire, mert fejlesztők-üzemeltetők-adószakértők hivatkoznak rendszeresen a másikra egy ilyen esetben, ahogy most is láttuk.

[pvmon]

Igen, mi is ezt tapasztaljuk, akkor üzemelhetne a fejlesztő által leírt módszer, ha az üzemeltetés oldalán minden rendben lenne és mindig minden funkció működne. Nem nagyon lehet NAV független számlázást csinálni, hiszen ha éppen nem tudunk feltölteni egy számlát, akkor nem engedhetjük helyesbíteni, hiszen ezekhez plusz időbélyeg is van és a helyesbítőben jelezni kell, hogy az eredeti számla fel van-e töltve. Ez így pedig bukó. Nem tud működni a számlázás anélkül, hogy tudnánk mi a helyzet az eredeti számlával, amit pl. helyesbítenének. De szerintem ezzel nem fogunk jutni semmire, mert fejlesztők-üzemeltetők-adószakértők hivatkoznak rendszeresen a másikra egy ilyen esetben, ahogy most is láttuk.

Mi is teljesen ugyanezt tapasztaljuk ilyen esetekben és nem megoldható helyzetbe kerül a szoftver. Csak a várakozás és próbálkozás marad. Egyre többen próbálkoznak az pedig azt okozza, hogy nagyon nehezen lábal ki a NAV szerver a leállást követő időszakból. Ez jól látható volt a múlt héten. Ha reggel működött, ahogy felhasználók beértek a munkahelyükre és elkezdtek dolgozni, a szoftverek pedig bepótolni az előző napi leállás miatti felküldéseket és lekérdezéseket, akkor láthatóan emelkedett a terhelés egész addig, amíg újra nem fogadott adatot és nem adott választ a szerver. Legalábbis én ezt láttam.

[gajzi]

Igen, mi is ezt tapasztaljuk, akkor üzemelhetne a fejlesztő által leírt módszer, ha az üzemeltetés oldalán minden rendben lenne és mindig minden funkció működne. Nem nagyon lehet NAV független számlázást csinálni, hiszen ha éppen nem tudunk feltölteni egy számlát, akkor nem engedhetjük helyesbíteni, hiszen ezekhez plusz időbélyeg is van és a helyesbítőben jelezni kell, hogy az eredeti számla fel van-e töltve. Ez így pedig bukó. Nem tud működni a számlázás anélkül, hogy tudnánk mi a helyzet az eredeti számlával, amit pl. helyesbítenének. De szerintem ezzel nem fogunk jutni semmire, mert fejlesztők-üzemeltetők-adószakértők hivatkoznak rendszeresen a másikra egy ilyen esetben, ahogy most is láttuk.

Mi is teljesen ugyanezt tapasztaljuk ilyen esetekben és nem megoldható helyzetbe kerül a szoftver. Csak a várakozás és próbálkozás marad. Egyre többen próbálkoznak az pedig azt okozza, hogy nagyon nehezen lábal ki a NAV szerver a leállást követő időszakból. Ez jól látható volt a múlt héten. Ha reggel működött, ahogy felhasználók beértek a munkahelyükre és elkezdtek dolgozni, a szoftverek pedig bepótolni az előző napi leállás miatti felküldéseket és lekérdezéseket, akkor láthatóan emelkedett a terhelés egész addig, amíg újra nem fogadott adatot és nem adott választ a szerver. Legalábbis én ezt láttam.

Korrekten leírtad a múlt heti eseményeket, ha a NAV is belátná, hogy ezzel a hozzáállással, hogy mindenki oldja meg az ilyen hibákat kliens oldalon a jelenleg rendelkezésre álló eszközökkel, öngólt lőnek és a takarózás helyett megoldásra törekednének jelentősen előre léphetnénk. Jelenleg INVOICE_NUMBER_NOT_UNIQUE esetén szerintük a kliens fusson neki QueryInvoiceDigest-tel visszakérni a számlát, ami ilyen esetben sok-sok próbálkozásra sem sikerül sokszor, ha ez nem megy, akkor kérjen le egy tranzakciós logot (ami időigényes feladat), ha ez sem sikerül, akkor ismételgesse, ha végre visszanyerte a Tranzakciós ID-t, akkor pedig kérdezgesse le a számla feldolgozottsági adatait, hibákat, warningokat egy Tranzakciós státussza, amíg nem sikerül. A QueryInvoice és a tranzakciós log kérdezgetése teljesen feleslegessé válna, ha INVOICE_NUMBER_NOT_UNIQUE mellé megkapnánk a Tranzakciós ID-t amivel egyezünk, Ügyfeleink az előző hétfőn, kedden összesen 200 ilyen duplán töltött számlába futottak bele. Ahogy felvázoltad ez a múlt heti haldoklás pont elkerülhető lett volna ilyen módszerrel, felesleges lekérések elkerülésével.

[Macskafarka]

@gajzi által javasolt megoldás príma lenne!
"..ha INVOICE_NUMBER_NOT_UNIQUE mellé megkapnánk a Tranzakciós ID-t amivel egyezünk, "