Rendszerterv készítése nyílt forrású projekthez

 ( gergelykiss | 2008. április 23., szerda - 16:01 )

Nagyjából egy héttel ezelőtt elindítottam egy nyílt forrású projektet, melynek célja egy ingyenes, moduláris felépítésű, multiplatformos ügyviteli rendszer elkészítése.
A projekthez már ketten csatlakoztak, folyamatban van az adatbázis tervezése és a rendszerterv megírása, ez utóbbi az én feladatom. Mivel ez az első komolyabb projektem, azt kérném Tőletek, segítsetek összeszedni, hogy milyen ábrákat, leírásokat kell elkészíteni a rendszerterv részeként?

Én az alábbi eszközöket ismerem:

- Osztálydiagram
- ER-modell, Bachmann-diagram az adatbázisról
- Felhasználó felület terve (ablakok megtervezése, kapcsolat az ablakok között)
- Use-case diagram

Ti hogyan készítenétek el a rendszertervet? Mi az, amire nagyon oda kell figyelni és egyáltalán hogy kell kinéznie egy korrekt rendszertervnek?

(A feladatspecifikációt megnézhetitek itt: http://www.martoncomp.hu/dl/szamlaseged_feladatspec.pdf)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

szerintem dia-t nézegesd.
a rendszerterveimet én eddig azzal csinaltam...
Igaz hogy ezek általában hálózatok voltak,
de adatbázisra tervezésre is lehet használni.

Köszi, ismerem a Diát, használtam is már. Azt tudom, hogy milyen programokat tudok használni a rendszerterv megírásához. Én igazából arra lennék kíváncsi, milyen lépésekből áll egy program rendszertervének elkészítése?

adatbazis tervezeshez kb hasznalhato megoldas - DBDesigner4 :
http://fabforce.net/downloads.php

ami linuxon utoljára évekkel ezelőtt működött....:)

Mükszik most is, csak kell neki néhány library, de sourceforge-on van egy fork, legutóbb mikor néztem kb. fél éves volt az utólsó feltöltés, és minden furfang nélkül elindult.

Általánosságban meghatározhatja a szükséges diagramjaidat, hogy milyen módszertant követsz. Jó eséllyel azonban a számodra szükséges kulcsszó az UML lesz, esetleg a RUP és variánsai is adhatnak útbaigazítást.

Magát a projektet hol lehet megnézni? Weboldal vagy valami? Ha csatlakozni akarok, satöbbi?

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Természetesen van weboldal, bár egyelőre csak a sourceforge-os "sablonoldal". A saját webhely készülőben van.

A projekt webhelye: http://szamlaseged.sf.net/

Itt van infó arról is, hogyan lehet bekapcsolódni a fejlesztésbe.

UML diagrammok készítéséhez tudom ajánlani az Umbrellát.(én a kde4-es verziót próbáltam)
Megvan benne az összes UML diagram, és egyszerűen tudsz belőle kódot is generálni. Azt hiszem a refaktoring is megy. Ja, és projekt szinten kezel mindent.

------------------------------------------------------
Aki utoljára nevet, annak van 56k-s modeme.

Én ilyenekre egy jól összerakott Eclipset használok. PDT, UML meg minden fittyfene...

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Nah, ehhez nem volt még türelmem. De jól hangzik, úgyis mindent Eclipse-el csinálok amit tudok.

------------------------------------------------------
Aki utoljára nevet, annak van 56k-s modeme.

ha nincs turelmed, hasznalj netbeanst ;-)

Fordítással, anyázással, szerencsétlenkedéssel, letöltéssel, plugin vadászattal olyan másfél óra és használható az eredmény

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Nem kekeckedésképpen, de miért éri meg n+1-ik ügyviteli rendszert elkészíteni, amikor nagyon sok OS rendszer van a 'piacon'?
Legtöbbször a számla moduljukba bele kell nyúlni, és ha még nincs (vagy rossz, részleges) a fordítás hozzá, azt el kell készíteni.

Komolyan kérdezem.

Én úgy érzem, megéri. És tisztában vagyok azzal, hogy léteznek már nyílt forrású ügyviteli rendszerek. Talán az lehet itt a különbség, hogy akár egyfelhasználós, akár hálózatos (LAN, WAN) kiadásban akarja egy cég használni a programot, ingyen megteheti. Maga a rendszer ingyenes lesz és az is marad, esetleg majd a modulokért érdemes lehet elkérni kisebb összegeket.
Egyébként a "trükk" a terméktámogatásban rejlik. Valószínűleg több vállalkozás is fel fog figyelni erre a projektre az ingyenessége miatt. Letölti, kipróbálja, megtetszik neki, és elhatározza, hogy a Számlasegédet szeretné használni. A projekt weboldalán látja, hogy a fejlesztők terméktámogatást nyújtanak a programhoz. Ha az illetőnek igazán számít az, hogy kap-e szakszerű segítséget a program telepítésével és használatával kapcsolatban, akkor megrendeli a supportot. Ez persze már nem lesz ingyenes. Így lehet némi üzlet az egészben.
De ha elkészül a program, nekem már az is nagy előrelépés lesz, ugyanis szerintem rengeteget lehet tanulni egy ilyen programból (pályakezdő programozó vagyok).

Supportot adhatsz pénzért bármelyk OS rendszerhez, ha beleástad magad.
És nagyságrenddel kevesebb meló.

Ez az uzleti modell elvben szepen hangzik, de gyakorlatban nem annyira mukodokepes, szerintem.
Egyreszt ott kezdodik, hogy hogyan lesz a kedves felhasznalonak egy nyilatkozata a megfelelossegrol. Gondolom nem fogsz ingyen adni mindenkinek egy ilyen nyilatkozatot, amivel magadra vallalod a felelosseget, a felhasznalo meg nem fog maganak irni egyet, ha egyszer nem erti meg a program forrasat sorrol sorra.
De ha ettol eltekintunk, akkor jon a kovetkezo problema: azok akik az ingyenes alapverziot hasznaljak, azok nem fognak elofizetni a supportra, akik pedig fizetnenek erte, azok nem altalanos rendszert szeretnenek valamilyen supporttal, hanem inkabb rajuk szabott specialis programot, amit raadasul mar nem is engednek beletenni a kozosbe ("nehogyma' a konkurencia is ingyen ezt hasznalja ha en fizettem ki a fejleszteset" alapon). Raadasul akkor meg nem beszeltunk pl. a jogszabaly kovetesrol: mi a biztositeka az egyszeri felhasznalonak, hogy jovore is tudja hasznalni a rendszert es meg fog felelni az eppen aktualis jogszabalyoknak? Szoval rengeteg kotelezettseg keletkezik egy ilyen rendszerrel, amit nem biztos, hogy ebben a formaban teljesiteni fogsz tudni. De en azert szurkolok neked ;-)
Legalabbis nalunk ez a tapasztalat (bar mi nem kinalunk ingyenes verziot es ranezesre mas celkozonsegnek szol a rendszerunk, de sok evvel ezelott meg en is ugy gondoltam, hogy ingyenes verzioval hoditjuk meg a piacot, aztan kozben nem maradt ra kapacitas az egyedi specialis rendszerek mellett...)

Mert pl. egyik sem felel meg az igényeinek?

Én sokat megnéztem, a Ledger és hasonlók egyszerűen hányinger, ahogy kinéznek, van néhány komolyabb, azokhoz viszont elképzelhető, hogy nagyobb lendületet igényelne a kusztomizáció.

