我正在开发一个简单的发票和会计应用程序，但我完全不知道如何在数据库中表示会计交易（期刊条目）。在数据库中使用单独的借方和贷方列似乎是一种方法，但我见过的大多数开源会计都使用单个金额列。我认为这大大简化了数学。但是，我如何将借方和贷方转换为数值。 Wikipedia Helped a little，但是当我尝试与会计系统进行交叉检查时，它看起来并不像它是如何完成的。
Here's the export 来自该会计系统：
看看日记帐 326。虽然在这种情况下的金额总和 = 0，但贷方的总和不等于借方的总和（从咨询和会计（E）借方 29，从 AP（L）借方 31.39 )，并将 2.39 计入销售税 (L))。
但是，如果我将其视为从 AP 扣款 -31.39，它确实如此。但是我不确定我们是否可以贷记/借记负值。
有人能解释一下数据库和会计原则是如何结合在一起的吗？
【问题讨论】：
标签： sql ruby-on-rails database database-design activerecord
我认为你提到的交易 326 的问题是你似乎在借方/贷方的事情上做错了。
正确的应该是： 从咨询和会计中扣除 29，以及 从销售税中扣除 2.39。 （如果这是您作为消费者必须支付的税款） ，然后从 AP 计入 31.39，
通常情况下，AP 将属于贷方，除非您结清付款。那么交易将是 从 AP 借记 xx.xx，然后从现金/银行贷记 xx.xx
在单独的列中处理这些借/贷项可能会使数据库更易于阅读。顺便说一句，分隔这些列的 UI 也更易于与最终用户交流。在我看来，我们越是按照用户从会计课程中学到的东西的方式来做事情，我们花在告诉他们如何使用软件上的时间就越少。
我们不能在会计交易中使用负值。但在 DBMS 方面，如果我们使用 + 表示借方，使用 - 表示贷方，我们可以将内容保存在同一列中。无论如何，在导出到会计报告时，您仍然必须将它们转换回绝对正值。
【讨论】：
Martin Fowler 的"Analysis Patterns" 有一章很好地介绍了会计系统建模。也许它可以帮助你。
我认为您最好从对象的角度来考虑问题，而不是尝试将其映射到关系数据库中。数据库是声明性的和基于集合的；对象用组件中的操作封装数据。我认为后者更适合建模会计，特别是如果你将它与面向方面的编程结合起来。让数据库成为您持久化事物的方式，并将逻辑保留在中间层。
【讨论】：
查看SQL-Ledger，这是一个使用 Perl 和 PostgreSQL 实现的免费软件会计系统。应该给你一个工作的例子。 （我和他们没有任何关系，但我以前用过它，它对于基本会计来说是令人满意的。）
【讨论】：
我要概述的内容来自记忆，很可能是代表帐户的“老式”方式。
**借方定义 - 任何或所有这些条件**
**信用的定义 - 任何或所有这些条件**
在您的帐户表中，您可以有一个名为“正常余额”或“典型余额”的标志类型列 -
只要有发票交易 - 它会根据 AR（应收账款）过帐 - 并且会过帐“正常余额”，即它被视为借方金额。
每当客户根据发票（全部或部分）付款时，它都是针对 AR 帐户的（异常） - 因此它将成为贷项。
每当供应商向您发送发票时，您都会在 AP 帐户上过帐正常余额，即贷记。每当您向供应商付款时，这将是针对 AP 帐户的（异常 - 即借记）过帐。
您的发票类或您的发票交易知道它将根据 AR（应收帐款帐户）正常过帐。
同样，您的支付交易或支付控制器模型知道它将针对 AR 发布信用。
请记住，当您向某人开具发票时，您正在通过创建“应收账款”来“构建资产”。因此，AR 被视为资产，除非它们已经多年未支付。
HTH。
【讨论】：