FLOSS ERP

Ledger szabad ügyviteli szoftver

Ledger él még itthon?

ODOO-n kívül milyen FLOSS ERP-t ismertek, amihez van magyar NAV kompatibilis számlázó?

FLOSS ERP tapasztalatok is érdekelnek, amennyiben valaki fejleszt vagy használ ilyet. ODOO-ról is jöhet (ha jól tippelem ő a legnépszerűbb, most itthon /az látom többen fejlesztenek alá/).

( djsmiley v | 2024. 04. 12., p – 08:46 )

Kicsit off, mert nincs mostanában tapasztalatom ilyesmivel:

Alapvetően bármi amibe egy "NAV kompatibilis" számlázót be tudsz kötni. Sztem egyre kevéssé releváns, mert szamlazzhu-nak meg billingonak is van phpapija, meg minden csoda illesztése.

Pontosan erre gondoltam. Anno pl. WHMCS-t is így oldottuk meg. Minden abban volt, a számlázó egy "kiszervezett" tevékenység, ne akarj vele foglalkozni. Kimegy az adat h. miről kell a számla (Az ERP-ből), majd visszajön h. OK, meg a PDF, amit beiktatsz egy dokumentumként az ügyfélhez.

Így nincs fregmentáció, mert amire szükséged van az egy helyen marad, cserébe a kiszervezett tevékenységet végző garantálja a jogi megfelelést, nem neked kell vele játszani. 

Azt én sem tudnám elfogadni ha egy rendszerből a folyamathoz ki kell mászni, bemászni egy másikba, majd vissza az előzőbe, de itt nincs erről szó, az adatok sem töredeznek, hiszen az ERP által szolgáltatott adatok az ERP-ben maradnak, akár később egy másik számlázóval is előállítható a számla (nyilván jogilag ez nem oké, de érted mire gondolok)

Ugye a számla jóváírásnál be kell hivatkozni a régi számlát is. Így a végén az api-s számlázó használat bonyolultabbá válik, mint maga a számlázó megírása NAV Api-val. Ez útóbbival már rendelkezem, mert implementáltam.

Maga az elgondolás nem ördögtől való, hogy van benne több ilyen konnektor, ezzel ráutazva a ezen szereplők piacának felhasználóira.

Sőt, helyesbítő és sztornó esetén is. Erre mi csináltunk anno 2 gombot ami gyakorlatilag 1-1 api call volt (ahol kellett felülettel persze).

A saját NAV api implementációt azért tartom teljesen feleslegesnek KKV méretben, mert egy billingo évi 10E forint és tuti nem lesz az a probléma h. hoppá, azonnal NAV api frissítés van, valamit elcsesztél stb. A felelősségvállalás azért ebben a kérdésben egészen komoly. Nem feltétlen csak azt ronthatod el h. épp rossz emoji került a belső kommentszekcióba, hanem akár csinálhatsz olyat is ami később jogi hátrányt okoz az adott cégnek.

Lehet, hogy nem teljesen ertem, mire gondolsz, de amit en elkepzeltem, ott a szamlazo API csak szamlakepet general (+ a jarulekos dolgokat, sorszam, stb.). Semmilyen adatot nem kerunk be tole utolag. Igy a jovairasnal sem kerdezunk tole semmit, a sajat ERP-n belul nezed ossze a jovairasokat a kiallitott szamlakkal.

A legfaszabb ugye az lenne, hogy a NAV Online Szamlazo tudna API-n keresztul is szamlat generalni, csak ez ugye kinyirna a piac nagy reszet.

Ez így kevés. Úgyanis amikor helyesbítő számlát készítesz lehivatkozod a számlát és annak sorszámát, valamint minden számla egyben egy készlet, vagyis negatívba csak annak erejéig tudsz jóváírni.

usecase folyamat:

1. számla kiállít -> 2 db lófaszról
2. számla módosít, mert visszahoz a vevő 1db lófaszt
3. vevő rájön neki nem kell lófasz egy sem, vissza hozza a maradék egyet is
4. a vevő az univerzumban talál még egy lófaszt és visszahozza lobogtatva a számlát, de te már ezt nem tudod visszavenni, mert a számla, mint készlet már nullás

