search

nav-gov-hu / Online-Invoice

Public repository of the Online Invoice System
Other
139 stars 52 forks source link

[Q&A] Elektronikus számla támogatás - alternativa PDF hitelesítés helyett #876

Closed WittmannWien closed 3 years ago

WittmannWien commented 3 years ago

A kérdés, amire választ szeretnék kapni / The question I would like to be answered Rövid és tömör leírása a kérdésnek. / A clear and concise description of the question. Kedves Mindenki, igyekeztem minden olyan issue-t elolvasni, ami erröl a témáról szól, és nem minden kérdésemre találtam választ. Emiatt bátorkodom egy új issue nyitással, hátha kapok segítséget, hogyan is induljak neki.

Kiindulási helyzet: Cégünk eddig nem használt elektronikus számlát, viszont ez igény már megjelent. Ahhoz hogy a megfelelöen müködjön, ugye a pdf-filet (vagy legyen ez bármilyen formátum) aláírással és/vagy idöbélyeggel kell ellátni. Ezzel tudom az hitelességet és sértetlenséget biztosítani. Viszont keresek olyan megoldást, amely helyettesíti ezt a mechanizmust és az XML 3.0 tudhat ebben segíteni.

Online számla Interfesz specifikáció HU_v3.0 155 oldalából másolt szöveg:

"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. Erre az Online Számla rendszer az alábbi megoldást nyújtja: A számlázási folyamatban az eladó oldalán létrejön egy elektronikus számla dokumentum (például: egy elektronikus aláírással és időpecséttel nem ellátott PDF fájl), melyre a jelen specifikációban megjelölt lenyomatképző algoritmusok egyikével az eladó rendszere hash-kódot képez. Ezt a hexadecimális számot a számláról adott adatszolgáltatás részeként közli a NAV-val (electronicInvoiceHash elem az invoiceApi.xsd-ben). Eladó oldalon a kibocsátott, vevő oldalon az eladótól kapott elektronikus számlát megfelelő adathordozón őrizni kell. Ha egy adóhatósági ellenőrzés közben az elektronikus számla (ami egy fájl, ebben a példában egy PDF fájl) hitelességét és sértetlenségét igazolni szükséges, akkor erre megfelelő módszer az őrzött állományon az eladó által az adatszolgáltatásban megjelölt algoritmussal képzett hash-érték, valamint az eladó/vevő által őrzött állomány adott algoritmussal képzett hash-értékének egyezősége. Ha tehát az ellenőrzés közben 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 tv-ben megkövetelt hitelessége (ténylegesen az eladó adta ki) és sértetlensége (keletkezése óta az adattartalmán nem módosítottak)."

Ebben a részben föleg archiválással kapcsolatban értekeznek, de a levezetés miatt nekem rendkívül érdekes lenne, hogy ez felhasználható-e aláírással és idöbélyeggel nem rendelkezö pdf számla hitelesség és sértetlenség igazolására.

A folyamat, ahogyan gondoltam: Verzió 1. Számlakiállítás esetén a rendszerünk automatikusan elöször létrehoz egy pdf file-t (aláírás és idöbélyeg nélkül), majd az Invoice XML állományt completenessIndicator>=’false’ értékkel, a manageinvoicerequest-ben felveszem az InvoiceXML (vagy a pdf file, nem vagyok biztos benne) electronicsInvoiceHash értékét megfelelö SHA3-512 vagy SHA-256-val és feltöltöm a számlát. A számla Done státusza után fogom a PDF filet és a generált electronisInvoiceHash értéket (egy másik file-ben tárolva) és átküldöm az ügyfélnek. Ez így rendben lehet? Itt igazából annyit tennék, hogy a pdf hitelesítés helyett a hash értéket használnám fel a számla hitelesítésére.

Verzió 2. Issue 566 Idézet NCTA-Tax 566 Issueból NTCA-tax commented on 3 Dec 2020

"Amennyiben PDF számla és a 3.0-ás verzióban lévő XML-es e-számla IS készül, akkor a két partner megállapodása, melyiket tekintik hiteles számlának. Amennyiben a PDF-et, akkor azt kell megőrizni, amennyiben az XML-t, akkor azt kell megőrizni. A megőrzés szabályait most nem részletezném, az nem is adatszolgáltatási kérdés.

A fentiek alapján ezt az issue-t lezárom, ha felmerülne kérdés, akkor új issue-ban beszéljük meg."

Amennyiben ezt a verziót választom, akkor ugye a completenessIndicator>=’true’ lesz viszont ha megállapodok a partnerrel hogy a PDF verziót tároljuk, akkor gondolom az electronicsInvoiceHash értéket az Invoice XML-böl számolom, majd az küldöm el a pdf számlával együtt. Ezt jól gondolom?

Elöre is köszönöm a segítségét.

További szép napot Mindenkinek.

Üdv Péter

csandazoltan commented 3 years ago

Dokumentáció 2.6-os pont

Verzió 1: Igen ez így működhet. A fájlokat jó helyre el kell tenni. Én eltenném a számláról teljes adatközklés xml-ét is, abban van a hash képzés módja is.

Verzió 2:NTCA-tax furán fogalmazott, ez valójában két külön metódus amit előre el kell dönteni melyik utat járod. Amikor adatot szolgáltatsz, készül egy xml amit lehet elektromos számlának tekinteni. Ha PDF-et tekintik hitelesnek annak hash-ét kell szolgáltatni completenessindicator false-al, ha az xml-t akkor annak a hash-ét, completenessindicator true-val

Amennyiben ezt a verziót választom, akkor ugye a completenessIndicator>=’true’ lesz viszont ha megállapodok a partnerrel hogy a PDF verziót tároljuk, akkor gondolom az electronicsInvoiceHash értéket az Invoice XML-böl számolom, majd az küldöm el a pdf számlával együtt. Ezt jól gondolom?

Ez így nem jó! Vagy egyik, vagy másik.... Ha completenessindicator true-val szolgáltatod az adatot akkor az XML lesz a hiteles, a PDF "nem tekinthető" hitelesnek, mert nem annak a hash-ét küldted a nav-nak.

Sajnos olyat nem lehet, hogy mindkettő hiteles. Ha a PDF-et tekintitek hitelesnek, akkor annak a hash-ét kell beküldeni, completenessindicator=false -al.

Elég érdekes kialakítás

WittmannWien commented 3 years ago

Nagyon szépen köszönöm a választ.

Akkor marad verzió 1: a completnessindicator= false és a pdf hash értékékkel történö beküldés, majd pedig a hash értéket mellékelem a pdf állományhoz, amely biztosítja a hitelességet és sértetlenséget. Hálás vagyok érte. További szép napot.

csandazoltan commented 3 years ago

@WittmannWien Én nem vagyok hiteles forrás ;) én így olvastam ki a leírásból és más kérdésekben is ezek a válaszok jöttek nekem

KMGY100 commented 3 years ago

Annyit hozzátennék a PDF hash értékékkel történö kibocsájtásához (mint elektronikus számla) hogy a HASH értéket a file nevében helyezném el, , így a számla befogadójának egyszerűbb a PDF és a HASH kód egyidejű őrzése.

DrotosTot commented 3 years ago

Mi még teszünk a fájlra egy read-only attribútumot, biztos, ami biztos alapon.

zsoftadmin commented 3 years ago

Egy lehetséges megoldás:

  1. Legenerálod a számla XML és HASH állományát (teljes adattartalommal)
  2. Elkészíted a PDF nézetét a számlának úgy, hogy csatolmányként hozzáteszed az XML és a HASH fájlokat.
  3. Az XML-t beküldöd a NAV-nak completenessindicator true-val.
  4. A PDF-et - melyben ott a hiteles XML számla melléklet - elküldöd a vevőnek.
WittmannWien commented 3 years ago

