[FEATURE] Online számla oldalon hash ellenőrző feature

[laladisc]

Az igény összefoglalása / Summary of the request

A hash kóddal hitelesített (completenessindicator=false) e-számlák hash értékének ellenörzése

Az általam javasolt megoldás / The solution I propose

Lehetne az online számla oldalon egy HASH ellörző menüpont, ahova feltöltve egy hash hitelesitéssel ellátott e-számlát, megjeleníthetné a hash értékét, így a számla befogadónak nem kellene mindenféle online hash ellenőrző oldalakon bolyongania és hiteles forrásból győződhetne meg a számlája hitelességéről. De tovább megyek, akár azt is el tudnám képzelni, hogy bejelentkezés után a szállító adószámának és számla sorszámának megadásával akár össze is vethetné a feltöltött electronicinvoicehash-el és visszaadhatná, hogy OK/NEM OK.

[NTCA-developer]

@NTCA-tax mit gondolsz?

[NTCA-tax]

Ez egy jogos felvetés. Az nem lenne jó megoldás, hogy a hash kódot lista szinten is le lehet kérdezni? Jelenleg a számla lekérdezőnél 21 adatot lehet megjeleníteni egy listában. Az megfelelő megoldás lenne, ha ehhez adnánk hozzá 22-dik elemként a hash kódot, amit a felhasználó választhat, hogy meg akarja-e jeleníteni vagy sem? Amennyiben így megjelenítjük a hash kódot, akkor akár Excel-be is el lehet menteni és utána összehasonlíthatja akár ezzel a megoldással a felhasználó.

Természetesen ott van mellette az API-n keresztüli lekérdezés is, ez a felület oldali megoldás lehet.

[laladisc]

@NTCA-tax, nem magának a hash kódnak a lekérdezése lenne a lényeg (de a digest akár vissza is adhatná), hanem egy olyan funkció beépítése, ami kiszámolja pl egy pdf fájl hash értékét, mint pl itt: [https://emn178.github.io/online-tools/sha256.html]. Így hiteles forrásból lehetne meggyőződni a számla sértetlenségéről. De ez csak egy ötlet.

[NTCA-tax]

Ebben az esetben a hash kódot nem ellenőrizzük. A dokumentációban van két típusú hash számítási algoritmus, de ettől eltérő algoritmust is alkalmazhat az értékesítő.

A fentiek alapján azt lehetne csinálni, hogy ha valaki feltölt egy pdf fájlt, akkor rászámolunk két algoritmussal hash-t. Egy ilyen megoldás arra lenne jó, hogy manuálisan lehetne ellenőrizni egy fájl hash értékét. Tehát ha jól értem, akkor ez lenne az igény?

[laladisc]

Igen, alapvetően erre gondoltam.

[kabelnet2]

Erről volt szó a már lezárt [FEATURE]Elektronikus számlák támogatása #241 -ban. Itt csak megismételni tudom: olyan feature kell, amiben nincs szó hash-ről még számítási módszerről, hanem amivel egy könyvelő megállapíthatja, hogy egy pl. pdf számla rendben van-e. És azért lenne jó, ha ezt a nav csinálná, mert az adna hitelességet a dolognak. A hitelesség miatt kevésbé jó az, ha egy felhasználói program lekérdezi a hash-t kiszámolja és azt mondja, hogy jó.

[topybear]

Nem nyitnék rá új issue-t, mert erősen kapcsolódik ehhez... Magánszemélynek kiállított, hash kóddal hitelesített - természetesen completenessindicator=false :) - e-számlák ellenőrzésére hogy lesz lehetőség? Mert ők jelenleg a hash értékhez nem férnek hozzá sehogy sem. Nem találtam erről infót sehol. Lesz esetleg egy regisztráció nélkül elérhető funkció, ahol mondjuk a kibocsátó adószáma és a számlaszám alapján lekérdezhető? Van erre valami terv?

[kabelnet2]

Azért az nem lesz egy gyakori eset, amikor a magánszemély a számla hitelességét akarja ellenőrzi. Sőt lekérni sem fogja, bőven elég neki, amit a boltban kapott. Vagy tévedek?

[topybear]

Hát ha egy ilyen akad... És akad!

[EnokhSys]

Sziasztok!

