Számla időbélyeg szolgáltatás

Fórumok

Sziasztok!

Tud valaki olyan szolgáltatót, aki időbélyeggel és digitális aláírással lát el PDF dokumentumokat? Konkrétan e-számlát. Van egy rendszerünk amiben már készen van a számla kiállítás, PDF generálás, online számla jelentés, a vevők kiértesítése stb. Szóval gyakorlatilag minden készen van, azt kivéve hogy a PDF-en nincsen digitális aláírás.

Keresgéltem a neten, de nem találtam olyan szolgáltatót, aki kifejezetten számla digitális aláírás szolgáltatást kínál. Mindenhol a saját számlázó programjukat, NAV jelentésüket meg adat archiválást reklámozzák. De ezekből nekem semmi nem kellene, kivéve a digiális aláírást valamilyen értelmes API-n keresztül.

(Azért került offtopic-ba mert nem találtam megfelelő kategóriát.)

Hozzászólások

> ps: ha jól tudom, akkor PDF-ben kiküldheted a számlát (mint eredeti példány) bár az igaz, hogy ez nem minősül e-számlának.

Ezt viszont Te tudod rosszul. Ezzel kapcsolatban nemrég jelent meg egy új tájékoztató füzet a NAV oldalán.

https://nav.gov.hu//data/cms558992/18_A_szamla_nyugta_kibocsatasanak_al…

Ebben a 11. oldalon világosan leírák a következőt:

> Így például elektronikus számla a kizárólag e-mailben megküldött számla, függetlenül attól, hogy a bizonylat adatai közvetlenül a számlázóprogramból kerültek az elektronikus üzenetbe vagy papíralapú számla szkennelt változataként.

Bár én itt látok egy logikai bukfencet (mert ha "papíralapú számla" akkor az már nem lehet elektronikus) de ez biztos csak elírás. A lényeg, hogy nem attól lesz elektronikus számla, hogy kinyomtatta-e valaki. Hanem az a meghatározó, hogy hogyan lett befogadva. Ha a vevő kizárólag elektronikus formában kapja meg (fogadja be), akkor az bizony elektronikus számla.

Egyébként az elektronikus számlára nem kötelező időbélyeget tenni, de ha nem teszel rá akkor saját üzleti folyamatokkal kell biztosítani a sérthetetlenségét. Erről is adtak ki újabb közleményeket, https://nav.gov.hu/nav/ado/afa/Az_elektronikus_szaml20200416.html (ez 2021 Április 16-án lett frissítve) és ott már sokkal pontosabban van megfogalmazva az, hogy mitől elektronikus egy számla:

> Az áfa előírások értelmében a számla kibocsátása ténylegesen a számla számlabefogadó részére történő rendelkezésre bocsátással valósul meg. Ennek következtében elektronikus számlának minősül az eredetileg papír alapon előállított számla is, melyet azonban nem személyesen vagy postai úton bocsátanak a befogadó rendelkezésére, hanem úgy, hogy azt beszkennelve, elektronikusan továbbítják részére. Ezért elektronikusszámlának minősül a kizárólag e-mailben, egyéb elektronikus üzenetben megküldött PDF számla is.

Itt már nem "papír alapú" hanem "papír alapon előállított" számláról beszél.

Ezek alapján arra jutottam, hogy bár nem kötelező az elektronikus időbélyeg, de eléggé erősen javasolt kategória.

Közben elkezdtem nézni a linkeket amiket küldtél:

 

* A netlock ezen oldalát én is láttam, de ott nincsenek árak. De abból kiindulva hogy "telefonos időpontfoglalás szükséges", meg a netlock kft-ről ismert általános vélemények szerint ez tutira nem olyan áron van ami nekem elfogadható.
* E-szignót hagyjuk, amit küldtél az egy windows-os program, amivel a SAJÁT kulcsoddal tudsz aláírni. Nekem API-ra van szükségem, és harmadik megbízható fél általi időbélyegzésre és aláírásra.
* A digitoll egy vicc, egy időbélyeget kínáló cég http-re teszi a honlapját??? A 13 Ft / számla nem sok egy kicsit? Egyetlen nyamvadt számla aláírásért, arhciválás meg minden nélkül?

