一种业务处理方法及装置

本申请涉及金融科技(Fintech)的数据处理技术领域，尤其涉及一种业务处理方法及装置。

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、实时性要求，也对技术提出更高的要求。在网络迅速发展的今天，已经实现可以通过计算机直接处理大部分金融业务，这种方式极大地节省了人力资源，又可以快速且准确的处理金融业务，提高了金融业务处理的精确性和实时性。

在如今的资源运转机制中，主要包括产品方、代销方、垫资平台、客户方。在代销方中金融理财方面的请款业务处理，主要通过业务处理公共节点记录并汇总交易信息，计算一定时间内所有交易明细的申购总金额和赎回总金额确定是否需要向垫资平台请款；若申购总金额大于等于赎回总金额，则可以走自然垫资，即将申购交易中获得的资金转账到进行赎回交易的客户账户。若申购总金额小于赎回总金额，则需要向垫资平台请款。请款过程中，垫资平台需要足够的时间汇集资金并转账到代销方，使得代销方可以及时将资金转账到客户账户；因此，需要在预定时间内生成请款单并发送。现有技术中所有交易明细计算都在业务处理公共节点中处理，交易明细依次处理，请款单需要一单一单生成，因而需要处理的数据量大，节点处理压力大，处理时间长效率低。

另一方面，向垫资平台请款需要经过产品方，而一般来说产品方合作的垫资平台数量只有1-2个，若垫资平台有系统维护等情况，有可能出现代销方请不到款的情况，加大了代销方的危机系数，导致业务停滞。

因此，现在亟需一种业务处理方法及装置，能够快速完成业务的正常运行，高效完成业务处理。

本发明实施例提供一种业务处理方法及装置，能够快速完成业务的正常运行，迅速匹配垫资平台，高效完成业务的处理。

第一方面，本发明实施例提供一种业务处理方法，该方法包括：

所述清算平台根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定针对至少一个垫资平台的预申请，所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；针对每个预申请，所述清算平台确定处理所述预申请的业务节点及该业务节点对应的子预申请；针对处理所述预申请的业务节点上报的子申请，得到所述预申请对应的总申请；将所述总申请发送至所述预申请对应的垫资平台，并在接收到所述总申请处理成功的指示后，通知所述业务节点；所述子申请是该业务节点基于自身的第二类业务生成的且满足所述子预申请的要求。

采用上述方法，通过清算平台接收多业务节点上报的第一类业务汇总信息和第二类业务汇总信息确定针对垫资平台的预申请；由此，可以预先确定一个或多个垫资平台以及这些确定的垫资平台相应的预申请款数值。且确定该预申请对应的业务节点和这些业务节点的子预申请。如此，可以将子预申请的申请款值发送到各业务节点，以使各业务节点确定子申请的申请款值，进一步使得清算平台获得各业务节点的子申请的申请款值，计算得到总申请值，生成总申请。相比于现有技术中只通过一个公共节点进行上述业务处理过程，本申请为多节点并行处理业务，能够快速完成业务正常运行，迅速匹配垫资平台，高效完成业务处理。

在一种可能的设计中，确定针对至少一个垫资平台的预申请，包括：根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定第一类业务与第二类业务之间的汇总差值；根据所述汇总差值和各垫资平台的属性信息，确定至少一个垫资平台的预申请；每个预申请具有对应的子汇总差值，各子汇总差值用于满足所述汇总差值。

采用上述方法，通过各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定第一类业务与第二类业务之间的汇总差值，也就是得到需要申请垫资的资金数额。根据汇总差值和各垫资平台的属性信息，确定预申请对应的垫资平台。如此，可以根据垫资平台的属性，确定向哪一个垫资平台申请垫资以及垫资金额，可以合理利用垫资资源。

在一种可能的设计中，所述清算平台确定处理所述预申请的业务节点及该业务节点对应的子预申请，包括：所述清算平台根据各业务节点的第二类业务的汇总信息，确定处理所述预申请的业务节点及该业务节点对应的子预申请，其中，处理所述预申请的业务节点的第二类业务的汇总信息不小于所述预申请对应的子汇总差值；处理所述预申请的业务节点的子预申请对应的和等于所述预申请对应的子汇总差值。

采用上述方法，通过清算平台根据各个业务节点的第二类业务的汇总信息确定其对应的预申请和子预申请，由此可以合理分配申请款值，保证每个业务节点需申请的款值可以得到匹配。

在一种可能的设计中，针对处理所述预申请的业务节点上报的子申请，得到所述预申请对应的总申请，包括：接收所述业务节点上报的子申请和第M+1个业务；其中所述子申请是所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总的M个业务得到的；其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；将处理所述预申请的业务节点上报的各子申请进行汇总，得到所述预申请对应的总申请；将各预申请的第M+1业务汇总，得到至少一个垫资平台对应的补充申请并将所述补充申请发送至对应的垫资平台；所述补充申请的业务金额不小于各总申请与各预申请的业务金额的差额。

