财务数据处理方法、装置、存储介质及电子设备与流程

1.本公开涉及数据处理技术领域，具体而言，涉及一种财务数据处理方法、财务数据处理装置、计算机可读存储介质以及电子设备。


背景技术：

2.随着电子商务的发展，越来越多的交易订单以在线交易的形式进行，因此，对交互数据进行核对变得越来越重要。
3.例如，对于互联网小额巨量业务，为了节约系统资源，业务系统只记录来自业务终端的订单总额数据，业务系统在核对财务数据时也只能核对对应的财务总额数据。当核对出现差异时无法确认差异来源，导致财务数据的准确性较低。
4.因此，提供一种财务数据处理方法以提高财务数据的准确性是非常必要的。
5.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

6.本公开的目的在于提供一种财务数据处理方法、财务数据处理装置、计算机可读存储介质以及电子设备，以解决现有技术中由于核对财务数据只核对总额，导致核对出现差异时无法确认差异来源的问题。
7.根据本公开的第一方面，提供一种财务数据处理方法，包括：
8.创建数据核对任务，并生成对应的数据核对任务标识；
9.根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；
10.当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；
11.当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。
12.在本公开的一种示例性实施例中，所述创建数据核对任务，并生成对应的数据核对任务标识，包括：
13.接收待核对文件，并生成对应的数据核对任务标识；
14.将所述待核对文件拆分为多条待核对财务数据；
15.将所述多条待核对财务数据存储至所述数据核对任务表中，所述数据核对任务表对应多个数据核对任务标识；
16.将所述数据核对任务标识存储至所述待核对任务消息队列中；
17.发布所述待核对任务消息队列。
18.在本公开的一种示例性实施例中，所述根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据，包括：
19.通过订阅所述待核对任务消息队列获取所述数据核对任务标识；
20.根据所述数据核对任务标识查询所述数据核对任务表，获取待核对财务数据。
21.在本公开的一种示例性实施例中，所述方法还包括：
22.获取所述待核对财务数据后，对所述待核对财务数据进行基础校验，并将通过校验的所述待核对财务数据进行核对处理。
23.在本公开的一种示例性实施例中，所述根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对，包括：
24.根据预设的对账标识，将所述待核对财务数据中的明细数据与数据库中的第一表单数据中的表单明细数据进行核对；
25.将核对结果更新至所述数据核对任务表中。
26.在本公开的一种示例性实施例中，所述根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对，包括：
27.在预设时间周期内，将所述待核对财务数据中的核心数据汇总，生成待核对总核心数据；
28.将所述第一表单数据中的表单核心数据汇总，生成表单总核心数据；
29.将所述待核对总核心数据和表单总核心数据进行核对，得到核对结果。
30.在本公开的一种示例性实施例中，所述方法还包括：
31.根据所述数据核对任务的任务标识聚合核对结果一致的财务数据，并将聚合结果与数据库中的第二表单数据进行核对。
32.根据本公开的第二方面，提供一种财务数据处理装置，包括：
33.任务创建模块，用于创建数据核对任务，并生成对应的数据核对任务标识；
34.数据查询模块，用于根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；
35.第一数据核对模块，用于当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；
36.第二数据核对模块，用于当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。
37.根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述所述的财务数据处理方法。
38.根据本公开的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述所述的财务数据处理方法。
39.本公开示例性实施例可以具有以下部分或全部有益效果：
40.在本公开示例实施方式所提供的财务数据处理方法中，通过创建数据核对任务，并生成对应的数据核对任务标识；根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。一方面，该方法可以实现财务数据的明细核对和总额核对，当核对出现差异时，可以根据财务明细数据确认差异来源，从而提高财务数据的准确性。另一方
面，用户根据财务数据的核对结果可以生成唯一的财务数据明细清单，从而可以更加准确的进行风险控制。
41.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
42.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
43.图1示出了可以应用本公开实施例的一种财务数据处理方法及装置的示例性系统架构的示意图；
44.图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；
45.图3示意性示出了根据本公开的一个实施例的财务数据处理方法的流程图；
46.图4示意性示出了根据本公开的一个实施例的对账任务添加的流程图；
47.图5示意性示出了根据本公开的一个实施例的对账任务处理的流程图；
48.图6示意性示出了根据本公开的一个实施例的对账结果推送的流程图；
49.图7示意性示出了根据本公开的一个实施例的开票流程图；
50.图8示意性示出了根据本公开的一个实施例的财务数据处理装置的框图。
具体实施方式
51.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
52.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
53.图1示出了可以应用本公开实施例的一种财务数据处理方法及装置的示例性应用环境的系统架构的示意图。
54.如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设
备101、102、103可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等等。应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。
55.本公开实施例所提供的财务数据处理方法一般由服务器105执行，相应地，财务数据处理装置一般设置于服务器105中。但本领域技术人员容易理解的是，本公开实施例所提供的财务数据处理方法也可以由终端设备101、102、103执行，相应的，财务数据处理装置也可以设置于终端设备101、102、103中，本示例性实施例中对此不做特殊限定。
56.图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。
57.需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
58.如图2所示，计算机系统200包括中央处理单元(cpu)201，其可以根据存储在只读存储器(rom)202中的程序或者从存储部分208加载到随机访问存储器(ram)203中的程序而执行各种适当的动作和处理。在ram 203中，还存储有系统操作所需的各种程序和数据。cpu 201、rom 202以及ram 203通过总线204彼此相连。输入/输出(i/o)接口205也连接至总线204。
59.以下部件连接至i/o接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至i/o接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。
60.特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元(cpu)201执行时，执行本技术的方法和装置中限定的各种功能。
61.作为另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图3至图7所示的各个步骤等。
62.需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、
或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
63.以下对本公开实施例的技术方案进行详细阐述：
64.随着电子商务的发展，越来越多的交易订单以在线交易的形式进行。以互联网业务承保为例，通过互联网商城购买保险商品后，会在第三方平台业务系统侧生成与商城订单对应的投保订单。对于这种互联网批量的小额巨量业务，为了节约系统资源，承保的时候投保订单不记录明细订单数据，只记录投保订单的总保费、总保额。
65.这种业务承保方法使得互联网商城的明细订单数据与第三方平台业务系统侧的投保订单数据分离，由于未建立二者之间的关联关系，会导致保费收付核对的匹配关系缺失，进而出现财务数据核对不清楚的问题。
66.基于上述一个或多个问题，本示例实施方式提供了一种财务数据处理方法，该方法可以应用于上述服务器105，也可以应用于上述终端设备101、102、103中的一个或多个，本示例性实施例中对此不做特殊限定。参考图3所示，该财务数据处理方法可以包括以下步骤s310至步骤s340：
67.步骤s310.创建数据核对任务，并生成对应的数据核对任务标识；
68.步骤s320.根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；
69.步骤s330.当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；
70.步骤s340.当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。
71.在本公开示例实施方式所提供的财务数据处理方法中，通过创建数据核对任务，并生成对应的数据核对任务标识；根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。一方面，该方法可以实现财务数据的明细核对和总额核对，当核对出现差异时，可以根据财务明细数据确认差异来源，从而提高财务数据的准确性。另一方面，用户根据财务数据的核对结果可以生成唯一的财务数据明细清单，从而可以更加准确的进行风险控制。
72.下面，对于本示例实施方式的上述步骤进行更加详细的说明。
73.本示例实施方式中，对于互联网业务承保服务，用户在通过互联网业务终端购买
保险商品后，会在第三方平台业务系统侧生成与业务终端订单对应的投保订单。承保服务完成后，可以将投保订单进行分层设计，引入第一表单和第二表单的概念，用第一表单记录投保明细信息，并按照一定的聚合规则，定期把符合聚合规则的第一表单进行聚合并关联到一个第二表单上，例如，可以用第一表单记录每个投保订单的保费，用第二表单记录多个第一表单聚合后的总保费。另外，可以将第一表单数据和第二表单数据存储在业务系统的数据库中。
74.当第三方平台业务系统侧有财务数据核对的需求时，可以将业务终端发送的财务数据和业务系统内存储的第一表单数据进行核对。其中，业务系统中的财务数据核对业务可以由多个任务服务器来执行。
75.在步骤s310中，创建数据核对任务，并生成对应的数据核对任务标识。
76.用户在进行财务数据核对时，可以通过第一任务服务器选取对应的业务类型，也就是在业务系统页面选取“数据核对业务”。其中，数据核对业务包含的数据核对类型可以是时间维度核对，例如，可以将一定周期内的财务数据进行核对，对应的可以是天核对方式、周核对方式等。数据核对类型也可以是明细维度核对，即明细核对方式，本示例实施方式中对此不做具体限定。
77.用户可以根据提前确认的数据核对类型，从业务终端搜集待核对财务数据，并将多条待核对财务数据作为待核对文件上传至第一任务服务器。其中，业务终端可以是第三方平台如保险公司各销售点的销售业务终端，也可以是用户网上自助购买保险服务所使用的计算机设备、智能移动设备等，也可以是其他可以进行保险服务销售、交易、承保等活动的业务终端。
78.可以理解的是，对应于不同的数据核对类型，待核对文件的数据核对模板也是不同的。例如，数据核对类型以天维度进行核对时，待核对文件中包含的待核对财务数据可以是时间和待核对金额，示例性的，可以是订单对应的保险起期的具体时间(如2020
‑
01
‑
01 00:00:00)和保费金额(如1000元)。数据核对类型以明细维度进行核对时，待核对文件中包含的待核对财务数据可以是核对标识、待核对金额和保单标识等数据，示例性的，可以是对账主键、保费金额和保单号等。其中，对账主键中可以由商品订单号和订单时间等数据组成，由于不同订单的唯一标识不同，业务终端和第三方平台业务系统可以同时约定对账主键，并根据对账主键核对双方记录的保费金额是否一致。
79.第一任务服务器接收该待核对文件时，可以生成对应的数据核对任务标识，如生成对应的数据核对任务id(identity，标识符)，示例性的，数据核对任务id可以是hd20210101001。其中，该待核对文件中可以包含多条待核对财务数据，如可以包含10万条待核对财务数据，应该理解，待核对财务数据的数目仅仅是示意性的。当待核对文件中的数据量较大时，可以先将该待核对文件进行拆分，得到多条待核对财务数据。同时，可以将拆分得到的多条待核对财务数据存储至数据核对任务表中。其中，数据核对任务表用来记录待核对的任务，可以包含各个数据核对任务的批次信息以及对应的执行状态等信息。数据核对任务表中可以存储多个批次的待核对财务数据，因此，数据核对任务表可以对应多个数据核对任务标识。
80.然后，可以将多个数据核对任务标识写入待核对任务消息队列中，并向第二任务服务器发布待核对任务消息队列，便于将数据核对任务标识依次发送至第二任务服务器以
进行后续的财务数据核对处理。其中，待核对任务消息队列(mq)可以是active mq，rabbit mq，kafka，rocket mq等多种类型的消息队列。
81.一种示例实施方式中，第三方平台将承保业务对应的财务数据进行对账时，可以在后管系统中添加对账任务。参考图4所示，对账任务添加的过程可以包括以下步骤s401至步骤s405：
82.步骤s401.用户在后管系统页面中选择对账业务和选择对账类型；
83.步骤s402.确定对账类型后，按照对应的对账模板上传待对账文件；
84.步骤s403.确定该待对账文件是否成功上传至后管系统。当待对账文件上传成功时，执行步骤s404，否则，执行步骤s405；
85.步骤s404.创建对账任务：接收待对账文件并进行拆分，得到来自业务终端的多条待对账数据，并根据多条待对账数据创建对账任务，也就是将多条待对账数据写入对账任务表中。另外，还可以按照明细订单维度创建对账任务消息队列，对账任务消息队列中可以包含对账任务号，且每个待对账文件对应于一个对账任务号。
86.步骤s405.进行报错提示：当该待核对文件上传失败时，可以向后管系统报错，并在系统页面进行提示。
87.本示例中按照明细维度上传待对账文件时，可以将用户提供的明细数据与后管系统中的保单明细数据进行对账，以实现业务终端侧数据和业务系统侧数据之间的一一核对，进而提高对账的准确性。
88.在步骤s320中，根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据。
89.第二任务服务器可以订阅待核对任务消息队列，以从待核对任务消息队列中读取数据核对任务标识，例如，可以采用mq消息处理服务器从待核对任务消息队列中拉取数据核对任务标识。其中，待核对任务消息队列可以是kafka消息队列，kafka的分布式消息队列比较适合简单的消息传递和分发，可以支持大数据量。可选的，第一任务服务器和第二任务服务器之间也可以采用进程间通信的方式传输数据核对任务标识。例如，进程间通信的方式可以发送http(hypertext transfer protocol，超文本传输协议)请求，也可以发送rpc(remote procedure call，远程过程调用)请求。
90.获取数据核对任务标识后，可以根据该数据核对任务标识查询数据核对任务表，以获取存储在数据核对任务表中的待核对财务数据。示例性的，第二任务服务器可以向第一任务服务器发送查询请求，如可以发送http请求，也可以发送tcp(transmission control protocol，传输控制协议)请求，对应的，可以通过websocket通信协议发送该查询请求，websocket是一种在单个tcp连接上进行全双工通信的协议，使得客户端和服务器之间的数据交换变得更加简单，并且，允许服务端主动向客户端推送数据。该查询请求中可以包含数据核对任务标识，以使第一任务服务器向第二任务服务器返回对应的待核对财务数据。
91.一种示例实施方式中，获取待核对财务数据后，第二任务服务器可以对待核对财务数据进行基础校验，并将通过校验的待核对财务数据进行核对处理。具体的，可以将对待核对财务数据进行基础校验，以将业务终端上传的待核对财务数据按数据库格式解析至数据库中，如不满足数据库格式及必录项的数据(即存入数据无法进行数据核对操作)会被筛
选出来。例如，待核对财务数据中的对账主键、订单号等字段中包含其他格式的字符如特殊字符时，说明待核对财务数据校验失败，也即无法解析至数据库。
92.当待核对财务数据解析失败时，可以组装该待核对财务数据未通过校验的信息，并将该信息返回至第一任务服务器，结束该待核对财务数据后续的对账服务，并在第一任务服务器的系统页面更新数据核对任务状态和校验失败的原因。其中，第二任务服务器可以根据具体的业务需求，将该信息及时地返回给第一任务服务器，也可以在多处理线程批量处理完成对账任务后，批量将该信息返回给第一任务服务器。
93.当待核对财务数据解析成功时，可以将业务终端和第三方平台业务系统针对不同商品约定的对账主键，以及商品对应的待核对金额等存储到待核对消息队列中，待核对消息队列也可以是active mq，rabbit mq，kafka，rocket mq等多种类型的消息队列。然后，可以根据不同商品的对账主键逐条发送mq进行财务数据的核对。监听待核对消息队列，当待核对消息队列中写入新的待核对财务数据时，从消息队列中获取最新写入的待核对财务数据。示例性的，可以采用集群方式获取待核对财务数据，如采用多个mq消息处理服务器进行批量拉取，以避免单点服务，在业务系统高峰时，可以动态扩容。同时如果某一个节点不可用，不会影响整体的财务数据处理。
94.在步骤s330中，当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对。
95.一种示例实施方式中，可以统计数据核对任务表中包含的待核对财务数据的总数据量，根据待核对财务数据的总数据量确定对应的数据核对类型。例如，可以预设一个数据量阈值如10万，当数据核对任务表中包含的待核对财务数据得总量小于10万条时，第二任务服务器可以按明细维度将通过校验的待核对财务数据与第一表单数据中的明细数据进行核对处理，得到核对结果。
96.示例性的，业务系统可以将承保服务生成的第一表单数据写入第一表单对账明细表中，例如，可以将第一表单数据中的对账主键、保额和保费等明细数据写入第一表单对账明细表中，便于将用户提供的数据与第一表单对账明细表进行对比，以区分出业务终端有业务系统无和业务终端无业务系统有的异常数据，并将异常数据记录到数据核对异常表中。当双方的对账主键、保费等数据均一致时，数据核对成功，记录核对结果。并根据核对结果更新数据核对任务表中的执行状态，为了通过数据核对任务表中的执行状态可以明确知道批次数据核对任务是否完成，每次执行待核对的批次数据核对任务后，可以将数据核对任务表中待核对的批次数据核对任务的执行状态进行更新。另外，第二任务服务器也可以向用户返回数据核对任务表。
97.在步骤s340中，当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。
98.又一种示例实施方式中，第一表单数据用来记录业务明细信息，例如，对于业务系统中的投保业务，第一表单数据可以包括但不限于对账主键、第一表单号、第一表单创建时间、出单状态(出单/未出单)、投/被保人的名称、证件类型、证件号码、保险起期、保险终期、保额、保费、产品名称和代码、商品名称等。其中，表单核心数据可以为保险起期、保额和保费等数据，对应的待核对财务数据的核心数据也可以为保险起期、保额和保费等数据。
99.当待核对财务数据的总数据量不小于预设的数据量阈值时，可以根据时间维度将
待核对财务数据中的核心数据与第一表单数据中的表单核心数据分别进行汇总，得到待核对总核心数据和表单总核心数据，将所述待核对总核心数据和表单总核心数据进行对账处理，得到对账处理结果。
100.用户按照业务提前确认的数据核对类型为时间维度时，示例性的，以天为时间周期时，可以按照保险起期当天汇总业务终端待核对财务数据中的保费，与数据库中第一表单数据中的当天总保费进行核对。当总保费一致时，记录核对结果，并根据核对结果更新数据核对任务表中的执行状态。当总保费不一致时，将核对失败的财务数据记录到数据核对异常表中，如记录失败批次，便于后续进行明细维度对账，以准确的查找对账差异的来源。
101.另外，可以通过调用预设的数据处理接口获取第二任务服务器返回的数据核对结果。可以理解的是，不同任务服务器之间关于数据核对的结果可以共享，也可以将数据核对结果输出到业务系统页面，以便于用户下载查看。
102.一种示例实施方式中，第三方平台业务系统可以包括后管系统和批改(对账)服务系统，其中，数据库中可以用第一表单记录投保明细信息，并按照一定的聚合规则，定期把符合聚合规则的第一表单进行聚合并关联到一个第二表单上，例如，可以用小保单记录每个投保订单的保费，用大保单记录多个第一表单聚合后的总保费。图5示出了一种对账任务处理的流程图，该过程可以包括以下步骤s501至步骤s520：
103.步骤s501.批改服务系统订阅对账任务mq，以获取对账任务号。根据对账任务号查询对账任务表，获取对账文件；
104.步骤s502.文件解析和基础校验：将对账文件进行解析和校验，如进行数据格式的基础校验，以将业务终端上传的对账文件中的数据按数据库格式解析至数据库中。校验通过时，执行步骤s503，校验未通过时，执行步骤s504；
105.步骤s503.根据业务终端和第三方平台约定的不同产品的对账主键发送mq，进行逐条对账；
106.步骤s504.将校验失败的信息返回至后管系统，更新后管系统页面的对账任务状态和失败原因，并记录异常，结束对账任务流程；
107.步骤s505.监听对账任务mq；
108.步骤s505.确定对账维度，对账维度为天维度时，执行步骤s507，对账维度为明细维度时，执行步骤s511；
109.步骤s507.汇总对账日所有待对账明细订单保费；
110.步骤s508.判断是否与系统中对账日小保单总保费一致，总保费一致时，执行步骤s509，总保费不一致时，执行步骤s510；
111.步骤s509.记录对账结果；
112.步骤s510.执行失败批次，继续进行明细对账；
113.步骤s511.将明细待对账数据与系统中小保单唯一标识进行对比，如将明细待对账数据中的对账主键与系统中小保单对应的对账主键进行对比；
114.步骤s512.对账主键一致时，获取渠道侧(业务终端)和业务系统对账匹配的数据，并执行步骤s514；
115.步骤s513.对账主键不一致时，获取渠道侧有，业务系统无和渠道测无，业务系统有的数据，并执行步骤s515；
116.步骤s514.判断同一主键对应的渠道测的保费和业务系统侧的保费是否一致，保费不一致时，执行步骤s515，保费一致时，执行步骤s516；
117.步骤s515.保存保费不一致的财务数据；
118.步骤s516.保存保费匹配一致的财务数据；
119.步骤s517.按照大保单聚合规则，定期把保费一致的财务数据进行聚合，生成财务核销账单以及财务核销账单号，保存保费一致的财务数据，以便于后续将财务核销账单和系统中大保单进行财务结算；
120.步骤s518.更新对账任务状态，发布对账任务结果文件mq消息，mq消息中包含对账任务号、对账状态等信息；
121.步骤s519.接收对账结果文件mq消息，根据对账任务号、对账状态校验对账任务是否均完成对账；
122.步骤s520.上传对账结果，更新对账任务表；
123.本示例中第三方平台业务系统基于接收的业务订单数据生成了小保单，小保单用来记录投保明细信息，基于小保单进一步生成大保单，大保单用来记录投保总保费，可以将业务订单数据和大保单建立关联关系，从而提高数据准确性。而且，突破了现有的小额巨量业务在进行财务对账时只能核对总金额的限制，通过核对财务明细数据，使得保费的财务处理可以具体到每一张明细投保订单，从而提高了财务数据的准确性。
124.一种示例实施方式中，根据明细维度核对财务数据时，可以根据数据核对任务的任务标识聚合核对结果一致的财务数据，并将聚合结果与数据库中的第二表单数据进行核对。具体的，可以将满足预设的聚合规则的财务数据进行聚合，如可以聚合数据核对任务号对应的核对结果一致的所有财务数据，也可以基于核对结果一致的所有财务数据通过取余数进行分组，根据取余分组号聚合对应分组中的待核对金额。
125.当用户结算财务数据时，可以通过第一任务服务器将财务数据核对结果推送至第二任务服务器，第二任务服务器可以按照数据核对任务号查询数据库中存储的第二表单聚合表，获取对应的第二表单号。接着，第二任务服务器调用第三任务服务器接口同步财务数据核对结果和第二表单号。第三任务服务器接收到财务数据核对结果和第二表单号后，将第二表单号中相应的待核对金额做财务结算，并向第二任务服务器返回数据结算成功状态，也可以向用户返回对账结果以便于用户查看。
126.示例性的，第三方平台业务系统可以包括业管平台的后管系统、批改(对账)服务系统和新核心收付系统。对账完成后，用户在业务系统页面选择是否将对账结果推送至收付系统进行实收入账。参考图6所示，示出了一种将对账结果推送至收付系统的流程图，该过程可以包括以下步骤s601至步骤s610：
127.步骤s601.用户在后管系统页面点击“推送收付”选项，以发出推送收付申请；
128.步骤s602.判断该收付申请是否可推送，通过确定该对账任务是否完成对账，或该对账任务的对账结果是否已完成推送。当该收付申请不可推送时，执行步骤s603，当该收付申请可以推送时，执行步骤s604；
129.步骤s603.进行相关提示：在后管系统页面提示“推送失败”，结束对账结果推送流程；
130.步骤s604.生成推送收付mq消息，并向批改服务系统发布推送收付mq消息，mq消息
中包括对账结果和对应的对账任务号等信息；
131.步骤s605.根据对账任务号查询对应明细：批改服务系统接收推送收付mq消息，获取对账结果和对应的对账任务号，并根据对账任务号查询大保单聚合表中对应明细的大保单号；
132.步骤s606.推送收付系统：调用收付接口同步对账结果、对账任务号等数据到新核心收付系统；
133.步骤s607.新核心收付系统处理将对账结果与对应金额的大保单进行财务结算；
134.步骤s608.判断处理结果，结算成功时，执行步骤s609，结算失败时，执行步骤s610；
135.步骤s609.接收收付系统返回结算成功的提示信息，更新对账成功的大保单推送收付状态，更新对账任务状态，流程结束；
136.步骤s610.更新失败原因，流程结束。
137.本示例中，通过大保单和小保单的数据分层，用小保单记录明细的保费，用大保单记录总保费。财务对账了多少明细就将相应总额的大保单保费做财务结算，既实现了明细订单的对账，又实现了总支付保费的核销，也进一步提高了财务数据的准确性，
138.财务数据核对完成后，用户可以继续将核对结果生成财务数据明细清单。一种示例实施方式中，图7示出了一种用户根据对账结果进行开票的流程图，该过程可以包括以下步骤s701至步骤s708：
139.步骤s701.获取待开票明细：根据业务类型，用户可以选择根据对账结果开票，即从对账成功的财务数据中获取待开票明细信息，用户也可以选择从统页面上传待开票明细。例如，用户可以在对账完成后的批改系统页面中点击“开票”跳转开票页面，也可以在后管系统页面手动上传待开票文件；
140.步骤s702.填写开票信息：用户在后管系统页面填写具体订单需要的开票信息，具体的，可以填写开票要素信息，如纳税人识别号，发票代码、发票号码、发票类型、开票日期，开票金额、电话号码等信息；
141.步骤s703.系统接收开票申请，调用开票系统服务，并创建开票任务；
142.步骤s704.根据对账任务查询对账成功核心大保单，组织开票信息；
143.步骤s705.写入开票推送大保单聚合表，生成开票mq消息，同步收付；
144.步骤s706.新核心收付系统接收待开票mq信息，进行开票处理；
145.步骤s707.开票完成后，调用服务回调接口同步开票结果至批改服务系统；
146.步骤s708.批改服务系统更新开票任务状态，并在系统页面刷新开票结果，开票流程结束。
147.本示例中用户根据财务数据的核对结果可以生成唯一的财务数据明细清单，避免由于开票无法匹配具体订单，同一订单出现重复开票的问题，从而可以更加准确的进行风险控制。
148.在本公开示例实施方式所提供的财务数据处理方法中，通过创建数据核对任务，并生成对应的数据核对任务标识；根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；当所述待核对财务数据的总属
性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。一方面，该方法可以实现财务数据的明细核对和总额核对，当核对出现差异时，可以根据财务明细数据确认差异来源，从而提高财务数据的准确性。另一方面，用户根据财务数据的核对结果可以生成唯一的财务数据明细清单，从而可以更加准确的进行风险控制。
149.应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
150.进一步的，本示例实施方式中，还提供了一种财务数据处理装置。该装置可以应用于一服务器或终端设备。参考图8所示，该财务数据处理装置800可以包括任务创建模块810、数据查询模块820、第一数据核对模块830和第二数据核对模块840，其中：
151.任务创建模块810，用于创建数据核对任务，并生成对应的数据核对任务标识；
152.数据查询模块820，用于根据所述数据核对任务标识，查询数据核对任务表中的待核对财务数据；
153.第一数据核对模块830，用于当所述待核对财务数据的总属性值小于预设属性值时，根据明细维度将所述待核对财务数据与数据库中的第一表单数据进行核对；
154.第二数据核对模块840，用于当所述待核对财务数据的总属性值不小于预设属性值时，根据时间维度汇总所述待核对财务数据与所述第一表单数据，并将汇总结果进行核对。
155.在一种可选的实施方式中，任务创建模块810包括：
156.文件接收模块，用于接收待核对文件，并生成对应的数据核对任务标识；
157.数据拆分模块，用于将所述待核对文件拆分为多条待核对财务数据；
158.数据存储模块，用于将所述多条待核对财务数据存储至所述数据核对任务表中，所述数据核对任务表对应多个数据核对任务标识；
159.标识存储模块，用于将所述数据核对任务标识存储至所述待核对任务消息队列中；
160.消息队列发布模块，用于发布所述待核对任务消息队列。
161.在一种可选的实施方式中，数据查询模块820包括：
162.标识获取模块，用于通过订阅所述待核对任务消息队列获取所述数据核对任务标识；
163.数据查询模块，用于根据所述数据核对任务标识查询所述数据核对任务表，获取待核对财务数据。
164.在一种可选的实施方式中，财务数据处理装置800还包括：
165.数据校验模块，用于获取所述待核对财务数据后，对所述待核对财务数据进行基础校验，并将通过校验的所述待核对财务数据进行核对处理。
166.在一种可选的实施方式中，第一数据核对模块830包括：
167.明细数据核对模块，用于根据预设的对账标识，将所述待核对财务数据中的明细数据与数据库中的第一表单数据中的表单明细数据进行核对；
168.数据同步模块，用于将核对结果更新至所述数据核对任务表中。
169.在一种可选的实施方式中，第二数据核对模块840包括：
170.第一数据汇总模块，用于在预设时间周期内，将所述待核对财务数据中的核心数据汇总，生成待核对总核心数据；
171.第二数据汇总模块，用于将所述第一表单数据中的表单核心数据汇总，生成表单总核心数据；
172.核心数据核对模块，用于将所述待核对总核心数据和表单总核心数据进行核对，得到核对结果。
173.在一种可选的实施方式中，财务数据处理装置800还包括：
174.第三数据核对模块，用于根据所述数据核对任务的任务标识聚合核对结果一致的财务数据，并将聚合结果与数据库中的第二表单数据进行核对。
175.上述财务数据处理装置中各模块的具体细节已经在对应的财务数据处理方法中进行了详细的描述，因此此处不再赘述。
176.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
177.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。