CN113177772A - 一种业务数据处理方法、装置和系统 - Google Patents

Abstract

本申请涉及金融科技领域，提供了一种业务数据处理方法、装置和系统，其中，该方法包括：响应于目标用户的补偿请求，生成工单；通过记账审批系统对所述补偿请求进行审批；在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。通过上述方案解决了现有的赔偿业务中效率较低的问题，有效提升了业务处理效率，提升了用户体验。

Description

一种业务数据处理方法、装置和系统

技术领域

本申请属于金融科技技术领域，尤其涉及一种业务数据处理方法、装置和系统。

背景技术

针对银行业基层给客户补偿金额的场景，一般存在申请及审批流程较长，不能完成立即补偿，无法及时将纠纷化解在当时当地的问题，同时也增加了基层的工作量。

在本例中，通过采取“先现场补偿、后登记备案”的处理流程，在原有的记账、报账、审批等一系列流程中，加入了工单体系，因为客户并不关心银行内部之间的报账审核，在记账成功通过后即可给客户转账，从而可以提升用户体验，通过上述方案克服了银行多系统无法联动操作，数据不共通共享的问题，通过加入工单系统，结合原银行记账、报账、对账等多系统联动，可以实现银行的多层级快速审批，从而达到快速到账的目的。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请目的在于提供一种业务数据处理方法、装置和系统，可以提升业务处理效率和用户体验。

本申请提供一种业务数据处理方法、装置和系统是这样实现的：

一种业务数据处理方法，所述方法包括：

接收目标用户的补偿请求；

通过记账审批系统对所述补偿请求进行审批；

在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

在一个实施方式中，在接收目标用户的补偿请求之后，还包括：响应于所述补偿请求，通过工单系统生成工单，其中，工单用于记录和表征所述补偿请求的处理进度。

在一个实施方式中，在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录，包括：

在审批通过的情况下，将补偿金额从银行网点内部账号转账至所述目标用户的账号中；

在转账成功后，生成一条待销账记录，并未所述待销账记录生成一个核算核销编号；

根据所述银行内部账号、所述核算核销编号和所述工单编号，生成一条待销账记录；

将所述待销账记录同步至所述消息队列中。

在一个实施方式中，通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功，包括：

通过所述报账系统从所述消息队列中提取待销账记录；

对所述待销账记录进行内部审批；

在内部审批通过后，将补偿金额从银行赔偿科目账号转账至银行网点内部账号中；

在转账完成后，将所述消息队列中的待销账记录的状态修改为报账成功。

在一个实施方式中，上述方法还包括

通过对账系统接收记账审批系统和报账系统通过消息队列传输的账务数据；

根据所述消息队列中的账务数据，对销账和报账所涉及的账号进行核算和更新；

在到达预设时间点的时候，对记账审批系统和报账系统的数据一致性进行校验；

在校验通过后，将校验结果数据通过消息队列反传至工单系统中以将所述工单的状态修改为已完成。

在一个实施方式中，在通过记账审批系统对所述补偿请求进行审批之后，还包括：

在审批未通过的情况下，调用HTTP协议的修改工单状态接口；

通过所述工单状态接口，将所述工单的状态修改为未通过。

一种业务数据处理装置，包括：

生成模块，用于响应于目标用户的补偿请求；

审批模块，用于通过记账审批系统对所述补偿请求进行审批；

转账模块，用于在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

报账模块，用于通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

在一个实施方式中，所述转账模块包括：

转账单元，用于在审批通过的情况下，将补偿金额从银行网点内部账号转账至所述目标用户的账号中；

第一生成单元，用于在转账成功后，生成一条待销账记录，并为所述待销账记录生成一个核算核销编号；

第二生成单元，用于根据所述银行内部账号、所述核算核销编号和所述工单编号，生成一条待销账记录；

同步单元，用于将所述待销账记录同步至所述消息队列中。

一种业务数据处理系统，包括：

工单发起系统，用于进行补偿请求工单的建立和工单状态的更改；

记账审批系统，用于对补偿请求进行审批，在审批通过后，为目标用户转账，并在消息队列中生成一条待销账记录；

报账核销系统，用于对消息队列中的待销账记录进行报账处理；

会计核算系统，用于根据消息队列中的记账数据和报账数据，对账户余额表进行更新，并对银行内部账号之间的借贷信息进行核对；