采用上述方法，通过接收业务节点上报的子申请和第M+1个业务，由此得到各业务节点上报的子申请汇总的总申请和补充申请。由此，在采用多个业务节点同时处理业务的情况下，保证了申请款数值相对于申请的合理分配，防止每个节点为得到足够的申请款值而另生成子申请，导致申请泛滥，浪费垫资资源。

在一种可能的设计中，将所述总申请发送至所述预申请对应的垫资平台之后，还包括：所述清算平台若未接收到所述总申请处理成功的指示，则重新确定所述总申请对应的垫资平台。

采用上述方法，若清算平台没有接受到申请处理成功的指示，则重新确定总申请对应的垫资平台，防止无法获得申请资金，第二类业务无法进行。

在一种可能的设计中，若接收到所述总申请处理成功的指示后，还包括：

所述清算平台根据所述总申请中涉及的第二类业务，生成记账文件；其中，所述记账文件包括文件头、文件体和文件尾，其中，所述文件头中包括所述总申请中涉及的第二类业务的交易总金额和交易总笔数；所述文件体中分多个文件包，每个文件包对应同一垫资平台，所述文件包中记录所述每个文件包对应的第二类业务的明细；每个文件尾中包括该垫资平台涉及的第二类业务的交易总金额和交易总笔数。

采用上述方法，清算平台通过生成包括文件头、文件尾、文件体的记账文件，并使得文件头中包括该总申请中涉及的第二类业务的交易总金额和交易总笔数；文件体中分多个文件包，每个文件包对应同一垫资平台，文件包中记录每个文件包对应的第二类业务的明细；每个文件尾中包括该垫资平台涉及的第二类业务的交易总金额和交易总笔数。由此，可以使得核心记账系统不用一笔一笔记录交易信息，解决了大量交易录入核心系统无法承受高频记账压力问题。

第二方面，本发明实施例提供一种业务处理方法，该方法包括：

业务节点根据自身接收的第一类业务和第二类业务，得到所述业务节点的第一类业务的汇总信息和第二类业务的汇总信息；所述业务节点将所述第一类业务的汇总信息和所述第二类业务的汇总信息上报至清算平台；所述业务节点接收所述清算平台发送的子预申请，所述子预申请是所述清算平台针对至少一个垫资平台的预申请确定的；所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；所述业务节点根据自身的第二类业务，生成满足所述子预申请的要求的子申请；所述业务节点将所述子申请上报至所述清算平台。

采用上述方法，业务节点将第一类业务的汇总信息和第二类业务的汇总信息上报至清算平台，由此得到子预申请，进一步根据自身的第二类业务生成子申请，并将子申请上报清算平台。由此可以保证每一笔交易的垫资平台为同一垫资平台。

在一种可能的设计中，业务节点根据自身接收的第一类业务和第二类业务，得到所述业务节点的第一类业务的汇总信息和第二类业务的汇总信息，包括：所述业务节点分别对自身的第一类业务和自身的第二类业务按如下方式进行汇总：针对同一类业务中各业务的交易时间，确定各业务所在的主组，其中，每个主组中的交易时间属于同一时段；针对每个主组，根据所述主组内的业务的数量划分所述主组中的各业务所在的子组；其中，每个子组中业务的数量不超过第一阈值，所述第一阈值是根据进程的处理量确定的；并行对多个子组进行处理，得到每个子组的汇总信息从而得到各主组的汇总信息。

采用上述方法，业务节点通过根据交易时间对自身的第一类业务和自身的第二类业务的各业务分主组，并对各主组中的业务数量统计，按照一定的数量分子组，如此在多进程并行的情况下，可以将业务平均分配到进程中，减少业务处理时间。

在一种可能的设计中，所述业务节点根据自身的第二类业务，生成满足所述子预申请的要求的子申请，包括：所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总；所述业务节点将前M个业务生成所述子申请，其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；所述业务节点将第M+1个业务上报至所述清算平台。

采用上述方法，业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总，可以保证在以此累计业务金额时，最后一笔业务为各业务交易金额最小值，使得业务节点将前M个业务生成的子申请中包含的申请款值最接近子预申请的申请款值。如此将第M+1个业务上报至清算平台与各业务节点上报的业务另生成补充申请，保证了申请款值的合理分配，合理的利用垫资资源。

第三方面，本发明实施例提供一种业务处理装置，该装置包括：

确定模块，用于所述清算平台根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定针对至少一个垫资平台的预申请，所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；还用于针对每个预申请，所述清算平台确定处理所述预申请的业务节点及该业务节点对应的子预申请；

处理模块，用于针对处理所述预申请的业务节点上报的子申请，得到所述预申请对应的总申请；

收发模块，用于将所述总申请发送至所述预申请对应的垫资平台，并在接收到所述总申请处理成功的指示后，通知所述业务节点；所述子申请是该业务节点基于自身的第二类业务生成的且满足所述子预申请的要求。

在一种可能的设计中，所述确定模块还用于：根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定第一类业务与第二类业务之间的汇总差值；根据所述汇总差值和各垫资平台的属性信息，确定至少一个垫资平台的预申请；每个预申请具有对应的子汇总差值，各子汇总差值用于满足所述汇总差值。