Ezt ertem, de itt kulonbozo, egymastol fuggetlen feladatok vannak:

  • szamlakep generalas
  • nyomtatas / e-szamla kuldes
  • NAV bejelentes
  • keszletezes

Ez szerintem akkor sem egy egyseg, ha magadnak fejleszted mindegyik lepest. Felejtsuk el a szamlazz.hu-t, tegyuk fel hogy kitalalod, nem akarod ketszer lefejleszteni ugyanazt a logikat, ezert a ceges ERP-dbol kiszervezed a szamlazo reszt egy microservice-be. Legyen szamlaservice a neve. Ekkor a fenti use case ilyesmi lesz:

  1. számla kiállít -> 2 db lófaszról
    • a szamlaservice megkapja a kerest, hogy ennek a vevonek, ezekkel a termekekkel, stb. kell egy szamla
      • bekuldi a NAV-hoz
      • visszaadja a kiallitott szamlat
    • az ERP kivesz 2 db lofaszt a raktari leltarbol es allokalja a megrendeleshez
  2. számla módosít, mert visszahoz a vevő 1db lófaszt
    • a szamlaservice megkapja a kerest, hogy ennek a vevonek, ezekkel a termekekkel, stb. kell egy szamla
      • bekuldi a NAV-hoz
      • visszaadja a kiallitott szamlat
    • az ERP visszarakja a raktarba a lofaszt a megrendelesbol
  3. vevő rájön neki nem kell lófasz egy sem, vissza hozza a maradék egyet is
    • a szamlaservice megkapja a kerest, hogy ennek a vevonek, ezekkel a termekekkel, stb. kell egy szamla
      • bekuldi a NAV-hoz
      • visszaadja a kiallitott szamlat
    • az ERP visszarakja a raktarba a lofaszt a megrendelesbol
  4. a vevő az univerzumban talál még egy lófaszt és visszahozza lobogtatva a számlát, de te már ezt nem tudod visszavenni, mert a számla, mint készlet már nullás
    • az ERP nem kuldi el a requestet, mert hulyeseg

A szamlaservice stateless, nem tart szamon semmit, minden info az ERP-bol jon, ami a szamlakiallitashoz kell. Most hogy az API tuloldalan a szamlazzhu van, vagy az Oregon Szamlaservice Ultimate Edition, az architekturalis szempontbol mindegy. :)

En sem gondolom, hogy ezzel nagyot lehetne sporolni, csak azt mondom, hogy technikailag nincs olyan akadalya, mint amirol beszeltel.

Ezt mar megcsinaltam, amugy, amikor ilyen-olyan felvasarlasok utan ossze kellett integralni a szamlazast. Ott is ez lett a megoldas, hogy a szamlazakiallitas ki lett herelve mindenhonnan, es egy kozos service-en keresztul lehetett szamlat kiallitani. Ezek a leanyvallalatok full fuggetlenek voltak egymastol raktarkeszlet szempontbol peldaul, tok felesleges osszedrotozni azzal a folyamattal, ami a nyomtathato PDF-et allitja elo.

Innentől kidobott pénz a 3rd party bevonása.

Ez amikor nem gondolod végig mit kell teljesíteni a szoftvernek, és neked pontosan elegendő, ha egy bizonyos formátumú pdf legenerálódott. Persze, tudom úgy értetted, hogy szívesen szinkronizálod ezt a szoftvert is, hogy megfelelő legyen a jogszabályi kiírásoknak ahelyett, hogy kifizetnél X<10 forintot hogy a számla előálljon, majd tudod tárolni ott ahol akarod. 
Évi 200k számla felett talán megéri ezt nem kiszervezni. 

API-API, igazából mindegy, hogy navosat vagy másét használod, az lesz a jobb neked amelyik kényelmesebb. Ez inkább felelősségi kérdés. Ha te hívod a NAV apit akkor a te felelősséged ha hülyeséget küldesz be, ha a számlázó program, akkor pedig azé aki azt gyártotta.

Ez inkább ilyen általános para szerintem. Hallott már valaki olyanról akit megbüntettek amiatt mert rosszul hívta a NAV apit? (nem költői a kérdés, én nem hallottam de lehet valaki igen)

