一种会计分录生成方法、装置、电子设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种会计分录生成方法、装置、电子设备及存储介质。

背景技术

目前，在业务数据处理过程中，为了满足业务的核算需求，新一代核算架构实现了交易与核算的分离，即交易系统与核算系统分离。

示例性的，交易系统通常根据交易过程中产生的中间数据及业务数据，确定类型为核算三维要素及计科目表(Chart Of Accounts，COA)段值的目标数据，并将目标数据，分别通过对应的标准化接口传输至核算系统，以使核算系统中的(交易驱动)会计引擎，根据目标数据自动产生会计分录；具体的，核算系统通过配置的核算参数生成会计分录。

然而，采用上述生成会计分录的方式，会因目标数据可能并不满足正常分录的要求，从而导致直接根据目标数据生成的会计分录，无法作为后续进行业务分析的有效数据。

因此，采用上述方式，生成的会计分录作为后续业务分析数据的有效性较低，即无法确保用于会计分录生成的目标数据能够满足正常分录的要求。

发明内容

本申请实施例提供了一种会计分录生成方法、装置、电子设备及存储介质，用以确保用于会计分录生成的数据能够满足正常分录的要求，从而提高生成的会计分录作为后续业务分析数据的有效性。

第一方面，本申请实施例提供了一种会计分录生成方法，所述方法包括：

接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细；其中，每个记账明细表征：相应业务发起方与多个业务接收方之间的账务交易信息，账务交易信息包括：至少一种交易货币类型；

若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果；

当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录。

第二方面，本申请实施例还提供了一种会计分录生成装置，所述装置包括：

接收模块，用于接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细；其中，每个记账明细表征：相应业务发起方与多个业务接收方之间的账务交易信息，账务交易信息包括：至少一种交易货币类型；

校验模块，用于若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果；

生成模块，用于当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录。

在一种可选的实施例中，在接收上游业务系统提供的业务数据时，所述接收模块具体用于：

接收上游业务系统发送的数据接收请求，并从数据接收请求中，确定业务数据的数据传输模式；

若数据传输模式为消息传输模式，则按照对应消息传输模式设置的数据接收方式，接收业务数据；

若数据传输模式为文件传输模式，则按照对应文件传输模式设置的数据接收方式，接收业务数据。

在一种可选的实施例中，若满足以下条件，则确定各个记账明细，均满足设定的账务平衡条件：

针对所述各个记账明细，分别执行以下操作：

对第一记账明细进行解析，获得多个交易记录；其中，第一记账明细为各个记账明细中的任意一个记账明细；

当多个交易记录的交易轧差总和为0时，确定第一记账明细满足账务平衡条件。

在一种可选的实施例中，在基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验时，所述校验模块具体用于：

针对各个记账明细，分别执行以下操作：

若第二记账明细的业务类型为第一业务类型，则对第二记账明细进行区域机构联合维度的待清算科目核查，获得第一核查结果；其中，第二记账明细为各个记账明细中的任意一个记账明细；

基于第一核查结果和区域机构联合维度下的交易轧差总和，对第二记账明细进行校验；

若第二记账明细的业务类型为第二业务类型，则对第二记账明细进行区域、机构以及业务类型联合维度的待清算科目核查，获得第二核查结果；

基于第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，对第二记账明细进行校验。

在一种可选的实施例中，在基于第一核查结果和区域机构联合维度下的交易轧差总和，对第二记账明细进行校验的过程中，所述校验模块还用于：

若第一核查结果表征第二记账明细中，不存在区域机构联合维度下的待清算科目，且区域机构联合维度下的交易轧差总和不为0，则对第二记账明细进行轧差汇总清算，直至区域机构联合维度下的交易轧差总和为0。

在一种可选的实施例中，在基于第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，对第二记账明细进行校验的过程中，所述校验模块还用于：

若第二核查结果表征第二记账明细中，不存在区域、机构以及业务类型联合维度下的待清算科目，且区域、机构以及业务类型联合维度下的交易轧差总和不为0，则对第二记账明细进行轧差汇总清算，直至区域、机构以及业务类型联合维度下的交易轧差总和为0。

在一种可选的实施例中，若校验结果为以下任意一种，则表征各个记账明细中，存在满足预设正常分录条件的目标记账明细：

区域机构联合维度下的交易轧差总和为0；

或者，

区域、机构以及业务类型联合维度下的交易轧差总和为0。

在一种可选的实施例中，在针对目标记账明细生成会计分录时，所述生成模块具体用于：

基于目标记账明细，获得跨区域的第一交易记录子集和非跨区域的第二交易记录子集，并针对第一交易记录子集，生成跨区域的会计分录；

基于第二交易记录子集，获得跨机构的第三交易记录子集和非跨机构的第四交易记录子集，并针对第三交易记录子集，生成跨机构的会计分录；