在一种可能的设计中，所述确定模块具体用于：所述清算平台根据各业务节点的第二类业务的汇总信息，确定处理所述预申请的业务节点及该业务节点对应的子预申请，其中，处理所述预申请的业务节点的第二类业务的汇总信息不小于所述预申请对应的子汇总差值；处理所述预申请的业务节点的子预申请对应的和等于所述预申请对应的子汇总差值。

在一种可能的设计中，所述处理模块具体用于：接收所述业务节点上报的子申请和第M+1个业务；其中所述子申请是所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总的M个业务得到的；其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；将处理所述预申请的业务节点上报的各子申请进行汇总，得到所述预申请对应的总申请；将各预申请的第M+1业务汇总，得到至少一个垫资平台对应的补充申请并将所述补充申请发送至对应的垫资平台；所述补充申请的业务金额不小于各总申请与各预申请的业务金额的差额。

在一种可能的设计中，所述收发模块还用于：所述清算平台若未接收到所述总申请处理成功的指示，则重新确定所述总申请对应的垫资平台。

在一种可能的设计中，所述处理模块还用于：所述清算平台根据所述总申请中涉及的第二类业务，生成记账文件；其中，所述记账文件包括文件头、文件体和文件尾，其中，所述文件头中包括所述总申请中涉及的第二类业务的交易总金额和交易总笔数；所述文件体中分多个文件包，每个文件包对应同一垫资平台，所述文件包中记录所述每个文件包对应的第二类业务的明细；每个文件尾中包括该垫资平台涉及的第二类业务的交易总金额和交易总笔数。

第四方面，本发明实施例提供一种业务处理装置，该装置包括：

处理模块，用于业务节点根据自身接收的第一类业务和第二类业务，得到所述业务节点的第一类业务的汇总信息和第二类业务的汇总信息；

收发模块，用于所述业务节点将所述第一类业务的汇总信息和所述第二类业务的汇总信息上报至清算平台；还用于所述业务节点接收所述清算平台发送的子预申请，所述子预申请是所述清算平台针对至少一个垫资平台的预申请确定的；所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；

所述处理模块还用于，所述业务节点根据自身的第二类业务，生成满足所述子预申请的要求的子申请；

所述收发模块还用于，所述业务节点将所述子申请上报至所述清算平台。

在一种可能的设计中，所述处理模块具体用于：所述业务节点分别对自身的第一类业务和自身的第二类业务按如下方式进行汇总：针对同一类业务中各业务的交易时间，确定各业务所在的主组，其中，每个主组中的交易时间属于同一时段；针对每个主组，根据所述主组内的业务的数量划分所述主组中的各业务所在的子组；其中，每个子组中业务的数量不超过第一阈值，所述第一阈值是根据进程的处理量确定的；并行对多个子组进行处理，得到每个子组的汇总信息从而得到各主组的汇总信息。

在一种可能的设计中，所述处理模块具体用于：所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总；所述业务节点将前M个业务生成所述子申请，其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；所述业务节点将第M+1个业务上报至所述清算平台。

第五方面，本申请实施例还提供一种计算设备，包括：存储器，用于存储程序指令；处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如第一方面的各种可能的设计中所述的方法。

第六方面，本申请实施例还提供一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行如第一方面的各种可能的设计中所述的方法。

本申请的这些实现方式或其他实现方式在以下实施例的描述中会更加简明易懂。

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

图1为本发明实施例提供的一种业务处理的架构示意图；

图2为本发明实施例提供的一种业务处理方法的流程示意图；

图3为本发明实施例提供的又一种业务处理方法的流程示意图；

图4为本发明实施例提供的一种记账文件的结构示意图；

图5为本发明实施例提供的一种业务处理方法的流程示意图；

图6为本发明实施例提供的一种业务处理方法的装置示意图；

图7为本发明实施例提供的一种业务处理方法的装置示意图。

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

本申请代销方直接与垫资平台进行业务交互，由于代销方对应的垫资平台数量较多，因此，代销方可以先根据垫资平台记录获取每次请款的相关参数，包括：额度查询成功率、额度查询平均返回时间、请款成功率、请款请求平均返回时间、请款查询平均返回时间、单笔请款额度、单日请款总额度、银行额度等，然后可以对相应的参数设置比重值，例如，针对一个垫资平台来说，额度查询成功率对于推算优先级来说，占比重值为1、额度查询平均返回时间占比重值为1、请款成功率占比重值为2、请款请求平均返回时间占比重值为1、单笔请款额度占比重值为2、单日请款总额度占比重值为1、银行额度占比重值为1，垫资平台的特征值＝额度查询成功率*1+额度查询平均返回时间*1+请款成功率*2+请款请求平均返回时间*1+单笔请款额度*2+单日请款总额度*1+银行额度，如此通过计算生成相应的特征值，再以特征值的大小判断垫资平台的优先级；此处，也可以为垫资平台的上述相应参数设置分段赋值，如，请款成功率在0％-20％为0、在20％-50％为1、在50％-80％为4、在80％-100％为5，以所得赋值与比重值相乘，再将相应参数的赋值与比重值的乘积作和以计算特征值。再根据垫资平台对应的特征值的大小将垫资平台的垫资优先级分等级，例如：高级、中级、低级，或更多的等级，也可以，通过聚类分析的方法，针对各个垫资平台对应的同一个相应参数的值，多次聚合，每一次聚合都将参数的值距离最近的参数聚合成一类，如此针对每个指标都形成一个树状图，统计树状图节点中垫资平台出现的次数，次数最多的垫资平台为最高优先级，按照次数降序依次降低优先级。这里为垫资平台设优先级的方式具体不做限定。最终将垫资平台的优先级信息存储在清算平台，便于清算平台后续生成预申请和总申请以及补充申请等处理工作。

