Teszt kérés

Fejlesztés

Sziasztok!
Lazarus alatt (kérésre) fejlesztgetek (ahogy az idő engedi) egy nagyon eccerű számlázó progit, aminek (végre) elértem a -szerintem- 1.0 állapotát. Feltettem egy demót, amit ha megnéznétek, és kicsit nyomkodnátok (vindózos, de tervezek linukszosat is), és mondanátok pár ötletet esetleg hibát (mert az biztosan van benne ugyebár...), megköszönném.

Elérhetősége: http://dbsz.mfi.hu/dbsz-1.0-DEMO.ZIP
(Az egyetlen jelzett hiba javítva)
Áttettem ide : http://data.hu/get/2277542/dbsz-demo-1.0.ZIP
Javított verzió: http://data.hu/get/2286630/dbsz-jav-1.0-demo.ZIP

  • 2709 megtekintés

( slackmania | 2010. 02. 26., p – 20:36 )

Ja, és még annyit, hogy leírást DIREKT nem adok hozzá. Ez is a teszt része.

( neutrino v | 2010. 02. 26., p – 20:58 )

Ha az ÁFA kitöltése előtt töltöm ki az alapárat, akkor ezt dobja ki:

A képet a Képfeltöltés.hu tárolja. http://www.kepfeltoltes.hu

127.0.0.1 SWEET 127.0.0.1

( slackmania | 2010. 02. 26., p – 21:15 )

Javítva. ( Ha üres, akkor erőszakkal beletolja a 25-öt. EZt persze még át kell gondolni, de azt hiszem, a 25 elég általános ÁFAkulcs...)

( l0ud v | 2010. 02. 28., v – 11:34 )

Pár dolog ami elsőre feltűnt:

- Ha a minden leürítése gombra kattintasz, és utána elindítod és az újranyomtatásra, akkor dob egy szép null hibát.

- Kitöltetlenül csak rákattintok a számlatétel+ gombra és hiba :) (pl. letilthatod a számlatétel+ gombot amíg nincs minden mező kitöltve)

- Amíg a beállítások nincsenek kitöltve a számlaszám 000000 az alap inkrementálódást 1-re raknám. És az a mező autoincrement legyen.

- Minden leürítés ???? <-- Ezt vedd ki belőle mert kurvára meg fog büntetni az apeh. /Majd te az adatbázisban matatsz max./ Számlát törölni nem lehet, mert adócsalásnak minősül.

- Kilépés gomb elég szar helyen van...

"- Ha a minden leürítése gombra kattintasz, és utána elindítod és az újranyomtatásra, akkor dob egy szép null hibát."
Javítva, kivéve
"- Kitöltetlenül csak rákattintok a számlatétel+ gombra és hiba :) (pl. letilthatod a számlatétel+ gombot amíg nincs minden mező kitöltve)"
Javítva
"- Amíg a beállítások nincsenek kitöltve a számlaszám 000000 az alap inkrementálódást 1-re raknám. És az a mező autoincrement legyen."
Javítva, de nem lett autoincrement, progi kezeli
"- Kilépés gomb elég szar helyen van..."
Javítva

( Dacr (nem ellenőrzött) | 2010. 02. 28., v – 11:41 )

Dupla katt a "0" egységárú számlára (középső lista), invalid integer (szerk.: bár szerintem inkább az üres mennyiség a gondja):

( zolti v | 2010. 02. 28., v – 13:06 )

off!

A számlázóprogramokban, ha után nyomtatást szeretnék egy régi számláról akkor annak hogy kell kinéznie ?
Pont ugyanúgy mint a réginek(kivétel a példányszám), vagy csak tartalmilag ugyanúgy(stílus változhat), vagy az esetleges kiállító adatainak (pl telephelyváltás) változását követnie kell ?

