Egy ÁFA ellenőrzés margójára

Egyik nagyon kedves partnerünk pénzügyi vezetője azzal a kérdéssel fordult hozzám, hogy hol találja az elektronikusan kibocsátott számlákat, mert ÁFA ellenőrzése lesz a cégnek és kérte az APEH (most már inkább NAV), hogy vigye magával.

A válasz nagyon egyszerű volt, hisz az általuk használt, a SAP Business One-hoz megvásárolható e-Doc+ Elektronikus számlázási Add-On egy különálló mappában menti el a kibocsátott elektronikusan aláírt, időbélyeggel ellátott pdf-eket.

Néhány órával később azonban újból hívott és azt mondta, hogy neki nem csak a kibocsátott pdf-ekre, hanem a bennük található adatokra is szüksége van méghozzá az APEH által előírt formátumok valamelyikében. A kéréséhez útmutatásként az alábbi előírást csatolta: 

Az elektronikus számlázás során az adóhatóság által elfogadott fájlformátumok 

Az adózás rendjéről szóló 2003. évi XCII. törvény (Art.) 95. § (3) bekezdése alapján (figyelemmel az Eszr. 3. §-ára is) az adózó az iratokat és az adózással összefüggő, elektronikus adathordozón tárolt adatokat (ide értve az elektronikus úton kibocsátott számlát is) felhívásra az adóhatóság által közzétett formátumban rendelkezésre bocsátja. Az elektronikus úton kibocsátott számlákra vonatkozóan az állami adóhatóság által elfogadott fájlformátumok a következők:

• .txt formátum (text fájl)
• bármilyen más olyan ún. print fájl formátum, mely nem formázott szöveget, illetve karaktereket tartalmaz, továbbá nem találhatók a fájlban - a soremelésen és az oldalkezdet jelzésén kívül - utasítások, és a fájl tartalma (a fájlban szereplő szöveg, illetve karakterek) egyértelműen megfeleltethető a kinyomtatott adatoknak (a fájlban szereplő karakterek sorozata, tulajdonsága a papírra történő kinyomtatással sem változik),
• .csv fájlformátum,
• .dbf fájlformátum,
• .mdb fájlformátum,
• .xls (Excel) fájlformátum,
• .xml fájlformátum.

Az .xml fájlformátum definícióit a közlemény 3. számú melléklete tartalmazza.
Az előzőekben részletezett fájlformátumokban az elektronikus számlákat kérésre adathordozón (floppyn, CD vagy DVD lemezen, USB csatlakozású adattároló eszközön) kell az adózónak az adóhatóság rendelkezésére bocsátania. 

Fontos kiemelni, hogy az említett fájlformátumok ellenőrzési formátumok, vagyis az adózó bármilyen formátumban kibocsáthatja elektronikus úton a számlát (akár pl. .pdf formátumban is), azonban az adóhatósági ellenőrzéskor az előzőekben említett formátumban kell az adóhatóságnak átadnia azokat. 

Szükséges megjegyezni ugyanakkor, hogy kérésre a fájlok adatszerkezetét is rendelkezésre kell bocsátani, mivel a fájlformátumokon belül is lehetnek eltérések, melyek az ellenőrzés lefolytatását nehezítik.

Miután kapcsolatba léptem az e-Doc+ fejlesztőivel kiderült, hogy nincs még tapasztalatuk ÁFA ellenőrzéssel kapcsolatban, így nem tudtak segíteni. Azt ajánlották, hogy a pdf-eket megnyitva az Adobe Reader programmal mentsem ki a bennük található xml mellékletet, mert az olyan formátumban tartalmazza az adatokat, mint ahogy az APEH várja.

Ez már egy nagyon jó hír volt, hisz így legalább az adatok újbóli előállítását meg lehet spórolni és "csak" a fájlok mentését kell elvégezni.

Az ördög azonban a részletekben rejlik! Több mint 6 ezer számlánál ugyanis már ez az egyszerű megnyitom, kimentem, becsukom, megnyitom, kimentem, becsukom feladat elvégzése is több mint 3 munkanapot venne igénybe!

Első próbálkozás: Írjunk programot!

Fejlesztőként rögtön utána néztem, hogy milyen ingyenes eszközök állnak rendelkezésre. Pár perces googlizás után találtam is egy nagyszerű leírást a stackoverflow.com-on, így miután letöltöttem az iTextSharp könytárat azonnal neki is kezdtem egy kis program összeütésének.

Bár pár perc alatt elkészültem a c#-os átiratával a stackoverflow-n talált java forrásnak, a program sajnos nem akart működni. Egy fél órát küzdöttem, hogy mi a csudáért nem csinálja azt amit kellene (ez a sor nem adta vissza a szükséges értéket: PdfDictionary names = root.getAsDict(PdfName.NAMES);), majd feladtam a küzdelmet és másik megoldás keresésébe kezdtem.

Második nekifutás: Keressünk valami ingyenes programot!