图1为本发明实施例提供的一种业务处理的架构示意图；各个业务节点根据自身接收的第一类业务和第二类业务，得到业务节点的第一类业务的汇总信息和第二类业务的汇总信息，将第一类业务的汇总信息和第二类业务的汇总信息上报至清算平台。清算平台接收各个业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，根据第一类业务的汇总信息和第二类业务的汇总信息和垫资平台优先级等信息确定一个或多个预申请，这里一个垫资平台可能会对应多个预申请；清算平台根据各个业务节点的第一类业务的汇总信息和第二类业务的汇总信息以及预申请，确定每个业务节点对应的子预申请，将子预申请下发到对应的业务节点中。业务节点接收清算平台发送的子预申请，并根据自身的第二类业务，生成子申请，将子申请上报至清算平台。清算平台根据接收到的子申请生成对应预申请的总申请，并发送至垫资平台。

基于此，本申请实施例提供了一种业务处理方法的流程，如图2所示，包括：

步骤201、所述清算平台根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定针对至少一个垫资平台的预申请，所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；

此处，清算平台为负责清算业务交易额度、生成相关文件的系统。第一类业务可以是申购理财基金、申购股票等等可形成资金流入代销方的业务。第二类业务可以是赎回理财基金、赎回股票等等可形成资金流出代销方的业务。第一类业务的汇总信息可以为客户申购理财基金、申购股票等的交易明细及相关信息。第二类业务的汇总信息可以为客户赎回理财基金、赎回股票等的交易信息。垫资平台为可以提供相应资金的机构，可以是一些基金公司、银行等汇集有大量资金的机构。预申请为预先生成的申请请款的请款单、请款文件等应用于请求垫资的申请。

其中，确定针对至少一个垫资平台的预申请，包括：根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定第一类业务与第二类业务之间的汇总差值；根据所述汇总差值和各垫资平台的属性信息，确定至少一个垫资平台的预申请；每个预申请具有对应的子汇总差值，各子汇总差值用于满足所述汇总差值。

此处，汇总差值为各个业务节点的第一类业务的汇总信息中的汇总金额和第二类业务的汇总信息中的汇总金额的差值，例如，各个业务节点的申购总金额和赎回总金额的差值。垫资平台的属性信息包括垫资平台优先级，以及垫资平台当前运营状态、单笔请款额度、单日请款总额度、银行额度等相关信息。子汇总差值为单个业务节点的第一类业务的汇总信息中的汇总金额和第二类业务的汇总信息中的汇总金额的差值。

也就是说，清算平台根据各个业务节点上报的申购总金额和赎回总金额计算出汇总差值，当申购总金额小于赎回总金额时，申购流入的资金不能支持赎回交易的流出资金，因此，需要向垫资平台申请请款。根据清算平台中垫资平台的优先级和相关信息，得到预申请单，一个预申请单可以对应多个业务节点，每个业务节点都有对应的子汇总差值。

举个例子，一天的固定时段内，第一业务节点上报的申购总金额为1万和赎回总金额为2万，第二业务节点上报的申购总金额为2万和赎回总金额为3万，第三业务节点上报的申购总金额为3万和赎回总金额为6万，如此，1+(-2)+2+(-3)+3+(-6)＝-5万，汇总差值为5万，第一业务节点的申购总金额与赎回总金额差值为1万，第二业务节点的申购总金额与赎回总金额差值为1万，第三业务节点的申购总金额与赎回总金额差值为3万，根据清算平台中垫资平台的属性信息，即，A银行优先级一级，单笔上限5万元，单日请款上限10万，系统维护，暂停向外借款。B银行优先级二级，单笔上限2万元，单日请款上限4万元，尚未发送申请垫资请求，今日可请款额度为4万元，C银行优先级三级，单笔上限5000元，单日请款上限2万元，尚未发送申请垫资请求，今日可请款额度为2万元，D银行优先级四级，单笔上限1000元，单日请款上限5000元，尚未发送申请垫资请求，今日可请款额度为5000元。依照尽量向优先级高的垫资平台发送申请垫资的原则，由于A银行系统维护，暂停向外借款，则顺位到B银行，B银行单笔上限2万元，单日请款上限4万元，且尚未向B银行申请垫资，因此，针对B银行可以生成2个额度为2万元的预申请，针对C银行可以生成4个额度为5000元的预申请，因为汇总差值为5万元，由此，生成预申请2万元、2万元、5000元、5000元。

