May this interesting topic:
Szerintem itt beszélhetünk magyarul (legalábbis a német részen németül beszélnek).
Igen, a magyar szabályoknak megfelelő számla kiállításának támogatása az egyik első lépés. Ennek egy része az online adatszolgáltatás, de van több más eleme is. Itt a NAV összefoglalója:
Egy talán egyszerűbb (átmeneti) alternatíva lehetne az ERPNext összekötése pl. szamlazz.hu vagy billingo online számlázókkal, így a tényleges számla azokban a rendszerekben készülne el, és attachmentként tárolnánk el az ERPNext sales invoice dokumentumában. Ennek meglenne az az előnye, hogy nem az ERPNext felhasználójának kell a számlázórendszer megfelelőségét garantálnia a NAV felé, hanem ezt megteszi a szamlazz.hu illetve a billingo.
Szia,
ez az irány engem is érdekelne. Van ebben fejlemény? Ha jól látom a Billingó jobban van dokumentálva.
Sziasztok,
Van woocommerce integracio es ugy mehetne a billingo, de ha valaki profi akkor mehet egyenesben is.
Szia,
én is arra jutottam, de számomra most derült ki, hogy woo és erpnext között csak woo küldi a rendeléseket/ügyfeleket és a termékeket, Viszont nem tart szinkron a két végpont között készlet szinten. Nincs igazán kész az integráció.
Szia,
Igen itt is errol van szo:
Szia,
köszi. várom, hogy letisztuljon a történet, aztán jól kipróbálom. Ha lesz róla hír referálok.
1 Like
Elsőként én a szamlazz.hu API-t gondoltam megcsinálni, de közben kijött az Onlineszámla 3.0 API is, és ott már az is megoldható, hogy a NAV-hoz be lehet küldeni a teljes számla PDF-et is, és ők vállalják az archíválást + a vevő is letöltheti tőlük, ha jól értem. Lehet, hogy ebbe az irányba lenne érdemes elindulni.
A NAV elég jó irányba fejlődik, már Githubjuk is van: Nemzeti Adó - és Vámhivatal · GitHub
EDIT: Írták a HUP-on, hogy félre voltam tájékoztatva, és nincs semmiféle megőrzés sem a NAV által. Ez van…
https://docs.erpnext.com/docs/user/manual/en/erpnext_integration/woocommerce_integration
Próbáljátok ki a V13 ban megjelent
Itt a Youtube link rá:
Dear kisg,
we are running ERPNext within an HU setup and may need some help to integrate this with NAV.
Stefan
Sziasztok,
dolgozunk a magyar számlázáson, de annak sok előfeltétele van, mint például a számlatükör, így azzal kezdtük. Erről nyitottunk egy új topikot itt:
Minden visszajelzésnek örülünk. Köszi. Bocs az offért, és a NAV számlázás részleteit majd ide is posztoljuk.
1 Like
NAV számlázás appal kapcsolatban:
ERPNext magyar számlázás Monolithon megközelítése
Miért nem készült már el az ERPNext magyar számlázási megoldás?
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.
Milyen szemlélettel fejlesztjük a magyar ERPNext számlázást?
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.
Milyenelő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.
Hogyan csinálják mások?
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.
Mit felejtettünk el?
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.
Miért született ez a bejegyzés?
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 eredeti példányát az oldalunkon publikáltuk, itt azért posztoljuk, hogy egyszerűbb legyen megvitatni: ERPNext magyar számlázás Monolithon megközelítése | Monolithon
1 Like
@backendo
Sok idő es energia amit beletesztek, köszönjük.
A VTSZ szám mindenképpen fontos a számlában feltüntetni.
Az uj MOHU környezetvédelmi díj azonosítása miatt.
Erre vonatkozó számlán feltüntetni kötelező nyilatkozathoz is fontos egy személyre szabható rész.
FELVILÁGOSÍTÁS KÉRÉS:
Hogyan működne az ERPNext rendszerben a számlázás?
Közvetlen beküldéssel vagy egy exporttal és annak a fájlnak beküldésével.
Ha közvetlen beküldéssel akkor hogyan kell beírni a NAV számlázási rendszerrel a kapcsolati kulcsokat és adatokat?
——
Számlázási alapok video most került fel nemrég:
Kellemes ünnepeket!
Sziasztok!
Néhány gondolat:
- létező számlázóhoz kapcsolódni nem új ötlet, lásd itt ebben a threadben is ezt javasoltam már 2020-ban.
- a számla dátumok kezelése szerintem más EU országokban is hasonló, mint Magyarországon (pl. Ausztria, Németország), ezért mielőtt egyedi magyar megoldásra gondolnánk, érdemes lenne velük is egyeztetni itt a fórumnak a nemzetközi részén, hogy ők hogyan kezelik ezeket.
- bankszámla szinkronizációnál már elég baj, hogy a PSD2 korlátai miatt egy 3rd party szolgáltatón kell átmenni (nálatok GoCardless - korábban Nordigen, az Alyf meg talán a Plaid-et használja), de ezen kívül én nem szeretném, ha még egy “ERPNext SaaS” szolgáltatón is átmennének a banki adataim. Ha a Ti megoldásotok nem így működik, az jó hír lenne.)
Jó lenne megtalálni annak a módját, hogy az ERPNext magyar támogatása is open-source módon tudjon elkészülni. Nyilván ez nem egyszerű, mert a fejlesztő cégek számára ez jelentős költséggel jár amit valahonnan elő kell teremteni. Ez történhetne akár közösségi finanszírozással akár pályázati alapon.
Üdv,
Gergely
Köszi az aktivitást, igyekszem röviden mindenre válaszolni sorrendben:
-
VTSZ lesz, de később.
-
Számlára megjegyzés lesz, jelenleg a Remarks részt gondoljuk ehhez felhasználni.
-
Úgy próbáljuk megcsinálni, hogy később akár NAV közvetlen kapcsoalthoz is minden rendelkezésre álljon, de most Billingo integráció készül. Tehát a Billingo API-ra küldjük a számlát, aki elkészíti a NAV számára. Tehát elsősorban Billingo creditental lesz tárolva a számlabeküldéshez.
-
Viszont NAV technikai adatot is tárolunk azoknak, akik a NAV-ból szeretnének adózói név és címadatokat letölteni adószám alapján. (Ahogy a VIES-it is így emeljük be, de ahhoz nem kell hozzáférést tárolni, mert az nyilvános)
-
Olyannyira nem új ötlet létező számlázóhoz kapcsolódni, hogy a szamlazz.hu-hoz már 2020. május 22-én el is készült a sokáig húzódó megoldás, azaz jóval az említett bejegyzés előtt. Ezt követően az volt a terv, hogy közvetlen NAV kapcsolatot használunk, de a fenti bejegyzésben tárgyaltak alapján egy új, Billingo integráció készítése mellett döntöttünk.
-
Nem csak dátum szinten követjük az összes nyilvános ERPNext megoldást. Nem tudunk új hozzáadott dátumról, nálunk viszont elkerülhetetlen. De ahogy fentebb írtam, nem kötelező használni, illetve default értékeket is adunk majd.
-
Bankszámlaszinkronizáció nem megy keresztül még egy ERPNext SaaS szolgáltatón (mert rajtunk nem megy keresztül adat, de van admin jogosultságunk), hanem a hivatalos ERPNext SaaS szolgáltató rendszerén érhető el a megoldás az ügyfél számára is admin jogosultsággal, de forráskód hozzáférés nélkül.
-
Ahogy korábban írtam még nem született meg hogyan lesz hozzáférhető, nyitottak vagyunk.