一、核心账务的概述和术语定义
二、账务组织的业务概述
科目分级没有固定的标准，只要是末级科目都可以直接对应分户，非末级科目下不可以对应账户。有3个特点：
◇ 平时记账在叶子上。
◇ 叶子的余额方向向上继承。
◇ 余额向上汇总。
（2）程序设计
科目作为重要的汇总参数，是以采用科目号的形式进行展示。使用这种方法，使得当科目发生变化时，对金融产品的影响最小化，特别针对金融产品的各种重要参数表的调整变得更为简单。如下：
在科目号的组成规则上，通常把一级科目号设计成4位编码，并将旗下的二级科目号设计成6位编码，并且前4位就等于一级科目编号，三级科目号同理。实际编程时也是，在二级科目向上汇总的程序中，通常也会截取二级科目号的前4位作为一级科目。
三、银行产品与银行账户的关系
四、银行产品与核算的关系与分离
（1）产品与总账的关系
产品可以按需要与要求进行不同粒度的分类与细分，总账里与产品对应的科目，也可以按需要与要求进行不同粒度的细分，以与产品形成对应关系。
（2）产品与核算的分离
基于层次化、组件化设计理念，会计核算系统内部同样也可考虑分层架构设计。将影响会计分录的会计事件，按产品、分户账等重要信息进行归纳抽象，构建会计引擎用于核算解析。
当产品账户发生交易时，会计引擎能够根据产品交易事件信息，确定具体的产品，自动提取与会计核算相关的信息，并根据预先设定的核算规则，自动将采集的数据转化为会计分录，完成账务处理。当核算规则发生变化时，只需调整会计引擎中的参数化规则。
五、账户与核算科目解析自动化
（1）客户账号
（2）核算编码
核算编码每个核算编码对应一具体的银行业务产品，组成规则与业务人员制定核算维度有关，是基于大多数的业务交易场景而抽象出来的相关核算属性，比如产品类型、期限等，这是在很多金融业务场景中都存在的共性维度。举例：
（3）核算科目解析自动化
该方案下，业务交易层与会计核算还是有一点耦合，只是耦合度相对方案一来说更弱一些；另外，该方案对辅助项的考虑有所缺失，基本不支持辅助项的灵活设置。
（4）内部账户体系
六、记账核心实现方法和基本思路图
（1）总体设计思路
（2）会计分录接口
（3）总账处理模式
（4）总账汇总口径
（5）账务批量处理
七、浅谈会计分录解析
在4.2和5.3中我们介绍了两种生产会计分录的方式，分别是交易直接生产会计方式和核算科目解析自动化，接下来我们谈谈方案三，科目与金额解析自动化：
◇解析原理：
会计核算平台接收上游各个业务系统产生的通用交易流水，并根据会计场景的匹配条件，筛选出符合条件的会计场景，从而获取到该交易流水对应的会计分录配置，最后根据会计分录各配置项的取值规则，即可生成对应的会计分录。
◇关键词：通用交易流水、会计场景、匹配条件、会计分录配置
◇先对以上关键词做一个简要说明：
通用交易流水：指会计核算平台与上游的各个业务交易系统，按照约定的字段结构，生成的交易流水，一般来说，会尽量让上游生成的交易流水结构保持一致，即各业务交易系统都是按相同的字段结构生成交易流水，所以才称之为“通用交易流水”。
而会计核算平台原则上只处理该通用交易流水，这样可以使得会计核算平台的职责更为专注清晰，从而更为通用， 提升会计核算平台的扩展性。即使未来有新的业务交易系统需要接入，则该新系统只需要按照相同的字段结构生成通用交易流水即可，对于会计核算平台来说是完全透明的，无需改动，因为对于会计核算平台来说，接收处理该新系统的交易流水，与接收处理其他系统的交易流水，都是相同的流水结构。
当然，由于上游的业务交易系统众多， 一份通用交易流水结构可能不一定都能适用满足，当现有的这份通用交易流水字段套用在这不同上游系统中，若存在流水字段的复用率较低时，则要重新审视通用交易流水结构的设计。
比如通用交易流水共包含了10个字段，有2类系统用到的相同字段还不到3个，即字段复用率还不到30%时，此时再强制要求这2类系统使用同一份流水结构时，可能就与“通用”二字的初衷相背离了。
造成这种情况一般有2种原因：
1、对于通用交易流水的各个属性没有抽象好，这是属于设计缺陷。
2、这2类系统业务差异实在太大，共性的业务维度太少，比如只有一两个共性维度在这2类系统中才都存在，剩余维度都不相同。
◇应对办法：
针对前者，建议进一步梳理分析现有业务场景，识别出其共性维度。流水字段复用率不求百分百，但建议要达到70%以上。
针对后者，可能需要考虑新抽象出另一种通用交易流水结构，以满足这类业务交易的特点，也即需要2套通用交易流水结构，例如支付类的交易数据与业务类交易数据，在共性维度上是比较少的，此时可考虑设计2套通用流水结构：
1、通用业务交易流水，包括产品类型、产品码、交易资金类型等；
2、通用支付交易流水，包括转入账号、转出账号等；
当然，建议控制好通用交易流水的种类数目，不要设计太多种类的“通用交易流水”，这会导致系统的复杂度直线上升，尤其是对系统的可维护性和扩展性造成挑战。原则上建议尽量复用同一套流水结构。
◇会计场景
在会计核算平台中需配置好各个会计场景，一个会计场景主要由3部分构成：
1、基本信息，如场景码、场景名称等
2、匹配条件，即满足哪些条件，才算是属于本会计场景
3、会计分录，包括核算科目、借贷方向、分录金额、辅助项等
以上3部分，只有“匹配条件”与交易流水直接相关，即匹配条件的设计依赖于交易流水的设计。
下面对会计场景的关键点做进一步的说明：
（1）会计场景的匹配条件
匹配条件是连接 通用交易流水与会计分录的桥梁，因此会计场景的匹配条件的设计是会计分录解析中的关键。
由于会计核算平台只面向通用交易流水进行会计分录的解析，因此，匹配条件也只能来自于通用交易流水中。
事实上，这里的匹配条件与方案二中的“业务维度”是类似的思路，本质上都是对已知业务场景的通用业务属性的抽象，只不过方案二在业务维度的基础上，还抽象出了一个“业务编码”，使业务维度与余额属性得以解耦，使得即使在没有共性业务维度的场景下也能复用。当然方案二的“业务维度”，也可以进一步拆分为“业务维度串 + 业务事件”。但无论是如何拆解，匹配条件都必须源自通用交易流水。
（2）会计分录配置
只要确定了会计场景的匹配条件，则会计分录的配置就很简单了，剩下的就是会计分录各个配置项的取值规则的设计。
会计分录的主要配置项，或者说主要的构成有 核算科目、借贷反向、记账金额、辅助项这4个属性。
其中，核算科目与借贷方向可直接按照财务会计同事确认的会计分录来配置，记账金额可以基于交易流水中的交易金额设置，辅助项则可结合科目配置与交易流水来设置。
（3）会计分录配置
可考虑为每条分录中的记账金额配置一个取值表达式，该取值表达式为固定值、操作符、数值3者的组合：
1、固定值：一般默认为交易流水中的交易金额，也可以为金额属性名；
2、操作符：如：加减乘除、括号、负号等；
3、数值：也可称为系数，是个自然数；
以上3者通过操作符自由组合，比如：
1、固定值*1.5*0.1 或
2、(金额字段A-金额表字段B*1.5)*0.1
这里说下“固定值”的设计，一般是默认为通用交易流水中的交易金额，但如果通用交易流水中有多个金额属性字段时，可考虑使用金额属性名的方式来设置固定值，当然该方式会造成分录配置与通用交易流水部分属性的过于耦合，即需要在配置中绑定通用交易流水的部分属性名，采用这种方式需考虑维护性与扩展性上的成本。
（4）会计分录的辅助项设置
可基于会计科目配置的科目辅助项与通用交易流水的相关字段的矩阵来生成，可使用Java的反射来实现。该方式同样也需要在科目配置中耦合通用交易流水的部分属性。
（5）小结
以上第3点与第4点都提到需要在配置(分录配置、科目配置)中绑定通用交易流水的部分属性，虽然也可以再拆出一层配置来衔接两者，让两者解耦，但本质上依旧是相当于要在配置中绑定DB表字段名，一旦DB表结构有变化，则会影响到解析规则的稳定性。
当然了，一般来说，系统设计开发好后，核心实体模型一般可视为稳定的，所以核心的DB表的变化还是很少的(不考虑系统重构情况)，因此将核心实体的部分属性直接放在配置中也可接受。总之，是否应该采用这种方式见仁见智，还请各位小伙伴提出更好的思路。
（6）方案3总结
该方案从分录科目、借贷方向、记账金额、辅助项上都完全实现了彻底的配置化，配置化程度较高，尤其是对会计分录配置可统一管理，维护性较好；同时也使得上游业务交易系统与会计核算平的各自职责更为清晰单一，更加符合“低耦合高内聚”的设计原则。
该方案下大致可分为如下3步进行：
1.同步交易流水：即外围业务系统只需要按照约定的结构，生成对应的通用交易流水，并同步至会计核算平台
2.确定会计场景：即会计核算平台针对接收到的通用交易流水，与所配置的会计场景进行匹配筛选，获取到对应的会计分录配置
3.生成会计分录：在获取到分录配置后，根据会计分录各配置项的取值规则，即可生成会计分录。
但该方案对通用交易流水的抽象要求较高，因为接入的外围业务系统众多，可能需要抽象出多个通用交易流水结构（比如信贷核心产生的业务交易流水与 支付平台产生的 网银收付款流水 差异巨大，复用的业务属性很少，很难归类到同一种通用交易流水结构），且后续可能会不断有新的业务场景或者新系统接入。
在设计之初，要确定一个较为稳定的流水结构，难度会比较大，非常考验架构师或产品经理对目前自己所在公司的所有业务场景的熟悉理解程度以及抽象分析能力，因此，如何保证通用交易流水的通用性与扩展性是一个不小的挑战。
八、聊聊双边分录
系统中除了表外科目可以使用单边分录外，所有记帐都使用双边分录，达到每笔交易的自平衡。如果存在业务上的交易动作分离情况，将使用系统统一的机构挂帐户进行过渡处理，在进行过渡处理时，系统除了记录该账户的分录，还需记录柜员临时存欠登记簿，登记簿采用销账方式管理。
与丁种帐不同之处在于，该账户的销账允许部分销账，解决一借多贷或一贷多借情况，如果存在多借多贷情况，原则上必须自平衡或通过中间临时存欠账户管理，转换为上述两种情况。
机构挂帐户记账规则：
1、采用机构挂帐户进行处理。
2、在正常交易情况下，每日账户余额应为0，但在特殊情况下，如：机构网络中断情况，该账户有可能存在余额不为0的情况。
3、为避免虚增对机构挂帐户的发生额，规定对该账户的记账为转账、借贷标志只为借，也即交易时可能的分录为借方蓝字或借方红字。
4、在记录机构挂账户时需要同时进行柜员临时存欠登记簿的登记。
5、柜员在签退时，除了上缴尾箱、进行柜员轧帐外，还需检查柜员临时存欠登记簿，检查柜员有无关联交易未完成。
6、在交易进行抹帐处理时，必须首先检查该交易是否已被核销，若已被核销，首先对核销交易进行抹帐处理，或通过冲正交易完成对交易的调整。
九、结束语
银行核心系统作为银行IT系统中的“心脏”系统，起着对整个银行的运行支撑的作用，而其中的账务处理，更是银行的血脉，融会贯通整个银行的核心系统。再回到我们最开始提到的三个关键词：产品、账户、科目，层层深入，每一层都有很多细节上的关注点，每深入一层都能有新的收获，每一层都值得深究，每一层都需要一整篇章来介绍。因为只有这样的深入分析和总结，业务才会更严谨，系统才会更完善。所以作为一个初步的梳理，可能还有更关键点有遗漏，欢迎各位小伙伴补充，一起探讨。