2010年12月13日、質問がありました。
総勘定元帳と買掛金の業界標準の論理データモデルを探しています。すぐに利用できる会計データモデルはありますか？
ケンダウンズは答えた：
抜粋：
最も基本的な元帳は、アカウント、バッチ、およびトランザクションの3つのテーブルです。>すべてのトランザクションはバッチである必要があります。一部の人々は借方と貸方のために2つの列を作成しますが、私は常に1つの列を作成し、借方と貸方は反対の符号を持っています。
買掛金も非常に簡単です。その中心となるのは、ベンダーの表と>バウチャー/請求書の表です。最後に生成されたチェックの表...その後、味わうために装飾します:)
請求書と小切手表の両方が総勘定元帳に影響を与えるので、それぞれが一意のバッチ番号を格納する必要があると想定するのは正しいですか？スキーマは、invoice：batchテーブルとchecks：batchテーブルに対して1：1の関係を示しますか？アドバイスありがとうございます。
ここには 1 対 1 の関係はありません。たとえば、いつでも複数の請求書を 1 つのバッチで支払うことができます。バッチ テーブルの考え方は、プログラミングの観点からではなく、アカウンティングの観点から見た単一の「作業単位」であるということです。
バッチの特別な必要性はありませんが、誰がいつ何をしたかという観点から情報を整理するのに役立ちます。特に、一連のトランザクションがビジネスの観点から互いに論理的に関連していることを示す場合は特にそうです。
Accounts はルックアップ テーブルです。トランザクション ヘッダーであるバッチとは対照的に、トランザクションはトランザクションの詳細です。単一の金額フィールドで十分であるという @OP の質問から、Ken Downs に同意します。借方と貸方の列を分けても意味がありません。このアイデアは紙の会計の世界から来ており、すべての計算が手作業で行われていた時代から役に立ちます。コンピュータ化されたシナリオでは、そのアイデアは時代錯誤であり、実際には価値がある以上の問題を引き起こします。Ken Downs の借方と貸方の符号が反対である限り、私は同意しません。これは特定のアカウントのコンテキスト内では当てはまりますが、さまざまな種類のアカウントには、会計規則に従って正または負の金額の借方があります。資産と収益は一方向に進み、負債と費用は反対方向に進みます。トランザクション テーブルの数値が正か負かは、トランザクションが適用されるアカウントの種類の問題になります。
編集の 1 つは、借方と貸方を適切に適用するときに、すべてのバッチの残高がゼロになるようにする必要があります。この編集をテストするためのロジックは、バッチ内の各勘定科目が資産、負債、収入、または費用のいずれであるかを知る必要があるため、勘定科目テーブルの属性である必要があります。
小切手、バウチャー、請求書、その他すべてについては、おそらく必要ですが、必ずしもすべてが必要というわけではありません。それらを持つ理由は、厳密な口座残高追跡のためではなく、そこに保持できる他のすべての指標情報のためです. この指標となる情報はすべて、バッチ テーブルの「ダム」テキスト フィールド (つまり「メモ」) に保持できます。これは、古い背の高い椅子、バイザー、羽ペンの時代に彼らが行った方法です. ただし、仕入先請求書テーブルがあると、特定の仕入先からのすべての請求書のリストを照会するなどの便利なことができるので便利です。小切手、請求書（売掛金）、明細書などの他の具体的なビジネスエンティティにも同じことが言えます。