. Az ERP meghivja a szamlazo API-t

 

Tudom egy cegnek semmi se draga, de az szamlazz.hu apija csak es kizarolag a legdragabb csomagban erheto el.

Persze van aki levelezeshez o365-ot vesz es nem kell neki egy smtp-n kivul meg egy office se.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A szamlazz.hu csak egy pelda, nem tudom, mik vannak a piacon. A letezo legolcsobb, API-t kinalo szolgaltatas is eleg lenne erre. Az uzleti logikat ugyis neked kell megirni.

Egyebkent nem ezt kell nezni? A "mindegyik csomagunkban elérhető Számla Agent modullal 100%-ban automatizálhatod a számla- vagy nyugtakiállítást!" szerk: ja, ezt kulon aruljak, latom

Volt egy olyan kosza gondolatom, hogy mint maganember a bejovo szamlaimat szkennelem, feltoltom, es kezelgetem fel evig, amolyan dogfood jelleggel.

 

De en mar csak ilyen fukar vagyok.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Vagy harminc évvel ezelőtt azt neveztük ERP-nek, amely képes a kiállított aktív és igazolt passzív számlákból szabályos mérleget csinálni. Egy ehhez kapcsolódó költséghelyes eredményelszámolás persze magától értetődően szintén ott kell legyen benne, meg a főkönyvi riportok, amből a kontrolling dolgozik stb.

Nagyon profi informatikusok akkoriban azt mesélték, hogy ez mind csak az előjáték, egy igazi ERP rendszer ugyanezt fordítva is tudja, tehát elő tudja állítani azokat a számlákat, amelyekből az év végi zárómérleg készühetett volna... ;^))

Ehhez képest kicsit riadtan olvasom, hogy a számlázás nagy tudású számítástechnikai szakemberek között önálló, kiszervezhető akcióként lehet ERP része. Hát igen. Tkp minden kiszervezhető, az informatikus meg majd integrál... röhej.

Michelberger Pál (ezt kutatja) szerint: ERP = TPS + MRP II. + MIS

Ez megfelel annak a  definíciónak és korszaknak, ami az ERP megjelenésének pillanatában igaz volt. Ma már inkább az az ERP amit annak hívnak, de ismertetőjelének kellene lennie, hogy az adott vállalat operatív tevékenységét és stratégiáját lefedje. Ezekhez lehetőleg ne kelljen más szoftveres megoldás. Ez szigorúan véve az operatív tevékenységekre igaz beleértve az operatív tervezést, míg a stratégiai tervezés már árnyaltabb, de annál is minimum döntéshez szükséges adatokat kell tudnia nyújtania.

Számlázó szoftvert csinálni szívás. Olyat meg ami minden játékosnak megfelel jogszabályilag (nem ízlésnek!!!) kb lehetetlen. Aki erre adja a fejét, az sokat fog anyázni. Esetemben a számlázóm pl. veszélyességi pontokat is számol (ADR), hogy az adott tételhez lehessen tudni, milyen a jármű szükséges, ha több autó van, akkor a veszélyességi elosztásban is segít.

Drága jó Pali bácsi. Vajon él-e még?

Nyilván bármit is lehet bárminek nevezni, de az az ERP, ami nem a számvitelen alapul, az valami más, nem ERP. Nem tudom, hogy az informatikai képzésnek része-e valamilyen számviteli alapkultúra megismertetése, de attól tartok, hogy az ERP-vel foglalkozó informatikusok, akik komoly számviteli rendszerszervezési támogatás nélkül használják ezt a hárombetűs kifejezést, csak ártanak. Az rendben van, hogy egy normális ERP rendszer terjedelmében a core business támogatása vagy az ahhoz tartozó különböző tervezési elemek nagyobb részt képviselnek, mint a számvitel, de a mag, az szigorúan pénzügy és számvitel.

