[Q&A] Invalid XML

[omachtandras]

Sziasztok,

éles rendszer. Tudom, annak nincs itt támogatása, de az éles supporttal kapcsolatban lesújtó a tapasztalatunk, így ha itt van érdeklődés szívesen adok infokat a számláról, ha nincs, akkor zárom az issue-t. :) Ma az egyik ügyfelünknél olyan számlaadat szolgáltatást töltött volna le a szoftverünk, ami az xml validáción elhalt. Ilyeneken: invoiceMain invoice invoiceLines line lineAmountsNormal lineVatRate vatPercentage = 0.270000

• numeric value out of bounds (<5 digits>.<4 digits> expected)

  invoiceSummary summaryNormal summaryByVatRate vatRate vatPercentage = 0.270000

• numeric value out of bounds (<5 digits>.<4 digits> expected)

Közben kiderült, hogy másik cég is érintett, náluk ilyen probléma van: invoiceMain invoice invoiceLines line lineAmountsNormal lineNetAmountData lineNetAmount = 25000.0000

• numeric value out of bounds (<18 digits>.<2 digits> expected) lineNetAmountHUF = 25000.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) lineVatData lineVatAmount = 6750.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) lineVatAmountHUF = 6750.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) lineGrossAmountData lineGrossAmountNormal = 31750.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) lineGrossAmountNormalHUF = 31750.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) invoiceSummary summaryNormal summaryByVatRate vatRateNetData vatRateNetAmount = 75000.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) vatRateNetAmountHUF = 75000.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) vatRateVatData vatRateVatAmount = 20250.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected) vatRateVatAmountHUF = 20250.0000
• numeric value out of bounds (<18 digits>.<2 digits> expected)

És egy harmadik is: incomplete data - InvoiceData invoiceMain invoice invoiceLines line lineAmountsNormal lineVatRate vatPercentage = 0.270000

• numeric value out of bounds (<5 digits>.<4 digits> expected) invoiceSummary summaryNormal summaryByVatRate vatRate vatPercentage = 0.270000
• numeric value out of bounds (<5 digits>.<4 digits> expected)

És még sok... sorba jönnek a jelentések... Másnál is jelentkezik a probléma? Nálunk soha nem volt még ilyen gond, és tegnap óta mi nem változtattunk ezeknél a rendszereknél semmit. Lehet, hogy a tegnap esti frissítés okozza? "Online Számla rendszer karbantartása 2024.03.07. 19.00 – 19.30"

[renced42]

Kedves @omachtandras

Mivel ez fontos ha küldesz egy TR ID-t akkor ránézünk. Minden számlánál előjön a probléma vagy csak specifikus ügyfeleknél?

[omachtandras]

Szia,

látok sikeres bejövő, kimenő számla letöltéseket sok adatbázisban. Látok olyat is, hogy már letöltött bejövő számlákat mára és utána jön hiba. OPG számla letöltésből is látok már sikerest, ráadásul pont olyan helyen, ahol utána hibás xml érkezett.

Egy érintett számla: 2024-BV/003120 tr_id : 4I43UMR0FUU5V0VF ins_date : 2024-03-08T08:11:11Z ;

András

Kedves @omachtandras

Mivel ez fontos ha küldesz egy TR ID-t akkor ránézünk. Minden számlánál előjön a probléma vagy csak specifikus ügyfeleknél?

[omachtandras]

Közben mi is nyomoztunk. Úgy tűnik hogy xsd valid az xml. Nem az fogja meg, hanem a Java bean validation, mert az xsd validálásban a fractionDigits -re a trailing zero-k nem számítanak, a Java bean-ben meg igen.

Nem tudom, hogy ez eddig miért nem jött elő, tényleg volt-e valami változás NAV oldalon? Ti az adatokat külön tároljátok és újra összerakjátok mindig az xmlt? Ebben történhetett változás?

[csangonzo]

Sziasztok!