消息队列系统，接收各系统上传的数据，并将接收数据更新至消息队列中。

一种电子设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述方法的步骤。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现上述方法的步骤。

本申请提供的业务数据处理方法和装置，针对现有的在用户存在赔偿需求的时候，需要银行内部走完所有的审批流程拿到赔偿款项之后，用户才能获取赔偿款，但是银行内部的流程与用户是没有关系的，这样势必导致用户体验较差，为此，在本申请中在目标用户的补偿请求审批通过后，就将补偿金额转账至所述目标用户的账号中，对于银行系统而言，后续的销账审批等都在为用户转账之后执行，从而使得用户可以在第一时间获得赔偿，通过上述方案解决了现有的赔偿业务中效率较低的问题，有效提升了业务处理效率，提升了用户体验。

附图说明

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

图1是本申请提供的业务数据处理方法一种实施例的方法流程图；

图2是现有的网点投诉补偿业务的流程示意图；

图3是本申请提供的多系统协同处理的流程图；

图4是本申请提供的账务流转示意图；

图5是本申请提供的新建工单后账务状态示意图；

图6是本申请提供的新建工单后工单状态示意图；

图7是本申请提供的一种业务数据处理方法的电子设备的硬件结构框图；

图8是本申请提供的业务数据处理装置的结构框图。

具体实施方式

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

针对现有的在用户存在赔偿需求的时候，需要银行内部走完所有的审批流程拿到赔偿款项之后，用户才能获取赔偿款，但是银行内部的流程与用户是没有关系的，这样势必导致用户体验较差，为此，在本申请中在目标用户的补偿请求的工单审批通过后，就将补偿金额转账至所述目标用户的账号中，对于银行系统而言，后续的销账审批等都在为用户转账之后执行，从而使得用户可以在第一时间获得赔偿，通过上述方案解决了现有的赔偿业务中效率较低的问题，有效提升了业务处理效率，提升了用户体验。

具体的，在本例中提供了一种业务数据处理方法，如图1所示，可以包括如下步骤：

步骤101：响应于目标用户的补偿请求；

步骤102：通过记账审批系统对所述补偿请求进行审批；

进一步的，像响应于目标用户的补偿请求，还可以通过工单系统生成工单，在工单系统生成工单后，可以同步在记账审批系统中生成一笔记账申请书，对补偿请求的审批就是对补偿申请书的审批。其中，工单用于记录和表征所述补偿请求的处理进度。

步骤103：在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

步骤104：通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

即，在工单新建后，工单状态从初始的“新建中”到最终显示“已处理”，账务状态从初始的“待销账”到最终显示“已销账”，实现业务+账务全流程闭环，有助于网点第一时间化解投诉问题，保证在账务流程中内部账务未核销情况下即完成转账，从而使得用户当场就可以得到处理结果，从而可以显著提升投诉处理时效，提升用户体验。

具体的，在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录，可以按照如下步骤执行：

S1：在审批通过的情况下，将补偿金额从银行网点内部账号转账至所述目标用户的账号中；

S2：在转账成功后，生成一条待销账记录，并未所述待销账记录生成一个核算核销编号；

S3：根据所述银行内部账号、所述核算核销编号和所述工单编号，生成一条待销账记录；

S4：将所述待销账记录同步至所述消息队列中。

即，初始审批通过，就通过网点的账号向用户账户进行赔偿金额的转账，然后生成待销账记录，即，由网点先行垫付，然后通过消息队列的方式，使得银行后台的系统可以对网点进行销账。

在进行销账的时候，即，通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功，可以包括：

S1：通过所述报账系统从所述消息队列中提取待销账记录；

S2：对所述待销账记录进行内部审批；

S3：在内部审批通过后，将补偿金额从银行赔偿科目账号转账至银行网点内部账号中；

S4：在转账完成后，将所述消息队列中的待销账记录的状态修改为报账成功。

对于消息队列而言，里面存储有待销账记录，也存储各个系统模块的账户处理数据，并对待销账记录的状态进行实时修改，这样各个系统模块可以通过维护消息队列的方式实现数据的同步，而不需要各个系统模块进行强耦合，以实现了模块的解耦。

