Online-invoice: NAV 3.0 Elektronikus számla

[ballonyi]

Ma hallottam egy Facebook beszélgetést Czöndör Szabolcs és Kocsis Csaba részvételével, és ott elhangzott hogy _"az adatszolgáltatás maga lehet elektronikus számla"_. A következőket szeretném kérdezni:

1. Ez azt jelenti, hogy az XML adatszolgáltatás önmagában lesz az adóügyi bizonylat, pdf (vagy egyéb) számlakép akár nem is kell?
2. Az adatszolgáltatás XML-t kell archiválni és az ellenőrzéskor is azt kell felmutatni?
3. Az interfész specifikációban (2.6) ezzel kapcsolatban annyit találtam, hogy a PDF fájlról készült hasht is beküldhetem az adatszolgáltatásban. Értelmezésem szerint ez egy (hasznos) egyszerűsítés a PDF hitelesség és sértetlenség megállapítására, de nem mondja hogy _"az adatszolgáltatás maga lehet elektronikus számla"_. Ez az állítás leírva hol olvasható?

Előre is köszönöm a segítséget!

[bcdel]

2.6.2 pont 150-dik oldal 5-dik sortol szerintem...

... ha ez az elektronikus szamla eppen ezen dokumentacio szerinti invoiceData.xsd sema szerinti XML allomany...

tehat nem az adatszolgaltatas az eszamla, hanem az xml, ami megegyezik azzal amit adatszolgaltatni IS kell.

[irsl]

Az e-számlával kapcsolatban vannak további jogszabályi követelmények definiálva - pl. a minősített digitális aláírásra vonatkozóan. Az adatszolgáltatás során kalkulált aláírások egészen más technikai paraméterekkel bírnak.

[kabelnet2]

Az e-számlával kapcsolatban vannak további jogszabályi követelmények definiálva - pl. a minősített digitális aláírásra vonatkozóan. Az adatszolgáltatás során kalkulált aláírások egészen más technikai paraméterekkel bírnak.

A jobszabályok már megváltoztak éppen azért, hogy a hash feltöltésével is lehessen e-számlát csinálni. Ma már elektronikus számla egy e-mail-ben küldött pdf is, ha a hash fel van töltve a NAV-hoz. https://nav.gov.hu/nav/ado/afa/Az_elektronikus_szaml20200416.html

[ballonyi]

Megnéztem az specifikációban hivatkozott 1/2018. (VI. 29.) ITM rendeletet, és a NAV oldalán fellelhető e-számla tudnivalókat.

1. Az ITM rendelet 7. §:
   _"adatszolgáltatással érintett, számla, számlával egy tekintet alá eső okirat 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) ... előállít egy különálló, de az adott elektronikus számla dokumentummal együtt kezelt adatot
   b) ... a hash kódot ... 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) 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."_
   A fenti megfogalmazásból számomra az derül ki, hogy a jogalkotó a számlaképet (pl. PDF) tekinti elektronikus számlának, az adadszolgáltatás XML-ben szereplő hash kód pedig egy lehetőség arra, hogy a PDF hitelességét bizonyítsuk. Nem tudom úgy értelmezni, hogy egy xml (ami megegyezik azzal amit adatszolgaltatni is kell) az elektronikus számla lenne. Ráadásul önmagában.

2. A fentebb hivatkozott NAV anyag
   Úgy fogalmaz hogy a hitelesség és sértetlenség igazolására az Áfa tv. idáig két lehetőséget adott, az elektronikus aláírást és az EDI adatként továbbított számlát. Ami most kiegészül az ITM rendelet adta, hash alapú ellenőrzéssel: _"E megoldás alkalmazásának feltétele, hogy a számlakibocsátó adóalany az online számlaadat-szolgáltatása során az Online Számla rendszerbe továbbítsa az elektronikus számla hash kódját."_
   Értelmezésem szerint ez is azt mondja hogy a számlakép (pl. PDF) az elektronikus számla, és a fájlból képzett hasht-t kell beletenni az adatszolgáltatásba.

3. Továbbá a specifikáció 2.6.1 fejezetében is erről ír: _"Ha tehát az ellenőrzés során az adott algoritmussal megképzett hash-érték azonos azzal, amit az eladó a számla kiállításakor megadott, akkor bizonyítottnak tekinthető az elektronikus számla áfa törvényben megkövetelt hitelessége"_
   Szerintem ez is egybecseng az előző kettővel.