A "NAV 3.0 Elektronikus számla" topikban nekem is eszembe jutott az a kérdés, hogy a vevő hogyan tudná ellenőrizni a kapott pdf számla hitelességét. Arra gondoltam, hogy talán a legegyszerűebben úgy lehetne, ha a pdf számlán is megjelenne a hash-érték QR kódja és a NAV OnLine Számla felületén lekérdezett számlák mellett is. Csak egy-egy csippantásba kerülne, és így nem kellene feltöltögetnie a vevőnek a pdf állományokat. Persze ezt úgy is meg lehet csinálni, ahogy @NTCA-tax írta, hogy lejönne a lista 22-ik oszlopában a hash-kód, és a vevő szoftvere gondoskodna arról, hogy ebből QR-kódot generáljon... de azért az előző megoldás a NAV felületén, gyorsabb és elegánsabb lenne.

[kabelnet2]

Hát hash kódot rátenni bármilyen formában a pdf-re, amere a hash-t képzed, az szerintem nem jó ötlet, mert maga a kód is módosítja a hash-t. A pdf hitelessége más eszközökkel biztosítható (ezt csinálják jelenleg az ezzel foglalkozó cégek), de az mind sokkal bonyolultabb (és drágább), mint amit a NAV ajánl. Az egyszerűséget nem szabadna feláldozni.

Ja igen: és mi biztosítja, hogy a rárakott kód az tényleg a pdf kódja? Azt sajna ki kell számolni az ellenőrzéshez.

[EnokhSys]

Hát hash kódot rátenni bármilyen formában a pdf-re, amere a hash-t képzed, az szerintem nem jó ötlet, mert maga a kód is módosítja a hash-t. A pdf hitelessége más eszközökkel biztosítható (ezt csinálják jelenleg az ezzel foglalkozó cégek), de az mind sokkal bonyolultabb (és drágább), mint amit a NAV ajánl. Az egyszerűséget nem szabadna feláldozni.

Ja igen: és mi biztosítja, hogy a rárakott kód az tényleg a pdf kódja? Azt sajna ki kell számolni az ellenőrzéshez.

Kedves @kabelnet2,

nyilvánvaló, hogy én nem arról az estről írtam, amikor a pdf a hash alapja. Ha elolvasod a másik topikot, láthatod, hogy letisztázásra került az, hogy amikor az adatszolgáltatásod az elektronikus számla, akkor a hasht, az invoiceData base64 értékéből kell számolni SHA3-512-vel, és ezt uppercase-síteni kell. Szerintem ezt a kódot érdemes rátenni a pdf-re valamilyen formában.

[kabelnet2]

Gondold végig: van egy pdf-ed és rajta egy kód. Van egy kód az online számla rendszerben. OK: A két kódot összehasonlítod és megegyeznek OK. De mi garantálja, hogy a pdf, amin a kód van, az az a pdf, amihez a kód tartozik (természetesen adatok tekintetében)? Az általad említett esetben csak akkor hiteles egy számla, ha az online rendszerbe bevitt adatokból hívod le (mint vevő), persze valami emberi fogyasztásra alkalmas formában. Erre is van issue, amiben NTCA érdeklődik, hogy ki csinálja a számlakészítő részt.

[sza8]

Én egy ilyen felületnek örülnék a NAV-tól:

• a kibocsátó adószáma + számlaszám + hash kód alapján ellenőrzi, hogy érvényes-e a számla,
• a hash kód(ok) előállítása természetesen a számlafájlból történne, de ehhez nem kell feltölteni, megoldható kliens oldalon,
• ne kelljen bejelentkezni, így magánszemély, cég vagy akár külföldi vevő is ellenőrizheti a számláját,
• az url-ben paraméterként megadható az adószám és számlaszám

A gyakorlatban ez úgy nézne ki, hogy a számlával küldünk egy linket is benne az adószámmal és számlaszámmal. Az ellenőrzés csak annyi lenne, hogy a vevő rákattint linkre és kiválasztja a számlát. Sőt, akár a pdf-be is be lehet linkelni.

Persze lehet fokozni, hogy ne csak érvényes/nem érvényes kimenetet adjon, pl.: beküldés ideje, számla kelte, kiállító adatai, összeg vagy akár az egész számla

[EnokhSys]

Gondold végig: van egy pdf-ed és rajta egy kód. Van egy kód az online számla rendszerben. OK: A két kódot összehasonlítod és megegyeznek OK. De mi garantálja, hogy a pdf, amin a kód van, az az a pdf, amihez a kód tartozik (természetesen adatok tekintetében)? Az általad említett esetben csak akkor hiteles egy számla, ha az online rendszerbe bevitt adatokból hívod le (mint vevő), persze valami emberi fogyasztásra alkalmas formában. Erre is van issue, amiben NTCA érdeklődik, hogy ki csinálja a számlakészítő részt.

