ジャーナルエントリはデータベース設計に記録する必要がありますか?
現実の世界では、日次簿記を保持し、後で複式簿記を複式簿記に振り替えることは理にかなっています。しかし、コンピューター化されたバージョンでは、これを行うと重複したレコードが生成され、それはまったく意味がありませんか?
Real life:
User ---> journal day book (single entry) ---> ledgers account (double entry)
ジャーナルエントリはデータベース設計に記録する必要がありますか?
現実の世界では、日次簿記を保持し、後で複式簿記を複式簿記に振り替えることは理にかなっています。しかし、コンピューター化されたバージョンでは、これを行うと重複したレコードが生成され、それはまったく意味がありませんか?
Real life:
User ---> journal day book (single entry) ---> ledgers account (double entry)
複式簿記のポイントは、訓練を受けた会計士なら誰でもすぐに理解できるということです。したがって、会計士向けのシステムを構築している場合は、会計士のドメインを正確にモデル化すると、コミュニケーションが容易になります。複式簿記モデルでのみ実装できるビジネスルールもあるかもしれません(私の側の推測です)。
また、常に役立つ優れた監査証跡も提供します。
編集
「ジャーナルエントリを記録する必要があるかどうかを知りたいと思っていました」
経理のバックグラウンドを持つ多数のユーザーに論理データモデルを提示する場合は、間違いなくジャーナルをエンティティとして含めます。ただし、物理データベースに関しては、元帳テーブルのビューとして実装することをお勧めします。
あなたの質問は本当に会計システムの設計についてです。運用上の考慮事項は、監査証跡です。
私の意見では、日記の段階をスキップすると、データベースに記録されている内容とユーザーが入力した内容からさかのぼることが難しい場合があります。データ入力用のユーザーインターフェイスが日記のように見える場合、さかのぼることができるようにするには、日記を記録する必要があります。会計士は、この問題の重要性を評価するのに役立ちます。
結果として生じる冗長性は、コンピュータリソースの観点からコストがかかる可能性があります。また、処理にバグがある場合、データベースの内部に一貫性がなくなる可能性があります。システムの混乱とデータ入力の人為的エラーの違いを見分けることができるのは、おそらく矛盾の痛みの価値があります。
繰り返しますが、会計士はあなたに言うことができます。プロジェクトに助言する会計士がいない場合は、会計士を取得します。
複式簿記は、複式簿記の各側が異なる名目元帳勘定に送られるため、重複レコードを生成しません。それが「重複レコード」の意味するのかどうかはわかりませんが、それをクリアする必要があると思いました。明らかに、データベースに重複する行を作成することは、一般的には良い考えではありません。