Nagyon szépen köszönöm az információkat. Hálás vagyok érte. Mindenkinek további szép napot.

dkekesi commented 3 years ago

Kicsit későn csatlakozok, elnézést. Ha az adatszolgáltatásban a completenessindicator true, és a számla PDF-en van aláírás+időbélyeg, akkor technikailag mindkettő hitelesnek tekinthető. Ilyenkor mit kell megőrizni?

csandazoltan commented 3 years ago

Kicsit későn csatlakozok, elnézést. Ha az adatszolgáltatásban a completenessindicator true, és a számla PDF-en van aláírás+időbélyeg, akkor technikailag mindkettő hitelesnek tekinthető. Ilyenkor mit kell megőrizni?

Tudtommal ha a completenessindicator true akkor az adatszolgáltatás xml-e és annak hash-e együtt hiteles a NAV felé. Azt kell megőrizni és az audit során felmutatni.

Az aláírt PDF az csak abból a szempontból hiteles, hogy te állítottad ki. NAV ellenőrzés szempontjából nem lehet majd felhasználni.

PDF akkor lesz mérvadó, ha a completenessindicator false és annak a PDF fájlnak a hash-ét adod a navnak.

A kettőt együtt nem lehet, egy hiteles dokumentum lehet.

dkekesi commented 3 years ago

Köszi, de akkor a fogadónak is az XML-t kellene megőriznie, viszont nem feltétlenül tudja, hogy azt kell. Főleg, ha nem nézi, hogy a NOL-ban mi és hogyan jött be.

dkekesi commented 3 years ago

"A kettőt együtt nem lehet, egy hiteles dokumentum lehet." Ez hol van leírva, hogy csak egy hiteles lehet? Azt értem, hogy a hash kód csak egy adatfolyamra vonatkozhat, de a hitelesség nem csak a NOL álatl tárolt hash-sel biztosítható.

dkekesi commented 3 years ago

Annyit hozzátennék a PDF hash értékékkel történö kibocsájtásához (mint elektronikus számla) hogy a HASH értéket a file nevében helyezném el, , így a számla befogadójának egyszerűbb a PDF és a HASH kód egyidejű őrzése.

Állandóan belefutok ebbe az "egyszerűsítésbe". Egyszerűbb, valóban, de semmi értelme így ellenőrizni. A hash-ek önmagukban semmire sem jók. Tartalom integritásának ellenőrzésére csak akkor alkalmasak, ha egy harmadik, megbízható, auditált fél garantálja a módosíthatatlanságukat. Erre szolgál az elektronikus aláírás vagy a megbízható forrásból biztonságos csatornán beszerzett lenyomat, mint amilyen a NAV Online. A számlával egy emailben elküldött hash esetén egy támadó nem csak a számla csatolmányt fogja kicserélni a mellékletben, hanem a hash-t is.

csandazoltan commented 3 years ago

Köszi, de akkor a fogadónak is az XML-t kellene megőriznie, viszont nem feltétlenül tudja, hogy azt kell. Főleg, ha nem nézi, hogy a NOL-ban mi és hogyan jött be.

Megmondom őszintén nem tudom mi az a "NOL" ha a completenessindicator az true akkor a navból töltheti le a vevő azt a számlát, akármilyen módon, de erről meg neki kell gondoskodnia

Igen, a fogadónak is az XML-t kell megőrizni, de erre már a számlakiállítás előtt meg kell állapodni neked a vevővel. Dokumentáció 2.6.2 f

Az Áfa törvény alapján az elektronikus számlázáshoz a vevőnek hozzá kell járulnia. Ebben a két partnernek kell megállapodnia, az adóhivatal nem vállalja át a megállapodás létrejöttéhez kapcsolódó ügyvitelt még részben sem. A vevő elektronikus számlázáshoz történő hozzájárulása – az általános szabályok szerint – megtörténhet írásban, szóban, ráutaló magatartással is, azonban ez az Online Számla rendszeren kívüli hozzájárulást jelent.

"A kettőt együtt nem lehet, egy hiteles dokumentum lehet." Ez hol van leírva, hogy csak egy hiteles lehet? Azt értem, hogy a hash kód csak egy adatfolyamra vonatkozhat, de a hitelesség nem csak a NOL álatl tárolt hash-sel biztosítható.

Ez nincs kifelyezetten leírva. A technikai követelmények és az xsd szabály nem engedi. Nem tudsz egyszerre a navnak egy PDF hash-ét és az adatszolgáltatás XML-enék hash-ét beküldeni, kizárják egymást (completenessindicator)

Az hogy a PDF hitelesítve van és alá van írva, az nem jelenti az, hogy a NAV azt tekinti hitelesnek az online adatszolgáltatás szempontjából, csak ha az adatszolgáltatásnál annak PDF-nek a hash-ét. pláne, hogy ebben az esetben nem is kell aláírni pdf-et

2 külön hitelességről beszélünk. (hülye magyar nyelv) Van PDF certificate ami aláírja és hitelesíti, hogy a te céged állította ki azt a PDF-et és van a navnak küldött elektronikus számla hitelesség, ami a nav adatszolgáltatás szempontjából hiteles és hiteles lesz bármilyen vitás esetben és/vagy NAV ellenőrzéskor

Ez lehet egy scannelt JPEG is ha az adattartalma megfelel az áfatörvénynek

Effektíve 1 db elektronikus számlát lehet az adatszolgáltatásba beletenni és azt kell megőrizni

csandazoltan commented 3 years ago

Annyit hozzátennék a PDF hash értékékkel történö kibocsájtásához (mint elektronikus számla) hogy a HASH értéket a file nevében helyezném el, , így a számla befogadójának egyszerűbb a PDF és a HASH kód egyidejű őrzése.

Állandóan belefutok ebbe az "egyszerűsítésbe". Egyszerűbb, valóban, de semmi értelme így ellenőrizni. A hash-ek önmagukban semmire sem jók. Tartalom integritásának ellenőrzésére csak akkor alkalmasak, ha egy harmadik, megbízható, auditált fél garantálja a módosíthatatlanságukat. Erre szolgál az elektronikus aláírás vagy a megbízható forrásból biztonságos csatornán beszerzett lenyomat, mint amilyen a NAV Online. A számlával egy emailben elküldött hash esetén egy támadó nem csak a számla csatolmányt fogja kicserélni a mellékletben, hanem a hash-t is.

Ez csak félig igaz. Te a certificate-es ellenőrzésről beszélsz.

Ha van meghatározott titkosítási szabvány. Ami a NAV-nál SHA3-512 És a közös pont adott, a nav tárolja a hash-t

Tehát mostmár nem kell az elektronikus aláírás Elkészül a száml és a hash-e Hash bekerül a navhoz a titkosítás módjával együtt. Filet és hash elteszed te és elteszi a vevő. Innentől bármilyen vitás helyzet van, a nav-ot meg kell kérdezni a hashről és az alapján lehet ellenőrizni a fájlok hitelességét.

Nem kell már elektronikusan aláírt PDF, ha a navot használod. Márpedig mindenkinek azt kell

dkekesi commented 3 years ago

Megmondom őszintén nem tudom mi az a "NOL" ha a completenessindicator az true akkor a navból töltheti le a vevő azt a számlát, akármilyen módon, de erről meg neki kell gondoskodnia

