[keresek] Webes számlázóprogram (egyszerű)

Üdv,

Jelenleg van ilyenem (még ha többet is tud nagyságrendekkel, mint amire szükségem van), ám a saját szerveres verziót a fejlesztők vélhetően nem támogatják többé, így 2016/Q2 vége felé újat kell beszereznem.

A követelmények:

  • Saját szervereken szeretném üzemeltetni (A szerveren a web, B szerveren a DB)
  • PHP vagy Perl legyen
  • MySQL adatbázis
  • Ne legyen benne Flash
  • Tudjon generálni PDF számlát
  • Lehessen a számlára egyedi elemeket tenni (logó, aláírás, stb)
  • Minden olyan feature-t tudjon, ami egy KATA-s vállalkozáshoz kell(het)
  • 2016-os adótörvény kompatibilitás - NAV adatszolgáltatás
  • Évi 30-50 számla kiállítása

Tudom, hogy ismét elő fog fordulni, ezért szeretném kérni, hogy arra koncenráljon a tisztelt olvasó, ami ott van a listán, ne arra, ami nincs :)
Tehát a Miért nem jó neked a.../Mi a bajod a ... kezdetű, és tetszőlegesen folytatódó (desktop/online/java/windóz/extel/stb) kérdésekkel nem akarok foglalkozni. Akit ez a kérdés nyugtalanít, hunyja le a szemét, és próbálja elképzelni az alábbi scenario-t:

Emberünk, hogy bemegy az étterembe, megrendeli az innivalót, megkapja az étlapot, majd a pincér visszatér a rendelést felvenni.
- Egy adag bécsi szeletet kérnék, de a feltüntetett rizs helyett hasábburgonyával.
- Miért nem jó Önnek a sima rántott hús, és mi a baja a rizzsel?
- Mert bécsit akarok zabálni krumplival, b@**meg!

Egyszóval a konstruktív javaslatokat előre is tisztelettel köszönöm :)

Hozzászólások

Tudom-tudom, de ez konkretan erdekel: miert preferalod jobban a sajat hostolt megoldast az online cuccokkal szemben? Adatvedelmi para, vagy konkretan van rossz tapasztalatod valamely szolgaltatassal? Foleg ez utobbi miatt kerdem...
--
Blog | @hron84
Üzemeltető macik

Szia,

Na, pont ez a bajom! Ezt használom most, minden szinten OK, viszont a 4-es verziót már nem fogom megkapni (amiben nincs flash), mert a saját szerveres verzió használatát erre már nem biztosítjátok. December 3-i hírlevél...
Ettől nem vagyok boldog, és emiatt kell váltanom :(
--
PtY - www.onlinedemo.hu, www.westeros.hu

Hali,

Én nem biztosítok semmit, csak használom :) Semmi közöm hozzájuk amúgy, csak megelégedéssel használom a cuccukat. Bár hozzá kell tennem, hogy a webes felületre szökőévente egyszer lépek be, mert API-n megy minden a saját rendszeremből, viszont emlékeztem, hogy van lehetőség saját szerveren futtatni (én nem úgy futtatom).

szamlazz.hu
és használd az általuk biztosított API-t.
Így saját szerveren tárolhatod a számláidat, onnan számlázol, akár az emaileket is onnan küldheted.

Én elégedetten használom a rendszerüket így 2 éve.

És ugyanez a cég fog 2-4 év múlva kacagva átállni felhőre, mert az a trendi....

A cég nem idegen, mert partnerségre léptek. Aláírod a titoktartási nyilatkozatot és szolgáltatási szerződést, stb. Ezek jelenleg sokkal korrektebbek, mint a google és egyéb online szolgáltatók "Elolvastam és ezzel megértettem" szerződései.

Az legyen az online ügyviteli megoldások ellen, aki SOHA nem lépett be a gmail-be és nem használt dropbox-ot és a telefonjával nem fényképezett le egy céges dokumentumot sem :)

Webes számlázót (ez inkább ERP) fejlesztek, de eszembe nem jutna idegen felhőbe rakni. Dedikált saját vas. Nem bízom más vállalkozásokban, mérettől függetlenül. Ha történik valami a rendszeremmel, akkor lehet abba bele is pusztul a cég, míg a szolgáltató megvonja a vállát és elenged nekem egy kis pénz a havidíjából.

Milyen jól látszik itt is az a két típus, akikkel találkozni szoktunk:
-az egyiknek az jelent biztonságot, hogy saját maga eszközein tárol mindent, minden a felügyelete alatt van
-a másiknak az jelenti a biztonságot, hogy nem kell saját infrastruktúráról gondoskodni, szerverrel "vacakolni", mentéseket csinálni, frissíteni, stb.

Tapasztalat szerint a cég méret, a működés jellege jobban befolyásolja azt, hogy melyiket érdemes választani. Ahol csak pár személy dolgozik, nem egy helyen vannak, nincs külön rendszergazda vagy hozzáértő ember, ott inkább a felhős verziót szokták preferálni, és ott az tűnik a jobb döntésnek.
Olyan helyen, ahol sokan használják a programot, a cég működése megbénul ha nem érik el állandóan a rendszert, ha rengeteg bizonylat készül (pl. pörgős készletnyilvántartás, logisztika), vagy sok a nagyméretű anyag (dokumentumkezelés), akkor tényleg a helyben levő példány a megoldás.