基于第四交易记录子集，获得跨业务类型的第五交易记录子集和非跨业务类型的第六交易记录子集，并针对第五交易记录子集和第六交易子集，生成跨业务类型的会计分录和非跨业务类型的会计分录。

在一种可选的实施例中，在针对目标记账明细生成会计分录之后，所述校验模块还用于：

针对获得的多个会计分录，分别执行以下跨系统往来科目检查操作：

若第一会计分录中的交易轧差总和不为0，则确定第一会计分录为异常会计分录；其中，第一会计分录为多个会计分录中的任意一个；

若第一会计分录中的交易轧差总和为0，且第一会计分录对应的业务类型为第一业务类型，则在区域、机构以及系统科目联合维度下的交易轧差总和不为0，则确定第一会计分录为异常会计分录；

若第一会计分录中的交易轧差总和为0，且第一会计分录对应的业务类型为第二业务类型，则在区域、机构、业务类型以及系统科目联合维度下的交易轧差总和不为0，则确定第一会计分录为异常会计分录。

第三方面，本申请提供了一种电子设备，其包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行上述第一方面所述的会计分录生成方法的步骤。

第四方面，本申请提供了一种计算机可读存储介质，其包括程序代码，当所述程序代码在电子设备上运行时，所述程序代码用于使所述电子设备执行上述第一方面所述的会计分录生成方法的步骤。

第五方面，本申请提供了一种计算机程序产品，所述计算机程序产品在被计算机调用时，使得所述计算机执行如第一方面所述的会计分录生成方法步骤。

本申请有益效果如下：

在本申请实施例所提供的会计分录生成方法中，接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细，若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果，从而当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录；采用这种方式，通过设定的账务平衡条件，对各个记账明细进行初步校验，并在初步校验成功后，对基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，这样，确保用于会计分录生成的数据能够满足正常分录的要求，从而提高生成的会计分录作为后续业务分析数据的有效性。

此外，本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者，通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为本申请实施例适用的一种可选的系统架构示意图；

图2为本申请实施例提供的一种会计分录生成方法的实施流程示意图；

图3为本申请实施例提供的一种接收上游业务系统提供的业务数据的逻辑示意图；

图4为本申请实施例提供的一种基于业务类型进行记账明细校验的方法实施流程示意图；

图5为本申请实施例提供的另一种基于业务类型进行记账明细校验的方法实施流程示意图；

图6为本申请实施例提供的一种明细分录生成批处理的方法实施流程示意图；

图7为本申请实施例提供的一种判断记账明细是否满足预设正常分录条件的逻辑示意图；

图8为本申请实施例提供的一种生成跨平衡段会计分录的逻辑示意图；

图9为本申请实施例提供的一种生成跨平衡段清算分录的方法实施流程示意图；

图10为本申请实施例提供的一种跨系统往来检查的批处理的方法实施流程示意图；

图11为本申请实施例提供的一种会计分录生成装置的结构示意图；

图12为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

需要说明的是，在本申请的描述中“多个”理解为“至少两个”。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。A与B连接，可以表示：A与B直接连接和A与B通过C连接这两种情况。另外，在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

此外，本申请技术方案中，对数据的采集、传播、使用等，均符合国家相关法律法规要求。

以下对本申请实施例中的部分技术用语进行解释说明，以便于本领域技术人员理解。

(1)会计分录：亦称“记账公式”，简称“分录”，它根据复式记账原理的要求，对每笔经济业务列出相对应的双方账户及其金额的一种记录，仅是记账凭证的一部分。

(2)平衡段：是COA的一部分，可按此维度独立出表，新核心平衡段包括：责任中心、机构、区域、业务分类等。

一般设计COA至少包括：平衡段、科目段；其中，结算段处理公司代码、法人和资金的段，平衡段用于确保所有(日)记帐分录和引用的结算段的每个值平衡。

此外，科目段限定段的资产、负债、资产净值、收入和费用支出分类，俗称自然科目段。

(3)单边账：即完成交易操作后，交易平台和用户只有一方账面发生相应变化。

(4)跨系统：借贷两笔分录分别发生在两个不同系统的记账场景。

(5)跨区域：借贷两笔分录分别涉及两个不同的区域的记账场景。

(6)跨业务类型：也即跨业务分类，借贷两笔分录分别涉及两个不同业务类型或业务分类的记账场景。

(7)跨机构：借贷两笔分录分别涉及两个不同机构的记账场景。

(8)清算寸头：是一种以买入或卖出表达的交易意向，头寸可指投资者拥有或借用的资金数量，头寸也称为"头衬"就是款项的意思。

(9)资金头寸：是指在金融市场中，投资者或者交易者拥有的可以用来进行交易的资金总额；示例性的，某个企业、个人或组织在特定时间内所持有的现金和投资资产的总和。

