Számlázóprogram (szerver linux, kliens windows is)

Iroda

Sziasztok!

Vállalkozásunk legkésőbb 2008.01.01. napjától számlázóprogram váltásra kényszerül és ehhez keresünk megfelelő szoftvert. A http://ugyviteliszoftver.lap.hu/ oldalon nézelődtem és google-t is kérdeztem, de még nincs meg az igazi :(

Követelmények:

  1. Adatainkat lokálisan szeretnénk tárolni, ezért a szamlazz.hu jellegű ajánlatok _számunkra_ nem megfelelőek.
  2. Hálózati működés, ahol a szerver az linux (lehetőleg Debian Etch) a kliensek pedig windows xp-k, illetve linuxos gépek. A linuxos gépeken elég egy ncurses felület is. Sőt egy ssh-val a szerveroldalra történő belépést követően is elég az ncurses felület, így ha csak ez kivitelezhető nincs is szükség windows-os kliensekre.
  3. Nincs szükség készletnyilvántartásra, cégeink szolgáltató tevékenységet folytatnak.
  4. A programnak több céget és cégenként több számlatömböt kell kezelnie (egy cégnél lehet több devizanemű számla és alkalmazhat több számlasorszám formátumot is.)
  5. Egy cégen belül több bankszámlaszám kezelése
  6. Átutalásos, készpénzes, stornószámla, előlegbekérő készítése
  7. Partner és számlatétel tárolása (kvázi partner és cikktörzs)
  8. Kintlévőségek kezelése (átutalásos számlák akár több részletben történő kiegyenlítésének lehetősége) és listázhatósága
  9. ÁFA analitika készítése
  10. Rugalmas ÁFA kulcs kezelés (pl. még most is kell alkalmaznunk 25%-os ÁFA kulcsot)
  11. Munkaszámok használata és ezek alapján listák készítése (számlarögzítést követően munkaszám változtatása)
  12. Előre rögzített, illetve számlakészítéskor egyéb szöveg felvitele a számlára
  13. Kötegelt feldogozás lehetősége pl. egy csv file-ból
  14. A partnertörzs alapján boríték készítése

Tehát csak számlázás és azok kiegyenlítsének nyomonkövetése a lényeg, semminemű készletkezelés nem kell.

Jelenleg 34 vállalkozás számlázására kellene, de

  • van olyan cég aki egész évben egyetlen számlát készít
  • az aktív cégek száma, aki havonta legalább 1 számlát készít az kb. 8 cég
  • a legaktívabb cég is csak 1000 db körüli számlát állít ki évente

miatt egyedi ár kellene, a cégenkénti fix többtízezer fentiek miatt nem játszik.

A jelenlegi program használatért - mely DOS alapú, nem hálózatos és a kötegelt feldolgozás is hiányzik belőle - évente kb. bruttó 150eHUF-ot fizetünk, így ehhez képest a milliós nagyságrendet nem hiszem, hogy tudnám a vezetőség felé képviselni.

Fenti feltételek alapján tud valaki ajánlani valamit?

Amiket én láttam, azok között sok elbonyolított a készlet és raktárkezelés miatt és az "egerészős" gui messze nem olyan hatékony, mint a billentyűzetről vezérelt öreg DOS-os programok. Persze ha a kötegelt feldolgozás megy akkor a havi fix számlák melletti 10-20 számlát már összekattogtatunk ;) .

Javaslataitokat, segítségetek előre is köszönöm!

Bye, Fifi

  • 8461 megtekintés

PHP-ban van írva... Tehát ha kell majd valakinek, vigye, és használja, ahol akarja... Viszont akkor nem lesz rá olyan support, mint azon, ami nálam van hosztolva. Végülis minden verziószám "végleges" változat. Mi már 2 éve használjuk. Tehát élesben futó rendszerről van szó.
Lévén, hogy script, nem lehet garantálni semmit. (Bárki belegányolhat, stb...)
--
Coding for fun. ;)

( hop1 v | 2007. 11. 13., k – 13:27 )

A fenti dátumtól én is saját fejlesztésű számlázóval indulok, decemberben testing módban már használni szeretném.
Aztán kikerül valahová, open source lesz.
A fenti kritériumoknak megfelel, sőt +.
De a január 1-ei indulást még nem ajánlom másnak nyugodt szívvel. :)

Még nincs olyan állapotban, hogy kipakoljam, még 2-4 hét.
Nagyjábol amit tud (majd):
-Korlátlan számú cég kezelése
-Korlátlan számú telephely
-több költséghely
-több pénztár
-cégenként korlátlan számú bankszámla
-project kezelés
-saját bizonylattipusok(egyedi nyomtatási képpel, egyenlőre xml-ben szerkeszthető)
-pénz ill. készletmozgás bizonylatonként illetve cikkenként állítható
-cikktörzs cikk kategóriákkal
-raktár
-címjegyzék

elég rugalmasan kezelhető, tehát nem kötelező raktárat, költségehelyeket, stb. használni. A cikktörzset célszerűnek tartom feltölteni.

( dii | 2007. 11. 13., k – 13:46 )

Helló!

Mindenben tudnék segíteni, de sajnos a határidő pont nem jó :(((
Konkrétan: Qt-ban, SQL-re most tesztelődik/csiszolódik/fejlődik céges környezetben számlázó program. Mivel Qt, ezért elfut mindenen, linux, win, stb. Mondjuk ebben van raktárkezelés is, de az talán mindegy. Persze egy-két speciális dolog hiányzik (több bankszámlaszám?, ez meglep), de természetesen minden személyes igényt be lehet ültetni.
Márciusra tudnék prezentálni valamit ebből, elöbb semmi képpen nem fog menni, sorry.

Egyépként GPL meg opensource az egész, itt a HUP-on fogsz értesülni a publikálásról ha minden jól megy.

Erről mindenképpen írjál majd hírt plz. Ha billentyűzetről könnyedén vezérelhető lesz minden funkciója és átlátható felületet csinálsz hozzá, egy megfelelő :) éves előfizetési díjjal mindenképpen érdekelne a dolog. Kicsit unom már, hogy csak a számlázóprogram miatt kell egy Qemu-WinXP párost tartani a gépemen. :I

Egyébként ha elfogadsz egy tanácsot és nem tartasz vele pofátlannak: az SQL modult IMHO írd meg modulárisra. Nagyobb cégeknél, több klienssel így lehet mögé pl. Postgrest rakni, míg kis cégeknél, ahol csak egy-egy példányban futna, elzötyöghetne SQLite-tal. Ez utóbbi neked is könnyebbséget jelent, mert ilyenkor ugye nem kell külön adatbáziskezelőt telepíteni és konfigurálni.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Alapfeltétel, hogy egér érintése nélkül dolgozni lehessen benne (és nem a gyors billentyüket bogarászni). SQL bármi lehet, ami tranzakciót és inner join-t lekezeli. Mondjuk az SQLite nem tudom ezt tudja-e, majd megnézem. Mondjuk a tranzakció kezelés hiánya nem dob hibát... marad az inner join. Azt viszont feltétlenül használni fogom. Gondoltam rá, hogy majd legyen egy ilyen lightweigth verzió is, de ez most nem élvez prioritást.

Továbbá: az a szegény aki ígérni sem tud :) A progi GPL lesz, ingyen vihetö. Talán elég színvonalas ahhoz, hogy ne kelljen állandóan feltalálni a spanyol viaszt. Mondjuk lehet, hogy egy nap a számlázó programukból élö hobbyprogramozók ezért felgyújtanak :) Persze supportot, felelöség nyilatkozatot (lásd lejebb), stb majd lehet venni, de mivel a fejlesztést nekem kifizeti az a cég akinek csinálom (az is inkább barátságból), nagy kaszálást nem tervezek.