Nincs itt fekete vagy fehér, jó vagy rossz: mindig az adott körülmények és elvárások döntik el, hogy mi a pillanatnyilag több előnnyel járó út. Aztán később meg legfeljebb jöhet az újratervezés :) Ilyenkor szokott jól jönni, hogy egy felhőben levő rendszerünket pillanatok alatt át tudjuk tenni az ügyfél saját szerverére, és visszafele is működik ez a dolog. :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Bár rábízhatnám másra a munkát, de ez nincs így, mert:
- nincs olyan nagy múltú cég, stabil anyagi háttérrel/erőforrásokkal akire rábíznám
- ha lenne ilyen, akkor nem érné meg nekem anyagilag

Egyszerűen folyamatosan azt látom, hogy cégek jönnek, cégek mennek és a szolgáltatások evolúciója olyan gyors ami nekem gond lenne. Nagyon jó érzés, hogy 2003 óta ugyanazt a rendszert illetve a fejlesztett verzióját használom. Szerintem kevesen mondhatják el ezt. Én simán kinyomtatok egy 2003-as számlát abból a rendszerből amiben ma is számlázok. Anno 2003-ban amikor webre elkezdtem írni a számlázómat (ekkor még csak ez volt), szinte mindenki hülyének tartott, mert a "vékony kliens" kategória a múlté, ahogy a szakma akkor fogalmazott. Az idő megmutatta azt amit sejteni lehetett már akkor is, hogy a webes technológiák tovább húzzák avulás nélkül, mint az asztali OS lib-ek. Ez idő alatt platformok jöttek-mentek alattam, folyamatosan migráltam eszközöket, de mint a Taft a rendszerem állta a szelet. :)

Több mint 12 év telt el, hogy a rendszeremet használjuk. Ez idő alatt csak tervezett leállás volt az is munkaidőn kívül és sohasem érte el az 5 percet. Vajon ezt mennyiért kapnám meg? :)

Sok forgatókönyv van, saját rendszer telepítésére. Szerintem (is) a legjobb a dedikált gép. Nem ránt magával mindent egy OS frissítés.
Lehetőségek egy része:
- Saját vasat fenntartani, azon virtualizálni.
- Valami jobb helyen gépeket bérelni pár ezer Ft-ért és tartani tarcsiban is párat.
- Ügyfél gépén megoldani.
- Ügyfél által bérelt gépen megoldani :)

Én SZVSZ a bérelt infrastruktúrán szeretem megoldani, mert nem nekem kell a VM-eket kezelni, fizikai vasat alátenni és érteni hozzá (ezért vagyok software-es). De be tudok lépni ügyfél VM-jére távolról, hogy ha valami baj van, kérdése van, stb. És gépet is tudok neki adni pár óra alatt a tarcsi gépekből...

Bevallom parázok attól, hogy valaki aki figyelmetlenebb, mint én dolgozik és ártani fog nekem, mindezt nemtörődömségből vagy figyelmetlenségből. Azt gondolom ez reális mert, ha annyira "fasza gyerek", megfontolt és céltudatos lenne, mint én, akkor nem egy hosting cégnél hallgatná a ventilátorokat. :) Továbbá én csak akkor kezdek hozzá kritikus dolgokhoz, ha érzem, hogy szellemi teljesítőképességem csúcsán vagyok és nem pedig parancsra. Na ez ami nem mindegy.

Számold ki, hogy a VM-eid mennyibe kerülnének havi szinten bérelt VPS esetén, és rájössz, hogy mindkettő.
A colocation havidíját meg ki lehet termelni avval, hogy néhány VM-et az ember kiad másnak. kb. 7x-ese lenne a költség 3 év alatt.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Próbáltam még pár éve. Az a baj, hogy több cpu+mem-et adnak el, mint amennyi rendelkezésre áll. Amolyan elméleti maximumot vesz az ember, a valóság pedig a töredéke. Főleg IO-ban. VPS piac tele van wannabe vállalkozóval. Nem vagyok rájuk kíváncsi. A nagyokat nem próbáltam még.

Ezért szép a virtualizáció :) Ezért kell eladni, és nem venni.
De amúgy gondolj bele: XY-nak kell egy webszerver, amin vannak alacsony látogatottságú oldalak (100-200/nap/site). Adsz neki 2 CPU-t, 2GB RAM-ot, 200GB disket, és azt látod, hogy a CPU ritkán megy 5% fölé, a RAM zömében 1-1,2GB-on áll, az oldalak pikk-pakk jönnek/mennek, mindenki boldog. Naná, hogy más is használhatja azt az erőforrást, amit XY éppen nem használ. És miért ne tenné?
--
PtY - www.onlinedemo.hu, www.westeros.hu

Többnyire magammal osztom meg, de van, akinek csak tárterületet adok, van, akinek VPS-t is. De nem dedikálok semmit.
Az sem mindegy, mennyiért adod. Szerintem van az a költség, ahol elfogadható, hogy nem dedikáltan kapod az erőforrást, és van az, ahol nem etikus.
Ahogy az árakat elnézem itt-ott, bőven megéri az ügyfeleimnek - akik ráadásul személyes ismerősök. Másnak, aki csak úgy bekopog, nem szívesen adok VPS-t vagy bármit.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Ez tipikus honi probléma; mondjuk tényleg amilyen emberekkel itthon szerződni lehet, nem csoda hogy előjön ez a bizalom kérdése. Ami szoftvert mi árulunk - nyugaton nagyon sok vevőnek jó a felhős, de itthon hallani se akarnak róla, mindenki üzemelteti a saját kis szervereit. De még az adatbázis-szerverüket se tudják rendesen belőni, abban is segíteni kell. Ezek után biztos csinálnak biztonsági mentéseket... :)