为了保证各系统模块的数据一致性，可以通过对账系统接收记账审批系统和报账系统通过消息队列传输的账务数据；根据所述消息队列中的账务数据，对销账和报账所涉及的账号进行核算和更新；在到达预设时间点的时候，对记账审批系统和报账系统的数据一致性进行校验；在校验通过后，将校验结果数据通过消息队列反传至工单系统中以将所述工单的状态修改为已完成。即，针对某个工单而言，所有节点模块都实现数据的校验之后，即，不管是销账系统还是报账系统，数据都是吻合的，就表明这个工单已经最终完成了网点已经销账了，这时该工单就可以调整为完成状态，从而形成一个完整的闭合工单。

在通过记账审批系统对所述补偿请求进行审批之后，还存在审批不同的情况下，针对审批未通过的情况，可以调用HTTP协议的修改工单状态接口；通过所述工单状态接口，将所述工单的状态修改为未通过。对于未通过的工单，整个流程结束。

考虑到针对补偿业务而言，对于银行系统而言需要设置一定的补偿次数和补偿金额限制，以避免恶意申请。为此，在通过记账审批系统对所述工单进行审批的时候，可以确定所述目标用户申请补偿的次数是否超出预设次数阈值；在确定未超出预设次数阈值的情况下，确定申请补偿的金额是否超出预设金额阈值；在确定未超出预设金额阈值的情况下，确定满足申请条件，通过记账审批系统对所述补偿请求进行审批。即，先确定该用户的请求次数和请求金额是否满足要求，如果是满足限制的，则再进一步对具体的申请请求进行审核，确定该用户是否满足补偿条件。

在本例中，还提供了一种业务数据处理系统，可以包括：

工单发起系统，用于进行补偿请求工单的建立、工单详情信息的补录和账务流程审批状态的展现；；

记账审批系统，用于对补偿请求进行审批，具体的，该补偿请求可以通过一笔申请书展现，在审批通过后，为目标用户转账，并在消息队列中生成一条待销账记录；

报账核销系统，用于对消息队列中的待销账记录进行报账处理；

会计核算系统，用于根据消息队列中的记账数据和报账数据，对账户余额表进行更新，并对银行内部账号之间的借贷信息进行核对；

消息队列系统，接收各系统上传的数据，并将接收数据更新至消息队列中。

通过上述多个系统模块进行协同处理，工单系统与记账系统的绑定实现工单数据与账务数据的联动。通过引入分布式消息引擎和定时任务来解耦记账系统和报账系统的强依赖关系，用数据最终一致性替换强事务。即，不必等到账务全流程处理完成，可提前给客户转账，待后续银行内部补充报账流程达到最终账务明细的一致性。通过分布式消息引擎和定时任务对账，实现了在账务流程中账务未核销情况下可以完成转账。用户当场就能得到处理结果，无需等待记账系统、报账系统和对账系统完成银行内部账务处理。在对账系统完成对记账数据和报账数据的一致性检查正确后，发送账务数据，工单系统监听账务数据来更新工单的最终状态，完成工单记录、账务记账、销账的全流程记录的闭环。

下面结合一个具体实施例对上述方法进行说明，然而，值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

在本例中，提出了一种多系统协同的业务处理方法，克服了现有业务流程中网点给客户补偿审批流程复杂、操作流程长，客户体验不佳的问题，在技术上克服了银行多系统无法联动操作，数据不共通共享的问题。具体的，通过工单、记账、报账、对账等多系统联动的处理方式，通过先发起工单、记账审批实现即时转账，后登记备案实现报账核算的方式实现银行多层级快速审批，快速到账，通过加入工单体系，通过账务数据和工单数据的联动，打通银行间多系统壁垒，实现发起、审批、挂账、销账、核算、查询、反传数据多系统联动处理业务，用工单中显示的工单状态和账务状态记录账务处理的全流程审批结果。

在工单新建后，工单状态从初始的“新建中”到最终显示“已处理”，账务状态从初始的“待销账”到最终显示“已销账”，实现业务+账务全流程闭环，有助于网点第一时间化解投诉问题，保证在账务流程中内部账务未核销情况下即完成转账，从而使得用户当场就可以得到处理结果，从而显著提升投诉处理时效，提升用户体验。

考虑到现有的银行系统账务体系包括记账、报账、会计核算等几个系统模块，这几个系统模块之间是强依赖关系，直到最后的报账和会计核算系统审核完成，网点内部户账号收到补偿款后才能处理用户的补偿流程，给客户转账。

