Online-invoice: electronicInvoiceHash képzése

[ballonyi]

az interfész specifikáció 38. oldalán ez szerepel:
_"...az electronicInvoiceHash értéke meg kell, hogy egyezzen az invoiceData csomópont BASE64 enkódolt értékének (a megadott algoritmussal számolt) hash értékével."_

Ugyanazon tényleges adattartalmú xml fájlból készített hash számos ok miatt eltérő végeredményt adhat:

• eltérő soremelés karakter (crlf vagy cr),
• formáztott vagy formázatlan xml (plusz sortörések)
• whitespaceek vagy anélkül.

Például eltérő base64 és hash értéket kapunk:

<a><b>1111</b><b>2222</b></a>

vs

<a    >
    <b>1111</b>
    <b>2222</b>
</a>

Ez pontenciális vakriasztásokat okozhat a hash ellenőrzéskor, megnehezítve/ellehetetlenítve gépi úton történő ellenőrzést.
Az ilyen problémák kiszűrésére az xml kanonizálás szolgálna, amelyet pl. az XML Signature esetén is használnak (ld. W3C)
Javaslom előírni ennek használatát vagy még a base64 képzés előtt, vagy a base64 helyett a kanonizált invoiceData elemből kelljen hasht számolni.

[EnokhSys]

Ezt nem egészen a gyakorlatban. Az eladó feltölt egy invoiceData csomagot Base64-ben a NAV-hoz. A NAV-nál ez a csomag nem változik meg, csupán validációja történik meg ill. a hash ellenőrzés. A vevő ugyanazt a csomagot töltheti le a saját gépére. Mitől változna meg a csomag tartalma? Tehát, ha az eladó "a " formátumban töltött fel valamit, az a vevőnél mitől jelenne meg "a"-ként? De ugyanez igaz soremelésre is.

[ballonyi]

2.6.2 fejezet e) pontja szerint _"Bár az elektronikus számla, mint az adatszolgáltatás eszköze ugyan megtalálható az adóhivatal rendszerében, azonban ebben az esetben sem vállalja az adóhivatal az archiválási rendelet szerinti megőrzést. Az elektronikus számlák megőrzéséről minden esetben az adózónak kell gondoskodnia."_

Ezzel szemben a NAV oldalán olvasható tájékoztató szerint _"A számlát az adóhivatal – a számlakibocsátó részére – archiválja, így az értékesítőnek a számla elektronikus megküldésén kívül nincs más feladata."_

Ez a két mondat látszólag üti egymást.

Illetve a 2.6.1 fejezetben található egy másik mondat is: _"Az 1/2018. (VI. 29.) ITM rendelet bevezette annak lehetőségét, hogy az elektronikus számlák archiválását az adatszolgáltatásba épített és az elektronikus számla adattartalmát védő hash-kóddal is lehet teljesíteni, más, e jogszabályban felsorolt módszerek mellett."_ Szerintem ez elírás, az "archiválását" helyett "hitelességének ellenőrzését" kellene inkább. Az én fejemben az archiválás 10 évre szóló, ellenőrizhető állapotban történő megőrzést jelent, a hash alapú ellenőrzés "csak" egy a PKI-nál egyszerűbb mód a hitelesség ellenőrzésre.

A fentiek miatt nem világos hogy mit kell megőrizni. A PDF-et (ha van) azt világos hogy kell, hiszen az a NAV-nál nincs is meg. Ha majd egy ellenőrzéskor megvizsgálnak egy számlát, akkor mindenképp le kell majd tölteni hozzá a NAV-tól a beküldött adatszolgáltatást, mert

• ha a PDF az elektronikus számla, akkor meg kell nézni hogy az adatszolgáltatásban beküldött hash és felmutatott PDF fájl hash megegyezik-e.
• ha maga az adatszolgáltatás volt az elektronikus számla, akkor is le kell tölteni, és meg kell vizsgálni hogy a felmutatott invoiceData-ból képzett hash szerinti adatszolgáltatás lett-e korábban beküldve.

Úgy tűnik egy ellenőrzés nem lesz megvalósítható egy queryInvoiceData hívás nélkül, mert enélkül nem dönthető el a felmutatott XML vagy PDF valódisága. De ha meg lekérdezzük, akkor minek kell a számla kiállítójának bármilyen XML-t felmutatni, hiszen nyilván a NAV-tól letöltött példány lesz referenciaként elfogadott. Ennek fényében viszont minek a PDF-en kívül bármi mást eltenni?

[topybear]

"A számlát az adóhivatal – a számlakibocsátó részére – archiválja, így az értékesítőnek a számla elektronikus megküldésén kívül nincs más feladata." - akkor ha azt az online számlázóval hoztad létre. A fenti mondatot tartalmazó bekezdés ugyanis így kezdődik:
"Szintén az adóalanyok rendelkezésére áll a NAV Online Számlázó programja."

[EnokhSys]

Úgy tűnik egy ellenőrzés nem lesz megvalósítható egy queryInvoiceData hívás nélkül, mert enélkül nem dönthető el a felmutatott XML vagy PDF valódisága. De ha meg lekérdezzük, akkor minek kell a számla kiállítójának bármilyen XML-t felmutatni, hiszen nyilván a NAV-tól letöltött példány lesz referenciaként elfogadott. Ennek fényében viszont minek a PDF-en kívül bármi mást eltenni?