Ne haragudj, nem kötözködni szeretnék, csak tisztán látni ebben a kérdésben. Jelmagyarázat: NOL = NAV OnLine Megpróbálom egy példán keresztül szemléltetni. Egy nagy cég szeretné sztenderdizálni a számlakibocsájtási folyamatait, és hogy az összes partnerének (potenciálisan tízezres nagyságrendben) megfeleljen a teljes számlatartalmat beküldi a NAV felé adatszolgáltatásként és a completenessindicator-t true-ra állítja. Ezen felül készít egy PDF fájlt is, amit fokozott biztonságú tanúsítványra épülő kulccsal hitelesít + időbélyegez és ezt a PDF-et elküldi a partnereknek emailben. Így nem kell partnerenként állítani, hogy épp PDF-et vagy XML-t küldjön, egységesen megy mindenkinek. Ha valaki XML letöltést akar, akkor azt használja, ha PDF-ből akar adatot rögzíteni, akkor azt. Ha egy adott partner viszont nem használja számlaletöltésre a NOL-t, akkor soha nem fogja megtudni, hogy neki az onnan letöltött XML-t kellene eltennie és a NAV felé mutogatnia ellenőrzéskor. Nem is lehet senkit kötelezni az XML kezelésére, mivel az nagyvállalati környezetben általában jelentős fejlesztéssel jár.

Az Áfa törvény alapján az elektronikus számlázáshoz a vevőnek hozzá kell járulnia. Ebben a két partnernek kell megállapodnia, az adóhivatal nem vállalja át a megállapodás létrejöttéhez kapcsolódó ügyvitelt még részben sem. A vevő elektronikus számlázáshoz történő hozzájárulása – az általános szabályok szerint – megtörténhet írásban, szóban, ráutaló magatartással is, azonban ez az Online Számla rendszeren kívüli hozzájárulást jelent.

Ez teljesen másra vonatkozik, nevezetesen arra, hogy az e-szmlázásról általánosságban meg kell állapodni, nem arról, hogy az XML vs PDF hitelességének kérdéskörét szabályozzák.

Ez lehet egy scannelt JPEG is ha az adattartalma megfelel az áfatörvénynek

Ez nem teljesen helytálló kijelentés, mert egy szkennelt papír csak akkor lesz hiteles elektronikus dokumentum, ha megfelel a külön rendeletben meghatározott másolatkészítési szabályoknak, ami nem egységes mindenkire nézve. Ráadásul a hash ebben az esetben be sem küldtehő az adatszolgáltatással.

dkekesi commented 3 years ago

Annyit hozzátennék a PDF hash értékékkel történö kibocsájtásához (mint elektronikus számla) hogy a HASH értéket a file nevében helyezném el, , így a számla befogadójának egyszerűbb a PDF és a HASH kód egyidejű őrzése.

Állandóan belefutok ebbe az "egyszerűsítésbe". Egyszerűbb, valóban, de semmi értelme így ellenőrizni. A hash-ek önmagukban semmire sem jók. Tartalom integritásának ellenőrzésére csak akkor alkalmasak, ha egy harmadik, megbízható, auditált fél garantálja a módosíthatatlanságukat. Erre szolgál az elektronikus aláírás vagy a megbízható forrásból biztonságos csatornán beszerzett lenyomat, mint amilyen a NAV Online. A számlával egy emailben elküldött hash esetén egy támadó nem csak a számla csatolmányt fogja kicserélni a mellékletben, hanem a hash-t is.

Ez csak félig igaz. Te a certificate-es ellenőrzésről beszélsz.

Ha van meghatározott titkosítási szabvány. Ami a NAV-nál SHA3-512 És a közös pont adott, a nav tárolja a hash-t

Tehát mostmár nem kell az elektronikus aláírás Elkészül a száml és a hash-e Hash bekerül a navhoz a titkosítás módjával együtt. Filet és hash elteszed te és elteszi a vevő. Innentől bármilyen vitás helyzet van, a nav-ot meg kell kérdezni a hashről és az alapján lehet ellenőrizni a fájlok hitelességét.

Nem kell már elektronikusan aláírt PDF, ha a navot használod. Márpedig mindenkinek azt kell

Itt egy pár dolog nem stimmel. Az SHA3-512 nem titkosítási szabvány, hanem lenyomatképző algoritmus, így nem titkosít semmit, és ÖNMAGÁBAN, egy emailben elküldve nem biztosítja az eredet hitelességét, valamint az adattartalom sértetlenségét sem. Továbbá én kifejezetten arra a folyamatra reflektáltam, ami a hozzászólásban szerepelt: "a HASH értéket a file nevében helyezném el, így a számla befogadójának egyszerűbb a PDF és a HASH kód egyidejű őrzése". A hash-t eleve nem raknám el, hanem ha ellenőrizni kell, akkor az algoritmus alapján (a lenyomatképző algoritmus megnevezését rakom el) újraszámolom, mert az a biztos. Ha mégis elraknám, akkor meg a NOL-ból venném, mert az hiteles. Ha meg a NOL-ból veszem, akkor mindegy mi van az emailben. A folyamat, amit te leírtál az jó, csak az eredeti hozzászólás arról szólt, hogy az emailben küldött hash-ben bízzunk meg. Én nem tenném... A legalább fokozott biztonságú tanúsítvány alapú ellenőrzést csak mint alternatívát írtam.

Macskafarka commented 3 years ago

@dkekesi -től erre reagálnék: "Ezen felül készít egy PDF fájlt is, amit fokozott biztonságú tanúsítványra épülő kulccsal hitelesít + időbélyegez és ezt a PDF-et elküldi a partnereknek e-mailben. Így nem kell partnerenként állítani, hogy épp PDF-et vagy XML-t küldjön, egységesen megy mindenkinek. Ha valaki XML letöltést akar, akkor azt használja, ha PDF-ből akar adatot rögzíteni, akkor azt." -Ez a logika nagyon sántít. Szerintem a számlakibocsátónak egyértelműen kell eldöntenie, hogy melyik a számla [eredeti] példánya. Nem teheti meg, hogy elkészíti PDF-ben is és XML-ben is, ellátja mindenféle hitelesítéssel, aztán a vevő majd eldönti melyiket használja. Hát nagyon nem így van! Csak az egyik lehet az [eredeti], és azt kell őrizgetni, és azt kell a vevőnek elküldeni. Borzasztóan nehéz kérdés ez, én sem a logika, sem az informatika, hanem a jog oldaláról indultam ki. A jog szerint kéretik a számlakibocsátónak meghatározni, melyik az eredeti vagy PDF, vagy az XML. Ezt számlabizonylatonként is eldöntheti. A sztenderdizálásnak megfelel az általad felvázolt logika, és nekem szimpatikus is. csak jogilag tartom aggályosnak.

csandazoltan commented 3 years ago

Nem kötözködés, csak próbálom átadni amit nekem mondtak, illetve fedeztek fel

Ez nem teljesen helytálló kijelentés, mert egy szkennelt papír csak akkor lesz hiteles elektronikus dokumentum, ha megfelel a külön rendeletben meghatározott másolatkészítési szabályoknak, ami nem egységes mindenkire nézve. Ráadásul a hash ebben az esetben be sem küldtehő az adatszolgáltatással.

OK a scannelt JPG erős volt, de egy generált jpg mehet. A leírásban az van, hogy áfa törvénynek megfelelő digitláis dokumentum PDF a legegyszerűbb, de az lehet, DOC, XLS, XML, majdnem bármi. Most volt jogzsabálymódosítás

A példádra válaszolva. Kicist fordítva látod a dolgot, nem te mondod meg, hogy küldöd az eszámlát. megcsinálhatod úgy, hogy a partnernél szerződéskötéskör megegyezel, (eszámlához meg kell egyezni, fent idéztem) hogy miként szeretné a számlát.

De ha digitálisan akarsz, akkor javaslom fixáld be a PDF-et, hash-et beküldve, completenessindicator FALSE-al és már partnerrel már az elején le kell játszani, hogy a PDF-eket meg kell őrizni. Céges környezetben szerintem már mindenki tudja mi az a PDF és eszámla

csandazoltan commented 3 years ago