针对上述问题，在本申请的方案中，通过新增工单记录的方式自动记录账务流转全流程的状态，并在记账时审批通过后就可以把钱转给用户，用户无需等待银行内部报账审核流程的处理结果就可以收到补偿，从而加速了流程处理效率。

具体的，在本例中，通过在原账务核销领域通过加入工单体系，实现包括发起工单、记账审批、转账、报账、核算等多个业务系统的联动和数据互通。并通过工单系统的工单状态和账务状态可以观察到账务流转全流程的结果和状态。进一步的，引入了消息引擎解除了记账系统对报账系统的强依赖关系，从而将账务数据投递到消息中心，达到了系统间解耦，由强事务变成最终一致性事务，允许一定时间内，不同节点的数据不一致，只需要保障数据最终的一致性即可。即不必等到记账、报账全流程完成，在记账完成后即可给客户转账，客户无需关心银行内部之间的报账审核结果即可结束投诉，待后续银行内部补充报账流程达到最终账务明细一致性，实现先快速审批、即时到账，后登记备案报账核销的效果。

如图2所示，为现有的网点投诉补偿业务的流程示意图，网点负责人需要通过记账、报账、会计核算系统流程，进行登记备案和记账报账审批，全流程结束后给客户实施转账。在本例中，通过加入工单系统，发起工单后同步在记账系统中生成账务申请书，网点审批结束后即可完成转账，后续在报账系统和会计核算系统中完成后续流程，从而实现先现场转账后登记备案的流程，提高了流程处理效率。且网点人员无需通过与分行线下沟通了解审批结果，通过网点的工单系统，直接通过工单中显示的工单状态和账务状态就可以记录账务处理全流程审批结果。

图3为多系统协同处理的全流程图，在本例中，通过工单系统与记账系统的绑定实现工单数据与账务数据的联动。通过引入分布式消息引擎和定时任务来解耦记账系统和报账系统的强依赖关系，用数据最终一致性替换强事务。即不必等到账务全流程处理完成，可提前给客户转账，待后续银行内部补充报账流程达到最终账务明细的一致性。同时，允许存在两种情况下报账系统和记账系统数据不一致：一是记账数据发送和订阅之间的延时；二是极少数消息丢失的情况，造成报账系统和记账系统数据暂时不一致。第一种情况一定时间范围之后报账系统会收到记账数据；第二种情况依靠对账系统的定时任务修复报账系统数据，达到最终的数据一致性。

通过分布式消息引擎和定时任务对账，实现了在账务流程中账务未核销情况下可以完成转账。用户当场就能得到处理结果，无需等待记账系统、报账系统和对账系统完成银行内部账务处理。在对账系统完成对记账数据和报账数据的一致性检查正确后，发送账务数据，工单系统监听账务数据来更新工单的最终状态，完成工单记录、账务记账、销账的全流程记录的闭环。

具体的，在本例中提供了一种投诉补偿处理系统架构，可以包括如下系统模块：

1)工单发起系统，负责整个流程的发起和结束闭环。工单系统可进行工单信息的初步录入、更新和补录，工单用户通过输入客户银行三要素及卡号、网点内部户账号及补偿金额后提交，从而形成工单，该工单可在记账系统的同个用户名下生成一笔新申请书，且工单编号与申请书编号具有一一对应关系。工单系统除了直接使用记账系统的账务数据，还订阅消息队列中会计核算系统传输的账务数据，来更新工单和账务状态。

2)记账审批系统，通过账务申请书的流转实现账务明细的上报，可对申请书内容即内部账务审批明细进行核对、提交、审批、记账，如果超过部门审批权限，则需要提交上级审批，在审批通过后，记账成功。在给客户转账的同时，生成一笔待销账记录，生成核算核销编号。将内部户账号、产品核销编号(即工单编号)、核算核销编号同步至分布式消息队列中，审批结果数据反传至工单系统从而更新工单状态与账务状态。

3)报账核销系统，获取分布式消息队列中的待销账信息，通过核对账户属性，调取系统账务管理登记薄中数据，一借一贷核销记账系统中记账数据进行报账，并更新会计核算系统的账户余额表和账务管理登记薄的数据。

