Online-invoice: [Q&A] Hibás karakterkódolás esetén mi a teendő?

[omachtandras]

Egyre több ügyfelünk dolgozza fel a bejövő számláit oly módon, hogy a szoftverünk a NAVtól letölti őket, majd automatikusan feldolgozza, az ügyfél pedig ellenőrzés után érvényesíti a rendszerben.
Sajnos elég sok visszajelzést kapunk, hogy értelmezhetetlen szövegek szerepelnek az átadott / átvett adatok közt, amely hibák arra vezethetőek vissza, hogy az átadó oldal hibás karakter kódolást használ.

Azt gondolom, hogy a kérdésem elsődlegesen NTCA-TAX tudja megválaszolni, de lehet, hogy technikai oldalról is kapok információt / ötletet / segítséget.

A kérdés pedig: mi ilyenkor a teendő? A partner adatszolgáltatása ilyenkor hibásnak minősül, annulálnia és újra fel kellene adnia? Mivel érvelhet az ügyfelünk, hogy elérje a javítást (ha más nem, legalább a jövőben kiállítandó bizonylatok esetén)? Egyáltalán az ügyfelünknek kell ilyenkor "harcolnia", vagy a NAV oldalán is foglalkoztok ezzel a problémával? Problémának tekintitek egyáltalán?

Az egyértelmű, hogy a számlaképen látható és az átadott adat eltér egymástól.

[Rossi73]

Tudnál mondani egy példát, mi lehet olyan eltérés a beküldő részéről, ami nem értelmezhető a lekérdező oldalon? Ha UTF-8-ban küldi be, akkor abban elég sok karakter megtalálható... Ha meg nem UTF-8, akkor elutasítja a rendszer a beküldést hibás karakterek miatt (vagy tévedek, és nem UTF-8-cal is lehet beküldeni? - sose próbáltam...)

[omachtandras]

UTF-8-ban küldi be, de mondjuk LATIN-2es az adatbázisa és a konverziót nem végzi el.
Itt egy olyan példa, ami könnyen dekódolható emberi szemmel is, de mégis látszik, hogy az ékezetes karakterekkel gond van:
KARBANTARTáSI DíJ 2020. OKTóBER

[Rossi73]

A kérdésed teljesen jogos, mert ha a 3.0-ban az adatszolgáltatás maga az elektronikus számla, akkor igencsak elvárható lenne, hogy az adatok karakterről karakterre azonosak legyenek mind beküldéskor, mind lekérdezéskor... Megjegyzés: nem csak a 3.0 miatt lenne persze érdemes ezt javíttatni valahogy a beküldő oldalán...

Egyébként a partnered mint vevő jelezte ezt már az eladó felé, hogy javíttassa ő a programját? Nem tudom, milyen népes a számlázó programot fejlesztők tábora, de valószínűleg ez a probléma nem a legnagyobbakat érinti, és valószínűleg nem az ily módon beküldők vannak többségben. Ha a partnered jelzi a problémát az eladó felé, és az ő fejlesztője javítja, akkor előbb-utóbb magától megszűnik - szerintem. Vagy ha nem sikerül elérnie a javítást, akkor jelezheti a NAV felé, a NAV pedig fel tudja venni célzottan a kapcsolatot az adott fejlesztővel, hogy javítsa. Semmi bünti, meg irgum-burgum, csak kérés, hiszen a NAV támogatólag lép fel ilyen esetekben.

Az is lehet, hogy most pl. 10 szoftverfejlesztőről beszélünk összesen... Meg az is lehet, hogy aki épp érintett ebben a kérdésben, olvassa a GitHub-ot, és magától is "észbe kap", hogy "hopp, hát ez pont rólam szól", és máris készíti a javítást... :)

[omachtandras]