步骤202、针对每个预申请，所述清算平台确定处理所述预申请的业务节点及该业务节点对应的子预申请；

此处，子预申请为单个业务节点所对应的预先准备的申请款值所对应的申请。在上一个示例中，预申请2万元可以分为两个子预申请，每个子预申请为1万元，分别对应于第一业务节点和第二业务节点。

其中，所述清算平台根据各业务节点的第二类业务的汇总信息，确定处理所述预申请的业务节点及该业务节点对应的子预申请，其中，处理所述预申请的业务节点的第二类业务的汇总信息不小于所述预申请对应的子汇总差值；处理所述预申请的业务节点的子预申请对应的和等于所述预申请对应的子汇总差值。

也就是说，清算平台根据各业务节点的第二类业务的汇总信息得到每个业务节点子汇总差值，确定预申请对应的业务节点和该预申请对应的业务节点对应的子预申请，其中，处理预申请的业务节点的第二类业务的汇总信息不小于预申请对应的子汇总差值，比如，预申请对应的子汇总差值为1万元，处理预申请的业务节点的第二类业务的汇总信息的汇总金额大于等于1万元，换句话说，处理预申请的业务节点的赎回总金额大于子汇总差值；处理预申请的业务节点的子预申请对应的和等于预申请对应的子汇总差值，子预申请中的业务金额相加等于预申请中的业务金额，即子汇总金额。

在上一个示例中，预申请中的业务金额为2万元、2万元、5000元、5000元，预申请的申请额度2万元针对第一业务节点中的申购总金额与赎回总金额差值1万元和第二业务节点中的申购总金额与赎回总金额差值1万元生成子预申请1万元和子预申请1万元，确定第一业务节点对应子预申请的1万元申请额度，确定第二业务节点对应子预申请的1万元申请额度；由于，第三业务节点的申购总金额与赎回总金额差值3万元，预申请的申请额度2万元、预申请的申请额度5000元和预申请的申请额度5000元合计可满足第三业务节点中3万元的申购总金额与赎回总金额的差值，确定第三业务节点对应子预申请的申请额度3万元。

步骤203、针对处理所述预申请的业务节点上报的子申请，得到所述预申请对应的总申请；所述子申请是该业务节点基于自身的第二类业务生成的且满足所述子预申请的要求。

此处，子申请为业务节点根据接收到的子申请将第二类业务的交易金额累加所得到的子申请。子申请包含的金额小于或等于子预申请中的申请额度。清算平台将预申请对应的业务节点的子申请的金额相加得到总申请。在上一个示例中，第一业务节点对应的子预申请1万元，第二业务节点对应的子预申请1万元，在第一业务节点中，将第二类业务相应的交易，交易1赎回金额2000元，交易2赎回金额1000元，交易3赎回金额2000元，交易4赎回金额2000元，交易5赎回金额1000元，交易6赎回金额2000元，以此累加到子预申请中，得到子申请1万元。

其中，接收所述业务节点上报的子申请和第M+1个业务；其中所述子申请是所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总的M个业务得到的；其中，前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；将处理所述预申请的业务节点上报的各子申请进行汇总，得到所述预申请对应的总申请；将各预申请的第M+1业务汇总，得到至少一个垫资平台对应的补充申请并将所述补充申请发送至对应的垫资平台；所述补充申请的业务金额不小于各总申请与各预申请的业务金额的差额。

也就是说，业务节点上报到清算平台的可以包括子申请和一笔第二类业务交易，子申请是业务节点将第二类业务中各业务按照业务金额从大到小依次累加到第M个业务得到的。例如，第一业务节点接收到的子预申请金额为13000元，第一业务节点中有交易1赎回金额5000元，交易2赎回金额4000元，交易3赎回金额3000元，交易4赎回金额2000元，按照业务金额从大到小依次累加，5000元+4000元+3000元+2000元＝14000元,14000元已经超过了子预申请金额13000元，因此，交易4的赎回金额2000元不能归于该子预申请中，因为同一笔第二类业务交易的垫资平台要为同一个垫资平台，也就是一笔第二类业务交易对应一个垫资平台，换句话说，不可以将交易4中的赎回金额2000元分作1000元和1000元，若将交易4中的一份赎回金额1000元算入子预申请另一份算到另一个子预申请中，则两个子预申请很可能不属于同一个预申请对应的垫资平台，5000元+4000元+3000元+1000元＝13000元,虽然恰好得到子预申请的申请额度，但交易4中的赎回交易中的赎回金额2000元则会来自两个垫资平台，违反垫资规则；因此得到子申请12000元，M＝3，第一业务节点将子申请12000元和第M+1笔第二类业务交易上报至清算平台。子预申请额度13000大于子申请金额12000，小于子申请金额+交易4赎回金额2000元＝14000元。如此，第二业务节点的子预申请为13000元，子申请为11000元，第M+1笔第二类业务交易的交易金额为3000，则总申请金额为13000+11000＝24000元，补充申请的业务金额为2000+3000＝5000元。补充申请的业务金额5000元大于各总申请与各预申请的业务额度的差额13000+13000-24000＝2000元。