4)会计核算系统，通过订阅消息队列中的记账数据和报账数据，更新账户余额表，并对账务登记薄中内部账号的账务借贷信息进行核对，每日定时将更新的账务信息发送至消息队列中，工单系统通过订阅消息队列中的账务数据来更新工单状态和账务状态。

5)消息队列系统，接收各系统间的账务数据，实现记账系统、报账系统、对账系统间的解耦，各系统不需要再考虑系统之间数据的调用情况，只需要向消息队列发送消息即可，提升了数据传输的效率和准确性。

在上述业务系统中，主要使用销账内部户，通过对销账内部户进行挂账和销账实现给客户转账，在账务流程中，分别阐述为记账和报账。各系统模块间系统编号和公共数据流转关系可以如下表1所示：

表1

基于上述的多系统协同的业务处理，可以按照如下步骤进行：

S1：在收到客户投诉后，网点负责人在工单系统中录入工单信息，工单系统通过调用记账系统提供的Http协议的记账申请接口，通知记账系统生成申请书。

S2：记账系统根据工单中账务信息生成包含内部销账明细的申请书后，网点负责人通过记账系统对明细内容进行核对、提交、审批。审批结果可以分为：不通过和通过两种状态：如果审批不通过，则调用工单系统提供的Http协议的修改工单状态接口，修改工单最终状态为不通过，流程终止；如果审批通过，则记账成功生成核算核销编号，并实施即时转账，转账流程结束，将内部户账号、产品核算编号、核算核销编号等账务信息数据发送到消息队列的记账成功主题中。

在该步骤完成后，表明对于客户而言，整个业务流程已经处理完成，审核通过，得到补偿。

S3：报账系统集群在同一个报账消费者组，根据消息队列的特性，可以保证一条记账成功数据是集群中的单节点处理，订阅到记账成功数据后，报账系统完成报账业务处理后，将内部户账号、产品核算编号、核算核销编号等账务信息数据发送到消息队列的报账成功主题中。

在该步骤完成后，表明报账系统参与业务处理的工作已完成。

S4：对账系统集群在同一个对账消费者组，根据消息队列的特性，不同消费者组订阅数据具有隔离性，互不干扰。一类数据的集合称为一个主题，对账系统作为数据的消费者订阅了记账成功主题和报账主题，消费到的数据存储到对账系统自己的数据仓库里。可以设置在每晚服务器空闲的时间，对记录到的记账成功数据、报账数据、记账数据表、报账数据表进行跑批处理，如果报账数据缺失，则根据记账数据进行修复，完成记账数据和报账数据的最终一致性。然后，发送工单处理完毕的数据到消息队列的工单状态主题中。

S5：工单系统通过订阅消息队列中的工单状态主题，更新工单状态，网点负责人在看到工单完成的最终状态后，可以关闭工单，结束整个流程。

如图4所示，为全流程的账务流转关系。例如，客户在网点投诉需返还客户100元，经网点核实后，可在工单系统进行记录借贷双方信息，网点负责人在记账系统进行初步核对审批后记账成功，即可完成转账，客户卡号收到100元，网点内部户账号减少100元，报账系统从消息队列中获取待销账信息进行销账成功，即从公司赔偿科目账号中给网点内部户报销100元，网点账务核销完成。

对于多模块数据流转而言，多模块可以包括：工单模块、记账模块、报账模块和会计核算模块，各模块可以按照如下逻辑进行处理：

1)工单模块，部署在工单系统中，主要包括：参数配置单元、用户权限单元、录入工单单元、自动更新状态单元、手动补录工单单元和查询工单单元，其中：

参数配置单元，可在工单系统中设置单个客户补偿次数，和本机构、上级机构直至总行的补偿金额上限参数。

用户权限单元，在工单系统中给处理该业务的用户添加特定角色，保证该业务在银行内小范围具有权限的用户在对应栏目中进行处理及查询。

录入工单单元，是在网点受理现场补偿投诉后，由具有特定角色的用户进入工单系统通过固定栏目输入客户三要素信息后，通过判断系统参数，判读该客户是否满足现场补偿的要求，如果满足，则继续输入(或选择)“客户手机号”、“网点负责人手机号”、“账户类型”、“客户卡号/账号”、“币种”、“钞汇标志”、“客户提出补偿金额”、“补偿金额”、“销账内部户账号”等重要信息，系统按照“补偿金额”记录实际需补偿的金额。信息输入无误后，点击提交，形成一笔新工单编号，工单编号以产品核销编号命名，如图6所示，此时工单状态为“新建中”，如图5所示，账务状态为“待挂账”，同时在记账系统中同步生成一笔新申请书。