@dkekesi -től erre reagálnék: "Ezen felül készít egy PDF fájlt is, amit fokozott biztonságú tanúsítványra épülő kulccsal hitelesít + időbélyegez és ezt a PDF-et elküldi a partnereknek e-mailben. Így nem kell partnerenként állítani, hogy épp PDF-et vagy XML-t küldjön, egységesen megy mindenkinek. Ha valaki XML letöltést akar, akkor azt használja, ha PDF-ből akar adatot rögzíteni, akkor azt." -Ez a logika nagyon sántít. Szerintem a számlakibocsátónak egyértelműen kell eldöntenie, hogy melyik a számla [eredeti] példánya. Nem teheti meg, hogy elkészíti PDF-ben is és XML-ben is, ellátja mindenféle hitelesítéssel, aztán a vevő majd eldönti melyiket használja. Hát nagyon nem így van! Csak az egyik lehet az [eredeti], és azt kell őrizgetni, és azt kell a vevőnek elküldeni. Borzasztóan nehéz kérdés ez, én sem a logika, sem az informatika, hanem a jog oldaláról indultam ki. A jog szerint kéretik a számlakibocsátónak meghatározni, melyik az eredeti vagy PDF, vagy az XML. Ezt számlabizonylatonként is eldöntheti. A sztenderdizálásnak megfelel az általad felvázolt logika, és nekem szimpatikus is. csak jogilag tartom aggályosnak.

Nem döntheti el a számlakibocsájtó, mint idéztem a leírásból:

Az Áfa törvény alapján az elektronikus számlázáshoz a vevőnek hozzá kell járulnia. Ebben a két partnernek kell megállapodnia, az adóhivatal nem vállalja át a megállapodás létrejöttéhez kapcsolódó ügyvitelt még részben sem. A vevő elektronikus számlázáshoz történő hozzájárulása – az általános szabályok szerint – megtörténhet írásban, szóban, ráutaló magatartással is, azonban ez az Online Számla rendszeren kívüli hozzájárulást jelent.

Köteles vagy számlát kiállítani, de azt olyan formában kell, amit a vevő be tud fogadni. Alapértelmezetten ez a nyomtatott papír Ha nem képes PDF-et biztonságosan tárolni, vagy nincs az Online rendszerbe bekötött számviteli szoftver ami XML-t letölti a nav-tól. Akkor nem tolhatod rá a PDF-et Ezért kell a megegyezés

Persze a szürke zóna megvan, hogy "ráutaló magatartás" = "Ha használod a progit akkor PDF eszámlát kapsz és arról neked kell gondoskodni, hogy megőrizd 5 évig" Ami persze egy gmail fiókot is jelenthet, vagy egy pendrive a fiókban, ez már a vevő kötelessége

zsoftadmin commented 3 years ago

@dkekesi

csandazoltan commented 3 years ago

@zsoftadmin

  • Ha egy cég rendelkezik külső hitelesítéssel, teljesen felesleges neki a NAV hitelesítését használni.

Ha nem adjuk meg az elektronikus számla hash-et az adatoszolgáltatáskor akkor is elfogadott a certificate-es PDF?

zsoftadmin commented 3 years ago

@csandazoltan A külső szolgáltatón keresztül történő hitelesítés és a NAV-os hitelesítés két eltérő hitelesítési forma. Mindkettő elfogadott, de nem célszerű keverni őket. Külső hitelesítésnél a NAV-hoz csak egyszerű adatszolgáltatás kell. A számla hitelességét ilyenkor a külső szolgáltató biztosítja (nem a NAV).

fenyvessy commented 3 years ago

@dkekesi:

Jelmagyarázat: NOL = NAV OnLine

Ez valami publikusan elérhető új szolgáltatás valahol?

Megpróbálom egy példán keresztül szemléltetni. Egy nagy cég szeretné sztenderdizálni a számlakibocsájtási folyamatait, és hogy az összes partnerének (potenciálisan tízezres nagyságrendben) megfeleljen a teljes számlatartalmat beküldi a NAV felé adatszolgáltatásként és a completenessindicator-t true-ra állítja.

Ez az eddig felsoroltakon túlmenően ott is elbukik, hogy a magánszemély vevő adatait nem küldheted be az XML-ben, tehát ilyen módon nem állíthatsz ki számlát magánszemély vevő részére. Ott e-számla vonalon marad a PDF külső hitelesítéssel vagy NAV SHA3-512 hash-al.

dkekesi commented 3 years ago

@zsoftadmin

Köszi a választ.

Ha viszont a NAV-hoz completenessindicator true-val történik a beküldés, akkor az a hiteles számla-verzió, és azt kell elküldeni a vevőnek is.

Na erre vonatkozóan nem találtunk semmilyen szabályozást.

A mai PDF dokumentumokba tetszőleges fájl beágyazható, így nem szükséges külön küldeni a pdf-et és az xml fájlt, mehet egyben is. Így nem kell az ügyfélnek xml-t kezelnie, és fel sem merül a "mit archiváljak" kérdés.

Igen, talán ez a legjobb általános megoldás. completenessindicator false és mindenki azt használ, amit akar, miközben mindkét fájlt elrakja.

dkekesi commented 3 years ago

A példádra válaszolva. Kicist fordítva látod a dolgot, nem te mondod meg, hogy küldöd az eszámlát. megcsinálhatod úgy, hogy a partnernél szerződéskötéskör megegyezel, (eszámlához meg kell egyezni, fent idéztem) hogy miként szeretné a számlát.

Tudom jól, hogy meg kell egyezni. Viszont ha abban egyezünk meg, hogy PDF-et kap, de mellette készül XML is, akkor a vevő nem fogja leharapni a fejem, max nem foglalkozik az XML-lel. Fordítva szintén: ha XML-ben egyezünk meg és mellé kap PDF-et is, akkor azt ignorálja.

csandazoltan commented 3 years ago

A példádra válaszolva. Kicist fordítva látod a dolgot, nem te mondod meg, hogy küldöd az eszámlát. megcsinálhatod úgy, hogy a partnernél szerződéskötéskör megegyezel, (eszámlához meg kell egyezni, fent idéztem) hogy miként szeretné a számlát.

Tudom jól, hogy meg kell egyezni. Viszont ha abban egyezünk meg, hogy PDF-et kap, de mellette készül XML is, akkor a vevő nem fogja leharapni a fejem, max nem foglalkozik az XML-lel. Fordítva szintén: ha XML-ben egyezünk meg és mellé kap PDF-et is, akkor azt ignorálja.

Igen! Ezt így lehet, csak tudni kell mindkét félnek, hogy mit kell megőrizni

dkekesi commented 3 years ago

Megpróbálom egy példán keresztül szemléltetni. Egy nagy cég szeretné sztenderdizálni a számlakibocsájtási folyamatait, és hogy az összes partnerének (potenciálisan tízezres nagyságrendben) megfeleljen a teljes számlatartalmat beküldi a NAV felé adatszolgáltatásként és a completenessindicator-t true-ra állítja.

Ez az eddig felsoroltakon túlmenően ott is elbukik, hogy a magánszemély vevő adatait nem küldheted be az XML-ben, tehát ilyen módon nem állíthatsz ki számlát magánszemély vevő részére. Ott e-számla vonalon marad a PDF külső hitelesítéssel vagy NAV SHA3-512 hash-al.

Igaz, de ezt azért elég egyszerű leprogramozni, így általános marad a számlakiállítás. Azt szeretném elkerülni, hogy partnerenként kelljen állítgatni, hogy kinek küldök XML-t és kinek PDF-et attól függően, hogy mire van épp igénye.

dkekesi commented 3 years ago

Igen! Ezt így lehet, csak tudni kell mindkét félnek, hogy mit kell megőrizni

Ezért egyszerűbb mindent adni és archiválni. A storage olcsó, a fájlok jellemzően nem nagyok. A folyamatok meg abból dolgoznak, amiből jól esik.

topybear commented 3 years ago

