Ha jól sejtem, akkor számvitelileg hibás az elképzelésed, pontosabban beleütközhetsz egy-két nagyon durva problémába, tehát figyelj a következőre:
(K) egy ügyviteli program, (S) viszont meg kell hogy feleljen a hatályos számviteli- és adótörvényeknek, -rendeleteknek, ezért:
Szla. létrehozása:
- (K) megkéri (S)-t, hogy hozzon létre egy új számlát
(S) visszaad egy ideiglenes azonosítót (nem generálhatod azonnal a számlasorszámot!)
- (K) egyesével átadja a tételeket. A tételes adatok között a következőknek kell szerepelnie (és lehetőleg másnak nem): VTSZ/SZJ-kód, megnevezés (annyi megjegyzéssel és egyébbel, amennyit csak akarsz), mennyiségi egység, mennyiség, nettó egységár
- (S) egyetlen dolgot tud ellenőrizni: a kapott VTSZ/SZJ kód szerepel-e az adatbázisában. Ha nem, akkor a tétel hibás.
- (K) Valamilyen módon átadja (S)-nek a vevő adatait. (ez a lépés elvileg bármikor megléphető)
Szla. kiállítása:
- (K) vagy (S) utasítja (S)-t, hogy nyomtassa ki a számlát. (az ideiglenes azonosító alapján)
- (S) kiszámítja az áfákat (VTSZ/SZJ alapján), a számla végösszegét, generál egy számlasorszámot, majd kinyomtatja a számlát. (Fontos: le _kell_ tárolni a kiszámított sorokat, egy számla utólagos lekérdezésekor már semilyen számítás nem végezhető rajta!)
Szla. sztornózása:
- Csak olyan számlát törölhetsz nyomtalanul, ami még nem lett kinyomtatva. Minden egyéb esetben sztornószámlát kell a rendszernek kiállítania, az eredeti számla "negálásával".
És hogy miért is ez a követendő módszer:
- Ha előbb generálsz számlasorszámot, mint nyomtatod, akkor előfordulhat, hogy a sorszámok nem időrendben követik egymást.
- Ha (S) kezeli az áfakulcsokat, akkor rengeteg (K)-t írhatsz, anélkül, hogy áfakulcs-módosításkor mindegyik adatbázisát javítanod kéne. (Magyarán: felvállalható az ügyfél felé az áfakulcsok karbantartása csak (S) módosításával.)
Végül: nem tárolhatod több számlakibocsátó számláit egy táblában (sőt, lehet, hogy egy adatbázisban sem). (Most meg nem mondom, hogy ez hol van törvényileg szabályozva.)