Amit én írtam, az, hogy a _papír_ alapú számlát kiküldheted 1. példányú PDF-ben (azaz Ügyfél fogja először kinyomtatni - amennyiben akarja papíron látni). Mivel a számla elfogadható pecsét és aláírás nélkül - így gyakorlatilag semmi különbség nincs aközött, hogy a számla kiállítója nyomtatja ki és borítékolja, vagy a befogadó nyomtatja ki a PDF-t.

Azt is leírja az általad linkelt oldal, hogy az e(lektronikus) számlázáshoz elengedhetetlen a felek együttműködése. 

Ha a vevő kizárólag elektronikus formában kapja meg (fogadja be), akkor az bizony elektronikus számla. 

ez nem igaz. Az e-számlának vannak követelményei és NEM attól lesz e-számla, hogy PDF-ben érkezik!!!
 

Digitoll egy vicc? Lehet. Nézd meg, h mennyiért vállalnak mások e-számla kiállítást, kiküldést, etc. ~25-40Ft/db lesz az ár.
Számold ki, hogy mennyiért tudod hitelesen időbélyegezni a számlákat saját infrastruktúra esetén, és szerintem rájössz, hogy bár drága így - még mindíg olcsóbb, mint kompletten megoldani magadnak, mondjuk úgy havi 5-25 000db számla esetén...

Amit én írtam, az, hogy a _papír_ alapú számlát kiküldheted 1. példányú PDF-ben (azaz Ügyfél fogja először kinyomtatni - amennyiben akarja papíron látni). Mivel a számla elfogadható pecsét és aláírás nélkül - így gyakorlatilag semmi különbség nincs aközött, hogy a számla kiállítója nyomtatja ki és borítékolja, vagy a befogadó nyomtatja ki a PDF-t.

 

 De igen van! Egész konkrétan le van az írva, hogy ha a számlát a vevő tisztán elektronikus úton kapja, akkor az elektronikus számlának minősül. A törvény szempontjából egyáltalán nem számít az, hogy később kinyomtatta-e valaki! Csak az számít, hogy papíron kapta meg, vagy nem papíron.

Természetesen abban igazad van, hogy ha a számla kiállítója és a vevője is azt hazudja, hogy papíron lett átadva, akkor valószínűleg soha nem derül ki. De ez pont olyan mint az a gyorshajtás, amikor nem kapnak el. Attól még hogy senki nem vette észre, az akkor is gyorshajtás, és ha valaki sokáig csinálja akkor ki fog derülni.

Egyébként az elektronikus számlánál más különbségek is vannak. Az elektronikus számlát kötelezően elektronikusan kell tárolni. Az a cég, amelyik a vevőnek e-mailben küldi ki a számlát, de a sajátját papír alapon kinyomtatja és úgy tárolja (és pl. adóellenőrzés során papíron szolgáltatja be), szabálysértést követ el, és büntethető. És ez halál komoly, és van is akit már büntettek emiatt.

Egyébként az elektronikus számlánál más különbségek is vannak. Az elektronikus számlát kötelezően elektronikusan kell tárolni. Az a cég, amelyik a vevőnek e-mailben küldi ki a számlát, de a sajátját papír alapon kinyomtatja és úgy tárolja (és pl. adóellenőrzés során papíron szolgáltatja be), szabálysértést követ el, és büntethető. És ez halál komoly, és van is akit már büntettek emiatt.

Szerintem a félreértés ott van, hogy nem attól lesz e-számla, hogy emailben megy ki, hanem attól lesz e-számla, hogy megfelel annak a követelményeknek.

Nem értem, hogy abban hol van a probléma, hogy a kiállító a 2. példányt kinyomtatja és lefűzi magának papíron, az első példányt pedig nyomtatás nélkül elküldi emailben a címzettnek, aki ott nyomtatja ki az első példányt. (pláne, ha azzal ki van egészítve a történet, hogy évente 1x, díjmentesen az üf.szolgáltaton átvehető minden számláról a hiteles másolat - akinek erre van igénye, az bemegy és elkéri, vagy egyszerre az adóévben kiállított összes számlát)

Hol hallottál arról, hogy _ezért_ valakit megbüntettek?