Ez az eddig felsoroltakon túlmenően ott is elbukik, hogy a magánszemély vevő adatait nem küldheted be az XML-ben, tehát ilyen módon nem állíthatsz ki számlát magánszemély vevő részére. Ott e-számla vonalon marad a PDF külső hitelesítéssel vagy NAV SHA3-512 hash-al.

Az utóbbinál erősen rezeg a léc, tekintettel arra, hogy a magánszemély nem tudja kinyerni a NAV-tól a számla hash-t, így hitelességet sem tud ellenőrzini.

csandazoltan commented 3 years ago

Megpróbálom egy példán keresztül szemléltetni. Egy nagy cég szeretné sztenderdizálni a számlakibocsájtási folyamatait, és hogy az összes partnerének (potenciálisan tízezres nagyságrendben) megfeleljen a teljes számlatartalmat beküldi a NAV felé adatszolgáltatásként és a completenessindicator-t true-ra állítja.

Ez az eddig felsoroltakon túlmenően ott is elbukik, hogy a magánszemély vevő adatait nem küldheted be az XML-ben, tehát ilyen módon nem állíthatsz ki számlát magánszemély vevő részére. Ott e-számla vonalon marad a PDF külső hitelesítéssel vagy NAV SHA3-512 hash-al.

Igaz, de ezt azért elég egyszerű leprogramozni, így általános marad a számlakiállítás. Azt szeretném elkerülni, hogy partnerenként kelljen állítgatni, hogy kinek küldök XML-t és kinek PDF-et attól függően, hogy mire van épp igénye.

adatszolgáltatás mindig van, tehát xml is, PDF mindig lesz, akkor igazán csak pár sor kód beépíteni, hogy a felhasználó szerződésén alapulva mi legyen egy legördülő menüjében a profilján

csandazoltan commented 3 years ago

Ez az eddig felsoroltakon túlmenően ott is elbukik, hogy a magánszemély vevő adatait nem küldheted be az XML-ben, tehát ilyen módon nem állíthatsz ki számlát magánszemély vevő részére. Ott e-számla vonalon marad a PDF külső hitelesítéssel vagy NAV SHA3-512 hash-al.

Az utóbbinál erősen rezeg a léc, tekintettel arra, hogy a magánszemély nem tudja kinyerni a NAV-tól a számla hash-t, így hitelességet sem tud ellenőrzini.

Magánszemély problémás, completenessindicator nem is lehet true náluk

És igen, többen kérték már, hogy legyen egy publikus hely ahol lehet hash-t ellenőrizni, fájlal, vagy nélküle Oldal, api vagy bármi

fenyvessy commented 3 years ago

Ez az eddig felsoroltakon túlmenően ott is elbukik, hogy a magánszemély vevő adatait nem küldheted be az XML-ben, tehát ilyen módon nem állíthatsz ki számlát magánszemély vevő részére. Ott e-számla vonalon marad a PDF külső hitelesítéssel vagy NAV SHA3-512 hash-al.

Az utóbbinál erősen rezeg a léc, tekintettel arra, hogy a magánszemély nem tudja kinyerni a NAV-tól a számla hash-t, így hitelességet sem tud ellenőrzini.

Igen, rezeg a léc, de jogszerű az e-számla kiállítása, és teljesül az adatszolgáltatási kötelezettség is. Mint ahogy a magánszemély vevő részéről is jogszerű, ha visszadobja bitkupacot és helyette papírt kér. Hiszen egy postai úton küldött papír számla hitelességét sokkal jobban le tudja ellenőrizni... (Hogyan is? :D)

dkekesi commented 3 years ago

adatszolgáltatás mindig van, tehát xml is, PDF mindig lesz, akkor igazán csak pár sor kód beépíteni, hogy a felhasználó szerződésén alapulva mi legyen egy legördülő menüjében a profilján

Pont ez az, hogy nem akarnak szerződgetni senkivel, eddig se tették. Kell e-számla? Igen/nem, ennyi (emailben kapnak mintát, megnézik, hogy a rendszereikkel együttműködik-e, visszaírnak hogy OK, onnantól megy az eszámla a megadott címekre). Mivel elég nagy hangsúlyt fektetünk a szabványosságra (nem hibákkal teli PDF-eket és XML-eket gyártunk), ezért senki nem panaszkodik. 10+ éve megy. Továbbá az adatformátum nem egy állandó, fix dolog. Az elején lehet hogy PDF kell, aztán kitalálják, hogy XML-t kérnek, aztán mégis vissza PDF-re, mert valamit elrontottak :) Ezt a kutya sem akarja adminisztrálni. Az egészet megette a fene, ha csak a töredezettség nő és nincs technológiai egységesség.

csandazoltan commented 3 years ago

adatszolgáltatás mindig van, tehát xml is, PDF mindig lesz, akkor igazán csak pár sor kód beépíteni, hogy a felhasználó

A 10 éves suzuki is megy, való igaz.... Személyes hozzászólás: Annyira imádom az ilyen hozzáállást, ha "működik" addig nem kell új. Ezért nyomtatnak néhány helyen még mindig tűs nyomtatóval. és windows 3.1-el működő edo ramos gépekkel megy a futószalag Nehogy véletlen haladjunk a korral Személyes hozzászólás vége

Szakmai hozzászólás: Igen, nem tudom milyen rendszerről van szó De ha meg van csinálva a rendszer, a lehetőségek adottak, akkor a partner fogja eldönteni mit akar, mert ő dolga lesz azzal foglalkozni és nem kell adminisztrálni semmit Te eleget tettél a számlakiadási kötelezettségnek az ügyféllel megyegyezve/kérésére abban a formátumban Nem kell minden ügyféllel szerződést kötni, navot nem érdekli, hogy milyen egyezség van. Ráutaló magatartás is lehet "Ha a szofteverem használod, lehetőséged van elektronikus számlára, ezt a profilodban beállíthatod" - Leírod a szabályokat és kész. A programba minimális változtatás kell Ha már a háttérben minden a rendelkezésre áll, miért ne adnánk oda a partnernek, minél többen használják a szabványokat annál egyszerűbb és gyorsabb lesz minden

Lehet vannak hiányosságai a NOL-nak, de én imádom, ami működik az marha jó, struktúrált adatközlés, nincs hercehurca. Rendeléstől 2 perc sincs mire a számla az ügyfélnél landol és az árut már készül is össze. Közel 0 adminisztrációval De nem kell haladni a korral

dkekesi commented 3 years ago

A szerződéskötést más kontextusban értettem, arra reagáltam. A személyes hozzászólásod - suzukis hasonlatod - nem igazán állja meg a helyét, mert a 10 éves autó olyan, amilyen, nem fejlesztik. A 10 éves rendszert viszont vélhetően igen, azért van még 10 év után is egy olyan dinamikusan változó szegmensben mint az eszámlázás. Ami viszont biztos, hogy az informatika az automatizálásról szól, amihez kell a szabványosítás. Senki - sem eladó, sem vevő - nem akar adminisztrációval foglalkozni, főleg, ha eddig sem kellett. Nem tudom, hogy mennyire látsz bele nagy cégek működésébe, de ott sokszor azt se tudják, hogy az ezredik partner portálra ki tud belépni, nemhogy hol kell állítani a számlatípust (ha egyáltalán még a cégnél dolgozik az illető). Ez nem jó, de ez a valóság. Remélem nem azt szűrted le a mondandóimból, hogy számomra a NOL egy ördögtől való problémahalmaz, mert ilyet sehol nem írtam, sőt, ebben egyezik a véleményünk: egy jól összerakott - és hála a NAV isteneinek - egy fejlesztett, támogatott megoldás. A problémákat én a folyamatokban és azok tisztázatlanságában, műszaki töredezettségében látom. A NOL ezeknek a folyamatoknak csak egy töredéke.

