两次录入簿记数据库设计

我正在创建会计软件。我需要强制两次记账。我有一个经典的问题，即每笔交易要排两行。

让我们举个例子，看看在两种情况下如何实现它。

考虑帐户Cash和帐户Rent。当我支付月租金时，我将$ 100从我的Cash帐户转入我的Rent帐户。

每笔交易一行

在单行系统中，此类交易将存储为：

交易

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

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

每笔交易两行

在两行系统中，我必须镜像相同的事务记录以创建相反的记录，一旦我将两者都加起来，就会得到零余额。

交易

 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

问题

首先，我想指出：我同时拥有transactions和transaction_records表（而不是一个表）的原因是能够处理拆分交易（这种情况下，我将100美元从一个Cash帐户转移到两个或多个不同的帐户）。

最初，我尝试用每笔交易一行来实现这一点，但是要计算帐户余额并实际检索数据很麻烦。

我倾向于第二种情况；但是，它也存在一些问题：

• 如何更新单个记录？假设我犯了一个错误，我没有记录$ 100的房租，而是记录了$ 10。我现在有2个transaction_records-贷方1个，借方1个，金额均为$ 10。
• 现在，我进行对帐，并且想解决此错字。如何在数据库中解决此问题？我不知道记录之间的联系，如果发生拆分，则一个事务可以包含两个以上的记录。我想出的唯一解决方案是ref_id为每个记录对添加一些，以将这些记录唯一地标识为特定上下文内的“彼此相对” tx_id。

哪种方法更好/更简单？

为了简化我的问题：我想代表资金从帐户A到帐户B的转移。我给出的两种情况都是存储此类交易的有效设计。正如我也指出的那样，它们都有优点和缺点（第一个优点：更易于保存，更难检索；第二个优点相反）。

他们可能还有其他优点/缺点，但我暂时没有发现，因此，我想请经验丰富的人发表意见。

实际上，所提出的单行记帐方案允许进行适当的两次记帐（以始终指定借记和贷记的帐户），而不会引入“金额”数据的冗余。

单行模式为您提供了一个双重条目的实现，该条目按构造进行平衡，因此不可能“失去平衡”。机器可以即时重新计算分类帐。

您必须选择2（而不是1）来检索分类帐。

请注意，除了交易拆分外，还有其他交易，例如外汇交易可能会以2条记录而不是4条记录结束。这全部取决于您是否要对非规范化进行一点处理，只需输入4条描述类似的交易即可。

您可以阻止任何事务的输入或修改以维护审核记录，如果您希望能够审核事务日志，则需要这样做。

似乎在上面的线程中，对于CPA，“完全规范化”似乎表示所有会计师都认可的规则，而对于程序员而言，它具有不同的含义，即没有存储派生数据或冗余数据。

会计数据所要做的就是一组交易，这些交易给出金额，金额，来源，以及它们的日期，一些说明（和其他附件）。分类帐和余额是通过求和从此事务数据得出的简单视图。

一个杂志是一个指定类型的会计制度的所有事务的年代列表。这是一本简单的销售（按客户）日记帐在分类帐上的经典演示：

请注意，每一行都是一笔交易，总借方=总贷方；并且每笔交易都击中相同的三个帐户 一个现金销售杂志看起来相似，但更换色谱柱应收账款借方与一个标记Cash银行。一个现金支出杂志将有标记的第一列Cash信用卡和附加列，如应付账款借方和员工费用借方。

这种演示是数百年来的标准，直到几十年前个人计算机可以负担得起。通过简单地检查每一行，可以轻松验证每个事务是否平衡，这具有显着的优势。同样，在将此类交易的页面发布到分类帐之前，可以类似地验证页面总数。那是许多会计系统中使用的批处理模型。

可以很容易地看到，当从字面上转录为自动化系统时，此纸模型具有明显的缺点：

1. 数据结构是一种关键数据结构，而经验表明，针对折叠数据结构进行编程要简单得多（也更健壮，更容易验证）。和
2. 因为每个专业日记帐都使用不同的帐户集，所以每个这样的日记帐都必须分别设计和编程，这既浪费又容易出错。

由于这些原因，通常建议使用“ 专业日记帐”设计作为会计系统的接口，但设计一个可以作为多个日记帐的数字存储库的数据结构。在现代的RDBMS中，这具有潜在的优势，即总帐，甚至专门的子分类帐都可以成为日记帐上的索引视图，从而完全消除了对过帐流程进行编码的要求（日记帐交易被锁定并拥有其帐户的步骤总计转录到各种分类帐中）。

无论您最终采用什么数据设计，关键是要对进行余额检查的每种交易类型（即等效纸张系统中的每个专业日记帐）都有一个单独的过帐条目。

我的观点是，您提出的两种方法都是重复记录簿记的不可靠机制。第一点：出于充分的理由，日记是一次写入表。有时，两个虚拟表 Pending Entries和Posted Entries并置在单个数据结构中，但是IsPosted位始终是只写的，并且系统必须确保保持Posted Entries记录的只读性质。

过去800年来会计师发布日记条目的方式已完全规范化。纸质演示文稿和声音电子演示文稿之间的唯一区别是，在后一种情况下，折叠桌结构更方便，而在前一种情况下，枢轴桌结构更方便，这在历史上在需要高度并行处理时最为重要-即每个职员都有很多文员。维护单个或少量的专业期刊。历史上只有Controller拥有对General Journal的权限。

请仔细注意，在上文中，我指定日记帐分录已完全规范化；日记帐分录是所有交易的按时间顺序记录，并按每种交易类型分类在日记帐中。该帖子的日记帐分录的总帐是一个独立的努力和，而在自己的完全正常化，是帐户，所有交易汇总的日记帐分录（总帐）或详细（分类帐）的冗余副本。Journals和Ledgers均独立使用两次记账。

@Codism任何会计系统，例如DEB或SEB，都可以为您记录的所有帐户提供通用报告。注意，在内部，从定义上讲，子分类账是单项簿记记录；另一侧是资产负债表上的相应控制帐户。DEB确保对资产的每一美元都有准确的资产资产商业债权记录，即资产中的权益（无论是债务权益（aka负债）还是所有权权益），以及这些债权的优先级（如果有）组织破产。

我是否可以建议您看一下该领域中的开源软件宝库？

谷歌的“ 开源复式记账软件 ”给出了几种有希望的调查途径。

您可以在此处查看GNU会计软件包，两个评论站点（1和2），最后是会计软件Wiki，以及关于自由软件的部分。

我敢肯定，通过检查一些F / LOSS源代码和模式，您可能会获得一些有关如何编写适合自己特定需求的模式和/或软件的良好提示和指示。

我的系统比起单行帐户，做双行和很多挑战。首先，我遇到了像借方那样只推一行的情况，导致帐户不平衡。即使没有对提交和回滚进行适当的控制，也不会在单个行帐户中发生这种情况。最后，您的数据库以双倍的增长率增长，您发送的第二行将有很多重复的信息，唯一的区别是第二个帐户。建议保留单行帐户，然后再去那条路线。