Az e-számlázás és a számlaadatok lekérdezésének, feldolgozásának jó gyakorlata
A beszélgetés hátterét az SDSYS által elkészített felmérés jelentette, amelyben a felhasználók – piaci szereplők, könyvelők – értékelhették az online számla-adatszolgáltatás működését, jelezhették esetleges fejlesztési igényeket.
A beszélgetés résztvevői egyetértettek abban, hogy még mindig nem teljesen egyértelmű a felhasználók számára az elektronikus számla fogalma. Czöndör Szabolcs szerint fileformátumtól függetlenül elektronikus számláról beszélhetünk, ha a számladokumentumot elektronikus folyamatokon keresztül kezeli az eladó és a vevő: elektronikusan állítják elő, ilyen csatornán küldik el, elektronikus folyamatokon keresztül fogadják be, és dolgozzák fel. Ebből a szempontból nemcsak az mindegy, hogy milyen dokumentumról beszélünk (PDF, képfile, XML stb.), de továbbítás csatornája is. Ugyan az elmúlt év érezhető változást hozott az elektronikus számlázás gyakorlatának elterjedésében, de még mindig érzékelhető a lemaradása az elektronikus számlafeldolgozás terén. Ezt igazolja a SDSYS kutatása is, mely szerint csak a válaszadók 9%-a számláz és fogad be számlát elektronikusan, 62% csak befogadja, 18% csak küldi az elektronikus számlát. A NAV a felzárkózáshoz is szeretne hozzájárulni az XML-számla – e speciális elektronikus számla – elterjesztésével, mely sokkal hatékonyabbá teheti a bizonylatok feldolgozását is.
Szalai Anett szerint azonban a bejövő számlák elektronikus feldolgozásával kapcsolatos ügyviteli evolúció már lezajlott vagy legalábbis jól halad, de a kimenő számlák kiállításánál és küldésénél még nem teljesen elektronikus vagy automatizált a folyamat. A NAV XML-számlában jó lehetőséget lát egy egységes template, struktúra megteremtésére, amely segítheti a számlakiállítás automatizálását is. Ugyanakkor kiemelte, hogy vannak olyan pontok – például a termékdíj kérdése – amely nehezen formalizálható, és amely hosszútávon is szükségessé teszi az emberi beavatkozást a folyamatba.
Éppen ezért érthető, hogy sok felhasználó szeretné az XML adatkörének további bővítését, hogy könnyebben illeszthessék ezt saját ügyviteli rendszerükhöz, vagy azért, mert így minden számukra szükséges információt biztosan fel kellene tüntetni a számlán. Czöndör Szabolcs és Mizsányi Attila azonban hangsúlyozták, hogy a kötelező adatok körét jogszabályok határozzák meg, nem lehet bekérni olyan adatot, amelyet Áfatörvény nem nevesít. Az XML struktúra csak azokat tartalmazza kötelezően, amelyeket mindenkinek tevékenységtől, ágazattól, terméktől és szolgáltatástól függetlenül meg kell adni. Ugyan ágazati jogszabályok, jövedéki, népegészségügyi, termékdíj törvények, vagy éppen a rezsicsökkentésre vonatkozó előírások bizonyos vállalkozások számára további adatokat is előírhatnak, de ezt csak a körülmények függvényében kötelezőek. Így az online számlarendszer ezek meglétét nem vizsgálja. Ennek ellenére már eddig is számos olyan opcionális mezővel – pl. megrendelési szám, cikkszám – bővítették az XML adatok körét, amelyek kifejezetten a számla-feldolgozási folyamatokat segítik.
A számlázó programok és ügyviteli rendszerek fejlesztői azonban versenyelőnyt kovácsolhatnának abból, hogy a megrendelői igények szerint további elemekkel egészítik ki az adatstruktúrát. Így a szoftvereik használatával kiállított számlák nem csak fiskálisan lesznek helyesek, hanem az összes olyan információt tartalmazzák, ami a számla befogadásához, a kontírozáshoz, az elszámoláshoz szükségesek az adott felhasználó számára. Ebben segíti őket a NAV által készített ajánlás, amely bemutatja, hogy hogyan érdemes a számlázó programot kialakítani.
Mizsányi Attila elmondta, hogy a NAV XML számlaként való használata csak egy lehetőség a vállalkozások számára, nem kötelező használni. Emlékeztetőül összefoglalta, hogy ilyenkor a számlázóprogramban kiállított a számla adatait megkapja a hatóság, és e mellett egy jelzést is, hogy maga az adatszolgáltatás minősül számlának. A vevő nem e-mailben kapja meg a számlát, hanem letölti az adatokat. Egységes szerkezete miatt a számlafeldolgozás egyszerűsödik, és teljesen automatizálható. Czöndör Szabolcs azzal egészítette ki mindezt, hogy ennek használatához szükséges a felek megállapodása az XML-számlák befogadásáról. Azt, hogy az XML-t tekintik a felek számlának a completness indicator használata jelzi, az eredetiséget pedig a hash-kód alkalmazásával lehet igazolni, mely lehetővé teszi az archiválást.
A számlák archiválásához tehát meg kell őrizni az eredeti file-t, amelyen a hash-függvényt futtatták és a hash-kódot is. Ha az eredeti számla egy PDF volt, akkor ezt meg sem kapja az adóhivatal, vagyis nem is tudná együtt őrizni, archiválni a számlát. Ha a számla XML, akkor ezzel ugyan rendelkezik, de ez esetben sem vállalja az archiválást. A számlák és az eredetiséget igazoló kódok őrzése a kiállító és a befogadó feladata.
A NAV XML alapján történő elektronikus számlázás használatával kapcsolatban tehát összefoglalóan elmondhatjuk, hogy várható, hogy az ezt használók az egész ügyviteli rendszerüket digitalizálni fogják, hiszen ez egy reális alternatíva, kiindulási alap, és így nem kell saját e-számlát fejleszteni mindenkinek. Az online számlarendszer további fejlesztése azonban lehetséges, például elképzelhető, hogy később az érintettek követhetik, hogy a számlát letöltötte-e, levonásba helyezte-e a vevő. Ugyanakkor az adóügyi ellenőrző riport funkció megszüntetését nem tervezik.
A beszélgetés másik fő témája a rendszer működéssel kapcsolatosan előforduló anomáliák, leállások, lassulások voltak. Kocsis Csaba ezzel kapcsolatban elmondta, hogy örömmel állapították meg, hogy már az év elejétől sokan használták a NAV 3.0-ás rendszert, vagyis a cégek nem várták ki a moratórium leteltét. Továbbá nemcsak az adatszolgáltatás, hanem az adatok letöltése is népszerű. Ennek köszönhetően azonban előfordulhatnak lassulások, leállások is, mert egy rendszert nem lehet adatszolgáltatásra, vagyis feltöltésre és az adatok letöltésére, olvasására is optimalizálni. Mivel ezt a rendszert elsősorban az adatszolgáltatásra, a számlaadatok beküldésére fejlesztették, a problémák nem is ezzel, hanem a lekérdezésekkel kapcsolatban jelentkeznek.
Ugyanakkor az eredeti elképzelésekhez képest ez az egyensúly felborult: munkaidőben, reggel 8-tól délután 5-ig 5 másodpercenként 3000 adatszolgáltatásra 20.000 lekérdezés jut. Bár az alapfunkció ilyenkor is működik, de a válaszidő megnőhet. Ugyan nem korlátozzák a forgalmat, és nem kvótázzák a lekérdezéseket, de fontos lenne, hogy a felhasználók se használják túl a rendszert.
Hogyan érdemes a lekérdezéseket elvégezni, hogy ne terheljük túl a rendszert?
-Egy nagy számlaforgalmú cég ne csúcsidőben és ne egyszerre indítson lekérdezést.
-Ne kérdezzünk le egyszerre nagyon sok számlát.
-Ha a letöltési idő hosszabb a vártnál, ne azonnal indítsunk új lekérdezést, mert ezzel tovább növeljük a terhelést, vagyis tovább lassítjuk a rendszert.
Mindezt természetesen a fejlesztés során kell helyesen kialakítani, a felhasználóknak nem kell üzleti igényeiket korlátozni, vagy tekintettel lenniük a rendszerekre. Egy jól megtervezett szoftver figyelembe veszi mindezt, és a háttérben ütemezi a lekérdezéseket. Ugyanakkor teljes bizonyossággal nem kerülhetők el a rendszerleállások, ezért az adójogszabályok fel vannak készítve az üzemszünetekre is. Ez biztosítja, hogy az adózók nem szenvednek hátrányt, ha az adatszolgáltatás megtörténik, amikor elhárult a probléma.
