Nyílt forráskódú, NAV kompatibilis, online számlázó program

Létezik ilyen?

Lenne rá igény?

Hozzászólások

A NAV  a programkészitőt nem abuzálja, a számlakiállító s***ge jó neki.

Kivétel van, ha te elvállalod  és "megbizott számlakiállító"  leszel , de még igy is egyetemleges a felelősség.  De itt se mint programkészitőt abuzálnának. Az más kérdés, hogy veled szemben a cég követelhet kártérítést, ha olyan a szerződésed, de egy free prgramnál semmilyen anyagi felelősséget nem szokás vállalni.

A könyvelőkkel kapcsolatban meg amikor bejött a NAV xml, emiatt az áFA törvényt kénytelenek szigorubban betartani, én azt tapasztaltam, hogy a programozóknak kellet elmagyarázni a kicsit bonyolultabb eseteket(mivel  (kénytelenek voltak a dokumentációkat átolvasni és utánanézni, ), pl. hogy hogyan kell szabályosan egy előlegszámlát mődosítani, miért nem lehet elözmény nélküli  stornó számlával elszámolni a göngyöleget stb.

A programoknak sok mindent kell tudnia, jó:

Vegyünk egy A programmal előállított számlát és próbáld meg szabályosan stornózni B programmal. Ez ugye még nem a holdraszállás project. Semelyik nagy online számlázóval ezt jelenleg nem tudod megtenni az ismereteim szerint.

Nyilván ha valaki kedvet érez , ne vegyük el a kedvét,egy ilyen fejlesztéshez, elég a leggyakoribb számlafajtákra koncentrálni, ezzel lefedi az esetek többségét.

Ez most ide OFF:

Pl: fizetsz előleget 100 Ft -ot. termék csak 80 Ft,ezért kapsz vissza 20 Ft , tiéd a termék és kapsz egy -20 Ft os végszámlát.  Általában így csinálják, Na ez így rossz, NAV erre hibát ad beküldéskor.

Könyvelő :rossz a programotok , hibát ír ki, nekem ne magyarázzatok, 20 éve így csináljuk. 

 NaV (idézet tőlük):

Amennyiben valaki nem ért egyet ezzel az útmutatással, vagy más utat keres, az teljesen a saját felelősségébe tartozik. Az "adóhivatali álláspont" több személlyel egyeztetett álláspont, ezért így is érdemes erre tekinteni.

</OFF>

Jó, de ebben mi a perspektíva?

Megcsinálod a szoftvert (=rengeteg pénz és idő), működik. Eddig ott tartunk, hogy ez befektetés, ráadásul nem is kevés (konkrétan sok).

Elkezded marketingelni, értékesíteni szokásos módon, ezenkívül githubra vagy valahova kiteszed a forráskódot.

Aki nálad elő fog fizetni, az jó dolog.

Ki fogja használni a forráskódot?

a) Saját ügyfél, mert Te nem tudod nekik kellően jó áron megcsinálni a kérését (netán az is zavarja, hogy más is ingyen hozzájut ahhoz, amiért ő fizetett). A későbbi követésekkel se kell bajlódnia, mert Te úgyis kipublikálod, azt majd átveszi. Ez neked nyilván nem jó, mert elestél egy ügyféltől, ráadásul potenciálisan egy olyantól, akitől érdemleges pénzt tudtál beszedni

b) Nem saját ügyfél, aki kellő üzemeltetési kapacitással és vállalkozó kedvvel rendelkezik. Ez esetben a befektetésedhez még annyi pénzt sem kerestél, mint a) esetben. Ez neked miért jó? Hátha visszaszolgáltat valamit?

c) Egy másik fejlesztő cég, aki esetleg ügyesebb marketingben és értékesítésben, netán már eleve nagy és kellő ügyfélbázisa van építkezni. A licenc lehet akár olyan is, hogy ezt kizárja, de mire észbe kapsz, simán lehet késő. A jogi csatározás bizonytalan kimeneteléről nem is beszélve (kellően jó licenc megfogalmazása sincs ingyen). És ne felejtsük, mikor erre sok kerül, még nem is feltétlenül térült meg a befektetésed.

