複式簿記データベースの設計

私は会計ソフトウェアを作成しています。複式簿記を実施する必要があります。トランザクションごとに1行と2行の古典的な問題があります。

例を挙げて、両方のシナリオでどのように実装されるかを見てみましょう。

account Cashとaccountを検討してくださいRent。毎月の家賃を支払うと、Cashアカウントから100ドルを口座に振り替えRentます。

トランザクションごとに1行

1行システムでは、このようなトランザクションは次のように保存されます。

取引

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

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

トランザクションごとに2行

2行のシステムでは、同じトランザクションレコードをミラーリングして反対のレコードを作成し、両方を合計すると、残高がゼロになります。

取引

 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

問題

まず最初に注意したいのは、（1つのテーブルの代わりに）テーブルtransactionsとtransaction_recordsテーブルの両方を持っている理由は、分割トランザクションを処理できるようにするためです（Cashアカウントから2つ以上の異なるアカウントに100ドルを転送する場合）。

最初は、トランザクションごとに1行でこれを実装しようとしましたが、アカウントの残高を計算し、実際にデータを取得するのは面倒です。

私は2番目のシナリオに傾いています。ただし、いくつかの問題もあります。

• 単一のレコードを更新するにはどうすればよいですか？間違いを犯し、家賃に100ドルを記録する代わりに、10ドルを記録したと仮定します。私は現在、2 transaction_recordsつを持っています-1つはクレジット用、もう1つはデビット用で、どちらも金額が10ドルです。
• 今、私は和解を行い、このタイプミスを修正したいと思います。データベースでこれをどのように修正しますか？レコード間の接続がわかりません。また、分割の場合、1つのトランザクションに3つ以上のレコードが含まれることがあります。私が思いついた唯一の解決策ref_idは、特定ののコンテキスト内で「互いの反対側」であるとしてそれらのレコードを一意に識別する各レコードのペアにいくつかを追加することtx_idです

どのアプローチがより良い/簡単ですか？

質問を簡単にするために、口座Aから口座Bへの資金の移動を表したいと思います。私が与えた2つのシナリオは両方とも、そのような取引を保存するための有効な設計です。私も指摘したように、両者には短所と長所があります（1つ目は保存が簡単で、取得が難しく、2つ目は反対です）。

彼らには、私が今のところ見つけていない他の長所/短所があるかもしれないので、より経験のある人から意見を聞きます。

実際、提案された単一行の会計スキーマにより、「金額」データの冗長性を導入することなく、適切な二重記入会計を行うことができます（常に借方と貸方の勘定を指定します）。

1行のスキーマは、構造によってバランスを取る二重エントリの実装を提供するため、「バランスを失う」ことは不可能です。マシンはその場で元帳を再計算できます。

元帳を取得するには、1つではなく2つの選択を行う必要があります。

トランザクションの分割に加えて、外国為替などのトランザクションは4ではなく2レコードになる可能性があることに注意してください。同様の説明で4つのトランザクションを入力するだけで非正規化するかどうかはすべて異なります。

監査証跡を維持するために、トランザクションの入力または変更を防ぐことができます。これは、トランザクションログを監査できるようにする場合に必要です。

上記のスレッドでは、CPAの場合、「完全に正規化された」とは、すべての会計士が認識するルールを意味するように見えますが、プログラマーには、派生データまたは冗長データが格納されないという異なる意味があります。

アカウンティングデータにあるのは、金額と、それらが流れる元となる口座、日付、何らかの説明（およびその他の添付ファイル）を提供する一連のトランザクションです。元帳と残高は、このトランザクションデータから合計を行うことで得られる単純なビューです。

A ・ジャーナルは、会計システムのための指定されたタイプのすべての取引の時系列のリストです。以下は、単純な売上（勘定）ジャーナルの元帳に関する古典的なプレゼンテーションです。

すべての行は単一のトランザクションであり、合計借方=合計クレジットであることに注意してください。すべてのトランザクションが同じ3つのアカウントにヒットすること。A 現金販売ジャーナルは同じように見えるが、列代わる売掛金デビットを 1つの標識されたと現金デビット。A 現金支出ジャーナルは、ラベルされた最初の列だろう現金クレジットとのような追加の列買掛金デビットと従業員の費用デビットを。