A NAV értelmezése szerint tényleg képesek e-számlának tekinti az e-mailben küldött számlát. Ez egyértelműen le van írrva a 18. információs üzet (https://nav.gov.hu//data/cms558992/18_A_szamla_nyugta_kibocsatasanak_al…) 11. oldalán:

A számla papíralapon és elektronikus úton is kibocsátható. 69 Az Áfa tv-ben meghatározott fogalomnak megfelelően elektronikus számlának minősül minden olyan, az Áfa tv-ben előírt adatokat tartalmazó számla, amelyet elektronikus formában bocsátottak ki és fogadtak be. Így például elektronikus számla a kizárólag e-mailben megküldött számla, függetlenül attól, hogy a bizonylat adatai közvetlenül a számlázóprogramból kerülnek az elektronikus üzenetbe vagy papíralapú számla szkennelt változataként. A számlákra vonatkozó általános szabályok az elektronikus számlákra is alkalmazandók.

Ezzel sokan vitatkoznak, hiszen ha:

  • a számla elkészültekor az adatszolgáltatásban papír számlaként lett beküldve
  • a számlára rá van írva, hogy a megjelenési formája papír
  • a vevő a NAV onlineszámla rendszerből a számla adatokkal együtt azt is megkapja, hogy papír számla
  • esetleg magára a számlára még az is rá van írva, hogy ez nem e-számla, és csak kinyomtatva érvényes
  • a szállító nyilatkozik, hogy ő is papír alapon őrzi a számlát (már 10 éve nincsen kötelező külön eredetei és másolati példány jelölés)
  • a szállító jelzi, hogy ha a vevő nem tudja kinyomtatni, vagy csak nincs kedve hozzá és jelzi az igényét, akkor postai úton is szívesen elküldi pontosan ugyanazt (ugyanúgy aláírás és bélyegző nélkül, nem kötelező elem)
  • nincs digitálisan aláírva és időbélyeggel ellátva
  • az e-számla befogadása a felek megállapodása alapján történhet, de ha nincs ilyen megállapodás, akkor egyik fél szerint sem e-számla (erre szokták azt mondani, hogy a számla kiegyenlítésével ráutaló magatartás történt az e-számla befogadására)

akkor mi alapján állítja olyan határozottan a NAV, hogy az bizony e-számla?  De ha elfogadjuk, hogy az, akkor ez nem a kiállítóra ró plusz feladatot (hiszen a papírra nyomtatással és lefűzéssel megcsinálta amit kellett), hanem a vevő köteles gondoskodni a védelemről, azaz a vevő saját költségén elláthatja elektronikus aláírással (az ingyenes NAV hash-al már nem, de ha ingyenes megoldást keres, akkor akár az AVDH is rendelkezésre állhat).  Szóval ez a kör szerintem még nincs teljesen lefutva :) 

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

> Ha a vevő kizárólag elektronikus formában kapja meg (fogadja be), akkor az bizony elektronikus számla. 

ez nem igaz. Az e-számlának vannak követelményei és NEM attól lesz e-számla, hogy PDF-ben érkezik!!!

De igaz. Olvasd el a hivatkozott törvényeket:  Áfa tv. 259. § 5. pont.

A követelmények pedig a következők:

  • a számla eredetének hitelessége
  • adattartalma sérthetetlensége
  • olvashatósága

A minősített digitális aláírás és az időbélyegző a fenti követelmények biztosításának egyik (de nem egyetlen!) lehetséges módja. Másik módja az "üzleti ellenőrzési eljárás", ide vonatkozik a Áfa tv. 168/A. § (2) bekezdés.

Ha már kész az onlineszámla adatszolgáltatás, akkor miért nem azt használod hitelesítésre, miért keresel külön szolgáltatót?

Az Online Számla 3.0 bevezetésével lehetőség van olyan módon is e-számlát kiállítani, hogy ahhoz nem szükséges külső hitelesítési szolgáltató, nem kell fizetni az elektronikus aláírásért és az időbélyegért sem. A számlázó programnak a NAV adatszolgáltatásban kell szerepeltetnie az elkészült PDF számla ellenőrző összegét (SHA3-512 hash), ez váltja ki a hitelesítési megoldásokat. Az ellenőrző összeg bármikor lekérdezhető a NAV rendszeréből a befogadó által is, de azért a számla mellett ezt is el kell küldeni a vevőnek.
Előnyei: a jelenlegi legolcsóbb megoldás, nem kell több féllel kommunikálni, az adatszolgáltatással együtt kész a hitelesítés is, ellenőrzéséhez nem kellenek speciális szoftverek.
Hátrányai: Külföldi számla befogadónak és magánszemélynek (azaz aki nem használ NAV onlineszámlát) nem triviális a hitelesség ellenőrzése...