Viszont a 2.6.2 fejezet 150. oldalon található, illetve a fentebb említett beszélgetésben Kocsis Csabától elhangzott mondat nem ezt mondja. Ha azt mondjuk hogy _"az adatszolgáltatás MAGA lehet elektronikus számla"_ akkor ez azt is mondja, hogy az önmagában alkalmas arra, hogy pl. követelés peresítésre felhasználjuk (mint ahogy tehetjük pl. egy elektronikus aláírással ellátott PDF esetén). Fontos lehet ez pl. akkor is, amikor bár megegyezik a PDF fájlból képzett és az adatszolgátatásban beküldött hash érték, de valami hiba folytán az adatszolgátatás eltérő értéket (pl. végösszeget) mutat, mint a PDF. Ha PDF az elektronikus számla, akkor sima technikai érvénytelenítést követően új adaszolgáltatást kell csak küldeni, de ha viszont az adatszolgáltatás tekintem elektronikus számlának, akkor sztornózni kell a számlát és újat kiállítani.

De könnyen lehet hogy félre értelmezek valamit...

Fontosnak tartom ebben kérdésben az egyértelműséget, megköszönöm ha segítséget kapok a precíz megértésében.

[kabelnet2]

Szia, én a 'minősített digitális aláírásra' írtam a hivatkozást, mert az tényleg jó dolog, ha a számlák (itt most pdf-re gondolok) megőrzése egyébként megoldott, akkor nincs szükség külső szolgáltató bevonására az e-számlához. Az xml nekem semmiképpen nem tetszik, nem fogjuk használni akkor sem, ha különben minden rendben van vele kapcsolatban.

[ballonyi]

Szia, az elektronikus aláírással védett pdf "tiszta ügy", ha jól tudom nem is kell minősített, elég a fokozott is.
A 3.0 kapcsán életbe lépő változások szerintem lehetőséget kínálnak a PKI infrastruktúra kiváltására kiállító és befogadó oldalon egyaránt. Ami könnyebbség.

[jozanesz]

Még egy kis adalék, hogy nehezebb legyen az élet.

A számla olvashatósága azt jelenti, hogy a számla az ember számára olvasható. Ennek a
megőrzési idő végéig így kell lennie. A számlának olyan írásmódot kell tartalmaznia,
amely lehetővé teszi a számla héa-val kapcsolatos valamennyi tartalmának pontos
olvashatóságát, papíron vagy képernyőn, anélkül, hogy azt alaposan meg kellene
vizsgálni vagy magyarázatra lenne szükség. Így például az EDI üzenetek, az XML
üzenetek vagy más strukturált üzenetek az eredeti formátumban nem tekinthetők az
ember számára olvashatónak (konvertálási folyamatot követően ember számára
olvashatónak tekinthetők – lásd lent).
Az elektronikus számlák esetében ez a feltétel akkor tekinthető teljesítettnek, ha a számla
kérésre ésszerű időn belül, ugyanolyan módon, ahogy a 245. cikk (1) bekezdése előírja,
késedelem nélkül – többek között konvertálási eljárást követően is – az ember számára
olvasható formában képernyőn vagy nyomtatva bemutatható. Ellenőrizhetőnek kell
lennie, hogy az eredeti elektronikus fájl adataihoz képest a bemutatott olvasható
dokumentum adataiban nem történt változás.

[ballonyi]

A számla olvashatósága azt jelenti, hogy a számla az ember számára olvasható. Ennek a
megőrzési idő végéig így kell lennie. A számlának olyan írásmódot kell tartalmaznia,
amely lehetővé teszi a számla héa-val kapcsolatos valamennyi tartalmának pontos
olvashatóságát, papíron vagy képernyőn, anélkül, hogy azt alaposan meg kellene
vizsgálni vagy magyarázatra lenne szükség.

És a PDF fájl ember által olvasható? Hiszen az egy bináris fájl, amit az Acrobat Reader, mint megtekintő program alakít olvashatóvá. Ennek mintájára, a számla adatszolgáltatás XML megjelenítő programja lehet egy böngésző, amennyiben az XML elejére odatesszük az "xml-stylesheet" elemet, amiben meghivatkozunk egy XLS-t. Szerintem nincs különbség.

A számla adatszolgáltatás tényleg akár lehetne önmagában is elektronikus számla, hiszen az ÁFA tv. szerint kell:

• a számla befogadó beleegyezése -> megszerezhető
• biztosítani kell eredetének hitelességét -> a számla kibocsátó authentikál az adatszolgáltatás beküldéskor, tehát küldő azonosítva van
• biztosítani kell a sértetlenségét -> NAV hoz beküldött adatszolgáltatás lekérhető, referenciaként lehetne használni a megállapítására.

