nicht angemeldet
Tach!
1.) Tabelle "Cashflows"
* ID ('1' oder '2')
* Cashflow ('Einnahme' oder 'Ausgabe')
Die Tabelle ist unnötig, dafür gibt es Vorzeichen, + rein, - raus.
2.) Tabelle "Eigene Konten"
* ID (zB. '3')
* Name (zB. 'Citybank Gehaltskonto', 'Hypo Bausparvertrag', ...)
* aktueller Kontostand (zB. '23.84')
Den Kontostand extra zu führen ist nicht notwendig, der ergibt sich aus der Summe der Buchungsbeträge (mit ihren Vorzeichen). Das hat sogar den Vorteil, dass Fehler auffallen. Dann stimmt nämlich die selbst berechnete Summe nicht mit dem Kontostand überein.
Eventuell möchtest du noch eine Spalte Kontotyp einführen, damit du die Konten zum Beispiel in Zusammenfassungen nach Arten gruppieren kannst. Girokonten betrachtet man anders als Sparkonten. Ein Kredit wäre auch ein Konto, bei dem man aber Tilgungen berechnen kann, was für Girokonten unsinnig wäre. Aber das später zu implementieren, wenn dir die Anwendungsfälle dazu einfallen, wäre auch kein Beinbruch.
3.) Tabelle "Finanzpartner"
4.) Tabelle "Buchungskategorien"
Passt.
5.) Tabelle "Transaktionen"
* ID (zB. '323')
* Datum (zB. '2013-11-25')
* Beteiligtes eigenes Konto (zB. '2')
* Beteiligter Finanzpartner (zB. '12')
* Cashflow (zB. '1')
* Gesamtbetrag (z. '231.12')
Cashflow weg, ergibt sich aus dem Vorzeichen.
6.) Tabelle "Buchungen"
* ID (zB. '634')
* Transaktions ID (zB. '323')
* Cashflow (zB. '1')
* Buchungskategorie (zB. '12')
* Betrag (zB. '23.89')
Das hab ich bei mir nicht extra sondern in der Transaktionentabelle drin. Die sieht so aus:
CREATE TABLE Transaction (
ID int(10) unsigned NOT NULL AUTO_INCREMENT,
ID\_Account int(10) unsigned DEFAULT NULL,
Date date NOT NULL DEFAULT '0000-00-00',
Sort tinyint(3) unsigned DEFAULT NULL,
Amount decimal(20,2) NOT NULL,
ID\_Payee int(10) unsigned DEFAULT NULL,
ID\_Category int(10) unsigned DEFAULT NULL,
Memo varchar(255) NOT NULL DEFAULT '',
Type set('Transfer','Split','SplitPart') DEFAULT NULL,
Flag enum('','A','V') NOT NULL DEFAULT '',
ReferenceID int(10) unsigned DEFAULT NULL,
PRIMARY KEY (ID),
KEY ID\_Account (ID\_Account),
KEY ID\_Payee (ID\_Payee),
KEY ID\_Category (ID\_Category),
KEY ReferenceID (ReferenceID),
KEY Date (Date)
);
Sort bekommt bei Bedarf eine Nummer, um Buchungen (=Transaktionen) eines Tages definiert anordnen zu können. Das ist nur Optik und kann auch wegbleiben. Memo ist ein Freitextfeld, wenn ich was zur Buchung zu vermerken habe (z.B was für ein Ding oder welche Vertragsnummer sie betrifft). Flag definiert ob verrechnet oder abgestimmt. Abgestimmt bedeutet, dass die Buchung mit einem Beleg verglichen wurde (Kontoauszug vs. Rechnung/Kassenzettel). Wenn es naturgemäß keinen Beleg gibt (wie bei Daueraufträgen), dann bekommt die Buchung trotzdem ihr A. Verrechnet ist eine Buchung, wenn sie auf dem Kontoauszug auftaucht, aber (noch) nicht mit einem Beleg vergleichen wurde, weil der zum Beispiel noch nicht da ist. Wenn das Feld leer ist, dann ist vielleicht schon der Beleg da oder auch nicht, jedenfalls ist das noch nicht auf dem Kontoauszug erschienen. Ich hab's aber trotzdem schon eingetragen, um es bei Planungen berücksichtigen zu können. Der Idealzustand ist also A. Diese Kennzeichnung gab es damals in MS-Money, und vielleicht ist ihre eigentliche Bedeutung auch eine ganz andere, ich hab es jedenfalls so interpretiert.
Type hat drei Aufgaben, abgesehen von NULL, was eine einfache Buchung darstellt. Transfer ist eine Überweisung zwischen zwei Konten. Das Feld ReferenceID bekommt dabei die Nummer der Gegenbuchung auf dem anderen Konto zugewiesen (was in drei Schritten erfolgt: erste Buchung anlegen, zweite Buchung mit Referenz auf die ID der ersten anlegen, Updaten der Referenz der ersten mit der ID der zweiten). Split sind Hauptbuchungen, wie beim Lohn/Gehalt oder Rechnungen, die ich auf Kategorien aufteilen möchte. SplitPart sind die einzelnen Teile, wobei da die ReferenceID auf die zugehörige Split-Buchung verweist. Idealerweise ergibt die Summe der SplitPart-Beträge denselben Wert wie die zugehörige Split-Buchung, aber das muss nicht so sein, wenn man beispielsweise unwichtige Teile nicht weiter aufdröseln möchte. Jedenfalls darf die Summe des/der Kontos nur ohne die SplitPart-Buchungen berechnet werden.
7.) Tabelle "Interne Umbuchungen"
Nicht notwendig, das sind zwei Einzelbuchungen auf den jeweiligen Konten, bei mir durch den „Transfer“-Type gekennzeichnet.
Als praktisches Beispiel: Angenommen, ich komme vom 'ALDI' nach Hause und habe einen Kassenbon, auf dem 3 Rechnungspunkte stehen. Also zB. 2 Bananan, 1 Pck. Milch und 1 Korb Weintrauben. Dann würde das in der Tabelle "Transaktionen" zu 1 neuen Eintrag führen und in der Tabelle "Buchungen" zu 3 Einträgen. Bei einer Transaktion, die aus einem einzigen Posten besteht, kommt es zu 1 neuen Eintrag bei den Transaktionen sowie 1 neuen Eintrag bei den Buchungen.
Das wäre mir viel zu zeitaufwendig ohne weiteren Nutzen. Kategorie Lebensmittel für den gesamten Einkauf und gut ist. Eventuell kann man das splitten, wenn was besonderes dabei war, dann aber in „besonderes Ding“ und „Rest“.
Beachte auch, als Spaltentyp für die Beträge DECIMAL und nicht FLOAT zu verwenden, sonst gibt es den bekannten und befürchteten Ärger mit ungenauer Abbildbarkeit von Nachkommastellen im Dualsystem (à la 1 - 0.1 = 0.89999999) .
dedlfix.