SharpSzámla - számlázó rendszer linuxra

Szoftver

Nemrégen publikálásra került a SharpSzámla 0.5-ös verziója. A SharpSzámla egy multiplatformos, GPL licencű számlázó rendszer, amely a Mono .NET keretrendszerre épül ezzel biztosítva a bináris kód hordozhatóságát Linux és Windows operációs rendszerek között. A projekt célja egy olyan általános számlázórendszer biztosítása, amely módosítások nélkül átvihető az előbb említett platformok bármelyikére és egységes, letisztult, jól átgondolt és legfőképp a felhasználók számára könnyen kezelhető és áttekinthető felületet biztosít.

Mivel a rendszer még fejlesztés és tesztelés alatt áll, így az éles üzembehelyezést az alapos és széleskörű tesztelés előtt nem javaslom. Éppen ezért szeretnék felkérni mindenkit aki teheti és érdekelt lehet a témában, hogy töltse le és tesztelje a programot.

Legfontosabb technikai jellemzők:

  • C#-ban íródott
  • GTK-s felület
  • MySQL adatbázis backend

Rengeteg-rengeteg javítanivaló van még hátra és sok dolgot kell még implementálni a jövőben egy stabil használható verzió eléréséig. Örömmel fogadok minden építő jellegű hozzászólást és ötletet de legfőképpen segítők jelentkezését várom.

Honlap itt, képernyőképek itt. Telepítési dokumentáció itt (Online) és itt (PDF).

( uid_228 | 2006. 04. 20., cs – 14:36 )

Egy megjegyzés, egyelőre csak a képernyőképek alapján: ITJ szám helyett már nem VTSz-szám kellene?

+A wishlistbe :) : az egyes számlatételekhez jó lenne, ha lehetne egyedi megjegyzést hozzáfűzni. Egy példa: fölviszel a szolgáltatástörzsbe egy tételt, ami egy viszonylag általános dolog (pl. domainregisztráció). Az egyedi megjegyzéshez be lehetne írni, hogy milyen domain(ek)ről van szó konkrétan.

Várható ugye a számlázó kereskedelmi forgalomba helyezése? :)

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

Nem tudom pontosan, hogy mikor kell ITJ-t és mikor VTSZ-t használni. Jól jönne ha valaki kiokosítana ez ügyben :-)
Az egyedi megjegyzés számlatételhez jó ötlet. Egyedi mezőt már lehet hozzáadni a számlához, de számlatételenként még nem. Belekerül a TODO-ba ez is.
Mit értessz a kereskedelmi forgalomba helyezésen?

Van egy PDF az apeh honlapon meg a ksh honlapon is "szakmakod03" cimmel. Az ezekben levő sorokat nagyon hasznos lenne felvinni a progiba, hogy ki lehessen választani (miután a T. felhasználó beállította a tevékenységeit ezekre szűkül a dolog). Ebben az SZJ számok vannak, amik elvileg teáor kompatibilisek. A vtsz meg a vámtarifaszám, ami a vpop honlapon szerintem fentvan. Ez utóbbi kissé szerteágazó, de azt tom, hogy a számtek cuccok egyszégesen a 8471 alá esnek. :)

Azért az érdekes, hogy számlázóprogramhoz sokkal könnyebb hozzájutni, mint számlatömbhöz. A számlatömböt ugye csak cégkivonattal meg aláírásival lehet venni, de ehhez képest a számlázóproginál ilyeneket nem kértek tőlünk. Az más kérdés, hogy szénné van adminisztrálva.

Akkor a képernyőképek alapján mondom az alapvető észrevételeim:
- ITJ helyett VTSZ vagy SZJ típus választás
- beszerzési ár megadásának lehetősége
- előre definiált áfa csoportok és ebből lehet a termékhez rendelni (persze itt maga a kulcs is szerepelhet, csak nehezebb elgépelni)
- vevő postázási címe és valamiféle kapcsolat tartó megadása és emailcím mindenképpen
- számlák kifizetettségének megjelölése és a nem fizetett számlákhoz tartozó vevő mailcímre email küldése, mint fizetési emlékeztető
- partnerhez beállítható fizetési mód és határidő, mint "kedvence"
- áruhoz kéne leírás is, mint belső használatú megjegyzés

A mysql backend, ugye úgy lett lekódolva, hogy a konkurrens tranzakciókkal is jól megy. Arra gondolok, hogy egynél több munkaállomáson is számlázhatnak.

Egy juzer+passz alapú hozzáférés ellenérzős sem árthat, főleg a fenti esetben (telepítéskor megadható a kezdőjuzer, illetve ez lesz az, aki továbbiakat is tud létrehozni).

Az észrevételekhez no comment. Mind megy TODO-ba. Lesz mit csinálni :-)
A mysql backend konkurrens tranzakciókkal is jól megy, tehát pl. ha ugyanabban az időpillanatban jön létre két számla, akkor nem azonos számlaszámot kapnak, az egyik tranzakció lockolja a táblát amíg ír, a másik tranzakció pedig vár a sorára.
A user + pass authentikációt is meg kell oldani és ezt ki is felejtettem a doksiból. Ezt úgy szeretném, hogy opcionálisan lehessen mysql, ldap (OpenLDAP, Active Directory stb.) stb. authentikáció közül választani. Így amennyiben a telepítés helyén már van directory service a usernek nem kell még egy usernever + jelszót megjegyeznie, ha pedig nincs ds akkor mysql auth.

Na a belépéshez ez jó ötlet, erre nem gondoltam ennyire. :)

Az észrevételeket a való élet hozta, szoktam számlázni, nemcsak észnélkül levéstem neked, hogy a TODO-t dagadjon. :)

Ó igen mysqlhez mégegy gondolat, de ez csak mellékes. A natív SSL-es mysql kapcsolatot tudja kezelni ez? Bár lehet hogy helyi kliens függő, ennek annyira nem néztem utána.

Minden esetre ha szépen kifejlődik ez a progid, akkor könnyen lehet, hogy áttérek erre. Elég ígéretesnek tűnik. :)

( cashy_hu | 2006. 04. 20., cs – 16:52 )