Ha neki szüksége van valamilyenre, és open source-ban fejleszti, ugyan kit zavar.
Ha Java EE alapú lenne, cross-platform desktop alkalmazás (tehát nem webes és nem a desktop alkalmazás turkál az adatbázisban, hanem alkalmazásszerveren keresztül...), tudna 1-2 specifikus dolgot, engem nagyon is érdekelne.

1) Kezdő programozóként felmérni, hogy mi felel meg a piac igényeinek....hmmm, hmmm.
2) Ledger valóban nem egy szépség, de van ahová elég (mondjuk én sem hittem volna).
3) Senkit.
4) Adempiere? Mintha szerepelne a célok között.

Oké, akkor megpróbálok ésszerű érveket és ellenérveket összeszedni:

Megéri, mert:

- tapasztalatot szerzek a teammunkában - már 3 tagból áll a csapat és nagy valószínűséggel lesz egy negyedik tagja is
- a fejlesztés által gyakorlatot szerzek a programozás terén
- ha elkészül a program, és kellőképp meg tudjuk hirdetni, akkor van rá esély, hogy sok céget érdekelni fog
- a programhoz írandó modulokat el lehet adni
- terméktámogatást lehet vállalni a programhoz, amit valószínűleg több cég is igénybe venne
- a piacon lévő ingyenes ügyviteli rendszerek mindegyikének van valamilyen komoly hiányossága - egyik túl primitív, hogy ténylegesen használni lehessen, másik meg nem elég felhasználóbarát (esztétikátlan, nehezen kezelhető GUI)

Nem éri meg, mert:

- sok hasonló projekt létezik már - a spanyolviaszt kétszer feltalálni nem érdemes (ahogy erre Te is rámutattál)
- bizonytalan, hogy lesz-e érdeklődés egy ilyen projekt iránt
- nyílt forrású, ezért nem biztos, hogy lehetséges nyilatkozatot kiadni hozzá
- a fejlesztésbe befektetett munka nem biztos, hogy megtérül, mivel a program ingyenes lesz

Hirtelen ennyi jutott eszembe. 5:4-hez az arány, tehát megéri. :P

Az utolsó kettőt nyugodtan törölheted.
A nyilatkozatnak az égvilágon semmi köze a forráskód nyílt/zárt mivoltához.
Attól hogy nyílt forrású (mondjuk GPL), nyugodtan adhatod pénzért is, esetleg plusz szolgáltatásokkal téve vonzóvá a saját céged által kínáltat. Például x év jogszabálykövetés, felelősségvállalási nyilatkozat a számlázó részhez stb.
Ja, és ha _tényleg_ jó lesz, biztosan lesz rá érdeklődő is :)

umbrello
bouml
argouml

"Ti hogyan készítenétek el a rendszertervet? Mi az, amire nagyon oda kell figyelni és egyáltalán hogy kell kinéznie egy korrekt rendszertervnek?"

Előszöris az, amit feladatspecifikácóként kaptál (?) egy kicsit kevés. Sokkal pontosabban össze kellene szedni a követelményeket, meghatározni hogy pontosan mit és hogyan kellene csinálnia a rendszernek. Szerintem legyen ez a legelső lépés. Ehhez eszközként a beszélgetés/telefon/papír/ceruza/openoffice kombinációt javaslom :-) (Azaz írd le pontosan, hogy mit is akar a megrendelő. A mostani specifikációba _bármit_ bele tudok magyarázni.)

Ha ezzel végeztél, azaz pár hét múlva, akkor esetleg érdemes lesz visszatérni mindenféle UML-re adatbázisokra meg hasonlókra. :-)

Azt hiszem félreérted, ez nem megrendelésre készül, ezt a feladatspecifikációt én írtam, egy olyan ismerős közreműködésével, aki valamennyire jártas az ügyviteli rendszerek terén (én nem vagyok az). A Számlasegéd egy általánosan használható ügyviteli rendszer szeretne lenni, már ha elkészül valaha is. De megint csak azt látom, hogy sokan hülyeségnek tartják, prog.hu-n már kaptam a fejemre, úgy látszik tényleg értelmetlen egy ilyen projektet fejleszteni... na meg semmi tapasztalatom nincs ilyen téren. Lehet, hogy hagyni kéne? És mondjuk el kéne menni a teszkóba árufeltöltőnek?

Egyébként köszönöm neked, hogy érdemben hozzászóltál a témához, a feladatspecifikációt megpróbálom kiegészíteni. Hangsúlyoznám, soha nem írtam még sem feladatspecifikációt, sem pedig rendszertervet (tudom, ez látszik), de mindent el kell kezdeni valahol. Én szeretném végigcsinálni ezt a projektet, ha nem lesz értelme, akkor elpazaroltam x hónapot az életemből, talán túlélem. De mindenképp meg kell próbálni. Én egy maximalista embernek ismerem magam (mások is), szóval gagyi, használhatatlan vagy esztétikátlan munkát soha nem adok ki a kezeim közül. De kezdem azt érezni, ez már senkit nem érdekel manapság. :(

Na szóval.
Elkellene dönteni elsősorban hogy mely feladatokat melyik szinten szeretnétek megoldani.
Ragaszkodik a projekt platformhoz/programnyelvhez/adatbáziskezelőhöz.

Ha nem specifikáljátok a programnyelvet vagy több programnyelven is elkészül a munka java részét az adatbázis kezelőre célszerű bizni( tárolteljárások, triggerek ...)

Ha ez igy van a specifikáció tartalmazza ezt.
A fugvények neveit vagy elnevezési terminologiáját, hogy a programozonak ne kelljen azon gondolkozni hogy mi lehet egy adott fgv neve... vagy egy egy problémát mely fgvvel oldjon meg.

Ezeket a programozokkal kell egyeztetni hogy olyan legyen a kiirás amit azok hajlandoak meg is valositani.

Első körben tisztázzátok azt hogy vékony kliens alkalmazást akartok irni vagy mást(pl. php, és a nyomtatások pdf -ből mennek).

A kiiras ilyen szempontbol nagyon kevés.

Ha vannak célok és nincsenek definiálva az eszközök akkor abból még simán lehet káosz.
....
kérdezősködjél.

Arra kiváncsi vagyok én is hogy multi platform/vékonykliens/.... vagy mit szeretnétek belőle kihozni.

A Számlasegéd desktop alkalamzásnak készül, SQLite vagy Firebird adatbázissal. Két kiadása lesz, egy egyfelhasználós (egyéni vállalkozóknak, kiscégeknek, ehhez lesz egy beágyazott sqlite) és egy többfelhasználós, hálózati (ehhez lesz a Firdebird).

A nyomtatás már a kiadott bétaváltozatban is PDF-alapon működik, az adatbázis esetében meg gondolkozom azon, hogy tárolt eljárással vagy forrásba beágyazott lekérdezésekkel oldjuk-e meg.

Egyébként tisztán C#-ban lesz fejlesztve az egész.

akkor már miért nem embedded firebird?
Ha nem muszáj, minek két DBMS-sel vesződni!

Mert tökmindegy, a programon nem kell változtatni ha kicseréled alatta az adatbáziskezelőt, a program konfigjában kell megváltoztatni, hogy hol keresse az adatbázist. Más ha jól csinálod :-)

Ez ebben a formában nem egészen állja meg a helyét.

Miért nem?

