ERPNext magyar számlázás Monolithon megközelítése

A laikusok sokszor mondják, hogy a számlázás milyen egyszerű, hiszen sok adatunk rendelkezésre áll és egy csomó országban használják az ERPNext-et és egyéb nemzetközi megoldásokat számlázásra. Ilyenkor a legegyszerűbb ha megmutatjuk a magyar Áfa törvényt, amely a számlázással kapcsolatos legtöbb kérdést szabályozza. Igen, nem csak a 27%-os áfa világbajnok, és ugyan nem hasonlítottuk össze, de szinte biztos, hogy az Áfa törvényünk is a leghosszabb, ami itt nem kifezetten előnyös. A számlának vannak kötelező tartalmi elemei, mint például dátumok. De az, hogy milyen dátumot lehet/kell szerepeltetni egy-egy dátum típusú mezőben a számlázás esetén az a kilóméter hosszú Áfa törvényből derül ki. Nagyrészt ugyanez elmondható a számla többi tartalmi eleméről is. És akkor a kivételek, mentesítések speciális feltételeinek útvesztőit még nem is említettük

Megállapíthatjuk, hogy a magyar számlázás a fentiek tükrében komplexebb annál, hogy gyorsan implementálható legyen egy nemzetközi rendszerbe. És itt a másik sarkalatos pont, hogy egy nemzetközi rendszerről beszélünk az ERPNext magyar számlázás kapcsán. A rendszer az általános dolgokra nyújt megoldásokat, de a legtöbb - országspecifikus - dologra nem. Ezt ki kell egészítenünk azzal, hogy olyan megoldást szeretnénk - mivel az ERPNext több szervezet/vállalkozás kezelésére képes, úgynevezett multicompany setuppal - ami több, más-más országban működő cég együttes működését is lehetővé teszi

Mondhatnánk, hogy azért nincs kész a magyar számlázás, mert túl komplex, nem prioritás, stb. Ami mind igaz, azonban a valóság az, hogy korábban már készítettünk egy számlabeküldő megoldást az ERPNext 13-as verziójához a szamlazz.hu rendszer felé a make (akkor integromat) megoldásával, valamint Odoo számlázással kapcsolatban is van tapasztalatunk, de mindezek alapján szerettünk volna egy komplexebb megoldást nyújtani ügyfeleinknek, amihez még több tervezésre és döntésre van szükség

Fontos szempont számunkra, hogy az ERPNext könyvelési rendszer alapvetően és ezt a funkcióját - szintén továbbfejlesztve/kiegészítve a magyar szabályoknak való megfeleléssel a későbiekkben - szeretnénk megtartani, így már nem csak számlázásról beszélünk. A számlázás integrálására is a fent említett szinkronizációs megoldás mellett natív NAV API alapú megoldás és közvetítő, például szamlazz.hu és billingo.hu alkalmazása esetén is rengeteg lehetőségünk van. Létrehozatunk egy saját számlázási modult, saját doctype-pal és workflow-val. Vagy kiegészíthetjük a meglévő invoicing/számlázási rendszert a magyar számlázáshoz szükséges funkciókkal, ami nem csak új mezőket és adatcserét, hamem alap funkciók felülírását is jelenti. Mindezt cégenkénti adminisztrációval és hosszútávon fentarthatóan, frissíthetőn. Korábban nem, vagy limitált más országoknak megfelelő ERPNext implementáció volt elérhető, így maga az alap ERPNext szoftver sem volt minden esetben megfelelő a magyar számlázás implementálásához, azaz túl sok nem létező funkciót kellett volna pótolni vagy meglévő logikát teljesen átírni tesztreszabhatóan, tehát nem csak lokalizálásról lett volna szó. Ennek egy része fennmaradt, például az előlegek, sztornók és módosító számlák esetében, de az új ERPNext verziók más számlázáshoz kapcsolódó dolgokban és főleg más országok megoldásai és az ahhoz szükséges fundamentumok módosításával nem csak csökkentették/egyszerűsítették a feladatunkat, hanem egyben utat is mutatnak bizonyos kérdésekben, de erről lentebb

Sok, például a fentiekben ismertetett szempont mellett először egy NAV API alalpú közvetlen számlabeküldést terveztünk, ami mellett egy Chrome headless Online Számla beküldés is felmerült, de végül egy integárció mellett döntöttünk