( pch v | 2007. 11. 13., k – 14:40 )

Nekünk is van egyedi számlázó progi. Linux alatt saját igényre irva php-ba.
Viszont felét se tudja amit kértél.
Ami viszont eszembe jutott:
Van vagy 3-4 számlázó progi ezekszerint ami akár lehetne gpl. Nem kellene összefogni és csinálni egy teljes ügyviteli rendszert?
Supportal akár pénz is lehetne keresni..

pch

Voltak rá kísérletek, de mind csírájában meghalt. Ráadásul mindenki PHP-ben webben gondolkozik. Nem mondom hogy rossz, de mondjuk egyfelhasználós rendszerben még minimum 2 szervert futtatni luxus (szerintem).
Nekünk szükségünk van rá, a meglévőknek mindnek voltak olyan hiányosságai, ami miatt nem tettszett, így nekiálltam egynek. Ha olyan szintre ér, mikor publikálható, ez meg fog történni, és mindenki tehet javaslatokat, ill saját kénye kedve szerint módosíthatja. :)

Olyan szempontból ez nem rossz, hogy valóban platformfüggetlen, de aki már kicsit is dolgozott billentyűzetről teljeskörűen vezérelhető számlázóprogrammal, az a pokolba kívánja az ilyen kattintgatós felületeket. Lassabbak és sokkal nagyobb a hibalehetőség.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Nem az a gond, hogy mennyire tudod vezérelni, hanem, hogy hogyan tud reagálni rá.
Pl. a számlára kerülö árú kiválasztása úgy az igazi, hogy beütöd az elsö betüket és kijön egy lista a mezö alatt, a választható cuccoknak. Ezt webes felületre megoldani nem kis feladat (bár lehetséges). Egy pörgös boltban nem biztos hogy belefér az idöbe a weboldalas kényelmetlenség.

Egyébként ettöl a eltekintve nagyon tisztességes munkák ezek a rendszerek is, gratuláció a kivitelezéshez.

( royal v | 2007. 11. 13., k – 15:21 )

A valtozatossag kedveert nekunk is van egy, ezt is ki lehet probalni, hatha megtetszik :) Ugyan sokkal tobbet tud, de a modulos felepites miatt a szamodra felesleges dolgok (pl. raktarkeszlet kezeles) nyom nelkul kiirthatoak belole. Ez perl+postgresql alapu... :)

Demo itt: http://demo.royalcomputer.hu
Marketing: itt

Huh, ez szép munka és kellemes design.
Még az sw oldal is kedvemre való (debian és postgresql).

Rengeteg funkció van benne, de első blikkre ezeket nem találtam, ami fontos lenne:
- Több cég számlázásának kezelése
- Több devizanemű számlák kiállíthatósága
- Számlázandók importja egy csv file-ból

Ezeket tudja csak én nem lelem?

Sok olyan modul es funkcio van, amelyeket nincs sok ertelme a demoba tenni, mert egyedi igenyek alapjan keszultek (pl. gumismuhely elojegyzesi rendszere, jatekbarlang vilagitas-vezerlesen alapulo szamlazas, stb.)
Tobb ceg eseteben javasolnam a cegenkent kulon URL-en torteno elerest (az mar mas lapra tartozik, hogy ez szerver oldalrol symlinkekkel kezelheto), valamint az egeszhez egy kozos nyito-oldalt, ami egy linkgyujtemeny lehetne a cegekhez.
Devizakent jelenleg EUR-t kezel a rendszer, a megadott arfolyam alapjan kepes a Ft arat atszamolni (valamint ehhez kapcsolodoan angol nyelvu kiegeszitese is letezik a szamlaformatumnak)
CSV import es export is letezik sokmindenhez, nem jelent problemat egy szemelyre szabott importalo modul elkeszitese (szerintem max 1-2 nap, ha jo a specifikacio). De akar kozvetlenul is lehet kommunikalni a progival, ahogy ezt webshopok eseteben szoktuk csinalni. Tomeges szamlazas is letezik, boritek betetlap nyomtatas is megoldott (de az osszes nyomtatvanyon ugy van pozicionalva a vevo neve, hogy megfelelo hajtassal ablakos boritekba teheto)

Ahem. :) Ki akartam volna próbálni, atlag felhasználónévvel bejelentkezve. Partnerek/Cégek/Cégek listája menüpontra egy ilyet kapok:

...itt egy méretes SQL hibaüzenet volt...

Őőőő, ez most mitől jött elő? :)

A hibaüzenetet megpróbáltam beidézni, de a HUP Apache-a 403-at mondott rá.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( hop1 v | 2007. 11. 13., k – 16:21 )

Ezért:
# Munkaszámok használata és ezek alapján listák készítése (számlarögzítést követően munkaszám változtatása)
nem hiszem, hogy vki kiállítja a felelősségvállalási nyilatkozatot, ha a munkaszám rákerül a számlára is.

Munkaszám nem kerül számlára!

Ez csak arra szolgál, hogy később analitikákat tudjunk készíteni.
Pl. Úgyanaz a tétel neve:
Bérleti díj, de a tétel rögzítésekor megadott munkaszámmal meg tudom különböztetni.
Pl. munkaszám 1 - főépület, munkaszám2 - melléképület stb.

Így hó végén meg tudom mondani, hogy mennyi bérleti díj folyt be a főépület, illetve a melléképület bérbeadásából. Ha Gizike meg elgépelte a munkaszámot, akkor az akár egy év múlva is ki kell tudnom javítani, hisz a kinyomtatott számlához semmi köze.

Erre való a cikktörzs(szolgáltatásokat is fel lehet venni, akár épületenként a bérleti díjat) ekkor gizike el sem tudja gépelni, hiszen a számlára az a tétel kerül, hogy 'bérleti díj melléképület1', ráadásul aki kapja is tudja miért fizetett. Egyébként, ha nem kerül a számlára, akkor megoldható, de számomra ez a verzió tisztább, és használhatsz raktár modult, akkor onnan mindenféle ilyen jellegű analitikát el tudsz készíteni.

