Design einer doppelten Buchhaltungsdatenbank

Ich erstelle Buchhaltungssoftware. Ich muss die doppelte Buchführung erzwingen. Ich habe das klassische Problem einer Zeile pro Transaktion gegenüber zwei Zeilen.

Nehmen wir ein Beispiel und sehen, wie es in beiden Szenarien implementiert wird.

Betrachten Sie Konto Cashund Konto Rent. Wenn ich meine monatliche Miete bezahle, überweise ich 100 USD von meinem CashKonto auf mein RentKonto.

Eine Zeile pro Transaktion

In einem einzeiligen System würde eine solche Transaktion gespeichert werden als:

Transaktionen

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

Zwei Zeilen pro Transaktion

In einem zweizeiligen System müsste derselbe Transaktionsdatensatz gespiegelt werden, um einen entgegengesetzten Datensatz zu erstellen. Wenn ich beide zusammenfasse, erhalte ich einen Saldo von Null.

Transaktionen

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00

Das Problem

Zunächst möchte ich festhalten: Der Grund, warum ich sowohl Tabellen transactionsals auch transaction_recordsTabellen (anstelle einer Tabelle) habe, ist die Möglichkeit, geteilte Transaktionen durchzuführen (ein Fall, bei dem ich 100 USD von einem CashKonto auf zwei oder mehr verschiedene Konten überweise).

Zuerst habe ich versucht, dies mit einer Zeile pro Transaktion zu implementieren, aber es ist schwierig, den Kontostand zu berechnen und die Daten tatsächlich abzurufen.

Ich neige zum zweiten Szenario. Es gibt jedoch auch einige Probleme:

• Wie aktualisiere ich einen einzelnen Datensatz? Angenommen, ich habe einen Fehler gemacht und statt 100 USD für meine Miete zu verbuchen, habe ich 10 USD verbucht. Ich habe jetzt 2 transaction_records- eine für Kredit und eine für Lastschrift, beide mit einem Betrag von 10 $.
• Jetzt mache ich meine Versöhnung und ich möchte diesen Tippfehler beheben. Wie würde ich das in der Datenbank beheben? Ich kenne den Zusammenhang zwischen Datensätzen nicht und im Falle eines Split kann eine Transaktion mehr als 2 Datensätze enthalten. Die einzige Lösung, die ich gefunden habe, besteht darin, ref_idfür jedes Datensatzpaar einige Datensätze hinzuzufügen , die diese Datensätze eindeutig als "gegenüberliegende Seiten" innerhalb eines bestimmten Kontexts identifizieren tx_id.

Welcher Ansatz ist besser / einfacher?

Um meine Frage zu vereinfachen: Ich möchte eine Bewegung von Geldern von Konto A zu Konto B darstellen. Die beiden Szenarien, die ich angegeben habe, sind beide gültige Entwürfe zum Speichern einer solchen Transaktion. Wie ich auch betonte, haben beide Nachteile und Vorteile (erstes: leichter zu speichern, schwerer zu finden, zweites das Gegenteil).

Möglicherweise haben sie andere Vor- und Nachteile, die ich derzeit nicht sehe. Daher frage ich erfahrene Leute nach einer Meinung.

In der Tat ermöglicht das vorgeschlagene einzeilige Abrechnungsschema eine ordnungsgemäße doppelte Abrechnung (um immer das belastete und gutgeschriebene Konto anzugeben), ohne die Redundanz der "Betrags" -Daten einzuführen.

Das einzeilige Schema gibt Ihnen die Möglichkeit, einen doppelten Eintrag zu implementieren, der konstruktiv ausgeglichen wird, sodass es unmöglich ist, das Gleichgewicht jemals zu verlieren. Die Maschine kann die Hauptbücher im laufenden Betrieb neu berechnen.

Sie müssen 2 anstelle von 1 auswählen, um ein Ledger abzurufen.

Beachten Sie, dass es neben der Aufteilung von Transaktionen auch andere Transaktionen gibt, z. B. Devisen, die möglicherweise 2 statt 4 Datensätze enthalten. Es hängt alles davon ab, ob Sie ein bisschen denormalisieren würden. Geben Sie einfach 4 Transaktionen mit ähnlicher Beschreibung ein.