步骤204、将所述总申请发送至所述预申请对应的垫资平台，并在接收到所述总申请处理成功的指示后，通知所述业务节点；

此处，将总申请发送至预申请相对应的垫资平台，在上步骤201和步骤202示例中，B银行对应的2万元的预申请和总申请2万元，将该总申请2万元发送至B银行，接收到B银行相应的总申请处理成功的知识后，通知第一业务节点和第二业务节点。

其中，若清算平台若未接收到所述总申请处理成功的指示，则重新确定所述总申请对应的垫资平台。这里可以设置轮询机制，在设定时间内未收到相应的垫资平台的响应，则重新按照选用最高优先级垫资平台的方式，确定该总申请对应的垫资平台，并将该总申请发送至该垫资平台。

这里，若接收到所述总申请处理成功的指示后，还包括：所述清算平台根据所述总申请中涉及的第二类业务，生成记账文件；其中，所述记账文件包括文件头、文件体和文件尾，其中，所述文件头中包括所述总申请中涉及的第二类业务的交易总金额和交易总笔数；所述文件体中分多个文件包，每个文件包对应同一垫资平台，所述文件包中记录所述每个文件包对应的第二类业务的明细；每个文件尾中包括该垫资平台涉及的第二类业务的交易总金额和交易总笔数。

此处，记账文件中包括每笔第二类业务交易信息和请款信息，如图4所示，为本申请实施例提供的一种记账文件的结构示意图。文件头中包含各总申请的交易总金额和交易总笔数。文件体中包含文件包，每个文件包对应一个垫资平台，文件包中记录第二类业务交易明细。文件尾中包含每个文件包对应的交易总金额和交易总笔数。此处，记账文件对应的文件头、文件尾中还可以包含其他相应信息，具体不做限制。

采用上述方法，通过清算平台接收多业务节点上报的第一类业务汇总信息和第二类业务汇总信息确定针对垫资平台的预申请；由此，可以预先确定一个或多个垫资平台以及这些确定的垫资平台相应的预申请款数值。且确定该预申请对应的业务节点和这些业务节点的子预申请。如此，可以将子预申请的申请款值发送到各业务节点，以使各业务节点确定子申请的申请款值，进一步使得清算平台获得各业务节点的子申请的申请款值，计算得到总申请值，生成总申请。相比于现有技术中只通过一个公共节点进行上述业务处理过程，本申请为多节点并行处理业务，能够快速完成请款金额清算，迅速匹配垫资平台，高效完成请款业务处理。

基于上述流程，本申请实施例提供了又一种业务处理方法的流程，如图3所示，包括：

步骤301、业务节点根据自身接收的第一类业务和第二类业务，得到所述业务节点的第一类业务的汇总信息和第二类业务的汇总信息；

此处，业务节点根据自身接收到的第一类业务得到第一类业务的汇总信息，进一步得到第一类业务的汇总金额，业务节点根据自身接收到的第二类业务得到第二类业务的汇总信息，进一步得到第二类业务的汇总金额。

其中，所述业务节点分别对自身的第一类业务和自身的第二类业务按如下方式进行汇总：针对同一类业务中各业务的交易时间，确定各业务所在的主组，其中，每个主组中的交易时间属于同一时段；针对每个主组，根据所述主组内的业务的数量划分所述主组中的各业务所在的子组；其中，每个子组中业务的数量不超过第一阈值，所述第一阈值是根据进程的处理量确定的；并行对多个子组进行处理，得到每个子组的汇总信息从而得到各主组的汇总信息。

此处，在业务节点中，可以通过多进程对第一类业务和第二类业务进行结算，为了可以保留业务的时间信息，且使得每个进程处理的业务数量相近；将业务按照业务产生的时间进行分主组，再统计主组内的业务数量分子组，使得每个子组内的业务数量相等或相近，由此，每个进程处理相等或相近数量的子组，进而使得每个进程处理的业务数量相等或相近，以此，能够减少每个进程处理业务数量不均造成的部分进程处理完业务后，还有部分进程仍然需要继续处理大量业务的情况。若一个主组内的业务分为多个主组过程中最后剩余一部分业务数量不足够分为一个子组，则判断剩余部分的业务数量加入子组后，子组中包含的业务数量是否超过第一阈值，若超过，则将剩余部分的业务作为一个子组，否则，加入上一个子组中。如此，可以得到每笔交易的主组号和子组号，将该交易所在的子系统I D、时间戳、DCN编号、子组号、主组号作为特征值形成全局唯一的交易流水号，从而，若需要将业务节点合并时，防止出现因为时间重复，而导致的流水号主键冲突，出现的自增序列的现象。这种情况下，即使业务节点扩容，也能不影响之前的数据，保证了业务的稳定性。

