NAV Online számla

https://onlineszamla.nav.gov.hu/

Regisztráció: 2017.07.11 (76-os ID)

https://kobak.nav.gov.hu/

XSD:

Online Számla XSD Verziószám: V8.011 Készült: 2017-05-26

https://onlineszamla.nav.gov.hu/KobakReg/faces/index.xhtml

2018.02.26 fórum jegyzet

NAV, Hungaria krt 112.

Online számla. Vonatkozó szabályozás:

ÁFA törvény

NGM tervezet

Műszaki doksi (XML spec)

Alapvető elvárás volt, hogy ne jelentsen fokozott terhet, adminsztrációt.

Lesz még egy fórum, aztán a diák publikusak lesznek.

Czöndör Szabolcs

Jogszabályi háttér:

ÁFA tv. 260/1/i

EVA tv.

NGM rendelet

Megmarad a régi XML export is, de lehet az új formátummal is teljesíteni az adatszolgáltatást.

Megmarad a program használat bejelentési kötelezettség és a kijelentési kötelezettség is.

Az új adatszolgáltatás gép-gép közötti interface, ami azonnali, xml alapú.

Hiba (rossz adat, nem dolgozható fel, stb.) eseten 3 napon belül javitani / pótolni kell, ha nem javithato, akkor kézi adatszolgáltatás

Üzemzavar (nincs net, stb.) megszünését követő 24 órán belül pótolni kell. 48 órát meghaladó probléma esetén bejelenteni (online, nav nyomtatvány), és kézzel kell beküldeni az adatokat.

Érintett számlák:

összes számlatípus (helyesbítő, stornó, stb.)

belföldi adóalany számára kiállított (azaz van adószáma)

az áthárított ÁFA több, mint 100e (de lefele el lehet térni, akár az összeset be lehet küldeni)

ha elfelejtik feltűntetni az adószámot, akkor nem teljesül az adatszolgaltatás, ami a felhasználó felelőssége

ha egy számla már adatszolgáltatott volt, akkor annak a módosító bizonylatairól is kell adatot szolgáltatni, még akkor is, ha a módosítás után már nem lenne kötelezett (pl. jóváírás és 100e alá csökken az áfa)

Az adózónak kell regisztrálnia (várhatóan júniusban), és az általa létrehozott technikai felhasználó továbbítja az adatokat.

Amikor már nem változhat a számla tartalma (azaz véglegesen elkészült) akkor kell adatot szolgáltatni. Ez a kibocsátással egyidejűleg, azzal párhuzamosan is történhet.

Technikai követelemények:

beépített funkció

vagy külső modul, ha az automatikusan és azonnal, beavatkozás nélkül működik

a válaszüzenet lekérdezésével ér véget az adatszolgáltatás

dokumentálni kell ezt a funkciót is ugyan úgy, mint a számlázó program többi részét.

A sikeres adatszolgáltatás pillérei:

Vevő

számlakibocsátásra kötelezett

kibocsátó

szoftver fejlesztő

Internetes hálózat

NAV

Lehetőségek, nem kötelező:

válaszüzenetek megjelenítése

warning

error

számla adatok lekérdezése keresztellenőrzéshez

program adatainak összevetése adatszolgáltatással

warning/error statussal rendelkező számlák lekérdezése

adószám ellenőrzés /queryTaxpayer

Mizsányi Attila

mizsanyi.attila@nav.gov.hu

Tartalom:

bevezetés

adatok az üzleti xsd-ben

kötelezőség

címadatok

módosítások kezelése

error/warning

javaslatok

1. Bevezetés

jelen: színes gyakorlat a

számlák elkészítésére

számlakészítés munkafolyamatára

számla tárolására

módosító okirat kiadásának szervezésére

jövő: egységes adatszolgáltatás

előzmény: a 2016-os adatszolgáltatási XML

2. Adatok az üzleti xsd-ben

Adatkörök:

ÁFA tv. szerinti kötelező adatok

egyéb tv (pl. jövedéki, termékdíj, stb.) nem kötelező adatok