Lehet, hogy nem jó helyen kérdezem, de Te biztosan utána jártál már: lehet ilyen programot használni Magyarországon? Nem kell engedélyeztetni az APEH-nél? Vagy csak a kiírt követelményeknek kell megfelelni?

Én is írtam anno (Clipperben:) számlázóprogramot, aztán jött a para, hogy nem lesz jó, mert az APEH. Akkor én abba is hagytam (mármint a kereskedelmi forgalmazását).

Van erről valami infód?

Ha a kereskedelmi forgalmazás alatt azt érted, hogy árulni a programkódot, akkor a SharpSzámlát ez nem érinti mivel a kód ingyenes.
Legjobb tudomásom szerint nyilatkozni kell, hogy a program megfelel azon formai és pénzügyi/számszaki követelményeknek melyeket a 24/1995 (XI.22) PM. rendelet, a 8/1999. (III.15.) PM. rendeletet módosító 8/2000. (II.16) PM rendelet, a 1991. évi LXXIV. tv. 13.§.-a és az Áfa törvény előír.
Ezt egy kicsit nehéz lesz összeegyeztetni a GPL licencel ha belefoglalom, hogy idézem:
"Az egyes szerzők és a magunk védelmében biztosítani akarjuk, hogy mindenki megértse: nincs garancia az ilyen szoftverekre. Ha a szoftvert mások módosították és továbbterjesztették, mindenkinek, aki a módosított változatot kapja, tudnia kell, hogy az nem eredeti. Így a mások által okozott hibáknak nem lehet semmiféle hatása az eredeti szerző hírnevére."
De biztos vagyok benne, hogy erre is lehet majd megoldást találni :-)

Levedeted a program nevet, es arra a nevre garantalod, hogy megfelel. Maga a programkod ettol meg GPL maradhat, deha valaki modositja, akkor nem hivhatja tobbe az altalad levedetett nevkent.

Vagy ilyet nem lehet?

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

Azzal egészíteném ki, hogy végfelhasználóknak bináris terjesztést javasolnék n+1 platformra. Ezzel egy plusz "önvédelmet" iktatnék be. Aki pedig hegeszt a forráson, az menjen saját apeh állásfoglalásért.

Egy webáruházas okosságon dolgozok épp és gondolkodtam, hogy milyen faxa lenne egy egyszerű számlázó hozzá. (Nem a sharpszamla adta az ötletet, már előtte is gondolkodtam ilyenen.) A fentieket olvasva, azt hiszem hogy ettől eltekintek. Ezzel szemben viszont valamiféle normális formátumú exportálását a számlázandóknak lehet hogy meg kéne oldani, amit, mondjuk a sharpszámla tud importálni, mint árukat és számla alapot (vevő, dátumok, határidők, áruk és összegek, valamint a tételek persze). Ez valami általam kevéssé szeretett XML-ben még jól is mutathat.

(Igazából valami nagyközös ilyen formátum kéne, hogy sokféle számlázóba lehessen ezeket importálni, biztos más webáruházas megoldásokhoz is jó lenne.)

Nem feltétlenül fogja az apeh elhinni, h a sorszámozás folytonossága biztosított, ha a felhasználó szabadon belepiszkálhat a kódba valamint a programból közkézen forog 453 féle hacked verzió.

Felhasználás előtt célszerű erre kérni egy állásfoglalást, mert iszonyú bukta lehet belőle (nem a fejlesztőnek, a felhasználónak ofkoz).

A másik dolog az, h erős kereskedelmi tapasztalat nélkül jobb bele sem vágni az ilyesmibe, mert ugyan nagyon egyszerűnek tűnik egy számlázó/raktárkezelő program, de az ilyenkor kötelező gyakorlatok: némi visszáru/előleg/rész/stornó számlakezelés (és ezek tetszőleges kombinációja), elosztott raktárkészlet, több számlázóhely, isoakármilyenkisfaszomnak megfelelő árukezelés brutálisan meg fogja bonyolítani a rendszert.

Kalandnak ellenben pompás ;)

Az APEH azt hisz el amit akar, a felesztőnek csak nyilatkoznia kell arról, hogy a rogram megfelel a törvényben előírt feltételeknek.
Ha az APEH ezt nem hiszi, akkor mehet a bíróságra, és neki kell bizonyítani, hogy a program ezt nem teljesíti. Az hogy ki mit módosít(hat) a program kódjában, már nem a fejlesztő felelőssége, hanem a felhasználóé. (Az már nem ugyanaz a program!)

Az APEH állásfoglalásai meg kb. annyit érnek a bíróság előtt, mint ha én írnék neked egy papírra bármit. Az APEH nem törvényalkotó, és ezt a Alkotmánybíróság (vagy Legfelsőbb, már nem emlékszem melyik) már megírta vala egyszer.

Ha igy all a helyzet, akkor csak annyit kell biztositani, hogyha valaki modosit a Sharpszamla programon, akkor azt mar nem hivhatja Sharpszamlanak. (ha megis annak hivja, akkor o vetett torvenyt).

Masik lehetoseg, hogyha valamilyen emblemat talal ki az ember. Certified by vbali;) Es akkor ezt az emblemat nem rakhatja ra masvalaki. (ezt mondjuk minden altala kinyomtatott lapra ranyomtatna).
Es ez a resze zart lenne, tehat csak az eloreforditott programba lenne benne. Ha valaki forrasbol forditana egyet, akkor annak ures lenne a lapja. Es igy lehetne penztis kerni a ,,hitelesitett'' programert.

Jol jonne egy IT szakmaban jaratos ugyved, aki megmondja a frankot;)

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

Az ügymenet mostanában úgy szokott zajlani, h ha ilyenkor az apeh talál pénzt számládon (akár 10 misit is), akkor azt leemeli inkasszóval, majd türelmesen kivárja, amíg a szakértői bevizsgálják a programot a lefoglalt számítógéppel egyetemben.

Ez is egy opció, de barátságosabb az állásfoglalás ;)

> 1. Hogy jön most ide ez az inkasszó dolog?

nyilvánvalóan úgy, h simán elküldheted a francba az ellenőrt, amikor a rendszer felől érdeklődik, de nem feltétlenül érdemes.

> 2. Lehet neked egy álásfoglalás barátságos, de attól még semmi sem ér.