Például azért, mert minden áru- és szolgáltatási ügyletre a PTK vonatkozik, és adott esetben egy polgári peres eljárásban szükség lehet a hiteles elektronikus számlák bemutatására. Tehát, mindenkinek a saját érdeke, hogy az ügyleteiből őrizzen meg egy eredeti példányt... na meg arról nem is beszélve, ha Brúsz Willis nem tudna időben megállítani egy közelgő meteort, és elpusztulna a NAV szerverparkja, legyen miből újjáépíteni az adatokat. :-))

[ballonyi]

@EnokhSys : _"polgári peres eljárásban szükség lehet a hiteles elektronikus számlák bemutatására"_ Ez így van. Na de mikor lesz hiteles? Akkor, ha meggyőződtem, hogy egyezik a NAV-ba beküldöttel. Tehát NAV lekérdezés nélkül nem tudod használni peresítéshez, és ha jön a meteorit, és elpusztítja a NAV adatbázisát, akkor onnantól egyetlen XML számla hitelességéről sem lehet meggyőződni. Szóval a fentiekkel arra akartam utalni, hogy ha a hitelesség igazolásához elkerülhetetlen a NAV-ből történő lekérdezés, viszont akkor nem túl nagy a jelentősége, hogy van-e "házi példányom" az XML-ből. Ezzel nem azt akarom mondani hogy nem akarom megőrizni, mert ahogy a számlázó rendszer adatbázisát, a beküldött adatszolgáltatásokat is megőrzi majd mindenki...

(Ellentétben az elektronikusan aláírással aláírt PDF-el, mert ott a hitelességet igazoló aláírás a dokumentum része, önmagában ellenőrizhető, és használható peresítéshez.)

[EnokhSys]

@EnokhSys : _"polgári peres eljárásban szükség lehet a hiteles elektronikus számlák bemutatására"_ Ez így van. Na de mikor lesz hiteles? Akkor, ha meggyőződtem, hogy egyezik a NAV-ba beküldöttel. Tehát NAV lekérdezés nélkül nem tudod használni peresítéshez, és ha jön a meteorit, és elpusztítja a NAV adatbázisát, akkor onnantól egyetlen XML számla hitelességéről sem lehet meggyőződni. Szóval a fentiekkel arra akartam utalni, hogy ha a hitelesség igazolásához elkerülhetetlen a NAV-ből történő lekérdezés, viszont akkor nem túl nagy a jelentősége, hogy van-e "házi példányom" az XML-ből. Ezzel nem azt akarom mondani hogy nem akarom megőrizni, mert ahogy a számlázó rendszer adatbázisát, a beküldött adatszolgáltatásokat is megőrzi majd mindenki...

(Ellentétben az elektronikusan aláírással aláírt PDF-el, mert ott a hitelességet igazoló aláírás a dokumentum része, önmagában ellenőrizhető, és használható peresítéshez.)

Nem, ez egyáltalán nem így van.
Az 1/2018. (VI. 29.) ITM rendelet 7. §-a szerint már akkor hiteles, amikor visszakaptad a befogadási igazolást a NAV-tól. Ha pl. évek múlva peres eljárásra kerül sor, ez az XML számla eleve hitelesnek minősül. Az már más kérdés, hogy amennyiben a bíróságban felmerül a gyanú a számla hitelességét illetően (pl. hamisítás gyanúja), akkor elrendelheti a szakértői vizsgálatát, amelynek az alapja lehet a NAV-tól történő lekérdezés és összehasonlítás. Persze te is bizonyíthatod a számla hitelességét azzal, hogy bemutatod a NAV-tól kapott "request" és "response" logot, amelyben a NAV visszaigazolta a számla befogadást, benne a hash-el.
De alapvetően erre nincs szükség, mert önmagában a számla hiteles, különben sem a számlakibocsájtó, sem a számlabefogadó nem használhatná a bevallási kötelezettségeinek teljesítésére.

Sőt, tovább megyek: ha csak egy egészen picit módosítanak ezen a rendeleten, akkor az elektronikus számla emberileg olvasható változata (pdf) is hitelesnek tekinthető majd, ha annak hash-kódja is beküldésre kerül az "adatszolgáltatás mint e-számla" során (az XML-adat és ennek hash-kódja mellett).

[ballonyi]

@EnokhSys : Rendben köszönöm, igazad van. Meglep, hogy a jogszabály ezt elfogadja hitelesnek, de kétségtelen hogy ez van leírva.

[EnokhSys]

@EnokhSys : Rendben köszönöm, igazad van. Meglep, hogy a jogszabály ezt elfogadja hitelesnek, de kétségtelen hogy ez van leírva.

Nagyon szívesen.

[NTCA-supporter]

Sziasztok!

Csak 1 plusz mondat a témához. A comletenessIndicator = true eseteknél (adatszolgáltatás az elektronikus számla) fenti okokból mi is gondoltunk ilyenre. De ezeknél a számláknál mindig az eredeti adatszolgáltatásban lévő lesz visszaadva a queryInvoiceData lekérdezésben (kimenő és bejövő lkeérdezésnél is), az eredeti formázással, így a hash érték helyes marad.
Üdv