Meglepően nagy cégekről is szó van. Olyanokról, akikkel szemben a befogadó ügyfél sokszor esélytelen.
Volt/van köztük közüzemi szolgáltató, akivel elvileg sikerült dűlőre jutni (de csak azért, mert a fejlesztők közt találtunk kontaktot), éppen most várjuk az első számlát már a jó kódolással, de számos multi is van, akikről tudjuk, hogy elég nagy számban állítanak ki számlákat és az ügyfélhez érkezők mind ilyen hibát tartalmaznak.

Azért is tettem fel a kérdést, mert az ügyfeleinknél nincs arra erőforrás hogy szélmalomharcot vívjanak. Ha nem tudnak valami olyan ütős érvet szerezni a megkeresések alátámasztására, amitől úgy érzik a nagyok is, hogy ezzel a kérdéssel foglalkozni kell, akkor nem fognak beleállni és nem fog javulni az adatszolgáltatás minősége.

[Rossi73]

Ja, ha multi, akkor ő diktál... Kíváncsian várjuk a NAV állásfoglalását e kérdésben...

[renced42]

Kedves @Rossi73 , @omachtandras Sajnos ezek a karakterek valid UTF-8 enkódolt karakterek. Vagyis ezek nem lesznek invalidok beküldéskor.
Ennek visszakósolását nektek kellene megoldani, hogy helyesen jelenjenek meg a karakterek. Az már egy másik kérdés, hogy honnan tudjátok, hogy milyen kararakterkészletre kellene dekódolni az adott szöveget.

A fenti példában pl a KARBANTARTáSI DíJ 2020. OKTóBER szövegből KARBANTARTáSI DíJ 2020. OKTóBER lesz dekódolás után.

[omachtandras]

Kedves @renced42, a NAV a saját oldalán elvégzi ezt a konverziót? Tehát, ha az Online számla felületen lekéri az ügyfél a számlát, akkor a dekódolás utáni szöveget fogja látni? És a NAV revizor is, amikor összeveti a számlaképpel? És a 3.0-hoz tervezett xslt-n alapuló megjelenítés esetén hogy fog kinézni a számlakép?

Az nem kérdés, hogy valid UTF-8 karaktereket ad át a partner, a probléma az, hogy nem azt, ami a számlaképen szerepel, hanem annak valamilyen "kódolt" változatát, aminek dekódolásával el lehet tölteni időt és energiát, csak kérdés, hogy ez így helyes-e. (Szélsőséges példa, de akkor beküldhetek mindent olyan kínai jelekkel, amelyek valid utf-8 karakterek, és csak egy egyszerű dekódolást kell végezni, hogy azt lássa az ember, amit a számlaképen?)

[renced42]

Kedves @omachtandras tudsz Teszt rendszeren ilyen számlát mondani?

[omachtandras]

Kedves @omachtandras tudsz Teszt rendszeren ilyen számlát mondani?

Kedves @renced42, nem tudok sajnos, ezek éles rendszerből letöltött adatok. Nincs rálátásunk / elérésünk a teszt rendszerhez az ő nevükben (ha regisztráltak egyáltalán), így nem tudjuk megnézni sem, hogy ezek a beküldések esetleg ott szerepelnek-e.

Amit tudok tenni, az annyi, hogy éles rendszerből érkező adatoknál tranzakció azonosítót és - ha szükséges - számlaszámot kérek be és továbbítom Nektek.

[bcdel]

Szerintem az nem lehet a probléma, hogy latin kódolásban van és nem végeznek rajta utf8-ra konverziót. Sőt...

Ránzésére ilyen jellegű hiba kétféle módon állhat elő.

1: Jól feltöltött adatok utf8ban, a letöltő pedig latin kódolásban olvassa. Ekkor így néz ki latin kódolásban az utf8 bytestream.
1.a: Ezen az sem segít ha átkonvertálja latin-ból utf8-ra és utf8-ban nézi :)

1.b: A megoldás (latin rendszerek esetén) utf8-latin konverzió, és voila, olvasható lesz.