Ez majd elmondom az apehnak is, a jelek szerint nem vágják eléggé.

1. Ki akarta itt elküldeni az ellenőrt a francba?
Nem válaszoltál arra a kérdésemre, hogy az inkasszónak mi köze ehhez a témához? Mármint ahhoz, hogy egy számlázó programról a szerzőnek nyilatkoznia kell. Nem kell az APEH-tól sem engedélyt, sem bevizsgálást, sem állásfoglalást kérnie.

2. Sok ember azt hiszi, hogy az APEH állásfoglalások valamiféle jogi erővel rendelkező kiegészítések a törvényekhez, rendeletekhez. Ez tévedés. Az APEH _nem_ jogalkotó!

> Nem válaszoltál arra a kérdésemre, hogy az inkasszónak mi köze ehhez a témához?

oppá, azt hittem, nyilvánvaló; apeh kijön, beleszagol a levegőbe és nem tartja elégségesnek a rendszert; nem mond semmit, majd leemeli a számládról a megelőlegezett bírságot és vélt elmaradt adókat indoklás nélkül. Majd kivizsgálja később, ha ráér.

Ha szerencséd van, akkor elnézést kérnek majd, de a pénzt semmiképpen nem kapod vissza; majd beszámítják a befizetéseidbe.

> 2. Sok ember azt hiszi, hogy az APEH állásfoglalások valamiféle jogi erővel rendelkező kiegészítések a törvényekhez, rendeletekhez. Ez tévedés. Az APEH _nem_ jogalkotó!

Nem erről beszéltem. A jogszabályok igen sokszor nem egyértelműek, illetve ellentmondóak. Amíg a jogalkotó nem módosítja, addig az állásfoglalások segítenek a helyzet tisztázásában, és általában figyelembe szokták venni őket.

Mivel a jogszabály nem rendelkezik a nyílt forrású számlázóprogramok ügyéről, ez egy ilyen eset. (A pereskedés egy más dolog, de pereskedjen az apeh-hal, akinek két anyja van.)

Csak egy állásfoglalás, nem fáj, na.

>oppá, azt hittem, nyilvánvaló; apeh kijön, beleszagol a levegőbe és nem tartja elégségesnek a rendszert; nem mond semmit, majd leemeli >a számládról a megelőlegezett bírságot és vélt elmaradt adókat indoklás nélkül. Majd kivizsgálja később, ha ráér.

Az APEH -ot nem érdekli a te számítógépes rendszered. Amíg a rendszered formailag helyes számlákat állít elő, addig őt a bizonylatok tartalma érdekli.

>Csak egy állásfoglalás, nem fáj, na.

Ha te úgy érzed, hogy valami nem tiszta számodra a törvényben, kérjél nyugodtan tőlük állásfoglalást. Nekem nem fog fájni :)

> Az APEH -ot nem érdekli a te számítógépes rendszered.

Ez nyilvánvalóan nem így van. Kérik a nyilatkozatot, dokumentációt, ahogy azt kell.

> Amíg a rendszered formailag helyes számlákat állít elő, addig őt a bizonylatok tartalma érdekli.

Ez akkor van így, ha előre sorszámozott nyomtatványra írod a számlát.

>> Az APEH -ot nem érdekli a te számítógépes rendszered.

>Ez nyilvánvalóan nem így van. Kérik a nyilatkozatot, dokumentációt, ahogy azt kell.

Pontosan így van. Csakis ezeket kérhetik. A programhoz semmi közük.

>> Amíg a rendszered formailag helyes számlákat állít elő, addig őt a bizonylatok tartalma érdekli.

>Ez akkor van így, ha előre sorszámozott nyomtatványra írod a számlát.

A formailag helyes alatt azt is értettem, hogy nem tud az ellenőr a sorszámok folytonosságát megsértő _számlákat_ (nem programot!) találni.

> A programhoz semmi közük.

Valóban, az apeh nem törődik a programmal. Ha szemre nem tartja megfelelőnek, akkor két (három) eset lehetséges:

a., az összes kiállított számlát semmisnek fogja minősíteni. Ez esetben a vevőid személyesen fogják véred venni.

b., az egész gépet, számlázóprogramostul, mindenestül elviszi, na nem az apeh, hiszen őket nem érdekli, hanem a rendőrség, te pedig kapsz egy aranyos idézést.

c., a fejlesztővel karöltve meggyőzöd, h a nyilatkozat komolyan vehető, már ha van komolyan vehető nyilatkozat a kezed ügyében.

>Valóban, az apeh nem törődik a programmal. Ha szemre nem tartja megfelelőnek, akkor két (három) eset lehetséges:

Tényleg nem értem miért erőlteted ezt az "ellenőr szemrevételezi a programot" szituációt. Az ellenőr a bizonylatokat ellenőrzi. Pont.
Ha esetleg van más tapasztalatod, szívesen meghallgatom :)

Kevés olyan idióta akad, aki úgy próbál csalni, h közben gubancos a könyvelése. Nem az a lényeg, h a papírok rendben legyenek. Az az alap.

Az ellenőr nem azért vizsgálja a bizonylatokat, h összeadogassa abakusszal és örüljön, ha talál 1 forint elütést.

Node, kezdem nem érteni, ezen mit kell magyaráznom :?

Semmit. Különbözőképpen látjuk az apeh ellenőr feladatait/jogait. Ezzel nincs semmi gond.

Kissé eltértünk viszont az eredeti kérdéstől.

>Lehet, hogy nem jó helyen kérdezem, de Te biztosan utána jártál már: lehet ilyen programot használni Magyarországon? Nem kell >engedélyeztetni az APEH-nél? Vagy csak a kiírt követelményeknek kell megfelelni?

Erre válaszoltuk többen is, hogy nem, nem kell. Csupán a formai követelményeknek kell megfelelni, és mellékelni kell a szerzőnek egy nyilatkozatot+dokumentációt. Ennyi.
Ha neked ez kevés, hát kérjél állásfoglalást az APEH-től.
Én csupán a véleményemet modtam el arról, hogy mit gondolok erről.

Az APEH inkasszózása nem ide tartozik (ezzel a módszerrel elmaradt befizetéseket, illetve "házon belül" lefolytatott ellenőrzések alapján kiszabott bírságot és késedelmi kamatot hajt be).