Persze a NAV-nak vállalnia kéne hozzá, hogy 10 évig lekérdezhetővé tesz minden számlát, amit gondolom meg is tesz, de vállallást tenni valósznűleg nem tervez. Furcsa, hogy az ITM rendelet mégis arról szól hogy a PDF, mint elektronikus számla hitelessége hogy ellenőrizhető az adatszolgáltatásban beküldött hash-el. Szóval, sajnos nem lelem azt a jogszabályt, amit a céges jogászok elé tudnék tenni, és igazolja hogy önmagában is elektronikus számla lehet az adatszolgáltatással egyező xml.

[jozanesz]

Így van. És valójában minden fájl bináris, a szöveg is. :) Gép nélkül igen nehéz olvasni. Még néhány évtized, és csak kitisztul ez a jogászok fejében is.

[irsl]

Musk agyinterfésze majd jól átírja a szabályokat!

[ballonyi]

Megtaláltam: az 3.0 interfész leírásban a completenessIndicator leírásánál (2.1.1) szerepel _"Jelöli, ha az adatszolgáltatás maga a számla"_

A Changelog 3.0 -ban találtam egy mondatot: _"A jogszabályi környezet igazodni fog ehhez a változáshoz..."_
Tehát még hiába keresem a jogszabályi hátteret. :)

Ha jól gondolom ilyenkor az electronicInvoiceHash értékét az InvoiceData elemből kell képezni (XML kanonizálást követően).

[NTCA-tax]

@ballonyi : Jól látod, a jogszabályi környezet változása szükséges ehhez. Ez nem törvényi változást jelent, hanem NGM rendeleti változás szükséges hozzá. Ott kell majd megtalálnotok majd a részletes jogszabályi hátteret. Ugyanakkor az interfész leírás eléggé részletesen tartalmazza ezt a lehetőséget 2.6 fejezete.

@jozanesz : Teljesen valid a felvetésed, éppen ezért tettük fel az XSLT kérdését, hogy melyik oldalon csináljuk meg. Az irányelvi magyarázat nem azt tartalmazza, hogy az XML nem lehet elektronikus számla, hanem biztosítani szükséges annak olvashatóságát.

[EnokhSys]

Bocsánat, lehet, hogy csak én bénázom el az ominózus részt, de hol találom az "electronicInvoiceHash" képzési algoritmusát?

Ugyanis a 38-ik oldalon ez szerepel:
"_2) Az electronicInvoiceHash az invoiceData csomóponton kívül szerepel a beküldésben. Emiatt a queryInvoiceData válaszban szintén az invoiceData csomóponton kívül szerepel, mivel az invoiceData csomópont BASE64 értékéből számolódik a hash-érték._"

Aztán a 151-ik oldalon ez szerepel:
"_A hash-érték megfelelő képzése az elektronikus számla, mint adatszolgáltatás feldolgozási folyamatában ellenőrzésre kerül, nem megfelelő hash-képzés esetén az adatszolgáltatás meghiúsul. (Lásd: 3.3.2 fejezet)_"

Aztán a 168-ik oldalon a hibakódoknál ez szerepel:
"_28 érvénytelen hash-érték
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) hash értékével._"

De könyörgöm, melyik részben/fejezetben van leírva ez az algoritmus, mint pl. ahogy az 1.5-ös fejezetben le van írva a RequestSignature számítási módszere? Vagy csak annyiból áll ez az algoritmus, hogy az BASE64-en elkódolt adatra képzek egy SHA3-512-es hasht?

[kabelnet2]

Én is bocsánatot kérek, még nem olvasgattam a V3 dokut. Ez a funkció viszont már megvan a V2-ben is, csak sajnos nem jó helyen, ezen javítottak a V3-ban. Ez nem az online számlára vonatkozik, hanem a valódi számlára, pontosabban annak tárolt formájára (pdf). Annak a hitelességet lehet úgy igazolni, hogy a pdf file-ról készítesz egy SHA256 lenyomatot (V2 doku 89. oldal) és feltölétöd azt az online számlával együtt. Ez később is bármikor igazolni tudja, hogy egy pdf hiteles, eredeti, nem módosított vagy sem.

[EnokhSys]

Én is bocsánatot kérek, még nem olvasgattam a V3 dokut. Ez a funkció viszont már megvan a V2-ben is, csak sajnos nem jó helyen, ezen javítottak a V3-ban. Ez nem az online számlára vonatkozik, hanem a valódi számlára, pontosabban annak tárolt formájára (pdf). Annak a hitelességet lehet úgy igazolni, hogy a pdf file-ról készítesz egy SHA256 lenyomatot (V2 doku 89. oldal) és feltölétöd azt az online számlával együtt. Ez később is bármikor igazolni tudja, hogy egy pdf hiteles, eredeti, nem módosított vagy sem.