Milyen előnyökkel jár ez a megközelítés? Így nem az ERPNext lesz a számlázó program. És ugyan manapság már nem kell bejelenti a számlázóprogramot a NAV felé, bár kötelező adatexport funkcióra még mindig szükség van, egyszerűsödik a saját és ügyfeleink élete is, ha megoldásunk nem számlázó a szó hivatalos értelmében, hanem megmaradunk ügyviteli rendszernek, amely számlázó kapcsolattal rendelkezik. Annak ellenére, hogy a NAV onlineszamla API használatát nem kerülhetjük el ha ingyen szeretnénk magyar név és címadatokhoz jutni adószám alapján, továbbá a szállítói számákat betölteni a rendszerbe, ennek ellenére ezt nem az első lépésben kívánjuk megvalósítani, ahogy például a VIES-ből történő adózó és adózói státus letöltését sem. (Bár már mindkettőre elkészült a PoC). Mindebből azonban következik, hogy a megoldásunkat egyrészt ezzel kompatibilisan célszerű felépíteni - ami lehetővé teszi később akár a közvetlen NAV onlineszamla beküldést, vagy a választott számlázó API lecserélését másik partnerre - és ez még komplexebbé teszi a feladatot. Persze némi támponttal is szolgálnak az API-k, amikor az említett nagyon hosszú áfa törvény nem foglamaz elég pontosan. (Ilyenkor az API által befogadott adatokat kezelhetjük javaslatként, amit persze mérlegelnünk kell)

Ugyan már utaltunk rá, de ezen a ponton kell megemlítetnünk, hogy ismernünk kell az alap ERPNext működést. Ezt azért kell kihangsúlyoznunk, mert az alap ERPNext is nagyon komplex, rengeteg számálzást is érintő kisebb-nagyobb funkcióval, amely részben, egészben valahogyan használható, használandó, legalábbis figyelembe veendő a magyar számlázás megvalósításakor. Például szeretnénk, ha minden funkció zavartalanul együttműködne a magyar lokalizáicóval együtt. Elsőre triválisnak tűnik, de például az automatikus számlakállítás és az előfizetések kezelése és azok kompatiblitása a folyamatos teljesítésű magyar számlákkal a valóságban egyáltalán nem az. Ezt a komplexitást teszi még nehezebbé, hogy néhány ország ERPNext számlázási lokalizáció már megjelent, amik szintén az alap ERPNext-re építkeznek szerencsére, és nem teljesen nulláról csak a Frappe Framework-re oldják meg az implementációt, és mivel ezekkel is szeretnénk kompatibilisek maradni multi company beállítás mellett, ez nem könnyű feladat, még ha ezekben az implementációkban és az ezekhez szükséges core (alap) rendszerben történ módosítások sokat segítenek a magyar számlázás kialakításában is

Ilyen például a világszerte terjedő e-számlázás (2028-tól kötelező minden EU tagországban), amire van olasz példa implementáció, de GULF országok mellett indiai megoldás és az angol Make Tax Digital is elkészült már, így a magyar, a külföldi API és létező implementációkat is próbáljuk figyelembe venni, ami nem könnyű feladat

Szeretnénk még egy szempontot behozni: az iparági jógyakorlatokat, hiszen vannak más szoftverekhez is magyar megoldások, sok szakemberrel dolgoztunk együtt, akik hasonló projektekben döntéshozóként vittek végig implementálásokat, amelyek alapján gondolhatnánk, hogy könnyebben lehet az ERPNext magyar számlázást kialakítani. Ez egyrészt igaz, hiszen mi valószínűleg új hibákat fogunk elkövetni, mint akik korábban hasonló projekteket csináltak, de fontos kiemelni egy alapvető kérdést, amit a magyar számlázás kapcsán egyik szoftvernél sem tapasztaltunk. Ezt fent félig már érintettük: a számlázás implementálása nem könyvelési szempontból történt, csak a számlázási kérdéseket vették a legtöbb esetben figyelembe

Két konkrét példát is ismerünk ahol például nagy figyelmet szenteltek annak, hogy hány és milyen dátumok használatára van szükség (például számla kelte, teljesítési dátum stb). Mégis az alaprendszer meglévő dátum funkcióit oly módon hasznosították újra, hogy nem képesek minden gazdasági eseményt megfelelően rögzíteni és különböző trükkökre van szükség. Mi is hajlottunk erre a megközelítésre, hogy például az áfa teljesítés dátuma legyen az alap ERPNext invoice date, de meglátásunk szerint ez zsákutca, (ahogy kiállítás dátumának sem megfelelő) mert nem ad annyi előnyt - értsd nem spórulunk meg vele más fejlesztést - mint amennyi fejfájást okoz. A példánál maradva, mi inkább felvállaljuk, hogy akár egy plusz dátummal több dátum mezőt használunk - bár ezek automatikus feltöltése esetén azok száma meglátásunk szerint mindegy - de minden gazdasági esemény rögzíthetővé válik a rendszerben

A lényeg, hogy nem csak a számla kötelező adatainak rögzítését tesszük lehetővé, hanem annak könyveléséhez szükséges adatokat is. Ez ott lesz érdekes például, amikor nem csak a saját rendszerünkből kiállított számlákat szeretnénk könyvelni. Konkrétabban: Ha az alap dátum mezőt használjuk könyvelési vagy áfa dátumra, akkor sok alap ERPNext funkció alapból továbbra is elérhető maradna. Akkor mi ezzel a gond? Az, hogy például azok az alap ERPNext riportok, mint példul áfa riport a magyar szabályoknak még nem fog megfelelni, azt tovább kellene finomítani. És itt jött a felismerés, hogy ha mindenképpen saját riportokat kell készítenünk a magyar számlázás kialakítása miatt/után, akkor azt egyszerűbb a nulláról felépíteni úgy - ahogy az előbb jeleztem - hogy minden szükségs adat rendelkezésre áll. Azaz például több dátumot kezelünk