Én még soha nem találkoztam olyan programmal, ami képes lett volna egy korábbi példányt újranyomtatni. Sőt, tudtommal ha egyszer kijött az első példány, a többin már mindig "másolat" kell, hogy szerepeljen. (Legalábbis amikor vagy 7-8 éve egy ügyviteli rendszer számlanyomtatási részét írtam, akkor még így volt.)

Most is úgy van, hogy első nyomtatáskor kinyomtatod az "Eredeti példány"-t (Vevőé) az "Első másolat"-ot (Eladóé)
és a "Második másolat"-ot (Könyvelőé), ha kell még akkor kinyomtatod az "3. másolat", "4. másolat", ...
annyit amennyi kell, de egyesével, és nem hármasával. Értelemszerűen másolat nyomtatásakor semmilyen mező nem
vehet fel más értéket, még a lábjegyzék se, azaz hogy ki készítette a számlázó programot. Sok helyen, és egyre
több helyen értenek az elektronikus úton előállított számlához, és keresik rajta, hogy ki készítette a számlázó
programot, és ha nincs rajta a készítő neve akkor nem fogadják el. Szerintem jogosan.
Fontos, hogy az elektronikus számla és az elektronikus úton előállított számla két teljesen különböző dolog.
Az elektronikus számlából nem kell, hogy készüljön és nem is készül papíros nyomtatvány, csak egy fájl amely
digitálisan alá van írva egy olyan aláírással, mely megfelel a mindenkori számviteli törvényi előírásoknak.

"Most is úgy van, hogy első nyomtatáskor kinyomtatod az "Eredeti példány"-t (Vevőé) az "Első másolat"-ot (Eladóé)"
Majdnem, a számlát eleve kiállíthatod több példányosan ezt a számlán fel is kell tüntetni (előírás), vagyis van eredeti első, eredeti második ... példány is, a lényeg hogy a számlára rá kell írni hány példányban készült. A másolat az már más kérdés, az csak másolat.

A fenti válaszokkal ellentétben, bármilyen másolatot előállíthatsz ami az ÁFA törvénykönyvnek TARTALMI vonatkozásban megfelel. Természetesen az adatoknak érintetlennek kell maradnia, pl gyakori hiba, hogy nem rögzíted a vevő adatait a számla mellé, csak az IDjét, aztán ha átírják mondjuk a címét, akkor a számla is módosul. Ez nem megengedett.

Ez esetben elég a számla tartalmát xml-ben adatbázisban eltárolnom és nem kell pont ugyanúgy kinéznie, csak az adatok egyezzenek.
Ez nagy segítség volt.
Nem tudtam elképzelni, hogy oldjam meg azt, hogy pár év múlva is tökéletes másolatát adjam (példányszám kivételével) az eredeti számlának.

"gyakori hiba, hogy nem rögzíted a vevő adatait a számla mellé, csak az IDjét, aztán ha átírják mondjuk a címét, akkor a számla is módosul"

Mi van a kiállító esetleges adatváltozásaival ?
Azok kövessék a változásokat vagy ne ?
Kiadható egy másolat ma úgy, hogy azon már elavultak a számla kiadó adatai ?

Ha tudnál egy törvényt, rendeletet vagy valami hivatalos dolgot linkelni szívesen végigolvasnám, de magam nem találtam meg az idevágó részt.

Benne van a nevében másolat, tehát semmilyen adat nem változhat, még a kiállító sem.
De nem csak az adatot kell eltárolni, hanem a számla, bizonylat külső megjelenését is.

Én az egyes bizonylatokra fixen ráírom a kiállító adatait is. Az ügyfél nem tudja megváltoztatni azokat,
a license fájl tartalmazza az összes bizonylatát. Ha változás van akkor kér egy újabb license-t. Ezzel a másolásvédelem is
meg van oldva (többé kevésbé)

A kiállító adatait is rögzítened kell a számlával, semmi nem történhet a rendszerben aminek hatására a rögzített adatok újra kinyomtatása (pl hiteles másolat) esetén más TARTALMI eredményt kapsz. Az előbbi példánál maradva, pl az áruk neve sem változhat. Az hogy hogy néz ki ez formailag, továbbra is tartom hogy mindegy.