A számlázóprogram nem pénztárgép. Többek között számlázóprogramnál nem létezik a fekete doboz fogalma.
A program használhatóságának feltétele az, hogy
1. formailag helyes számlát állítson ki
2. ne lehessen a _programból_ a sorszámozás folytonosságát befolyásolni
3. valaki nyilatkozzon arról, hogy az 1995/24-es PM rendeletnek (alapvetően az előbbi két feltételnek) megfelel (ez lehet a program írója, de akár a felhasználó is, főleg, ha mondjuk házon belüli a fejlesztés)

Ha az APEH úgy gondolja, hogy a program nem felel meg a feltételeknek, akkor adócsalás gyanúja miatt feljelentést kell tennie, és rajta a bizonyítás terhe. (Aki netán manipulálja a sorszámozását, és erre menüpontot ír a programjába, az pedig meg is érdemli :)

>Nem feltétlenül fogja az apeh elhinni, h a sorszámozás folytonossága biztosított, ha a felhasználó szabadon belepiszkálhat a kódba valamint a programból közkézen forog 453 féle hacked verzió.

Azt hiszem itt kellet volna figyelmesebben olvasnom.
A lényeg az, hogy amiről te írsz az a pénztárgép esete. Ott van az az eset, amit te most a számlázó programokkal kapcsolatban gondolsz.
De a helyzet az, hogy a számlázó programmal kapcsolatban az APEH-nek nincs mit elhinni, vagy nem elhinni. Az ő jogosítványa csak annyi egy ellenőrzésnél, hogy az adott számla (nem a program!) formailag és tartalmilag helyes-e.

> Az ő jogosítványa csak annyi egy ellenőrzésnél, hogy az adott számla (nem a program!) formailag és tartalmilag helyes-e.

Oké, fussunk neki újra. A program igazolására a nyilatkozat szolgál. Pont az a gond, hogy egy 653 alkalmi programozó és foltküldő által jegyzett rendszernek nincs kiadója. Nincs, aki aláírja tudniillik. Megírja és kiadja A, ad egy nyilatkozatot. B letölti, kijavít rajt egy karaktert, újra kiadja, de ki adja a nyilatkozatot, A vagy B?

Szóval a nyilatkozatkérdésen már meg is bukott az egész (vagy nem, ezért kellene az a bizonyos tudodmi ;)

>Megírja és kiadja A, ad egy nyilatkozatot.

OK.

>B letölti, kijavít rajt egy karaktert, újra kiadja, de ki adja a nyilatkozatot, A vagy B?

Bárki a fejlesztők közül, aki meri vállalni a felelősséget.
Ha B meri (megbízik a saját javításában), akkor ő, ha modjuk A a project gazdája és esetleg B nem is csinálhat rilízt, akkor A eldönti majd, hogy csinál-e rilízt és ahhoz ad-e nyilatkozatot, vagy sem.

> Bárki a fejlesztők közül, aki meri vállalni a felelősséget.

"A" nem vállalhatja, mert nem fogja átnyálazni a kódot, h B mit turkált bele.

"B" nem vállalhatja, mert nem fogja átnyálazni a kódot, hiszen csak a számára fontos módosításokat végezte el, nem tudhatja, h nincs-e kiskapu/jelentős hiba a rendszerben.

Innentől nincs aki vállalhatná.

mar miert ne lenne? ha B csinal modositast, valoszinu azert, mert hasznalni akarja. namost meg kell bizinia az eredeti progiban, kulonben miert nez ra?? megcsinalja a modositast, es _arra_ a buildre amit o" keszitett valalja a felelosseget.

bar ha hiba van az eredeti progiban, akkor a B szivhat (az A is de az ettol fuggetlen), de a felelosseg nem az A-je, mert a sajat buildjet hasznalta!

Egy nyílt forrású project gazdája ugyanúgy megválogathatja, hogy kinek ad commit jogot, vagy kitől vonja meg azt, mint egy zárt forrásúé.
A te logikád alapján csak egyéni vállalkozók és egyszemélyes kft-k számára lehetséges számlázóprogram fejlesztése. Érdekes gondolat :)

A másik történet az, amikor egy hiba miatt valóban sérül a sorszámozás (kifagy lezárás közben/ több munkaállomás ugyanolyan sorszámú számlát állít ki zárolási hiba miatt), akkor a felhasználó a rá kiszabott soksok milliós bírság után a galandférget is kiperelheti a fejlesztőből.

( gdavid v | 2006. 04. 20., cs – 17:34 )

postgres-t is lehetne betenni. nem csipom a mysql-t.

A tárolt eljárást elmagyaráznád?

En erre gondolok:
Tárolt eljárás (stored procedures):
Megirunk egy fuggvenyt SQL-ben, es ezt elnevezzuk, majd ezekutan ezt a fuggvenyt hivogatjuk (ahelyett, hogy sok sql parancs lenne egymasutan).

http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html

Jol ertem?

ps: tehat ennek semmi koze mondjuk objektumok adatbazisban torteno tarolasahoz.

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

Átfutva (tényleg futva, kb. 10 percet foglalkoztam vele) a forráskódod, nem egészen értem a MySQL (pontosabban a tárolt eljárások) létszükségletét.
Ha már egyszer minden adatbázisműveletet a SharpInvoice.MySQL osztály függvényei végeznek, akkor bármilyen adatbáziskezelő lehetne a háttérben...

SZVSZ ha átlagfelhasználó kezébe akarod adni, akkor célszerű olyan megoldást választani, ami nem bonyolítja ennyire a dolgot (gondolom nem csak én találkozom olyanokkal, akiknek ha elsőre nem megy, csak annyit mondanak, hogy a Linux/BSD/akármi sz*r, marad a Windows-nál).