janisoft commented 3 years ago

Nem lehet keverni az XML-t es a PDF-et. Amennyiben a completenessIndicator=true, akkor az XML a "számla". Mellekesen ilyenkor az XML-ben minden adatmezot ki kell tolteni, amit amugy a szamlan szeretnek megjeleniteni. Mindket felnek az XML-t kell archivalni es adohatosagi vizsgalaton prezentalni. Az XML melle generalhato PDF a nezegeteshez, de az nem szamla, szerintem megteveszto is Szamla cimmel ellatni, sokkal inkabb Szamlakep vagy Szamlamelleklet vagy barmi (otletek johetnek). Alairni sem szukseges. Ha a PDF a szamla, akkor a torvenyi megfelelest a bekuldott HASH vagy az alairas biztositja. Mindket fel a PDF-et koteles archivalni, es bemutatni. Az XML-nek ilyenkor csak adatszolgaltatasi funkcioja van, az elozovel ellentetben ilyenkor csak az AFA tv 169 par szerinti adatokat kotelezo kitolteni, egyeb szamla adattartalmat nem.

Jogszeruen ki lehet allitani PDF vagy akar doc, jpeg szamlat is alairas es hash nelkul is. A befogado kotelessege ilyenkor gondoskodni az archivalasrol, pl digitalis alairassal.

Ugy gondolom a befogadoi oldalon osszetettebb a helyzet, mint kibocsatoi oldalon, mivel a kibocsato tudja mit kuld, de a befogadonak azonositani kell, hogy melyik esetrol van szo, es annak megfeleloen eljarni az ellenorzessel es archivalassal kapcsolatban.

Janos

dkekesi commented 3 years ago

Köszönöm a választ.

Nem lehet keverni az XML-t es a PDF-et.

Erre van valahol leírás, jogszabály, rendelet, törvény?

Ugy gondolom a befogadoi oldalon osszetettebb a helyzet, mint kibocsatoi oldalon, mivel a kibocsato tudja mit kuld, de a befogadonak azonositani kell, hogy melyik esetrol van szo, es annak megfeleloen eljarni az ellenorzessel es archivalassal kapcsolatban.

Ez azt jelenti, hogy a befogadónak mindenképpen onlineszámlát kell használnia, ha kétséget kizáróan meg akarja tudni, hogy melyik fájlt archiválja, ha esetleg kap különálló PDF-et és XML-t?

zsoftadmin commented 3 years ago

@janisoft Némi ellentmondást érzékeltem a bejegyzésedben: először azt írod, hogy nem lehet keverni az xml-t és a pdf-et, utána pedig azt, hogy az xml mellé egy pdf generálható... - Értem, hogyan gondoltad, de mivel más bejegyzésekben is érzékeltem némi zavart ezen a téren, kiegészítésképpen pár gondolatot megosztanék:

A zavar valószínűleg a különböző hitelesítési módokból fakad. Külső hitelesítésnél a szolgáltató leggyakrabban egy fájlt hitelesít, ami általában egy olvasható dokumentum (pl. pdf, jpg), míg a NAV a beküldött XML állományt hitelesíti. Egy XML állomány olvasása ill. értelmezése eredeti formájában nem várható el egy hétköznapi embertől, emiatt szükséges valamilyen megjelenítőt is csatolni mellé. Ez lehet akár egy pdf dokumentum is. Fontos, hogy míg az első esetben a hiteles dokumentum az olvasható számlakép, addig a NAV-os verzióban az olvasható dokumentum csak egy "megjelenítő", - a hiteles számla az "olvashatatlan" XML állomány.

Elvárás, hogy a vevő megkapja a hiteles számlát és a hitelesség ellenőrzéséhez szükséges adatokat. Külső szolgáltatónál általában a dokumentum mellé elküldik a hitelesítést végző szolgáltató adatait és az ellenőrző bélyegzőt. NAV-os hitelesítésnél pedig elküldik az XML fájlt és az olvasható dokumentum-képet (pl. pdf-et).

Kultúrált (és javallott) megoldás, hogy a vevő egyetlen fájlban kapja meg az összes adatot (pl. zip fájlban), mert akkor nem fordulhat elő, hogy az ügyintéző a számla valamelyik részét elfelejti archiválni. A NAV-os verzió további előnye, hogy elegendő hozzá egyetlen pdf fájl, amibe be van ágyazva a beküldött XML és HASH állomány.

janisoft commented 3 years ago

@zsoftadmin Ugy ertettem, hogy vagy a PDF a szamla vagy az XML (XOR a kapcsolat :) mindketto nem lehet egyszerre. Kiegeszito informacio barmikor kuldheto a szamlahoz akar pdf-ben, akar xml-ben, akar szabad szovegesen, pl szamlamelleklet, alairt szallitolevel, teljesitesi igazolas, stb.

Befogadoi oldalon mindenkeppen erdemes a NAV online rendszerebol kinyerni az informaciot. Lekerdezheto a conpletenessindicator, azaz eldontheto, hogy az XML (amit erdemes letolteni minden esetben a NAV-tol) a szamla vagy nem. Ha nem, akkor le kell kerdezni a hash kodot. Ha van, akkor lefuttathato a PDF(vagy egyeb elektronikus fajl) ellenorzese. Ha nincs hash, akkor PDF eseten ellenorizni kell az alairas megletet, ervenyesseget. Ha nincs ervenyes alairas, akkor el kell latni egy sajattal, es akkor archivalhato.

csandazoltan commented 3 years ago

Még mindig keveritek páran a dolgokat, mindenkinek egyszerre, ugyanazok a kérdések jönnek elő újra és újra:

Nem lehet keverni az XML-t es a PDF-et.

Erre van valahol leírás, jogszabály, rendelet, törvény?

Nincs, ennek technikai korlátja van. Mint írtam, navnak mint hiteles elektronikus számlát 1 db dokumentumot lehet jelenteni. Létezhet több fájl, igen. De előre el kell dönteni, hogy mi lesz a számlázás és a nev szempontjából a hiteles, tárolandú dokumentum. Minden más csak "szemét"

Ugy gondolom a befogadoi oldalon osszetettebb a helyzet, mint kibocsatoi oldalon, mivel a kibocsato tudja mit kuld, de a befogadonak azonositani kell, hogy melyik esetrol van szo, es annak megfeleloen eljarni az ellenorzessel es archivalassal kapcsolatban.

Ez azt jelenti, hogy a befogadónak mindenképpen onlineszámlát kell használnia, ha kétséget kizáróan meg akarja tudni, hogy melyik fájlt archiválja, ha esetleg kap különálló PDF-et és XML-t?

Nem jelenti azt. A befogadónak azt kell használni ahogy megegyezik a kibocsájtóval. Ha azt mondja a vevő, hogy ő papírt szeretne. Akkor azt kell adni. Nem lehet ráerőszakolni a vevőre a eszámlát. Viszont, ha a programod csak eszámlát tud kiállítani. Akkor még bármilyen ügylet előtt ezt tisztázni kell a befogadóval. Ha ebbe beleegyezik, akkor mehet a számla azon a módon ahogy meg lett egyezve. Ha PDF akkor pdf, ha a számviteli programja be van kötve a nav-hoz akkor XML és onnan tölti a neki kiállított számlát mindenkitől aki úgy küldi. Ha nem egyezik bele akkor kisnyúl, egyikőtöknek sem kötlező a másikkal üzletelni.

Egy XML állomány olvasása ill. értelmezése eredeti formájában nem várható el egy hétköznapi embertől, emiatt szükséges valamilyen megjelenítőt is csatolni mellé.