Nálunk is hasonló a helyzet, ami érdekes, hogy egy régebbi számlánál jött elő, tehát előtte és utána is jöttek be sikeres kimenő/bejövő számlák. Nekünk az első hiba UTF-8 conversion során volt. Ami érdekes, de lehet csak véletlen egybeesés, hogy az érintett számla sorszáma a fent említettel (2024-BV/003120) egyező formátumú 2024-10/******.

(Két serviceünk is fut egy python és egy rust számlabetöltő service és mind a kettő ugyan ezen a ponton ugyan olyan hibával akadt meg.)

[laladisc]

Sziasztok!

Nekünk is jelezték az ügyfelek, hogy bejövő számla letöltésekor a program hibaüzenetet dob 1-1 számla esetében. Nem valid xml-t kapunk vissza a BASE64 decode után. Amit eddig láttam, ott az xml deklaráció hibás, konkrétan ez található az XML fájl deklarációs részében: ?<InvoiceData xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.nav.gov.hu/OSA/3.0/data">

[jeezy1984]

Sziasztok! Csatlakozok az előttem szólóhoz. Nekünk is egyre több ügyfelünk jelzi hogy nem tudja letölteni a bejövő számlákat. Nálunk konkrétan több esetben az ékezetek miatt hasal el. A NavOnline felületén belépve szépen látszanak az ékezetek de lekérdezve már hibás karakterek vannak benne. Próbálkoztunk több online és offline xml megjelenítővel is, és mind érdekes karaktereket mutat az ékezetek helyén.

[renced42]

Kedves @omachtandras és többiek.

Elviekben, most egy az egyben azt kapja vissza a kliens amit eddig beküldött. Eddig is így volt csak más volt a módszer az adatok összeállítása tekintetében.

Kedves @laladisc Amit küldtél az gyanús, küldenél erre RID-et, mert megnéznénk. A ? jel az elején az véletlen?

[laladisc]

Nem-nem. Pont az a baj hogy ott van az elején és így értelmezhetetlen az XML fájl. Reqiest id-m a következő: K24_AAN20240308113854

[renced42]

Nem-nem. Pont az a baj hogy ott van az elején és így értelmezhetetlen az XML fájl. Reqiest id-m a következő: K24_AAN20240308113854

Kedves @laladisc megnéztem a kérdéses response tartalmát amit visszaadtunk. A base64 tartalom jó a benne lévő XML-el semmi baj, a kérdőjel nincs a base64-ben benne, ha van akkor az nálatok kerül a kibontás után elé. Az XML fejléc is jó, ha valami miatt baj is lehet az az XSD validátorotok miatt lehet problémás, ugyanis a beküldött XML állományban a beküldéskor a fejlécből hiányzó névterek a tag-ek ben vannak felsorolva, ami teljesen szabványos, még ha nem is túl gyakran lát ilyet az ember.

  <taxpayerId xmlns="http://schemas.nav.gov.hu/OSA/3.0/base">xxxxxxx</taxpayerId>
              <vatCode xmlns="http://schemas.nav.gov.hu/OSA/3.0/base">x</vatCode>
              <countyCode xmlns="http://schemas.nav.gov.hu/OSA/3.0/base">xx</countyCode>

@omachtandras nálatok még jobb A headerben is van egy névtér: <InvoiceData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.nav.gov.hu/OSA/3.0/data" xmlns:b="http://schemas.nav.gov.hu/OSA/3.0/base">

Meg a tag-ekben is(lásd fent). Ami nem azonos a hederben megadott névtér definícióval.

Tehát az XML-ek jók, kliens oldalon kell faragni. A különbség az tegnap óta, hogy a requestben a bitre pontos és azonos beküldött állományt adjuk vissza.

[omachtandras]

Tehát az XML-ek jók, kliens oldalon kell faragni. A különbség az tegnap óta, hogy a requestben a bitre pontos és azonos beküldött állományt adjuk vissza.

Köszönjük. Faragunk. Jó lett volna, ha ez nem ennyi idő után jön ki. :) :(

[EPluribusUnum]

@renced42 , itt nincs feltűntetve hogy a backend működés változott: https://onlineszamla.nav.gov.hu/informatikai_valtozasok A tegnapi karbantartással került ki az újítás hogy most már a feltöltővel bitre egyező xml van letöltésnél?

[renced42]

@renced42 , itt nincs feltűntetve hogy a backend működés változott: https://onlineszamla.nav.gov.hu/informatikai_valtozasok A tegnapi karbantartással került ki az újítás hogy most már a feltöltővel bitre egyező xml van letöltésnél?

Köszi a jelzést tényleg nincs kint, továbbítom.

Igen, így van illetve a státusz lekérdezésnél lett optimalizáció bevezetve a gyorsabb kiszolgálásért, de a leírásban majd szerepel.

[renced42]

Sziasztok! Csatlakozok az előttem szólóhoz. Nekünk is egyre több ügyfelünk jelzi hogy nem tudja letölteni a bejövő számlákat. Nálunk konkrétan több esetben az ékezetek miatt hasal el. A NavOnline felületén belépve szépen látszanak az ékezetek de lekérdezve már hibás karakterek vannak benne. Próbálkoztunk több online és offline xml megjelenítővel is, és mind érdekes karaktereket mutat az ékezetek helyén.

Kedves @jeezy1984 Javaslom, hogy a karakterkonverziót, ne csak küldéskor, hanem fogadáskor is végezzétek el ahol beolvassátok a célrendszerbe az adatokat.

[csangonzo]

Sziasztok! Csatlakozok az előttem szólóhoz. Nekünk is egyre több ügyfelünk jelzi hogy nem tudja letölteni a bejövő számlákat. Nálunk konkrétan több esetben az ékezetek miatt hasal el. A NavOnline felületén belépve szépen látszanak az ékezetek de lekérdezve már hibás karakterek vannak benne. Próbálkoztunk több online és offline xml megjelenítővel is, és mind érdekes karaktereket mutat az ékezetek helyén.

Mi is ezt látjuk, régebbi számla februári lekérésnél tökéletesen hozta az ékezeteket, most ugyan ezt lekérdezve az ékezetek helyett értelmezhetetlen karakterek állnak: "lineDescription": "BOG�DI R�CSOS CS�SZ�R DAR.VF. CCA 300G". Az invoiceData-t base64 decodeoljuk, ha compressed_content_indicator true, akkor gzip decompresseljük, majd az így kapott byteokat stringé alakítjuk utf-8 decode-al - az utolsó utf-8 decode-nál száll el a folyamat. ~2 éve megy így a service, most találkoztunk először ezzel a problémával.

[renced42]

Kedves @csangonzo

Nézzétek meg, hogy mit küldtök be a BASE64-ben. Mi ezt megfelelően lekezeljük az OSA-ban amikor kibontjuk az adatokat.

Példa, hogy is kellene:

Java

• byte[] decodedBytes = Base64.getDecoder().decode(str);
• String decodedString = new String(decodedBytes,"UTF-8");

PHP

• $input = base64_decode('');
• $input_encoding = 'UTF-8';
• echo iconv($input_encoding, 'UTF-8', $input);

[jeezy1984]

@csangonzo Ugyan ez a helyzet nálunk is. Delphi + JAVA-ban fejlesztünk. A Delphi eddig tökéletesen működött Base64.Decode paranccsal, de ezt most teljesen elfeküdt. Át kellett tenni Byte-okba majd onnan visszakódolni. Így működnek az ékezetek, de volt még 1-2 dolog amit meg kellet változtatni (bár ez már a mi sajátosságunk volt). A gépeken az OS, a Delphi, a Java nem volt frissítve, egyszerűen csak jött ez a hiba (ráadásul több ügyfélnél egyszerre ... valamikor tegnap este volt az első aki jelezte). Nem tudom mi változott odafent... de remélem ez segít valamennyit.

[laladisc]

Ezentúl akkor a karakterkódolást is figyelni kell mert ahogy beküldik, úgy kapjuk vissza a számlát ha jól értem?

[renced42]

Ezentúl akkor a karakterkódolást is figyelni kell mert ahogy beküldik, úgy kapjuk vissza a számlát ha jól értem?

A specifikáció szerint a beküldendő adat karakterkódolása UTF-8. Igen e szerint kell dekódolni is.

[csangonzo]

Az érintett számlák lekérésénél decode("utf-8") helyett decode("iso8859_2") oldotta meg a problémát nálunk.

[renced42]

Kedves @csangonzo Igen mert ti abban a készletben éltek, ezért is van az, hogy a beküldött állományban rombuszok meg kérdőjelek vannak az ékezetes betűknél.

[EPluribusUnum]

Online_Szamla_interfesz specifikacio_HU_v3.0.pdf 1.6.3 : "Az adatbázisba mentés és a válasz a kérésben megadott encodingtól függetlenül mindig UTF-8 lesz".

Ez a fix UTF-8 válasz lett most csendben megváltoztatva mindenféle előrejelzés nélkül. Most már az xml beküldő oldaltól függ a letöltött xml karakter kódolása.

Ez súlyos breaking change! Azonnali visszaállás kellene az előző backend verzióra, és pár hónap teszt és átállási időszakot adni.

[jsz66]

Csatlakozom az előttem szólóhoz. Péntek óta próbáljuk javítgatni a folyamatosan előjövő problémákat és amikor azt gondoltuk rendben, akkor mindig van egy újabb. Az ügyfelek nálunk jelentkeznek és azt nehezen értik meg, hogy olyan változtatás történt, amiről fogalmunk sem volt, nemhogy felkészülünk előre! Úgy érzem, jelenleg katasztrófális a helyzet.

[Macskafarka]

Az ilyen helyzet elkerülése miatt ezt az egészet részletekbe menően jogszabályban kellene szabályozni, ahol a változásra felkészülési időt kell biztosítani.

[NyBela]

Annyit jó lenne tudni, hogy várható a visszaállítás, vagy mindenki oldja meg ahogy tudja!? Kérünk visszajelzést!

[renced42]

Kedves Kollégák!

Jelen pillanatban nem várható visszaállás.

[lvitya586]

Az ilyen helyzet elkerülése miatt ezt az egészet részletekbe menően jogszabályban kellene szabályozni, ahol a változásra felkészülési időt kell biztosítani.

Nem ártana valami felettes szerv is, ami kordában tartja ezeket a lókötőket. :)

[jeezy1984]

Kedves Kollégák!

Jelen pillanatban nem várható visszaállás.

Ezt ha kérhetném gondolják át újra, mert több száz ügyfelünk több ezernyi számlái közül guberálunk egész nap és próbáljuk kitalálni a hibásan beküldött számláknál ki hogy küldte be. És ugyebár erre a "hibára" nem igazán számlázhatunk munkadíjat az ügyfeleink felé ... vagy esetleg a NAV kifizeti az erre fordított időnket?

[EPluribusUnum]

@jeezy1984 . Nem számít hogy ki küldi be. Az számít hogy milyen az xml header a letöltött számlában. Ha van benne "encoding", akkor azt kell használni, egyébként maradt UTF-8.

@renced42 az itteni https://github.com/nav-gov-hu/Online-Invoice/issues/1088#issuecomment-1985953054 UTF8 égetés nem helyes már. Helyett bele kell olvasni a bináris elejébe, kinézni a kódolást, és utána azt használni a komplett dekódoláshoz.

[EPluribusUnum]

Amikkel eddig találkoztam. Nincs xml header. -> UTF-8 van xml header, de nincs encoding -> UTF-8 van xml header és van encoding -> encoding használata.

Eddig látott encoding-ok : UTF-8, ISO-8859-2, WIN1250. És bizots vagyok benne hogy ennél jöbbféle encoding is előfordulhat még. @renced42 , erre ki lehetne adni egy statisztikát hogy jelenleg a feltöltők milyen encoding-okat használtak, hátha valami egzorikusra is fel kell készülni, ne akkor kelljen kapkodni, amikor már szembe jött és probléma van.

[EPluribusUnum]

TIL hogy az xml attribútum értékeknél az aposztrof is elfogadott, nem csak a macsakaköröm, azaz lehet encoding='utf-8' és encoding="UTF-8" is.

[omachtandras]

@renced42 az itteni #1088 (comment) UTF8 égetés nem helyes már. Helyett bele kell olvasni a bináris elejébe, kinézni a kódolást, és utána azt használni a komplett dekódoláshoz.

@renced42, kaphatunk megerősítést, hogy ez így helyes? Ha igen, akkor bekerülhet a dokumentációba is?

[jeezy1984]

Amikkel eddig találkoztam. Nincs xml header. -> UTF-8 van xml header, de nincs encoding -> UTF-8 van xml header és van encoding -> encoding használata.

Eddig látott encoding-ok : UTF-8, ISO-8859-2, WIN1250. És bizots vagyok benne hogy ennél jöbbféle encoding is előfordulhat még. @renced42 , erre ki lehetne adni egy statisztikát hogy jelenleg a feltöltők milyen encoding-okat használtak, hátha valami egzorikusra is fel kell készülni, ne akkor kelljen kapkodni, amikor már szembe jött és probléma van.

Jó a tipp az esetek többségében, de van két számla fejlécem kikódolva: * <?xml version="1.0" standalone="yes"?>

... illetve * ... Semelyikben sincs encoding szóval UTF8 kéne legyen. DE NEEEM ... az egyik UTF8 a másik win1250 >:( Azon kívül hogy "megpróbálom dekódolni és ha hibára megy akkor újra próbálom dekódolás nélkül" nincs más ötletem. *itt xml kódok lennének de nem jeleníti meg ...

[EPluribusUnum]

@renced42 , jó lenne ha a számla metaadatok között (InvoiceDigest) a feltöltő szoftver azonosítója is elérhető lenne. Így könnyebben lehetne felismerni a rentiens eseteket és kezelni azokat.

[renced42]

Kedves Fejlesztő Kollégák!

Megvizsgáltuk a visszaállás lehetőségét. Valószínűleg még a mai napon vissza tudunk állni, ez nem jár leállással. Jelzem, ha megtörtént.

[vikhorvath]

Sziasztok!

Előre is elnézést, de ezt már nem tudom szó nélkül hagyni. Szóval hogy a kinek a milyével a csalánt... már megint...

A helyzet az, hogy le vagyon írva a doksiba, hogy mit és hogyan, hogy mennyire pontos, vagy nem, azon most lépjünk túl hamar. (nyilván pont azért is van sok pontatlanság amiről beszélek) Kijön egy határidő, pl. hogy fél év múlva már csak ilyen, meg olyan feltételeknek megfelelő számlákat fogad be a NAV. De mivel a sok semmirekellő sz*rik az egészre, és küldi be a szemetét évek óta, ezért születik egy olyan belső döntés, hogy jó, befogadjuk a nem megfelelő számlákat is, megoldjuk házon belül. Ebbe szépen belekényelmesedik mindenki, ráadásul egy része még azt is hiheti, hogy nagyon király cuccot csinált, soha egy WARN, egy ERROR (ja hát ha csak küldi a szemetét, és soha egy státuszt nem kérdezett le a beküldött számláiról...) Csak nagyon-nagyon halkan mondom, hogy ezek szerint nem azt kapom vissza, amit a beküldő feltöltött.

Talán úgy kéne ezt csinálni, hogy letelik a határidő, aztán akinek nem sikerült megugrani az adott feladatot, azt kiértesítjük kap még 1 hónapot, aztán ha így se megy, akkor büntetünk, majd megvonjuk az engedélyét...

De addig amíg erre nem képes a NAV, addig lesz szíves az eddig pluszba elvégzett munkát továbbra is elvégezni azok helyett akiktől nem akarja megkövetelni hogy megfelelően szolgáltasson adatot. Majd következő lépésben csak be kellen tartatni játékszabályokat... Ne mesélje nekem senki, hogy pl. egy METRO áruháznál nincs erőforrás arra, hogy megfelelő kódolásba küldjék fel a számláikat, esetleg egy energiakereskedő cég képes legyen kiállítani egy elszámoló számlát normálisan... (évi párszáz milliárdos bevételből csak fussa pár tíz óra programozói órabérre "pluszban")

Eddig se volt egyszerű feladat egy számlát feldolgozni... várja az ember, hogy jön a specifikációnak megfelelő válasz, aztán mégse. És a legjobb benne, hogy soha nem tudhatja, hogy holnap éppen mi lesz... És akkor itt kezdhetnék bele, hogy mennyi plusz munka ha az ember annak a bizonyosnak ezen az oldalán van. Mennyi magyarázkodás, mekkora arcvesztés, hogy már megint miért szar az amit csinál. Kinek kéne vállalni a felelősséget? (jogit, szakmait, erkölcsit, anyagit)

Ha már lendületbe jöttem, akkor azért jelzem, hogy pénztárgépeknél se jobb a helyzet. A gyártó felteszi a kezét, majd azt mondja, hogy neki van engedélye....

Így.

utóirat: ne dühöngj! :)

[renced42]

Kedves Fejlesztő kollégák!

A visszaállás megtörtént.

Update: csak az éles rendszeren.

[omachtandras]

Update: csak az éles rendszeren.

Köszönjük! Mi ugyan tegnap estére elkészültünk a módosítással, de ez így sokkal jobb, hogy nem kell sos verzióváltásra kényszeríteni az ügyfeleket. Esetleg arról kaphatunk információt, hogy mik a tervek? Be lesz vezetve a változás, csak egy későbbi időpontban? Mikorra kell elérni, hogy az ügyfeleknél kint legyen a módosítás? Hogy lehet tesztelni azt, hogy "mindent" jól kezelünk-e, mert nyilvánvalóan nem kapunk a teszt rendszerünkben mindenféle kódolásos adatot. (@EPluribusUnum felvetését támogatva, ha lesz újra bevezetés, előtte jó idővel kaphatunk listát, hogy milyen karakter kódolásokra kell számítani, milyeneket fogad be/kap jelenleg a rendszer?) Illetve @vikhorvath felvetésére visszacsatolva, van-e terv arra vonatkozóan, hogy végre rávegyétek az adatbeküldőket, hogy a nyilvánvalóan rossz gyakorlatokat szüntessék már meg végre, szolgáltassanak, ha nem is tökéletes (biztos nekünk sem sikerül ezt a szintet elérni), de egy minimálisan elfogadható minőségű adatot?

Előre is köszönöm a válaszokat.

[renced42]

Kedves @omachtandras

Ez egy olyan rejtett probléma, amire senki sem gondolt, hogy problémát okoz, viszont ezzel az átállással rávilágítottunk egy neuralgikus pontra az adatszolgáltatások tekintetében. Valahogy kezelni fogjuk, már csak azért is mert az EU-s VIDA kapcsán pontosan ugyanilyen gondokat fog majd okozni mindenkinek EU szerte, ha ez nincs megfelelően kezelve.

Egyenlőre így hagyjuk a rendszert de nem sokáig (nem egy fél évig), várhatóan 2-3 hónapig. De lesz kommunikáció, hogy mi fog történni.

Ezzel zárom is az Issuet.

[Macskafarka]

Végre valaki jól összefoglalta. @vikhorvath . A pénztárgép az jogilag más, mert ott tényleg lehet arra hivatkozni, hogy megkapta a jóváhagyást. Onnantól kezdve a jóváhagyó felelőssége. Persze az ilyen nagy, országos rendszereket nem lehet rángatni ide-oda, Sajnos ezt a Tisztelt Jogalkotónak, vagy a jogalkotás előkészítésekor kellene figyelembe vennie. A NAV ugyanúgy kapkodja a fejét a jogalkotás miatt, Mi legalább tudjuk melyik oldalon állunk. A NAV-nak egyrészt be kell tartatnia azt is, amivel szakmailag nem ért egyet, másrészt kezdeményezni kellene a módosítást. Nekem nagyon hiányzik erről a fórumról a jogalkotást képviselő PM. Úgy látszik, hogy a NAV eléggé magára van hagyva.

[szecsenyizoltan]

@Macskafarka A nagy olajosok közül talán a MOL az egyetlen aki közel azonnal küldi be a számlakat. Mind a Shell és az OMV van amikor csak hónapokkal később, felszólításra teszi csak meg. (Pár céges tapasztalat)

Remélhetőleg az online-számlát egyre többen fogják használni a számlalikvidációs folyamataikban, így lesz vevői nyomás a jövőben. Magam részéről rendszeresen riportolok az ilyen "renitens" vállalkozások felé. Feljelentés eszközével nem kívánok élni . . . még, . . . de az ilyen beszállítók a jövőben megdrágítják az üzleti folyamatokat, így gazdasági kárt okoznak a vevőiknek.

[renced42]

Amikkel eddig találkoztam. Nincs xml header. -> UTF-8 van xml header, de nincs encoding -> UTF-8 van xml header és van encoding -> encoding használata. Eddig látott encoding-ok : UTF-8, ISO-8859-2, WIN1250. És bizots vagyok benne hogy ennél jöbbféle encoding is előfordulhat még. @renced42 , erre ki lehetne adni egy statisztikát hogy jelenleg a feltöltők milyen encoding-okat használtak, hátha valami egzorikusra is fel kell készülni, ne akkor kelljen kapkodni, amikor már szembe jött és probléma van.

Jó a tipp az esetek többségében, de van két számla fejlécem kikódolva: *

... illetve * ...

Semelyikben sincs encoding szóval UTF8 kéne legyen. DE NEEEM ... az egyik UTF8 a másik win1250 >:(

Azon kívül hogy "megpróbálom dekódolni és ha hibára megy akkor újra próbálom dekódolás nélkül" nincs más ötletem.

*itt xml kódok lennének de nem jeleníti meg ...

Kedves @jeezy1984 A kérdéses számlát, ha megnézitek a webes felületen ott jól jelenik meg? Teszt rendszeren ha találtok ilyen problémás számlákat nem UTF8 hanem más WIN1250 stb... azt küldjétek meg kérlek (számlaszám, kibocsájtó), hogy mi is megnézhessük.

Köszönöm szépen!

[jeezy1984]

Kedves @jeezy1984 A kérdéses számlát, ha megnézitek a webes felületen ott jól jelenik meg? Teszt rendszeren ha találtok ilyen problémás számlákat nem UTF8 hanem más WIN1250 stb... azt küldjétek meg kérlek (számlaszám, kibocsájtó), hogy mi is megnézhessük.

Köszönöm szépen!

Kedves @renced42, igen a webes felületen jól jeleneik meg, semmi gond nincs vele. Ma kb 500 + számlán mentem végig. A nagy része már jó de még van néhány csodabogár. Egyik cégtől bejött két külön számla és egyik jó a másik nem. Bár tény hogy az egyik egy módosító a másik pedig egy egyszerűsített számla, szóval lehet két külön számlázó program állította ki őket. Csak még azt nem értem hogy ha az általad javasolt eljárással (először byte-ba majd onnan string) feldolgozással a kapott xml jó kódolással van (böngészőben és szerkesztővel is ellenőrizve), akkor a mi feldolgozónk miért tudja az egyiket rendesen ékezetesen olvasni, a másikat meg át kell alakítani külön UTF8 dekódolással. Bár ez már a mi dolgunk kideríteni, de érdekes hogy 03.08 módosítás előtti xml-ek egyikével sem volt ilyen gond.

Nagyjából egyenesben vagyunk így 2-3 nap után, de jó lenne az ilyen változásokra a jövőben kapnánk előre egy figyelmeztetést és némi felkészülési időt.

Mindenesetre köszönöm neked és mindenkinek a segítséget.

[topybear]

Sziasztok!

Nálunk is hasonló a helyzet, ami érdekes, hogy egy régebbi számlánál jött elő, tehát előtte és utána is jöttek be sikeres kimenő/bejövő számlák. Nekünk az első hiba UTF-8 conversion során volt. Ami érdekes, de lehet csak véletlen egybeesés, hogy az érintett számla sorszáma a fent említettel (2024-BV/003120) egyező formátumú 2024-10/******.

(Két serviceünk is fut egy python és egy rust számlabetöltő service és mind a kettő ugyan ezen a ponton ugyan olyan hibával akadt meg.)

Ez egy bizonyos közlekedési vállalat számlája? :) Az adómentesség magyarázatában rendszeresen illegális karaktert adnak.

[NTCA-KZJ]

Sziasztok, EDU környezetben a mai naptól az Online Számla rendszerben a teljes számlaadattartalmat lekérdező (queryInvoiceData) API operáció kiszolgálása az eredetileg beküldött adatszolgáltatásból történik (az eddig használt formátumra konvertálva). Ha minden megfelelő, akkor csütörtökön, 2024.10.03án a PROD-on is.

[omachtandras]

@NTCA-KZJ köszönjük az információt! Reméljük fel tudtunk rá kellően készülni.