Sie können die Eingabe oder Änderung von Transaktionen verhindern, um einen Audit-Trail zu führen. Dies ist erforderlich, wenn Sie das Transaktionsprotokoll überwachen möchten.

Es scheint, dass im obigen Thread für die CPA "vollständig normalisiert" Regeln bedeutet, die von allen Buchhaltern anerkannt werden, während für den Programmierer eine andere Bedeutung darin besteht, dass keine abgeleiteten oder redundanten Daten gespeichert sind.

Alles, was es zu Buchhaltungsdaten gibt, ist eine Reihe von Transaktionen, die den Betrag und die Konten, von denen und zu denen sie fließen, zusammen mit ihrem Datum, einer Beschreibung (und anderen Anhängen) angeben. Ledger und Salden sind einfache Sichten, die aus diesen Transaktionsdaten mit Hilfe von Summen abgeleitet werden.

Ein Journal ist eine chronologische Auflistung aller Transaktionen eines bestimmten Typs für ein Buchhaltungssystem. Hier ist eine klassische Präsentation eines einfachen Sales (on Account) Journals auf Hauptbuchpapier :

Beachten Sie, dass jede Zeile eine einzelne Transaktion ist, mit Total Debits = Total Credits; und dass jede Transaktion die gleichen drei Konten trifft. Ein Barverkaufsjournal würde ähnlich aussehen, aber die Spalte Debitorenbuchung durch eine mit Bareinzug beschriftete Spalte ersetzen . Ein Barauszahlungsjournal würde eine erste Spalte mit der Bezeichnung " Barauszahlung" und zusätzliche Spalten wie " Debitorenbuchhaltung" und " Debitorenbuchhaltung für Mitarbeiter" enthalten .

Diese Präsentation war jahrhundertelang Standard, bis PCs vor einigen Jahrzehnten erschwinglich wurden. Es hat den entscheidenden Vorteil, dass Sie einfach überprüfen können, ob jede Transaktion ausgeglichen ist, indem Sie einfach jede Zeile überprüfen. Ebenso könnten die Seitensummen vor dem Posten einer Seite einer solchen Transaktion in den Hauptbüchern auf ähnliche Weise überprüft werden. Dies ist ein Stapelverarbeitungsmodell, das in vielen Buchhaltungssystemen verwendet wird.

Es ist leicht zu erkennen, dass dieses Papiermodell erhebliche Nachteile aufweist, wenn es buchstäblich in ein automatisiertes System übertragen wird:

1. Die Datenstruktur ist schwenkbar, wohingegen es erfahrungsgemäß viel einfacher (auch robuster und leichter zu überprüfen) ist, eine gefaltete Datenstruktur zu programmieren. und
2. Da jedes spezialisierte Journal einen anderen Satz von Konten trifft, jede solche Journal müssten separat entworfen und programmiert werden, eine verschwenderische und fehleranfällige Tätigkeit.

Aus diesen Gründen wird im Allgemeinen empfohlen, den Entwurf für spezialisierte Journale als Schnittstelle zum Buchhaltungssystem zu verwenden, aber eine Datenstruktur zu entwerfen, die das numerische Repository für mehrere Journale sein kann. In einem modernen RDBMS hat dies den potenziellen Vorteil, dass das Hauptbuch und sogar die spezialisierten Nebenbücher zu indizierten Sichten des Journals werden können, wodurch die Codierung eines Buchungsvorgangs (der Schritt, bei dem eine Journaltransaktion gesperrt ist und über ein Konto verfügt) vollständig entfällt Summen, die in die verschiedenen Hauptbücher übertragen wurden).

Unabhängig vom Datendesign, mit dem Sie am Ende fertig sind, müssen Sie für jede Vorgangsart (dh jedes Fachjournal im entsprechenden Papiersystem), in dem Saldenprüfungen durchgeführt werden, einen einzigen Buchungseintrag erstellen .