@kabelnet2 köszi szépen, de ott is csak az "állomány" sha-lenyomata található, amit anno én is pdf állományként értelmeztem, csak ez a funkció eddig nem volt érdekes számunkra. De a v3-as leírásában célzás van arra, hogy "_...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._" Ebből azt szűröm le, hogy mégsem a pdf állomány az alap, hanem az invoiceData/Base64.

[kabelnet2]

Gondolom akkor, ha nincs külön számla, az XML az e-számla (el kéne már olvasnom a V3 dokut, de most sajnos más a főcsapás)

[NTCA-supporter]

Sziasztok!

Valóban nem elég pontos a doksi.
Bevezetésre került a comletenessIndicator, ami azt jelzi, hogy az adatszolgáltatásod az elektronikus számla. Ha ezt true értékkel küldöd be, akkor van az, hogy csak SHA3-512 algoritmust fogadunk el, és az invoiceData base64 értékéből számolva uppervcase-elve kell beküldeni az electronicInvoiceHash mezőt. Ilyenkor (completenessIndicator = true) ellenőrizzük is a hash értékét és ERROR-t adunk ha az nem helyes.

Ha nem az adatszolgáltatásod az elektronikus számla (completenessIndicator = false), akkor is beküldheted a hash értéket, pl. a pdf hash értékét, de ilyenkor a hash értékét nem validáljuk, csak letároljuk, hiszen nincs meg nekünk a pdf.

A dokumentáción mindenképp pontosítunk! Van még kérdés?

Köszi

[EnokhSys]

Kedves @NTCA-supporter ,

nagyon szépen köszönöm, az algoritmus így már tiszta.

Egyetlen kérdésem maradt: jól értelmezem azt, hogy "az adatszolgáltatásom az elektronikus számla" azt jelenti fogalmilag, hogy azáltal, hogy beküldöm a számla adatait (amihez értelemszerűen kell a kötelező hash kód) a "NAV OnLine Számla" rendszerébe és az elfogadásra kerül, ezáltal az megfelel az elektronikus számla jogi előírásainak? Tehát innentől fogva akár PDF-ben, akár Word-ben, akár JPEG-ben is kiküldhetem a számlát a vevőnek, a lényeg az, hogy ez ne legyen módosítható?
(Persze tudom, hogy hülye példa a word és a jpeg, ezzel csupán azt szeretném tisztán látni, hogy nem a "v3.0adatbeküldés+hash+emberileg olvasható formátum" együttese teszi elektronikus számlává a számlát, hanem már eleve a "v3.0adatbeküldés+hash" teszi azzá?)

Előre is köszi.

[NTCA-supporter]

Szia @EnokhSys !
Technikailag igen. Jogszabályilag/adózásilag nem én fogom megmondani, hogy kell-e hozzá bármi egyéb tudnivaló.
@NTCA-tax tud segíteni, ha van bármi konkrét kérdés még.
Üdv

[EnokhSys]

Szia @EnokhSys !
Technikailag igen. Jogszabályilag/adózásilag nem én fogom megmondani, hogy kell-e hozzá bármi egyéb tudnivaló.
@NTCA-tax tud segíteni, ha van bármi konkrét kérdés még.
Üdv

Köszi @NTCA-supporter, ez így okés, technikailag tiszta. Legfeljebb @NTCA-tax ha erre jár, kérem, hogy sűrűn bólogasson arra, hogy jogszabályilag még nincs teljesen letisztulva a kérdés, tehát várjuk, amíg előbb-utóbb vmely NGM rendeletből ez kiderül.

Az 1/2018. (VI. 29.) ITM rendelet, 7. § d) pontja is csak annyit mond, 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_". Na és akkor eljutottunk oda, hogy a vevőnek is el kell küldeni a számla olvasható képe mellett, az invoiceData base64 értékét, hiszen a NAV OLSZ esetében ez utóbbi képezi az elektronikus számla dokumentumát (nem pedig az olvasható pdf kép/állomány).

Egyébként az zavar még, hogy nincs kötelezővé téve a hash kód szerepeltetése a vevőnek küldött olvasható állományban, vagy magában a számlaképen. Ha egy vevő ellenőrizni szeretné a kapott pdf eredetiségét, akkor ezt csak úgy tudja megtenni, ha a pdf számla minden adatát összenézi a NAV rendszeréből lekérdezett számla adatával, holott elegendő lenne csak a hash kódot "szemmel vernie".

[kabelnet2]

Nézz át ide: https://github.com/nav-gov-hu/Online-Invoice/issues/432 hátha találsz jó javaslatot a számlák ellenőrzésére.