Minden DBMS eltér vmennyire az SQL szabványoktól, van mit kénytelen vagy a kliensekkel elintézni, gondolj csak egyszerűen a DBMS hibaüzeneteire. Ahhoz, hogy egy DBMS-t csak úgy kicserélj egy tisztességes kliens alatt, ahhoz meg kell egyezzenek a hibaüzik. Vagy nézd meg a DBMS-ek jogosultságkezelését.
Öszintén megvalva egy DBMS-sel sincs elég tapasztalatom - nemhogy többel - de ezt a két dolgot figyelembevéve, számomra elégséges indoknak tűnik ahhoz, hogy ne lehessen csak úgy egyiket kirántani, másikat alápkolni a kliensek különösebb felkészítése nélkül.

ORM? Meg ha nem is ORM, manapság már mindenféle színes-szagos framework-ök vannak, hogy ezt a problémát minimalizálják, legalábbis a java világban.

Nem azt mondtam, hogy nem megoldható, csak kisebb-nagyobb problémát jelenthet a megvalósítása.
Ráadásul, ha esetlegesen a kliensek lekérdezéseit is optimalizálnod kell, akkor halott a dolog.

Jogos a kérdés. Úgy láttam, picit macerás Linux alatt beállítani a Firebird beágyazott változatát. Ezért választottam az SQLite-ot.

Szerintem ez az egyik legrosszab indok, amit mondhattál.

Tudom, de más nem jutott az eszembe. :)

Véletlenül sem tartom hülyeségnek azt, amit csinálni akarsz. Legalább egy nagyon nagy haszna van: ha végigcsinálod, akkor komoly tapasztalatot fogsz szerezni olyan téren, hogy hogyan kell végigcsinálni egy ilyen projektet. Szeirntem nem tudod elképzelni sem, hogy mennyire kevés olyan ember van Magyarországon, aki ezt jól csinálja... :/

A feladatspecifikáció kibővítésénél szerintem a következőkre figyelj oda:

- Magyarázd meg a fogalmakat úgy, hogy az ügyviteli rendszerekhez nem értő programozók is felfogják, hogy miről van szó. Mi az a telephely? mi az a cikktörzs? Milyen adatok szerepelnek az egyes számlatípusokon, pl. egy csekken? Emögött az a motiváció, hogy a programozó nem biztos, hogy ezeket csak úgy tudni fogja. Ha Te sem tudod és jófej akarsz lenni, akkor megtanulod, ha kevésbé akarsz jófej lenni, akkor legalább azt beleírod a doksiba, hogy a programozó pontosan honnan fogja tudni kideríteni ezeket.

- A bővítésnél érdemes arra is odafigyelni, hogy NE arról szóljon, hogy hogyan kell megcsinálni valamit, hanem arról, hogy mit kell megcsinálni. Ezt szerintem szépen tartja eddig a dokumentum.

- Ami még fontos lenne, hogy gondold át a doksiban írtakat az adatáramlás szempontjából, és itt nem adatbázisokra meg az elérésükre, vagy hasonlókra gondolok, hanem pl. arra, hogy a valutakonverter honnan fogja tudni, hogy az átváltáshoz szükséges arány micsoda? Kézzel lehet majd megadni a rendszernek? Valamilyen publikus szolgáltatás szabadon elérhető árfolyamértékeit fogja használni?

Azt azért még hozzátenném, hogy ha csinálsz egy ilyet, azt nem rendszertervnek hívják, hanem követelménydokumentációnak. A rendszerterv elkészítése leginkább akkor kezdődhet majd, ha a követelményeket elolvasva nem nagyon merülnek fel kérdések azzal kapcsolatban, hogy mit is kellene csinálni. Ez egyébként egyáltalán nem jelenti azt, hogy ezek után a követelmények már nem fognak változni, csak azt, hogy a követelmények már érthetőek. Fontos különbség :-)

A rendszerterv kapcsán a következőket érdemes kiemelni szerintem:
- adjon egy általános, könnyen áttekinthető, magasszintű nézetet a teljes rendszerről
- legyen egységes koncepciója a rendszer kapcsán, amelybe beleillik minden egyes elem (!)
- tagolja a rendszert kisebb, áttekinthető részrendszerekre
- deklarálja pontosan, hogy melyik részrendszer melyik másikakkal kommunikálhat (!)
- adja meg, hogy melyik alrendszer milyen adatokat ad a kommunikáció során más alrendszereknek.
Ha eddig megvagy, akkor lehet ismételni ezt a folyamatot az egyes modulokra. Ezen a szinten már szépen lehet osztálydiagramokat, szekvenciadiagramokat és hasonlókat rajzolgatni, itt jönnek a képbe igazán.

Ha már ennyit szövegeltem: azt próbáld meg elérni, hogy az egész összeálljon csak a dokumentációk alapján is egy egységes, lezárt egésszé. Ezt tökéletesen elérni sosem fogod, de az erre irányuló törekvések hosszú távon mindenképpen meghozzák gyümölcsüket.

Köszönöm. :)
Most épp arra várok, hogy elkészüljön az adatbázis szerkezete, emellett megkértem az egyik társfejlesztőt, aki valamennyire ért az ügyvitelhez, hogy szedje össze, milyen adatokat kell szerepeltetni az egyes bizonylatokon. Ha ezek meglesznek, már sokkal konkrétabban meg lehet írni a fejlesztői doksit. Legalábbis remélem, így lesz.

Úgy veszem észre, Te már csináltál ilyet. Megkérdezhetem, hogy mivel foglalkozol?

Gondolom az adatbázisban valamilyen módon tárolni fogjátok a bizonylatok adatait. Hogy fogjátok kitalálni, hogy mit kell tárolni az adatbázisban, mielőtt össze lenne szedve, hogy mik szerepelnek a bizonylatokon? Szerintem célszerűbb lenne először kideríteni a számlák adatait, és utána megtervezni az adatbázisrészt, amelyben a számlák adatai tárolva lesznek. (Persze ha az adatbázis tervezője bevállalja, hogy összeszedi ezeket helyetted, akkor ne utasítsd vissza :-D )

Igen, csináltam már ilyet, bár konkrétan számlázó vagy ügyviteli rendszert nem, és C#-pal vagy .NET-tel sem foglalkoztam sokat, inkább Java/JEE az, amit ismerek. Viszont Ti itt egy GUI-s alkalmazást akartok csinálni és ahhoz én is inkább a C#-ot javasolnám.

A mivel foglalkozol kérdésre pedig az az egyszerű válasz, hogy azzal, amit megfizetnek :-) Hivatalosan egy mobil tartalomszolgáltató cégnél vagyok üzemeltetési vezető, gyakorlatilag projektként jónéhány fejlesztési/migrálási/üzemeletésoptimalizálási projektben részt vettem már, illetve vezettem ilyen projekteket.

Segítő szándékkal írok. Amit egyszer már kitaláltak, azt ne próbáld meg még 1x kitalálni. (sőt, ha azt hiszed kitaláltál valamit, nagyon valószínű, hogy valaki előtted azt már legalább részbe kitalálta). Magyarul, ha bármilyen programot akarsz írni, akkor keress olyan alkalmazásokat (nem feltétlen FOSS), amik legalább részben teljesítik azt amit meg szeretnél csinálni. Találd ki a dokumentációjuk alapján hogyan működhetnek. Tedd hozzá a saját gondolataidat, írd le a nagyon részletes feladatspecifikációt (UML használati eset diagramokkal legalább), és csak utána jön csak a rendszerterv. Rendszertervezés során is a munkád minimalizálásával törődj: hogyan lehet minél több már meglévő, jó minőségű, dokumentált FOSS komponensre építened a rendszeredet.