Szerintem ez a munkaszámos dolog azért jó:
- mert ezért nem kell raktár modullal bonyolítani a programot és a kezelőfelületét egy termékeket nem forgalmazó cégnél
- szerződés szerint úgyis tudja mit bérel és miért fizet. Ha van több bérleménye, akkor persze lehet több cikk. Mivel kevés tétel van a cikktörzsben csak "Bérleti díj", ezért Gizike nem tudja elrontani a számlát, a munkaszámot meg később lehet javítani, de nem kell számlát stornírozni és újat kiállítani, ha véletlenül a főépület helyett melléképület munkaszám került rögzítésre.

( zZsOlTi v | 2007. 11. 13., k – 16:55 )

Kicsit offtopic, de ha már ennyien összejöttek itt, akik így-vagy úgy de számlázó programmal foglalkoznak (fejlesztenek), lenne 2 kérdésem:

1, Hogyan lehet egy számlázó program opensource? Azért kérdezem, mert ahány számlázó programot láttam, ott mindig volt a programnak "gazdája" -egy cég, vagy maga a fejelsztő-, aki garantálta mind a programot használó ügyfelek felé, mind az apeh felé, hogy a program és a vele kiállított számlák megfelelnek a hatályos szabályoknak. Plusz, a számlázó program készítőjének -ha jól tudom- nyilván kell tartania az ügyfeleit, akik a programot letöltik/használják. Egy opensource, forrásban bárki számára hozzáférhető (és akár módosítható, terjeszthető) programnál a fentiek hogyan garantálhatók?

2, Egyszer régen már széttúrtam az apeh honlapját illetve kerestem jogszabályokat is, de nem találtam semmi konkrétumot arra vonatkozóan, hogy milyen kritériumok vannak egy számlázó programmal kapcsolatban (milyen jogszabályoknak kell megfelenie, kell-e valamilyen hatóság áldását kérni rá, milyen adatokat kell/nenm kell tárolni, mik egy számla kötelező elemei, mik az opcionális elemek, az adatokat hogyan kell tárolni (pl plain XML lehet-e, vagy kell valahogy biztosítani -titkosítás-, hogy utólag ne lehessen maipulálni), stb..?

Azért a kérdések, mert én is régóta agyalok valami nagyon egyszerű számlázó program készítésén (hogy zárt, vagy opensource, ez részben a fenti kérdésektől is függ). Én mondjuk kicsiben gondolkozom mindenképp -elsősorban a saját igényeimből kiindulva, mert sajnos linux alá nem találtam még megfelelő programot-, kis cégeknek, egyéni vállalkozóknak, ahol nincs szükség külön robosztus adatbázis backendre az ügyfelek, meg raktárkészlet meg egyebek nyilántartásra. (Mono/GTK#-ban gondolkozom, XML backenddel, de egylőre az egész csak terv, talán mostanában lesz időm, hogy kicsit jobban letisztázzam magamban -és papíron- a "specifikációkat").

1. Csak az az elvaras, hogy a program keszitojenek nyilatkoznia kell arrol, hogy megfelel az eloirasoknak (34/1999. (XII.26) PM rendelet, 1.§ , 7. bekezdes ha minden igaz). Arra vonatkozoan nincs eloiras, hogy nyilvan kellene tartani a program hasznaloit. Az eredetiseg ellenorzesere pedig sok variacio letezik. Ha az ugyfelnel levo szerveren fut a rendszerunk, akkor sha1sum keszul minden filerol es ez elvalaszthatatlan reszet kepezi az atadasi dokumentacionak.
2. Az AFA torveny es a fenti PM rendelet egyutt adjak a szabalyozast.

A számvitelről szóló tv. tartalmazza az egyszerűsített számla ill. számla tartalmi elemeit. Felelősségvállalási nyilatkozatot arról állítasz ki, hogy a számla tartalma e tv-nek megfelel, ill. sorszámozása folyamatos, kihagyás nélküli. Az, hogy hogyan tárolod tök mindegy, nem a gépen tárolt adatok jelentik a számlát, hanem a papír, ami kijön a nyomtatóból, ezt az egyéb számlákkal(nyomtatvány, tömb) megegyezően kell kezelni.
Elektronikus számla esetében az apeh kiadott egy xml specifikációt, ez esetben a bizonylatot maga a gépen tárolt adathalmaz jelenti, ezt megfelelő hitelesítéssel, ill. időbélyeggel kell ellátni.

Opensource programnál általában nem biztosítható a felelősségvállalás, tehát maga a felhasználó az, akinek felelősséget kell vállalnia. Ezért nem túl gyakori, hogy GPL-es számlázóprogramot használjanak, ugyanis az APEH számonkérheti a nyilatkozatot, ez pedig azt jelenti, hogy valakinek "tökéletesen" értenie kell a program forráskódját.

Az os cucc írója evidensen nem vállalhat felelősséget azért, ha valaki módosítja a kódot. Így ha egy os számlázóprogramot akarsz használni, akkor valakinek nyilatkoznia kell, hogy megfelel a vonatkozó PM-rendeletnek. (A GPL pl. eleve kizárja a felelősségvállalást.)
Ezzel elvileg nincs is gond, hiszen evidensen nem fog egyetlen kiadott számlázóprogram sem olyan funkciókat tartalmazni, amiket a rendelet tilt (pl. már kinyomtatott számla módosítása, többszöri "eredeti" nyomtatás stb.). Viszont mi történik, ha a program hibázik, és mondjuk kiad két ugyanolyan sorszámú számlát, esetleg "átugrik" egy sorszámot?
Mered vállalni egy ilyenért a felelősséget?

Szerintem még inkább:
Nem a program készítője vállal felelőséget, hanem aki használja. A program készítőjétől kaphatsz nyilatkozatot, hogy megfelel a hatályos jogszabályoknak, de a felelőség a cégé, amelyik dolgozik vele. Ha kiderül, hogy illegális műveleteket végeznek vele, a bukta a cégé. Erről egyébként van egy aktuális zárójeles sztorim, de csak ha érdeklődés van rá :)

Elég zavaros helyzetet teremtene egyébként a dolog, tekintve, hogy nagyon sok adatbázist kézzel lehet nyomkodni, az accesstól a sap-ig láttam rá példákat. A programozó erre nem sok felelőséget tud vállalni, a törvény meg nem kötelezi, hogy titkosítsa az egész adatbázist és mechanizmusát.
Persze a konkrét jogalkalmazás ugye sokféle lehet :)