(10)轧差：是指利用抵销、合同更新等法律制度，最终取得一方对另一方的一个数额的净债权或净债务，如，市场交易者之间，可能互有内容相同，方向相反的多笔交易，在结算或结束交易时，可以将各方债权在相等数额内抵销，仅支付余额。

(11)全局流水号：在金融交易系统中，一笔交易一般需要一个或多个系统在不同时段或相同时段对信息的协作处理才能完成。由于不可避免的系统缺陷或人为错误，金融交易并不总是能成功完成。

为了快速定位交易在信息系统中失败的原因，通常需要用一个唯一编号来代表该笔交易，无论这笔交易流转到系统中的哪个节点，该编号值不变。这种编号称之为所代表交易的全局流水号。

(12)子交易序号：在金融交易系统中，全局流水号在一笔交易处理过程中保持不变，为了进一步区分该交易的信息在各系统中的流转情况，在该笔交易的每次处理时，一般都会分配一个唯一序号，来标记本次处理，该序号在本次交易中唯一且有序，用来识别交易步骤。

进一步的，基于上述名词及相关术语解释，下面对本申请实施例的设计思想进行简要介绍：

目前，交易系统通常根据交易过程中产生的中间数据及业务数据，确定类型为核算三维要素及COA段值的目标数据，并将目标数据，分别通过对应的标准化接口传输至核算系统，以使核算系统中的(交易驱动)会计引擎，根据目标数据自动产生会计分录。

然而，采用上述生成会计分录的方式，会因目标数据可能并不满足正常分录的要求，从而导致直接根据目标数据生成的会计分录，无法作为后续进行业务分析的有效数据。

有鉴于此，为了确保用于会计分录生成的数据能够满足正常分录的要求，从而提高生成的会计分录作为后续业务分析数据的有效性，在本申请实施例中，提出了一种会计分录生成方法，具体包括：接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细；其中，每个记账明细表征：相应业务发起方与多个业务接收方之间的账务交易信息，账务交易信息包括：至少一种交易货币类型；若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果；当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录。

特别地，以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请实施例及实施例中的特征可以相互组合。

参阅图1所示，其为本申请实施例适用的一种系统架构示意图，该系统架构包括：上游业务系统(101a，101b)和服务器102。上游业务系统(101a，101b)和服务器102之间可通过通信网络进行信息交互，其中，通信网络采用的通信方式可包括：无线通信方式和有线通信方式。

示例性的，上游业务系统(101a，101b)可通过蜂窝移动通信技术接入网络，与服务器102进行通信，其中，所述蜂窝移动通信技术，比如，包括第五代移动通信(5thGeneration Mobile Networks，5G)技术。

可选的，上游业务系统(101a，101b)可通过短距离无线通信方式接入网络，与服务器102进行通信，其中，所述短距离无线通信方式，比如，包括无线保真(WirelessFidelity，Wi-Fi)技术。

本申请实施例对上述系统架构中涉及的通信设备的数量不做任何限制，例如，可以更多上游业务系统，或者没有上游业务系统，或者还包括其他网络设备，如图1所示，仅以上游业务系统(101a，101b)和服务器102为例进行描述，下面对上述各设备及其各自的功能进行简要介绍。

上游业务系统(101a，101b)，用于将业务数据发送给服务器102，以便服务器102根据接收到的业务数据，生成会计分录，和/或，向服务器102发送数据接收请求，以便服务器根据接收到的数据接收请求，接收业务数据。

示例性的，上游业务系统(101a，101b)包括但不限于：信贷系统、核心系统、票据系统、资产证券化系统、国际结算系统、线上贷款系统、财务系统以及信用卡系统等。

服务器102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

值得提出的是，在本申请实施例中，服务器102用于接收上游业务系统(101a，101b)提供的业务数据，并获取业务数据中的各个记账明细；进一步地，若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果；最终，当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录。

下面结合上述的系统架构，以及参考附图来描述本申请示例性实施方式提供的会计分录生成方法，需要注意的是，上述系统架构仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

参阅图2所示，其为本申请实施例提供的一种会计分录生成方法的实施流程示意图，执行主体以服务器为例，该方法的具体实施流程如下：

S201：接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细。

其中，每个记账明细表征：相应业务发起方与多个业务接收方之间的账务交易信息，账务交易信息包括：至少一种交易货币类型。

示例性的，业务发起方和业务接收方均可为：公司、机构、单位、组织以及企业等，为了便于理解与描述，在本文中，以业务发起方为机构为例进行描述；并且，业务发起方与业务接收方，在本申请实施例中的会计分录相关操作中，没有层级所属关系，每个记账明细中可表征：业务发起方对应的法人，以及业务发起方与多个业务接收方之间的账务交易信息。

可选的，账户交易信息可以为借贷信息，例如，业务发起方向业务接收方借款：200万人民币(￥)，再如，业务发起方向业务接收方贷款：50万美元($)。

