Kontosaldo berechnen

L

Ludwigmller

SQL-Guru
Beiträge
171
Hallo,
ich möchte gerne den Saldo aus Kontobewegungen berechnen. Mein bisherigern Ansatz ist folgende Tabelle:
Code: 
Create table kontobewegungen
(
  id serial,
  datum date,
  von integer,
  an integer,
  artikelnr integer,
  anzahl integer
)
Es wird also pro ArtikelNr und Bewegung ein Datensatz gespeichert. 'von' und 'an' verweisen jeweils auf die KundenNr in der Tabelle kunden.

Code: 
insert into kontobewegungen(von, an ,artikelnr, anzahl)
values (0,1,1,224), (0,1,1,6),(1,0,1,100);
Für diese Werte sollte letztendlich ein Saldo von 224+6-100=130 ermittelt werden.

Wie kann man das am besten machen?

Da man bei der Tabellenstruktur eine gewisse Redundanz hat (entweder 'von' oder 'an' ist gleich 0) wäre es vielleicht einfacher, nur eine Spalte 'kunde' zu haben und die Anzahl entweder positiv oder negativ zu speichern. Dann vielleicht eine Funktion neue_bewegung(Datum, von, an, artikelnr, anzahl) erstellen, die den entsprechenden Datensatz in kontobewegungen erstellt?
 
Zuletzt bearbeitet:
Werbung:
Ergänzung: Die KundenNr = 0 ist die des Benutzers/eigene Firma.

Zwischenzeitlich habe ich eine Lösung gefunden:
Code: 
select t1.kundennr, t1.artikelnr, sum(t1.anzahl) from

(select
id,
datum,
(case when b.von=0 then an else von end) as kundennr,
(case when b.von=0 then b.anzahl*(-1) else anzahl end) as anzahl,
 b.artikelnr
from kontobewegungen b) as t1

group by artikelnr, t1.kundennr
Was ist davon zu halten?
 
ohne Subselect:

Code: 
edb=*# select case when von=0 then an else von end as kundennr, artikelnr, sum (case when von=0 then anzahl else -anzahl end) from kontobewegungen group by 1,2;
 kundennr | artikelnr | sum
----------+-----------+-----
        1 |         1 | 130
(1 row)

edb=*#

Ja, um Redundanz zu verweiden wäre nur eine Kundenspalte und pos/neg Beträge denkbar.
 
Werbung:
Ich kann nicht drauf schwören, aber aus Anwenderperspektive wird in der Buchhaltung nur mit positiven Beträgen gearbeitet. (Und einem Buchungsschlüssel, der mehr oder weniger den Umgang bestimmt)
Ich habe mal vor Jahren sowas gemacht, mit einer Kontoart (verschiedene: Kunde, Eigen, EigenLieferanten, ..) und Buchungstypen/-Schlüssel, die tw aus den Banktypen stammten (Mapping)
Die Verwendungsart o.ä. an die KundenNr zu binden, ist nicht sauber. Falls man noch aus Zeiten kommt, in denen selbst 7/8 Bit ASCI einen teuren Speicherplatz Unterschied machte, die Zeiten sind wirklich vorbei. Man spart nichts und hat nur mehr Kodierungsaufwand für Fallunterscheidungen, Reporting usw.
 
Zurück
Oben