A program 'készítője' azért vállal felelősséget, hogy a programmal előállított bizonylat a törvényi előírásoknak megfelel. Ez szgéppel előállított számlánál annyit tesz, hogy tartalmazza a számviteli törvényben előírt adatokat, illetve sorszámozása folyamatos, kihagyás nélküli. A számla kinyomtatását követően a kutyát nem érdekli, hogy mi történik vele a gépen, akár törölheted is. Sőt előtte sem. Itt a bizonylat a nyomtatóból kijövő papir.

Hm... teljesen igazad van.
Akkor visszakanyarodva a kérdéshez, ha egy GPL-es program esetén, ahol nincs gazda, kié a felelőség, illetve ki írhatja meg ezt a papírt? Ez kezd egyre bonyolultabb lenni :)
Egyáltalán a nyilatkozat nélkül nem ér azt a programot használni? Gondolom, hogy az APEH kéregetni szokta, de van erre jogalapja? Nem elég ha valóban megfelel a progi az előírásoknak (amit úgyis látnak a könyvelésben)?
Adhat számítástechnikai cég szakvéleményt, hogy megfelel a program az előírásoknak?

A vicces az egészben az, hogy a könyvelésben úgyis látszik a baki a sorszám és a számlakép kapcsán. Kicsit nyugatabra az ilyen 1 számla/hó cégek egyszerűen kinyitják a word-öt és beírják a következő sorszámot kézzel, meg hogy "5db lepkefing 20€" és mindenki boldog. Itt mindent túl kell bonyolizálni :(

Na, pontosan ez a kérdés.

1, Ez a bizonyos felelősség vállalás, és az erről kiállított nyilatkozat kötelező tartozéka-e egy számlázó programnak?

2, Ha igen és a program nyílt forrású, akkor ki tartja a hátát a hatóságok felé? Én, mert én írtam az első 10 sor kódot és én indítottam útjára a projektet?

3, Ha valaki megpiszkálja a forrást és elterjeszt egy olyan program verziót, amivel mondjuk utólag is lehet változtatni a kiadott számlákon és ezzel a program verzióval valaki(k) visszaélnek, akkor ki lesz a felelős? Tudom ez már majdnem sci-fi kategória, de simán elképzelhetőnek tartom, hogy ilyen ügyben a program eredeti szerzőjét/it vennék elő a hatóságok (mert mondjuk a program about boxában az ő neve/nevük van).

Az aki mondjuk utólag változtat a kiadott számlákon, tehát nem az autógyártó a felelős a balesetekért, hanem az aki használja. Amúgy meg feltörhetetlen számlázóprogram nincs, és hosszasan lehetne arról beszélni hogy miként lehet manipulálni egy-egy programot vagy pénztárgépet.

1, igen törvényi előírás
2, aki kiállítja a felelősségvállalási nyilatkozatot. Értelemszerűen nem az aki akár egy sort is írt bele, hanem aki nyilatkozott.
3, Ha valaki megpiszkálja, arra már nem vonatkozik a felelősségvállalási nyilatkozat. A nyilatkozatot adott felhasználónak, adott prg. verzióra adod. Akár a lefordított prg. fájljainak checksum-ját is belefoglalhatod, sztem ez elégséges védelem. :)

2, aki kiállítja a felelősségvállalási nyilatkozatot.

Most végülis ebből én azt szűrtem le, hogy mégsem lehet egy számlázó program opensource. Elvileg igen, gyakorlatilag azonban nehezen tudom elképzelni, mert egy bármikor, bárki által forrás szinten is hozzáférhető programra senki nem fog garnciát/felelősséget vállalni. Az opensource fejlesztés lényege ugye az lenne, hogy bárki belenyúlhat, javíthat hibát, fejleszthet. Ha egy sort átír valaki a forrásban, akkor az már nem ugyanaz sem forrás, sem bináris szinten, mint az egy órával korábbi verzió.

"A nyilatkozatot adott felhasználónak, adott prg. verzióra adod."

Ha bárki letöltheti a programot akár kész bináris csomagban, akár forrásban -ami folyamatosan változhat-, akkor ez nem megoldható, nem tudom ki lesz a végfelhasználó, sőt azt sem tudom, hogy a letöltött forráson esetleg módosít-e valamit, mielőtt lefordítja magának.

Kanyarodjunk vissza az elejére :)
Adott XY, számlázóprogram fejlesztésén töri a fejét.

Első opció, hogy zártan fejleszt, hobbi projekt szinten. Később esetleg fizet külső fejlesztőknek a bedolgozásért. Saját cége nevében vállalja a felelősséget a programért, a kiadott program verzió mellé mellékeli erről a kötelező nyilatkozatot. A programot nem ingyen adja.

Második opció, hogy XY GUI tervekkel és egy kezdeti minimális kódbázissal útjára indít egy opensource projektet, amiből remélhetőleg jópár lelkes fejlesztő segítségével hamarosan megszületik a számlázó program. Ebben az esetben a program nem a sajátja, a programnak nincs "gazdája", nincs mögötte cég, van A B C D ... Z fejlesztő, van aki ad hostingot az SVN-hez, van aki logót tervez, van aki dokumentációt ír, stb. A nyílt forrás bármelyik fejlesztési és végleges stádiumában bárki számára hozzáférhető, letölthető, módosítható, lefordítható, és _használható_, ingyen. Vagyis mégsem, mert ebben az esetben XY nem áll "hivatalosan" a projekt mögött és nem vállal -nem mer- jogi felelősséget a sokak által fejlesztett _közös_ projektért. Nem akar nyilatkozatokat kiadni és az apeh felé később elszámolható formában nyilvántartani, hogy kinek milyen buildet, milyen nyilatkozattal adott. Nem akar olyan kellemetlen helyzetbe kerülni, hogy egy más által készített problémás buildet rajta kérjen számon az apeh, még akkor sem, ha relatíve könnyedén bizonyítható, hogy az a build nem hivatalos. Így viszont nincs értelme az egésznek, mert nyilatkozat híján a programot senki nem használhatja.

Szerintem nem ilyen rossz a helyzet. Átböngészve még egyszer a vonatkozó jogszabályokat, tulajdonképpen két kritériumnak kell megfelelni:
1. Mi van a kinyomtatott számlán: rajta legyenek az adatok a névtől az adószámig, nettó, bruttó, stb.
2. szigorú sorszámozás

Ez számomra racionális módon ellenőrizhetőnek tűnik. Fogsz egy adott verziót, csinálsz róla checksum, akármi dolgokat, elrakod a weboldaladra kapcsolódó dokumentumként, cd-re írod és pecsétes borítékba teszed, kinyomtatod a forrást :), stb, valahogy eltárolod és azt mondod, hogy ez a verzió megfelel a jogszabályoknak. Persze jönnek a fícsörök meg a bugfixek, mondjuk fél év múlva megint csinálsz egy ilyet. A való életbe senki nem fogja a program verziót meg a forrás kódot ellenőrizni, hogy a két állapot között volt-e valami változás vagy mi.

