質問：以下の場合、すべての金額を正の小数として保存し、借方を負の金額として保存し、貸方を正の金額として保存するのではなく、金額を「借方」または「貸方」としてフラグ付けする必要がありますか？
私のデータベース設計では、「借方」を負の金額として保存し、貸方を正の金額として保存します。
これを行うと、結果が間違って表示されることがあります。
TotalAmount = Amount-Fee、および引き出し額が$ 100で、手数料が$1の場合。
最終的に-$100-$1 =-$ 101になりますが、これは誤った結果です！ 。
ご存知のように、すべてに1つの列を使用してから、借方または貸方に負の数を使用しても機能しません。アカウンティング値はスカラーではありません。列挙型（借方または貸方）と固定小数点の10進数（正または負の場合があります）を含むベクトルです。
すべての会計トランザクションには、同数の借方と貸方が含まれている必要があります。そうでない場合、それは有効なトランザクションではありません。
同様に、口座残高も同じ種類のベクトルです。いつでも、会計システムのすべてのアカウントの合計借方と合計貸方は互いに等しくなければなりません。そうでないと、何かが壊れました。
これを見る別の方法は、会計値を複素数と考えることです。ここで、借方は実数であり、貸方は虚数です。これは、4デビット+3クレジット=4+3iを意味します。これにより、虚数項を負の実数項に折りたたむことによって、これ以上単純化することはできないことが明らかになります。これは、同じ数直線軸ではありません。これは、4 + 3i=4-3と主張するのと同じです。有効な数学ではありません。
データベースが複素数をネイティブに格納できる場合、複素数は実際には会計データを格納するための優れた方法であり、プログラマーが会計に関して通常抱える多くの混乱を解消し、あらゆる種類の興味深いプロパティにつながる可能性があります。たとえば、バランスの取れたトランザクションは、バランスの取れたアカウントのセットと同様に、常に45度の位相角を持ちます。ただし、ほとんどのデータベースでは、保存する前に複素数を実数と虚数に分解し、それらの用語を異なる列に保存する必要があります。会計の世界では、これら2つの列の名前はそれぞれ「借方」と「貸方」です。
PS：一部の人々がクレジットにネガティブを使用し、デビットにポジティブを使用していることを私は知っていますが、これは正しく行うために細心の注意を払っており、壊れやすいです。アカウントに触れるたびに、アカウントの通常の残高を追跡する必要があります。たとえば、資産アカウントには借方の通常の残高があるため、正の数を使用して増やすことができます。ただし、負債勘定科目の通常の残高は負であるため、その勘定科目の値の増加は負の数になります。これらの2つの値をいつでも合計することはできません。これらは同じものではありません。借方はあなたが持っているものであり、貸方はあなたが借りているものです。データベーステーブルの同じ列に両方を配置すると、悪臭がします。
アカウンティングはすべてジャーナルエントリに基づいているため、データモデルはそれに従うのが最適な場合があります。これは、テーブルに2つの列があり、1つは借方用、もう1つは貸方用であることを意味します。次に、アプリケーションに任せて、何を「正」の値と見なし、何を「負」と見なすかを決定します。（質問は常に発生します-誰の観点からポジティブですか？銀行口座間で送金する場合、一方のアカウントでは「ネガティブ」ですが、もう一方のアカウントでは「ポジティブ」です。）
このような作業をしてからしばらく経ちますが、借方と貸方の列に正と負の両方の値が含まれている可能性があることを覚えているようです。会計士は私たちのプログラマーとは数字についての考え方が異なるため、会計士のためにソフトウェアを作成する場合、彼らの慣習に従って作業しようとすると、物事を単純化することができます。
私はSageTimberline会計システムを使用しており、借方を正の金額として、貸方を負の金額として保存しています。試算表を含むすべてのレポートで、借方と貸方を行います。次に、借方の取消には負の借方を行い、貸方の取消には正の貸方を行います。正常に動作します
OK、私はパーティーに少し遅れていますが、ここにいくつかの興味深い答えがあり、私は自分のテイクを追加する必要があると思いました。
質問に答えるには：値を正の金額として保存し、借方または貸方としてフラグを立てる必要がありますか？
簡単な答え：フラグを追加する必要はありません。正しい署名された形式で番号を保存すると、どのシステムでもフラグ「デビット」または「クレジット」が自動的に適用されるためです。それは「-」記号です。代わりに、借方または貸方の2つの列のいずれかに値を格納する必要がありますか？絶対にありません ！システム内のすべてのトランザクションに空のフィールドを保存するのはなぜですか？正しい符号付きの値を持つ単一の列は、管理がはるかに簡単です。
質問のタイトルに対する長い答え：会計とデータベースの設計、借方と貸方の金額の保存。
複式簿記を理解している限り、それは完全に単純で堅牢です。仕訳帳を名目元帳に転記するときは、仕訳帳の各行の借方項目と貸方項目をユーザーに提供します。アプリケーションでは、フィールドの1つだけに値（1行あたり）を許可します。値は正の符号なしの値である必要があります。トランザクションを作成するときに、借方がある場合は、そのまま書き込みます。クレジットフィールドに値がある場合は、それを逆にして負の数として書き込みます。データベースでは、1行（レコード）ごとに、1つの列に1つの符号付きの値のみが表示されます。会計士なら誰でも言うように、仕訳はバランスを取る必要があるので、仕訳トランザクションラインのデータベースレコードは合計でゼロになります。アプリケーションコードは、ジャーナルのバランスが取れていることを確認する必要があります。
次に、ユーザーがシステムに追加する購入請求書について考えてみます。Widget Companyのこの（ありそうもない）請求書があるとしましょう。
棒鋼は500ポンド
封筒1箱100ポンド
旋盤で£10000
£2120購入税
合計£12720の請求書
アプリケーションは、ドキュメントテーブルに単一のレコードを書き込みます。トランザクションテーブルへの1対多のリンクがあります。3行の請求書の場合、5つのトランザクション行がアプリケーションによって書き込まれます。
500ポンドは、損益計算書の総勘定元帳勘定である売上原価にリンクされています。借方残高=損益計算書にある場合の費用
損益計算書の総勘定元帳であるステーショナリーにリンクされた£100。借方残高=損益計算書にある場合の費用
貸借対照表の総勘定元帳勘定であるMachineryにリンクされた£10000。借方残高=bsにあるときの資産。
£2120は、bsglアカウントであるInputTaxReclaimableにリンクされています。借方残高=資産、私たちは税務署からお金を借りています
-bsglアカウントであるCreditorsControlにリンクされた£12720。クレジット残高=負債、これはサプライヤーのおかげです
トランザクションテーブルに書き込まれた5つのレコードの合計値は£0.00です。
次に、ユーザーが追加する売上請求書について考えてみます。
プレミアムウィジェットは250ポンド
標準ウィジェットの場合は£250
£100の消費税
合計£600の請求書
ここでも、単一のレコードがドキュメントテーブルに書き込まれます。2行の請求書の場合、4つのトランザクション行が書き込まれます。これは売上請求書であるため、アプリケーションはバックグラウンドで値を逆にする必要があります。売上請求書の行は簿記のクレジットですが、ユーザーはそれらを負の値として追加する必要はありません。
£250-プレミアムウィジェットセールス、損益計算書アカウントにリンクされています。クレジット残高=損益計算書にあるときの収入/利益
£250-標準ウィジェットの販売、損益計算書のアカウントにリンクされています。クレジット残高=損益計算書にあるときの収入/利益
£100-未払税金、bsglアカウントにリンクされています。クレジット残高=BSにいるときの負債。私たちはこのお金を税務署に借りています。
bsglアカウントであるDebtorsControlにリンクされた£600。借方残高=資産、これはお客様の負担となります。
トランザクションテーブルに書き込まれた4つのレコードの合計値は£0.00です。
返品されたものにクレジットを付けたい場合は、売上請求書にマイナスの行を追加してもまったく問題ありません。トランザクションを書き込む前に、他のすべての行と逆になります。より一般的には、クレジットノートを発行します。このノートには、売上収益の借方として書かれた行があり、損益計算書の売上高が減少します。
システムが在庫管理を行っている場合、数量は取引明細に書き込まれ、製品テーブルにリンクされます。
銀行のエントリは、多くの場合、本以外のキーパーを追い出します。彼らは、私たちは銀行にお金を入れたので、口座に入金したと言います。銀行をビジネスの外部の人と考えてください。あなたが安全に保管するためにあなたのお金を渡すとき、彼/彼は債務者になり、あなたのお金を要求に応じて返還しなければなりません。したがって、銀行への領収書は借方として記録され、支払いは貸方として記録されます。顧客から支払いを受け取ると、2つのトランザクションラインを記述します。
銀行口座、bsglアカウントにリンクされた£600。借方残高=資産の価値を高め、より多くのお金を持っています。
£600-bsglアカウントであるDebtorsControlにリンクされています。クレジット残高=資産の価値を減らし、私たちはより少ないお金を借りています。
トランザクションテーブルに書き込まれた2つのレコードの合計値は£0.00です。
これを実行すると、Debtors Controlには売上請求書の発行時に600ポンドが書き込まれ、支払いの受領時に600ポンドが書き込まれていることがわかります。正味残高=£0.00。これは、お客様が現在支払うべき金額です。
したがって、適切な設計、関係、およびインデックスを使用すると、すべてのレポートはドキュメントとトランザクションの組み合わせから実行されます。
以上です。トランザクションテーブルを合計すると、常にゼロが返されます。2つの列を維持する必要はありません。アプリケーションは2つのことを行う必要があります。さまざまなトランザクションタイプに正しい署名を適用するようにコーディングする必要があります。また、トランザクションが0より大きいか0より小さいかに応じて、2つの列のいずれかにトランザクションを表示する必要があります。したがって、試算表、顧客とサプライヤの元帳、銀行と現金の勘定科目、および総勘定元帳をすべて借方と貸方の列に適切にフォーマットすることができます。
複式簿記の両面を1回の取引で記録するシステムを構築することは魅力的です。1つのトランザクションが失敗しても、アカウントのバランスが崩れることはありません。署名された値の列は1つだけです。各トランザクションに2つのgl外部キーを記録します。1つは記録した値（借方または貸方を表す正または負の値）用で、もう1つは投稿するアカウントを記録するためのgl外部キーです。反対の（「複式簿記」）値。また、2つの税管理勘定の総勘定元帳も記録する必要がある場合があります。1つは出力税管理勘定用で、もう1つは入力税管理勘定用です。したがって、トランザクションラインを1つではなく4つのglアカウントにリンクすることになります（さらに、顧客のリンク、両方の方法に適用されるサプライヤーと製品の表）。コントロールアカウントには、非常に大量のトランザクションがリンクされています。10行の請求書には、ドキュメントごとに1つではなく、10のトランザクションがリンクされます。伝票の合計としてではなく、各請求書明細の税要素を個別に計算する必要があります（とにかくこれを行う場合があります）。最後に、ジャーナルエントリドキュメントの特別な取り決めが必要になります。これには、借方として10行が含まれ、貸方として1行だけオフセットされるため、ここでは単一トランザクションアプローチは機能しません。伝票の合計としてではなく、各請求書明細の税要素を個別に計算する必要があります（とにかくこれを行う場合があります）。最後に、ジャーナルエントリドキュメントの特別な取り決めが必要になります。これには、借方として10行が含まれ、貸方として1行だけオフセットされるため、ここでは単一トランザクションアプローチは機能しません。伝票の合計としてではなく、各請求書明細の税要素を個別に計算する必要があります（とにかくこれを行う場合があります）。最後に、ジャーナルエントリドキュメントの特別な取り決めが必要になります。これには、借方として10行が含まれ、貸方として1行だけオフセットされるため、ここでは単一トランザクションアプローチは機能しません。
SQL Server内のABS関数を使用して、絶対値を取得できます。これにより、負の数を正の数として扱うことができます。
例えば：
select ABS(-100)
100ではなく、を返します-100。
これは、「データモデルリソースブック」と呼ばれるすばらしい本のトランザクション詳細スキーマです。このスキーマは、2つの列を使用せずにすべての記録要件を満たします。
PK TransactionID - int
PK TransactionDetailSequenceID - smallint
Amount decimal
CreditDebitFlag char(1)
シンプルで効果的であり、ここで他の回答が示唆しているように、無関係な列を使用しません。すべての数値データを格納する1つの列でありながら、資産および負債の勘定科目を適切に追跡する機能を提供します。
すでに受け入れられている答えがありますが、それは非常に質問のポイントですが、他の人がデータベースを設計するときに特別に決定するのに役立つ可能性があるので、私の意見も共有したいと思います！
全体的に、両方とも独自の短所と長所がありabs()、受け入れられた答えのように使用することで問題を簡単に終わらせることができます！しかし、問題は、異なる人々が異なる心を持っている可能性があり、特にデータベースから値を直接読み取っている場合に、（-ve）値を保存すると実際にはさらに混乱が生じると信じているチーム間で話すときに発生します！
ほとんどの場合、借方に記入するときに-ve値をデータベースに保存することに反対していませんが、+ veを保存すると、データベースプログラマーであっても、実際には混乱が少なくなります。コードを記述しようとすると、アプリレベルで簡単に変換できます。
データベースレベルでの使用には例外がありsum(value)ますが、実際にはこれは最も使用されていないシナリオです。これは、会計ではほとんどの場合、実行中の残高が表示され、アプリレベルでは（+）または（-ve）を使用できるためです。
私が提起したいのは、データベースは企業の観点または顧客の観点で使用できるということです。現在、企業には両方の観点から考えるデータアナリストがいます。また、+ veの数値を保存すると、すでにフラグが設定されているため、覚えやすくなります。どのような価値が何であるかを知っています！