Amit példának említesz, szerintem ugyanezt támasztja alá. A számlázás az ERP-ben a folyamat végefelé van, a számla tartalmát a tranzakció elején - többnyire a szerződéskötéskor - kell kialakítani (mindenféle tarifák, szabályok, elszámolási megállapodások alapján, amiket általában a szerződés vagy valamilyen üzleti kondíciós lista tartalmaz). Különben nincsen elhatárolás, nincsen tervezés, nincsen forecast, nincsen mérés és nincsen döntés előkészítés. Egy szemérmes, a szerződés tartalmától független számlázómodul elmegy még egy péküzletben vagy egy piroslámpás házban, de az ilyesmi aligha lesz része egy ERP-nek. Ha az ADR szerinti tarifát a számlázó modulra bízod, abból nem lesz ERP.

Meg úgy van, ahogy írod, egy jogszabálykövetés nélküli  önálló "számlázó modul" nevetséges cucc, csak szopás a felhasználónak is.

"Ha az ADR szerinti tarifát a számlázó modulra bízod, abból nem lesz ERP."

Szarul fogalmaztam. Teljesen független nálam, de infot ad számlázás közben a felületen is, ahogy  megrendelésnél vagy már a felhasználónak a webáruházban vásárlásközben. (100 pont felett ADR-es autó kell)

Lassan kezdem erteni, hol a felreertes koztunk. :)

En szamlazas alatt nem ezt ertem. Az, hogy kigeneralodjon egy nyomtathato PDF, vagy e-szamlanal a timestamp meg a tobbi vacak, az egy tok fuggetlen dolog a keszletkezelestol, ADR-tol, akarmitol, meg akkor is, ha az ADR-infokat ranyomtatjuk a papirra. Lehet, hogy a UI layerben osszeernek, de architekturalisan en nem drotoznam ossze.

Amit fentebb irtam szamlaservice, az peldaul az egyik rendszerbol kapta a kiallitando szamlak adatait, a masikbol az aktualis marketing-lofaszt, amit ra kell nyomtatni a papirra, a harmadikbol a sarga csekk adatait, a negyedikbol meg azt, hogy milyen API-n lehet kuldeni a nyomdanak a kesz szamlakepet.

 Akad szabadon letölthető NAV xml beküldő pl https://github.com/pzs/nav-online-invoice

Viszont 2028-ra a közösségi  számlákat szabványositani akarják, egységes elektronikus számla és egységes beküldés, az egész EU-ben, amit az adóhivatalok átvehetnek a nemzeti  számlázáshoz, de nem kötelező. NAV azt nyilatkozta, hogy "nagy eséllyel" tervezi átvenni (EN 16931 adatstruktúra) . Akkor már csak 4*365 -öt kell aludni és lehet hogy megjelennek a FLOSS verziókban is az egységes (EU) nav beküldők.

https://blog.claryel.hu

Pedig nagyjából azok. Ezt még a harmonizáció legelején kellett rendezni. De ettől függetlenül, a számla tartalmára vonatkozó normák még az EDIFACT óta közösek. A NAV informatikája sokkal előrébb van, mint sok más nálunk fejlettebb ország adóhivataláé. Pl. a személyi jövedelemadó bevallásban nagyjából úgy egy évszázadnyival vagyunk előbbre az EU átlagánál. Vagy a NAV-hoz bekötött pénztárgépek, amit sikk volt kiröhögni. Oszt tessék, működik.

Itt szerintem arról van inkább szó, hogy ma nálunk a számla kibocsájtója által felszámított ÁFA a NAV-nál összevezethető a számla befogadója által elszámolt ÁFÁ-val. Tkp. az ÁFA bevallás számlaszintű kontrollját meg lehet csinálni a NAV-nál. Ha bevezetik ezt az egész EU-ra, akkor nem csak a magyar számlák lesznek benne a rendszerben, hanem az összes EU-s elszámolás is. Ennek a lánckereskedelem esetén van jelentősége. Nálunk a rendszer ezt nagyjából kizárja vagy könnyebben felderíthetővé teszi, az EU-ban meg sokmilliós ÁFA csalásokat lehet csinálni. Itt szerintem nincsen lemaradásunk, az EU-nak lehet felzárkóznia a NAV-hoz.  ;^))

Nem kértek felmentést:

Európai Bizottság VAT in Digital Age (VIDA) javaslatcsomagja kötelezné a tagországokat a közösségen belüli ügyletek esetében, miközben egy új, majdnem valós idejű digitális adatszolgáltatási rendszer (DRR, Digital Reporting Requirements) bevezetését is előírná.

 

A magyar vállalkozások szempontjából mindez azt jelenti, hogy mivel hazánk nem kért és nem is tervez derogációt kérni a vonatkozó közösségi szabályok alkalmazása alól, ezért amíg az EU-s előírások nem változnak, Magyarországon nem lesz kötelező az elektronikus számlázás, és nem módosul az online számla-adatszolgáltatás.

Egyelőre tehát fellélegezhetnek azok, akiknek ez nehézséget okozna. Antretter elmondása szerint ez azonban nem jelenti azt, hogy a kérdéssel egyáltalán nem szükséges foglalkozni, hiszen ami késik, nem múlik.

Jogszabályok eltérése országonként  nem  akadályozná a számlabeküldést, kiállítás egíységesítését, szerintem. 

https://blog.claryel.hu

Ehhez képest kicsit riadtan olvasom, hogy a számlázás nagy tudású számítástechnikai szakemberek között önálló, kiszervezhető akcióként lehet ERP része

Egy kicsit azert probaljuk megerteni a feladatot. :)

Oregon egy dobozos termeket akar fejleszteni, ha jol ertem. Ha nem tudja ugy eladni, hogy meglevo rendszerekkel egyuttmukodjon, akkor kisebb a megcelozheto piac. Sokkal kisebb. A szamlazas pont az egyik ilyen kritikus resz lehet. Van mondjuk egy ceged, ami mar csinal valamit. Lehet, hogy inditanal egy tok fuggetlen uzletagat, ahova kene egy ilyen ERP. Kidobatod a regi szamlazorendszeruket? Hat, sok sikert hozza.

Amit lehet, hogy Oregon a hazon belul fejlesztett ERP-ja fejlesztese kozben talan nem lat, hogy zoldmezos projekt ERP-ban gyakorlatilag nincsen. Lehet ugy csinalni, mint az orosz borotvalkozogep, az SAP-nak anno be is jott, de nem biztos, hogy ez a siker megismetelheto.

Hibátlan, míg élek.

 

Arra gondoltam csinálnék egy céget ifjakkal, akik üzlettársak lennének benne és valamilyen FLOSS rendszer alá fejlesztenénk. Ez esetben én is migrálnék alá. Így, ha meghalok már nem vagyok kockázati tényező, mert egy létező cég tovább vinné a rendszert + community.

Jelentkező már több is van erre. Most vizsgálódom. Azt látom, hogy olyan emberek nem nagyon tevékenykednek itthon FLOSS ERP közelében, mint én, aki ért az üzlethez és a kódoláshoz is.

Az a baj az ERP-el, hogy ahány cég annyi elgondolás és annyi féle igény is van.
Nekem 90%-ba paraméterezhető, de még mindig van olyan, hogy jön be új paraméter, mert egy ügyfél kitalál valamit, amit viszont a többi ügyfél nem kér.

pch
SB-soft online ügyviteli rendszer

Azt látom, hogy olyan emberek nem nagyon tevékenykednek itthon FLOSS ERP közelében, mint én, aki ért az üzlethez és a kódoláshoz is.

Szerintem az "itthon" + "FLOSS" + "ERP" fejlesztoi szempontbol egy nagyon specifikus piac. Ha valaki nem erdekelt benne kozvetlenul valamilyen formaban, akkor nagyon nehez embert talalni az indulashoz.

Igeny viszont szerintem lenne ra, szoval jo otletnek tunik.

Szia!

