XML hash hiba

[Mgeza]

A bevallás xml-je annak rendje-módja szerint felküldére került. Gondolom, akkor a beküldéskor képzett hash-ek értéke megfelelő kellett, hogy legyen, mert különben hibaüzenetet kaptam volna.
A finalize funkció után a megkapott processingid-val a querydeclarationprocessingStatus válaszul a INVALID_XML_HASH error code-t ad vissza. Ez hogy lehet? Mit ronthattam el?

[NTCA-tax]

A validáció a finalize után fut le, nem a partíciók feltöltésekor. Egy másik kérdésed kapcsán én arra gyanakszok, hogy nem a teljes adatállományra, hanem a partíciókra számoltad a hash értéket.

[Mgeza]

Az volta hiba, hogy nem a teljes állomány zip-elt formájára számoltam a hash-t. Ez ti. nem szerepel a leírásokban. Tisztelettel Michaletzky Géza NEXT Software Kft. From: NTCA-tax ***@***.***> Sent: Friday, April 24, 2026 3:56 PM To: nav-gov-hu/eVAT ***@***.***> Cc: Michaletzky Géza (NEXT Software Kft.) ***@***.***>; Author ***@***.***> Subject: Re: [nav-gov-hu/eVAT] XML hash hiba (Discussion #206) A validáció a finalize után fut le, nem a partíciók feltöltésekor. Egy másik kérdésed kapcsán én arra gyanakszok, hogy nem a teljes adatállományra, hanem a partíciókra számoltad a hash értéket. — Reply to this email directly, view it on GitHub<#206 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSQG2X4K2JWMRWZ7E4OOHD4XNXARAVCNFSM6AAAAACX2H2HLWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZQGI2DAMY>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/ANSQG2S3PY4U4PRVCC5C5MD4XNXARA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRXGAZDIMBTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android<https://github.com/notifications/mobile/android/ANSQG2U72MLWHUDBEGSARWD4XNXARA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRXGAZDIMBTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[cyraxx22]

Üdvözlet!

A jelenség nekem is ugyanaz, mint amit a témaindító jelzett, viszont én a teljes állomány zip-elt formájára kiszámított hash-el dolgozok.

Ez kerül bele a manageDeclarationUpload request contentHash részébe és ugyanezt használom a manageDeclarationPartition request signature számításánál is a signature végére fűzve a szabályok szerint.
Kipróbáltam azt a változatot is, hogy a manageDeclarationPartition request signature részébe a az adott partíció hash-ét teszem bele, az eredmény ugyanaz.

Mit értelmeztem rosszul?

üdv
Horhy László

[NTCA-JA]

[ZenonEger]

• "ugyanazt az értéket, amit egyébként a kérés contentHash mezőjébe is beírnak."
• "és ez kerül az adott ManageDeclarationPartitionRequest contentHash mezőjébe"

Kedves NTCA-JA!
A ManageDeclarationPartitionRequest-nek nincs contentHash mezője!
Nálam nincs és működik, valamint a dokumentációban sincs.
Kérem, pontosítsa, hogy mit ért alatta, mert így zsákutcába viszi a fejlesztőket!
Köszönöm!

[NTCA-JA]

Kedves @ZenonEger !
Köszönöm a helyesbítést!
Pontosítva újra felteszem majd!

[NTCA-JA]

Helyesbítem az előző hozzászólásomat. A folyamat az interfész-specifikáció (eÁFA M2M 2.0,
v1.1, 6.4.3.1 fejezet) és az API Gateway dokumentáció (2.4 fejezet) alapján:

1. A beküldendő XML végleges bájtsorozatának előállítása. A hash-számítást és a tömörítést
   ugyanerre a bájtsorozatra kell végezni.

2. ManageDeclarationUploadRequest.contentHash: a teljes, TÖMÖRÍTETLEN XML SHA3-512 hash-e
   (a hash számítása a tömörítés ELŐTT történik). Nem a gzip állományra és nem a
   partíciókra számított hash.

3. A teljes XML tömörítése egyetlen gzip bájtfolyammá.

4. A gzip bájtfolyam felosztása egymást követő bájttömbökre (partíciókra), a maximális
   partícióméret (128 MB) betartásával. A partíciókat nem kell külön tömöríteni.

5. Partíciónként egy ManageDeclarationPartitionRequest multipart kérés (body: az XML-kérés,
   file: a partíció bájtjai, application/octet-stream). Az XML-kérésben csak a
   declarationUploadId és a partition szerepel, contentHash mező nincs.

6. requestSignature: a requestId + a timestamp (yyyyMMddHHmmss, UTC) + az aláírókulcs
   összefűzése után a bemenet végére hozzá kell fűzni a kérésben szereplő octet-stream rész
   nagybetűs SHA3-512 lenyomatát; az így kapott sztring SHA3-512 hash-e (nagybetűsítve) a
   requestSignature. Ez a manageDeclarationPartition és a manageAttachmentUpload műveletekre
   vonatkozik.

7. Finalize. A hash-validáció ekkor fut le, ezért az INVALID_XML_HASH hiba a
   queryDeclarationProcessingStatus válaszában jelenik meg. Gyakori ok, hogy a hash nem a
   teljes, tömörítetlen XML-re készült (hanem pl. a gzip állományra vagy egy partícióra).

A két hash tehát eltérő célú: a contentHash a tömörítetlen XML hash-e, a partíció hash-e
pedig csak az adott partíció requestSignature-jének bemenetében szerepel. A kettő egyetlen
partíció esetén sem azonos.

[cyraxx22]

Üdv!

Köszönjük a részletes leírást a hash-ekről!

A működés nálam pontosan így megy, tehát a beküldendő XML tömörítetlen formájára számolt hash megy a ManageDeclarationUploadRequest.contentHash-ben, illetve a partícióknál a tömörített darab kiszámolt hash-e adódik hozzá a ManageDeclarationPartitionRequest kérés requestSignature értékéhez a leírtak szerint.

Maga a partíció beküldés biztosan jó, mert kaptam az XML-re vonatkozó validációs hibákat, pontosan megjelölve a hiba helyét, tehát a NAV oldalán sikerült összerakni a darabokat és kitömöríteni a tartalmat.

Arra gyanakszom, hogy az XML-hez tartozó hash előállítása előtt elmarad valamilyen XML formázási, vagy egyéb előkészület, ami viszont a NAV oldalán lefut és ezért nem megfelelő a beküldött hash.
Milyen esetleges preprocessz műveletek történhetnek a kitömörített XML-lel a NAV oldalán, ami a hash-től való eltérést okozza és ami itt, a küldő oldalon esetleg elmaradhat?
Egyébként az XML-t kompakt formában küldöm, sortörések nélkül.

Esetleg lehetséges valamiféle debug, ha az XML-t és a hozzá tartozó hash-t megadom, kiderülhet, hol a bibi?

üdv
Horhy László

[Mgeza]

Kérdés: miért küldöd sortörés nélkül? Én nem szedem ki ezeket. Másik a sortörések kiszedése előtt vagy utána számolsz hash értéket? Tisztelettel Michaletzky Géza From: cyraxx22 ***@***.***> Sent: Monday, September 28, 2026 12:52 PM To: nav-gov-hu/eVAT ***@***.***> Cc: Michaletzky Géza (NEXT Software Kft.) ***@***.***>; Author ***@***.***> Subject: Re: [nav-gov-hu/eVAT] XML hash hiba (Discussion #206) Üdv! Köszönjük a részletes leírást a hash-ekről! A működés nálam pontosan így megy, tehát a beküldendő XML tömörítetlen formájára számolt hash megy a ManageDeclarationUploadRequest.contentHash-ben, illetve a partícióknál a tömörített darab kiszámolt hash-e adódik hozzá a ManageDeclarationPartitionRequest kérés requestSignature értékéhez a leírtak szerint. Maga a partíció beküldés biztosan jó, mert kaptam az XML-re vonatkozó validációs hibákat, pontosan megjelölve a hiba helyét, tehát a NAV oldalán sikerült összerakni a darabokat és kitömöríteni a tartalmat. Arra gyanakszom, hogy az XML-hez tartozó hash előállítása előtt elmarad valamilyen XML formázási, vagy egyéb előkészület, ami viszont a NAV oldalán lefut és ezért nem megfelelő a beküldött hash. Milyen esetleges preprocessz műveletek történhetnek a kitömörített XML-lel a NAV oldalán, ami a hash-től való eltérést okozza és ami itt, a küldő oldalon esetleg elmaradhat? Egyébként az XML-t kompakt formában küldöm, sortörések nélkül. üdv Horhy László — Reply to this email directly, view it on GitHub<#206?email_source=notifications&email_token=ANSQG2WMZO2S4WLBLFUJZOL5RI7FZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGM4DMMJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18638619>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSQG2WP6VFXQJ7JZMJFKS35RI7FZAVCNFSNUABHKJSXA33TNF2G64TZHM2TGMJUGI4TOOJYHNCGS43DOVZXG2LPNY5TSOBYHAZTKONBOYBA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/ANSQG2UA3736YVMKAD3KUM35RI7FZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGM4DMMJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android<https://github.com/notifications/mobile/android/ANSQG2WFTTAG7KMQZJOS7ST5RI7FZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGM4DMMJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[cyraxx22]

Megpróbáltam, kihagytam az XML-ből a [partnerName] és az [additionalAddressDetail] tag-et is, ugyanaz a gebasz.
Ezek szerint nem itt volt a kutya elásva...

[Szildiko]

van értelme annak, ha adok neked egy xml-t ami nálam működik?

[cyraxx22]

mindenképpen van, hálás köszönet...
cyraxx22@gmail.com

[sgabor1955]

Az biztos, hogy az online számla stringre végzett hash nekem itt nem működött. próbáltam a stringbe pakolni cr,lf karaktereket, úgy se.
A hash kódólásba nincs kedvem belenézni. változott-e a végső szabvány a keccak eredeti algoritmusához képest, valami záró byte-ról olvastam valahol. Egy dolog biztosan bevált: az xml file-ra,és a gzip particióra web server php hash() függvényét használva működött a dolog. Szóval, ha van kéznél web server, azzal lehet tesztelni a saját hash értéket.

[cyraxx22]

Az a bosszantó, hogy a gzip partíció hash-e jónak tűnik, a darabok hitelesítése okés, a NAV oldalán összetudják rakni a darabokat és ki tudják tömöríteni az XML-t.
Ugyanaz a hash képző fv van használva a gzip hash és az XML hash esetén is. Kezd már marha idegesítő és frusztráló lenni a dolog.

[susanahu2-pzsu]

A szóközmentességet úgy értettem, hogy az XML tag-ek között nincs plusz szóköz, tehát az egyik tag záró > után rögtön a következő tag nyitó < jele jön. A tag-ek tartalmából nem szedem ki a szóközt. Az ékezeteket én direktben írom, lévén úgyis UTF8. HTML átkódolás elvileg akkor lenne benne, ha spec jelet vagy idézőjelet tartalmazna a név, de eddig olyan a tesztadataimban nem fordult elő. cyraxx22 ***@***.***> ezt írta (időpont: 2026. okt. 8., Cs, 10:53):

…

A sortörésmentesség az okés, de a szóközmentesség nem jelent tartalmi gondot a [partnerName] és az [additionalAddressDetail] tag-eknél, ahol valódi cégnevet és címet teszel bele? Illetve nekem van ilyen [additionalAddressDetail] : Szabadság utca 14. Itt esetleg nem lehet gond, hogy az ékezetes betűk a megfelelő HTML entitással vannak helyettesítve (jelen esetben az 'á' helyett á szerepel). Nálad ilyen eseteknél mi a helyzet? — Reply to this email directly, view it on GitHub <#206?email_source=notifications&email_token=B3A4FERYI2HXTJ5H3AXUIJT5S5I2BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGA4TCMZUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18809134>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B3A4FEQOAWEWXJAXFMMMJ3L5S5I2BAVCNFSNUABHKJSXA33TNF2G64TZHM2TGMJUGI4TOOJYHNCGS43DOVZXG2LPNY5TSOBYHAZTKONBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B3A4FEQZN3HWKFTETLKTNFT5S5I2BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGA4TCMZUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/B3A4FETWCRBKCJXB4EYKTU35S5I2BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGA4TCMZUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[cyraxx22]

Értem, köszi!