Tippem szerint nem ez az eset áll fenn.

2: A feltöltő az utf8 karaktereiből készült byte streamen alkalmaz egy latin-utf8 konverziót és ezt tölti fel. Ez technikailag valid utf8 miközben nem magyar karaktereket tartalmaz. Ekkor a letöltő látja, hogy ez rossz. És jogosan reklamál. (Bár technikailag megoldható a dekódolás, de nem elvárható, mert nem a letöltő oldalon van a hiba, és nem is automatizálható könnyedén)

A
"KARBANTARTáSI DíJ 2020. OKTóBER "
példa jól mutatja, hogy a 2-es eset fordulhatott elő, ami nagybetűsítés után nem nagybetűsítette az 'Á' és 'Ó' stb. karaktereket, mert azok nagybetűsítéskor már valójában 'Ã' '¡' '³' karakterek voltak (dupla-utf8 kódolás szerint).

Itt az adatfeltöltőnek kellene javítania.

---

ps: (a fenti szóhasználatomban a 'latin' hogy most latin1 vagy latin2 az szinte lényegtelen, ezért is nem mengem bele ilyen részletekbe)

[omachtandras]

@bcdel - köszönöm a pontosítást és a megerősítést, hogy az adatfeltöltő oldalán van a probléma.

@NTCA-tax - mi a véleményed az esetről? Mi a NAV álláspontja, terve arra vonatkozóan, hogy az ilyen problémák megoldódjanak? Tudtok ebben valamit lépni / tudunk esetleg mi (az ügyfelek) segíteni?

[bcdel]

Demoként beküldtem a teszt rendszerbe V2: egy ilyen hibás számlaadatot. A hiba a customerName mezőben van.
trid: 35GH03XVBP87I5QR
Nyilván lehet, hogy ott ahol előfordul, ott minden adat így rossz.
Szerintem ilyen hibára bukkanhatott omachtandras kolléga.

[renced42]

Kedves @bcdel @omachtandras megnéztem ami be lett küldve, igen ilyen hibáról van szó.
Mivel a NAV nem konvertál semmit (nem is teheti) a beküldött adatszolgáltatásokban, sem visszaadásukkor ez így marad meg bennük. Viszont az is tény, hogy ha olyan helyre teszi ezt a dolgot, amit egyébként kiterítünk tranzakciós rendszerbe, Netán meg is mutatjuk valamilyen felületen (pl: tételsorok megnevezésébe) az zavaró lehet,hát ha még vissza kell, adni csakúgy mint a rendes adatszolgáltatásban. Pl elad 10 db árvíztűrőtükörfúrógépet (árvíztűrőtükörfúrógépet) az nem olyan szép a letöltött excel exportban. Mert ez így alapvetően szemét a rendszerben. Át kell gondolni, hogy ezzel mit lehet tenni és hogyan lehet ezen segíteni, ha egyáltalán lehet. Jelentkezni fogunk, hogy mi az álláspont ezzel kapcsolatosan.

[NTCA-supporter]

Sziasztok!
Mivel ahogy fentebb is volt róla szó, NAV oldalon mi semmit nem konvertálhatunk. Már az uppercase koverzió is ki lett vezetve, nemhogy ilyenek.
Zárom az issuet, erre szerveroldali megoldást nem tudunk adni.
Az ügyfelekkel érdemes konzultálni.
Üdv

[omachtandras]

Sajnálom, elég sok ilyen kódolási problémás számlát látunk ügyfeleknél bejövő oldalon.
Akkor marad nekik a harc, hogy értelmes adatok legyenek az adatszolgáltatásban.

Köszönöm azért az együtt gondolkodást.

Bocsánat, még annyit, hogy én nem is vártam volna el, hogy a NAV konvertáljon, inkább egy warningban gondolkodtam volna, hogy jelezze a rendszer, hogy itt problémás lehet az adatszolgáltatás a számlaképhez képest.