Az ügyvitellel sokkal egyszerűbb dolgod van, mert semmit nem kell kitalálnod. Elmész az SAP oldalára, letöltesz pár ezer oldal dokumentációt, elolvasod, értelmezed, és 1-2 év múlva tudni fogod, hogy mit _kell_ egy ügyviteli rendszernek tudni. Ezek után majd reálisan el tudod dönteni, hogy érdemes-e egy ilyen rendszert megírni, vagy sem (befektetett munka, megtérülés, stb.). Ha ezt végigcsinálod, akkor talán inkább már meglévő megoldások fejlesztésén fogsz gondolkodni, pl. tinyERP.

Írtad, hogy pályakezdő vagy. Abból kiindulva, amit én tanultam egyetemen (de más magyar egyetemek sem sokkal jobbak, ahogy tudom), azt javasolnám, hogy inkább a módszertanok, technológiák megismerésével kezd. Az egyetemen nekem semmit, vagy semmi gyakorlatit nem tanítottak a következőkből: ORM, Tervezési minták, Extrém programozás.

Mindezt csak azért írtam le, mert nekem nem írta le annak idején senki. Bár, amennyire önfejű voltam/vagyok, lehet meg se fogadtam volna :)

Magáról a projekt céljáról: számlasegéd: Magyarországon a számlakészítő program fejlesztőjének nyilatkoznia kell, hogy a program a vonatkozó törvény követelményeinek megfelel. Nem lehet FOSS egy számlakészítő program Mo-n, ugyanis: értelmes ember nem ír alá egy ilyen dokumentumot kiadott forráskódhoz, mert a forráskódot módosítja a paraszt ügyfél, a jogi következmények meg a fejlesztőt terhelik.

Én is segítő szándékkal írok. Először is nem kell nyilatkoznia semmiről, a felelősség a felhasználóé, hogy legyen érvényes felelősségvállalási nyilatkozat a kezében (ami lehet self-made is). Ha a programkészítő nyilatkozik a felelősségről, azt nyilván az ingyen elérhető program x vagy y release-ére fogja tenni. Ha valaki nem azt használja, nem érvényes. Ennyi.

A többiről meg. Jó nagy szarban lennénk, ha mindenki csak akkor állt volna neki programozni, ha már kívülről-belülről ismert egy problémát, és még nem létezett másik megvalósítás. Az én időmben hobbiból Turbo Pascal-ban kódoltunk Nibbles és hasonló játékokat. Nem kellett volna, mert már volt másik? Igen, mondtak ilyet, (olyanok, akik soha nem tudták volna megírni).

Én is értelmetlennek tartom a Pistike Bt.-féle ilyen-olyan langyos projekteket, de tegyünk különbséget a rendelésre történő megélhetési programozás között és aközött, amikor valaki szenvedélyből csinál valamit, hajlandó 5x újraírni, stb. Ha hobbiból csinálod, akkor nem TinyERP-t akarsz reszelni! Az ügyviteli szoftver helyett lehetne itt GNU tar reimplementáció, vagy akármi.

Egy szóval sem mondom, hogy én jelen formájában nagy jövőt jóslok a projektnek (talán, 1-2 újragondolás-újraírás után, ha még akkor is úgy gondolja), az a lényeg, hogy elkezdett valamit csinálni.

Azt meg mindannyian tudjuk hogy az egyetemet, az ORM-et, a design patterneket, az UML-t és úgy általában az összes többit fel lehet dugni magadnak, ha nem szeretsz programozni. Azt meg nem Hibernate-tel fogod megszeretni, azt garantálom :) Tehát mint üzleti szoftver, engem is irritál egy Firebird adatbázis, amihez ráadásul egy desktop ablak kapcsolódik, de nem örültem volna anno ha vmi 3D kóder beszól a nibbles programomra (lehet most pék lennék vagy valami). Ha ráérez a dologra, akkor az első újraírásnál majd másképp csinálja.

> Először is nem kell nyilatkoznia semmiről, a felelősség a felhasználóé, hogy legyen érvényes felelősségvállalási nyilatkozat a kezében

Melyik ügyvezető ír alá egy rendszergazda által készített, "self-made" felelősségvállalási nyilatkozatot? Ez vicc :) Na persze, ahol az ügyvezető a rendszergazda ott reális.

> A többiről meg.

Tényleg szarban lennénk, ha így gondolkodna az ember, de nem is erről beszéltem. Nem hobbi kódolásról van szó. A korábbi hozzászólásokban terméktámogatásról is esett szó.

Az 5x újraírás segít valamit szerinted? újraírni azért kell, mert olyan problémával találkoztál, amit ez eddig koncepciódban nem tudsz kezelni. Kérdezem, ki találkozott több problémával? a kezdő fiatal programozó vagy a kurva sok embert alkalmazó nagyvállalat? De nem azt mondtam az előbb se hogy másnak a megoldását kell lemásolni, hanem azt, hogy meg kell próbálni megérteni, hogy milyen problémák elkerülésére csinálták ők úgy a rendszerüket ahogy, és azt vedd figyelembe a saját rendszered tervezésekor.

> az a lényeg, hogy elkezdett valamit csinálni.

Ja, csak nem mindegy, hogy egy minőségi OS projekt születik, ami majd később érdemes lesz arra, hogy terméktámogatással rendelkező szoftver legyen (azaz a fejlesztő célja megvalósul), vagy fél éven belül megdöglő, 1 release-el és 0 download-al rendelkező valami ("hát legalább tanultam belőle valamit" projekt)

Ugyanaz az ügyvezető, amelyik eltenné az sf.net-ről származó nyilatkozatot anélkül, hogy fizetne érte :)

Hobbi kódolásról van szó, a terméktámogatás, lóvé, stb az álmodozás része, ami inspirációt ad. Ezután jön az a fázis, ahol majd kiderül, hogy tényleg komolyan gondolja-e.

Kb. 50 projekt van a céges SVN-ben ami hasonló módon indult, tehát kitaláltuk hogy majd pénz lesz belőle, persze így utólag semmi realitása nem volt, de szerintem elég sok jó projekt így indul. Ezek nélkül semmihez sem értenék (így se).

Semmi gond a "tanultam belőle valamit" projektekkel. A "kurva sok embert" alkalmazó nagyvállalatokról meg a probléma ismeretről annyit, hogy google://ügyviteli szoftverek, tölts le néhány demót, miután körbeokádtad az asztalt rájössz, hogy a rendszerváltás környékén felcsövesedett, volt TSZ elnökök vezette cégek se ismerik a problémát jobban, nem is tudnak jobban programozni, de ha eltekintünk a magyar helyzettől, láttunk már "nagy nevű" vállalatirányítású rendszereket is úgy összeborulni, a hibakeresés közben olyan elementáris hibákat találva, hogy nincs senkinek semmi szégyellnivalója sehol.

Meg azért egy számlázó-raktárkezelő program nem a világ, ha már félretetted az ERP célokat, appszervert, mit tudom én (tudom, hogy nem kéne), akkor gyakorlatilag a GUI minőségén áll vagy bukik a dolog, semmi máson :) Feltéve, hogy az alapvető logikát megértette valaki (miről milyen adatot tárolunk, mit jelentenek), dehát ez egy számla esetén nem túl bonyolult. Ha majd könyvelni is akarsz, meg mit tudom én, akkor igen, de itt szó sincs ilyesmiről.

Ez nekem már zavaros kicsit, de jó látni azt, hogy milyen jól elbeszélgettek :)