在一种可选的实现方式中，参阅图3所示，在执行步骤S201时，服务器接收上游业务系统发送的数据接收请求，并从数据接收请求中，确定业务数据的数据传输模式，若数据传输模式为消息传输模式，则按照对应消息传输模式设置的数据接收方式，接收业务数据，若数据传输模式为文件传输模式，则按照对应文件传输模式设置的数据接收方式，接收业务数据；这样，通过消息模式和文件模式，以接收相关各个产品系统(即上游业务系统)提供的交易流水和分录(即业务数据)，从而产生相应的会计分录，并进行必要的分录汇总可以满足总账、管理会计及其他管理系统后续处理要求。

需要说明的是，业务数据无论是以消息传输模式进行传输，还是以文件传输模式进行传输，每行交易流水的动作信息部分和分录信息部分都会增加业务类型(即业务分类)、新业务类型(新业务分类)字段；并且，生成的控制文件中，接口版本号需要一致，若不一致，则需将其调整一致，示例性的，将接口版本号均调整为0x版本。

S202：若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果。

在一种可选的实现方式中，若各个记账明细满足以下条件，则可确定各个记账明细，均满足设定的账务平衡条件；其中，针对各个记账明细中的任意一个记账明细，即第一记账明细，执行以下操作：对第一记账明细进行解析，获得多个交易记录，从而当多个交易记录的交易轧差总和为0时，确定第一记账明细满足账务平衡条件；这样，在确定各个记账明细，均满足账务平衡条件时，便可确定业务数据满足初步正常分录的要求，以进行后续的数据校验。

同理，若各个记账明细中存在不满足设定的账户平衡条件的记账明细，则可确定业务数据不能进行正常分录，即属于异常分录数据。

需要说明的是，上述多个交易记录的交易轧差总和0可以表示同一法人(即同一业务发起方)，各种交易货币类型下的轧差为0。

在一种可选的实现方式中，服务器在确定各个记账明细，均满足设定的账务平衡条件时，便可基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验；其中，业务类型包括：第一业务类型和第二业务类型，第一业务类型表征业务类型为平衡段，第二业务类型表征业务类型不为平衡段。

需要说明的是，业务类型可通过布尔(bool)型变量标记，例如，第一业务类型的对应的bool数值为0，第二业务类型的对应的bool数值为1。

故而，服务器针对各个记账明细中的任意一个记账明细，即第二记账明细，存在如下两种校验情况：

情形1：参阅图4所示，若第二记账明细的业务类型为第一业务类型，则服务器可针对第二记账明细，执行以下操作：

S401：对第二记账明细进行区域机构联合维度的待清算科目核查，获得第一核查结果。

其中，第一核查结果为第二记账明细中，不存在区域机构联合维度下的待清算科目，或者，第二记账明细中，存在区域机构联合维度下的待清算科目。

示例性的，在执行步骤S401时，假定区域对应一类待清算科目、机构对应二类待清算科目，则服务器对第二记账明细进行区域机构联合维度的待清算科目核查，也即核查第二记账明细中是否有一类待清算科目和二类待清算科目。

S402：基于第一核查结果和区域机构联合维度下的交易轧差总和，对第二记账明细进行校验。

具体的，在执行步骤S402时，服务器在获得第一核查结果之后，便可根据第一核查结果、区域机构联合维度下的交易轧差总和，以及预设的第一交易轧差总和阈值，对第二记账明细进行校验。

需要说明的是，无论第一核查结果表征第二记账明细中，是否存在区域机构联合维度下的待清算科目，都需要将区域机构联合维度下的交易轧差总和，与预设的第一交易轧差总和阈值进行比较判别。

示例性的，假定预设的第一交易轧差总和阈值为0，故而，上述区域机构联合维度下的交易轧差总和，与预设的第一交易轧差总和阈值进行比较判别为：区域机构联合维度下的交易轧差总和是否为预设的第一交易轧差总和阈值0。

在一种可选的实现方式中，服务器在基于第一核查结果和区域机构联合维度下的交易轧差总和，对第二记账明细进行校验的过程中，若第一核查结果表征第二记账明细中，不存在区域机构联合维度下的待清算科目，且区域机构联合维度下的交易轧差总和不为0，则对第二记账明细进行轧差汇总清算(也即多维轧差清算)，直至区域机构联合维度下的交易轧差总和为0。

基于上述方式，可以确保当第一核查结果表征第二记账明细中，不存在区域机构联合维度下的待清算科目时，无论区域机构联合维度下的交易轧差总和是否为0，都可将第二记账明细判定为正常分录数据，以后续生成会计分录。

情形2：参阅图5所示，若第二记账明细的业务类型为第二业务类型，则服务器可针对第二记账明细，执行以下操作：

S501：对第二记账明细进行区域、机构以及业务类型联合维度的待清算科目核查，获得第二核查结果。