[EnokhSys]

Nézz át ide: https://github.com/nav-gov-hu/Online-Invoice/issues/432 hátha találsz jó javaslatot a számlák ellenőrzésére.

@kabelnet2 Köszi, elolvastam, mindjárt írok oda is.

[kabelnet2]

És mi van magánszemély esetén? On-line vásárlásnál ma is gyakorlat, hogy egy linket adnak, ahonnan letölthető a számla (pdf). Nekik is jó lenne az úl e-számla lehetőség, de sajnos nem jó.
Mivel magánszemély esetén a név és cím nem adható fel xml-ben, így ÁFA törvénynek megfelelő számla sem nyomtatható csupán az online számla rendszerben tárolt xml adatokból. Tehát kell pdf-et csinálni és akkor már annak a hitelességét kell ellenőrizhetővé tenni (bár ilyen ellenőrzésre nem hiszem, hogy tömeges igény van/lesz)

[ballonyi]

@kabelnet2 : igen, sajnos nem lehet teljesen ráállni az XML formátumú elektronikus számlára, hiszen privatePersonIndicator és completenessIndicator nem lehet egyszerre true, meg hát mit is kezdene egy magánszemély vevő egy XML-el. Nekik marad a PDF.

[EnokhSys]

Kedves @kabelnet2 és @ballonyi,

igen, mivel ennek leginkább jogszabályai vannak, ezért vannak esetek, amikor az "adatszolgáltatás mint e-számla" nem alkalmazható. De ez csupán egy lehetőség, és a számlakibocsátó dönthet úgy, hogy pl magánszemélyeknek pdf. számlát állít elő saját maga által képzett hash-el. Nem hiszem, hogy a magánszemélyeknek szolgáltató nagyvállalatok egyhamar ki fogják dobni a már jól bejáratott digitális aláírásos+időbélyegzős pdf számláikat.

Viszont a cégek közötti számlázásra kiválóan alkalmas lehet. Épp tegnap beszéltem egy jelentős forgalmú vállalat informatikai igazgatójával, akik különböző okok miatt, még mindig papíralapon kénytelenek készíteni havi tízezernél is több számlát, és már egy ideje tervezgetik az e-számla bevezetését. Egyből ráérzett a v3.0 előnyére és kérte, hogy készítsek egy összefoglalót a vezetőség számára, hogy milyen jogszabályi feltételek mellett, ezt technikailag hogyan tudnánk kivitelezni.

[EnokhSys]

Kedves Mindenki!

Töprengtem egy sort ezen az "adatszolgáltatás mint e-számla" polémián. Amint látható a beszélgetésünkből itt a legfőbb aggály az, hogy a vevőnek küldendő pdf számla hitelessége hogyan biztosítható, ha a hash-kód nem a pdf-ből készül, hanem az "invoiceData" szegmensből készül. A megoldás nagyon egyszerű: legyen két db. hash-code bevezetve. A jelenlegi "electronicInvoiceHash" szolgáljon az "invoiceData" biztosítására, és mondjuk egy új-, "readableInvoiceHash" szolgáljon a pdf biztosítására.

Hogy nézne ki ez a gyakorlati folyamatban:

1. A számlakibocsátó megképzi az "invoiceData" BASE64 alapján az SHA3-512-es hasht, amelyet az "electronicInvoiceHash"-ben szerepeltet.
2. Amennyiben a számlabefogadóval úgy állapodott meg a számlakibocsátó, hogy az kér olvasható számlát is, akkor rendeletileg kötelezővé kell tenni lehetőség van az 1-es pontban megképzett "electronicInvoiceHash" szerepeltetésére az emberileg olvasható számla képén, azaz a pdf.-ben. (Megjegyzés: kihúztam a rendeleti kötelezőséget, mert nincs értelme, hiszen a hiteles számla a completenessIndicator=true esetén az XML invoiceData-ban található.)
3. A számlakibocsátó elkészíti a pdf számlát.
4. Az elkészült pdf-ből készít egy hash-t egy meghatározott algoritmus szerint, amelyet a "readableInvoiceHash" szegmensben szerepeltet, ezzel együtt már beküldhető a számla a NAV OnLine Számla rendszerébe.
5. A számlabefogadó megkapja a pdf számlát e-mailben, és ellenőrízheti, hogy a pdf számlán látható-, a számla adattartamára vonatkozó hash kód egyezik-e a NAV-hoz feltöltött "electronicinvoiceHash"-el, ugyanakkor ellenőrízheti a pdf integritását is a "readableInvoiceHash"-el.