A multiuser egy nagyon előnyös tulajdonság, de a többség nem igényli. (A "kisebbség"-nek viszont nem okoz gondot a forráskódból telepítés :)
Nekem van egy csomó adatfeldolgozással foglalkozó kisebb programom, és általában az Sqlite-ot használom ilyen esetekben, többek között azért, mert ott van a Mono GAC-ban, és egy user-nek elég (pedig ezek többsége VS2005-ben készül - ami mellett ott az MSSQL 2005 - SWF felülettel, tehát erősen a Windows-hoz kötődik). Igaz, minden programomban van egy ISql interfész, és az azt megvalósító Sqlite-ot használó osztály, de bármikor átírhatom egy "nagyobb" adatbáziskezelőre az egészet. Viszont amikor odaadom mondjuk egy történésznek a programot, akkor nem kell még elmagyaráznom neki, hogyan pakoljon fel egy adatbázisszervert a gépére...

Ha már egyszer minden adatbázisműveletet a SharpInvoice.MySQL osztály függvényei végeznek, akkor bármilyen adatbáziskezelő lehetne a háttérben...

Most engem is elfogott a kivancsisag, es belelestem a kodba;)
(tiszta java-feeling btw)

Pl. az src/ContainerDialog.cs fajlban osszesen negy helyen hiv meg tarolt eljarast (stored procedure):

CALL sp_showpartners('nev')
CALL sp_showproducts('Megnevezes')
CALL sp_deletepartner(" + partnerTV.partnerItem.PartnerID + ")
CALL sp_deleteproduct(" + productTV.productItem.ProductID + ")

Ezen kivul a kovetkezo fajlokban van meg direkt SQL hivas (mind stored procedures):
PreferencesDialog.cs 27,56,40,62,80,139,149
InvoiceDialog.cs 97,150,199,231,315,336,368,424
PartnerDialog.cs 85,98
PrintInvoice.cs 93,115,149,167,419,434
ContainerDialog.cs 95,116,188,191
Main.cs 125,171,224
InvoiceItemDialog.cs 161
Misc.cs 199,215,231,276,290

Szoval mysql hivasok szet vannak szorva a kodban rendesen.
vbali: jobb lenne egy osztalybol hivogatni a MySQL-t szerintem.

A tarolt eljarasokra visszaterve:
Van jopar olyan tavoli eljaras, ami szerintem teljes mertekben felesleges. Peldaul:

CREATE PROCEDURE `sp_getuniquedesc`()
BEGIN
SELECT * FROM UNIQUEDESC;
END $$

Erre az egyszeru SELECT utasitasra minek egy egesz fuggvenyt hivni?

Amennyire en megertettem a mySQL doksijabol, ennek a tarolt eljarasnak akkor van ertelme, hogyha trigger esemenykent fogjuk fel. Tehat ha az egyik tabla valamelyik soran modositasz es ez kihatassal van a masik tabla valamelyik mezojere, akkor ezt egyszerre kell megcsinalni (eddig lockolassal csinaltuk. mondjuk lockolni mintha most is kene ettol(ket konkurrens procedure szerintem okozhat meglepetest, bar mysql imho kioptimakolja, es nem jon elo. De azert en csak lockolgatnek).)

Szoval tobb tablan vegzett muveleteket erdemes osszefogni egy fuggvenybe. Ez kenyelmi es teljesitmenybeli szempont.
Itt nem lenyeg a teljesitmeny.
Vegigneztem a procedure-jeidet, a sp_updateisstorno kivetelevel az osszes folosleges. (egyetlen parancsot hajtasz vegre mindenhol).
Teny, hogy atlathatobb, de sztem atestel a lo tuloldalara.

Tenyleg nem akarok okoskodni (meg kivulrol ez abszolut nem latszik), de szerintem igy kellene megcsinalni:
Minden mySQL parancsot egy osztalybol hivni. Minden SQL-es stored procedure-nak csinalni az osztalyban egy ugyanolyan nevu metodust, es azt kellene meghivni (es a metodus hivna meg a MySQL-ben levo stored procedure-t).

Igy tok egyszeru lenne kicserelni a MySQL-t mogotte, mivel csak az SQL-ben levo stored procedure logikajat kell a metodusban megvalositani (kulonallo parancsok szerint).

Es a mostani stored procedure-ok szamat 1-re lehetne csokkenteni (a mostani 32-rol).(a tobbi 31 teljesen felesleges sztem).

A stored procedure szerintem nem oldja meg a tranzakciokezelest btw.
(jo lenne ennek az ellenkezojerol doksit talalni).

...mert ott van a Mono GAC-ban,
Errol tudnal egy linket adni, hogy mi fan terem? Hogy mi (en) foldi halandok is ertsuk;)

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

Úgy látszik, félreérthető voltam, természetesen én is láttam, hogy van egy csomó direkt SQL-hívás a kódban, de pont azt próbáltam kifejteni, hogy a tárolt eljárásokra jelen esetben gyakorlatilag semmi szükség. (Az tényleg a triggerek esetében hasznos, illetve ha nagy hálózati adatforgalmat spórolna meg, de ahogy elnéztem, nem erről van szó.)

SQLite a Mono-ban: http://www.mono-project.com/SQLite
(maga az sqlitedll természetesen nincs benne, de azt elég egyszerűen letölteni és bemásolni az exe mellé)

de pont azt próbáltam kifejteni, hogy a tárolt eljárásokra jelen esetben gyakorlatilag semmi szükség.
Teljesen egyetertunk.

(maga az sqlitedll természetesen nincs benne, de azt elég egyszerűen letölteni és bemásolni az exe mellé)
Ahogy en nezem az SQLite-nak az az elonye, hogy eloreforditott binarisa van linux-ra es winre. Igy az alkalmazas melle lehet tenni. Raadasul egy .db fajl csupan az adatbazis, igy egy elore elkeszitett adatbazist is lehet mellekelni (akar nehany tesztadattal feltoltve).

Jol ertem?

A mono-hoz alapban ezek az adatbaziskotesek (bindings) jonnek (debian sid)
libmono-firebirdsql1.7-cil - Mono FirebirdSql library
libmono-npgsql1.0-cil - Mono Npgsql library
libmono-npgsql2.0-cil - Mono Npgsql library
libmono-sqlite1.0-cil - Mono Sqlite library
libmono-sqlite2.0-cil - Mono Sqlite library

Mondjuk nemigen ertem az 1.0 es 2.0 kozotti kulonbseget. Ahogy nezem a SharpSzamla 1.0 libekkel van forditva. Hol van ennek jelentosege? (lehet keverni is a libeket?)