Ez a fajta e-számla nem keverendő össze azzal, amikor maga az adatszolgáltatás (XML) az e-számla, mert az teljesen más...

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

1/2018. (VI. 29.) ITM rendeletben teljesen konkréten le van lrva:

7. § A megőrzésre kötelezett az általános forgalmi adóról szóló 2007. évi CXXVII. törvény 10. melléklet 6. és 13. pontja szerinti adatszolgáltatással érintett, számla, számlával egy tekintet alá eső okirat (a továbbiakban együtt: elektronikus számla dokumentum) elektronikus formában történő megőrzését teljesítheti olyan módon is, amely megfelel a következő követelményeknek:

a) a megőrzésre kötelezett az adott elektronikus számla dokumentumhoz az állami adó- és vámhatóság közleményében meghatározott módon egyirányú kódolási algoritmussal előállít egy különálló, de az adott elektronikus számla dokumentummal együtt kezelt adatot (a továbbiakban: hash kód),

b) a megőrzésre kötelezett az a) pontban létrehozott hash kódot a számla és a nyugta adóigazgatási azonosításáról, valamint az elektronikus formában megőrzött számlák adóhatósági ellenőrzéséről szóló 23/2014. (VI. 30.) NGM rendeletben [a továbbiakban: 23/2014. (VI. 30.) NGM rendelet] foglaltak alkalmazásával megküldi az állami adó- és vámhatóság részére,

c) ha az állami adó- és vámhatóság visszaigazolja a b) pontban meghatározott módon megküldött adatszolgáltatás sikeres feldolgozását, biztosítható az elektronikusan megőrzött számla, számlával egy tekintet alá eső okirat adattartalmának védelme és az eredet hitelessége,

d) a megőrzésre kötelezettnek az a) pontban foglaltak alapján képzett hash kódot és az elektronikus számla dokumentumot együttesen szükséges megőriznie, ezzel igazolva az elektronikus számla dokumentum adattartalmának változatlanságát, valamint az utólagos módosítás és sérülés kizárását.

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

A kérdést se értem. Ha letárolod a számlát, akkor abból bármikor meghatározható a hash. Fordítva nem igaz.

Azt, hogy a számla módosult-e, önmagában a hash értékkel (vagy a számlával, amiből a hash egyértelműen kiszámítható), nem tudod bizonyítani.

A bizonyítékot az  szolgáltatja hogy megküldöd a NAV-nak is ezt az értéket, és ők letárolják. (Tehát konkrétan a hash-t nem te őrzöd meg, hanem ők!) Ezt az teszi hitelessé, hogy a NAV rögzíti a hash értéket és az időpontot, és ennek módosíthatatlanságát és sértetlenségét maga a NAV garantálja. Ebbe nem tudsz belenyúlni. Bár a számla PDF nincs meg a NAV-nál, de ennek sérthetetlensége is garantálva van azáltal, hogy a hash függvény egyirányú, és senki nem képes egy adott hash értékhez tetszőleges tartalmú számlát utólag generálni. Ez az egész bizonyítja, hogy az adott tartalmú számla az online számla beküldés időpontjában már létezett, és hogy azóta se változott meg.

 

Szóval a Te feladatod (a hash érték beküldésén felül) annyi, hogy megőrzöd a számlát elektronikusan, és ha adóellenőrzés van akkor odaadod a hatóságnak. De ez semmiben nem tér el a papír alapú számlától. Ott is meg kell őrizned és át kell adnod ha kérik. Csak a tárolás módja a különbség. (papír vs. pdf).

 

A törvény azonban úgy tűnik, hogy egy külön d.) pontban kitér arra, hogy a számlával együtt a hash értéket is meg kell őrizni. Hát ennek semmi értelme nincs. :-) Ha megőrzöd azt a számlát, aminek a hash-értéke megegyezik az online számla rendszerbe lejelentett értékkel, akkor az már bizonyítja hogy nem változott, és a jelentés időpontjában létezett.

Hogy ki az a harmadik fél, aki tanúsítja a hash érték létezését a számla kiállításának időpontjában, az teljesen lényegtelen. A hitelesítést végző harmadik fél személyétől teljesen független az az tény, hogy ha már megőrzöd a számlát, akkor abból egyértelműen meghatározható a hash érték. Ha valaki ezen felül még arra is kötelez, hogy a hash-t is külön eltárold, akkor az bizonyítja saját maga inkompetenciáját.