Ezzel a módszerrel biztosítva van az, hogy az "adatszolgáltatás mint e-számlát" lehessen használni automatizált számlabefogadásra is, tehát amikor a vevő nem kér pdf számlát, mert a számlát a NAV-tól tölti le és jeleníti meg a saját rendszerében, és lehessen használni hitelesített biztonsági kóddal ellátott pdf számlaként is, attól függően, hogy az eladó és vevő hogyan állapodik meg erről.

Összefoglalva: nagyon jó ötlet, hogy az XML-ben szereplő adat legyen az elektronikus számla, de ennek elterjedését erősen meg fogja akadályozni az, ha a számlabefogadó ügyintézője/könyvelője/pénzügyese csak a NAV felületén láthatja a számlát. Évtizedek óta dolgozom velük, már az sem volt könnyű elfogadtatni, hogy a papírszámlát ne a kezükbe fogják, hanem annak képét a monitoron nézzék meg pdf.-ben. Az utóbbi években kialakítottak a saját munkamódszerüket, különböző mappákba szervezik a bejövő pdf számlákat, szinte biztos, hogy ha csak a NAV felületén tudják majd ezeket megnézni, nem fognak szerződést kötni az eladóval az elektronikus számlák ilyen formájára, tehát mindenképp figyelembe venni az emberi tényezőket.

(Az már a vevő, azaz a számlabefogadó felelőssége, hogy ellenőrizze ezeket a kódokat, de nyilvánvaló, hogy az olvasható elektronikus számlák esetében, "szemmelveréssel" összehasonlítgatni nem könnyű, ezért idővel bizonyára meg fognak jelenni olyan célszoftverek a piacon, amelyek ezt megkönnyítik,)

@NTCA-supporter, @NTCA-developer és @NTCA-tax nektek mi a véleményetek erről a megoldásról?

[kabelnet2]

Szerintem ez nem így van kitalálva. Eldöntöd, hogy pdf vagy ez az új lehetőség. Ha az új lehetőség, akkor nem küldesz semmit a vevőnek (most azt vegyük, hogy küldeni kell a számlát), csak egy e-mail-t, hogy van új számlája. A vevő meg letölti a NAV-tól olvasható formában, ami az xml-ből generálódik.
Új lehetőség esetén a hash csak arra kell, hogy mást ne tölthess fel abba a mezőbe :), illetve hogy a nálad tárolt xml valódiságát ellenőrizni lehessen (mert egyenlőre még tárolni kell).
A számlakép nyomtatásáról meg volt egy szavazás, most már lezárva: https://github.com/nav-gov-hu/Online-Invoice/issues/349 Mivel az igen győzött, gondolom megcsinálják.
Ez természetesen csak az én értelmezésem. Amúgy mi maradunk a pdf-nél.

[EnokhSys]

Szerintem ez nem így van kitalálva. Eldöntöd, hogy pdf vagy ez az új lehetőség. Ha az új lehetőség, akkor nem küldesz semmit a vevőnek (most azt vegyük, hogy küldeni kell a számlát), csak egy e-mail-t, hogy van új számlája. A vevő meg letölti a NAV-tól olvasható formában, ami az xml-ből generálódik.

Na és miért ne lehetne megadni mindkét lehetőséget? Csak egy plusz mezőbe kerül, és az eladó-vevő szabadon dönthet arról, hogy csak az xml-t akarja használni, vagy mindkettőt. Már Hofi is megmondta, amikor lóbálta a szenes vasalót: "_a dolgozónak van döntési joga... hogy erre dobja vagy arra_" :-)

Új lehetőség esetén a hash csak arra kell, hogy mást ne tölthess fel abba a mezőbe :), illetve hogy a nálad tárolt xml valódiságát ellenőrizni lehessen (mert egyenlőre még tárolni kell).

A hash nem csak arra kell, hogy ne tölthess fel mást abba a mezőbe, hanem arra, hogy az adatcsomag integritása biztosítva legyen az eladó-NAV-vevő útvonalon, ill. hogy bármikor utólagosan egy esetleges jogi eset kapcsán ellenőrizhető legyen az eredetisége. A kötelező tárolásra vonatkozó kitétel biztosan nem fog megszűnni, sem az eladónál, sem a vevőnél.

A számlakép nyomtatásáról meg volt egy szavazás, most már lezárva: https://github.com/nav-gov-hu/Online-Invoice/issues/349 Mivel az igen győzött, gondolom megcsinálják.
Ez természetesen csak az én értelmezésem. Amúgy mi maradunk a pdf-nél.