A nyílt forráskódnak akkor látnám esetleg értelmét, ha valaki kellően nagyra nőtt ahhoz, hogy eltartsa a saját fejlesztését (és már megtérült a befektetés) és valamiért jófejkedni akar, valahogy ki tud építeni olyan közösséget, ahonnan visszakap valamit és saját ügyfeleinek tovább tudja adni, fenntartva a versenyképességet. De még akkor is ott van az, hogy más ingyen felépül arra, amin te nagyon sokat dolgoztál és kockáztattál. Mindez hazai környezetben (beleértve a piac méretét is).

Egyébként piacilag sem látom, erre miért lenne kereslet: aki online-t akar, feltehetően pont azért, mert nem akar üzemeltetéssel foglalkozni, fejlesztéssel pedig pláne nem. Mert ha nem csorgatod vissza a forráskódot, akkor örökké saját nyűg a nyomonkövetés. Ez pedig nem olcsó, egy nulláról indult rendszert pedig első körben jó eséllyel kisebb cégeknek lehet eladni, ahol kevesebb a funkcionális elvárás.

Nem is tudom mióta használom őket, teljes elégedettséggel. Csakis ajánlani tudom. Lendületben vannak a srácok, folyamatosan fejlesztik. Jó cucc, mobil app is van hozzá.

Ezért a pénzért nem érdemes saját írásával szarakodni, főleg, hogy ingyenes, ha kicsik az igényeink. Ha meg van rendes bevétel, akkor havi 1000Ft-ért ne basszunk fillért.

Nem a fillérb.szásról van szó. Ha lenne egy nyílt forrású, self-hosted megoldás, akkor azt akár a

- publikus netre sem kellene kitenni, így adatvédelmi szempontból is jobb lehetne

- megfelelő háttérrel talán gyorsabban testre szabható, módosítható, illeszthető lehetne

(uhh, beleért a kezem a bilibe)

[Falu.Me]==>[-][][X]

publikus netre sem kellene kitenni, így adatvédelmi szempontból is jobb lehetne

Márpedig oda ki kell tenned, mert online kell, hogy legyen, NAV-hoz kötelező küldeni.

Sztem azért nem lesz ilyen soha, mert a ténylegesen kompetens személyeknek érdektelen, unalmas rutinmunka egy ilyen projekt, sok és mély külső szakmai ismeretet igényel. Ilyennek max kezdők állnak neki, aztán szépen el is hal, mert ráunnak (nem ok nélkül).

IMHO a magyarországi adózási környezetben ez felejtős. Kicsit sem egyszerű amit egy számlázó programnak tudnia kell (nem vagyok beavatott, de haverok fejlesztenek számlázót, nagyon nem irigylem őket).

Ráadásul egy jogszabály változás ha kijön, arra záros határidőn belül reagálni kell. Hogyan tudod ezt garantálni egy nyílt forráskódú szoftvernél? Az úgy nem megy hogy majd valamikor kijavítja valamelyik önkéntes fejlesztő a bugot, ha éppen lesz rá ideje - addig az összes ügyfelet 100x megba megünteti a NAV mert nem feleltek meg a számláik a jogszabályban lefektetett követelményeknek.

Hidd el, nem akarsz nyílt forráskódú számlázót fejleszteni pusziért.

Mi nem is számlázót fejlesztünk, csak számlázó szoftver fölé overlayt (bankkártya terminálokról számlázunk) és maximálisan alá tudom támasztani a tapasztalataidat. Már a számlázó API-t is szívás lekövetni néha, pedig a számlázószoftver elfedi az érdemi munka nagyrészét. Legutóbb pl december 28.-án jöttek ki január 1-től érvényes változások. Ezt tényleg nehéz ingyenes alapon megszervezni, valakinek mindenképpen mögé kell állnia aki garantálja hogy időre lesznek frissítések.

Szerkesztve: 2021. 02. 12., p – 20:00

Rossz helyre ment, bocs.

Kum Gábor

Szerkesztve: 2021. 02. 12., p – 21:15

Szerintem nem jó ötlet.

Ha valakinek ingyenes kell, akkor ott van a NAV ingyenes számlázója.

Ha az nem jó, akkor van sok más egyéb, pl. Billingo, Billzone, Szamlazz.hu. Ezekhez van API, tehát lehet hozzájuk kapcsolni más rendszert, de vannak már pluginek is hozzájuk, pl. elterjedtebb webáruházak irányába.

Nagyon gyakran változnak a jogbszabályok, ezeket le kell követni naprakészen.