Mein Punkt ist, dass beide von Ihnen vorgeschlagenen Ansätze unsolide Mechanismen für die doppelte Buchführung sind. Erster Punkt: Journale sind aus guten Gründen einmal beschreibbare Tabellen. Manchmal sind die beiden virtuellen Tabellen Pending Entries und Posted Entries in einer einzigen Datenstruktur zusammengefasst, aber das IsPosted- Bit ist immer schreibgeschützt und das System muss sicherstellen, dass der Nur-Lese-Charakter der Posted Entries-Datensätze beibehalten wird.

Die Art und Weise, wie Buchhalter in den letzten 800 Jahren Journaleinträge veröffentlicht haben, ist vollständig normalisiert . Der einzige Unterschied zwischen einer Papierpräsentation und einer soliden elektronischen Präsentation besteht darin, dass eine gefaltete Tischstruktur im letzteren Fall praktischer ist, während eine geschwenkte Tischstruktur im ersteren Fall von größter Bedeutung war, als eine hochparallele Verarbeitung gewünscht wurde - dh jeweils viele Angestellte Führen einer einzelnen oder einer kleinen Anzahl von Fachzeitschriften. Nur der Controller hatte in der Vergangenheit Berechtigungen für das General Journal.

Beachten Sie sorgfältig, dass ich oben angegeben habe, dass Journaleinträge vollständig normalisiert sind. Journaleinträge sind eine chronologische Aufzeichnung aller Transaktionen, gruppiert in Zeitschriften spezifisch für jede Bewegungsart. Die Buchung von Journalbuchungen in die Ledger ist ein eigenständiges Unterfangen und, obwohl vollständig normalisiert, eine redundante Kopie der Journalbuchungen, in der alle Transaktionen nach Konto zusammengefasst (Hauptbuch) oder detailliert (Nebenbuch) sind. Sowohl Journals als auch Ledgers verwenden unabhängig voneinander die doppelte Buchführung.

@Codism Mit jedem Abrechnungssystem, DEB oder SEB, können Sie allgemeine Berichte für alle erfassten Konten erstellen . Beachten Sie, dass ein Nebenbuch intern per Definition ein Buchhaltungsdatensatz mit einem Eintrag ist. Die andere Seite sind die entsprechenden Kontrollkonten in der Bilanz. Die DEB stellt sicher, dass für jeden Vermögenswertdollar eine genaue Aufzeichnung des Geschäftsanspruchs auf den Vermögenswert vorliegt , dh des Eigenkapitals des Vermögenswerts, unabhängig davon, ob es sich um ein Fremdkapital (auch als Verbindlichkeit bezeichnet) oder ein Eigenkapital handelt , und der Priorität dieser Ansprüche, wenn die Organisation wird zahlungsunfähig.

Darf ich vorschlagen, dass Sie einen Blick auf die Schatzkammer der Open Source-Software werfen, die es in diesem Bereich gibt?

Ein Google von " Open Source Double Entry Accounting Software " bietet mehrere vielversprechende Möglichkeiten der Untersuchung.

Sie könnten das GNU - Accounting - Paket buchen , hier , ein paar Seiten schreiben ( 1 & 2 ) und schließlich die Wiki von Buchhaltungs - Software mit einem Abschnitt über Freie Software.

Ich bin mir sicher, dass Sie beim Untersuchen einiger F / LOSS-Quellcodes und -Schemas einige gute Tipps und Hinweise zum Schreiben von Schemas und / oder Software erhalten, die Ihren speziellen Anforderungen entsprechen.

Ich habe ein System, das doppelte Linien und seine vielen Herausforderungen erledigt, als einzeilige Konten zu haben. Zuerst bin ich auf Fälle gestoßen, in denen nur eine Zeile wie die Lastschrift verschoben wurde, was zu einem unausgeglichenen Konto führte. Selbst wenn ich Commit- und Rollback-Kontrollen nicht ordnungsgemäß durchführe, würde dies nicht in einzeiligen Konten geschehen. Schließlich wächst Ihre Datenbank mit doppelter Wachstumsrate. Ihre zweite Sendezeile enthält viele doppelte Informationen. Der einzige Unterschied ist das zweite Konto. Würde raten, einen einzeiligen Account beizubehalten, gehe auf diese Route ..