Olvasnivaló:
"ÁFA törvénykönyv" 169. paragrafus környéke
http://net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=A0700127.TV&timeshift=0
Kapcsolódó PM rendelet:
http://net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=99500024.PM

( slackmania | 2010. 03. 01., h – 20:18 )

Nos? Ha valaki töltötte az új verziót, mondhatna valamit róla.....

( samuf v | 2010. 03. 01., h – 20:39 )

Néhány észrevétel

1: Ha van rá lehetőség használj normális adatbázis kezelőt ami képes a sql-re és tranzakciókezelésre. Ha később bővíted a programot, esetleg hálózatos verzió is lesz belőle, jól fog jönni.
2: Bár a kódot nem néztem, de ha jól vettem észre a számlaszámot már előre kiosztod a számlának. Ez nem a legcélszerűbb mivel, ha hiba történik az adatok rögzítésénél akkor a számlaszám már felhasználásra kerül és mivel nincs tranzakció kezelésed nem tudod visszagörgetni. Pl. hozzáadsz egy tételt a számlához, de nem a készre nyomsz, hanem kilépsz a programból, a számla meg ottmarad.
3: Általában a bruttó egységárat szokták beírni, persze ha van rá lehetőség inkább mindkettő kellene.
4: Az adatbázisod nincs optimalizálva, a számla fejléc adatait inkább külön táblában kellene tárolnod a tétel adatoktól és a tétel rekordok hivatkozzanak a fejléc adatokra.

Igen, vacilláltam is rajta, hogy mi legyen a motor. Aztán sql-t kidobtam a kosárból, mégpedig azért, hogy bármelyik gépre telepíthető legyen egyszerűen, gyorsan. Ezért eccerű számlázó a neve.
Ha sql lenne, akkor szegény műfordító (pl) megsem tudna moccanni valakinek a segítsége nélkül, nem?
Ez így jóval "rugalmasabb", kibontja, beállítja, oszt kész.

Redundancia: Direkt nem akartam. Igazából jól elfér, kezelhetőek az adatok így is. Sztem, ennél sokkal nagyobb és összetettebb adatbázisoknál érdemes külön erőforrást beletolni a redundáns adatok kezelésébe, itt és most csak feleslegesen bonyolította volna a kódot.

"Bár a kódot nem néztem, de ha jól vettem észre a számlaszámot már előre kiosztod a számlának. Ez nem a legcélszerűbb mivel, ha hiba történik az adatok rögzítésénél akkor a számlaszám már felhasználásra kerül és mivel nincs tranzakció kezelésed nem tudod visszagörgetni. Pl. hozzáadsz egy tételt a számlához, de nem a készre nyomsz, hanem kilépsz a programból, a számla meg ottmarad."

A számlaszán NEM íródik be az adatbázisba feleslegesen ilyenkor még, csak "át van nyújtva" a részére, hogy nesze, itt van :). Villanykimaradás esetén nem fog elszállni a számlaszám a levegőbe, hiszen fizikailag, a számla.dbf-be nem íródik be, csakis a számla nyomtatása előtt közvetlenül.

"A számlaszán NEM íródik be az adatbázisba feleslegesen ilyenkor még, csak "át van nyújtva" a részére, hogy nesze, itt van :). Villanykimaradás esetén nem fog elszállni a számlaszám a levegőbe, hiszen fizikailag, a számla.dbf-be nem íródik be, csakis a számla nyomtatása előtt közvetlenül."

Kipróbáltad amit példaként felhoztam? Felveszel egy tételt és a "Kész,..." helyett bezárod a programot "az X-el". A számla tétele rögzül az adatbázisba és így a számlaszám is