Erről nem tudtam, de ez is egy lehetőség. Szinte biztos, hogy a partnereim nem fognak élni vele, egyrészt, mert szeretik céges logóval küldeni az elektronikus PKI számlát, másrészt, ha a NAV belassul, akkor ez megakasztja a számlázást, és bizony, ha az esti expediálás után nem tudnak percek alatt elkészíteni több száz számlát, akkor nagyon megcsúszik az országos kiszállítás.

[kabelnet2]

Ha két forma van, mindegyik hitelesített, akkor ki és mi fogja bizonyítani, hogy a kettő megegyezik? (Mármint a pdf és az XML.) És ha nem, melyik az igazi? Szerintem jobb ebbe nem belemenni.

[EnokhSys]

Ha két forma van, mindegyik hitelesített, akkor ki és mi fogja bizonyítani, hogy a kettő megegyezik? (Mármint a pdf és az XML.) És ha nem, melyik az igazi? Szerintem jobb ebbe nem belemenni.

Áácsi, félreérted! Amennyiben a számlakibocsátó azt választotta, hogy az "adatszolgáltatás az elektronikus számla" (completenessIndicator=true), akkor értelemszerűen az XML a hiteles. A pdf csupán biztonsági kódokkal ellátott dokumentum az emberi olvashatóság segítésére. A számlakibocsátó felelőssége, hogy az XML és a PDF adattartalma megegyezzen, és arra szolgálna a "readableInvoiceHash", hogy az általa létrehozott pdf érintetlenségét bizonyítsa.
Tehát ugye ebből következik. hogy nem fordulhat elő olyan eset, hogy az XML és a PDF adattartalma ne egyezne meg, csak akkor, ha a számlakibocsátó számlázóprogramja hibásan müxik.

[kabelnet2]

Ez esetben miért kell belekeverni a NAV-ot? Csinálsz egy hash-t és elküldöd a pdf-el, akár a file nevében.
De szerintem felesleges, mert ha kétely merül fel a hitelességével kapcsolatban, az online számla rendszer adataival össze lehet hasonlítani (értékek, dátumok,stb.)
Végül azt nem értem, ha úgy gondolod hogy pdf-et kell küldeni (amiben különben egyetértünk), akkor miért foglalkozol ezzel az új elektronikus számla lehetőséggel. A pdf-et kell hitelesnek megtenni.
De szerintem eleget tárgyaltuk a témát. Jó munkát, akármelyik megoldást választod.

[EnokhSys]

Ez esetben miért kell belekeverni a NAV-ot? Csinálsz egy hash-t és elküldöd a pdf-el, akár a file nevében.

Azért mert a pdf mehet ugyan nem biztonságos útvonalon (pl. e-mailben), de a biztonsági kódja ugyanúgy feleljen meg a 1/2018. (VI. 29.) ITM rendelet 7. §-án ak, mint az XML biztonsági kódja. Attól még, hogy az XML-t tekintjük a hiteles számlának, az olvasható számla esetében is törekednünk kell a maximális biztonságra.

De szerintem felesleges, mert ha kétely merül fel a hitelességével kapcsolatban, az online számla rendszer adataival össze lehet hasonlítani (értékek, dátumok,stb.)

Ha a NAV oldalán fent van a biztonsági kódja, ez a vevők számára is megnyugtatóbb, hogy a számla eredeti és sértetlenül érkezett meg hozzájuk.

Végül azt nem értem, ha úgy gondolod hogy pdf-et kell küldeni (amiben különben egyetértünk), akkor miért foglalkozol ezzel az új elektronikus számla lehetőséggel. A pdf-et kell hitelesnek megtenni.

Mivel évek óta foglalkozom EDI/PKI elektronikus rendeléssel és számlázással, pontosan tudom, hogy milyen rettentően bizalmatlanok a vevők is, a szállítók is a technológia iránt, és a NAV féle módszer még képlékeny, érdemes a legjobbat kihozni belőle. Mert szerintem az egy zseniális ötlet, hogy ha már amúgyis kötelező a számlát beküldeni a NAV-hoz, akkor az adatszolgáltatás legyen önmagában az elektronikus számla, amit a vevő vagy letölt a rendszerébe és úgy tudja elolvasni, vagy kap mellé az eladótól egy olvasható változatot, amelynek az eredetisége biztosított. Tehát szerintem a vevőknek (főleg a könyvelőknek) sokkal nagyobb bizalma lesz egy olyan elektronikus számla iránt, ha tudja azt, hogy annak adattartalmi eredetiségét a NAV garantálja, ill. az olvasható változatnak a biztonsági kódját a NAV honlapján is leellenőrizheti.

De szerintem eleget tárgyaltuk a témát. Jó munkát, akármelyik megoldást választod.