其中，第二核查结果为第二记账明细中，不存在区域、机构以及业务类型联合维度下的待清算科目，或者，第二记账明细中，存在区域、机构以及业务类型联合维度下的待清算科目。

示例性的，在执行步骤S501时，假定区域对应一类待清算科目、机构对应二类待清算科目，以及业务类型对应三类待清算科目，则服务器对第二记账明细进行区域、机构以及业务类型联合维度的待清算科目核查，也即核查第二记账明细中是否有一类待清算科目、二类待清算科目以及三类待清算科目。

S502：基于第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，对第二记账明细进行校验。

具体的，在执行步骤S502时，服务器在获得第二核查结果之后，便可根据第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，以及预设的第二交易轧差总和阈值，对第二记账明细进行校验。

需要说明的是，无论第二核查结果表征第二记账明细中，是否存在区域、机构以及业务类型联合维度下的待清算科目，都需要将区域、机构以及业务类型联合维度下的交易轧差总和，与预设的第二交易轧差总和阈值进行比较判别。

值得指出的是，上述预设的第二交易轧差总和阈值与上述预设的第一交易轧差总和阈值并没有明确的大小关系，即两者可以相同，也可以不同。

示例性的，假定预设的第二交易轧差总和阈值也为0，故而，上述区域、机构以及业务类型联合维度下的交易轧差总和，与预设的第一交易轧差总和阈值进行比较判别为：区域、机构以及业务类型联合维度下的交易轧差总和是否为预设的第二交易轧差总和阈值0。

在一种可选的实现方式中，服务器在基于第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，对第二记账明细进行校验的过程中，若第二核查结果表征第二记账明细中，不存在区域、机构以及业务类型联合维度下的待清算科目，且区域、机构以及业务类型联合维度下的交易轧差总和不为0，则对第二记账明细进行轧差汇总清算(也即多维轧差清算)，直至区域、机构以及业务类型联合维度下的交易轧差总和为0。

基于上述方式，可以确保当第二核查结果表征第二记账明细中，不存在区域、机构以及业务类型联合维度下的待清算科目时，无论区域、机构以及业务类型联合维度下的交易轧差总和是否为0，都可将第二记账明细判定为正常分录数据，以后续生成会计分录。

基于上述S201～S202的方法步骤，参阅图6所示，服务器实现了如下的记账明细的批处理：

S601：开始。

也即启动明细分录(会计分录)生成批处理的流程。

S602：法人和币种轧差是否为0，若否，则转入步骤S603；若是，则转入步骤S604。

需要说明的是，上述法人和币种轧差为0的判断，也即判断同一法人所涉及的各自币种的交易记录的轧差是否为0。

S603：异常分录。

需要说明的是，当确定记账明细属于异常分录数据时，可以生成警示信息上报，以便后续对记账明细进行问题追溯，即异常分录的溯源。

S604：业务类型是否为平衡段，若否，则转入步骤S605；若是，则转入步骤S610。

需要说明的是，业务类型是否为平衡段，是针对不同的业务类型预先设置的，故而，服务器在判断业务类型是否为平衡段时，直接根据对应当前业务类型设置的相关标识信息，便可确定是否为平衡段。

S605：是否有一类和二类待清算科目，若是，则转入步骤S606a；若否，则转入步骤S606b。

S606a：区域、机构轧差是否为0，若是，则转入步骤S607；若否，则转入步骤S608。

其中，区域、机构轧差为0也即区域机构联合维度下的交易轧差总和为0。

S607：正常分录。

也即判定记账明细属于可被正常分录的数据。

S608：异常分录。

也即判定记账明细属于异常分录的数据。

S606b：区域、机构轧差是否为0，若是，则转入步骤S607，若否，则转入步骤S609。

S609：多维轧差清算，直至在区域、机构轧差为0时，转入步骤S605。

可选的，在执行步骤S609时，服务器可通过会计引擎，以“全局流水跟踪号+子交易序号”为维度，对记账明细(也即整套明细分录)按相同平衡段(区域+机构+业务类型)进行借贷方发生额汇总轧差处理，即相同平衡段汇总借方发生额减汇总贷方发生额；其中，“业务类型”按前两位1级分类进行汇总轧差；需要说明的是，若轧差结果为正数，则轧差发生额为借方发生；若轧差结果为负数，则轧差发生额取绝对值，为贷方发生。

S610：是否有一类、二类和三类待清算科目，若是，则转入步骤S611a；若否，则转入步骤S611b。

示例性的，在执行步骤S610时，服务器可以通过会计引擎，按引擎变式设置“一类待清算科目/二类待清算科目/三类待清算科目”，用于后续生成跨平衡段的清算分录。

S611a：区域、机构、业务类型轧差是否为0，若是，则转入步骤S607；若否，则转入步骤S608。