Nagyon le akarnak itt beszélni néhányan erről a projektről, és sajnos az a baj, hogy valamiért nagyon befolyásolható vagyok ilyen téren.

Van még olyan egyáltalán, aki szerint érdemes egy ilyen projektre munkát és időt áldozni? Most eléggé elkeseredtem. :(
Azt hittem, végre elkövetem az első értelmes dolgot az életemben, de ezek szerint tévedtem. Akkor marad a tecsó árufeltöltő. :) Ahhoz talán nem kell túl nagy tehetség/intelligencia/üzleti érzék.
Az emelt szintű programozó végzettségemet meg kirakom a falra a CCNA négy tanúsítványával együtt, közvetlenül a "Kresz tilalmak" című plakát mellé. :)
Mit javasoltok? Szerezzek meg 4 diplomát, plusz 6-7 év szakmai gyakorlatot és utána jusson eszembe a dolog újból? :)

Amúgy meg egy kis ízelítő belőlem: http://www.martoncomp.hu/dl/kiss_gergely_-_hazam.mp3

Zongora + ének by me.

A saját topikomat hadd offoljam már szét. :D

Ne hagyd magad! :) 2 éve elkeseredetten keresek egyszerű(!) és normális GUI-val megáldott számlázó programot, fizetnék is érte (és nem csak én, itt a hupon már nem egy "számlázót keresek linuxra" topic volt). Már én is ott tartottam, hogy elkezdtem tervezgetni egyet (sőt, nemrég kódolni is nekiálltam -szintén Mono/Gtk#-, de ez egyelőre inkább csak gyenge próbálkozás a tiédhez képest).

Én kicsit egyszerűbb programban gondolkoztam, mivel alapvetően a saját igényeimből indultam ki, ezért pl készletkezelést eleve nem akartam. Annó windows-on a "Profit társ lite" nevű ingyenes kis program volt a kedvencem. Kb semmit nem tud, csak számlát rögzíteni, nyomtatni, az egyszer már bevitt ügyfeleket és tételeket (termékek, szolgáltatások) eltárolja. Abba gondolkoztam, hogy egy ilyen alap program kéne, első körben egy felhasználós verzió SQLite backenddel, következő lépésként többfelhasználós MySQL backenddel, illetve valamilyen "plugin" rendszerrel megoldani, hogy bővíthető legyen (pl készletkezeléssel, vagy egyéb egyedi igényekkel).

Nem tudom a Te terveidbe mennyire fér bele egy nagyon alap tudású verzió elkészítése, amit feljebb vázoltam? Ha belefér, akkor megosztom veled a GUI terveimet(pl szamlazo3.ogg). Esetleg beszállnék valmaiylen szinten a fejlesztésbe (azért fogalmazok óvatosan, mert nem vagyok profi programozó). Ha nem érdekel a dolog, akkor viszont lehet felhasználnék pár dolgot a kódbázisodból és mennék a saját fejem után :)

A teljes forráskód fent van a projekt oldalán (http://szamlaseged.sf.net), azt csinálsz vele, amit csak szeretnél. GPL alatt van, úgyhogy szabadon másolhatod, átírhatod, akár könyvet is írhatsz róla. Én végleg befejeztem a projektet. Sajnos. :(

Nemár, ennyire elvették a kedvedet? Pedig van a dologban fantázia, szvsz -kicsit jobban átgondolva az egészet- még üzletet is lehetne rá építeni...

Szerintem kár, hogy nem csinálod végig, de ha ez a döntésed, akkor tiszteletben kell tartani. Egyébként én mondtam valami rosszat? Nem állt szándékomban...

Egyelőre nem adom fel... Ma felajánlotta a segítségét egy egyetemista srác, ez kicsit újra visszahozta a lelkesedésemet. Aki azt mondja, hogy értelmetlen az egész, az várja csak meg, hogy elkészüljön a program első stabil kiadása, próbálja ki, és utána döntse el, hogy mennyire volt értelme megcsinálni. Többet nem hallgatok azokra, akik le akarnak beszélni erről a projektről. :P

Nem kell feladni! :)
Csak nem mindegy, hogy
- berohanok az alagútba, és vagy jön a vonat, vagy nem
- körültekintöen felmérem a terepet, és utána berohanok úgy az alagútba, hogy 99%-biztos vagyok benne, hogy nem jön vonat.
(Na, ez kicsit gyermetegre sikeredett.)

És továbbra sem válaszoltál a kérdésemre.

Válaszodban azt erősítetted, hogy miért is jó az elképzelésed. Bár az más FOSS rendszerekre is igaz.

".......és normális GUI-val megáldott számlázó programot, fizetnék is érte......."

Általában mikor tényleg fizetni kéne akkor még sem kell annyira. Volt és van is több számlázó program és fizetni senki nem akar érte. Szépen el is tűntek, befulladtak, tönkrementek, stb. Persze funkcionalitási és megjelenési igények lennének bőven...Csak pénzbe ne kerüljön és tenni se kelljen érte.

----- www.blackpanther.hu -----

+1

Mondd melyik programok azok. Mert amiket eddig én láttam, azok sehogy nem működtek.

"Persze funkcionalitási és megjelenési igények lennének bőven"

Hát igen, a hülye vevők, ügyfelek már csak ilyenek, hogy igényeik vannak. Fene megette. Talán ezeket az igényeket figyelembe véve kéne a programokat tervezni. Pl kezdjük ott, hogy senki nem akar a laptopján azért webszervert meg adatbázis szervert futtatni, hogy aztán egy ultra gányul összerakott, kényelmetlen webes felületen írja meg a számláit.

Te melyiket vennéd meg?

olcsó linuxos számlázó, készletkezelő:
http://www.lafisoft.hu/button/rakt_szla_nagyk_linux/kep/szamlapimp.jpg

vs

olcsó windowsos számlázó:
http://www.clearadmin.hu/szamlazo_program_kepek.php

Egyetlen olyan linuxos számlázót nem láttam még, aminek pl _normális_ Gnome-ba illeszkedő GTK-s GUI-ja lett volna, amit csomagkezelővel lehetett volna telepíteni (mondjuk a legnépszerűbb disztrókhoz, vagy legalább egy normális bitrock telepítője lett volna), meg amihez nem kell külön adatbázis meg webszerver backendet konfigurálni. Kézzel írok számlákat mióta linuxra váltottam, mert egyszerűen nincs normális számlázó (profit társ meg nem fut wine alatt). Ha lenne a kis cégeknek szóló 20e Ft-os kategóriában egy ilyen clearadmin vagy profit-társ színvonalú egyszerű, kényelmes program, bizisten megvenném.

Rossz embernek panaszkodsz, mert én ~8 éve használom a Lafisoft programot több helyen is, és mondhatni tökéletes megoldás annak aki kézzel írná a számlát. És csomagból telepíthető, ráadásul ehhez help mozi is van, persze jobb rendszerekhez :)))) (http://www.lafisoft.hu/download/bp_lafisoft_install.avi)

De ott volt az X-raktár is ami hirtelen eszembe jut, installerrel stb., aztán volt egy másik ami elhalt igény híján, a weboldala még létezik valahol, de a nevére nem emlékszem. Sőt, mi magunk is elkezdtünk csinálni egy ingyenes megoldást, de ahány felhasználó annyi nyafogás volt, de segíteni senki nem akart. Emiatt is született a postom.

A képen szereplő számlázó nekem egyáltalán nem szimpatikus, bocs. Persze neked ettől még megfelelhet.

----- www.blackpanther.hu -----

OK, mások az igényeink. Én érzékeny vagyok a "kinézetre" meg a desktop integrációra és meggyőződésem, hogy a szép -egyszerű, átlátható- GUI az fél siker. (2 azonos tudású program közül én azt választanám, ami passzol a desktopomba, tehát nem saját vagy őskori widget készletet használ, nem használja a GUI-n a szivárvány minden színét, átveszi a beállított támát/ikonokat, natív dialógusoakt használ stb). Lásd pl én meg ezt dobtam össze, mikor pár hónapja nekiálltam tervezgetni: számlázó GUI teszt (ogg video)

Ja tényleg, látom pantherhez van csomag :)), de gondolhatnának az olyan exotikus disztrókra is mint pl az ubuntu (erre nekem pl nem ment fel, 1x próbáltam) :)