步骤302、所述业务节点将所述第一类业务的汇总信息和所述第二类业务的汇总信息上报至清算平台；

此处，业务节点将包括汇总金额的第一类业务的汇总信息和包括汇总金额的所述第二类业务的汇总信息上报至清算平台。

步骤303、所述业务节点接收所述清算平台发送的子预申请，所述子预申请是所述清算平台针对至少一个垫资平台的预申请确定的；所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；

此处，业务节点接收清算平台的子预申请，子预申请是清算平台针对预申请和该业务节点的汇总金额确定的，每个预申请对应至少一个垫资平台，如在步骤202的示例中，预申请中的业务额度为B银行2万元、B银行2万元、C银行5000元、C银行5000元，B银行预申请的子汇总差值2万元针对第一业务节点中的1万元和第二业务节点中的1万元生成B银行子预申请1万元和B银行子预申请1万元，确定第一业务节点对应B银行子预申请1万元，确定第二业务节点对应B银行子预申请1万元；B银行预申请的子汇总差值2万元、C银行5000元预申请的子汇总差值5000元和C银行5000元预申请的子汇总差值5000元针对第三业务节点中的3万元，确定第三业务节点对应B银行和C银行5000元子预申请3万元。预申请则是为了申请借款得到足够的资金以满足第一类业务和第二类业务正常营运的申请。

步骤304、所述业务节点根据自身的第二类业务，生成满足所述子预申请的要求的子申请；

其中，所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总；所述业务节点将前M个业务生成所述子申请，其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；所述业务节点将第M+1个业务上报至所述清算平台。

也就是说，业务节点将自身的第二类业务中各业务按照业务金额从大到小依次累加交易金额，当累加到第M笔第二类业务交易金额时，得到的业务金额小于子预申请的业务金额，当累加到第M+1笔第二类业务交易金额时，得到的业务金额大于子预申请的业务金额，则将累加到第M笔第二类业务交易金额得到的业务金额为子申请。业务节点将子申请和第M+1笔第二类业务交易信息上报至清算平台。

步骤305、所述业务节点将所述子申请上报至所述清算平台。

此处，业务节点将子申请上报至清算平台或将子申请和第M+1笔第二类业务交易信息上报至清算平台。

采用上述方法，业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总，可以保证在以此累计业务金额时，最后一笔业务为各业务交易金额最小值，使得业务节点将前M个业务生成的子申请中包含的申请款值最接近子预申请的申请款值。如此将第M+1个业务上报至清算平台与各业务节点上报的业务另生成补充申请，保证了申请款值的合理分配，合理的利用垫资资源。

基于上述图2和图3的流程，本申请实施例提供了又一种业务处理方法的流程，如图5所示，包括：

步骤501、业务节点计算自身第一类业务的业务金额和第二类业务的业务金额并上报至清算平台；

步骤502、清算平台接收到各业务节点的第一类业务的业务金额和第二类业务的业务金额生成预申请；

此处，清算平台接收到各业务节点的第一类业务的业务金额和第二类业务的业务金额，并将各业务节点的第一类业务的总业务金额和第二类业务的总业务金额做差得到的差值为汇总差值，该汇总差值为需要申请借款的资金金额，根据汇总差值和垫资平台的优先级以及单笔请款上限等信息，生成对应垫资平台的预申请。

步骤503、清算平台根据各业务节点的第一类业务的业务金额和第二类业务的业务金额生成子预申请；

此处，确定预申请对应的垫资平台及预申请之后。再根据各业务节点的第一类业务的业务金额和第二类业务的业务金额，将每个业务节点的第一类业务的业务金额和第二类业务的业务金额做差得到相应的差值，根据该差值确定业务节点对应的子预申请。

步骤504、各业务节点接收到清算平台发送的子预申请后生成子申请；

此处，各业务节点接收到子预申请后，根据第二类业务的汇总信息将第二类业务的业务金额依照从大到小依次排列累加，直到累加到第M笔业务时，累加金额等于子预申请，则将得到的子申请的业务金额等于这M笔业务的业务金额总和，且等于子预申请的业务金额；若直到累加到第M笔业务时累加金额小于子预申请且累加到第M+1笔业务时累加金额大于子预申请，则得到的子申请的业务金额等于这M笔业务的业务金额总和，且小于子预申请的业务金额。

步骤505、各业务节点将子申请上报至清算平台；

此处，各业务节点将子申请上报至清算平台，若有步骤504中累加到第M笔业务时累加金额小于子预申请且累加到第M+1笔业务时累加金额大于子预申请的情况，则该业务节点将子申请和第M+1笔业务一起上报至清算平台。

步骤506、清算平台接收到各业务节点上报的子申请后得到总申请；

此处，清算平台接收到各业务节点上报的子申请后，根据各子申请对应的子预申请相应的预申请进行整合，得到总申请，若有业务节点上报步骤504中的第M+1笔业务时，则将上报各业务节点上报的第M+1笔业务汇总得到补充申请。

步骤507、清算平台将各总申请分别发送至总申请相对的预申请对应的垫资平台；