S611b：区域、机构、业务类型轧差是否为0，若是，则转入步骤S607；若否，则转入步骤S612。

S612：多维轧差清算，直至在区域、机构、业务类型轧差是否为0时，转入步骤S610。

基于上述S601～S612的明细分录生成批处理方法步骤，服务器不仅实现了对记账明细是否属于正常分录数据的校验，还采用了零级清算模式，即清算时所有机构均为同一层级关系，例如，总行、分行、事业部总部、事业部分均为同级清算关系，跨平衡段清算分录均生成在原记账机构；这样，一定程度上避免了相关技术中，多级清算模式不利于异常分录溯源的问题。

示例性的，在同业银行目前通过机构间对开清算头寸账户的方式进行账务清算，账户体现实际资金头寸的场景中，多级清算模式主要分为两种：

1、不同分行上下逐级对开清算户

总分行间为两级清算结构；一级分行与二级分行间为两级清算结构；总行、事业部总部以及事业部分部采取三级清算结构，形成总行-事业部总部-事业部分部的系统内资金三级管理体系。

2、同一分行同层级对开清算户

事业分部于所在分行开立清算头寸账户，用于分行汇总缴税、与分行贷款划转等业务的机构间清算。

S203：当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录。

需要说明的是，参阅图7所示，若上述校验结果为以下任意一种，则表征各个记账明细中，存在满足预设正常分录条件的目标记账明细：区域机构联合维度下的交易轧差总和为0，或者，区域、机构以及业务类型联合维度下的交易轧差总和为0，也即上述预设正常分录条件为：相应记账明细对应的区域机构联合维度下的交易轧差总和为0，或者，相应记账明细对应的区域、机构以及业务类型联合维度下的交易轧差总和为0。

故而，基于上述方式对校验结果进行判别分析，并且，当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，服务器便可针对目标记账明细生成会计分录。

可选的，参阅图8所示，服务器基于目标记账明细，获得跨区域的第一交易记录子集和非跨区域的第二交易记录子集，并针对第一交易记录子集，生成跨区域的会计分录；接着，基于第二交易记录子集，获得跨机构的第三交易记录子集和非跨机构的第四交易记录子集，并针对第三交易记录子集，生成跨机构的会计分录；最终，基于第四交易记录子集，获得跨业务类型的第五交易记录子集和非跨业务类型的第六交易记录子集，并针对第五交易记录子集和第六交易子集，生成跨业务类型的会计分录和非跨业务类型的会计分录。

需要说明的是，服务器可根据“业务类型平衡段标志”，判断是否生成跨业务类型清算分录，其中，“业务类型”在核算时仅保留前两位分类，并按照第一级分类进行平衡；需要说明的是，业务类型通常一共包括8位。

示例性的，服务器可通过交易组件，在目标记账明细中上送正确平衡段段值，并根据不同的跨平衡段，由会计引擎负责生成跨平衡段清算分录，参阅图9所示，具体流程如下：

S901：开始。

也即启动跨平衡段清算分录的流程。

S902：跨区域，若是，则转入步骤S903；若否，则转入步骤S904。

S903：生成跨区域清算分录。

其中，上述跨区域清算分录也即跨区域的会计分录。

S904：跨机构，若是，则转入步骤S905；若否，则转入步骤S906。

S905：生成跨机构清算分录。

其中，上述跨机构清算分录也即跨机构的会计分录。

S906：跨业务类型，若是，则转入步骤S907；若否，则转入步骤S908。

可选的，在执行步骤S906时，服务器可根据业务类型平衡段标识判断，是否存在跨业务类型；并且，在不存在跨业务类型，转入步骤S908的过程中，可由会计引擎生成非跨业务类型清算分录，也即非跨业务类型的会计分录。

S907：生成跨业务类型清算分录。

其中，上述跨业务类型清算分录也即跨业务类型的会计分录。

S908：结束。

需要说明的是，服务器通过会计引擎，生成明细分录(即会计分录)时，明细分录(会计分录)的“业务类型”与原交易流水8位“业务类型”相同。

显然，采用这种方式，服务器可以通过会计引擎，在发生跨平衡段(区域、机构、业务类型)业务场景时，生成跨平衡段清算分录，即各类跨平衡段的会计分录，具体为：按平衡段汇总轧差后分录按“区域→机构→业务分类”的顺序判断跨平衡段场景。跨区域场景生成“一类待清算科目”清算分录(即跨区域清算分录)；跨机构场景生成“二类待清算科目”清算分录(即跨机构清算分录)；“业务类型平衡段标志”为是，且跨业务类型场景生成“三类待清算科目”清算分录(即跨业务类型清算分录)；需要说明的是，清算分录平衡段取值均与汇总轧差后分录相同。