Mysql bindinget is beletelt egy darab idobe mire rajottem, hogyan kell telepiteni.

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

Egyet is értek az általad említettekkel meg nem is. Igazat adok abban, hogy egy elszeparált osztályba lehetne megvalósítani a tárolt eljárásokat hívogató függvényeket így egy új adatbáziskezelő megvalósítása leegyszerűsödik. Ezt nem is tudnám máshogy elképzelni. Mivel jelenleg csak a MySQL támogatott ezért nem került külön osztályba ez a rész :-)
Amivel nem értek egyet, az az, hogy fölösleges tárolt eljárásokat használni mint pl.:

SELECT * FROM UNIQUEDESC;

Magam részéről amiatt részesítem előnyben a tárolt eljárások használatát, mert ezáltal az SQL utasítások teljesen el vannak szeparálva a programkódtól, ezáltal adott esetben kisebb módosítások nem igénylik a kód újrafordítását. Másrészt sokkal strukturáltabb lesz tőle a program, jobban áttekinthető a kód. Ha például elvégzek egy kisebb módosítást egy tárolt eljárásban akkor - mondjuk 10 kliens esetén - nem kell 10 helyen frissítenem a kliensprogramot is. Persze ez nem minden esetben kivitelezhető, ha a tárolt eljárás módosítása a kód módosítását is magával vonja.
Egy szó mint száz, a kód olvashatóságát egyértelműen javítja ha tárolt eljáráokkal vannak megvalósítva az SQL hívások. Ez az előnye. De mi a hátránya? Biztosan van valami hátrány is, de nem hiszem, hogy a hátrányok mértéke meghaladná az előnyökét. Ez persze szubjektív :-)
Képzeld el, ha az sp_updateisstorno a kódba kerül. Szép baleset lenne. Annak pedig végképp semmi értelme, hogy az SQL utasítások egy része tárolt eljárásba kerül, más része pedig a kódba.
Minden esetre örömmel tölt el, hogy vetted a fáradtságot és belenéztél a kódba. Ezek szerint valamennyire olvasható/érhető volt a kódom. Ha ez így volna nagy büszkeséggel töltene el, mivel valahol ez is az open source előnye. Néha tudok olyan kódot "generálni", hogy még én sem értem, hogy mit csinál :-)
Visszatérve a témához, épp a fent említettek miatt lenne szükségem minél több segítőre. Mint korábban említettem nem vagyok Postgres-hez értő. Ha valaki pl. segítene az "SQL függetlenítésben" jobban haladna a fejlesztés, nem is beszélve arról, hogy tesztelni is kellene. Sokat!!!

Ok, egy példa:
Ha a sztornozást nézzük, adatkezelés szintjén ez most vhogy így néz ki:

db.Query("CALL sp_updateisstorno(" + treeFej.invoice.InvoiceID.ToString() + ")");
db.FreeResult();

Ha az SQL utasítások a kódba kerülnek tárolt eljárás helyett akkor a következő utasításokat kell a db.Query-vel meghívogatni. 

	DECLARE NextInvoiceNumber VARCHAR(20);
	DECLARE lastid INTEGER;
	DECLARE IsOrder TINYINT(1);
	DECLARE origSzamlaszam INTEGER;
	DECLARE origPartnernev VARCHAR(50);
	DECLARE origPartnercim VARCHAR(106);
	DECLARE origPartnerBankszamlaszam VARCHAR(26);
	DECLARE origPartnerAdoszam VARCHAR(15);
	DECLARE origFizMod INTEGER;
	DECLARE origTeljesitesIdopontja DATE;
	DECLARE origSzamlaKelte DATE;
	DECLARE origFizetesHatarideje DATE;
	DECLARE origIsSztorno TINYINT(1);
	DECLARE origIsPrinted TINYINT(1);
	DECLARE origMegjegyzes TEXT;
	DECLARE origOrigSzamlafejID INTEGER;
	DECLARE origIsMegrendeles TINYINT(1);
	DECLARE tetelSzamlafejID INTEGER;
	DECLARE tetelTermek VARCHAR(100);
	DECLARE tetelMennyiseg INTEGER;
	DECLARE tetelAFA INTEGER;
	DECLARE tetelEgysegar INTEGER;
	DECLARE tetelKategoriaID INTEGER;
	DECLARE tetelITJ VARCHAR(10);
	DECLARE tetelMeId INTEGER;
	DECLARE tetelProductID INTEGER;
	DECLARE uniqueSzamlafejID INTEGER;
	DECLARE uniqueUniqueDescID INTEGER;
	DECLARE uniqueValue VARCHAR(255);
	DECLARE done INT DEFAULT 0;
	DECLARE curSZAMLATETEL CURSOR FOR SELECT
		SzamlafejID,
		Termek,
		Mennyiseg,
		AFA,
		Egysegar,
		KategoriaID,
		ITJ,
		MeId,
		ProductID
	FROM SZAMLATETEL 
	WHERE SzamlafejID = ID;
	DECLARE curUNIQUEFIELDS CURSOR FOR SELECT
		UniqueDescID,
		Value
	FROM UNIQUEFIELDS 
	WHERE SzamlafejID = ID;
	DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
	SELECT IsMegrendeles INTO IsOrder FROM SZAMLAFEJ WHERE SzamlafejID = ID;
	SELECT MAX(Szamlaszam) AS KovSorszam INTO NextInvoiceNumber 
	FROM SZAMLAFEJ
	WHERE Year(SzamlaKelte) = Year(Now()) AND IsMegrendeles = IsOrder;
	SELECT IFNULL(NextInvoiceNumber+1, 1) INTO NextInvoiceNumber;
	SELECT 
		Szamlaszam,
		Partnernev,
		Partnercim,
		PartnerBankszamlaszam,
		PartnerAdoszam,
		FizMod,
		TeljesitesIdopontja,
		SzamlaKelte,
		FizetesHatarideje,
		IsSztorno,
		IsPrinted,
		Megjegyzes,
		OrigSzamlafejID,
		IsMegrendeles
	INTO 
		origSzamlaszam, 
		origPartnernev,
		origPartnercim,
		origPartnerBankszamlaszam,
		origPartnerAdoszam,
		origFizMod,
		origTeljesitesIdopontja,
		origSzamlaKelte,
		origFizetesHatarideje,
		origIsSztorno,
		origIsPrinted,
		origMegjegyzes,
		origOrigSzamlafejID,
		origIsMegrendeles
	FROM SZAMLAFEJ WHERE SzamlafejID = ID;
	IF origIsSztorno > 0 THEN
		LEAVE sproc;
	END IF;
	INSERT INTO SZAMLAFEJ (
		szamlaszam,
		partnernev,
		partnercim,
		partnerbankszamlaszam,
		partneradoszam,
		fizmod,
		teljesitesidopontja,
		szamlakelte,
		fizeteshatarideje,
		issztorno,
		isprinted,
		megjegyzes,
		OrigSzamlafejID,
		ismegrendeles)
	VALUES (
		NextInvoiceNumber,
		origPartnernev,
		origPartnercim,
		origPartnerBankszamlaszam,
		origPartnerAdoszam,
		origFizmod,
		origTeljesitesidopontja,
		Now(),
		origFizetesHatarideje,
		0,
		0,
		origMegjegyzes, 
		ID,
		origIsMegrendeles);
	SELECT LAST_INSERT_ID() INTO lastid;
	OPEN curSZAMLATETEL;
	REPEAT
		FETCH curSZAMLATETEL INTO
			tetelSzamlafejID,
			tetelTermek,
			tetelMennyiseg,
			tetelAFA,
			tetelEgysegar,
			tetelKategoriaID,
			tetelITJ,
			tetelMeId,
			tetelProductID;
		IF NOT done THEN
			CALL sp_insertinvoiceitem(
				lastid,
				tetelTermek,
				tetelMennyiseg * -1,
				tetelAFA,
				tetelEgysegar,
				tetelKategoriaID,
				tetelITJ,
				tetelMeId,
				tetelProductID);
		END IF;
	UNTIL done END REPEAT;
	CLOSE curSZAMLATETEL;
	SET done = 0;
	OPEN curUNIQUEFIELDS;
	REPEAT
		FETCH curUNIQUEFIELDS INTO
			uniqueUniqueDescID,
			uniqueValue;
		
		IF NOT done THEN
			CALL sp_insertuniquefield(
				uniqueUniqueDescID,
				lastid,
				uniqueValue);				
		END IF;
	UNTIL done END REPEAT;
	CLOSE curUNIQUEFIELDS;
	UPDATE SZAMLAFEJ SET IsSztorno = 1, OrigSzamlafejID = lastid WHERE SzamlafejID = ID;