Worst case scenario: mi van ha valaki megváltoztatja a kódod a tudtod nélkül és csinál valami galibát (pl a sorszámozás nem jó). Ha rád akarják húzni a vizes lepedőt, egyszerűen független szakértőt hívsz és megmutatod, hogy meg lett hackelve a dolog. Szerintem ez egy racionális (haha) bíróság elött megállná a helyét. Megjegyzem, hogy ez zárt forrásnál is előfordulhat, tehát ezt a problémát nem az open-source hozná magával.

Ha program hibás a felhasználót büntetik meg. (Minden esetben akár nyilt akkár zárt)
A felhasználó nyilatkozhat, hogy az ő progija márpediglen jó.

Ha te akarsz valakinek nyilatkozni (aki hiba esetén esetleg kártérítést követelhet, miután őt megbüntetik), azt is megteheted.

Bocs, ha trivilitásokat mondok.
Az OpenSource kódba, ha valaki belenyúl az nem kerül bele automatikusan minden példányba. Csak a modosító saját példányába, a modosítást elküldheti másnak, aki bele rakja a saját példányába, ha tetszik, ha nem akkor nem rakja bele.

Sok féle nyílt forrású license van.
- Van olyan ami nem engedi, hogy programot ugyan azzal névvel tovább add modosítva.
- Van olyan ami egyáltalán nem engedi, hogy tovább add a kódot, de program vásárlói belenézhetnek. (Az eledónak végezhetsz ilyenkor is ingyen munkát :) )
- Lehet olyan is ami csak, hobby felhasználást enged ingyen.

Egy zárt program működését is meg lehet változtatni!
A nyomtatón meg az jön ki amit kiküldök..

Köszi, ez lett volna az eggyel fölötted lévő hozzázólásom harmadik opciója, vagyis kérdése (csak már nem volt erőm leírni), hogy hogyan lehetne olyan megoldást találni, ahol a fejlesztés mehet részben/teljesen opensource formában, de a programnak mégis lenne egy "gazdája" (cég), aki a hivatlaos verziót kiadja, és aki vállalja a érte felelősséget. A programot mondjuk ne lehessen csak bizonyos feltételekkel forkolni, és mindemellett még legyen kedve beszállni pár programozónak hobbiból. :) Jól hangzik.. :)

(halkan hozzáteszem, hogy az egész kérdésnek nagyobb a füstje, mint a lángja, mert amit én elképzeltem, az kb 2-3 hétévgés projekt lenne egy GTK#-ban jártas embernek :), ettől függetlenül ez a topic -így szétoffolva- úgy érzem hasznos volt, úgyhogy mindenkinek köszönöm a válaszokat mégegyszer :))

Ilyen van több szoftver esetében is. Hogy csak egy példát mondjak, az Adempiere nevű ERP rendszernek (amivel lehet számlázni is :) ) pl. mi vállaljuk a magyarországi támogatását, ha kell a felelősségvállalási nyilatkozatot is aláírjuk.

GPL-es a cucc, a forrás tehát jár hozzá, aláírva, MD5 checksum, stb...

A forrásért magáért nem is kérünk pénzt, hanem csak az elvégzett egyéb munkákért, amik már persze nem feltétlenül open source kategória.

--
Gabriel Akos

Gondolom megfeleló végzettséggel kell hozzá rendelkezni. Magánszemély esetén egy számtech. érettségi, vagy egy alapfokú OKJ-s számtech. végzettség, azzal már írhatsz programot. Cég esetében szerintem nincs különösebb feltétele, amióta, ha jól tudom már csak a fő tev. körnek kell szerepelnie a cégbírósági iratokban.
Az apeh a nyilatkozatot, illetve a felhasználói kézikönyvet kérheti, ez törvényi előírás.
Számtech. cég minden további nélkül adhat ilyen nyilatkozatot.
A számlaképnek nem feltétlen kell egyeznie, a tartalom a lényeg. Pl.: Ha kedves ügyfél szól, hogy elvesztette a számlát, állíthatsz ki hiteles másolatot róla, ami nem feltétlen néz ki úgy mint az eredeti, de tartalmilag egyezik.

Köszönöm szépen a választ, látom nagyon otthon vagy a témában!

Ha még van türelmed, akkor:
Ha jól értelemezem a törvényt, akkor végülis bármi kinyomtathatja a számlát, amennyiben a papíron az adatok rendben vannak és a sorszámozás is ok. Jelenti ez azt, hogy a korábban vázolt "wordben megírom a számlát, kézzel adok neki sorszámot" módszer tulajdonképpen elfogadható itthon is? Vagy itt már rezeg a léc?

Más: akkor úgy néz ki, hogy GPL licenc alatt tulajdonképpen kiszórhatom a programomat a netre és még mindig kitermelhetek néhány zsíroskenyérnyit azzal, hogy pénzért adok róla megfelelőségi nyilatkozat, nameg manuált. Ez elég érdekes helyzet. Nem mintha meg kívánnám szedni magam a "yet another számlázóprogram" és kerék újrafeltalálás projektemmel. :)

A word werzió nem működik, a sorszámot a proginak kell előállítania.

Igen, gyakorlatilag erről van szó.

Másrészt visszaolvasva a hozzászólásokat, nem vagyok GPL ügyben biztos a dolgomban. Azért valószínünek tartom, hogy ez a nyilatkozat nem ütközik vele, merthogy itt egy buildra(tehát nem a forrásra) adod a nyilatkozatot, adott személynek.

Átnéztem a GPL magyar fordítását. Ez a másodig bekezdés:
A másoláson, terjesztésen és módosításon kívül más tevékenységgel nem foglalkozik ez a dokumentum, azokat hatályon kívülinek tekinti. A Program futtatása nincs korlátozva, illetve a Program kimenetére is csak abban az esetben vonatkozik ez a szabályozás, ha az tartalmazza a Programon alapuló munka egy részletét (attól függetlenül, hogy ez a Program futtatásával jött-e létre). Ez tehát a Program működésétől függ.

Értelmezésem szerint olyan garanciát vállalsz rá - külön megállapodás alapján - amilyet akarsz, és azért lovit kérhetsz.

Közben megvilágosodtam, hogy nem reveláns a társalgás szempontjából, de azért érdekes. Az APEH azt állítja, hogy készpénzes fizetés esetén nem lehet (korábban) szállítólevelet kiállítani.
Aki kereskedik, az tudja hogy ez bevett gyakorlat: mikor elviszed a cuccokat szállítónk kiadják, azt amit felhasználsz valamikor kifizeted, a maradékot visszaadod, és akkor lesz ebből KP számla. A kettő között pedig dolgozgatsz a cuccal. Na, most éppen úgy gondolják az APEHnél, hogy ez nem legális, csak ha banki utalással fizetsz (miért is?).
Attól eltekintve, hogy ez mennyire igaz vagy sem, vagy az APEH ellenőr hülye-e, itt például súroljuk azt az esetet, hogy a programmal akkor tulajdonképpen illegális bizonylat készült. De persze nem a programozó felelősége, mert a szabályoknak tulajdonképpen megfelel a számla, mégis kifogásolják a rendet ahogy létrejött.
Nem hiszem egyébként, hogy bármi büntetés fog ebből fejlődni, mert elég irracionális az elképzelés, de az ellenőr ilyesmikkel is próbálkozik. Hát ennyi a sztori :) az APEH útjai kifürkészhetetlenek.