"Kipróbáltad amit példaként felhoztam? Felveszel egy tételt és a "Kész,..." helyett bezárod a programot "az X-el". A számla tétele rögzül az adatbázisba és így a számlaszám is"
Most fogom még csak indítani a virtualboxot, helyet csináltam, mert küzdök a gigákkal. (meg dolog is van).
Próbálom.

( tomi66 | 2010. 03. 01., h – 21:01 )

vevőadatbázis feltöltésénél nem lenne nagy ügy, ha:
- ellenőrizné az adószám formai helyességét
- ellenőrizné a bevitt bankszámla formai helyességét
- ellenőrizné az adószámot a standard algoritmus alapján, CDV
- ellenőrizné a bankszámlaszámot, CDV, esetleg egy átfordítási táblából a bank és fiókkód helyességét
- nem fogadna el rossz irányítószámot
- nem engedne rekordot duplikálni (sikerült két vevőt felvinnem, teljesen azonos adattartalommal, ez gáz lesz)
- a felvitt rekordot engedné szerkeszteni

számlánál:
- számlánál ha átírom az ÁFAkulcsot, nem számolja újra, amit újra kell számolni
- ha az első input boxba bármit beírok, azt felveszi a vewvőadatbázisba gondolkodás nélkül, rosszul, az előző vevőrekord adataival kiegészítve
- szj számot ellenőrizhetné adatbázisból
- kitöltött számlával rendelkező vevőt ne engedjen kitörölni a vevőadatbázisból
- vevőadatbázisból töröltem egy vevőt és az magával rántott egy másikat, azaz az is törlődött

szóval ez még a V0.0-ás verzió legyen csak.

+1
Bár ezek az ellenőrzéses dolgok néha visszájára sülnek el.
pl. "nem fogadna el rossz irányítószámot", ha bejön egy Német ügyfél, hogyan rögzíted az adatait?

Hogy konstruktívak is legyünk, a vevők törlésére jó megoldás lehet a logikai törlés, azaz egy mezőben jelzed, hogy a listában ne jelenjen meg a vevő és az alapján szűrve listázod ki a vevőket.

Szerk: A teljesítési idő nem a számla tételeihez tartozik, hanem a számlához

No, azt hiszem, félreértetted a dolgot. Ez egy egyszerű, olcsó, könnyen használható proginak készül. Egyáltalán nincs szándékom az általad felvetett ellenőrzéseket beletenni, szerintem a használójának legyen annyi esze, hogy az APEH büntitől félve leellenőrzi saját maga ezeket. (Ha papírra írja a számlát, kézzel-tollal, akkor sem ellenőrzi semmi sem, nem igaz?)

A vevőduplában igazad van, hamarosan megnézem, ez így nem maradhat.
"- ha az első input boxba bármit beírok, azt felveszi a vewvőadatbázisba gondolkodás nélkül..."
Hoppá, ezzel nem találkoztam itt nálam.

*Javítva

"- kitöltött számlával rendelkező vevőt ne engedjen kitörölni a vevőadatbázisból"
Oké, ezt rendezni fogom.

*Javítva (kivettem a törlést, mert minek?)

"- vevőadatbázisból töröltem egy vevőt és az magával rántott egy másikat, azaz az is törlődött"
Hogymivan?

*Ellenőrizve, nem csinálta, de már nem lehet ilyet (ld egyel feljebb)

"szóval ez még a V0.0-ás verzió legyen csak."
Ja, szerintem is. Bár én már ezt használom kb fél éve. ( és a hibákra rá nem jöttem volna egyedül, mert tudom, hogyan kell kattintani :) )
Köszi az észrevételeket.

( Dacr (nem ellenőrzött) | 2010. 03. 02., k – 11:18 )

Most hogy van egyébként? Kell vizsgáztatni ilyen szoftvert APEH által, vagy elég, ha megfelel a hatályos törvényeknek, s már tehetem is a boltok polcára?

( kojot | 2010. 03. 06., szo – 20:15 )

Nézd meg a szla újranyomtatást is!
"Could not convert variant of type (Null) into type (String)"