自动更新状态单元，需要在日终批量后自动更新工单数据，分为两部分，工单系统接收记账系统数据更新状态和工单系统接收会计核算系统数据更新状态。具体地，如图5和图6所示，第一部分工单系统接收记账系统批量传送的数据来更新工单状态和账务状态包括记账成功，工单系统工单状态不更新，账务状态为待销账。如果记账失败，工单状态更新为已删除，账务状态更新为记账失败。第二部分工单系统接收会计核算系统批量传送的数据来更新工单状态和账务状态包括报账成功，工单系统的工单状态不更新，账务状态为已销账。如果报账失败则状态均不更新。

手动补录工单单元，如图5和图6所示，由具有特定角色的用户进入工单系统通过固定补录栏目，通过工单编号链接进行信息补录，补录完成后，工单状态更新为“已处理”，账务状态不更新。当工单状态为已处理，账务状态为已销账时，账务处理及工单处理全流程已闭环。具体的账务状态和工单状态的状态机变化可以如图5和图6所示。

查询工单单元，一方面包括客户不满足参数要求，提示补偿次数或机构补偿金额达到上限，则无法再次补偿，工单系统用户可点击工单编号查询前期补偿情况。一方面形成工单后，即可通过工单编号、客户信息等条件查询工单进展，查看工单状态和账务状态的更新情况。

2)记账模块，部署在记账系统中，主要包括用户对接单元、参数维护单元、审批单元、记账结果单元，其中：

用户对接单元，是记账系统中用户和工单系统中用户为同一人，需在记账系统中进行用户新增和增加用户角色，该用户为机构账务处理岗，同时需设置机构账务审批岗，根据审批参数额度，需配置不同机构层级的审批人。

参数维护单元，包括机构专业线配置，用户机构归属配置，审批额度层级设置，通过参数配置，可实现机构专属专业线对申请书中内部账务明细进行审批，并设置网点、一级支行部门、一级支行行长、二级分行部门、二级分行行长、一级分行部门、一级分行行长审批额度，实现不同额度不同层级的审批。

审批单元，包括账务处理岗对申请书中内部账务的明细核对，主要核对借方为网点内部销账户，贷方为客户卡号，确认无误后提交审批。账务审批岗审批，审批通过后，将记账信息上送消息中心，审批不通过将该笔申请书退回账务处理岗修改。

记账结果单元，主要包括两部分，一个记账信息上送主机返回记账成功，记账成功后系统批量向客户指定账户转账，并在账务管理登记薄中形成核销编号等核销信息。一个上送主机返回记账失败后，账务处理岗可进行失败重提，重提后在直接再次上送主机返回记账结果。记账结果信息保存至批量信息中，可更新工单系统的工单状态和账务状态。

3)报账模块，部署在报账系统中，主要包括录入报账信息单元和审批报账信息单元。

网点和上级分行之间的账务报销，在本例中将该系统从账务转账处理流程中解耦，形成弱依赖，报账系统需要上级账务审核员进行审核，所以达不到实时处理用户工单，而用户并不关心银行内部之间的报账审核。因此，引入分布式消息引擎将记账系统对报账系统的强依赖解除，将账务消息投递到消息中心，然后记账系统更新工单状态。报账系统监听账务消息，并处理后续的报账流程。对于引入分布式消息中心可能造成的极小概率的消息丢失，通过每天的定时对账系统进行最终数据的校验，保证四个系统的数据的最终一致性。

录入报账信息单元，报账时原网点内部销账户做贷方，通过输入销账内部户账号可对接会计核算系统中账务管理登记薄信息，回显该销账内部户名下的核销记录，选择对应记录。借方使用赔偿支出科目，一借一贷后上送报账信息，形成流水信息号。

审批报账信息单元，审批报账信息后，报账处理成功，内部销账户原有挂账信息被销账，并将报账信息记录在会计核算系统的账务管理登记薄中。