このプレゼンテーションは、数十年前にパーソナルコンピューターが手頃な価格になるまで、何百年もの間標準でした。各行をチェックするだけで、すべてのトランザクションのバランスが簡単に確認できるという大きな利点があります。同様に、そのようなトランザクションのページを元帳に投稿する前に、ページの合計を同様に検証できます。それはバッチ処理です多くの会計システムで使用されるモデルです。

このペーパーモデルは、自動化されたシステムに文字通り転写されると、重大な欠点があることは容易にわかります。

1. データ構造はピボット構造ですが、経験から、折り畳まれたデータ構造に対してプログラミングする方がはるかに単純である（堅牢で検証も容易です）ことが示されています。そして
2. 専門のジャーナルはすべて異なるアカウントのセットにヒットするため、そのようなジャーナルはそれぞれ個別に設計およびプログラミングする必要があり、無駄が多くエラーが発生しやすいアクティビティです。

これらの理由により、一般的には、会計システムへのインターフェースとしてSpecialized Journalsデザインを使用することをお勧めしますが、複数のジャーナルの数値リポジトリになり得るデータ構造をデザインすることをお勧めします。現代のRDBMSでは、これには総勘定元帳、さらには特別な補助元帳でさえも、ジャーナルのインデックス付きビューになることができるという潜在的な利点があります。これにより、転記プロセス（ジャーナルトランザクションがロックされ、そのアカウントを持つステップ合計がさまざまな元帳に転写されます）。

最終的にどのようなデータ設計を行う場合でも、バランスチェックが行われる各トランザクションタイプ（同等の紙のシステムの各専門ジャーナル）に単一の転記エントリを作成することが重要です。

私のポイントは、あなたが提案する両方のアプローチが複式簿記のための不健全なメカニズムであるということです。第一のポイント：ジャーナルは非常に正当な理由で追記型のテーブルです。2つの仮想テーブルの保留中のエントリと投稿済みエントリは単一のデータ構造に併置されることがありますが、IsPostedビットは常に書き込み専用であり、システムは投稿済みエントリレコードの読み取り専用の性質が維持されることを保証する必要があります。

会計士が過去800年間に仕訳を投稿した方法は、完全に正規化されています。紙のプレゼンテーションとサウンドの電子プレゼンテーションの唯一の違いは、後者の場合は折り畳まれたテーブル構造がより便利であるが、前者のピボットテーブル構造は非常に並列処理が必要な場合に歴史的に最も重要だったことです。単一または少数の専門誌を維持する。歴史的には、長官のみが一般ジャーナルの権限を持っています。

上記では、ジャーナルエントリが完全に正規化されることを指定したことに注意してください。仕訳は、すべての取引の時系列記録であり、各取引タイプに固有の仕訳にグループ化されています。元帳への仕訳入力の転記は別の作業であり、それ自体で完全に正規化されますが、すべての取引がアカウントごとに要約される（総勘定元帳）または詳細な（元帳）仕訳入力の冗長コピーです。JournalsとLedgersは両方とも、複式簿記を独自に採用しています。

@Codism DEBまたはSEBの会計システムは、記録されたすべてのアカウントの一般的なレポートを提供します。内部的には、補助元帳は定義上、単一エントリの簿記レコードであることに注意してください。反対側は、貸借対照表上の対応する統制勘定です。DEBは、すべての資産ドルについて、資産に対するビジネスクレーム、つまり、負債エクイティ（負債）または所有権エクイティであるかどうかの資産のエクイティの正確な記録と、組織は破産します。

この分野にあるオープンソースソフトウェアの宝庫をご覧になることをお勧めしますか？

「オープンソースの複式簿記ソフトウェア」のGoogleは、いくつかの有望な調査手段を提供しています。

ここではGNU会計パッケージ、2つのレビューサイト（1＆2）、最後にフリーソフトウェアに関するセクションを含む会計ソフトウェアのwikiを見ることができます。

F / LOSSのソースコードとスキーマの一部を調べることで、特定のニーズに合ったスキーマやソフトウェアの作成方法についての良いヒントと指示を得ることができると確信しています。

私は、二重回線を行うシステムと、単一回線のアカウントを持つよりも多くの課題を抱えています。最初に、借方側のようにプッシュされている1行のみのインスタンスに遭遇し、アカウントが不均衡になりました。コミットとロールバックの適切な制御を行っていなくても、これは単一行のアカウントでは発生しません。最後に、データベースは2倍の成長率で成長し、2番目の送信行には多くの重複情報がありますが、2番目のアカウントのみが異なります。保持することをお勧めします、単一行アカウント、そのルートに行きます。