进一步地，在一种可选的实现方式中，服务器在针对目标记账明细生成会计分录之后，还可以针对获得的多个会计分录中的任意一个会计分录，即第一会计分录，执行以下跨系统往来科目检查操作：若第一会计分录中的交易轧差总和不为0，则确定第一会计分录为异常会计分录；若第一会计分录中的交易轧差总和为0，且第一会计分录对应的业务类型为第一业务类型，则在区域、机构以及系统科目联合维度下的交易轧差总和不为0，则确定第一会计分录为异常会计分录；若第一会计分录中的交易轧差总和为0，且第一会计分录对应的业务类型为第二业务类型，则在区域、机构、业务类型以及系统科目联合维度下的交易轧差总和不为0，则确定第一会计分录为异常会计分录；这样，实现了对跨系统往来检查的批处理。

示例性的，基于上述方法步骤，参阅图10所示，服务器实现了如下的跨系统往来检查的批处理：

S1001：开始。

也即启动跨系统往来检查的批处理的流程。

S1002：法人和币种轧差是否为0，若是，则转入步骤S1003；若否，则转入步骤S1006。

S1003：业务类型是否为平衡段，若否，则转入步骤S1004；若是，则转入步骤S1005。

S1004：区域、机构、跨系统科目轧差是否为0，若否，则转入步骤S1006。

S1005：区域、机构、业务类型、跨系统科目轧差是否为0，若否，则转入步骤S1006。

S1006：组件往来异常明细分录。

需要说明的是，上述组件往来异常明细分录，也即跨系统往来检查结果异常，示例性的，以第一会计分录为例，组件往来异常明细分录也即表征：第一会计分录为异常会计分录。

显然，基于上述步骤S1001～S1006记载的跨系统往来检查的批处理方法，服务器可以针对生成的多个会计分录进行跨系统是否异常的会计分录检查。

此外，在本申请实施例中，服务器还可提供单边账的交易组件生成跨系统清算分录，即当发生跨系统交易(即存在跨系统场景)时，交易组件有记单边账的业务场景，则需生成跨系统清算分录。

还需说明的是，基于上述S601～S612、S901～S908以及S1001～S1006的方法步骤，服务器可以按照统一的、独立的会计核算规则，并通过批量方式，对分录进行平衡检查和对账，支持自动生成必要的会计分录，以保证引擎处理的可靠性和一致性。

综上所述，在本申请实施例所提供的会计分录生成方法中，接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细，若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果，从而当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录；采用这种方式，通过设定的账务平衡条件，对各个记账明细进行初步校验，并在初步校验成功后，对基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，这样，确保用于会计分录生成的数据能够满足正常分录的要求，从而提高生成的会计分录作为后续业务分析数据的有效性。

进一步地，基于相同的技术构思，本申请实施例提供了一种会计分录生成装置，该会计分录生成装置用以实现本申请实施例的上述方法流程。参阅图11所示，该会计分录生成装置包括：接收模块1101、校验模块1102以及生成模块1103，其中：

接收模块1101，用于接收上游业务系统提供的业务数据，并获取业务数据中的各个记账明细；其中，每个记账明细表征：相应业务发起方与多个业务接收方之间的账务交易信息，账务交易信息包括：至少一种交易货币类型；

校验模块1102，用于若各个记账明细，均满足设定的账务平衡条件，则基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验，获得校验结果；

生成模块1103，用于当校验结果表征各个记账明细中，存在满足预设正常分录条件的目标记账明细时，针对目标记账明细生成会计分录。

在一种可选的实施例中，在接收上游业务系统提供的业务数据时，所述接收模块1101具体用于：

接收上游业务系统发送的数据接收请求，并从数据接收请求中，确定业务数据的数据传输模式；

若数据传输模式为消息传输模式，则按照对应消息传输模式设置的数据接收方式，接收业务数据；

若数据传输模式为文件传输模式，则按照对应文件传输模式设置的数据接收方式，接收业务数据。

在一种可选的实施例中，若满足以下条件，则确定各个记账明细，均满足设定的账务平衡条件：

针对所述各个记账明细，分别执行以下操作：

对第一记账明细进行解析，获得多个交易记录；其中，第一记账明细为各个记账明细中的任意一个记账明细；

当多个交易记录的交易轧差总和为0时，确定第一记账明细满足账务平衡条件。

在一种可选的实施例中，在基于各个记账明细各自对应的业务类型，分别对各个记账明细进行校验时，所述校验模块1103具体用于：

针对各个记账明细，分别执行以下操作：

若第二记账明细的业务类型为第一业务类型，则对第二记账明细进行区域机构联合维度的待清算科目核查，获得第一核查结果；其中，第二记账明细为各个记账明细中的任意一个记账明细；

基于第一核查结果和区域机构联合维度下的交易轧差总和，对第二记账明细进行校验；

若第二记账明细的业务类型为第二业务类型，则对第二记账明细进行区域、机构以及业务类型联合维度的待清算科目核查，获得第二核查结果；