A végeredmény természetesen ugyanaz, de a kód áttekinthetősége lényeges eltéréseket mutat. Ismétlem ez szubjektív, de nekem könnyebbséget jelent, hogy a kódban csak egy CALL-t eresztek el, a többit pedig MySQL Query Browser-ben szerkesztem.
Természetesen ez nem zárja ki, hogy mondjuk a MySQL-es rész tárolt eljárásokat használjon míg mondjuk egy Sqlite-os konfiguráció esetén az adatkezelő layert megvalósító osztály maga tartalmazza az SQL utasításokat.

Tévedsz :)
A fenti kód fele pont a tárolt eljárás miatt szükségeltetik...

(Onnantól, hogy több SQL-motoron is megy, végképp baromi macerás tárolt eljárásokkal dolgozni, mert ott meg abba futhatsz bele, hogy a két vagy több motornál nem pontosan ugyanúgy néz ki a tárolt eljárások nyelve.)

Valószínűsítem, hogy mindkettőnknek igaza van és egyikünknek sem :-) Természetesen igazad van abban, hogy "végképp baromi macerás tárolt eljárásokkal dolgozni" több SQL-motor támogatása esetén. Ha eljutunk oda, hogy több motor is támogatva lesz és ehhez a tárolt eljárások feláldozásán keresztül vezet az út, fel fogom áldozni őket. Addig pedig elférnek :-)

Ha például elvégzek egy kisebb módosítást egy tárolt eljárásban akkor - mondjuk 10 kliens esetén - nem kell 10 helyen frissítenem a kliensprogramot is.

Eleg ketelu a dolog. Miert feltetelezned, hogy egy kisebb cegnel 10-en is akarnak szamlazni? Mar korabban ,,megallapitottuk'', hogy a legtobb potencialis felhasznalod egyedi felhasznalo lesz. Tehat ugyanazon a gepen lesz neki a MySQL es a sharpszamla is. Toluk elvarni, hogy frissitsek az SQL adatbazisat szerintem nagyobb melo (raadasul tobb hibalehetoseget is hordoz), mint az, hogy elinditsak az ujabb verzio telepitojet.

Megint a *sajat* kenyelmed a szempont;) (hogy neked ne kelljen 10 gepre feltenni az ujabb verziot)

Nem hiszem, hogy
a) sok nagyvallalati ugyfeled lesz (10+ gepre telepitve)
b) kethetente kijon egy ujabb verzio

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

( Elbandi v | 2006. 04. 20., cs – 17:48 )

wishlistbe: importalas lehetosege (partner,termek es szamla). nekunk havonta kell csinalni jonehany szamlat (cca 200-300db), jo lenne ha letezne valami progi amivel gyorsan lehetne megcsinalni a szamlakat. most kezzel viszi be egy emberke...

( khiraly | 2006. 04. 21., p – 02:05 )

Ekezetek

Eleg erdekes a helyzet. Ami a .glade fajlban van ekezetes szo, az jol jelenik meg.(pedig az is utf-8). Ami a programkodban van sztringkent az iso-8859-2 -vel jelenik meg. Igy az utf-8 eleg hanyadek lesz.

Itt egy shot rola:
http://img212.imageshack.us/img212/6528/sharpszamla9ro.png

Eszrevetel
Ha nincs adatbazis alatta, akkor legalabb 12 popup-ot le kell OKezni, mire vegre kilep a program.

Telepiteni meg egy remalom volt btw;-\

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

szimplan igy inditsam?:
./SharpSzamla.exe -codepage:65001

Mert nem segitett. Ugyanolyan mint volt. Semmi valtozas nincs.