A felhőben futó szerintem a legjobb számlázó, mert a self hosted a végén drágábbra fog kijönni, ha még külön rendszergazdát is fizetni kell hozzá. Márpedig átlagos cég nem fogja tudni hosszú távon rendszergazda nélkül üzemeltetni. Többfelhasználóst működést is meg kell tudni oldani, meg főleg a biztonsági mentést.

E-számlázáshoz kell elektronikus aláírás és időbélyeg számlánként.

De közben ahogy írtam, eszembe jutott valami, ami felé érdemesebb lenne elindulni.

Nyílt forráskódú plugint viszont érdemes lenne írni, valamelyik elterjedett számlázó programhoz, lásd fentebb.

Pl. nyílt forráskódú WordPress plugin WooCommerce webáruházhoz, ami összeköti szépen a WooCommerce webáruházat és adott számlázót. Persze van már ilyen, de még lehetne rajtuk fejleszteni.

Vagy egyéb olyan rendszerhez fejleszteni plugint, amihez még nincsen, összekötve adott számlázó programmal. Erre viszont szerintem lenne igény, egyszerűbb is megvalósítani, szerintem ebbe az irányba indulj el.

Webáruházak, CRM rendszerek, vállalatirányítási rendszerek, általában ezeket szokták összekötni számlázókkal.

Igazából onnan indult a dolog, hogy kértem az online számlázóm fejlesztőitől egy nagyon apró módosítást (a számlaképen kellett volna a tétel megjegyzés betűtípusát fix szélességűre állítani (a beviteli mező betűtípusa egyébként fix szélességű)), de közölték, hogy erre nincs kapacitásuk. Úgy gondolom, hogy ez egy óránál nem lehet több meló teszteléssel, mindennel együtt. 

[Falu.Me]==>[-][][X]

Úgy működhetne, ha létrehozol erre egy komoly céget, felveszel programozót, ügyfélszolgálatost. A teljes kódbázis lehetne szabad szoftver, de a felhasználónak magának kell telepítenie, frissítenie és nincs hozzá ügyfélszolgálat.

Lenne a fizetős verzió, ami ugyanaz a kódbázis, de te futtatod a felhasználók részére a felhőben, van hozzá ügyfélszolgálat és fizetős. Persze fontos, hogy naprakészen kövesd a jogszabályi változásokat, és API is kéne, mert sokan össze akarják majd kötni a számlázót sokféle rendszerrel. De API nem elég, kell hozzá plugineket is fejleszteni webáruházakhoz, CRM-hez stb.

E-számlázáshoz kell elektronikus aláírás és időbélyeg is.

Magát a márkanevet le kéne védetni, tehát ha valaki forkolja, akkor nyugodtan megteheti, de a márkanevet nem használhatja. Tehát lehetne az egész szabad szoftver, kivéve a márkanév és a logó.

Erre van sok sikeres példa, pl. WordPress, Drupal, Discourse.

De erre tényleg akkor létre kell hoznod egy komoly céget és komoly pénzeket elkölteni, mire lesz egy használható verzió.

Amúgy volt egy Számlahegy nevű számlázó, itt volt elérhető: https://szamlahegy.hu/

De úgy látom, megszűnt. Vajon mi lett a felhasználóival?

Én nem használtam, de párszor megnéztem a weboldalukat, és volt nekik működő online számlázójuk.

Ha komolyan gondolkodsz a dolgon, akkor lehet hogy érdemes lenne megkeresned őket és megvenni / átvenni tőlük a kódbázist, ha van értelme.

Vagy még ami eszembe jutott, biztos van valahol már szabad szoftver számlázó, csak nem magyar jogszabályi környezetre. Egy olyat is lehetne forkolni és átalakítani magyar jogszabályi környezetre.

Úgy gondolom, hogy ez egy óránál nem lehet több meló teszteléssel, mindennel együtt. 

Ah, ja, meg kapcsolgathatóvá tenni, mert valakinek pont a fix szélesség nem felel meg. Aztán valamelyik user rákezdi, hogy meg kéne változtatni az oszlop szélességét, mert így pont nem fér ki a fasza céglogós ASCII art. :) És így tovább, amíg a végén lesz egy rohadt kacifántos user story-d, aminek az implementálása egy fillér profitot nem termel.