Újabb keresgélés után rátaláltam a végső megoldást jelentő Pdftk nevű programra, amely parancssorból vezérelhetően képes arra, hogy különféle műveleteket hajtson végre pdf fájlokon. 

A programmal kapcsolatban a legnehezebb feladatot a letöltési link megtalálása jelentette, amelyet valamilyen perverzió okán a Version History oldalra helyeztek el.

A megoldás ismertetése

Azzal, hogy meglett az eszköz amivel a feladat elvégezhető, a legnagyobb probléma elhárult. Hátra volt még azonban az, hogy kidolgozzam az elemi lépéseket melyek elvezetnek a végcélhoz.

1 lépés: A program meghívása a több ezer pdf fájlal

Szükség van egy olyan parancs fájlra (batch) amely egyenként meghívja a pdftk programot a megfelelő paraméterezéssel. Mivel több ezer fájlról volt szó, így nem jöhetett számításba, hogy kézzel készítsem el a fájlt. Szükség volt egy olyan parancsra amelyik elvégzi a munka nagy részét.

Erre az alábbi tűnt a legjobb megoldásnak:

dir *.pdf /b /s > osszespdf.bat

A parancs futtatása után előállt az alábbi sorokat (persze nem csak ennyit, hanem az összeset) tartalmazó szöveges fájl:

g:\e-számla\tároló\SBOG - ARInvoice - 8205.pdf
g:\e-számla\tároló\SBOG - ARInvoice - 8206.pdf
g:\e-számla\tároló\SBOG - ARInvoice - 8207.pdf
g:\e-számla\tároló\SBOG - ARInvoice - 8209.pdf
g:\e-számla\tároló\SBOG - ARCorrectionInvoice - 100.pdf
g:\e-számla\tároló\SBOG - ARCorrectionInvoice - 101.pdf
g:\e-számla\tároló\SBOG - ARCorrectionInvoice - 102.pdf

 A fenti sorok egy megfelelő szövegszerkesztővel (notepad++) és némi ötleteléssel gyorsan átalakíthatók az alábbi formátumra:

pdftk\bin\pdftk.exe "SBOG - ARInvoice - 8205.pdf" unpack_files output apehxmls
pdftk\bin\pdftk.exe "SBOG - ARInvoice - 8206.pdf" unpack_files output apehxmls
pdftk\bin\pdftk.exe "SBOG - ARInvoice - 8207.pdf" unpack_files output apehxmls

Már majdnem kész is lennénk, ha az összes pdf-ben nem ugyan az lenne a mellékletként szereplő xml-eknek a neve... Ez egy kicsit megbonyolítja a helyzetet, mert bár kimentődik a melléklet, de a legutolsó fájl mindig felülírja az előzőt.

2. lépés: A feldolgozó batch

Ennek az elkerülésére nem közvetlenül a pdftk.exe-t kell meghívni az osszespdf.bat-ból, hanem egy újabb batch fájlt (mondjuk pdftk.bat), ami elvégzi egyrészt a melléklet kimentését, majd az aktuális xml átnevezését.

Ehhez az alábbihoz hasonló sorokra lesz szükség az osszespdf.bat-ban:

call pdftk.bat ARInvoice-8205  
call pdftk.bat ARInvoice-8206 

A szemfülesek észrevehetik, hogy a pdftk.bat-nak átadott paraméter nevéből ki lett szedve a szóköz. Sajnos erre a paraméter átadás miatt van szükség és persze ehhez nem csak a szöveget kellett módosítani, hanem a fizikai fájlok nevét is... Erre ajánlom a TotalCommander Csoportos átnevezés funkcióját.

Ha sikerült a fentieket elvégezni, akkor már csak az utolsó lépés van vissza, a feldolgozó parancsállomány:

pdftk\bin\pdftk.exe %1.pdf unpack_files output apehxmls
ren apehxmls\*.xml %1._xml

Bár a fenti sorok magukért beszélnek talán annyi magyarázatot fűzhetek hozzá, hogy az első parancs kimenti az aktuális pdf-ből a melléklet xml-t, majd a második parancs átnevezi a könyvtárban található xml fájlokat a pdf-el azonos nevű _xml kiterjesztésű fájllá.

Erre azért van szükség, hogy mindig csak egy - az utolsó - xml kiterjesztésű állomány legyen a könyvtárban.

Mivel az _xml kiterjesztés az nem a legjobb, az osszespdf.bat állomány utolsó parancsának érdemes beilleszteni az alábbit:

ren apehxmls\*._xml *.xml

Végszó

Talán első olvasatra elrettentő, hogy milyen nyakatekerten lehet előállítani a szükséges adatokat, de ilyenkor egyrészt érdemes arra gondolni, hogy csak egyszer kell(ett) kidolgozni a módszert és innentől kezdve, akár több tízezer számla esetén is 5-10 perc alatt produkálhatók a szükséges adatok.

Másrészt pedig 6-8000 ezer számla elektronikus kibocsájtása kb. félmillió forint megtakarítást jelent az SAP Business One-t e-Doc+ Add-On-nal használó cégnek.

Olvasd tovább!