Másik topicba írtam (https://hup.hu/comment/2962611#comment-2962611):

Ha nyílt forrású ügyviteli rendszer érdekel, akkor az ERPNext-et javaslom: https://erpnext.com

Ez egy komplett ERP rendszer nagyon sok modullal, de meg tudod csinálni, hogy csak azt kapcsolod be benne, amire éppen szükséged van. Ellentétben az Oodo-val, itt tényleg minden hivatalos modul nyílt forráskódú, teljesen támogatott, GPL / AGPL licencű, nincs "fizetős upgrade feature".

A rendszer Frappe Framework-re (https://frappeframework.com) épül (ennek MIT a licence), amivel nagyon gyorsan lehet üzleti appokat fejleszteni. Gyakorlatilag az ERPNext is egy nagyon komplex Frappe app. Korábban egy monolitként adták ki, de most elkezdték felvágni különálló appokra.

A HR modul neve "Frappe HR": https://frappehr.com/

Ha az alaprendszer nem tud valamit, akkor nagyon könnyen testre szabható, a módosítások külön cégspecifikus appba is kiszervezhetők, hogy ne kelljen gányolni.

Full Disclosure: Mi már egy ideje használjuk belső eszközként (pont nemrég néztem, hogy 2016-ban regisztráltam a fórumára :) ), és most egy WYSIWYG Web CMS-t fejlesztünk hozzá, ami integrálódik a Frappe admin appjába, de a frontend külön React & NextJS alapú.

Viszont NAV kompatibilis számlázó még nincs hozzá, nekünk ez egyelőre nem volt prioritás. Van egy másik magyar csapat, akik dolgoznak magyar támogatáson, itt írtak a fórumra: https://discuss.frappe.io/t/hungarian-invoice-magyar-szamlazas/64970/15…

Örülnék, ha lenne eköré a rendszer köré nagyobb közösség Magyarországon, beszélhetünk, ha gondolod.

Emellett van egy másik rendszer, amit az Odoo elődjéből forkoltak, ez a Tryton: https://www.tryton.org/
Konkrétan az egyik Odoo (akkor még TinyERP) fejlesztő megelégelte, hogy milyen irányba megy a rendszer és a cég, és csinált egy forkot. Technikailag nagyon szépen van vezetve a projekt, vannak tesztek, rendes release folyamat, dokumentáció ... stb. Viszont user experience szempontból a Frappe / ERPNext sokkal jobb volt. (Amikor legutóbb néztem.) Úgy tudom, hogy ennek sincs magyar támogatása.

Üdv,
Gergely

Köszi. Egyelőre gyűjtőm az infot.

Téged mi érdekelne az egészből?

 

update: Elolvastam a magyar bejegyzéseket számlázással kapcsolatban. Eszembe jutott, hogy nem beszélni szeretek róla, hanem csinálni. :)

Szerintem:
1. Monolithon szerintem túl gondolja.
2. Felesleges olyan számlázót csinálni ami mindenkinek jó.
3. A számla ne tudjon róla, mit fog vele kezdeni a könyvelés.

( Oregon | 2024. 04. 13., szo – 10:33 )

Szerkesztve: 2024. 04. 13., szo – 10:33

Ha esetleg valakinek kedve van a kipróbáláshoz (Ubuntu-s példa):

 

ODOO telepítése

sudo docker run -d -e POSTGRES_USER=odoo -e POSTGRES_PASSWORD=odoo -e POSTGRES_DB=postgres --name db postg
sudo docker run -p 8069:8069 --name odoo --link db:db -t odoo

 

ErpNext telepítése

git clone https://github.com/frappe/frappe_dock
cd frappe_dock
sudo docker-compose -p pwd -f pwd.yml up -d

user: Administrator
pass: admin

( Oregon | 2024. 04. 15., h – 19:03 )

Szerkesztve: 2024. 04. 15., h – 19:04

Odoo Magyarországnál lévő ismerősöm ma elmondta a community-ről migrálás enterprise-ra az egyirányú utca. Ha csak odoo online-t használsz, akkor semmit nem tudsz feltelepíteni, még a magyar számlázást sem, ahhoz odoo.sh kell. Odoo.sh-ban a verzió frissítést a magaar support nem ingyen csinálja. Milliós tétel is lehet, míg odoo online-ban ez egy gomb.

( martonmiklos v | 2024. 04. 15., h – 19:03 )

Szerkesztve: 2024. 04. 15., h – 19:07

Nem teljesen ERP, de számlázni éppen lehetne belőle: én az InvenTree nevű raktárkészlet kezelő/MES (jellegű) rendszert szoktam patkolgatni.

MES fronton amit itt Magyarországon láttam alakításhoz képest világszínvonalú...