基于第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，对第二记账明细进行校验。

在一种可选的实施例中，在基于第一核查结果和区域机构联合维度下的交易轧差总和，对第二记账明细进行校验的过程中，所述校验模块1102还用于：

若第一核查结果表征第二记账明细中，不存在区域机构联合维度下的待清算科目，且区域机构联合维度下的交易轧差总和不为0，则对第二记账明细进行轧差汇总清算，直至区域机构联合维度下的交易轧差总和为0。

在一种可选的实施例中，在基于第二核查结果和区域、机构以及业务类型联合维度下的交易轧差总和，对第二记账明细进行校验的过程中，所述校验模块1102还用于：

若第二核查结果表征第二记账明细中，不存在区域、机构以及业务类型联合维度下的待清算科目，且区域、机构以及业务类型联合维度下的交易轧差总和不为0，则对第二记账明细进行轧差汇总清算，直至区域、机构以及业务类型联合维度下的交易轧差总和为0。

在一种可选的实施例中，若校验结果为以下任意一种，则表征各个记账明细中，存在满足预设正常分录条件的目标记账明细：

区域机构联合维度下的交易轧差总和为0；

或者，

区域、机构以及业务类型联合维度下的交易轧差总和为0。

在一种可选的实施例中，在针对目标记账明细生成会计分录时，所述生成模块1103具体用于：

基于目标记账明细，获得跨区域的第一交易记录子集和非跨区域的第二交易记录子集，并针对第一交易记录子集，生成跨区域的会计分录；

基于第二交易记录子集，获得跨机构的第三交易记录子集和非跨机构的第四交易记录子集，并针对第三交易记录子集，生成跨机构的会计分录；

基于第四交易记录子集，获得跨业务类型的第五交易记录子集和非跨业务类型的第六交易记录子集，并针对第五交易记录子集和第六交易子集，生成跨业务类型的会计分录和非跨业务类型的会计分录。

在一种可选的实施例中，在针对目标记账明细生成会计分录之后，所述校验模块1102还用于：

针对获得的多个会计分录，分别执行以下跨系统往来科目检查操作：

若第一会计分录中的交易轧差总和不为0，则确定第一会计分录为异常会计分录；其中，第一会计分录为多个会计分录中的任意一个；

若第一会计分录中的交易轧差总和为0，且第一会计分录对应的业务类型为第一业务类型，则在区域、机构以及系统科目联合维度下的交易轧差总和不为0，则确定第一会计分录为异常会计分录；

若第一会计分录中的交易轧差总和为0，且第一会计分录对应的业务类型为第二业务类型，则在区域、机构、业务类型以及系统科目联合维度下的交易轧差总和不为0，则确定第一会计分录为异常会计分录。

基于相同的技术构思，本申请实施例还提供了一种电子设备，该电子设备可实现本申请上述实施例提供的会计分录生成方法流程。在一种实施例中，该电子设备可以是服务器，也可以是终端设备或其他电子设备。参图12所示，该电子设备可包括：

至少一个处理器1201，以及与至少一个处理器1201连接的存储器1202，本申请实施例中不限定处理器1201与存储器1202之间的具体连接介质，图12中是以处理器1201和存储器1202之间通过总线1200连接为例。总线1200在图12中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1200可以分为地址总线、数据总线、控制总线等，为便于表示，图12中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。或者，处理器1201也可以称为控制器，对于名称不做限制。

在本申请实施例中，存储器1202存储有可被至少一个处理器1201执行的指令，至少一个处理器1201通过执行存储器1202存储的指令，可以执行前文论述的一种会计分录生成方法。处理器1201可以实现图11所示的装置中各个模块的功能。

其中，处理器1201是该装置的控制中心，可以利用各种接口和线路连接整个该控制设备的各个部分，通过运行或执行存储在存储器1202内的指令以及调用存储在存储器1202内的数据，该装置的各种功能和处理数据，从而对该装置进行整体监控。

在一种可能的设计中，处理器1201可包括一个或多个处理单元，处理器1201可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1201中。在一些实施例中，处理器1201和存储器1202可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器1201可以是通用处理器，例如CPU、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的一种会计分录生成方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1202作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1202可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器1202是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器1202还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通过对处理器1201进行设计编程，可以将前述实施例中介绍的一种会计分录生成方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行图2所示的实施例的一种会计分录生成方法的步骤。如何对处理器1201进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

基于同一发明构思，本申请实施例还提供一种存储介质，该存储介质存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行前文论述的一种会计分录生成方法。

在一些可能的实施方式中，本申请还提供了一种会计分录生成方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在装置上运行时，程序代码用于使该控制设备执行本说明书上述描述的根据本申请各种示例性实施方式的一种会计分录生成方法中的步骤。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个服务器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

可使用一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算装置上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算装置上部分在远程计算装置上执行、或者完全在远程计算装置或服务器上执行。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。