NAV e-pénztárgép XSD 1.1: mi változott?

A NAV 2026. május 28-án frissítette az eNyugta rendszerhez közzétett 1.1-es XSD-sémát, és ezzel együtt feltöltötte a fejlesztői dokumentáció 1.5-ös változatát. A módosítás nem egy teljesen új kommunikációs rendszer bevezetését jelenti, hanem az XML-üzeneteket meghatározó séma egy kisebb, de a fejlesztők számára kötelezően követendő pontosítását.

A NAV közleménye szerint az 1.1-es XSD frissítése az eReceiptBase.xsd egyik pattern meghatározását érinti. Nem teljes interfészcseréről vagy új XSD-főverzióról van szó.

Mi az XSD, és miért fontos az e-pénztárgépnél?

Az XSD az XML Schema Definition rövidítése. Olyan szabályrendszer, amely meghatározza, hogy egy XML-üzenet:

• milyen adatmezőket tartalmazhat;
• mely mezők kötelezők vagy opcionálisak;
• milyen sorrendben szerepelhetnek az elemek;
• milyen adattípus és formátum fogadható el;
• milyen hosszúsági vagy karakterkészlet-korlátok érvényesek;
• milyen értékek felelnek meg egy meghatározott mintának.

Az e-pénztárgép által elkészített XML-üzenetnek meg kell felelnie a NAV által közzétett sémának. Ha egy kötelező mező hiányzik, az adattípus hibás, vagy egy érték nem felel meg az előírt mintának, az üzenet sémaellenőrzése sikertelen lehet.

Pontosan mi változott 2026. május 28-án?

A hivatalos fejlesztői közlemény három változást nevez meg:

1. Az 1.1-es XSD-csomagban frissült az eReceiptBase.xsd.
2. A módosítás egy pattern, vagyis egy formátumellenőrző minta meghatározását érinti.
3. A repository átszervezése során eltávolították az XSD_export mappát.

Ezzel egy időben elérhetővé vált a fejlesztői dokumentáció 1.5-ös változata is.

Fontos, hogy az XSD és a fejlesztői dokumentáció verziószáma nem azonos:

• XSD-verzió: 1.1;
• fejlesztői dokumentáció: 1.5.

Az „XSD 1.1” ebben az esetben a NAV által közzétett eNyugta-sémacsomag verzióját jelenti. Nem szabad összekeverni a fejlesztői dokumentáció 1.5-ös verziószámával.

Mi az a pattern az XSD-ben?

Az XSD-ben a pattern egy reguláris kifejezéshez hasonló szabály, amely egy szöveges érték megengedett formátumát írja le.

Pattern használható például annak ellenőrzésére, hogy egy mező:

• csak számokat vagy meghatározott karaktereket tartalmazzon;
• előírt hosszúságú legyen;
• meghatározott előtaggal kezdődjön;
• egy szabályos azonosítóformátumot kövessen;
• ne tartalmazzon tiltott karakterkombinációt.

Egy látszólag kis pattern-módosítás azért lehet fontos, mert a korábbi szabály alapján elfogadott érték az új sémával már hibás lehet, vagy fordítva: egy korábban indokolatlanul elutasított érték szabályossá válhat.

Mit nem jelent az XSD 1.1 frissítése?

A frissítésből önmagában nem következik, hogy az e-pénztárgépek gyorsabban kommunikálnak majd a NAV-val.

Az XSD az üzenetek szerkezetét és érvényességét szabályozza. A tényleges kommunikáció sebességét más tényezők határozzák meg, például:

• a hálózati kapcsolat minősége;
• a NAV végpont válaszideje;
• a készülék hardverének teljesítménye;
• az alkalmazás XML-feldolgozási sebessége;
• a várakozási és újraküldési logika;
• a háttérben feldolgozandó üzenetek mennyisége.

Az sem állítható, hogy egy sémamódosítás automatikusan megszünteti az adatátviteli hibákat. Legfeljebb egy konkrét validációs probléma javítható vele.

Az XSD-frissítés nem hálózati gyorsítás. Elsősorban azt pontosítja, hogy milyen XML-adatot tekint szabályosnak a rendszer.

Mit jelent a frissítés az e-pénztárgép-fejlesztőknek?

A módosítás elsősorban a gyártók és szoftverfejlesztők számára jelent feladatot. A fejlesztői csapatnak nem elegendő egyszerűen lecserélnie az XSD-fájlt.

Javasolt ellenőrzési folyamat:

1. A pontos release rögzítése: a forráskódban és a buildrendszerben egyértelműen meg kell határozni, melyik NAV-release-t használja az alkalmazás.
2. A sémák összehasonlítása: ellenőrizni kell, pontosan mely pattern és mely adattípus módosult.
3. Generált osztályok frissítése: ha a projekt XSD-ből generált Java-, C#-, C++- vagy más adatmodelleket használ, szükség lehet ezek újragenerálására.
4. Példaüzenetek validálása: a korábban használt XML-mintákat az új sémával is ellenőrizni kell.
5. Határértékek tesztelése: külön vizsgálni kell a pattern által elfogadott és elutasított szélsőértékeket.
6. Regressziós teszt: ellenőrizni kell, hogy a módosítás nem érintette-e az üzenetkészítés, aláírás, titkosítás vagy továbbítás más részeit.
7. Hibaválaszok kezelése: az alkalmazásnak érthetően kell naplóznia, ha egy XML nem felel meg az új sémának.

Automatikusan új NAV-engedélyezés szükséges?

Az eredeti szöveg kategorikusan azt állította, hogy minden gyártónak új NAV-engedélyezési eljárást kell lefolytatnia. Ez így nem jelenthető ki kizárólag az XSD-frissítés alapján.

A szükséges hatósági eljárás attól függhet, hogy:

• a módosítás érinti-e az engedélyezett pénztárgépszoftvert;
• változik-e az adóügyi működés;
• az adott változtatás milyen módosítási kategóriába tartozik;
• mit ír elő a forgalmazási engedély és a vonatkozó eljárásrend;
• szükséges-e új verzió bejelentése, vizsgálata vagy engedélyezése.

Ezt minden gyártónak a saját engedélyezett konfigurációja és a NAV előírásai alapján kell meghatároznia.

Kell-e bármit tennie a kereskedőnek?

Egy üzlet vagy vendéglátóhely számára az XSD-fájl közvetlen kezelése nem feladat. A szükséges módosítást az e-pénztárgép-szoftver gyártójának vagy forgalmazójának kell elvégeznie.

Az üzembentartónak elsősorban arra kell figyelnie, hogy:

• a készülék engedélyezett szoftververziót használjon;
• a gyártó által kiadott kötelező frissítés települjön;
• a sikertelen adatküldések ne maradjanak észrevétlenül;
• a készülék rendszeresen kapcsolódjon a központi rendszerhez;
• hiba esetén a hivatalos forgalmazó vagy szerviz adjon segítséget.

A frissítés tehát a kereskedő számára várhatóan háttérben történő technikai változás lesz, nem új kezelési folyamat.

Miért fontos a verzió pontos rögzítése?

Az olyan megjelölés, mint az „XSD 1.1 kompatibilis”, önmagában nem mindig elég pontos. Ugyanazon főverzióból több javított release is megjelenhet.

A fejlesztési és üzemeltetési dokumentációban célszerű rögzíteni:

• a release teljes nevét;
• a letöltés vagy átvétel dátumát;
• a repository commitazonosítóját;
• az XSD-fájlok ellenőrző összegét;
• a hozzá tartozó fejlesztői dokumentáció verzióját;
• az alkalmazás azon verzióját, amelybe a séma bekerült.

Így egy későbbi hibánál pontosan visszakövethető, hogy melyik séma alapján jött létre az XML-üzenet.

Miért változhat még a fejlesztői specifikáció?

Az eNyugta rendszer több szolgáltatásból, XML-üzenetből, visszaigazolásból és biztonsági folyamatból áll. Egy új rendszer fejlesztése során előfordulhat, hogy a gyakorlati tesztek olyan formátum- vagy értelmezési problémát tárnak fel, amelyet a sémában vagy a dokumentációban pontosítani kell.

Ez önmagában nem rendellenes. A fontos az, hogy:

• a módosítások nyilvánosan követhetők legyenek;
• készüljön egyértelmű változásjegyzék;
• a régi és az új verziók ne keveredjenek;
• a fejlesztők elegendő időt kapjanak a tesztelésre;
• a bevezetés ne okozzon váratlan kompatibilitási hibákat.

Összegzés

A NAV 2026. május 28-i kiadása az eNyugta rendszer 1.1-es XSD-sémájának kisebb frissítését tartalmazza. A hivatalos tájékoztatás szerint az eReceiptBase.xsd egyik pattern meghatározása változott.

Ezzel együtt megjelent a fejlesztői dokumentáció 1.5-ös verziója, és átszervezték a publikus repository mappaszerkezetét.

A módosítás a gyártók és fejlesztők számára sémafrissítést, összehasonlítást, újravalidálást és regressziós tesztelést jelent. A kereskedők oldalán várhatóan nincs közvetlen teendő, amennyiben az engedélyezett e-pénztárgép frissítése megfelelően megtörténik.

Nem indokolt azonban a változást teljesen új korszaknak, gyorsabb kommunikációnak vagy automatikusan biztonságosabb működésnek beállítani. Ez egy célzott technikai pontosítás, amelynek valódi hatását a módosított szabály és a fejlesztői implementáció határozza meg.

Hivatalos források: NAV eRECEIPT – XSD 1.1 frissítés és v1.5 fejlesztői dokumentáció , NAV fejlesztői közlemény az 1.1-es XSD frissítéséről , NAV eNyugta rendszer publikus fejlesztői repository