Megoldás:
Szállító összevonása számlába ami utalásos.
Utánna rögtön nyomtatsz egy készpénzbefizetési bizonylatot.
Mivel a számla utalásos lesz, így az apech felé jó.
De mivel nem kötelezhetnek senkit, hogy csak bankba rendezheti, hanem kp-ba is kiegyenlítheti befizetési bizonylat mellett ezért az is legális.

pch

Ha ez nekem szólt, akkor igen, gondolkoztam már rajta -láttam a projektet az indulásakor, próbáltam a demót is-, de valahogy idegenkedem tőle, hogy webes felületen intézzem a számlázást (nem mintha szupertitkos állami megrendeléseken dolgoznék :), de akkor is). Egy egyszuerű kis programot szeretnék, ami a saját gépemen fut, és kiváltható vele egy sima számlatömb.

( stomx | 2007. 11. 13., k – 18:02 )

Pont itt tartok en is, es par hete kerdeztem meg a Kulcs-Soft-ot, hogy a szamlazojukbol nem kivannak-e csinalni linuxos verziot.
Azt a valaszt kaptam, hogy kb egy ev mulva kijon Linuxra is.
Jelenleg van egy free szamlazoprogijuk (max 50 szamla/ev). Ki kellene probalni wine-nal.

Remélem, nem a Készlet és Számla nevű Delphiben írt förmedvényre gondolsz.
Komolyan mondom, ha ingyen adnák se kéne. Egy ügyfelem használja, de iszonyatos szenvedés volt beüzemelni:
- A cucc külső adatot importálni csak egy külön megvásárolható modullal tud, csak Excelből, és feltétel egy teljes Excel 2000+ megléte a gépen (nem volt). Maradt a "kézzel begyúrom a táblákba" eset.
- Adatbázismotor gyanánt az MSDE-t használja. Valószínűleg az MSDE korlátai miatt vannak pl. törzstáblák 2-3 darabba szétszedve (tán nem bír el ennyi oszloppal a MS? :).
- A Delphiből következően nem unicode-os (legalábbis anno nekem nem sikerült unicode-támogatást kicsalnom egy 5-ös Delphiből, sőt később a Kylixból sem). Ez kifejezetten érdekessé teszi, ha pl. angol Win alól használod, és bármilyen okból nem állítod át magyarra a nem-unicode programok kódlapját, netán így, három évvel az EU-csatlakozás után esetleg szeretnéd a partnereid nevét helyesen leírni...
- A lekérdezéseknél a megjelenítés nem csak egy képernyőnyi adatot kér le az adatbázisból, hanem az egészet, így pl. százezer tételnél összeomlik a grid widget. (Ne használd pl. alkatrészkereskedésben.)
- Számunkra a legdurvább tervezési hiányossága: nem tudok beszerzési árat megadni kalkulációhoz, ha ténylegesen nem szereztem be (pl. netes boltok esetén ki az, akinek mindene raktáron van, ami rendelhető?). Magyarán nem tudok olyan tételt feltüntetni árlistában, ajánlatban, ami nincs raktáron. Persze lehet trükközni külső raktárak kezelésével, valójában nem létező beszerzések megadásával, de ha a Főkönyv nevű könyvelőprogramjuknak (ami viszont a könyvelő szerint igen jó) így adom át az adatokat, akkor az gáz.
- "Apróbb" használhatósági problémák: nem tudsz bármelyik oszlopra rendezni az előtted lévő táblán, a keresés kényelmetlen, a nagy táblák hálózaton igen lassan kezelhetők (OK, nem arra tervezték, hogy 1 Mb/s-es neten keresztül használja valaki, de nekünk mégiscsak erre kell :)

Nem hinném, hogy attól rossz a program mert Delphiben készítették.
Bár nem ismerem az adatbázisuk szerkezetét, de az hogy egy törzsadat tábla szét van szedve az nem hiba, hanem tervezés! A Delphi támogatja az unicode kezelését, csak nem egy 7-8 évvel ezelötti verzióval kellene probálkozni amit 95, 98 és NT rendszerekhez készítettek.

Nem a WideChar típusra gondoltam: tudtommal a VCL-ben definiált controlok jelenleg nem unicode-osak.
A törzsadat-tábla szétszedése a lekérdezéseknél felesleges join-okhoz vezet. (Nincs értelme pl. a cikkszámot és a hozzá tartozó ÁFA-kódot külön táblában tartani.) Lehet, hogy tervezés, de akkor hibás.

( zsotya v | 2007. 11. 13., k – 23:08 )

Sziasztok!

Nem tudom nagyon rosz helyre irok e de nagyjabol temaba vag, s hatha jartas valaki ebben is.

Az lenne a kerdes hogy egy Mo-i egyeni vallalkozo roman cegnek milyen szamlat adjon, adhat, kell hogy adjon?(nyelv, penznem, tipus, esetleg milyen programot ajanlatok?) Hogy lehet ezt megoldani hogy itteni torvenyekbe se utkozzon, elfogadjak, s a romaniai ceg is efogadja, roman torvenyeknek is megfeleljen?

Sorry ha rosz helyre irtam megegyszer, s ha ez tortent adjatok tippet hol tegyem fel ezt a kerdest.. Konyvelonk sajnos nem az igazi s e kerdesre nem tudott megnyugtato valaszt adni:-(

Koszonom elore is!

Elviekben, de kérdezz meg egy profi könyvelőt:

Románia EU tag, ha van közösségi adószáma a partnernek akkor:
Ha termék, akkor ÁFA nélkül állítod ki a számlát.
Ha szolgáltatás és idehaza teljesíted, akkor ÁFÁval.
Ha szolgáltatás és külföldön teljesíted akkor ÁFA nélkül.

A pénz lehet forintba, akkor az ő könyvelésük molyol azon hogy az mennyit jelent nekik.
Vagy lehet valutában, ekkor a napi MNB középárfolyamon átszámolva forintba kerül be a könyvelésedbe (ezt nem árt feltüntetni a számlán).

Ha a partnernak nincs közösségi adószáma, akkor csak normál (ÁFÁs) számlát adhatsz neki (de ezt is el tudja számolni). A közösségi adószámot elvileg neked kell ellenőrizni, az apeh oldalán van link egy ellenörző oldalra, vagy bekéred az adószám kiállításáról a papírt (és lemásolod legjobb esetben).

Ennyit tudok, remélhetőleg helyesen :)