Köfi, Neked is! :-)

[KMGY100]

@EnokhSys @kabelnet2
Alaposan kifejtettétek a gondolatotokat az elektronikus számlával kapcsolatban, de
úgy látom csak a számla kibocsájtói oldalt taglaltátok.

Adva van egy egyszerű vállalkozás aki kap egy elektronikus számlát
vagy így:

1. kap email-ben számlaadat XML állományát és annak Hash kódját
   (azért megérdemel egy PDF állományt is mert csak azt tudja olvasni )
   vagy így:
2. kap email-ben számla PDF állományt és annak HAsh kódját

A vállalkozás kifizeti a számla végösszegét, de ezzel a ráutaló magatartásával
máris beleegyezett abba , hogy elektronikus számlát kapjon (kifejezett akaratán kívül )

Kifizette a számlát, kinyomtatja a PDF állományt és csak papír alapon őrzi a számlát,
a Hash kód nem is érdekli.
( és máris a feje felett lóg a NAV általi büntetés lehetősége )

Ezzel a kéretlen elektronikus számla küldéssel veszélybe sodorhatja a
számla kibocsájtója a számla befogadóját.

[EnokhSys]

Adva van egy egyszerű vállalkozás aki kap egy elektronikus számlát
vagy így:

1. kap email-ben számlaadat XML állományát és annak Hash kódját
   (azért megérdemel egy PDF állományt is mert csak azt tudja olvasni )
   vagy így:
2. kap email-ben számla PDF állományt és annak HAsh kódját

A vállalkozás kifizeti a számla végösszegét, de ezzel a ráutaló magatartásával
máris beleegyezett abba , hogy elektronikus számlát kapjon (kifejezett akaratán kívül )

Én úgy emlékszem, hogy a jogszabályok szerint szükség van a vevő beleegyezésére. Nem tudom, hogy elegendő-e a ráutaló magatartás, legfeljebb akkor, ha a számlakibocsájtó a számla megjegyzésében/üzenetében, vagy az azt kísérő levélben kifejezetten felhívja erre a figyelmet. Tehát, ha valaki a "kifejezett akaratán kívül" fogad be elektronikus számlát, és egy polgári peres eljárásban a bíróság megállapítja azt, hogy a számlakibocsátó megtévesztő módon járt el, akkor ott a számlakibocsájtó a felelős bizonyos mértékig.

Kifizette a számlát, kinyomtatja a PDF állományt és csak papír alapon őrzi a számlát,
a Hash kód nem is érdekli.
( és máris a feje felett lóg a NAV általi büntetés lehetősége )

Ezzel a kéretlen elektronikus számla küldéssel veszélybe sodorhatja a
számla kibocsájtója a számla befogadóját.

Mivel itt említed a NAV büntetés lehetőségét, feltételezem, hogy a számlabefogadó jelen esetben valamilyen formában működő vállalkozás, amely adócsökkentési célból (ÁFA, Vállalkozói kivét, SZJA, stb) elszámolhatja a számlát. (Tehát nem magánszemély, mert számlabefogadóként őt nincs miért büntesse a NAV).
Minden vállalkozásnak köteles minimálisan tisztában lennie azokkal a jogszabályokkal, amelyek a tevékenységét érintik, így a számla kibocsájtással és befogadással is. Ennek megfelelően, az adóelszámolását alátámasztó elektronikus számlát csak és kizárólag elektronikus formában őrizhet meg a biztonsági kóddal (hash) együtt, papíralapon nem. Kinyomtathatja magának, de az még csak nem is hiteles másolat.
Ha a fentebb említett polgári peres eljárásnál maradunk, hiába marasztalható el a számlakibocsájtó azért, mert megtévesztően járt el, azért már nem ő felel, hogy a számlabefogadót megbüntette a NAV, hiszen a számlabefogadónak tisztában kellett lennie azzal, hogy csak papíralapú számlát őrizhet meg papíron, elektronikus számlát nem.

Egyébként csak megjegyzem, hogy ebből a szempontból hibás az 1/2018. (VI. 29.) ITM rendelet. Ugyanis a 7. §-ban végig a "megőrzésre kötelezett" kifejezés van használva, holott a paragrafus a), b) és c) pontja kifejezetten a "számla kibocsájtóra" vonatkozik, és csak a d) pont vonatkozik egyaránt a "számla kibocsájtóra" és a "számla befogadóra" egyaránt. (Ugye a számla befogadó-, mivel ő is kötelezett a számla megőrzésére, nincs mit kezdjen az a)-c) pontokban a hash képzéssel és küldéssel, mert azt nem ő végzi, hanem a számla kibocsájtója.)