Ez a probléma valós. Több, mint 15 éve van szerverem hosting cégnél és hidd el, sok kirohadt alólam (nem szerver). Már ez is elég probléma volt, nem kell még ez köbölni wannabe tehetségekkel vagy olyanokkal, akik nem is gondolják komolyan azt amit csinálnak és számukra nem hivatás, hanem egy snapshot az egyik napjukról.

Van saját felhőm, mert trendi :)
Saját infrastruktúrán.
Nem használok gmail-t, nincs dropboxom, ellenben van saját levelezőrendszerem, és saját owncloudom. Biztos én romtok el valamit :)
És igen, fotóztam le céges dolgokat telefonnal (olyat, ami nem tilos - pl. rackszekrény kiépítést) és azok már nincsenek a telefonomon.

Szóval izé...

--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem a szolgáltatói oldalra gondoltam, és nem az IT-s vénádra vonatkozott a dolog. Azokra a cégekre, akik a felhőt nem szeretik:
- Felhő = valahol van, mindenki látja
- Meghal a net, nem érem el.

Közben pedig:
- Dedikált VM-en van, fix IP-vel és IP szűréssel rajta kívül senki nem lát bele, de a fejlesztő cég tud deployolni.
- Nem hal meg a net! (!!!). Rendes cégnek van backup megoldása, bérelt vonal, végső esetben mobilnet. Az internet annyira a mindennapok része lett, hogy nem állhat le (telefon sem menne, jobb helyeken be sem tudnak lépni a kártyáikkal) és nem is áll le. Max faluvégén...

Nem API-t szeretnék. Saját hosztolt DB-t és alkalmazást.
Amúgy furcsállom, hogy miért jelent problémát egy gyártónak, ha valaki saját szervert akar?
Ha a kódot félti, akkor hülye.
Csomó egyedileg fejlesztett app van, amit X-Y-Z cég a saját rendszerén használ. Senki nem nyúlja le, nem nyúl bele. Miért lenne ez másképp egy egyszerű számlázórendszerrel?
--
PtY - www.onlinedemo.hu, www.westeros.hu

Igen, a szamlaagent az API.
Nagyon szépen, stabilan és kultúráltan működik évek óta. Eddig bárkinek javasoltam, mindenki csak jókat mondott róla. Határozottan érdemes alapozni rá, ha erre van szükséged.

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Ez lenne a legkisebb baj...
Így vigyázunk biztonságodra
Hát megnéztem, hogy hogyan (csak két idézet a login oldal HTTP response headeréből)...

  • Apache/2.2.22 (Debian)
  • PHP/5.5.27-1~dotdeb+7.1

Na ez az egyik ok, amiért magam szeretném hosztolni...
A többi ok itt van (Qualys SSL riport):
This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B ...
The server does not support Forward Secrecy with the reference browsers.
Prefix handling Not valid for "billingo.hu" CONFUSING
Chain issues Contains anchor (leküldik a chainben a root CA-t)

Hogy nincs HSTS/OCSP/PKP sem, alapjaiban még nem is lenne baj... De...

A termék ettől még lehet jó, de ők az én biztonságomra nem vigyáznak, és ezen az extended verified cert sem segít... Ha jól beállított szerveren szutyok class 1 cert lenne, még az is sokkal többet érne IMHO.

Az oldalukon nem látom, hogy lenne saját szerveres verzió... Az API nem az! Az API vicc.

De azért megkérdezem.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Nemwebes de platformfüggetlen nem játszik?
Tsiztában vagyok a hátulütőkkel, csak kérdezem.

Ha veletlenul talalnal egyet, akkor megpingelsz?

En az easyinvoice-ot hasznaltam, de sose jutottam el odaig, hogy betegyem virtualis gepbe es emulaljam az X-et, meg egeret.

---
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....

KATA-s vállalkozásnál? Évi 30-50 számlánál? LOL
Hol éri meg (a kényelmet és mindent beleszámítva), hogy egy számla kibocsátása 1200-2000 HUF költséggel menjen?
Szerintem - ha a folyamatos szoftverkövetést is beleszámolom éves szinten, akkor a kb. 500 HUF/számla kellene, hogy legyen a plafon.

Ha szoftverkövetés is kell, akkor az még havi 5k. Avval már 120/év lenne, 8*annyi, mint a jelenlegi.