Jobban belegondolva, ez a kérdésed nem értelmes. :-) A d.) pont konkrétan arra az esetre vonatkozik (hetes paragrafuson belül van!), amikor a NAV számára megküldöd a hash-t. Ha nem NAV-val hitelesítesz, akkor az egész hetes paragrafus nem vonatkozik rád, és a d.) pont sem.

Szóval ha vonatkozik rád akkor a hash kód külön eltárolása értelmetlen (mert a számla önmagában egyértelműen meghatározza a hash-t), ha meg nem vonatkozik rád akkor meg nincs is "külön tárolt hash"  amiről beszélhetnénk (mivel akkor rendes digitális aláírás van, és azt nem tudod "nem megőrizni", illetve nem tudod külön tárolni, mivel a digitálisan aláírt dokumentum aláírásának a része).

Még tovább gondoltam. A hash kód külön eltárolása nem csak hogy értelmetlen hanem nagyon káros. Ha valaki ellenőrizni akarja a számla sértetlenségét, akkor a számla PDF-ből kell kiszámítania a hash-t, amit összehasonlít a NAV-nál tárolt értékkel. Ha emellé még külön eltároljuk a hash értéket is, akkor azzal arra csábítjuk az ellenőrzést végző személyt, hogy kihagyja a hash kiszámítás lépését, és közvetlenül a tárolt hash-t próbálja meg összehasonlítani a NAV-nál tárolt értékkel. Tehát arra csábítjuk őt, hogy szarvashibát kövessen el a sértetlenség ellenőrzésekor.

A d.) pont nem csak értelmetlen, hanem káros, és veszélyes hogy belekerült a rendelet szövegébe.

Mert hát értitek, olyan adat eltárolására köteleznek, amit TILOS felhasználni a számla sértetlenség ellenőrzésére. :D

De pont arra gondolok. Miért ne működne? A hash számolás alkalmával kizárólag a file tartalma számít, a file neve nem befolyásolja. Szerintem sincs semmi értelme a d) pontnak, de sajnos nem csak azokat a szabályokat kell betartani, aminek értelmét látom :) Mindenesetre ha az van leírva, hogy " a megőrzésre kötelezettnek az a) pontban foglaltak alapján képzett hash kódot és az elektronikus számla dokumentumot együttesen szükséges megőriznie", akkor el kell juttatnod a hash-t és a számlát is a vevőhöz. Mivel a pdf számlára, (a számlát tartalmazó pdf-re) ezt nem tudod ráírni, így vagy elküldöd neki szöveges információként a hash-t (levél szövege), amit el fog hagyni. Elküldheted neki pl. egy zip-be egybecsomagolva a számlát és a hash-t, azt a befogadók egyik része nem tudja megnyitni (mert zip helyett pdf-et vár), egy másik jelentős része kiveszi a pdf-et belőle a többit kukázza és csak egy kis része őrzi meg megfelelően. Ha csak linket küldesz neki a letöltendő számlához, akkor pont ugyan az fog történni. Viszont ha krixkrax.pdf-et küldesz neki, akkor azzal te is betartottad a d pontot, és a vevő is csak direkt tudja elhagyni a hash-t. Szerintem.

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Igen, köszi az ötletet. Ez szerintem is jó ötlet, tegnap így is csináltam meg.

Bár az azért elég vicces, hogy SHA3-512 értéket kérnek ami 64 byte, és mivel a NAV-hoz hexában kell jelenteni, ezért ebből egy 128 karakteres hex encoded hash lesz. Amit beleraksz a file nevébe és ha ezt valaki le akarja tárolni windows alatt, akkor már a file neve miatt rögtön a felére csökken a 260 karakteres path length limit-hez (másik cég másik hülyeség...)

De még mindig így a jobb, mert ha a vevődtől kérik be a számlát és így küldi el a NAV-nak, akkor a NAV nem fog külön rákérdezni hogy "na és hol van a hash"?

Egyébként ez igazából kedveskedés a vevő felé, mivel a számla + hash kód archiválási kötelezettsége a vevőt és a kibocsátót is terheli. Az igazából nem a kibocsátó feladata, hogy segítse a vevőt a hülyebiztos tárolás módjának kitalálásában. :-)