4)会计核算模块，部署在会计核算系统中，也属于对账系统，负责银行内部账务的核算和管理，可接收记账系统和报账系统通过消息队列传输的账务数据，并根据消息队列中的账务数据更新账务管理登记薄和账户余额表中信息，对涉及销账内部户账务信息进行核算、更新，每晚执行定时任务审核记账系统和报账系统数据的正确性，以完成数据最终一致性的校验，并将数据通过消息队列反传至工单系统中自动更新工单系统中的状态，到达工单可关闭状态，工单操作员看到工单中账务状态显示为已销账，即可关闭工单，业务处理完成，流程闭环。

本申请上述实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在电子设备上为例，图7是本申请提供的一种业务数据处理方法的电子设备的硬件结构框图。如图7所示，电子设备10可以包括一个或多个(图中仅示出一个)处理器02(处理器02可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器04、以及用于通信功能的传输模块06。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备10还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。

存储器04可用于存储应用软件的软件程序以及模块，如本申请实施例中的业务数据处理方法对应的程序指令/模块，处理器02通过运行存储在存储器04内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的业务数据处理方法。存储器04可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器04可进一步包括相对于处理器02远程设置的存储器，这些远程存储器可以通过网络连接至电子设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块06用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输模块06包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块06可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在软件层面，上述装置可以如图8所示，可以包括：

生成模块801，用于响应于目标用户的补偿请求；

审批模块802，用于通过记账审批系统对所述补偿请求进行审批；

转账模块803，用于在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

报账模块804，用于通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

在一个实施方式中，上述报账模块804具体可以用于通过所述报账系统从所述消息队列中提取待销账记录；对所述待销账记录进行内部审批；在内部审批通过后，将补偿金额从银行赔偿科目账号转账至银行网点内部账号中；在转账完成后，将所述消息队列中的待销账记录的状态修改为报账成功。

在一个实施方式中，上述业务数据处理装置还可以用于在接收目标用户的补偿请求之后，响应于所述补偿请求，通过工单系统生成工单，其中，工单用于记录和表征所述补偿请求的处理进度。

在一个实施方式中，上述转账模块803可以包括：转账单元，用于在审批通过的情况下，将补偿金额从银行网点内部账号转账至所述目标用户的账号中；第一生成单元，用于在转账成功后，生成一条待销账记录，并为所述待销账记录生成一个核算核销编号；第二生成单元，用于根据所述银行内部账号、所述核算核销编号和所述工单编号，生成一条待销账记录；同步单元，用于将所述待销账记录同步至所述消息队列中。

在一个实施方式中，上述业务数据处理具体还可以用于通过对账系统接收记账审批系统和报账系统通过消息队列传输的账务数据；根据所述消息队列中的账务数据，对销账和报账所涉及的账号进行核算和更新；在到达预设时间点的时候，对记账审批系统和报账系统的数据一致性进行校验；在校验通过后，将校验结果数据通过消息队列反传至工单系统中以将所述工单的状态修改为已完成。

在一个实施方式中，上述业务数据处理具体还可以用于在审批未通过的情况下，调用HTTP协议的修改工单状态接口；通过所述工单状态接口，将所述工单的状态修改为未通过。

本申请的实施例还提供能够实现上述实施例中的业务数据处理方法中全部步骤的一种电子设备的具体实施方式，所述电子设备具体包括如下内容：处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的业务数据处理方法中的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤1：响应于目标用户的补偿请求，生成工单；

步骤2：通过记账审批系统对所述补偿请求进行审批；

步骤3：在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

步骤4：通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

从上述描述可知，本申请实施例针对现有的在用户存在赔偿需求的时候，需要银行内部走完所有的审批流程拿到赔偿款项之后，用户才能获取赔偿款，但是银行内部的流程与用户是没有关系的，这样势必导致用户体验较差，为此，在本申请中在目标用户的补偿请求的工单审批通过后，就将补偿金额转账至所述目标用户的账号中，对于银行系统而言，后续的销账审批等都在为用户转账之后执行，从而使得用户可以在第一时间获得赔偿，通过上述方案解决了现有的赔偿业务中效率较低的问题，有效提升了业务处理效率，提升了用户体验。

本申请的实施例还提供能够实现上述实施例中的业务数据处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的业务数据处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤1：响应于目标用户的补偿请求，生成工单；

步骤2：通过记账审批系统对所述补偿请求进行审批；

步骤3：在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

步骤4：通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

从上述描述可知，本申请实施例针对现有的在用户存在赔偿需求的时候，需要银行内部走完所有的审批流程拿到赔偿款项之后，用户才能获取赔偿款，但是银行内部的流程与用户是没有关系的，这样势必导致用户体验较差，为此，在本申请中在目标用户的补偿请求的工单审批通过后，就将补偿金额转账至所述目标用户的账号中，对于银行系统而言，后续的销账审批等都在为用户转账之后执行，从而使得用户可以在第一时间获得赔偿，通过上述方案解决了现有的赔偿业务中效率较低的问题，有效提升了业务处理效率，提升了用户体验。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

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

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims (11)

1.一种业务数据处理方法，其特征在于，所述方法包括：

接收目标用户的补偿请求；

通过记账审批系统对所述补偿请求进行审批；

在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

2.根据权利要求1所述的方法，其特征在于，通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功，包括：

通过所述报账系统从所述消息队列中提取待销账记录；

对所述待销账记录进行内部审批；

在内部审批通过后，将补偿金额从银行赔偿科目账号转账至银行网点内部账号中；

在转账完成后，将所述消息队列中的待销账记录的状态修改为报账成功。

3.根据权利要求1所述的方法，其特征在于，在接收目标用户的补偿请求之后，还包括：

响应于所述补偿请求，通过工单系统生成工单，其中，工单用于记录和表征所述补偿请求的处理进度。

4.根据权利要求3所述的方法，其特征在于，在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录，包括：

在审批通过的情况下，将补偿金额从银行网点内部账号转账至所述目标用户的账号中；

在转账成功后，生成一条待销账记录，并为所述待销账记录生成一个核算核销编号；

根据所述银行内部账号、所述核算核销编号和所述工单编号，生成一条待销账记录；

将所述待销账记录同步至所述消息队列中。

5.根据权利要求3所述的方法，其特征在于，还包括：

通过对账系统接收记账审批系统和报账系统通过消息队列传输的账务数据；

根据所述消息队列中的账务数据，对销账和报账所涉及的账号进行核算和更新；

在到达预设时间点的时候，对记账审批系统和报账系统的数据一致性进行校验；

在校验通过后，将校验结果数据通过消息队列反传至工单系统中以将所述工单的状态修改为已完成。

6.根据权利要求3所述的方法，其特征在于，在通过记账审批系统对所述补偿请求进行审批之后，还包括：

在审批未通过的情况下，调用HTTP协议的修改工单状态接口；

通过所述工单状态接口，将所述工单的状态修改为未通过。

7.根据权利要求1所述的方法，其特征在于，通过记账审批系统对所述补偿请求进行审批，包括：

确定所述目标用户申请补偿的次数是否超出预设次数阈值；

在确定未超出预设次数阈值的情况下，确定申请补偿的金额是否超出预设金额阈值；

在确定未超出预设金额阈值的情况下，确定满足申请条件，通过记账审批系统对所述补偿请求进行审批。

8.一种业务数据处理装置，其特征在于，包括：

生成模块，用于接收目标用户的补偿请求；

审批模块，用于通过记账审批系统对所述补偿请求进行审批；

转账模块，用于在审批通过的情况下，将补偿金额转账至所述目标用户的账号中，并在消息队列中生成一条待销账记录；

报账模块，用于通过报账系统对所述消息队列中的待销账记录进行内部审批和报账处理，在内部审批和报账处理结束后，将所述消息队列中的待销账记录的状态修改为报账成功。

9.一种业务数据处理系统，其特征在于，包括：

工单发起系统，用于进行补偿请求工单的建立和工单状态的更改；

记账审批系统，用于对补偿请求进行审批，在审批通过后，为目标用户转账，并在消息队列中生成一条待销账记录；

报账核销系统，用于对消息队列中的待销账记录进行报账处理；

会计核算系统，用于根据消息队列中的记账数据和报账数据，对账户余额表进行更新，并对银行内部账号之间的借贷信息进行核对；

消息队列系统，接收各系统上传的数据，并将接收数据更新至消息队列中。

10.一种电子设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述权利要求1至7中任一项所述方法的步骤。

11.一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现权利要求1至7中任一项所述方法的步骤。

Images