会计系统设计和数据库

Question

我正在开发一个简单的发票和会计应用程序，但我完全不知道如何在数据库中表示会计交易（日记帐）。在数据库中使用单独的借方和贷方列似乎是一种方法，但我看到的大多数开源会计软件都使用单个金额列。我认为这样可以简化很多数学运算。但是如何将借方和贷方转换为数字值呢？维基百科有所帮助，但当我尝试与会计系统进行核对时，它看起来并不是那样完成的。请点击此处。

请看一下日志326。虽然在这种情况下金额总和= 0，但贷方总和不等于借方总和（从咨询和会计（E）借出29，从AP（L）借出31.39，向销售税（L）贷款2.39）。然而，如果我将其视为从AP借出-31.39，就可以了。但我不确定是否可以借贷负值。

有人能解释一下数据库和会计原理如何配合吗？请点击此处查看导出内容。

- Abhishiv Saxena

Answer 1

Martin Fowler的《分析模式》书中有一章很好地介绍了建模会计系统。也许可以帮到你。

我认为，思考这个问题时最好从对象的角度出发，而不是试图将其映射到关系数据库上。数据库是声明性和基于集合的；对象通过组件封装数据和操作。我认为后者更适合建模会计，特别是如果与面向方面的编程结合使用的话。让数据库成为持久化数据的方式，并将逻辑保留在中间层。

- duffymo

---

我已经翻阅了Fowler的书，但它并不能帮我解决这个特定的问题。 - Abhishiv Saxena

Answer 2

我认为你提到的326号交易问题在于，你似乎在Debit/Credit方面搞错了。

正确的方式应该是：

从咨询与会计中借出29，

从销售税中借出2.39（如果这是您作为消费者需要支付的税），然后从AP中贷入31.39。

通常，除非你结清了付款，否则应将AP放在Credit侧。那么交易将是从AP中取出xx.xx，然后从现金/银行账户中存入xx.xx。

将这些Debit/Credit事项分开处理，可以使数据库更易读。此外，将这些列分开的用户界面也更容易与终端用户沟通。在我看来，我们将事物放在与用户从会计课堂学到的相似的方式中，我们就需要花费更少的时间告诉他们如何使用软件。

我们不能在会计交易中使用负值。但是，在DBMS方面，如果我们对Debiting使用+，对Crediting使用-，则可以将它们保存在同一列中。无论如何，在导出会计报告时，仍需将其转换为绝对正值。

- Viruch Hemapanpairo

---

你说得对。当我这样想的时候，一切都变得很清晰明了。非常感谢！ - Abhishiv Saxena

Answer 3

请查看SQL-Ledger，这是一个使用Perl和PostgreSQL实现的免费软件会计系统。它可以为您提供一个工作示例。（我与他们没有任何关系，但我之前使用过它，对于基本的会计工作还是不错的。）

- Eric Heflin

Answer 4

我要概述的是从记忆中得出的，很可能是一种“老式”的表示账户的方式。

借方的定义 - 任何或所有以下条件之一：

1. 增加资产（例如每当您向某人发票时） 2. 增加费用（购买文具）

贷方的定义 - 任何或所有以下条件之一：

1. 收入增加或资产减少 2. 负债增加

在您的账户表中，可以有一个名为“正常余额”或“典型余额”的标志类型列 -

对于应收账款账户 - 正常余额为“D”或借方。 对于应付账款账户 - 正常余额为“C”或贷方。

每当有发票交易时 - 它会针对AR（应收账款）进行发布 - 并且它会发布“正常余额”，即被视为借方金额。

每当客户支付发票（全额或部分），它就是针对AR账户的（异常）- 因此它将是贷方。

每当供应商向您发送发票时，您将在应付账款上发布正常余额，即信用。每当您支付供应商时，它将是（异常-即借方）针对应付账款的发布。

您的发票类或发票交易知道它将正常发布至应收账款（Accounts receivable account）。

同样，您的付款交易或付款控制器模型知道它将针对AR发布信用。

请记住，当您向某人开具发票时，您正在“建立资产”，通过创建“应收账款”。因此，除非它们已经未支付多年，否则AR被视为资产。

希望对您有所帮助。

- blispr

---

谢谢回复！我知道借方和贷方与账户类型的关系。我的问题是如何在数学上表示借方和贷方？我想在我的transaction_entries表中只有一个金额列，而不是分开的借方/贷方列。 - Abhishiv Saxena