Node a kapott kódot el kell raknod, mert az a kiállítás pillanatában jött és később ezzel egyeznie kell a dokumentum hash-ének. Ha belekotorsz akár 1 bitet is, akkor változni fog a hash és így máris nem érvényes, viszont ezt onnan tudod, hogy az alap hash ott van mellette.

Nem kell "elraknod". A számlát elektronikusan kell tárolnod, és ebből bármikor ki lehet számítani hozzá a hash-t. Papír alapú számlák esetében az ennek megfelelő analóg elvárás az lenne, hogy a papíron kinyomtatott és eltárolt számla mellé nyomtasd ki és tárold el a számla bal felső sarkát külön. De minek??? Értelmetlen. (Oké az analógia sántít de a lényeget lehet érteni.)

Szokás szerint megint nagyon értelmes dokumentációt adtak hozzá... A 3.0 dokumentációban az electronicInvoiceHash leírása a 18.2.1. részben, a 24. oldalon a hatos alpontban szerepel.

> Az electronicInvoiceHash tag az InvoiceOperationType komplex típusban szerepel. A hash-lenyomat megadása opcionális sémaszinten, azonban completenessIndicator jelölő true értéke esetén kötelező. Az electronicInvoiceHash tag a típusából adódóan kiegészül egy új, kötelező attibútummal: cryptoType néven. Elfogadott értéke az adott számla completenessIndicator (adatszolgáltatás maga a számla) tag értékétől függ. Ha a completenessIndicator értéke true, az egyetlen elfogadott érték az SHA3-512. Ilyen esetben a hash értékének nagybetűs változatát kell beküldeni. Ha a completenessIndicator jelölő értéke false, az elfogadott értékek: SHA3-512, SHA-256.

A hash értékek köztudottan binárisak. Ha valaki azt írja hoyg "nagybetűs változatát kell beküldeni", akkor abból lehet sejteni, hogy itt valamilyen módon kódolni kell ezt a bináris értéket. De ez lehet base64, hexa, binhex, uuencode vagy xxencode stb.

Az xsd-ből se leszünk okosabbak:

			<xs:element name="electronicInvoiceHash" type="common:CryptoType" minOccurs="0">
				<xs:annotation>
					<xs:documentation xml:lang="hu">Elektronikus számla vagy módosító okirat állomány hash lenyomata</xs:documentation>
					<xs:documentation xml:lang="en">Electronic invoice or modification document file hash value</xs:documentation>
				</xs:annotation>
			</xs:element>

A cryptotype meg ilyen:

	<xs:complexType name="CryptoType">
		<xs:annotation>
			<xs:documentation xml:lang="hu">Kriptográfiai metódust leíró típus</xs:documentation>
			<xs:documentation xml:lang="en">Denoting type of cryptographic method</xs:documentation>
		</xs:annotation>
		<xs:simpleContent>
			<xs:extension base="SimpleText512NotBlankType">
				<xs:attribute name="cryptoType" type="SimpleText50NotBlankType" use="required"/>
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

Nemüres szöveg, ami max. 512 karakter. Hát ez bármi lehet. :-D

 

Mondjuk azt lehet sejteni, hogy nem valami egzotikus (pl. Base62) kódolást kell használni, de ez így akkor is kevés. Nem tudom mit szólnának hozzá, ha mondjuk base32 vagy base36 kódolással írnám ide a hash-eket?

Szóval a számla mellé őrizzük meg a hash-t. Azt a hash-t ami legyen nagybetűsen beküldve (mert ez nagyon fontos!), de hogy milyen encoding-gal az meg már nem számít. Ilyeneket nem lenne szabad eltéveszteni egy olyan dokumentációban, ami több millió embert érint. Az egészről süt a hozzá nem értés.

Na jó szóval a dokumentáció 177. oldalán van egy leírás a 28-as kódú "érvénytelen hash-érték" hibaüzenetről. A magyarázat hozzá a következő:

> Ha a completenessIndicator (az adatszolgáltatás maga az elektronikus számla) jelölő értéke true, akkor az electronicInvoiceHash értéke meg kell, hogy egyezzen az invoiceData csomópont BASE64 enkódolt értékének (a megadott algoritmussal számolt) nagybetűs hash értékével.
 

Ha az invoicedata base64 enkódolt, akkor talán a hash-hez is base64 enkódolt értéket várnak.

De most tényleg egy 300 oldalas dokumentumban a hibaüzenet listából kell kikukáznom azt, hogy hogy encode-oljak? Ez nem dokumentáció, ez egy sz@r.