[Q&A] Tömörített számlaadat probléma szállító számla letöltéskor

[szako]

Sziasztok!

A rendszerünk ütemezetten tölti le a NAV-ból az szállítók által beküldött adatszolgáltatásokat. Az utóbbi időben láttunk többször olyat, hogy az ütemezetten letöltött XML és az utólag még egyszer lekérdezett XML eltér egymástól. Többféle szerver oldali konverziót látunk amik nem érintenek, csak feljegyeztük:

• namespace változás
• .0* értékek levágása, pl. 1.00000 -> 1
• <selfBillingIndicator> és <cashAccountingIndicator> visszatétel a fejbe, ha nem volt eredetileg
• üres tagek törlése pl. <conventionalInvoiceInfo/>

Nemrég volt egy olyan esetünk (2024.03.08), hogy a gzippelt számlatartalom "korrupt" volt letöltés után és elakadt a szerver oldali kicsomagoló rutinunk. Ha jól látom hiányzott a fájl hossz és a CRC32 érték meta adat. A Win-es 7Zip eszköz inkonzisztensnek jelezte a gzippelt tartalmat, de ki tudta csomagolni ennek ellenére. Adatlekérdezéssel később már helyesen csomagolt állományt töltött le a rendszer, amiben nem volt hiba. Ez a probléma 210000 számlaletöltés után jött elő az ügyfélnél, tehát nem gyakori probléma.

Az alábbi kérdéseim lennének:

• Az adatszolgáltatás tárolása után mennyi idővel történik meg az XML szerver oldali helyrerakása / konverziója NAV oldalon?
• Jó irány-e, hogy akkor tekintünk sikeresnek egy adatszolgáltatás letöltést, ha ki lehet csomagolni hiba nélkül?
• Adatszolgáltatáskor rátesztel (rögtön) a NAV rendszere a csomagolt állományra és csak egy későbbi fázisban konvertál?
• A NAV oldali implementáció mit vizsgál a kicsomagoláskor? (=A használt eszköz valószínűleg hibatűrőbb, mint a nálunk használt.)

Köszönöm!

[NTCA-KZJ]

Tisztelt Szako! Kérek még egy kis türelmet a válaszhoz.

[NTCA-KZJ]

Tisztelt Szako! Elméletileg a jelzett problémát a kollegáim megszüntették. Kérem, hogy erősítsd meg, ha így van. Köszönöm