Értem én, hogy mindent tud, meg is éri az árát - csak nem nekem. Mert amire nekem kell, arra túl sok. Pedig tény, hogy az app teljesen rendben van, és marha jó - de nem arra, amire én használnám. :(

Ha lehet javaslatom a fejlesztőnek, tegye modulárissá, és csak avval a modullal szállítsa, amit az ügyfél kér. Mindenképp rugalmasabb lenne az árképzés.

--
PtY - www.onlinedemo.hu, www.westeros.hu

Mindig nálam a mobilom, minek a számlatömb?
Egy online rendszerben nem rontasz el semmit (főleg számszaki hibára, elírásra gondolok), nem kell emiatt stornózni, újat írni.
Ha mégis lemered róla valami, amit az ügyfél hiányol, akkor egy kattintással storno, a régiből új számla generál, javít, ment.
Az egész nincs 30mp.
Számlatömbbel szarakodni, az múlt századi dolog.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Nah elkezdtem egy csak számlázót írni. (illetve meglévő modulokból összecsiszolni)
Amit tud (majd)
Partner
Cikktörzs (egy árral)
Számla kiállítás
Számla kiegyenlítés
Kimutatás (összes számla, kiegyenlítetlen, tartozások)
Export
Nem lesz benne:
Ajánlat, rendelés, bejövő bizonlyat, könyvelés, tárgyi eszköz, szabadság meg az összes olyan ami nem szigorúan egy számla kiállításához kell.

Web+sql

Várhatóan 1-1,5 hét és lehet tesztelni.

pch
--
http://www.buster.hu "A" számlázó
--

Melyikről?
Amit most írok abból már csak a kimutatás van hátra. Valószínűleg a hétvégére kész is lesz.
Vagy ami már megvan?
Abból lehetne sorozatot csinálni mert elég összetett. Elég csak azt megemlíteni, hogy a termékeknek az ára időarányos és jöhet három helyről is. (direkt beírva, szerződésből, származtatva).
Lehet készítek egy videosorozatot. Nem rossz ötlet.

pch
--
http://www.buster.hu "A" számlázó
--

Az ára még csak-csak, de a tudása túl sok.
Számomra nem az a fontos, hogy mennyit tud, és ahhoz képest mennyibe kerül, hanem az, hogy milyen arányban tudom kihasználni amit tud, és az megér-e nekem annyit.
Egy példa.
Ha havonta 100km-t autózok a boltig meg vissza, akkor értem én, hogy 4M HUF-ért nagyon megéri egy vadiúj, fullextrás Ferrari, de ha valaki 200e HUF-ért kínál egy 10 éves Matiz-t, akkor ez utóbbit fogom megvenni még akkor is, ha van elég pénzem a Ferrarira :)
--
PtY - www.onlinedemo.hu, www.westeros.hu

Szerintem nem vagyok egy agresszíven nyomulós fajta, nem akartam eddig se senkire rátukmálni az eVIR-t, de miért nem teszel egy próbát vele? :) Ahogy olvasgatom ezt a témát, egyre inkább úgy látom, hogy ezt keresed :) Amit nemrég neked csináltam egyedi demó rendszert, abba felkerült a számlázó modul is, játszhatsz vele kedved szerint :)