Nem kell neked biztosítani, a PDF sem olvasható embernek, csak ha megynyitod egy harmadik féltől származó programmal. A PDF egy szabványt követ, pont mint az XML Ha a befogadó vállalja, hogy XML NOL számlát befogad akkor neki kell biztosítani ennek feltételeit. Legyen az egy számviteli program ami a NAVtól veszi az adatokat, vagy a NAV ingyenes számlázó progija Emellé hozzájön még, hogy a befogadónak gondoskodni kell a tárolásról

Kultúrált (és javallott) megoldás, hogy a vevő egyetlen fájlban kapja meg az összes adatot (pl. zip fájlban), mert akkor nem fordulhat elő, hogy az ügyintéző a számla valamelyik részét elfelejti archiválni. A NAV-os verzió további előnye, hogy elegendő hozzá egyetlen pdf fájl, amibe be van ágyazva a beküldött XML és HASH állomány.

Ez így nem teljesen jó. A navnak beadott hash fájlját már nem módosíthatod mert az eltolja a hash-t is. completenessindicator false. Egy PDF hash, ebbe bele lehet rakni előre a navnak közölt data xml-t még küldés előtt igen. és utána hash-elni pdf-et és mehet a tényleges nav beküldés completenessindicator true. XML be van küldve, hash-el együtt. Utána bármilyen fájlt csinálhatsz információ jelleggel. De az az XML és hash-e lesz a hiteles elektronikus számla (röviden leheteletlen a fájl hash-ét fájlba tárolni, mintha be akarnád zárni az egyetlen kulcsot a dobozába)

@janisoft Jól látja a dolgokat

zsoftadmin commented 3 years ago

@csandazoltan Valamit nagyon félreértettél....

Nem kell neked biztosítani, a PDF sem olvasható embernek, csak ha megynyitod egy harmadik féltől származó programmal. A PDF egy szabványt követ, pont mint az XML

A való világban elvárás, hogy ha emailen elküldöd a számlát a vevőnek, akkor azt a pénzügyes közvetlenül el tudja olvasni, és még a régimódi könyvelő is képes legyen kinyomtatni. Ma még nem terjedtek el az általad említett szabványos XML megjelenítő programok.

Ez így nem teljesen jó. A navnak beadott hash fájlját már nem módosíthatod mert az eltolja a hash-t is.

Az írásomban nincs szó a hash módosításáról vagy eltolásáról. A vevőnek pontosan a NAV-hoz beküldött XML-t és Hash-t kell elküldeni, de ez a küldés úgy is megvalósítható, hogy zip helyett egy pdf-be ágyazod bele őket, és akkor már egy számlaképet is küldtél...

topybear commented 3 years ago

Szamla cimmel ellatni, sokkal inkabb Szamlakep vagy Szamlamelleklet vagy barmi (otletek johetnek).

"Elektronikus számlamásolat" :)

topybear commented 3 years ago

Van azért zavar rendesen, csak egy példa a valós életből: Céges netes vásárlás, a folyamat során sehol nem lehetett jelezni, hogy milyen számlát kérünk. Szépen megérkezett email-ben egy digitálisan aláírt, időpecsételt pdf. Jeleztük az ügyfélszolgálatnak, hogy ez nem lesz jó, papír alapú számlát kérünk, nem fogadunk be elektronikus számlát. A válasz az volt, hogy nyomtassuk ki, egyébként is benne van az ÁSZF-ben, hogy ők elektronikus számlát állítanak ki, amit a vevőnek kell kinyomtatni (!!!). És tényleg benne van az ÁSZF-ben! A pénzügyesünk persze beleállt a dologba, hogy nem lesz így jó, ráadásul megnézte a NAV-nak lejelentett adatokat, ott bizony elektronikus számlaként van lejelentve. Végül eljutott az ő pénzügyesükhöz, elmondta mit szeretne, kiküldték postával, kinyomtatva, papíron. Most van egy iktatott, papír alapú példányunk, így a mi fenekünk fedezve van.

De aki szót fogad és kinyomtatja, aztán egy ellenőrzésnél azt veszi elő, az nagy sz.rban van, mert minden jel arra mutat, hogy kapott egy elektronikus számlát amit nem archivált megfelelően. Egyébként nem egy kis forgalmú, noname cég számlájáról van szó...

csandazoltan commented 3 years ago

Van azért zavar rendesen, csak egy példa a valós életből: Céges netes vásárlás, a folyamat során sehol nem lehetett jelezni, hogy milyen számlát kérünk. Szépen megérkezett email-ben egy digitálisan aláírt, időpecsételt pdf. Jeleztük az ügyfélszolgálatnak, hogy ez nem lesz jó, papír alapú számlát kérünk, nem fogadunk be elektronikus számlát. A válasz az volt, hogy nyomtassuk ki, egyébként is benne van az ÁSZF-ben, hogy ők elektronikus számlát állítanak ki, amit a vevőnek kell kinyomtatni (!!!). És tényleg benne van az ÁSZF-ben! A pénzügyesünk persze beleállt a dologba, hogy nem lesz így jó, ráadásul megnézte a NAV-nak lejelentett adatokat, ott bizony elektronikus számlaként van lejelentve. Végül eljutott az ő pénzügyesükhöz, elmondta mit szeretne, kiküldték postával, kinyomtatva, papíron. Most van egy iktatott, papír alapú példányunk, így a mi fenekünk fedezve van.

De aki szót fogad és kinyomtatja, aztán egy ellenőrzésnél azt veszi elő, az nagy sz.rban van, mert minden jel arra mutat, hogy kapott egy elektronikus számlát amit nem archivált megfelelően. Egyébként nem egy kis forgalmú, noname cég számlájáról van szó...

Igen... Ez a "ráutaló magatartás" jogrend rémálma. A vásárlással a befogadó megegyezett a kibocsájtóval. Lehet ez így "fura" de a befogadónak kötelessége a számlák megfelelő tárolása, ebbe az is beletartozik, hogy utánanéz hogy kell számlázni.

"Csak nyomtassa ki" az mondjuk elég ciki volt a kibocsájtó részéről, mert ez egyszerűen nem igaz és nem jó.

Mindkét oldalnak igaza van. A vevő papírt akar és nem lehet rákényszeríteni a digitálist Az eladó csak adigitálist ad, ha ez nem jó akkor nem tudunk üzletelni

DrotosTot commented 3 years ago

"ez nem jó akkor nem tudunk üzletelni" Pedig ez lenne a lényeg. Hogy tudjunk üzletelni, minél többet, azon jó sok pénzt keresni, amiből majd adózunk. Ezt kellene a jogszabályi környezetnek is támogatnia. Nem azt mondom, hogy eddig nem történt előrelépés és jó megoldások, de még messze vagyunk a végétől.

csandazoltan commented 3 years ago

"ez nem jó akkor nem tudunk üzletelni" Pedig ez lenne a lényeg. Hogy tudjunk üzletelni, minél többet, azon jó sok pénzt keresni, amiből majd adózunk. Ezt kellene a jogszabályi környezetnek is támogatnia. Nem azt mondom, hogy eddig nem történt előrelépés és jó megoldások, de még messze vagyunk a végétől.

Minden támogatás megvan, az hogy a vevő nem akar digitálisra átállni, semmilyen törvény vagy támogatás nem segít. (a kötelezésen kívül) De vannak támogatások, nem egy pályázat van számlázás digitalizálásra.

zsoftadmin commented 3 years ago