Mire használjuk akkor tehát a meglévő dátumokat? Mindent arra, amire alapvetően való. Ezzel csökkentjük a bevezetendő dátum mezők számát például. És itt volt a legtöbb félreértés, hogy melyik mező valójában mire való. Az alap számla dátum mező az a dátum amikor a saját könyvelésünben szerepeltetni szeretnénk a számlát. Ez sokszor persze nem választás kérdése, de például lezárt adóév számláját később kapjuk meg, akkor azt az aktuális/folyó évre könyvelhetjük csak, annak ellenére, hogy a számla eredeti adattartalma mellett áfabevallási dátumra is szükség van és az elhatárolások kérdését hagyjuk. Továbbá nem említettük, a folyamatos teljesítésű számlákat, kezdő és végdátummal, ami periódusnak is felfogható, de számviteli teljesítési dátumként is funkcionálhat

Az alaposan kivesézett komplexitásból adódóan próbáljuk a tárgyalt témákat figyelembe venni, azonban pont ezek miatt egy kisebb, megfoghatóbb egységek “leszállításán” dolgozunk, azaz a számlázás kapcsán a vevőszámlák mielőbbi kiállíthatósága a cél és csak utána bővítjük a scope-t, pedig - mivel például az indiai megoldás is használja a VTSZ számokat - jó lenne minél több dolgot belevenni, de azzal csak még tovább tolnánk a megjelenést amit nem szeretnénk.

Azt, hogy olyan vevőszámla megoldást szeretnénk, ami megfeleltethető és könnyen alkalmazható szállítói számlák rögzítésére is, azaz a workflow, a mezők, a működés mindkét oldalon azonos tud lenni, megkönnyítve ezzel a felhasználók mindennapjait, ami szintén nem triviális. És ott van még az Áfa. Igen, ami 2024-től eÁfa, ami az eddig ismert kb 30 adókodót 236-ra bővíti és akkor még nem beszéltünk az egyéb valahogyan számlázáshoz kapcsolódó adókról, bevallásokról, mint csomagolási termékdíj vagy szállás, vendéglátás esetén az NTAK. Ezért is koncentrálunk a legkisebb egységre, ami a vevőszámla kiállítás. De megemlíthetjük a pénzforgalmi (pl: EV) és áfa esetét is, amiket jelenleg nem tervezünk megvalósítani, mert látunk rájuk kerülőutat például az említett saját riportok megvalósításával, de igyekszünk ezeket is figyelembe venni. Továbbá az is érdekes kérdés, hogyan célszerű kezelni a kézi és automatikus beküldéseket, a hibákat, az újraküldéseket, a visszavonásokat, javításokat.

Érdekes kérdés volt még az app szervezése is. Itt korábban több kisebb appban gondolkodtunk, hogy egy-egy részei külön-kölön is használhatóak legyenek. De mivel ez szinte mindegyik magyar specifikus, itt viszont egy-egy elem nélkül nem igen használható, ezért inkább egy komplex megoldásban gondolkodunk. Például MNB árfolyamokra is szükség van a legtöbb esetben, ami PoC szintjén szintén elkészült már

Azon túl, hogy örömmel fogadjuk a visszajelzéseket, kérdéseket, ötleteket és javaslatokat és ezzel szeretnénk párbeszédet kezdeményezeni, ezeket mintegy vezérelv követjük, ha döntéseket kell hoznunk, és amúgy is segít a gondolatok összegzésében amiből célokat és feladatokat hozhatunk létre azok megvalósítása érdekében

A publikálás részleteit még nem tudjuk. Többször felmerült az ingyenes open source kiadás, ami még mindig lehetőség, annak ellenére, hogy az egyik általunk készített megoldást - bankszámla szinkronizáicó GoCardless integrációval - havidíjas SaaS, azaz felhőszolgáltatásként tettük elérhetővé, mert egy másik ERPNext partner is készített egy hasonló fizetős megoldást és nem szerettünk volna neki keresztbe tenni azzal, hogy ingyenes konkurens megoldást teszünk közzé. Arra a megoldásunkra tehát nem bevételre, hanem inkább egy megvalósíthatósági tanulmányként tekintünk, ami a magyar számlázás esetén még kérdéses

Jelen bejegyzés másolatát publikáltuk a fórumon is, hogy egyszerűbb legyen megvitatni

https://discuss.frappe.io/t/hungarian-invoice-magyar-szamlazas/64970/15