会计引擎核心三要素（一文漫谈会计引擎）

青春应该怎样度过?有的如同烈火，永远照耀别人。有的却像荧光，甚至也照不亮自己!不同的生活理想，不同的生活态度，决定一个人在战斗中站的位置。所以就跟老师来一起看看吧。

总账系统的职能定位往往是作为企业级统一的核算平台。一般来说，业内比较通用的账务解析能力主要有两种：

支持会计流水文件，文件中包含完整账务分录，总账系统的作用主要体现在归集账务数据，以完成财务报表合并；支持业务流水文件，此类文件最大的特点是仅包含业务属性要素，此类文件必须要经过会计引擎的解析翻译，才能表达成符合核算规则的会计分录。

上述的第二种文件，就必须要使用本文重点介绍的内容：会计引擎。

01 账务要素

如下图，一张传统的“会计传票”或者“会计凭证”的样式，主要要素是账务日期，传票序号，摘要，科目，借贷方向，金额（大小写）。会计电子化之后，相比传统纸质的会多出一些必要的字段，以便报送数据的加工（例如：EAST报送）或者财务数据分析。

在介绍会计引擎之前，我们先理解一个概念：“账务要素”。账务要素即一组/套传票/凭证/分录中的信息。我习惯划分成两部分：基础要素和扩展要素。

基础要素的定义是借贷平衡检查的范围，即：账套，机构，科目，币种，借贷方向，金额；扩展要素的定义是作为扩展字段仅做信息展示和记录，有时会用作数据关联等用途。例如：产品编号、凭证摘要、备注、价税分离标识、冲正标识等。

以上要素其实就是会计引擎追求的输出表达结果。如此一来，会计引擎的解析其实就在做两件事。1）将业务流水中要素信息做赋值表达；2）将业务流水中要素信息做加工。以下再对两种类型做个归类理解：

赋值型

通过上游业务系统提供的字段进行映射赋值，例：账套、产品、摘要、备注 、价税分离标识、冲正标识、机构、币种、金额。

加工型

通过上游业务系统提供属性字段进行组合加工，其中最重要的就是科目和借贷关系：

科目，按照统一核算的架构设计，源业务系统不需要维护科目号，那么科目显然必须通过会计引擎的解析来完成；借贷关系，分录中的借贷关系也必须按照既定的核算规则通过会计引擎实现，一般分为：一借一贷和多借多贷（包括一借多贷，一贷多借）。

通过以上介绍，我们终于建立了对会计引擎的最质朴的理解：通过业务流水的要素解析出账务要素。

02 引擎原理

在上一Part结尾的时候得到的结论还可以进一步完善，更准确的说法应该是业务流水与系统预置的规则参数共同作用，被会计引擎翻译成账务要素。下图用一个逻辑流程图可以描述的更加清晰。

在敏捷开发的思想驱动下，为追求开发管理的效率和成本，很多架构设计很早就将逻辑代码和业务代码进行解耦。这里类同低代码的实现思想，其本质是追求整体解决方案的效益，这里不做开展讨论。通俗的讲，在职能上把研发人员和需求人员进行了分工，研发人员专心设计和维护底层程序，目标是标准化，上层通过高度参数化的配置功能面向系统的用户提供能力；而这个配置工作仅仅需要一名逻辑性强的业务/需求人员就可以即可完成。这名需求人员只需要全身心的关注和挖掘“业务语言”和“逻辑语言”，而不需要再费劲心思琢磨“编程语言”。我们知道所谓语言无非是一套灵活的，体系化，预定义的规则。其他还有些好处是从设计模式上将稳态和敏态实现了分离，而且可以实现支持热更新的部署。

对于会计引擎，我很喜欢这个简洁的见解。“规则引擎可以被视为复杂的if-then语句解释器，被解释的if-then语句称为规则。”

常见的规则引擎框架有Drools、OpenL Tablets、Easy Rules、RuleBook等。以Drools框架为例，“当业务用户或自动化系统在 Drools 中添加或更新规则相关信息时，该信息会以一个或多个事实的形式插入 Drools 引擎的工作内存中。Drools 引擎将这些事实与存储在生产内存中的规则条件进行匹配，以确定符合条件的规则执行。（这种将事实与规则匹配的过程通常被称为模式匹配。）当满足规则条件时，Drools 引擎会激活并在议程中注册规则，然后 Drools 引擎会对优先级或冲突的规则进行排序以准备执行。”

Drools 引擎组件概览

图中Drools 引擎组件介绍：

规则：您定义的业务规则或 DMN 决策。所有规则必须至少包含触发规则的条件和规则规定的操作。Facts：输入或更改到 Drools 引擎中的数据，Drools 引擎匹配规则条件以执行适用规则。生产内存：规则存储在 Drools 引擎中的位置。工作记忆：事实在 Drools 引擎中存储的位置。议程：注册和排序激活规则的位置（如果适用）以准备执行。