Tipikus "egy órás feladat" lifecycle: https://derrickesharry.blog.hu/2017/03/26/a_csak_egy_mezot :)

Ismerem, csináltam már én is hasonlót.

Igazából onnan indult a dolog, hogy kértem az online számlázóm fejlesztőitől egy nagyon apró módosítást (a számlaképen kellett volna a tétel megjegyzés betűtípusát fix szélességűre állítani (a beviteli mező betűtípusa egyébként fix szélességű)), de közölték, hogy erre nincs kapacitásuk. Úgy gondolom, hogy ez egy óránál nem lehet több meló teszteléssel, mindennel együtt. 

Erre reflektáltam, csak véletlenül rossz szálba postoltam. Ez esetben ha véletlenül HTML-ből nyomtatnának számlát akkor kliens oldalon greasemonkey-el (vagy tampermonkey-el) injektált javascripttel lehetne a kívánt formázásokat elvégezni. PDF-re jó ötletem nincs (azon kívül, hogy taknyolni lehetne valami "proxy" webes szolgáltatást ami a PDF-et átalakítaná és hasonlóan kliens oldalra injektált scripttel először annak átadni és redirectelni a javított PDF-re a nyomtatáshoz). Tudom ezek nem "enterprise grade" dolgok, de a kis magyar valóságban simán működhetnek.

aperger QtSmartStorage-ja egy darabig nyílt forráskódú volt. Aztán mikor jött a NAV online téma ő is bezárta a kódot, mert iszonyat munka volt a support implementálása.

Én egy meglevő open-source ERP-hez csinálnám inkább meg a Magyarország modult. Például az ERPNext-hez: http://erpnext.com

Azzal azonban egyetértek a többiekkel, hogy ezt hobbiprojektként nem csinálnám, csak ha profi támogatást is mögé lehet tenni, ami viszont nem lesz ingyen. De ennek a rendszernek nem is az online számlázót használóknak kellene feltétlenül lennie a célcsoportjának, hanem olyan cégeknek, ahol már van keret és igény a komolyabb ügyviteli rendszerre, aminek a számlázás csak egy része.

A fórumnak már van magyar szekciója, bár még nincs nagyon nagy élet itt, ha komolyan érdekel, akkor csatlakozz: https://discuss.erpnext.com/c/community/hungarian-community

Speciel ezt anno én is benéztem. Az viszont elég vicces, hogy a NAV nem vállalja, hogy megőrzi az adatokat. Az egész minden számlát be kell küldeni legnagyobb hozadéka lehetne, ha ezen a módon lehetne elektronikus számlát kiállítani, mindenféle aláírósdi és időbélyegzősdi helyett, a hivatalos céges elektronikus levélcímre történő értesítéssel.

Az a durva, hogy ha az xml maga a e-számla és a hash is fel lett töltve még akkor sem garantálják, hogy az náluk meglesz. A kibocsájtónak és a befogadónak is gondoskodni kell a jogszabályok szerinti archiválásról.

Ezt most hogy gondolják ? Hogy veszhet el onnan bármi is ? Vagy ezt direkt hagyták meg maguknak arra az esetre, ha egyes cégeknek vagy pártoknak leégne az irodájuk akkor tudják törölni az elégetett számlákat is.   

Valaki csinálhatna nekik valami blokchain alapú archiválót, hogy ne vesszenek el a számlák a rendszerből. 

De mostmár nem a sima emailben küldött számla is elektronikus számlának minősül (függetlenül az elektronikus aláírástól / időbélyegtől)? Ezt mintha a NAV Githubján láttam volna egy issueban. Tudom, hogy a jogszabályt / hivatalos doksikat kéne olvasnom, de még a tájékozódási szakaszt sem kezdtem el. :)

Ja, egy bónusz a NAV semmit nem vállalhoz: még apehes időkben kapott a cégem egy 3 milliós inkasszót, mert elvesztettek egy oldalt egy bevallásból. Úgy látszik, azóta sem javult semmi, bár nem tudom, hogy akinek anno az volt a feladata, hogy a beérkezett bevallásokból a tűzőkapcsot eltávolítsa (amikor ezt megláttam, egyrészt megvilágosodtam, másrészt nagyon nehezen bírtam ki, hogy ne törjön ki belőlem a hangos röhögés), az most mit csinál? Random időközönként kirántja a tápkábelt a szerverekből?