Egyébként minden elismerésem a lafisoftnak, hogy már ilyen régóta fejleszti és még talpon van.

A fejlesztő eredendően a Wines verzióból él, hiszen a Linux-os elég kedvező feltételekkel kapható meg és akár ingyen is használható. Nekem a Lafisoft-os program megjelenése és használhatósága szimpatikus (persze én is tudnék változtatni), de ott van a Pergersoft-os program is (SmartStorage), eléggé jól megtervezett és akár nagyobb feladatokat is tud. De én egyszerű, kattintok és számlázok megoldásra a Lafi-s programot javasolnám. Hogy mit értesz azon, hogy nem megy fel, nem tudom, egy binary-t kell futtatni kicsomagolás után akár a kicsomagolt mappában és kész. Így az Ubuntu-n is mennie kellene. Csomag pedig azért van bP-re mert csináltam, még sem mondhatom egy vevőnek, hogy húzz le egy csomagot, bontsad ki valahova és onnan lehet számlázni.. Persze mindez ingyen másképp néz ki.

----- www.blackpanther.hu -----

"Először is nem kell nyilatkoznia semmiről..."

höhöhö.
Ha lövésed sincs róla, miért írogatsz??

A PM 47/2007. rendelet : 2008. január 1-jétől előírja, hogy minden vállalkozásnak, amely számítógépes szoftverrel állít elő számlát, a szoftver gyártójától a nevére szóló nyilatkozattal kell rendelkeznie arról, hogy az általa használt szoftver, illetve szoftververzió az éppen hatályos számlázási illetve adójogszabályoknak eleget tesz. A vállalkozás csak ennek a nyilatkozatnak a birtokában készíthet olyan számlát, amelyet az adóhatóság adóigazgatási bizonylatként elfogad.

és ez kire is hárít felelősséget? hol írja elő, hogy ha hobbiból készítek egy szoftvert, ami alkalmas számla nyomtatására, akkor nekem arról globális felelősséget kell vállalnom (lol)? A szoftver készítője annak nyilatkozik, akinek akar, a tényleges felhasználóé a felelősség, hogy rendelkezzen ilyen nyilatkozattal.

Na, ehhez hozzá tudok szólni. :) A fejlesztői nyilatkozat arra vonatkozik, hogy a program _rendeltetésszerű_ használatával kiállított számlák megfelelnek az áfa-törvényben, a 24/1995. PM rendeletben, meg még néhány egyéb rendeletben meghatározott követelményeknek.
És ezt a nyilatkozatot kiadhatom akár úgy is, hogy egy MD5 hash-értékkel rendelkező bináris kiadásra vonatkozik. :) Így ha átírnak valamit a forrásban, ami által a program a "jogellenesen" fog működni, az már nem az én felelősségem.

Ha még nem jöttél volna rá, ez egy jogászország.
Viszont a jogászok kevéssé ismerik az IT-t.
MD5 hash-ről pedig elenyésző (közel 0)%-uk hallott.
Jogszabály erre: 0 azaz NULLA.
Szopás faktor: 100%

Na, mégegyszer.

Ha a szoftver készítője nem nyilatkozik, akkor a felhasználó nem fogja használni.
Miért nem?
Mert nem felel meg - nyilatkozat hiányában - a PM előírásainak.
És ha mégis használná, egy APEH ellenőrzésnél nem fogadják el bizonylatként, és így a számla befogadója nem igényelhet vissza ÁFÁt a kiállított (nem)számla alapján.
Ha mégis megteszi, adóhiány állapítanak meg nála, megbírságolják, és késedelmi pótlékkal növel összeget követel rajta az APEH.
Big deal!

Tudod mit? Tényleg igazad van, nem kell a nyilatkozat.

Az egy más kérdés, hogy f@szság az egész nyilatokzósdi (is).

Ez az egész élet egy faszság, nekem nagyjából most van elegem mindenből.
De nem gáz, hallgasd meg mit alkottam, engem mindig feltölt energiával ez a szám! :)

http://hup.hu/node/54127#comment-545189

Szerintem ne ezt vedd le!

Elöször lépj kicsiket!

Jah, írjak egy pasziánszt, torpedót, kirakós játékot... akármit aminek 10-szeresen nincs semmi értelme... mégis mire gondolsz az alatt, hogy lépjek kicsiket?

Ha ennyitől elmegy a kedved, akkor igen, írj pasziánszt.

Nézzük az eddigiek negáltját.
Mindenki örül, hogy milyen jó ötlet és többen be is jelentik, bekapcsolódnának a fejlesztésbe.
Még gazdasági, sőt jogi szakemberek is jelentkeznek, így szakmai szempontokat is figyelembe tudtok venni.
De!
Hol vannak a célok?
Mi alapján született meg a döntés, hogy új rendszert kell írni?
Megvizsgáltad-e a fellelhetö FOSS ill. (általad fellelhetö) gyártóspecifikus rendszerekt?
Hová pozicionáltad az elkészítendö rendszert?
Mik a motivációs tényezök/célok rövid, közép és hosszútávon?
Stb, stb, stb.

Az az indok, hogy ifju tehetség vagy, és irgalmatlan sebességgel kódolsz hiba nélkül, (már) kevés a mai világban.
Abban gondolom egyetértünk, hogy olyat csinálni, amit már más(ok) is megcsinált(ak) n+1 példányban, nem érdemes.
Annál jobbat csinálni, na azt már igen! És itt a jobb nem (csak) arról szól jobb a kódbázis, az adatbázisterv, stb., hanem arról, hogy jobb a rendszer a felhasználó igényeinek kiszolgálásában.
És ez az a pont, ahol egy kezdö programozó el tud vérezni. Ha nincs valós kapcsolatod az igénnyekkel, csak kidobott energia, idö (és így pénz) az egész.

Valaki fentebb írta, hogy már régóta keres FOSS számlázót. "Ö már igény"! Kérdés, hogy konkrét elképzelése van, vagy csak számlát szeretne kiállítani egy ingyenes rendszerrel? (És utána elvárja, hogy folyamatosan megfeleljen az, kis hazánkban folyamatosan változó jogszabályoknak.)

Szóval ha nagyban gondolkodsz, akkor ne a közepéröl kezdjél tervezni, vagy tényleg marad a pasziánsz.

"Hol vannak a célok?
Mi alapján született meg a döntés, hogy új rendszert kell írni?
Megvizsgáltad-e a fellelhetö FOSS ill. (általad fellelhetö) gyártóspecifikus rendszerekt?"

Ha nem gond én válaszolok:

- Jelenleg nincs linuxra olyan, ami megfelelne (kis cégnek, egyszerű GUI, egyszerűen kezelhető). Ami van, az mind vagy ágyúval-verébre egy kis -szolgáltatásokat értékesítő- cég szemszögéből, vagy khmm.. nem úgy néz ki, nem úgy működik, ahogy elvárható lenne 2008-ban (kb az egyetlen alternatíva ma a Lafisoft számlázó, de annál rondább GUI-t még életemben nem láttam, és amikor ubuntun az install script valami karakter kódolás beállítását kérte (persze, majd átállítom a rendszert utf8-ról iso8859-2-re, 1 program kedvéért), akkor ment a kukába az egész (deb/rpm csomag nincs belőle, ilyen az, amikor a fejlesztő a saját feje és nem az igények után megy)).

- Sok helyen olvastam/hallottam már, hogy igény lenne ilyesmire, és úgy gondolom, hogy ez az igény egyre inkább nő.

- A linux gyorsan terjed, sok kis cég szívesen váltana, az egyetlen ellenérv lassan csak az lesz, hogy nincs számlázó és/vagy raktárkezelő és/vagy könyvelő program, meg egyéb egyszerű nyilvántartók, amik egy kis cégnek kell(het)nek (pl útnyilvántartás).

Szerintem ezen igényekre válaszolva -jól átgondolva, jól kitalált kapcsolódó szolgáltatásokkal- lehetne ebből üzletet is csinálni. De amíg az ember csak agyal, addig nincs semmi. Egy alap ingyenes verzió kiadása után már jobban látszana(visszajelzésekből, jelentkező plusz igényekből), hogy merre érdemes továbblépni.

1) OK
2) Azzal vitába szállnék, hogy a vállalkozói réteg verné az asztalt, hogy Linuxos számlázóra van szükségük. Nekik egy támogatott, jó számlázó kell, amit egyszerü használni, mert sokan versenyezni tudnak egy 100-as szöggel is. :(
3) Igen, szerver vonalon. Desktop szinten 0,5%. Lásd: http://www.rankings.hu/index.php?page=Ranks:RanksPage&stat=21|OW (pipe szétbaxa a linket)
4) Igen, nincs ezzel gond, csak a 2. pont miatt nem az SMB alját kellene megcélozni, hanem a közép-felsö réteget. Oda meg már több kell, mint egyszerü számlázó.
Tudom, ügyviteli rendszerről volt szó a topicnyitóban, de az annyira szerteágazó, hogy az elsö lépés nem a rendszerterv, hanem a követelmények meghatározása. Csak ezzel jó pár hónapot el lehet tölteni. Ha nincs jó(!) követelmény specifikáció, milyen lesz, miröl fog szólni a rendszerterv?

"4) Igen, nincs ezzel gond, csak a 2. pont miatt nem az SMB alját kellene megcélozni, hanem a közép-felsö réteget. Oda meg már több kell, mint egyszerü számlázó."

Valamivel el kell indulni. Úgy gondolom, hogy sokan és sokszor azért szalasztanak el jó lehetőségeket -én is, pedig sok jó ötletem volt már-, mert túlkomplikálják a dolgokat.

Kanyarodjunk vissza az elejére: adott egy diplomamunka gyanánt elkészített számlázó program, ami gyakorlatilag kész van, némi csiszolgatás után használható lenne. Jelenleg a beleölt munkán kívül pénz nincs benne, nincs mit elbukni. Nem világmegváltásról van szó, korai azon gondolkozni, hogy hogy lesz ebből nagyvállalati ügyviteli rendszer. Azon kell gondolkozni, hogy hogy lehet a jelenlegi állapotot jó irányba folytatni, szerezni néhány ügyfelet, akik igénylik magát a programot és a mellé adott támogatást és/vagy egyéb szolgáltatást, aztán lehet agyalni, hogy merre tovább. De első lépésként ehhez kell a program, amire rá lehet fogni, hogy 1.0 és használható. Lehet először csak 5 ügyfél lesz, de aztán 1 év múlva lehet, hogy lesz 500. Vagy kiderül, hogy annyira kicsi az érdeklődés, hogy az összesen 10 ügyfél miatt nem érdemes vele tovább foglalkozni, ez is benne van a pakliban.

Igy van.
Nincs is ezzel gond.
Az a 'gond', hogy fel vagy-e készülve, arra a sok sallangra, ami a jogszabályokból következik?

Ma már nem lehet megtenni, hogy "ott van a stuff, használd, aztán reportolj", mert
ad 1. ki a szerzö?
ad 2. nyilatkozik-e a szerzö (ki is?), a megfelelöségröl?
ad 3. ha nem nyilatkozik, senki nem fogja, használni. Akkor meg minek?

Be kell valljam - mint gyakorló paranoiás - néha azt hiszem, hogy a kormányzat direkte ellene megy a FOSS-nak.

Persze, ezek olyan kérdések, amiket át kell gondolni. A dolog több féle képpen lehet életképes, szerintem:

1, Teljesen opensource alapon: kiadni a programot, befejezni, aztán lesz ami lesz. Lehet, hogy lesz cég aki mögé áll és felveszi a kínálatába a windows megoldásai mellé, lehet lesz cég, aki mer hozzá kiállítani nyilatkozatot (magának, vagy másoknak is, pénzért).

2, Eleve céges alapon -ettől még lehet opensource-, cégként vagy vállalkozóként vállalni a felelősséget, kiadni a nyilatkozatot. Ki kell találni valami életképes konstrukciót. Pl: a nyilatkozat az általam kiadott stabil X verzióhoz jár, Y összegért. A felhasználókat regisztrálni kell (ezt windowsos számlázóknál is így csinálják). Ha valaki belemókol és nem az original vásárolt verziót használja, az nem az én felelősségem (ennyire azért nem kell parázni imho, senki nem fogja megbuherálni a programot, mert semmi értelme, csalni máshogy is lehet, egyszerűbben. Pl számlakönyvet simán veszek papírok nélkül, meg céges pecsétet is csináltatok - szomorú tapasztalat (bt-m van, de 1-2 esetet kivéve még sosem kértek tőlem semmi igazolást)).

3, Nyílt forrás, de egyedi licensszel. Saját verzióhoz jár a nyilatkozat, a forráshoz meg felelősségvállalással (= egy aláírt nyilatkozat fejében) lehet hozzájutni, miszerint mindenki saját felelősségre szórakozzon vele, ezzel te be vagy biztosítva.

4, Zárt forrás.

Hm, egesz jol tolod a muzsikalast, az enek sem rossz. Gratulalok. :)

Köszi. :) Nagyon szeretem a zenét.

Csak egy kerdes - Az adohatosag kepes bevizsgalni az adott szoftvert, es kiallitani rola egy nyilatkozatot, hogy eleget tesz a hatályos számlázási illetve adójogszabályoknak?

Nem, mivel;
"a szoftver gyártójától a nevére szóló nyilatkozattal kell rendelkeznie arról, hogy az általa használt szoftver, illetve szoftververzió az éppen hatályos számlázási illetve adójogszabályoknak eleget tesz."

Ebben csak az a bokkeno, hogy minden jogszabalyt lehet igy is, meg ugy is magyarazni. Ki fogja eldonteni melyik magyarazat a helyes? Palyafutasom alatt volt mar olyan esetem, hogy megyenkent maskepp ertelmeztek ugyanazt a jogszabalyt. Termeszetesen mindenkinek az altala kert modon szamitott eredmenyeket produkaltam. En magam sem tudtam eldonteni, melyik a helyes. Ilyen esetben akkor mi van?

Masik aranyos esetem , allami hivataltol hozott a polgar igazolast. Az egyik soraban ez a szoveg volt "Adozva PC szerint". Na ettol is hanyatt vagtam magam.