( styg v | 2007. 11. 14., sze – 10:31 )

Fifi, tegnap küldtem neked egy üzenetet. Megkaptad?

( gyrgyvrs | 2007. 12. 13., cs – 19:53 )

A Magyar Közlönyben megjelent az ÁFA törvény 2008. január 1-től hatályos változata (CXXVII. törvény). EU-s jogharmonizáció, elektronikus számla. Elvileg külön jogszabályban szabályozzák a gépi számlázást is, ha jól láttam.

No igen. Ez a pdf egyébként is az egyik kedvencem.
Ilyeneket ír pl:

"a) az (1) bekezdés a) és b) pontjában említett esetben a 169. §-ban felsorolt adatok közül a h) pontban megjelölt helyett az ellenérték adót is tartalmazó összege, valamint az i) pontban megjelölt helyett az alkalmazott adómértéknek megfelelõ, a 83. § szerint meghatározott százalékérték feltüntetése kötelezõ azzal, hogy egyúttal a j) pontban megjelölt adat nem tüntethetõ fel;"

Mi is a helyzet?
Az én adómból fenntartott pénzügyminisztériumi közalkalmazottak ilyeneket irkálnak, amiket csak az én adómból fenntartott jogászok tudnak elolvasni, akik jelzik az én adómból fenntartott adóellenőröknek, hogy ÉN ezt nem értettem meg (ezért nem tartom be), tehát elindul egy (az én adóforintjaimból finanszírozott) büntetőeljárás... grrrrrrrr...

:-)

( pch v | 2008. 01. 11., p – 08:02 )

Hi!
Az lenne a kérdésem a tisztelt programozókhoz, hogy árulják el, hogy csinálják a számlák nyomtatását. Esetleg egy forráskódot is mellékelhetnek.
PHP+myqsl-be fut a számlázó progi és most ugy oldottam meg, hogy megszámlálom a sorokat és ha az több mint pl.: 40 akkor lapdobás és uj fejléc. De ez nem járható nagyon, mertha egy megnevezés nagyobb min pl.: 20 akkor az 2 sorba lesz kiiratva és rögtön elcsúszik az egész.

előre is köszi
pch

( gmatyi | 2008. 01. 11., p – 08:48 )

Az ősszel én is beleástam magam ebbe a témába, de sajnos zsákutcába futottam. Sajnos kiderült, hogy a magyar adójogszabályok szerint gépi számlát csak olyan programmal szabad készíteni, ahol (1) a rögzített adatokat utólag ne lehessen módosítani (2) a nyomtatás folyamata ellenörzött legyen, hogy a számlát kizárólag a programból lehessen kinyomtatni, a szoftver tartsa nyilván, ha egy számlából pl. másodpéldány lett kinyomtatva. A sikertelenül kinyomtatott számlákat (pl. a papír begyűrődött) a programban tudomásom szerint le kell sztornózni, és új számlaszámmal kell a számlát kinyomtatni. A programnak a nyomtatót közvetlenül kell vezérelnie, nem szabad lehetőséget biztosítani arra, hogy a pl. pdf- fájlba nyomtassunk.

Sajnos ezt a marhaságot olyan ember találta ki, akinek lövése sincs a számítástechnikához, a gondolataiban a számlázógép még mindig egy DOS-os számítógép egy hozzákapcsolt nyomtatóval.
Windowsos gépen egy számlázóprogramot láttam működés közben. Az Internet explorerrel lehetett a számlázóprogramba belépni, itt a nyomtatást egy activex plugin végezte, ellenőrizte. Firefox alól természetesen nem lehetett a programot használni, Linux alól se.

Szerintem az ember fiának az élete ebben a témában akkor lesz könnyebb, ha kifizeti ezt a sarcot - az más téma, hogy ez a dolog is a jó magyar mutyi, vagyis hoznak egy törvényt, hogy a haverok betegre keressék magukat.

Szia

"A programnak a nyomtatót közvetlenül kell vezérelnie, nem szabad lehetőséget biztosítani arra, hogy a pl. pdf- fájlba nyomtassunk" Ezt hol találtad? El tudnád küldeni a törvényt, vagy a pontos számát?

Attila

-------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"

sajnos nem tudom elküldeni. Ellenben csatlom azt a levelet, amelyet a vállalkozásunk mint egyébk adóigazgatási kérdés eljuttatott az APEH-hez, és egyben a választ is.

