Az egész nagyjából 5 éve kezdődött, amikor a NAV elhatározta, hogy az összes számlázó programból struktúráltan adatokat kíván nyerni egy általuk meghatározott XML formában. (Gyanítom milyen gyakran használták ezt a funkciót, de legalább a fejlesztők nem unatkoztak.)
A történet azonban itt nem ért véget, tavaly az egészet újragondolták és elkezdték kilapátolni az ablakon a pénzt egy olyan rendszer bevezetésén dolgozva, amely lényegében ugyan azt tudja, mint az előző, de itt a feldolgozás már automatikusan történne, emberi közreműködés nélkül.
Az ötlet egészen jó! Lényegében csak egy jól megírt API-ra van szükség.
Azt nem tudni, mennyit dolgoztak rajta, de menet közben elég sokszor váltottak koncepciót, végül nagyjából 2017 végére elkészült egy egészen stabil API, sok dokumentációval és egy viszonyalg jól működő portállal.
Mivel a Total Studio–nál egyedi szoftvert használunk ügyvitelre, így nekünk is követni kell a szabályokat és meg kell valósítsuk a NAV Online számla bekötést. Velünk karöltve így tesz a legtöbb Online számlázó is, többek közt a Számlázz.hu vagy az OTP EBiz... mivel kötelező.
Akinek pedig a számlázó programja nem tudja a funkciót, a NAV saját ingyenes számlázót biztosít!
Persze csak akkor, ha el is árulják, hogy hol is van ez a számlázó és hogyan lehet hozzáférni. Nekem nem sikerült rájönnöm, pedig még a hirado.hu is foglalkozott a témával.
A rendszert tényleg komolyan gondolják, egy az élessel megegyező tesztrendszert is létrehoztak, amelyre az év elejétől lehetett regisztrálni és lehetett próbálgatni a számlázók kommunikációját.
A tesztrendszer pont ugyan úgy működik, mint az éles, de induláskor az éles rendszerbe is regisztrálni kell és új felhasználói azonosítókat kell igényelni az API-nk működéséhez.
Amikor mi a tesztrendszerbe próbáltunk regisztrálni, csak a sokadik nekifutásra sikerült, amelynek teljesen logikátlan okai voltak. Ezeket most meg is osztom mindenkivel, így remélem, jó pár ideges percet megspórolhatok olvasóinknak.
Az egész ott kezdődik, hogy csak és kizárólag érvényes ügyfélkapu regisztrációval lehet használni a rendszert. Ez jó esetben egy cégvezetőnek azért van.
A regisztrációkor be kell jelentkezni az ügyfélkapuba, majd meg kell adni cégünk adószámát, ezzel meg is kezdődhet a regisztráció. Kitöltjük cégünk adatait, ezek nagyobb részét már egyébként automatikusan hozza a rendszer.
Ez mind szép és jó, ám ezután jön a feketeleves, a rendszer ugyanis újra bekéri a személyes adatainkat. Nekünk a fő hajtépést a következő hibaüzenet okozta:
“A megadott adatokkal magánszemély nem található.”
Szerencsére voltak türelmesebb emberek is, akik a ssaját blogjukban, meg is írták, mi a teendő ebben az esetben.
Röviden és tömören, pont ugyan úgy kell megadni az adatokat, mint az Ügyfélkapuban. (A legnagyonobb kitolás szerintem a tartózkodási hely megadása, ugyanis ha Budapest, akkor kell a kerületet is mögé, méghozzá számmal. pl: BUDAPEST 12)
Erre semmi utalás nem volt a felületen, pedig egy info buborék felhelyezése nem hiszem, hogy nagyot dobott volna a fejlesztési időn/költségen.
Miután sikerült ezt megfejteni és a mentésre nyomni, a rendszer kijelentkeztetett...!
Azóta szerencsére már legalább egy figyelmeztetés felkerült az oldalra, amely értesít: max 5 perced van ezen művelet teljes elvégzésére.
Ha bejutottunk, onnabtól már egészen egyértelmű a rendszer, egy technikai usert kell felvegyünk, amelyhez járnak API kulcsok, ezekkel kezdhetjük meg a fejlesztést.
Nekünk nagyjából 20 órányi fejlesztési időt vett igénybe az összekötés, úgy hogy nem tud mindent az áttöltő, csak a főbb funkciókat.
Sajnos a dokumentáció sokszor nem elég részletes, így csak a netről lehet összevadászni, hogy most éppen mi a baja.
A fejlesztés elején gondoltam elkezdem feljegyezni, mik voltak a típushibák, de ez végül elmaradt, így most csak emlékezetből írom meg a komolyabb problémákat, amelyek álmatlan éjszakák sorát okozhatják.
A rendszer dátum kezelése iszonyat macerás, timezone/nem timezone, formátum stb… Ráadásul PHP alapból nem tudja azt a formátumot, amit a NAV elvár, így kis sufni tunningra volt szükség.
A szoftver azonosítója teljesen aluldokumentált, de egy megkötött formátumot vár el, amely egyedi kell legyen. Ennyi a Pattern, amit megadtak ([0-9A-Z\-]{18}). De ennél nagyobba megkötés, például az első 2 karakter az ország kód kell legyen, utána kövesse az adószámunk első 8 karaktere, majd a maradék részt töltsük fel bármi karakter sorozattal, pontosan 18 karakterig.
A számlagenerálásnál belefuthatunk abba, hogy a mezők sorrendje nem mindegy, hogy miként van kigenerálva. PL attól függően, hogy milyen a számla típusa, kell megadni a dátumot, de ehhez először a számla típusát kell megadni. Használjuk a minta fájlokban található sorrendet. (Bár teljesen logikátlan, hiszen az XML pont arra van, hogy mindegy milyen sorrendben küldöd az adatokat, a távoli oldal értelmezni tudja.)
Az egész témát úgy tudnám jellemezni, hogy a rendszer nem lett rossz, viszonylag jól működik, de pár gyakran ismételt kérdéseket azért felvehetnének még. Ennek ellenére nem lehetetlen a számlázónk bekötése.
Fontos megjegyezni még, hogy csak a 100 ezer forint ÁFA feletti tartalommal ellátott számlákat kell jelenleg beküldeni. Ha gonosz lennék, azt mondanám, kicsit tartanak a rendszer túlterhelésétől és csak ezért hozták meg ezt a döntést :), de nem tartom kizártnak, hogy hamarosan bejelentik, minden számlát be kell küldeni.
A Beküldést elvileg azonnal a számla kibocsátását követően meg kell tenni, de vannak, akik a 24 órán belüli jelentést is rebesgetik.
Végül már csak azt nem értem, miért nem tudtak rendes osztályokat kiadni a számlázó API-hoz, ha már annyi időt beleöltek, mert ezzel legalább tényleg megkönnyítették volna a fejlesztők dolgát.
Én jófejségből megosztom a saját kódunkat, lett amilyen lett, de legalább működik :), és elképzelhető, hogy segítségül szolgálhat sorstársaimnak.
https://github.com/lamasgergo/navInvoice
Update:
Egy jobban dokumentált megoldás :)
https://github.com/pzs/nav-online-invoice