Egy kis összefoglaló egy lehetséges megvalósításról és néhány kiegészítő gondolat, - hátha segít valakinek...

  1. Először is fontos megérteni, hogy a NAV-os hitelesítés más, mint az amit külső szolgáltatók szoktak végezni. A külső hitelesítő általában egy számlaképet tartalmazó fájlt hitelesít, ezt látja el bélyegzővel. Ezt a fájt utólag nem lehet módosítani (ez a hitelesítés lényege). A NAV viszont egy XML állományt hitelesít, így a módosítási tilalom értelemszerűen erre vonatkozik. Itt nincs szó számlaképről, a NAV-hoz - se pdf-et, se grafikát stb. nem lehet beküldeni.
  2. A vevőnek el kell küldeni a hiteles számlapéldányt és a hitelesség ellenőrzéshez szükséges adatokat. Ez külsős hitelesítésnél az a számlakép, amit hitelesítettek, NAV-os hitelesítésnél a beküldött XML állomány. A külsőleg hitelesített számlakép elküldésével nincs gond (sok éve használjuk már), de mi legyen a NAV-os számlával? Elég, ha az XML fájlt elküldjük? - Van aki azt mondja, hogy elég, hiszen a vevő feladata az XML fájl értelmezése. Én úgy vélem, hogy illik küldeni egy számlaképet is, hiszem amíg nem állnak rendelkezésre általánosan elfogadott XML megjelenítők, a pénzügyesnek (könyvelőnek) addig is tudni kell kezelni az emailen küldött számlákat.
  3. Így tehát van egy NAV-os XML állományunk, egy hash lenyomatunk, és - mivel jófejek vagyunk - egy számlaképünk, amit el kell juttatnunk a vevőhöz. Ezeket külön-külön is hozzácsatolhatjuk egy email-hez, de megtehetjük, hogy csatolás előtt egy zip fájlba tömörítjük, hogy biztosan ne kallódjanak el az összetevők. De az általam ismert legelegánsabb megoldás az, hogy az XML és Hash fájlt egyszerűen beágyazzuk a számlaképbe. Így egyetlen pdf dokumentumot kell csak eljuttatni a vevőnek, és még a tömörítéssel sem kel bajlódni (a technikai megvalósítását a 7. posztban már leírtam.).

Gondolatok:

Az ügyfelek visszajelzései alapján úgy vélem, hogy az e-számla eltrejedésének legfőbb akadálya jelenleg a bizonytalanság. A tavaszi NAV konferencián szó volt arról, hogy e-számla témakörben is várható egy konferencia. Sokat segítene az ügyön, ha ez minél hamarabb megtörténne.

fenyvessy commented 3 years ago

@zsoftadmin : az összefoglalód kizárólag a completenessIndicator=true esetre vonatkozik, de szerintem abban sem pontos több helyen sem. Olyanokra gondolok, mint:

Az ügyfelek visszajelzései alapján úgy vélem, hogy az e-számla eltrejedésének legfőbb oka jelenleg a bizonytalanság.

Ehhez még annyit tennék hozzá, hogy akkor szoktak még elzárkózni az e-számla befogadásától, amikor tudatosul bennük, hogy ez a befogadói oldalra is sokkal nagyobb munkát és felelősséget ró. Nem elég átadni a számlát a könyvelőnek aki lefűzi a dossziéba és kész mint a papír számlánál, hanem neki kell gondoskodni az archiválási törvényben szereplő feltételekről. Nem tűnik nagy dolognak, az ITM rendeleben szereplő "védi az elektronikus dokumentumot a törlés, a megsemmisítés, a véletlen megsemmisülés, az utólagos módosítás és sérülés, valamint a jogosulatlan hozzáférés ellen" egészen addig, ameddig ki nem derül, hogy nincs megfelelő adatmentési rendszere, nincs jogosultsági korlátozásokkal rendelkező tárolási rendszere, stb, stb. Aztán amikor törli a szolgáltató az email fiókját amiben az e-számlák voltak, vagy jön a zsaroló vírus ami elkódol mindent, vagy csak hely felszabadítás miatt véletlenül kitöröl néhány számlát, akkor jön a probléma. A kevésbé felelőtlen felhasználó (akinek van valamilyen mentése) meg akkor kezd el fejvesztve rohangálni, amikor kiderül, hogy a pendrive mégsem örök életű, a mentés külső HDD-je nem bírja a leesést... Azaz vagy informatikát fejleszt (szerver, NAS, automatizált mentések, stb.), vagy szenved azzal, hogy állandóan több pendrive/hdd között másolgat, vagy előfizet valahol még valami olcsó felhős szolgáltatásra, ahol biztonságosabban tárolja az adatait (OneDrive, Google Drive, stb. ahol szintén nem vállalnak semmilyen garanciát az adatok megmaradására), vagy választ egy minősített elektronikus archiválási szolgáltatót (ami már nem 2 fillér). Hát nem egyszerűbb úgy dönteni, hogy kizárólag papír számlát fogad be, amit odaad a könyvelőnek lefűzésre, és automatizáláshoz meg ugyanúgy használja a letöltött XML-t? :)

csandazoltan commented 3 years ago

@zsoftadmin Még minding nem kerek a dolog, nem jó szemszögből szemléled a dolgot: Pontok:

  1. A külső hitelesítés az stimt. A NAV viszont azt tekinti hiteles elektronikus számlának amit beküldesz neki. Ha a completenessindicator az false, akkor olyan digitális dokumentum hash-ét küldöd be amit akarsz, amíg az megfelel az áfa törvénynek. A "számlakép"-ről el lehet feledkezni, mivel digitális fájl, nincs kinézete. Lehet egy generált PDF is vagy egy generált kép is, aminek a hash-e megy a navhoz. Onnantól audit során a nav azt a fájlt fogja kérni ami az SHA3-512 hash-e megegyezik a beküldött hash-el, mindegy mi az a fájl

  2. Amikor arról beszélünk, hogy XML akkor a completenessindicator true ágáról beszélünk. Olyankor nem küldesz semmit a vevőnek, mert vállalja, hogy a nav rendszerében fogja keresni számláját, azt le fogja tölteni és archiválni, NAV API-n keresztül. Ebben a hash is benne lesz. Nincs szükség PDF-re, nincs szükség "számlaképre" nem kell semmilyen megjelenítést biztosítani. A vevő akármilyen programja fogja a struktúrált adatot letölteni, tárolni és akárhogy megjeleníteni.

"Én úgy vélem, hogy illik küldeni egy számlaképet is, hiszem amíg nem állnak rendelkezésre általánosan elfogadott XML megjelenítők, a pénzügyesnek (könyvelőnek) addig is tudni kell kezelni az emailen küldött számlákat." - Nincs szükség erre, az XML-es adatközlés lényege pont az (ez az egész progi aminek a githubján vagyunk) hogy közös szabványon legyen az ataküldés és fogadás. Nem kell pénzügyes aki érkezteti a számlát, hanem a számla automatikusan bekerül abba a számlázó programba amibe be van építve a NAV API Ráadásul tudtommal lehet a könyvelőnek technikai felhasználót adni a NAV Online-hoz API-val le lehet kérdezni a neked kiállított ÖSSZES számlát, a vevő minden számlája ott lesz a nav-nál.

  1. Ha PDF az eszámla, akkor email-ben elküldöd és az email testébe belerakod a hash-t azt a vevő archiválja az email-t (eml file), vagy a zipelés is járható út PDF + TXT. Ez totál automatizálható. Ha completenessindicator TRUE, akkor nem kell küldened semmit, mint a 2-es pontban leírtam. A vevő fogja letölteni a számláit és kezelni azokat. Egy értesítést dobhatsz, hogy "Számlája elkészült SZL12345 amit a NOL rendszerbe küldtünk."

Gondolatok:

csandazoltan commented 3 years ago

@fenyvessy Minden pontoddal tökéletesen egyetértek, kivéve az elsővel

A "hülye" magyar nyelvvel van itt gond... a külső alírás PDF-ben az "Certificate" amit a NAV csinál az meg "Validate" a szavak közel vannak egymáshoz, magyarban lehet hitelesítés-nek nevezni mindkettőt

A certificate azt hitelesíti, hogy ki állította ki és mikor és milyen tartalommal, a validate pedig, hogy az a fájl az e aminek lennie kell bitre pontosan.