egyéb gyakori adatok pl. fizetési határidő

jellemző adatok (pl. megjelenési forma, hash)

egyéb szabadon írható adatok (saját célokra)

Miért vannak a nem kötelező adatok?

a 2016-os XML adatexport is teljesíthetővé válik ezekkel

lehetőség a számla egységes szerkezeti leírására, amivel saját folyamatokban is használhatóvá válik

pl. logisztikai cégeknél tömeg, térfogat, stb.

elektronikusan továbbítható a vevőnek, feldolgozható

Adatok kötelezősége:

Az adat akkor kötelező, ha:

technikailag elengedhetetlen (pl. sorszám)

vagy ÁFA tv + minden szla szerint releváns + minden módosító okirat tekintetében is releváns

ha nem kötelező valami az xsd-ben, az nem jelenti azt, ahogy nem is kell beküldeni!

lehet, hogy első ránézésre kötelezőnek látszik valami, de valójában nem az (pl. a gyerek kötelező, de a szülő nem)

Milyen adatokat kell beküldeni:

xsd megköveteli vagy

ÁFA tv által megkövetelt és releváns

Címadatok:

egyszerű vagy részletes

egyszerű: ország, irszám, település, továbbiak

részletes: ország, irszám, település, közter. név, jelleg, házszám, épület, lépcsőház, emelet, ajtó, hrsz

Módosítások kezelése:

számla

számlával egy tekintet alá eső okirat /modosito/ervenytelenito/helyesbito/storno/stb.

kötelező adattartalom ÁFA tv szerint

egy számla van. mindem más annak az egy számlának a módosítása. Nincs olyan, hogy módosító módosítása, minden módosítás az eredeti számlát módosítja.

érvénytelenítés: ha nem történt meg a gazdasági esemény

módosítás: ha téves adat van

szabad a módosítást érvenytelenítésselés egy új számla kiadásával elvégezni. Ilyenkor ezek az eredeti számla módosításának tekintendőek beküldés tekintetében

slide-on a módosítés bemutatása, linenumber, reference, stb. Lényeg, hogy a módosító számla linenumber az a módosító számlán belüli 1-től kezdődő folytonos, a refenece pedig az eredeti számla linenumberei után következő sorszámok.

a beküldés sorrendje nem számít, modificationTimestamp alapján lesz rendezve

modifyWithoutMaster=true jelentése, pl ha az eredeti szla nem kötelezett, vagy július előtt kiállított számla módosul.

a különbséget kell szerepeltetni (lineoperaton modify) ha már korábban is szerepelt bevallásban

Technikai érvenytelenítés:

Error

számla xml nem valid

az eladó törzsszáma az api xml-ben szereplőtől eltér

már volt adatszolgáltatás ezzel a számlaszámmal

tételek sorszámozása kihagy vagy ismétel

az eredeti számla nem tartalmaz tételt

a módosítás olyam számlára hivatkozik, amire nem volt adatszolgáltatás

a technikai érvénytelenítés olyam számlára hivatkozik, amire nem volt adatszolgáltatás

Warning:

A vevő adószáma hiányzik, érvénytelen, nem létezik

A vevő azonos az eladóval

Irszám és település nem kapcsolódik

számszakilag hibás az összesítés

a warningoknak nincs jogkövetkezménye, csak információ

Az errort meg kell előzni, a warningot pedig kezelni kell:

kizárni az xsd hibát okozó adatok szerepeltetését

elkerülni az érvénytelen adószámokat

elkerülni az adathiányokat, összefüggés hibákat

ezekhez célszerű az adózói oldalon áttekinteni a folymatokat.

Rencenji Dénes

Alkamazott technika:

https

rest api

xml

xsd

sha512, crc32, base64

wadl

Kapcsolat kiépítés feltételei:

Intetnet

nem kell fix ip

rest apit hívó kliens

felhasználói név / jelszó

xml aláíró kulcs / cserekulcs

Jelentős kockázatok:

nem szűrt csatorna

bárki álltal elérhető interface

ddos

auth adatok