此处，将各总申请分别发送到各总申请相对的预申请对应的垫资平台，将补充申请发送至为该补充申请匹配的垫资平台。

步骤508、垫资平台是否给予申请成功响应；

此处，判断垫资平台是否返回申请成功响应，若是申请成功，则执行步骤510，否则执行步骤509。

步骤509、清算平台重新确定垫资平台；

此处，若该总申请对应的垫资平台申请失败或无返回申请响应，则重新为该总申请匹配垫资平台，发送到该垫资平台请求垫资。

步骤510、接收申请资金转账。

基于同样的构思，本发明实施例提供一种业务处理装置，图6为本申请实施例提供的一种业务处理装置示意图，如图6示，包括：

确定模块601，用于所述清算平台根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定针对至少一个垫资平台的预申请，所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；还用于针对每个预申请，所述清算平台确定处理所述预申请的业务节点及该业务节点对应的子预申请；

处理模块602，用于针对处理所述预申请的业务节点上报的子申请，得到所述预申请对应的总申请；

收发模块603，用于将所述总申请发送至所述预申请对应的垫资平台，并在接收到所述总申请处理成功的指示后，通知所述业务节点；所述子申请是该业务节点基于自身的第二类业务生成的且满足所述子预申请的要求。

在一种可能的设计中，所述确定模块601还用于：根据各业务节点上报的第一类业务的汇总信息和第二类业务的汇总信息，确定第一类业务与第二类业务之间的汇总差值；根据所述汇总差值和各垫资平台的属性信息，确定至少一个垫资平台的预申请；每个预申请具有对应的子汇总差值，各子汇总差值用于满足所述汇总差值。

在一种可能的设计中，所述确定模块601具体用于：所述清算平台根据各业务节点的第二类业务的汇总信息，确定处理所述预申请的业务节点及该业务节点对应的子预申请，其中，处理所述预申请的业务节点的第二类业务的汇总信息不小于所述预申请对应的子汇总差值；处理所述预申请的业务节点的子预申请对应的和等于所述预申请对应的子汇总差值。

在一种可能的设计中，所述处理模块602具体用于：接收所述业务节点上报的子申请和第M+1个业务；其中所述子申请是所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总的M个业务得到的；其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；将处理所述预申请的业务节点上报的各子申请进行汇总，得到所述预申请对应的总申请；将各预申请的第M+1业务汇总，得到至少一个垫资平台对应的补充申请并将所述补充申请发送至对应的垫资平台；所述补充申请的业务金额不小于各总申请与各预申请的业务金额的差额。

在一种可能的设计中，所述收发模块603还用于：所述清算平台若未接收到所述总申请处理成功的指示，则重新确定所述总申请对应的垫资平台。

在一种可能的设计中，所述处理模块602还用于：所述清算平台根据所述总申请中涉及的第二类业务，生成记账文件；其中，所述记账文件包括文件头、文件体和文件尾，其中，所述文件头中包括所述总申请中涉及的第二类业务的交易总金额和交易总笔数；所述文件体中分多个文件包，每个文件包对应同一垫资平台，所述文件包中记录所述每个文件包对应的第二类业务的明细；每个文件尾中包括该垫资平台涉及的第二类业务的交易总金额和交易总笔数。

基于同样的构思，本发明实施例提供一种业务处理装置，图7为本申请实施例提供的一种业务处理装置示意图，如图7示，包括：

处理模块701，用于业务节点根据自身接收的第一类业务和第二类业务，得到所述业务节点的第一类业务的汇总信息和第二类业务的汇总信息；

收发模块702，用于所述业务节点将所述第一类业务的汇总信息和所述第二类业务的汇总信息上报至清算平台；还用于所述业务节点接收所述清算平台发送的子预申请，所述子预申请是所述清算平台针对至少一个垫资平台的预申请确定的；所述预申请用于满足各业务节点执行各自的第一类业务和第二类业务；

所述处理模块701还用于，所述业务节点根据自身的第二类业务，生成满足所述子预申请的要求的子申请；

所述收发模块702还用于，所述业务节点将所述子申请上报至所述清算平台。

在一种可能的设计中，所述处理模块701具体用于：所述业务节点分别对自身的第一类业务和自身的第二类业务按如下方式进行汇总：针对同一类业务中各业务的交易时间，确定各业务所在的主组，其中，每个主组中的交易时间属于同一时段；针对每个主组，根据所述主组内的业务的数量划分所述主组中的各业务所在的子组；其中，每个子组中业务的数量不超过第一阈值，所述第一阈值是根据进程的处理量确定的；并行对多个子组进行处理，得到每个子组的汇总信息从而得到各主组的汇总信息。

在一种可能的设计中，所述处理模块701具体用于：所述业务节点将自身的第二类业务中各业务按照业务金额从大到小依次汇总；所述业务节点将前M个业务生成所述子申请，其中前M个业务汇总的业务金额之和小于所述子预申请的要求且前M+1个业务汇总的业务金额之和大于所述子预申请的要求；所述业务节点将第M+1个业务上报至所述清算平台。

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

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

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

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

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