A feltételeidet egy kivételével (azaz egészen jó arányban :D ) tudjuk teljesíteni:

  • Saját szervereken szeretném üzemeltetni (A szerveren a web, B szerveren a DB)
    Ezt tudod, hogy tudjuk teljesíteni, hiszen már fut rendszerünk a te szervereden. Műszakilag nekünk nem probléma, hogy nem egy helyen van a program és a DB, csak legyen IP kapcsolat a kettő között.
  • PHP vagy Perl legyen
    Perl-ben készül
  • MySQL adatbázis
    Ez az egy, ami nem nyert, mert Postgresql van alatta. 15 évvel ezelőtt a 7-es Postgresql mellett döntöttünk (talán a tranzakciókezelés volt az egyik legnyomósabb érv mellette), és azóta is jó döntésnek tűnik :)
  • Ne legyen benne Flash
    Nincs benne flash. Sőt, egyéb grafikus cucc se sok, valamint funkcionalitást befolyásoló javascript sincs, ezért kifejezetten jól és teljes értékűen működik akár w3m/liks/lynx alatt is :D (bár nem gondolom, hogy rajtam kívül túl sokan használnák screen-ben, karakteres konzolon)
  • Tudjon generálni PDF számlát
    Tud.
  • Lehessen a számlára egyedi elemeket tenni (logó, aláírás, stb)
    logót lehet, aláírást nem (és mivel ezer éve nem kötelező sem aláírni, sem pecsételni a számlát, ezért a számlaképről akár le is hagyható az aláírás helye is)
  • Minden olyan feature-t tudjon, ami egy KATA-s vállalkozáshoz kell(het)
    Ami úgy van definiálva, hogy "minden" az ingoványos terület, de vannak KATA-s ügyfeleink és használják probléma nélkül.
  • 2016-os adótörvény kompatibilitás - NAV adatszolgáltatás
    Van benne ilyen. Év végéig még tovább csiszolgatjuk olyan ütemben, ahogy csöpög az információ róla :)
  • Évi 30-50 számla kiállítása
    Nincs limit a kiállított számla mennyiségére vonatkozóan sem.

    Szó volt másik rendszer kapcsán a modulszerű felépítésről: az eVIR modulokból áll, azokból összeválogatva áll össze a rendszer funkcionalitása, ezért nem látható mindig minden rendszerben az oda nem kellő tömkelege.

    Felmerült az ár kérdés is: ha csak szolgáltatások számlázására használod (azaz nincsenek a készletnyilvántartás, logisztika, stb. modulok telepítve), akkor a legkisebb csomag is jó neked, aminek nettó 900 Ft / hó az előfizetési díja. Ha nem a felületről akarod használni, akkor akár már ez a verziót is ki lehet úgy alakítani, hogy mondjuk egyetlen https hívással mondjuk a JSON adatszerkezetben átadott adatokból készült PDF számla eredeti példányát a rendszer elküldje automatikusan a vevő email címére :)

    Mi szól ellene a Mysql kivételével? :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

  • Megfordult a fejemben, de el is vetettem.
    MySQL szerverem van. Csak emiatt az egy rendszer miatt, amit átlagosan 8-10 naponta használok, tegyek fel egy Postgres-t?
    Nem akarok :)
    Nem tudom, milyen konnektort használtok, ha DBD-t abban (n|s)em nagy művészet átírni a DB URI-t. Az alap DB dump konvertálható A-ból B-be, oda vissza.
    Ha standard SQL query-ket használtok, és nincs tárolt eljárás, akkor akár MySQL alá is bevarázsolható.

    Azaz csak a mysql szól ellene :(
    A raktárkezelőt amúgy szeretik, de még bénáznak vele. Ahogy elnézegettem, teljesen jó - biztos vagyok benne, hogy a számlázó része is rendben van. De Postgres-t nem akarok :)

    Ha esetleg lesz olyan igény valamelyik ügyfelem részéről, aki az én infrastruktúrámon postgres-t használna, és telepítenem kell emiatt egy VM-et, és nem találtam még meg a megfelelő rendszert, mindenképp szólok! Még van cirka 6 hónapom :)

    --
    PtY - www.onlinedemo.hu, www.westeros.hu

    Nem lehet olyan könnyen kicserélni alatta a db engine-t. Pont azért használunk Postgresql-t, mert tele van mindenféle tárolt eljárással, tranzakciókezeléssel, triggerekkel, stb. különféle postgres specifikus függvényekkel, azaz kihasználjuk a benne rejlő lehetőségeket.
    Nincs egyetlen "select * from" kezdetű query a rendszerben :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Bocs, de ez _szerintem_ mar a boszmeseg kategoriaja. Ami terhelest egy szamlazorendszer generalni tud, az nagyjabol a semmivel egyenerteku, ha nem tizezren hasznaljak egyszerre. Semmibe se kerulne neked egy apt-get install postgresql a mostani DB szerveredre, es nem venned eszre a terhelesnovekedest, mert az ido 90%-aban idle lenne a processz. De ehelyett befeszulsz, mintha valaki Windows telepitesere kenyszeritene.

    Komolyan nem ertem a dolgot. Itt van egy baromi jo rendszer, minden igenyedet kielegitene, sot, ismered is, ismered a keszito csapatot is, tippre talan nem is annyira draga, de belekotsz, hogy miert nem MySQL. Mintha abba kotnel bele, hogy miert pirosak benne a gombok. Irrelevans, lenyegtelen kerdes. Van egy MySQL szervered, oke. De attol, mert mar van egy kek tollad, meg nem kell befeszulni, hogy marpedig te nem veszel pirosat is, mert hat van egy kek!
    --
    Blog | @hron84
    Üzemeltető macik

    > hogy miert pirosak benne a gombok

    ...és még ezt is meg tudjuk változtatni, testre lehet szabni! :D Az üzleti logika és a megjelenítés teljesen elválik egymástól, külön van a Perl kód, külön a HTML template, és külön a CSS. Bárki szabadon átszínezheti benne a gombokat a kedvenc színeire anélkül, hogy a program működését befolyásolná :D
    (jól megláttam a lényeget a hozzászólásodban, ugye? :))) )
    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Igen, szolgáltatjuk a felhőből is, de lehet akár az ügyfélhez is telepítve, dedikált vason vagy virtuális szerveren, vagy akár közösködünk is másokkal (bár ez annyira nem szerencsés...)

    Persze nem a havi 3 szolgáltatás számlázása esetében szoktuk a helyi szervert javasolni, hanem a nagyobb rendszereknél, ahol sokezres nagyságrendben vannak a termékek, partnerek, stb, vagy nagyon sok bizonylatot készítenek.

    Ez elmúlt időszakban sok EU támogatott vállalatirányítási rendszeres pályázatos bevezetésünk volt országszerte, ott pedig kizárólag az ügyfél saját szerverén futó szoftver volt támogatható az EU által. Ezt maradéktalanul teljesítettük is, viszont kialakítottunk néhány olyan modulösszeállítást, amit szolgáltatásként nyújtunk saját szerverekről is.

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    ugyan nekem semmi kozom a szalhoz :) de felkeltette az erdeklodesem, mert nalam is felmerult a szamlazo szoftver csereje. amit viszont nem talalok az evir oldalan, hogy a light verzioba lehet-e importalni a szamlakat (minden adatot, vevoet es a szamla tetelek is egyszerre)? nekunk van sajat fejlesztesu projekt es keszletnyilvantartasunk, amit semmikepp nem cserelnek le, es ez generalja ki a szamlakat magabol (jelenleg dbf-be de xml vagy mas is megoldhato), amit most 2 kattintassal behuzok a szamlazoba es mar nyomtatja is.

    A'rpi

    Nagyjából igen, bármelyik verzióban.
    Van olyan megoldás, ahol egy szem JSON adatszerkezetet adsz át automatizálva https-en keresztül, és választásod szerint visszakapod vagy a PDF számlát, vagy a számlaszámot, és ha szeretnéd, akkor akár el is küldi emailben az első példányt a vevő email címére.
    Ha partnerkódot adsz meg, akkor annak készül a számla, ha partner adatokat, akkor először megnézi, hogy van-e pontosan ilyen névvel és címmel partner már az adatbázisban. Ha nincs, akkor felveszi és azt használja tovább.
    Tétel esetén viszont mivel sok más adatra is szükség van, ezért a számlázandó cikkszámnak léteznie kell a cikktörzsben.
    Mondjuk műszaki akadálya szerintem nincs annak, hogy ha nem terméket, hanem szolgáltatást kell tételként a bizonylatra tenni és minden szükséges paraméter ott van a JSON-ban, akkor létrejöhessen a törzsadatokban a szolgáltatás cikkszáma. Termék esetében macerásabb lenne, mivel negatív raktárkészletet nem enged a rendszer, ezért olyan terméket nem tudsz értékesíteni, ami nincs bevételezve korábban valamelyik raktárba...

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Negatív raktárkészletet határozottan nem enged, de van olyan, hogy "termék cikktörzsből" típusú értékesítés. Ilyenkor bármit el tudsz adni, de a rendszer várja, hogy majd később bevételezd azt a terméket is a "termék utólagos bevételezése" funkcióval. Ilyenkor az árukövetésben is helyreáll a dolog, pl. a később bevételezett gyáriszámos termék a korábban kiállított számla tételhez fog tartozni. Természetesen bármikor lekérdezhető, hogy még milyen olyan termékek vannak, amihez még nem érkezett be a szállítói számla és/vagy szállítólevél. De ez a funkció néhány helyen túlbonyolítja a dolgokat, ezért globálisan kikapcsolható. Ezen felül van a hagyományos bizományba adás és vétel is, azzal is megoldhatóak a hasonló feladatok. :)
    Komplett folyamatot kezel, ajánlatból vevői rendelés, amiből szállítói rendelés, abból bevételezés szállítólevéllel, abból bevételezés számlával, amiből kiadás szállítólevélel amiből számla készülhet. Persze nem minden lépés kötelező :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Mi van akkor, ha a cég gyártással, vagy összeszereléssel foglalkozik.
    Semmi olyan nem megy ki soha a számlán, ami a bevételezéskor bejött.
    Pl. veszek alaplapot, procit, ramot, ssd-t, optikát, szoftvereket és eladok egy számítógépet, meg a szoftvereket.
    Vagy veszek üvegtáblát, aluminium lécet, ragasztót, műanyag profilt, acél profilt és nyílászárókat adok el.
    Ezt hogyan lehet megoldani?

    Van egy gyártás modul (amit én inkább összeszerelésnek neveznék), ami akár egyedileg, akár receptek alapján tömegesen is meg tudja csinálni, hogy a raktárban levő cikkszámokból egy másik cikkszámot állít elő és helyezi raktárra. Természetesen a felhasznált mennyiségeket leveszi készletről, az elkészülteket meg készletre veszi, és igyekszik a felhasznált termékek beszerzési árai alapján a gyártott termék beszerzési árát is helyesen meghatározni. Mondjuk gép alkatrészek esetén szerintem annyira nem nyerő, mert ott a különböző alkatrészek gyári száma fontos lehet, és összeszerelést követően ezek a gyári számok már nem tartoznak közvetlenül a számlához, ezért garanciális keresésnél egy lépessel több megkeresni őket. Inkább olyankor jobb, ha csomagokat állítunk elő, vagy szétbontunk-összeszerelünk darabos-kartonos-raklapos kiszerelésű cuccokat.
    Azért nem szeretem gyártásnak hívni, mert nem kapcsolódik hozzá olyan erőforrás kezelés, ami bármilyen gyártás támogatási rendszernél alapvető. De mivel a rendszert alapvetően nem gyártó, hanem kereskedelmi-szolgáltató cégek részére készítjük, ez nem szokott problémát jelenteni.

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    az eleje meg jol hangzik, de a vege nagyon nem. en nem akarok meg egy rendszerbe felvinni mindent, masreszt nalunk is van olyan, hogy mas az input mint az output (alkatreszeket, anyagokat veszunk es gepeket stb adunk el).

    nekem tenyleg csak az kell, hogy valami adatszerkezetbe atadom mi keruljon a szamlara (nem csak szolgaltatas, termek is van, sot a 2 keverve is) es azt okoskodas nelkul kiszamlazza (pdf is jo) a cucc. a raktarhoz semmi koze. es mindezt nem horror penzert
    (neztem a szamlazz.hu-t is, de az alapdijon felul a havi +1500ft api-dij sok kb havi 10-15 szamla kinyomasaert)

    lassan ott tartok hogy erdemes lenne lefejlesztetni egy ilyet es arulni, igeny szerintem igencsak lenne ra, de senki se arul ilyet.

    A'rpi

    Ha neked egyáltalán nincs szükséged készletkezelésre, akkor szolgáltatásként kell mindent számláznod, és már meg is van oldva :) Ez csak a belső nyilvántartás módját befolyásolja, de attól még lehet a tétel megnevezése bármilyen terméknév, mert szolgáltatás jellegű cikkszámként van rögzítve :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Ugyanabban a cipoben vagyunk. Te eddig melyik szamlazot hasznaltad?
    Nekem az easyinvoice tudta ezt (.xml-t be, pdf-et adott ki).

    Csak ugye az gui-s volt, igy programhoz alig lehet illeszteni (mondjuk azt a havi par szamlat kezzel is be tudom huzni).

    Valoszinu maradok annal, de ha lenne egy command line only szamlazo, akkor atternek arra.
    Az ara se volt horror ugy emlekszem, hogy 12+Afa volt es lehuzott 2 evet nalam, igy vegulis evi 6eFt-ra jott ki.

    Gondolkodok a kezi szamlazasra visszateresre, csakhat nemkicsit gaz kulfoldi partnereknek kezi szamlat kuldeni...

    ---
    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....

    Küldtem neked üzenetben konkrét kipróbálható, használható URL-eket, amelyekben egy megfelelően felparaméterezett JSON szerkezet található. Ezekkel vagy megkapod a számlát PDF-ben, vagy elküldi a partner email címére.

    Ha van kedved, próbáld ki :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Igazad van, nem kell rá sem aláírás, de semmi nem is tiltja meg a használatát, ha szeretné. Akár kicsi virágokat is rajzolhat rá :)

    Azért van több olyan eset is, amikor jól jön az aláírás a bizonylaton: pl. ha az áru átadását-átvételét igazolja.

    De olyan is van, amikor csak egyszerűbb inkább aláírni, mint nekiállni meggyőzni a túloldalt, hogy márpedig fogadja be aláírás nélkül. :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Én pl a múltkor érdeklődtem az egyik megrendelőnél, hogy kábé mikorra tervezi a számlám kifizetését.
    Azt válaszolták, hogy azért nem fizettek még mert a könyvelőjüknek aláírt, pecsétes számla kell.
    De hát rá van írva, hogy aláírás, pecsét nélkül is érvényes... (mondtam félszegen) de ha ragaszkodnak hozzá (és pénzt is akarok), akkor küldök olyat.

    --
    [ Falu.me | Tárhely | A Linux és én ]

    Ugyan ilyen konfliktusforrás dolog szokott lenni a példányszámozás is :)
    2010-ig kellett számozgatni a példányokat, utána pár hónapig pedig csak az eredetit és a másolatot megkülönböztetni, de azt a paragrafust is hatályon kívül helyezték, majd 2014-ben az egész korábbi rendeletet is. Azaz már kb. 5 éve nem kötelező, de mégis még ma is sokan hiányolják, ha nincs rajta a számlán... Pont úgy van, ahogy a hivatkozott blogpostban szerepel... :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Sokan azért nem teszik ezt, mert nem akarják elveszíteni az ügyfelet. Azért valld be őszintén, te sem szívesen rendelnél meg bármit is attól, aki már egyszer végrehajtást kért ellened :)

    Ennél sokkal barátságosabb és humánusabb megoldás az, amit mi is csinálunk és ügyfeleinknél is be szoktuk állítani: a program noszogatja őket automatikusan, emailben :) Kb. a következő séma szerint szoktuk megcsinálni:
    -a fizetési határidő előtti 2 nappal egy emlékeztető mail, hogy 2 nap múlva lejáró számlája van
    -a fizetési határidő utáni napon egy udvarias "bizonyára elkerülte figyelmét..." mail
    -utána kb. 3 naponta egyre szigorúbb fizetési felszólítás a kb. 30. napig
    -végül egy "behajtás előtti utolsó fizetési felszólítás", ami után aztán már tényleg mehet az ügyvéd/végrehajtó.
    -a fentiektől függetlenül hetente egyszer egy "pénzügyi összefoglaló" mail, ami nem felszólítás, viszont tartalmazza az ügyfél összes pénzügyileg rendezetlen számláját.

    Persze beállítható partnerenként, hogy kapja vagy ne kapja, és aki kapja, az az információs leveleket és/vagy a felszólításokat kapja.

    Ha valaki fizetni akar, akkor erre azért már szokott. Vagy ha van oka, hogy miért nem, akkor tud reagálni a levelekre, és kiderül az indok. Mindenesetre azt nem mondhatja, hogy nem szóltunk, mert mire ügyvédhez kerül a dolog, addigra vagy 10 levelet biztosan kapott... :)

    A címzettek nagyon kis része szokta csak kérni, hogy ne kapjon információkat, de ezek nem is szoktak tartozni, mert normális nyilvántartásuk van. A többiek meg örülni szoktak az emlékeztetőnek :)

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Szerintem nem is küldünk nektek soha egyetlen előzetes emlékeztetőt sem, vagy rosszul emlékeznék? :)

    Pont ezért van lehetőség partner szinten beállítani, hogy mit küldjön a rendszer automatikusan. Átlagosan úgy 5% körül lehet azoknak az aránya, akik egyszer már kapták és többet nem kérik. Amikor el kezdtük ezt csinálni a különböző rendszereken, akkor legalább 50%-ra tippeltem azokat, akik nem fogják kérni az értesítést, de tévedtem.

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    > Szerintem nem is küldünk nektek soha egyetlen előzetes emlékeztetőt sem, vagy rosszul emlékeznék? :)

    Altalanossagban irtam, h nem biztos, h az nem bosziti az ugyfelet.

    > Pont ezért van lehetőség partner szinten beállítani, hogy mit küldjön a rendszer automatikusan.

    Amugy persze, a mi esetunkben is igy jart el a partner.

    Egészen addig, ameddig valaki egyszer nem kezdi el érvényesíteni velük szemben a számlánként 40 EUR behajtási költségátalányt meg a késedelmi kamatot :) Onnantól kezdve már más a leányzó fekvése :)
    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    ha a 40 eur behajtasi kotlsegatalanyt nem ervenyesitik a kesokon, akkor a nav ha akarja, meg tudja szivatni.
    ugyanis elo van irva hogy 40 eur behajtasi koltsegatalanyt kell alkalmazni.
    namarmost olyan logika alapjan jatsszik a nav, hogy mivel ez elo van irva, ennyivel kellene noni a bevetelnek, abbol kovetkezoen a nyeresegnek, abbol kovetkezoen a tarsasagi adonak es az ipa -nak is.
    es buntet az elmaradas miatt...

    kiveve pesze ha ott a mindket fel altal alairt lemondo nyilatkozat a 40 eur behajtasi koltsegatalany ugyeben.

    Persze ehhez az kell, hogy ezek a cégek a saját pénzükből vállalkozzanak, amit sokan kifelejtenek a sztoriból.

    ps.: tegnap pont megkaptam, hogy nem rugalmas a cégem, mert az egyik ügyfél 2m-es tartozás miatt nem kap árut. Beszarok (nem elég, hogy tartozik még kioktat és feltart), amúgy szerintem meg ő nem rugalmas, mert nem bír szerezni két millát. :P

    mi meg vevobiztositast kotunk minden vevore es 30-60 napra adjuk a termekeket aztan befaktoraljuk a szamlakat, igy kb. azonnal nalunk landol a 90%-a a 30-60 napos szamlaknak.
    ha meg nem fizet, majd a bank es a hitelbiztosito kombo kisajtolja belole, ha sehogy se sikerul es fel kell szamoltatni, akkor kis kesessel ugyan, de a maradek 10%-bol meg 7%-ot megkapunk. 3% az onresz.
    (hozzateszem, ilyenre meg nem votl pelda, ha valaki kesve is, de rendezte mindig a szamlat. 15-20 nap turelmi idovel a bank es a biztosito is szamol.)

    magyarorszagon sok a rosszul vagy nem fizeto partner, ezert mar csak olyannal allunk szoba akire kapunk keretet valamelyik biztositotol.

    az esetleges felszolitasok, stb. megy manualisan megy.

    nem kell itt idegeskedni a nemfizetokon.

    regebben, mielott ezt a svajci modellt bevezettuk, nalunk is katasztrofa volt a cash-flow, a munka nagy reszet a penzbehajtas vette el, a kulombozo penzbehajtasi modszerek kidolgozasa, uzemeltetese, a cash-flow sakkozgatasa naprol-napra a be nem erkezo, es ezert azt felborito penzek miatt, stb. stb.

    annyit azert adok tippnek, hogy a kozjegyzoi fizetesi meghagyas tulhaladott dolog, eleg, ha annyit visszair az ados, hogy "Vitatom.", es maris perre alakul a dolog, ahol felmerul az ugyvedi dij, a perkoltseg elolegezese a birosag fele, atb.stb.
    ennel egyszerubb, olcsobb, hatekonyabb a felszamolasi eljaras inditasa. ott nincs mese, egyszer kaphat 45 nap haladekot, hogy rendezze a szamlat, ha nem tudja igazolni, akkor megindul a felszamolas.

    Ez nagyon durva költség.

    Egyszerűség kedvéért:
    10M évi forgalom megy így el, ami legyen egyenlő havi arányban 833e/hó

    Ha 60 napra fizetnek neked, akkor egyszeri 2x833e-re fizetsz 10M-nek a kamatát, ami brutális. Ha pénzed van, akkor csak álmodsz ekkora hozamról. Faktoráltatni annak kell, aki elköltötte a következő "n" napját. Egyszer kell csak meghúznia szíjat és aztán jobban élni.

    ps.: nálam nagyon jó a fizetési morál, csak olykor van egy-két ember aki még nem ismer (minket)

    ennek azert nezz utana.
    nem vagyok a dologban biztos, de ugy tudom, hogy ilyen sezrvezetek, mint pl. bankok, telekom szolgaltaok, es egyeb nagy tomegu szamlazok allithatnak ki hitelesen alairas es pecset nelkul szamlat. azt hiszem, azzal van osszefuggesben, hogy un. "folyamatos" szamlazas tortenik.
    lehet, hogy elavultak az ismereteim, csak 50%-ban vagyok ebben biztos.

    A számla kötelező adattartalmára vonatkozó előírásokat az ÁFA törvény 169. paragrafusa sorolja fel, ezek között nem szerepel sem az aláírás, sem a pecsét.

    ÁFA törvény: http://net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=A0700127.TV

    A "folyamatos számlázás" is már régen a múlté :) Amit leánykori nevén "folyamatos teljesítés"-nek hívtak, azt most már "időszaki elszámolású ügyletek" néven kell keresni :) Éppen januártól van ezek elszámolása kapcsán újra néhány változás...

    --
    http://eVIR.hu
    Elektronikus Vállalatirányítási Információs Rendszer

    Nem perl és nem php, de qt. A PergerSoft QtSmartStorage programja jó lehet. Az adatbázis lehet mysql,pgsql vagy lite. Ha az adatbázist a szerveredre rakod, és a biztonságos elérését megoldod, akkor a programot csak be kell állítani hogy onnan használja. Nálam egy Nas-ról megy az egész, ami otthon csücsül, vpn-el elérve,nfs-el mountolva. Nálad nyilván nem kell mountolni, csak csatlakozni a db-hez.

    --
    RGeri77
    Fedora Ambassador, játékmester ;-)