hamis adatok beküldésének lehetősége

jogtalan lekérdezések

A rendszer elérhetősége:

ügyfél felület

gépi interface (jelenleg api-test.onlineszamla.nav.gov.hu)

User auth:

ügyfélkapun regisztrálni a cégvezetőnek (magyarorszag.hu)

ügyfélfelületen regisztrálni elsődleges felhasználóként

létrehozni legalább egy technikai felhasználót

4 biztonsági komponens:

user

pass

xml aláírókukcs

cserekulcs

Interface funkciók:

/végpont

tokenkérés

adatszolgáltatás beküldése

adatszolgáltatási status lekérdezése

adatok visszakeresése

adózó ellenőrzése

Operációk:

token kérés kizárólag a /manageInvoice -hoz kell

Miért kell token:

egylépcsős auth nem elég

csak az ügyfél ismeri

korlátozott ideig érvényes

titkosított

cserekulcsal dekódolt állapotban kell visszaküldeni

Beküldési szabályok:

egy tech user bármennyi tokent létrehozhat

a tokent érvényességi időn belül (5 perc) lehet felhasználni

a tokent másik tech user is felhasználhatja

párhuzamos beküldés is lehet akár ugyanazzal a felhasználóval

token érvényessége 5 perc

egyszerre beküldhető számlák száma 100 db

Hitelesség biztosítása:

adatszolgáltató boríték xml beágyazva base64 kódolva

sha512 aláírás

a beküldendő adatokra (tartalom) crc32

a checksum része a crc-nek

Token igénylés lényegi elemei:

request id (egyedinek kell lenni adószámonként)

formázott timestamp (az xml timestamp mezője alapján)

xml aláírókulcs

kérés aláírás sha512 hash

login név

jelszó sha512 hash

sha512(requestid + timestmp + xml kulcs) =128 uppercase!

Adatszolgáltatás beküldési folyamata:

adatok összeállítása token kéréshez

rest api POST UTF8

xsd validáció

válasz feldogozása

hibakezelés

token dekódolás aes128

titkosított token érvényességének tárolása

Adat összeállítása beküldéshez:

kiens oldali ellenőrzés (adószám, xml)

kérés beküldése POST, UTF88

xsd és üzleti validáció

válasz feldolgozása

hiba kiértékelés vagy

tranzakció id visszakapása és letárolása

Beküldés után 3-5 perc múlva tranzakció id alapján kell lekérdezni a statust.

Szinkron vizsgálat a fogadó oldalon:

auth adatok

jogosultság

token érvényesség és létezés

kérés aláírás érvényesség

Aszinkron feldolgozás után lekérdezhető:

tranzakcio is alapjan

feldolgozási szintek

received

processing

done

aborted (hibás)

done esetén is lehet warning

Csak az az adatszolgáltatás tekinthető teljesítettnek, aminek a statusa done.

Az ügyfélnek kell a warningokat kezelni, javítani.

Kommunikáció esetén a standard http status kódokat értelmezni kell.

a sikertelen küldés után újra kell küldeni

ha a küldés sikeres volt de válasz elveszett, akkor /queryInvoiceData kérdezi le a tranzakció id-t

Ki küldhet be adatot:

az adatszolgáltatásra kötelezett

ön és bérszámlázó

bárki, aki rendelkezik a beküldéshez az adatokkal

Segítség a fejlesztéshez:

interface specifikáció

fejlesztési segédlet (jmeter projektfile letölthető)

hamarosan lesz egy offline desktop program a teszteléshez

offline wadl

online számla tool

interface tesztek támogatása: init.onlineszamla_teszt_support@nav.gov.hu

Kocsis Csaba

Roadmap

aszinkron feldolgozás teszt márciustól

szamlát még nem ment, de minden másra már jó lesz

Az alapszámla mentése lesz a következő

március végére teljes funkcionalitás

április végére kézi számlarögzítés

májusban a segédszolgáltatások, nyilatkozatok, technikai érvénytelenítés

Lesz lehetőség email értesítést kapni akkor, ha probléma van az adatfeldolgozással