会计系统设计＆amp;数据库

Question

我正在开发一个简单的发票和会计应用程序，但我完全迷失了如何在数据库中表示会计事务（日记条目）。在数据库中使用单独的借方和贷方列似乎是一种方式，但我见过的大多数开源会计都使用单一金额列。我认为这简化了数学。但是，我如何将借方和贷方转换为数值。 Wikipedia Helped a little，但当我尝试与会计系统进行交叉检查时，它看起来并不是这样做的。

来自该会计系统的

Here's the export：

看一下期刊326.虽然这个案例的金额总和= 0，但是学分总和不等于借方总和（来自咨询与会计（E）的借方29，来自AP的借方31.39）（ L），并将2.39记入销售税（L））。

但是，如果我将其视为来自AP的Debiting -31.39，它确实如此。但是我不确定我们是否可以贷记/借记负值。

有人可以解释数据库和会计原则如何结合在一起吗？

Answer 1

Martin Fowler的"Analysis Patterns"在会计系统建模方面有一个很好的章节。也许它可以帮助你。

我认为你最好在对象方面考虑问题，而不是试图将其映射到关系数据库。数据库是声明性的和基于集合的;对象使用组件中的操作封装数据。我认为后者将更好地用于建模会计，特别是如果你将它与面向方面的编程结合起来。让数据库成为您持久化的方式，并将逻辑保留在中间层。

Answer 2

我认为您提到的交易326的问题是，您似乎已经在借方/贷方的错误方面做了。

正确的应该是： 来自咨询公司的借记29会计，和 从销售税中扣除2.39。 （如果这是您必须作为消费者支付的税） ，然后从AP获得31.39，

通常情况下，AP将在信用方面，除非您确定付款。然后交易将是 从AP借记xx.xx，然后从现金/银行借记贷款xx.xx

在单独的列中处理这些借记/贷记事项可能会使数据库更易于阅读。顺便说一句，分隔这些列的UI也更容易与最终用户通信。在我看来，我们越是把用户从会计课程中学到的东西变得类似，我们花在告诉他们如何使用软件上的时间就越少。

我们不能对会计交易使用负值。但是在DBMS方面，如果我们使用+代表借方，那么我们可以将内容保留在同一列中，并且 - 对于Creditings。无论如何，在导出到会计报告时，您仍然需要将它们转换回绝对正值。

Answer 3

查看SQL-Ledger，这是一个用Perl和PostgreSQL实现的免费软件会计系统。应该给你一个有效的例子。 （我与他们没有任何关系，但之前我已经使用过它，基本会计也很满意。）

Answer 4

我要概述的是记忆，很可能是一种代表帐户的“老式”方式。

**借记卡的定义 - 任何或所有这些条件**

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

**信贷的定义 - 任何或所有这些条件**

1. 增加收入或减少资产
2. 增加责任

在您帐户的表格中，您可以拥有一个名为“正常余额”或“典型余额”的旗帜类列 -

• 表示/ c应收账款 - 正常余额为“D”或借方。
• 用于应付帐款 - 正常余额为“C”或贷记。

每当有发票交易时 - 它会对AR（应收账款）进行过帐 - 并且它会发布'正常余额'，即它被视为借记卡。

每当客户支付发票（全部或部分）时，它就会对AR账户发起（异常） - 因此这将是一个信用。

每当供应商向您发送发票时，您都会在AP帐户上发布正常余额，即信用额。无论何时向供应商付款，都将是针对AP帐户的（异常-i.e.借记）过帐。

您的发票类或发票交易知道它将正常发布AR（应收帐款帐户）。

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

请记住，当您向某人开具发票时，您通过创建“应收款”来“建立资产”。因此，AR被视为资产，除非他们多年没有获得报酬。

HTH。