03 引擎配置

基于以上会计引擎的运行原理，我们开始理解会计引擎上层的配置功能。为了实现复杂功能，多层级配置的设计经常被应用到这类低代码思想的实践中，这已经不稀奇了。观察使用了市场上主流的几款会计引擎产品，归纳整理一般设计分为三层：

账务场景层：这是最贴近交易场景的模式设计，理论上应该可以和实际业务场景一一对应，对每个场景进行编码后，因为一一对应了业务场景，那么场景码也是业务类系统中很容易关联取值到的一个值。在这个基础上仔细研究的话，还可以大致归纳为3种类型：例如：贷款放款场景、提前还款场景、利息计提场景等，这一类交易场景你基本可以在业务系统中找到对应的业务节点或者人工坐席端的触发动作；例如：利息计提场景，正常贷款转逾期场景等，这一类场景一般属于业务系统批处理执行，也是会产生账务；例如：募集期内行本行理财申购场景，此类场景往往只是行内的资金冻结交易，暂不涉及账务，等募集期结束才会真正划款到对应理财账户，进行账务处理。此类交易场景一般不需要在会计引擎中体现，但是作为分析过程，我也一起做了归类。公共交易层：这一层设计原理是抽象出一些公共的规则以便于复用，最佳的状态是完全抽离业务逻辑，达到最小的交易原子规则。例如：贷款业务的还款交易中都会分为本金还款和利息还款两块，其中本金还款是相同的分录模板，如下表。正常类还款，逾期还款，非应计还款也就是对应的贷方本金科目不同。那这个模板就可以被多个场景复用，但是细心的朋友可以发现，这里交易越抽象，执行条件的判断就需要越复杂。

DR

客户账户（活期存款）

CR

贷款本金科目

分录模板层：定义科目映射关系，解决科目的解析问题。这里会引入一个金额类型的重要概念来解决映射逻辑处理。

例如：常见的金额类型有正常本金，正常利息收入，逾期利息收入，罚息收入，手续费，公允价值等，如果是正常本金，那么对应的本金科目号也就固定了。通过接口文档中设置不同的金额类型字段，业务系统在对应的金额类型字段下传入金额即可。会计引擎在解析出科目号的同时，就可以直接赋值金额。

以上已经解释说明了会计引擎配置的设计，从逻辑完整性角度，还需要再做以下补充。

账务场景层：通过交易场景核算配置，还需要完成以下两个事项。

1）建立场景和子交易关联关系，在数据库中维护场景码和公共交易编号的关联关系，以便一层一层的传递逻辑；

2）接口表中来源字段和目标字段的映射，如账套编号，产品编号等；

公共交易层：通过子交易规则配置确定借贷关系，同样要关注以下事项：

1）建立关联关系：子交易-金额类型；

2）执行条件+借贷关系+“金额类型+业务属性值+产品” + 赋值（金额）；

其中，执行条件非必选，其实就是IF的条件遍历，若为空则必执行该分支。

分录模板层：通过产品属性组合和会计科目配置完成科目映射

1）“金额类型+属性+产品”的建立关联；

2）“金额类型+属性+产品”的关联关系=>科目号。

至此，就可以通过会计引擎解析出完整的账务分录了。

04 核算管理

前文中介绍会计引擎配置层级的逻辑关系，那么在梳理过程是正好反过来的。在实操过程中，一般可以分为以下三步。

1】整理核算办法文档

1-1 文档需要明确包括产品-交易场景-账务场景-分录的信息；

1-2 一般来说，核算办法文档由运管部制定核算办法的部门（或称清算中心）确定，若现有科目无法满足，会请会计部评估进行新科目开立，流程因不同银行的内管需要而异，供参考。

2】会计引擎的场景梳理文档

2-1基于核算文档分析确定影响账务关系的业务属性因子，如：境内境外，短期中长期，个人对公等；

2-2基于核算文档分析抽象子交易及其分录；

2-3完成会计引擎配置

3】定义给业务系统的接口文档

3-1需要和业务系统沟通确认接口中定义的各个属性参数能否准确提供，因为依赖其逻辑实现。

4】测试联调，全场景的账务明细核对。

---

新系统建设不单单意味着新功能而已，伴随着系统建设，与其相生相伴的管理制度也应该一同与时俱进的完善，这也是为什么我特意提到上文中第四部分的考量。通过数字化建设，尊重过去经验，引进新理念，把专业化和规范化全面建立，才会实现最大价值。

会计引擎核心三要素（一文漫谈会计引擎）的问题您看懂了吗，希望这个解答可以帮助到您，如果大家还想知道更多的可以关注我们会计实战基地哦！会计实战基地是专业的线上考证培训机构，能最大程度解决您的会计考证难题，还在等什么呢？赶快行动起来吧！