Ha igy inditom:
mono -codepage:65001 ./SharpSzamla.exe
Unknown command line option: '-codepage:65001'

Akkor ezutan kilep. (tehat fel se jon a gui)

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

Rémálom volt a telepítés? Hogy értve? Az tény, hogy forrásból felhúzni bonyolultabb mintha lenne neki telepítője, de ez még fejlesztői verzió, nem végfelhasználóknak való :-)
A karakter problémát tekintve nézd meg a /etc/mono/2.0/machine.config filet és abban a globalization sectiont:

<globalization requestEncoding="utf-8"
responseEncoding="utf-8"
fileEncoding="utf-8"/>

A 12 popup leokádása valóban idegesítő - hozzáteszem ez ha jól be van lőve a config, akkor nem jön elő - minden esetre javítva lesz, mert ez így most gáz!

A karakter problémát tekintve nézd meg a /etc/mono/2.0/machine.config filet és abban a globalization sectiont:

responseEncoding="utf-8"
fileEncoding="utf-8"/>

Nalam is ugyanez van benne. Mindenhol utf-8. blr 5letet kellene megnezni, de meg nem sikerult rajonnom, hogy hova kellene irnom a -codepage:65001 parametert.

vbali: nalad ez hogyhogy nem jon elo?

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

Megtalaltam hova kell irni ezt a codepage:65001 -et.
Itt egy screenshot, hogy latszodjon, hogy megjavult;)
http://img213.imageshack.us/img213/5638/sharpszamlajo3ov.png

src/Makefile:am 11.sora utan irtam be.
Nalam ez a resz most igy nez ki:

ASSEMBLIES = \
-r:System.Data \
-r:Mono.Posix \
-r:../resources/itextsharp \
-r:../resources/MySql.Data \
-codepage:65001

A Makefile.in 205. sora utan ugyanigy betettem.
(remelem a tabokat nem nyeli le a portalmotor).

Nem ertek a Makefile.in generalasahoz (nem hasznaltam automake/tools/akarmit. Ha par sorban leirnad, hogy hogyan kell ilyen configure, makefile meg hasonlokat generalni a projekthez, akkor annak orulnek. (es ezekbol a fajlokbol: configure.ac, Makefile.ac, etc) melyik a kezzel irt, es melyik a generalt.)
Jo lenne ilyen leiras is. Valami fejlesztoi szekcioba, hogyha valaki kacerkodik, akkor tudja, hogyan kell folytatni a projektet.

Valami ilyenre gondolok:
1. Leirod, hogy milyen auto(tools|make)-et hasznaltal, hogyan hoztad letre a projektet. (tehat ha 0-rol akarok csinalni egy helloWorld mono projektet, akkor boldoguljak). Szoval egy mini-howto hogyan kell csinalni egy helloWorld projektet automake-kel.

2. A jelenlegi projektet hogyan kell importalni monodevelop-ba. Hogyan kell modositas utan kiexportalni, hogy ujra fordithato legyen. Hogyan kell monodevelop-bol ugy forditani, hogy ne rakja tele a projektkonyvtarat ideiglenes fajlokkal (generalt Makefile, configure, etc).

3. Szoval hogyan lehet belefejleszteni ebbe a fajlba, es probalgatni hogy mukodik-e.

Nem ertek a mono/C# -hoz, de hasonlit a javahoz, igy meglesnem, hogy mire lehet jutni vele.

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

Én sem vagyok Makefile guru de ezt-azt még C-s múltamból elsajátítottam. Egy HowTO-t szívesen összedobok ha van rá igény de egyrészt biztos vannak itt sokkal kompetensebb hozzáértők is másrészt nem hiszem, hogy egy kis HowTO-ba összedobható az egész, mert elég nagy a téma. Egy szakdolgozatnak mondjuk jó lenne :-) Minden esetre egy "Beginners Guide"-ot talán meg tudok oldani (ha megemészthető, hogy vak vezet világtalant). Előzetesen csak annyit, hogy a configure.in és Makefile.am fileokat kell megcsinálni a többi generálódik. A MonoDevelop-os kérdésedre és a Makefile-okra visszacsatolva megoldás a SharpSzamla CVS verziója. A CVS-t a SourceForge hostolja sharpincoice néven :-)

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/sharpinvoice login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/sharpinvoice co -P sharpinvoice

Az így leszedett kódban megtalálható a MonoDevelop-os projectfile is, mivel azonban a CVS nem kezeli a symlinkeket lehet vele egy kis zűr. Ha a sharpinvoice/monodevelop könyvtárból hiányzik az src mappa/symlink akkor létre kell azt hozni: 

cd sharpinvoice/monodevelop
ln -s ../src src

Ezt követően már használható a MonoDevelop :-)

Szia

Engem is érdekel ez az automake, hol olvassak utánna, annyi mindent találok, de abból ugyse jövök rá, te mit csináltál...
Amúgy mi értelme van ennek az automak edolognak?
Elvileg forrásra ott a monodevelop, kipróbálásra, meg a .NET-re fordított homi már elég, vagy tévednék?

Ja és mégegy kérdés, .NET:
Hogy a csudába mondom meg a monodevelop-nak, hogy ez és ez az osztály ebb dll -be az meg az meg abba...
mcs -t tudom úgy paraméterezni, de monodevelop-ot nem... (Habár a project-nél van olyan, hogy library, de ugye az ember nemcsak library-t akar egy projekten bellül...)

A 12 popup leokádása valóban idegesítő - hozzáteszem ez ha jól be van lőve a config, akkor nem jön elő - minden esetre javítva lesz, mert ez így most gáz!

Szerintem, ha nincs mogotte SQL, akkor is ugyanugy hasznalhatonak kellene lennie, csak nem lehetne adott muveleteket vegrehajtani. (tehat amikor be akarunk vinni egy szamlat,akkor feldobna egy popup-ot, hogy nincs adatbazis, elobb telepits).

Ez azert lenne jo, mert igy tobben ki tudnak probalni (az hogy mennyire kenyelmes a felulete igy is megallapithato), anelkul hogy egy mySQL-t kellene fullosan bekonfiguralni. Raadasul valahol mar van 4.x telepitve, oda feltenni egy 5.x-et eleg nehez.

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