Üdvözöllek jogászországban!

Az APEH ilyet nem csinál, és a jogszabályok szerint erre nincs is szükség.

Akkor milyen jogon adhatok ki ilyen nyilatkozatot?

Nem az APEH fele van szerintem kotelezettsege a szoftver cegnek, hanem a vevo fele.
A vevonek van viszont kotelezettsege van az APEH fele. Az APEH-nak meg egy adu asza, hogy szamlakat vegyen ki, mert valaki elfelejtett kitolteni egy tok felesleges papirt. Miert is van Mo-on feketegazdasag?

Mas dolog ha fekete dobozt kell hasznalnom, de ezeket az adohatosag evidalja, es idonkent ellenorzi. A fekete doboz tartalmat osszeveti a papiron talahato adatokkal.

De tovabb menve - Kit fog terhelni a rossz adat bevitelbol eredo kar. Ezeket lehet a legnehezebben kivedeni. A szoftver ceg maximum az tudja allitani, hogy minden ismert lehetseges hibaforrast kikuszobolt. De mindig vannak expertek, akik felfedeznek valamilyen uj modszert:)

A felelőséggvállalási nyilatkozat kiállítója nem a számlák tartalmáért vállal felelősséget jelen esetben, hanem azért, hogy a programmal kiállított számviteli bizonylatok megfelelnek a számviteli törvény, és egyéb rendelkezések által támasztott követelményeknek.
Gyakorlatilag ez azt jelenti, hogy a programmal készített számlákon feltüntehető minden szükséges tartalmi elem (eladó neve, címe, vevő neve, címe, szükséges dátumok, a tételek megfelelő részletességgel, áfa tartalom, stb) illetve a sorszámozás folyamatos, és kihagyás nélküli.
A nem rendeltetésszerű, vagy hibás használatból adódó felelősség egyértelműen a használót terheli.
A felelősségvállalási nyilatkozat nem arról szól, hogy 24/7-es supportot nyújtasz a termékre!!!! Ez külön megállapodás kérdése.
Könyörgöm ne keverjük a szezont a fazonnal!

lol, valamirol lemaradtam. mind1

-

A prog.hu-n volt erről szó valamikor egy számlázóprogram kapcsán. Akkor írta valaki, hogy ő megvizsgáltatta az apeh-al a programját, akik egy külső céget bíztak meg. Azért ment át, többek közt, mert díjazták, hogy egy algoritmussal számolt egy véletlenszám mezőt a rekordokhoz, ezzel tudta volna visszaellenőrizni, hogy a felhasználó módosította-e az adatbázist kívülről.
Egyébként sok sikert a projekthez, szerintem szükség van rá, főleg, ha keresztplatformosra készíted.
A netacadémián volt egy oktatási anyag fenn, annak a témája, ha jól emlékszem MS Visual Studióval hogyan készítsünk számlázó progit. Talán nézd meg, bár az elsősorban a terméknek reklám.

Az nem véletlenül pénztárgépes rendszer volt? Számlázó programot nem kell engedélyeztetni, pénztárgép rendszereket viszont igen.

Ajánlom ezt az eszközt: http://www.visual-paradigm.com/
Igaz korlátozásokkal, de ingyen használható opensource projektekhez, nézegető meg teljesen szabadon van hozzá.
És sok sikert!

Róluk pozitív tapasztalatom van nekem is. Sokféle tervezős, diagramszerkesztős módszerre van alkalmazásuk, java alapúak ezért futnak több rendszeren is. Támogatást akkor is kaptam hozzá, amikor nem vettem meg a terméküket; gyorsan reagáltak, javították a hibát, sőt volt, hogy rendszerhibánál launchpad.net-es linket is küldtek:) (Ubuntut használok)

Eloszoris nagyon pozotiv a torekves, hogy specifikaciokat keszits a fejlesztes elott. Ez az open source vilagban meglehetosen ritka jelenseg, sajnos. Ugyanakkor a kerdesidbol az derul ki, hogy valoszinuleg nem sok tapasztalattal rendelkezen ezen a teren.

Igazabol nem is tudok jo konyvet sem ajanlani, mert en sem talaltam ilyet annak idejen. De megprobalok azert nehany kiindulasi pontot adni:
A feladatspecifiakcio nagyon fontos, es jo hogy megvan. Ez egy osszegzes. Mindig viossza lehet terni ra, jo attekintest ad, konnyu rola beszelni. A kovetkezo lepes egy reszletes kovetelmenyspecifikacio. Ez egy nagyon igenyes feladat, hiszen nem trivialis dolog ertheto, attekintheto, tesztelheto, konzisztens, teljes kovetelmenyspecifikaciot irni. Raadasul itt a GUI kovetelmenyek megfoglamazasanak kulon modszertana van. Na es ha mindez megvan, akkor johet a design (tervezesi) specifikacio. Errol nehez altalanossagban beszelni, hiszen minden feladat mast igenyel. De nagyjabol azt lehet mondani, hogy egy specifiakcio (ez igaz a kovetelmeyekre is) akkor jo, ha abbol a kovetkezo szint egyertelmuen szarmaztathato. Tehat olyan diagramokat es szoveges leirasokat kell kesziteni a tervezes soran, ami alapjan a feladat implementalhato. Tampont lehet meg, hogy jellemzoen a modellezest a statikus modellnezetekkel celszeru kezdeni, es dinamikus modellnezeteket inkabb csak a szukseges esetekben kell kesziteni. De tenyleg a feladat valaogatja, hogy mit igenyel.
Ez persze a fejlesztesnek csak az egyik aga, annak is csak egy resze. Szoval teljes fejlesztesi modszertanok vannak a legkulonfelebb alapelvekkel. Ezekrol meglehetosen draga tanfolyamok vannak, es nagyon keves jo es osszeszedett anyag, ami nyilvanosan is elerheto. Kozepesen sikerult muvekkel tele a padlas. ;-)

Szoval hajra.

Először is szeretnék gratulálni nektek, hogy egy ilyen projektbe belefogtatok, és azt kívánom, hogy sikerüljön létrehoznotok egy működő, szép és hasznos, sokak által használt programot.

Továbbá egy apróságot szeretnék javasolni hozzá. Jó lenne, ha a csomagban lenne valamiféle sablon szerkesztő modul, ahol egyedire tudná alakítani a felhasználó a számlát. És ezeket a sablonokat tudná aztán tényleges felhasználás előtt aktiválni, és a kívánt formában kinyomtatni a számlát. Talán ez a sablon módszer lehetővé tenné, hogy a felhasználó esetleges jogszabály módosítás hatásait képes legyen saját maga követni azáltal, hogy kivesz felesleges elemeket a számláról vagy beszúr új, szükséges elemeket.

Harmadrészt nagyon szívesen részt vennék a projektben, ha megfelelően kis feladatot tudnátok számomra találni. Ezt azért mondom, mert c#-ban még sosem programoztam, Szóval először azt kellene elsajátítanom. Most ismerem már nagyjából a C++ nyelvet, valamint a Qt4 csomag alapjait. Ugyanakkor dolgozó ember lévén nincs is túl sok időm a programozásra. (Egyébként gépészmérnök vagyok, tehát alapból nincs közöm a szoftveres világhoz.) Ha szükségesnek látod velem felvenni a kapcsolatot, akkor a felhasználói adataimban a "kapcsolat" fülben tudsz küldeni email-t.

Köszi az ötleteket és a jókívánságokat!

Írtam egy mailt, remélem, megkaptad.