Kedves @kabelnet2,

kicsit tovább- és újragondoltam az elektronikus számla sztorit, ezért nem biztos, hogy válaszolok az eredeti kérdésedre, mert most más szempontból közelítem meg a dolgokat, amelyben nem a pdf számla és annak hitelességén van a hangsúly.

A NAV, a v3.0-ás API-val egy új koncepciót vezetett be az elektronikus számlával kapcsolatban, amelyhez - ha jól értem - még némi jogszabály igazítás is szükséges, de mindenképp nagyon jó az irány. Ezért most különítsük el a két elektronikus számla fogalmát:

A. A hagyományos elektronikus számla az, amikor létrehozol egy pdf dokumentumot, amelyből képzesz valamilyen hitelesítő hash kódot. Ezt a hash-t már a v2.0-ban is feltölthetted a NAV OnLine Számlába, amelynek visszaigazolása után, teljesült a számla integritására vonatkozó jogi követelmény. A pdf számlát és a hash kódot elküldve a vevőnek (akivel korábban már megállapodtál az el.számla befogadásáról), pont úgy hiteles számlának minősült, mint egy papír alapon, aláírt és lepecsételt számla. Tehát ebben nem hozott újat a v3.0-ás verzió, ez már a v2.0-tól, azaz idén júl 1.től használható megoldás volt.

B. A NAV féle elektronikus számla egy új koncepció, amelynek abban van az óriási előnye, hogy egyáltalán nem szükséges pdf-ben megküldeni a számlát, elég, ha a vevőnek elküldöd (vagy letölti a NAV rendszeréből) az "invoiceData" szegmens BASE64-ben lekódolt tartalmát és az erre vonatkozó SHA3-512-es hasht. Ez a kettő képezi az elektronikus számlát, amelyhez persze küldhetsz egy emberileg olvasható pdf számla képet is. Ez utóbbinak hitelessége jogszabályilag még nem teljesen tiszta, de várhatóan év végére ennek tisztázása is megtörténik. Viszont a pdf számla nem is annyira fontos, mert mint mondtam, maga az invoiceData/Base64 mint elektronikus számla jelenti az előnyt, hiszen amikor a szoftverfejlesztők eljutnak arra a felismerésre, hogy a bejövő számlákat a saját rendszerükben tölthetik le és jeleníthetik meg a saját ízlésük szerint (pont úgy, mint az EDI-t használó cégek teszik ezt már régóta), attól a pillanattól kezdve feleslegessé válik a pdf számlakép küldése.

A magam részéről kifejezetten örülök ennek a "B" variációnak, mert egy 14 évvel ezelőtti elképzelésem válik valóra, csak akkor még nem sejtettem, hogy a NAV lesz a megvalósítója. Ugyanis már 2006-ban, amikor még az EDI/XML rendelésfogadás és számlaküldés is csak gyerekcipőben járt, azon töprengtem annak fejlesztése közben, hogy államilag központosított szervereken kellene bonyolítani a számlaküldést-fogadást a gazdasági élet szereplői között, hiszen nem csupán hatalmas papírmennyiséget-, hanem iszonyú időt, adminisztrációs- és postaköltséget lehetne megspórolni vele. Dicséretes, hogy a NAV informatikai vezetése, megpróbálja az OnLine Számla rendszert a törvényi kötelezettségen túlmenően - amely valljuk be, elég nagy közutálatot és ellenszenvet szült -, párhuzamosan egy új, hasznos és innovatív irányba is terelni. (Csak nehogy a felsőbb politika belekontárkodjon ebbe, mert abból nem sül ki semmi jó.)

[szabogab]

Még egy előny, megjelenítés is lehet hogy meg lesz oldva központilag, lásd: Legyen-e XSLT a 3.0-ás Data XML megjelenítéséhez, számlakép generáláshoz? #349

[andrew-azarov]

Shouldn't all hashed invoices be considered as electronic invoice per EU directive VAT Directive 2006/112/EC is art. 233, 2? They even mention text file with hash.

[NTCA-supporter]

@NTCA-tax kérlek jelezz vissza, hogy ezzel kapcsolatban mi az álláspont. Köszönöm