LWN：确定了会计系统！

关注了就能看到更多这么棒的文章哦～

The end of the accounting search

By Jonathan Corbet
May 5, 2023
DeepL assisted translation
https://lwn.net/Articles/925782/

有些事情就是没法加速的。早在 2007 年，编者第一次开始考虑替换一下 LWN 自始至终一直使用的专有的会计系统（proprietary accounting system）。在 2012 年的时候这跟需求变得更加紧迫了，并在 2017 年又重新开始集中精力寻找更好的方案。但又过了五年，才达成某种结论。不过好在终于最终还是达成了目标，LWN 不再使用专有软件来满足会计需求了。

到目前为止一直使用的系统是 QuickBooks，这是公司 1997 年成立之初就开始采用的。长期以来，一直表现出专有系统特有的各种不合适的行为。尽管新版本几乎没有带来什么新的功能，但还是不得不要定期地进行（付费）更新。经常会有 crash；QuickBooks 的用户都知道每隔几分钟就要做一次备份，以避免丢失工作内容。该软件有各种各样的限制，目的都是强迫 "升级" 到 "enterprise" 版本。最近，Intuit 已经完全停止了对桌面版的支持，从而迫使所有用户都使用其按月付费的在线服务。

够了，终于够了。编者花了一些时间回去查看过去曾经考虑过的各种系统。结果发现，为从 QuickBooks 中提取出数据而开发的脚本仍然有效，至少在更新到 Python 3 后（更新得有点晚）。最后，我们选定的胜出方案是 GnuCash。

How the decision was made

有大量的免费会计系统存在于 Linux 系统上。许多都是很复杂，都是用来解决更大的问题的；它们包括库存跟踪功能、客户关系管理功能等。这样的系统操作起来很不方便，而且很难上手。事实上，许多系统似乎是开发出来作为咨询业务（consulting business）的平台的，毕竟肯定没有人会故意让他们的软件复杂和棘手来激励客户购买他们的服务的。LWN 倾向于不以这种方式花费辛苦赚来的钱，毕竟也不需要那些复杂的功能，所以这些系统在早期就被我们放弃了。

另外一个方向上，有一些会计系统是基于纯文本文件和一组相关的程序的。这些系统更容易操作，可以适应大多数需求。这样的系统可以用在 LWN 里，但它们往往缺乏一些有用的功能。例如，支票书写和报告生成往往支持得不是很好。许多操作的用户界面都是直接使用文本编辑器；这通常被视为一种优势，但随着交易数量的增加，这种优势就不那么明显了。为手头的工作而设计的图形界面是有优势的。

GnuCash 绝不是一个完美的程序，但它确实提供了 LWN 所需要的会计功能，以及一个合理的图形界面，以及最低程度的额外复杂性。

2017 年的重新调查的时候列出了新的会计系统必须满足的一些要求：

• 数据的导入和导出必须可以支持，而且要是相对比较简单的。将我们的 QuickBooks 数据导入 GnuCash，需要使用相应的 Python 绑定支持来编写一些脚本。此后，我们又编写了另一组脚本，从网站和银行账户中导入数据。GnuCash 对银行输出的数据格式导入功能方面实现得非常强大，采用一个贝叶斯（Bayesian）系统将交易分配给账户，但使用脚本的话可以让这个过程更快。
  

• 基本的会计操作需要操作简单，毕竟本来就是简单的动作。
  

• 也需要能针对我们的法律报告要求生成表格。GnuCash 有一些功能来处理这个问题，虽然不是针对美国的表单。最后，这个任务我们现在只需交给我们的会计师，由他和我们的年税申报一起处理就行。还有一个相关的要求是打印支票，这对一个企业来说是很重要的；下面会有更多关于这个问题的说明。
  

• 上面提到了要方便跟 LWN 其他业务整合；Python 绑定的支持使得大多数事情都很容易做。
  

• 最后一个要求是该系统的未来有关，就是社区健康程度如何？GnuCash 项目开始于 1997 年，比 LWN 略早；它在四分之一个世纪后仍然在这里，并且仍然在发布。GnuCash 可能不会很快消失。不过它的开发社区比人们所希望的要小，而且进展也不快。
  

总而言之，多年前列出的要求已经得到了很好的满足，足以让我们做出改变。

Some further impressions

在许多方面来看，GnuCash 还没有完成开发。例如，很多年来它一直具有使用 SQL 数据库（PostgreSQL、MySQL 或 SQLite）的能力，但本地的 XML 格式仍然在文档里称为 "最稳定和最成熟的"，被推荐给大多数用户使用。在 PostgreSQL 中存储数据确实更有效率，使用这个方案时启动时间会稍微快一些。可悲的是，即使在使用 PostgreSQL 时，也不支持多用户访问。另一个例子是对账（reconciliation）过程，它不记得以前的 reconciled value 是什么，而是编造一些奇怪的东西出来。

GnuCash 有报告生成机制，显然投入了大量的精力；该系统被设计为可由终端用户所扩展的。不幸的是，这个扩展语言是 Scheme，而且在大多数情况下文档不足。Scheme 看起来像 Lisp，但并不是真正的 Lisp；熟悉它的人肯定不多。为 GnuCash 创建一个新的报告（或改进一个现有的报告）的工作看起来可能有点令人生畏；请看资产负债表的实现（https://github.com/Gnucash/gnucash/blob/stable/gnucash/report/reports/standard/balance-sheet.scm ）就是一个例子。编者最后发现直接在 GnuCash 之外用 Python 创建新的报告更容易。

打印支票的能力一直都在列表中。即使在美国，我们开的支票也比以前少得多，但仍是有这种需要的。GnuCash 具有这种能力，而且它可以与几乎所有的支票格式一起使用。用于添加新支票格式的语言很简陋，但它最终还是能很好地用起来的。GnuCash 的支票打印的一个恼人的特点是，每次打印支票时都必须输入地址信息，即使收件人的地址在 GnuCash 中被存储为一个供应商（vendor）也一样。

这次迁移中我们最大的损失是无法再用我们的会计师能够直接读取的格式将数据导出到他专有的报税系统里去了。不过，他愿意与我们合作，并相信从 GnuCash 生成的报告也是足以完成工作而不需要大量的额外工作（和费用）的。也许他也厌倦了听编者对 QuickBooks 的抱怨，这么多年来，他几乎已经做好准备可能会有任何一个东西来替换它。

最后，GnuCash 足以完成 LWN 需要它做的事情。摆脱了 LWN 运营中使用的一个专有程序，让我们对会计数据有了更好的控制，这种感觉真好。新系统运行得很好，编者正在为等待这么久才做出这一改变而自责。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～