Az a helyzet, hogy már sokmindenkinek nekimentem a mai világban, de ezt az ügyet feladtam. ;(

Tisztelt Ügyfélszolgálat!

Szoftverfejleszto cég vagyunk, és felmerült az a probléma, hogy külföldi (unión belüli) vevoink részére elektronikus formátumban kellene a számlát kibocsáltanunk. Ennek kapcsán egy számunkra egyre jobban átláthatatlan problémahalmazba ütköztünk, kérem ebben szíves segítségüket.

A termékeink és szolgáltatásaink esetében az alapprobléma az, hogy teljesítéskor nincs áruforgalom, az ügyféllel történo személyes találkozás is kimarad. A termék vagy szolgáltatás konkrétan egy szofver, vagy annak kifejlesztése, illetve telefonon történo konzultáció. pl. egy weblap elkészítésekor az elkészült weblapot mi töltjük fel az ügyfél szerverére, o pedig átutalással fizet, illetve csak fizetne, ha tudnánk neki elektronikusan szabályos számlát adni. Jelenleg papír alapú számát vagyunk kénytelenek postai úton az ügyfél postacímére elküldeni, vagy egy személyes találkozás során tudjuk azt részére átadni.

Külföldi beszállítóktól történo vásárlás esetén (pl. szerver tárhely szolgáltatás vásárlás) tapasztalatilag ez úgy muködik, hogy a szolgáltató a magán hitelkártyámról leemelni a szolgáltatás díját, a számlát pedig pdf formátumban elküldi az e-mail címemre, lényegében a vevoink is hasonló módon szeretnék a mi számláinkat fogadni.

A kisebbik problémát úgy tunik megoldottuk. A számlázóprogramnak van pdf generálás funkciója. De rögtön itt van a nagyobbik gond, hogy jelen ismereteim szerint ezt elektronikusan csak úgy küldhetem el, hogy azt elektronikus aláírással látom el, amihez egy elektronikus tanúsítványt kellene kiváltanom, illetve egy idobélyeg szolgáltatásra kellene elofizetnem.

Tervben van véve egy webshop rendszer üzemeltetése is, ahol az ügyfél on-line hitelkártya elfogadással tudná megvenni valamely szoftvertermékünket. Ennek nincs technikai akadálya, itt is a számlázás a gond, de a probléma még komplexebb. A számlát itt nem én állítom ki, hanem maga a webshop szerver alkalmazás. A számlázáshoz szükséges adatokat a szerver alkalmazás az ügyfél regisztrációs adataiból illetve a hitelkártya tranzakció alapján keletkezik. Az általunk kifejlesztett még tesztüzemben lévo rendszer erre alapvetoen képes, természetesen elektronikus aláírást, idobélyeget viszont nem tud a generált számlákra ráhelyezni.

Jelenlegi információink szerint még az egyszerubb esetben is (amikor saját magam írom alá egy célszoftverrel a kibocsátandó számlát) évi többtízezer Ft-ba kerülne a szolgáltatás. A bonyolultabb esetben, amikor a szerver alkalmazás írja alá az on-line generált számlát, az pedig kb. 1,5-2 millió Ft-ba kerülne - természetesen ezen összegek annak ismeretében keletkeztek, hogy szoftverfejleszto cég révén az elektronikus aláírás szoftver integrációját magunk is képesek vagyunk elintézni.

Igazából nem látom át a mostani szabályozást. Azt látom, hogy az unión belüli más tagországok vállalkozóival szemben versenyhátrányban vagyunk, mert akár az angol, német, holland vagy spanyol vállalkozót (szoftverfejleszto cég) szemléljük, egy szoftveres úton eloállított pdf formátumú számla kiállítása és annak e-mail ben történo elküldése az ottani törvények értelmében szabályos, ennek megfeleloen nekik nem szükségük ezen összegeket megfinanszírozniuk.

Kérem szíves segítségüket az ügyben.

A válasz:

Tisztelt Ügyfelünk!

Igazgatóságunkhoz e-mailben érkezett levelére az alábbi tájékoztatást adom.
A jelenleg hatályos szabályozást az ? APEH közlemény az elektronikus számlázásról ? tartalmazza, mely megjelent az Adó-és Ellenorzési Értesíto 2005./9. számában, illetve elérheto a Complex Jogtáron belül az általános forgalmi adóról szóló 1992. évi LXXIV. törvény kapcsolódó anyagai között.

Tájékoztatásom kizárólag a levelében foglaltakon alapuló szakmai vélemény, amely kötelezo jogi erovel nem bír.

Tisztelettel:
Adó-és Pénzügyi Ellenorzési Hivatal

Na most itt két különböző dologról beszélünk. Az elektronikus számla, ami a második postodban van, teljesen más, mint a számítógéppel kiállított számla. A számítógéppel kiállított számlával kapcsolatban formai követelmények vannak (mit kell tartalomaznia), de a technikai hátérre nincs megkötés. Ellenben az elektronikus számlával valóban sok baj van, mert tényleg egyfajta minősített rendszerben kell elkészülnie.
Elmélet és gyakorlat. Le van írva a jogszabályba (november 16.-i közlöny ~178. oldal), hogy hogyan kell működnie. Időbélyegző, aláírás, megváltoztathatatlanság. Ezt valamennyire össze kell barkácsolni, de bevizsgáltatni (a sima számlázó programokhoz hasonlóan) nem kell. (Ha jól tudom, ennek azért nézz utánna.) Ha be kell vizsgáltatni, akkor szívoznak veled pár kört, de végül a technikai paraméterek mindegy lesznek, csak megmutatják ki az úr. Legalábbis a pénztárgépes mókáknál ez van.
Aztán szabad rablás. A házi barkács rendszerektől a SAP-ig mindenben lehet turkálni az adatokat és meg is teszik, a szabályozás ebből a szempontból teljesen értelmetlen. Meg más szempontból is. Valaki azt rebesgette, hogy felül fogják vizsgálni ezeket a törvényeket, de hát a csodára várni kell :)))

"házi barkács rendszerektől a SAP-ig mindenben lehet turkálni az adatokat és meg is teszik, a szabályozás ebből a szempontból teljesen értelmetlen"

A szabályozás úgy szól, hogy a felhasználónak ne legyen lehetősége az adatok utólagos megváltoztatására.
Természetesen az adatbázisbana fejlesztő/rendszergazda/akárki megteheti, viszont a program felhasználójának a program nem adhat ilyen lehetőséget.

technikai szempontból ez valóban 2 külön dolog. Annyiban viszont közös a hasonlóság, hogy valaki kitalált egy iszonyúan bürorkatikus törvényt, hogy egy bizonyos kör ebből tudjon kaszálni.
Elektronikus számla: a világon szinte mindenhol az adóhivatal elfogadja számlának azt a nyomtatott vagy elektronikus formában lévő dokumentumot, amely tartalmazza a kötelező tartalmi elemeket. Nálunk nem. Itt a számlát csak a számlázóprogram nyomtathatja ki, elektronikus számlát pedig időbélyeggel és elekronikus aláírással kell ellátni. Természetesen az EU csatlakozásunk óta a papír alapú számlát nem kötelező sem aláírni, sem lepecsételni. Magyarán ha a kinyomtatott számlát beszkenneled, majd elküldöd az ügyfélnek, és megkéred, hogy nyomtassa ki, akkor döntse el az apeh, hogy az most postán lett e küldve, vagy elektronikusan... Tehát minek ekkor aláírni elektronikusan?
On-line számlázás esetén pedig? Hát ekkor a privát kulcsodat feltelepítheted a szerverre az aláíró szoftveredbe. Gratula. Ha ezt egy hacker ellopja, aztán azzal aláír a nevedben egy szerződést, akkor magyarázkodhatsz a bíróságon, hogy nem te voltál.

Végeredményben arra jutottam, hogy a házi barkács rendszerek használatába bele fog tudni kötni az apeh, ha éppen olyan kedve van. Ha megvásárolod valakinek a számlázó rendszerét, ami bevizsgált, akkor te gond esetén moshatod kezeidet.

"Végeredményben arra jutottam, hogy a házi barkács rendszerek használatába bele fog tudni kötni az apeh, ha éppen olyan kedve van. Ha megvásárolod valakinek a számlázó rendszerét, ami bevizsgált, akkor te gond esetén moshatod kezeidet."

Korábban már beszélgettünk a felelőség és felelőség vállalás kérdéséről itt és máshol is a nyílt forrás kapcsán. Arra a következtetésre jutottunk, hogy a programozót a jelenlegi törvények szerint nem terheli felelőség, ha a programját úgy használják, hogy a jogszabályoknak nem megfelelő dolgot tesznek. Ezt a megállapítást megfordítva egy bevizsgált program esetén sem moshatod a kezed, mint felhasználó, ha az APEH belédköt. Ez úgy általában is aranyszabály, ha belédkötnek, akkor úgy jártál :)))

A többi kérdésben sajnos igazad van. Már írtam, hogy Ausztriába például egyszerűen kinyitják a Word-öt és írnak vele egy számlát. Ha online kell, elküldik mailbe. Hihetetlen amit itt követelnek :(