CN113362166A - 业务处理方法及装置 - Google Patents

Abstract

本申请实施例提供一种业务处理方法及装置，该方法包括：接收终端设备发送的第一业务对应的第一业务请求，第一业务请求包括待请求对象的第一数量和第一账户的标识。根据第一账户的标识和第一业务的标识，在预设数据库中查询获取第一账户在第一业务下的第一剩余对象数量。确定第一业务对应的业务类型，并根据第一账户的标识和业务类型，在预设数据库中查询获取第一账户在业务类型下的第二剩余对象数量。根据第一数量、第一剩余对象数量和第二剩余对象数量，对第一业务请求进行业务处理。按照第一业务所属的业务类型对第一业务进行相应的处理，这使得同一业务类型下的多个业务复用相同的业务处理方法，降低了业务处理冗余度，提高了业务处理效率。

Description

业务处理方法及装置

技术领域

本申请实施例涉及自动控制技术，尤其涉及一种业务处理方法及装置。

背景技术

在业务系统中，为客户提供了多种业务。针对客户的各种业务请求，业务系统为各种业务提供有相应的业务处理方法，用以响应各种业务请求。

目前，在现有技术中，通常针对各种业务均独立设置有各自对应的业务处理方法，即针对各业务自身的具体情况作出相应的业务处理。例如，对于金融业务中的银团贷款业务和双边贷款业务来说，银行针对银团贷款业务和双边贷款业务，均独立设置有各自对应的业务处理方法。

然而，当多个业务的特点比较相似时，对应的针对该多个业务的业务处理方法也有相同之处，现有技术中为多个业务独立设置业务处理方法，存在业务处理冗余度过高的问题。

发明内容

本申请实施例提供一种业务处理方法及装置，以克服业务处理冗余度过高的问题。

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

接收终端设备发送的第一业务对应的第一业务请求，所述第一业务请求包括待请求对象的第一数量和第一账户的标识；

根据所述第一账户的标识和所述第一业务的标识，在预设数据库中查询获取所述第一账户在所述第一业务下的第一剩余对象数量；

确定所述第一业务对应的业务类型，并根据所述第一账户的标识和所述业务类型，在所述预设数据库中查询获取所述第一账户在所述业务类型下的第二剩余对象数量；

根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理。

在一种可能的设计中，所述根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理，包括：

判断所述第一数量是否小于或等于所述第一剩余对象数量；

若是，则根据所述第一数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

在一种可能的设计中，所述根据所述第一数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理，包括：

判断所述第一数量是否小于或等于所述第二剩余对象数量；

若是，则向所述第一账户分配所述第一数量的对象；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

在一种可能的设计中，所述向所述第一账户分配所述第一数量的对象，包括：

确定所述第一账户对应的第三剩余对象数量、以及所述第一账户所属的总账户对应的第四剩余对象数量；

在所述第一数量小于或等于所述第三剩余对象数量，以及所述第一数量小于或等于所述第四剩余对象数量时，向所述第一账户分配所述第一数量的对象。

在一种可能的设计中，所述向所述第一账户分配所述第一数量的对象之后，还包括：

分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量以及所述第四剩余对象数量减少所述第一数量。

在一种可能的设计中，所述方法还包括：

接收所述第一业务对应的第二业务请求，所述第二业务请求包括待归还对象的第二数量和所述第一账户的标识；

根据所述第二业务请求，分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量及所述第四剩余对象数量增加所述第二数量。

第二方面，本申请实施例提供另一种业务处理方法，包括：

接收终端设备发送的第一业务对应的业务创建请求，所述业务创建请求中包括第一账户的标识和所述第一账户在所述第一业务下的第一对象数量；

确定所述第一账户对应的第三对象数量，所述第一业务对应的业务类型、以及所述业务类型对应的第二对象数量；

根据所述业务创建请求创建所述第一业务，以及根据所述第一对象数量更新所述第二对象数量及所述第一账户对应的第三对象数量。

在一种可能的设计中，所述根据所述业务创建请求创建所述第一业务，包括：

判断是否存在所述第一账户对应的已创建业务，所述第一业务与所述已创建业务的业务类型相同；

若是，则创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联；

若否，则创建所述第一账户对应的业务类型、以及创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联。

在一种可能的设计中，所述创建所述第一账户对应的业务类型、以及创建所述第一账户对应的所述第一业务之后，包括：

若不存在所述第一账户对应的总账户，则创建所述总账户、确定所述总账户对应的第四对象数量，并将所述第一账户与所述总账户关联。

在一种可能的设计中，所述根据所述第一对象数量更新所述第二对象数量及所述第一账户对应的第三对象数量，包括：

判断所述第一对象数量是否大于所述第二对象数量；

若是，则更新所述第二对象数量、所述第三对象数量及所述第四对象数量。

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

接收模块，用于接收终端设备发送的第一业务对应的第一业务请求，所述第一业务请求包括待请求对象的第一数量和第一账户的标识；

查询模块，用于根据所述第一账户的标识和所述第一业务的标识，在预设数据库中查询获取所述第一账户在所述第一业务下的第一剩余对象数量；

第一确定模块，用于确定所述第一业务对应的业务类型，所述查询模块还用于根据所述第一账户的标识和所述业务类型，在所述预设数据库中查询获取所述第一账户在所述业务类型下的第二剩余对象数量；

第一处理模块，用于根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理。

在一种可能的设计中，所述第一处理模块具体用于：

判断所述第一数量是否小于或等于所述第一剩余对象数量；

若是，则根据所述第一数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

在一种可能的设计中，所述第一处理模块具体用于：

判断所述第一数量是否小于或等于所述第二剩余对象数量；

若是，则向所述第一账户分配所述第一数量的对象；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

在一种可能的设计中，所述第一处理模块具体用于：

确定所述第一账户对应的第三剩余对象数量、以及所述第一账户所属的总账户对应的第四剩余对象数量；

在所述第一数量小于或等于所述第三剩余对象数量，以及所述第一数量小于或等于所述第四剩余对象数量时，向所述第一账户分配所述第一数量的对象。

在一种可能的设计中，向所述第一账户分配所述第一数量的对象之后，所述第一处理模块还用于：

分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量以及所述第四剩余对象数量减少所述第一数量。

在一种可能的设计中，所述第一处理模块还用于：

接收所述第一业务对应的第二业务请求，所述第二业务请求包括待归还对象的第二数量和所述第一账户的标识；

根据所述第二业务请求，分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量及所述第四剩余对象数量增加所述第二数量。

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

获取模块，用于接收终端设备发送的第一业务对应的业务创建请求，所述业务创建请求中包括第一账户的标识和所述第一账户在所述第一业务下的第一对象数量；

第二确定模块，用于确定所述第一账户对应的第三对象数量，所述第一业务对应的业务类型、以及所述业务类型对应的第二对象数量；

第二处理模块，用于根据所述业务创建请求创建所述第一业务，以及更新模块，用于根据所述第一对象数量更新所述第二对象数量及所述第一账户对应的第三对象数量。

在一种可能的设计中，所述第二处理模块具体用于：

判断是否存在所述第一账户对应的已创建业务，所述第一业务与所述已创建业务的业务类型相同；

若是，则创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联；

若否，则创建所述第一账户对应的业务类型、以及创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联。

在一种可能的设计中，所述第二处理模块具体用于：

若不存在所述第一账户对应的总账户，则创建所述总账户、确定所述总账户对应的第四对象数量，并将所述第一账户与所述总账户关联。

在一种可能的设计中，所述更新模块具体用于：

判断所述第一对象数量是否大于所述第二对象数量；

若是，则更新所述第二对象数量、所述第三对象数量及所述第四对象数量。

第五方面，本申请实施例提供一种业务处理设备，包括：

存储器，用于存储程序；

处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如第一方面任一项所述的业务处理方法，或者，如第二方面任一项所述的业务处理方法。

第六方面，本申请实施例提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如第一方面任一项所述的业务处理方法，或者，如第二方面任一项所述的业务处理方法。

第七方面，本申请实施例提供一种计算机程序产品，所述程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行如第一方面任一项所述的业务处理方法，或者，如第二方面任一项所述的业务处理方法。

本申请实施例提供一种业务处理方法及装置，该方法包括：接收终端设备发送的第一业务对应的第一业务请求，第一业务请求包括待请求对象的第一数量和第一账户的标识。根据第一账户的标识和第一业务的标识，在预设数据库中查询获取第一账户在第一业务下的第一剩余对象数量。确定第一业务对应的业务类型，并根据第一账户的标识和业务类型，在预设数据库中查询获取第一账户在业务类型下的第二剩余对象数量。根据第一数量、第一剩余对象数量和第二剩余对象数量，对第一业务请求进行业务处理。其中，按照第一业务所属的业务类型对第一业务进行相应的处理，这使得同一业务类型下的多个业务复用相同的业务处理方法，这在降低了业务处理冗余度的同时，提高了业务处理效率。

附图说明

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

图1为本申请实施例提供的一种应用场景示意图

图2为本申请实施例提供的业务处理方法的流程图一；

图3为本申请实施例提供的银行业务分类的示意图；

图4为本申请实施例提供的业务处理方法的流程图二；

图5为本申请实施例提供的第一账户对应的已授信业务的示意图；

图6为本申请实施例提供的第一账户对应的更新后已授信业务的示意图一；

图7为本申请实施例提供的第一账户对应的更新后已授信业务的示意图二；

图8为本申请实施例提供的业务处理方法的流程图三；

图9为本申请实施例提供的总账户对应的已授信业务情况的示意图；

图10为本申请实施例提供的业务处理方法的流程图四；

图11为本申请实施例提供的一种业务处理装置的结构示意图；

图12为本申请实施例提供的另一种业务处理装置的结构示意图；

图13为本申请实施例提供的业务处理设备的硬件结构示意图。

具体实施方式

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

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

为了便于理解本申请的技术方案，首先对本申请所涉及的相关概念进行介绍：

业务：用于指示各行业中需要处理的事务，或各行业向客户提供的服务、产品等。例如，银行等金融机构向客户提供了各种金融业务，如贷款、担保等业务。

接下来，以金融业务为例，对金融业务所涉及的相关概念进行介绍：

授信：银行向客户直接提供资金，或在相关金融业务中对客户可能产生的赔偿、支付责任做出的保证。

授信额度：通过客户资信状况、信用需求、风险与收益等因素，对客户核定的未来一段期限内银行愿意和能够承受的各类信贷业务和非信贷业务的最高信用风险限额。

用信：根据银行给予客户所用金融业务的授信额度，客户在后续金融业务交易中对所用金融业务的授信额度的使用过程。

需要说明的是，银行在为客户办理各种金融业务之前，均会为客户所办理的各金融业务确定一个授信额度。后续，在客户进行各种金融业务的实际交易中，为避免交易累计额超出授信额度的风险，银行会根据客户所办理金融业务对应的授信额度、可用额度及本次交易额以完成本次金融业务的业务处理。

因此，在金融业务处理的过程包括两部分，分别为：授信过程和用信过程。

接下来，对现有技术、现有技术存在的问题以及本申请的技术构思进行介绍：

目前，在相关技术中，银行针对各种金融业务均独立设置有各自对应的业务处理方法。例如，针对银团贷款业务和双边贷款业务，均独立设置有各自对应的业务处理方法，即这两种业务处理方法之间没有任何联系。考虑到在实际业务处理时作出合理的业务处理，需要结合各个相关业务的具体情况。

然而，当多个业务的特点比较相似时，对应的针对该多个业务的业务处理方法也有相同之处，现有技术中为多个业务独立设置业务处理方法，存在业务处理冗余度过高的问题。

基于上述存在的问题，本申请提出了如下的技术构思：考虑到对某一客户进行用信处理，需要综合考虑该客户下其他金融业务的情况，从而对本次金融业务作出合理的处理，因此，本申请提出一种业务处理方法考虑对交易中的金融业务根据业务类型进行归类，并将各业务与各业务对应的业务类型建立关联关系。在创建业务或进行业务处理的过程中，若存在该业务对应的业务类型时，则无需再重复创建业务类型，只需给业务类型下添加该业务即可。同时，在对该业务的处理过程中不仅要考虑该业务情况，而且要考虑与该业务对应的业务类型下的其他业务的情况。因此，这在降低了业务处理冗余度的同时，提高了业务处理效率。

下面，结合图1，介绍本申请实施例的应用场景。

图1为本申请实施例提供的一种应用场景示意图。请参见图1，终端设备10、服务器20和数据库30。其中，终端设备10可以为支持信息通信的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等。

服务器20可以是提供这种业务处理的设备，例如对用户通过终端设备10发送的业务请求进行处理，服务器20向数据库30发送业务查询指令并根据从数据库30中获取查询结果，服务器20对用户提出的业务请求作出业务处理。

下面，通过具体实施例对本申请所示的技术方案进行详细说明。需要说明的是，如下实施例可以单独存在，也可以相互结合，对于相同或相似的内容，在不同的实施例中不再重复说明。

为了便于理解本申请的技术方案，下面结合具体的实施例首先对本申请所提供的授信过程对应的业务处理方法进行详细介绍，图2为本申请实施例提供的业务处理方法的流程图一。

如图2所示，该方法包括：

S201、接收终端设备发送的第一业务对应的业务创建请求，业务创建请求中包括第一账户的标识和第一账户在第一业务下的第一对象数量。

在本申请实施中的执行主体可以为具有业务处理功能的服务器，本实施例对此执行主体的具体实现不做限定，只要其可以进行业务处理即可。

终端设备为可以提交业务请求的设备，例如可以为电脑，平板及手机等设备。

业务创建请求用于请求为第一账户创建第一业务，且创建的第一业务中包括的对象数量为第一对象数量。

其中，第一账户的标识例如可以为一组由数字和/或字符组成的序列。

需要说明的是，本实施例只是对第一账户的标识进行示例性的介绍，并非对第一账户的标识的限定。

第一对象数量为请求创建的第一业务中包括的对象数量。例如，当第一业务为贷款业务时，第一对象数量可以为贷款金额。

例如，在用户需要通过账户1贷款50万时，用户可以控制终端设备向服务器发送业务创建请求，业务创建请求中包括账户1的标识和50万。

S202、确定第一账户对应的第三对象数量，第一业务对应的业务类型、以及业务类型对应的第二对象数量。

第三对象数量是指为第一账户对应的授信总金额。

一个业务类型可以对应多个业务，每个业务仅对应一个业务类型。

业务类型为根据各个业务的业务特点做出的类型划分。例如，银团贷款业务、双边定期贷款业务、双边循环贷款业务的主要业务内容均为贷款业务，则该三种业务的业务类型均为贷款类。

每种业务有其对应的对象数量，业务类型对应的第二对象数量大于或等于该业务类型下的各业务对应的对象数量。

例如，业务类型1对应业务1和业务2，则业务类型1对应的第二对象数量大于或等于业务1对应的对象数量，以及，业务类型1对应的第二对象数量大于或等于业务2对应的对象数量。

再例如，假设业务类型为贷款类业务，贷款类的业务包括银团贷款、双边定期贷款，贷款类业务对应的可贷款总金额为50万，则银团贷款和双边定期贷款的可贷款总金额均小于或等于50万，且在实际贷款中，银团贷款和双边定期贷款的实际贷款金额之和小于或等于50万。

接下来，对银行所提供的各种业务进行示例性的介绍：在银行提供的金融业务中可以根据各个业务的特点对业务进行归类。具体的，对银行金融业务的分类例如可以如图3所示的分类方法，图3为本申请实施例提供的银行业务分类的示意图。

如图3所示，该银行的金融业务具体分为6大类，分别为贷款类1000、贸易融资类2000、担保类3000、货币市场4000、衍生品类5000及投资6000。其中，每个业务类型包含由1种或多种金融业务。例如，贷款类1000中包括5种业务，分别为银团贷款1001、双边定期贷款1002、双边循环贷款1003、抵押品贷款1004及零售透支1005。

对本申请实施例中的业务的具体分类均以图3为例，进行说明。

第二对象数量为业务类型中包括的对象数量。例如，当业务类型为贷款类时，第二对象数量可以为贷款类对应的贷款授信金额。

在一种可能的实现方式中，服务器向预设数据库发送业务查询指令，预设数据库在接收到业务查询请求后，向服务器返回第一业务对应的业务类型，以及业务类型对应的第二对象数据。

S203、根据业务创建请求创建第一业务，以及根据第一对象数量更新第二对象数量及第一账户对应的第三对象数量。

在服务器创建第一业务之前，服务器会在预设数据库中查询下第一业务对应的业务类型。预设数据库返回业务类型后，服务器判断在第一账户中是否存在该业务类型。若存在，则服务器只需要创建第一业务。若不存在，服务器则需要在第一账户中同时创建业务类型及第一业务。

接下来，对根据第一对象数量更新第二对象数量及第一账户对应的第三对象数量的两种可能的实现方式进行说明。

在一种可能的实现方式中，当确定在第一账户中存在该业务类型时，只需要为第一账户在创建第一业务。当第一对象数量小于或等于第二对象数量，且小于或等于第三对象数量时，无需更新第二对象数量及第三对象数量。当第一对象数量大于第二对象数量时，将第二对象数量进行增加第一数值的操作，得到更新后的第二对象数量。其中，第一数值为大于或等于第一差值的数值。其中，第一差值为第一对象数量与第二对象数量的差值。判断更新后的第二对象数量与第三对象数量的大小，确定对第三对象数量的更新操作。若更新后的第二对象数量小于或等于第三对象数量，则无需更新第三对象数量。若更新后的第二对象数量大于第三对象数量，则将第三对象数量进行增加第二数值的操作，得到更新后的第三对象数量。其中，第二数值为大于或等于第二差值的数值。其中，第二差值为更新后的第二对象数量与第三对象数量的差值。

在另一种可能的实现方式中，当确定在第一账户中不存在该业务类型时，则需要在第一账户中同时创建业务类型及第一业务。具体的，在为第一账户中创建业务类型时，同时设置业务类型对应的第二对象数量，其中，第二对象数量小于或等于第三对象数量，同时第二对象数量大于或等于第一对象数量。接下来，在第一账户该业务类型下创建第一业务的同时，设置第一业务对应的第一对象数量。

在本实施例中，只是对根据第一对象数量更新第二对象数量及第一账户对应的第三对象数量的实现方法进行示例性的介绍，并不是对根据第一对象数量更新第二对象数量及第一账户对应的第三对象数量的实现方法做以限定，对根据第一对象数量更新第二对象数量及第一账户对应的第三对象数量的实现方法可以根据实际需求进行选择。

本申请实施例提供的业务处理方法，该方法包括：接收终端设备发送的第一业务对应的业务创建请求，业务创建请求中包括第一账户的标识和第一账户在第一业务下的第一对象数量。确定第一账户对应的第三对象数量，第一业务对应的业务类型、以及业务类型对应的第二对象数量。根据业务创建请求创建第一业务，以及根据第一对象数量更新第二对象数量及第一账户对应的第三对象数量。其中，在创建第一业务的过程中，通过将第一业务对应的业务类型进行关联。因此，在每创建一个新业务时，会首先查询在该第一账户中是否存在该新业务对应的业务类型。若存在，则无需对此业务类型进行重复创建。同时，将第一业务与第一业务的业务类型进行关联可以更高效、方便的了解到同业务类型下其他业务的情况，这为后续通过参考同业务类型下其他业务的情况对第一业务进行合理的业务处理提供了直接的参考依据。

在上述实施例的基础上，下面结合一个具体的实施例对本申请提供的授信过程对应的业务处理方法进行进一步的介绍，结合图4及图7进行介绍，图4为本申请实施例提供的业务处理方法的流程图二，图5为本申请实施例提供的第一账户对应的已授信业务的示意图，图6为本申请实施例提供的第一账户对应的更新后已授信业务的示意图一，图7为本申请实施例提供的第一账户对应的更新后已授信业务的示意图二。

如图4所示，该方法包括：

S401、接收终端设备发送的第一业务对应的业务创建请求，业务创建请求中包括第一账户的标识和第一账户在第一业务下的第一对象数量。

S402、确定第一业务对应的业务类型、以及业务类型对应的第二对象数量。

其中，步骤S401与S201的实现方式类似，以及，步骤S402与S202的实现方式类似，此处不再赘述。

S403、判断是否存在第一账户对应的已创建业务，其中，第一业务与已创建业务的业务类型相同，若是，则执行S404，若否，则执行S405。

在本实施例中，已创建业务是指与在第一账户中已经创建的业务，且与第一业务属于同业务类型的业务。

在一种可能的实现方式中，服务器根据第一业务的业务类型，在预设数据库中查询第一账户中是否存在该业务类型对应的一个或多个已创建业务，预设数据库将查询结果返回给服务器，其中查询结果例如为已创建业务的名称或无，或者，查询结果也可以为存在或不存在。当服务器确定在第一账户中存在已创建业务，则执行步骤S404；当服务器确定在第一账户中不存在已创建业务，则执行步骤S405。

S404、创建第一账户对应的第一业务，并将第一业务与业务类型关联。

在一种可能的实现方式中，服务器在第一账户中创建第一业务，并在第一业务与第一业务对应的业务类型之间建立关联关系，即将第一业务作为该业务类型下的子业务添加到该业务类型下。

例如，如图5所示，服务器经过查询确定第一账户对应的已授信业务类型包括：贷款类1000、融资贸易类2000、货币市场类4000及投资类6000。其中，在贷款类1000中已授信的业务为双边定期贷款1002、双边循环贷款1003及抵押品贷款1004；贸易融资类2000中已授信的业务为出口类2002；货币市场类4000中已授信的业务为同业拆出4001；投资类6000中已授信的业务为债券买卖6001。

若创建业务请求对应的第一业务具体为银团贷款1001，如图5所示，在第一账户对应的已授信业务中存在与银团贷款1001同业务类型的业务(如，双边定期贷款1002、双边循环贷款1003及抵押品贷款1004)，因此表明在第一账户中存在第一账户对应的已创建业务。接下来，服务器为第一账户创建银团贷款1001，并将银团贷款1001作为子业务归于贷款类业务中。因此，第一账户对应的已授信业务得到更新，更新后第一账户所包括的业务如图6所示。

S405、创建第一账户对应的业务类型、以及创建第一账户对应的第一业务，并将第一业务与业务类型关联。

在一种可能的实现方式中，服务器为第一账户中创建业务类型、第一业务，并在第一业务与业务类型之间建立关联关系，即将第一业务作为该业务类型下的子业务添加到该业务类型下。

例如，当第一业务为银行保函业务3001时，对照图5可以确定的是：在第一账户对应的已授信业务中不存在与银行保函业务3001同业务类型的业务，因此表明在第一账户中不存在第一账户对应的已创建业务。接下来，服务器在第一账户对应的已授信业务中创建担保类3000，其中，担保类3000为银行保函业务3001对应的业务类型。之后，服务器为第一账户创建银行保函业务3001，并银行保函业务3001与担保类3000之间建立关联关系，即将第一业务作为该业务类型下的子业务添加到该业务类型下。因此，第一账户对应的已授信业务得到更新，更新后第一账户所包括的业务如图7所示。

S406、判断是否存在第一账户对应的总账户，若否，则执行S407，若是，则执行S408。

在本实施例中，总账户是指包括有一个或多个子账户的账户，其中，总账户分别与一个或多个子账户具有关联关系。

在一种可能的实现方式中，服务器判断是否存在与第一账户具有关联关系的账户。

若存在第一账户对应的总账户，则无需重复为第一账户创建总账户；若不存在第一账户对应的总账户时，服务器则执行S407。

S407、创建总账户、确定所述总账户对应的第四对象数量并将第一账户与总账户关联。

第四对象数量为第一账户对应的总账户的授信总金额。

在本实施例中，服务器创建一个总账户，为总账户确定第四对象数量，并将在第一账户与总账户之间建立关联关系，即将第一账户作为该总账户下的子账户添加到该总账户下。

S408、判断第一对象数量是否大于第二对象数量，若否，则执行S409，若是，则执行S410。

在授信业务中，第一对象数量、第二对象数量、第三对象数量及第四对象数量的大小关系，必须满足第一对象数量必须小于或等于第二对象数量，第二对象数量必须小于或等于第三对象数量，以及，第三对象数量必须小于或等于第四对象数量。

因此，在给第一账户对应的第一业务的设定第一对象数量时，需要根据第一对象数量的大小，确定是否需要更新第二对象数量、第三对象数量及第四对象数量。

S409、不更新第二对象数量、第三对象数量及第四对象数量。

在本实施例中，当第一对象数量小于或等于第二对象数量时，则不更新第二对象数量、第三对象数量及第四对象数量。

S410、更新第二对象数量、第三对象数量及第四对象数量。

接下来，对第二对象数量、第三对象数量及第四对象数量进行更新的一种可能的实现方式进行说明。

在一种可能的实现方式中，当第一对象数量大于第二对象数量时，将第二对象数量进行增加第一数值的操作，得到更新后的第二对象数量。其中，第一数值为大于或等于第一差值的数值。其中，第一差值为第一对象数量与第二对象数量的差值。判断更新后的第二对象数量与第三对象数量的大小，确定对第三对象数量的更新操作。若更新后的第二对象数量小于或等于第三对象数量，则无需更新第三对象数量。若更新后的第二对象数量大于第三对象数量，则将第三对象数量进行增加第二数值的操作，得到更新后的第三对象数量。其中，第二数值为大于或等于第二差值的数值。其中，第二差值为更新后的第二对象数量与第三对象数量的差值；判断更新后的第三对象数量与第四对象数量的大小，确定对第三对象数量的更新操作。若更新后的第三对象数量小于或等于第四对象数量，则无需更新第四对象数量。若更新后的第三对象数量大于第四对象数量，则将第四对象数量进行增加第三数值的操作，得到更新后的第四对象数量。其中，第三数值为大于或等于第三差值的数值。其中，第三差值为更新后的第三对象数量与第四对象数量的差值。

在本实施例中，只是对第二对象数量、第三对象数量及第四对象数量进行更新的一种可能的实现方式进行示例性的说明，并不是对第二对象数量、第三对象数量及第四对象数量进行更新的实现方式做以限制，对第二对象数量、第三对象数量及第四对象数量进行更新的实现方式可以根据实际需求进行选择。

本申请实施例提供的业务处理方法，将第一业务与第一业务的业务类型进行关联可以更高效、方便的了解到同业务类型下其他业务的情况，这为后续通过参考同业务类型下其他业务的情况对第一业务进行合理的业务处理提供了直接的参考依据。

在上述实施例的基础上，下面结合一个具体的实施例对本申请提供的用信过程对应的业务处理方法进行介绍，结合图8至图9进行介绍，图8为本申请实施例提供的业务处理方法的流程图三，图9为本申请实施例提供的总账户对应的已授信业务情况的示意图。

如图8所示，该方法包括：

S801、接收终端设备发送的第一业务对应的第一业务请求，第一业务请求包括待请求对象的第一数量和第一账户的标识。

第一业务请求中包括待请求对象的第一数量和第一账户的标识。其中，待请求对象可以为交易币种。其中，第一数量为第一账户在第一业务上对应的请求交易额度，例如，第一账户在双边定期贷款业务上请求贷款额度为30万。

在本实施例中，服务器接收终端设备发送的第一业务对应的第一业务请求。

在一种可能的实现方式中，第一账户的标识例如可以为一组由数字和/或字符组成的序列。

在本实施例中，以第一账户对应的已授信业务如图9所示为例，对用信过程对应的业务处理方法进行介绍。

如图9所示，总账户下包括两个子账户，分别为第一账户及第二账户。其中，第一账户对应的已授信业务类型包括三种，分别为贷款类1000、贸易融资类2000以及担保类3000。其中，第一账户对应的业务类型1000中包括三个业务，分别为：双边定期贷款1002、双边循环贷款1003以及抵押品贷款1004；第一账户对应的贸易融资类2000中包括一个业务，即海外代付2004；第一账户对应的担保类3000中包括一个业务，即银行保函3001。

第二账户对应的已授信业务类型包括两种，分别为贷款类1000和投资类型6000。其中，第二账户对应的业务类型1000中包括两个业务，分别为：双边定期贷款1002以及双边循环贷款1003；第二账户对应的投资类6000中包括一个业务，即债券买卖6001。

例如，第一账户通过控制终端设备向服务器发送银行保函3001对应的业务请求，服务器接收到终端设备发送的为第一账户办理交易金额为10万的银行保函3001业务的请求。

需要说明的是，在本实施例中以第一业务为银行保函3001为例，对业务处理方法进行介绍。

S802、根据第一账户的标识和第一业务的标识，在预设数据库中查询获取第一账户在第一业务下的第一剩余对象数量。

第一业务下的第一剩余对象数量是指第一账户在第一业务中的可用额度。

在本实施例中，服务器向预设数据库中发送业务查询指令，其中查询指令中包括第一账户的标识和第一业务的标识。预设数据库收到业务查询指令后，根据第一账户的标识，查询到第一账户。接下来，根据第一业务的标识，预设数据库查询第一账户在第一业务下的第一剩余对象数量并将第一业务下的第一剩余对象数量返回给服务器。

例如，服务器向预设数据库发送业务查询请求，其中，业务请求中包括第一账户的标识以及银行保函3001的标识。预设数据库根据业务查询请求，向服务器返回第一账户在银行保函3001的可用余额为30万。

S803、确定第一业务对应的业务类型，并根据第一账户的标识和业务类型，在预设数据库中查询获取第一账户在业务类型下的第二剩余对象数量。

第二剩余对象数量为业务类型的可用额度。

在本实施例中，服务器根据图3所示的业务类型与第一业务的关联关系，确定第一业务对应的业务类型。例如根据图3所示，可以看出银行保函3001对应的业务类型为担保类3000。同时，服务器向预设数据库发送业务查询请求，其中，业务请求中包括第一账户的标识和业务类型。预设数据库向服务器返回第一账户在业务类型下的第二剩余对象数量。

S804、根据第一数量、第一剩余对象数量和第二剩余对象数量，对第一业务请求进行业务处理。

在一种可能的实现方式中，首先，判断第一数量与第一剩余对象数量的大小关系，来确定服务器接下来所执行的步骤。当第一数量大于第一剩余对象数量时，则服务器向终端设备发送拒绝信息；

当第一数量小于或等于第一剩余对象数量时，则服务器继续判断第一数量与第二剩余对象数量的大小。当第一数量大于第二剩余对象数量时，则服务器向终端设备发送拒绝信息；当第一数量小于或等于第二剩余对象数量时，则服务器确认继续为第一账户提供后续的业务处理，其中，后续的业务处理例如可以为第一账户放款，并将第一剩余对象数量更新为第一剩余对象数量减去第一数量后的数值，以及将第二剩余对象数量更新为第二剩余对象数量减去第一数量后的数值等等。

在本实施例中，只是对后续的业务处理方法进行示例性的介绍，并不是对后续的业务处理方法做以限制，对后续的业务处理方法可以根据实际需求来选择即可。

本申请实施例提供的业务处理方法，包括：接收终端设备发送的第一业务对应的第一业务请求，第一业务请求包括待请求对象的第一数量和第一账户的标识。根据第一账户的标识和第一业务的标识，在预设数据库中查询获取第一账户在第一业务下的第一剩余对象数量。确定第一业务对应的业务类型，并根据第一账户的标识和业务类型，在预设数据库中查询获取第一账户在业务类型下的第二剩余对象数量。根据第一数量、第一剩余对象数量和第二剩余对象数量，对第一业务请求进行业务处理。其中，按照第一业务所属的业务类型对第一业务进行相应的处理，这使得同一业务类型下的多个业务复用相同的业务处理方法，这在降低了业务处理冗余度的同时，提高了业务处理效率。

在上述实施例的基础上，下面结合一个具体的实施例对本申请提供的用信过程对应的业务处理方法进行进一步的介绍，结合图10进行介绍，图10为本申请实施例提供的业务处理方法的流程图四。

如图10所示，该方法包括：

S1001、接收终端设备发送的第一业务对应的第一业务请求，第一业务请求包括待请求对象的第一数量和第一账户的标识。

S1002、根据第一账户的标识和第一业务的标识，在预设数据库中查询获取第一账户在第一业务下的第一剩余对象数量。

S1003、确定第一业务对应的业务类型，并根据第一账户的标识和业务类型，在预设数据库中查询获取第一账户在业务类型下的第二剩余对象数量。

其中，步骤S1001与S801的具体实现方式类似，步骤S1002与S802的具体实现方式类似，以及，步骤S1003与S803的具体实现方式类似，此处不再赘述。

S1004、判断第一数量是否小于或等于第一剩余对象数量，若是，则执行S1005，若否，则执行S1010。

在本实施例中，服务器通过判断第一数量与第一剩余对象数量的大小，来确定下一步的执行步骤。具体的，当服务器确定第一数量小于或等于第一剩余对象数量时，则执行步骤S1005；当服务器确定第一数量大于第一剩余对象数量时，则执行步骤S1010。

需要强调说明的一点是，每一步交易成功的前提条件是：请求交易额度一定要小于或等于可用额度，即第一数量一定要小于或等于第一剩余对象数量，第一数量一定要小于或等于第二剩余对象数量。

S1005、判断第一数量是否小于或等于第二剩余对象数量，若是，则执行S1006，若否，则执行S1009。

在本实施例中，当服务器确定第一数量小于或等于第一剩余对象数量时，则服务器会继续判断第一数量是否小于或等于第二剩余对象数量。若是，则执行S1006，若否，则执行S1009。

S1006、确定第一账户对应的第三剩余对象数量、以及第一账户所属的总账户对应的第四剩余对象数量。

针对每个账户来说，第三对象数量为该账户对应的总授信额度；第三剩余对象数量为该账户对应的可用授信额度。

第四对象数量是指总账户的总授信额度；第四剩余对象数量为总账户的可用授信额度。

需要说明的一点是，每个账户的第三对象数量小于或等于总账户的第四对象数量。

进一步的，在本实施例中，当服务器确定第一账户对应的第一业务的第一数量小于或等于第一业务的第一剩余对象数量且小于或等于第二剩余对象数量后，接下来，服务器向预设数据库发送业务查询请求，预设数据库给服务器返回第一账户对应的第三剩余对象数量、以及第一账户所属的总账户对应的第四剩余对象数量。其中，业务查询请求中包括第一账户的标识，总账的标识等信息。

S1007、在第一数量小于或等于第三剩余对象数量，以及第一数量小于或等于第四剩余对象数量时，向第一账户分配第一数量的对象。

在本实施例中，在服务器确定第一账户中第一业务对应的第一数量小于或等于第三剩余对象数量，且第一账户中第一业务对应的第一数量小于或等于第四剩余对象数量时，则服务器向第一账户分配第一数量的对象。若在服务器确定第一账户中第一业务对应的第一数量大于第三剩余对象数量，或者，第一账户中第一业务对应的第一数量大于第四剩余对象数量时，拒绝向第一账户分配第一数量的对象，并向终端设备发送拒绝信息。

例如，当服务器确定第一账户中银行保函3001对应的第一数量为20万、第一账户对应的第三对象数量为15万、第一账户所属的总账户对应的第四对象数量为18万时，拒绝向第一账户分配第一数量的对象，并向终端设备发送拒绝信息；当服务器确定第一账户中银行保函3001对应的第一数量为20万、第一账户对应的第三对象数量为25万、第一账户所属的总账户对应的的第四对象数量为30万时，服务器向第一账户的第一业务分配额度为20万的对象。

S1008、分别将第一剩余对象数量、第二剩余对象数量、第三剩余对象数量以及第四剩余对象数量减少第一数量。

在本实施例中，服务器分别对第一剩余对象数量、第二剩余对象数量、第三剩余对象数量以及第四剩余对象数量进行减少第一数量的操作。

例如，服务器将对第一账户中银行保函3001对应的可用额度、担保类3000对应的可用额度、第一账户对应的总可用额度以及总账户对应的总可用额度进行减去请求交易额度的操作。

S1009、拒绝向第一账户分配第一数量的对象，并向终端设备发送拒绝信息。

在本实施例中，当服务器确定第一数量大于第二剩余对象数量时，则拒绝向第一账户分配第一数量的对象，并向终端设备发送拒绝信息。

S1010、拒绝向第一账户分配第一数量的对象，并向终端设备发送拒绝信息。

在本实施例中，当服务器确定第一数量大于第一剩余对象数量时，则服务器拒绝向第一账户分配第一数量的对象，并向终端设备发送拒绝信息。

例如，当第一账户在银行保函3001对应的业务请求中的第一数量为30万，且当前第一账户在银行保函3001对应的第一剩余对象数量为10万时，第一数量大于第一剩余对象数量即不满足请求交易额度必须小于或等于可用额度的业务处理条件。因此，服务器拒绝向第一账户分配请求交易额度，并向终端设备发送拒绝信息。

S1011、接收第一业务对应的第二业务请求，第二业务请求包括待归还对象的第二数量和第一账户的标识。

其中，第二业务请求例如可以为归还额度请求，其中待归还对象的第二数量例如可以为待归还额度。需要说明的一点是，第二数量应小于或等于第一数量。

在本实施例中，在处理还款或者贷款到期等业务时，服务器会收到第一账户中第一业务对应的第二业务请求。例如，在处理还款业务时，服务器会接收到第一账户中第一业务对应的归还额度请求，以请求第一业务对应的可用额度、第一账户对应的总可用额度以及总账户对应的总可用额度恢复。

S1012、根据第二业务请求，分别将第一剩余对象数量、第二剩余对象数量、第三剩余对象数量及第四剩余对象数量增加第二数量。

在本实施例中，根据第二业务请求，服务器分别将第一剩余对象数量、第二剩余对象数量、第三剩余对象数量及第四剩余对象数量增加第二数量。

例如，服务器将对第一账户中银行保函3001对应的可用额度、担保类3000对应的可用额度进行加上待归还额度的操作。进一步的，在本实施例中，服务器将对第一账户对应的总可用额度以及总账户对应的总可用额度进行加上待归还额度的操作。

本申请实施例提供的业务处理方法，对第一业务的业务处理中不仅考虑到了自身的业务情况，而且参考了同业务类型下的其他业务的情况，这使得处理方式在同类业务处理过程中得到复用，实现了对多种业务类型下的业务进行统一管理。在保证第一业务处理准确率的同时，提高了业务处理的可维护性、可复用性，降低了维护业务处理方法的冗余度。

图11为本申请实施例提供的一种业务处理装置的结构示意图。如图11所示，该装置1100包括：接收模块1101、查询模块1102、第一确定模块1103以及第一处理模块1104。

接收模块1101，用于接收终端设备发送的第一业务对应的第一业务请求，所述第一业务请求包括待请求对象的第一数量和第一账户的标识；

查询模块1102，用于根据所述第一账户的标识和所述第一业务的标识，在预设数据库中查询获取所述第一账户在所述第一业务下的第一剩余对象数量；

第一确定模块1103，用于确定所述第一业务对应的业务类型，所述查询模块1102还用于根据所述第一账户的标识和所述业务类型，在所述预设数据库中查询获取所述第一账户在所述业务类型下的第二剩余对象数量；

第一处理模块1104，用于根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理。

在一种可能的设计中，所述第一处理模块1104具体用于：

判断所述第一数量是否小于或等于所述第一剩余对象数量；

若是，则根据所述第一数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

在一种可能的设计中，所述第一处理模块1104具体用于：

判断所述第一数量是否小于或等于所述第二剩余对象数量；

若是，则向所述第一账户分配所述第一数量的对象；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

在一种可能的设计中，所述第一处理模块1104具体用于：

确定所述第一账户对应的第三剩余对象数量、以及所述第一账户所属的总账户对应的第四剩余对象数量；

在所述第一数量小于或等于所述第三剩余对象数量，以及所述第一数量小于或等于所述第四剩余对象数量时，向所述第一账户分配所述第一数量的对象。

在一种可能的设计中，所述第一处理模块1104还用于：

分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量以及所述第四剩余对象数量减少所述第一数量。

在一种可能的设计中，所述第一处理模块1104还用于：

接收所述第一业务对应的第二业务请求，所述第二业务请求包括待归还对象的第二数量和所述第一账户的标识；

根据所述第二业务请求，分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量及所述第四剩余对象数量增加所述第二数量。

本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图12为本申请实施例提供的一种业务处理装置的结构示意图。如图12所示，该装置1200包括：获取模块1201、第二确定模块1202、第二处理模块1203以及更新模块1204。

获取模块1201，用于接收终端设备发送的第一业务对应的业务创建请求，所述业务创建请求中包括第一账户的标识和所述第一账户在所述第一业务下的第一对象数量；

第二确定模块1202，用于确定所述第一账户对应的第三对象数量，所述第一业务对应的业务类型、以及所述业务类型对应的第二对象数量；

第二处理模块1203，用于根据所述业务创建请求创建所述第一业务，以及更新模块1204，用于根据所述第一对象数量更新所述第二对象数量及所述第一账户对应的第三对象数量。

在一种可能的设计中，所述第二处理模块1203具体用于：

判断是否存在所述第一账户对应的已创建业务，所述第一业务与所述已创建业务的业务类型相同；

若是，则创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联；

若否，则创建所述第一账户对应的业务类型、以及创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联。

在一种可能的设计中，所述第二处理模块1203具体用于：

若不存在所述第一账户对应的总账户，则创建所述总账户、确定所述总账户对应的第四对象数量，并将所述第一账户与所述总账户关联。

在一种可能的设计中，所述更新模块1204具体用于：

判断所述第一对象数量是否大于所述第二对象数量；

若是，则更新所述第二对象数量、所述第三对象数量及所述第四对象数量。

本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图13为本申请实施例提供的业务处理设备的硬件结构示意图，如图13所示，本实施例的业务处理设备1300包括：处理器1301以及存储器1302；其中

存储器1302，用于存储计算机执行指令；

处理器1301，用于执行存储器存储的计算机执行指令，以实现上述实施例中业务处理方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。

可选地，存储器1302既可以是独立的，也可以跟处理器1301集成在一起。

当存储器1302独立设置时，该业务处理设备还包括总线1303，用于连接所述存储器1302和处理器1301。

本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上业务处理设备所执行的业务处理方法。

本申请实施例还提供一种计算机程序产品，程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (15)

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

接收终端设备发送的第一业务对应的第一业务请求，所述第一业务请求包括待请求对象的第一数量和第一账户的标识；

根据所述第一账户的标识和所述第一业务的标识，在预设数据库中查询获取所述第一账户在所述第一业务下的第一剩余对象数量；

确定所述第一业务对应的业务类型，并根据所述第一账户的标识和所述业务类型，在所述预设数据库中查询获取所述第一账户在所述业务类型下的第二剩余对象数量；

根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理，包括：

判断所述第一数量是否小于或等于所述第一剩余对象数量；

若是，则根据所述第一数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理，包括：

判断所述第一数量是否小于或等于所述第二剩余对象数量；

若是，则向所述第一账户分配所述第一数量的对象；

若否，则拒绝向所述第一账户分配所述第一数量的对象，并向所述终端设备发送拒绝信息。

4.根据权利要求3所述的方法，其特征在于，所述向所述第一账户分配所述第一数量的对象，包括：

确定所述第一账户对应的第三剩余对象数量、以及所述第一账户所属的总账户对应的第四剩余对象数量；

在所述第一数量小于或等于所述第三剩余对象数量，以及所述第一数量小于或等于所述第四剩余对象数量时，向所述第一账户分配所述第一数量的对象。

5.根据权利要求4所述的方法，其特征在于，所述向所述第一账户分配所述第一数量的对象之后，还包括：

分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量以及所述第四剩余对象数量减少所述第一数量。

6.根据权利要求4-5任一项所述的方法，其特征在于，所述方法还包括：

接收所述第一业务对应的第二业务请求，所述第二业务请求包括待归还对象的第二数量和所述第一账户的标识；

根据所述第二业务请求，分别将所述第一剩余对象数量、所述第二剩余对象数量、所述第三剩余对象数量及所述第四剩余对象数量增加所述第二数量。

7.一种业务处理方法，其特征在于，包括：

接收终端设备发送的第一业务对应的业务创建请求，所述业务创建请求中包括第一账户的标识和所述第一账户在所述第一业务下的第一对象数量；

确定所述第一账户对应的第三对象数量，所述第一业务对应的业务类型、以及所述业务类型对应的第二对象数量；

根据所述业务创建请求创建所述第一业务，以及根据所述第一对象数量更新所述第二对象数量及所述第一账户对应的第三对象数量。

8.根据权利要求7所述的方法，其特征在于，所述根据所述业务创建请求创建所述第一业务，包括：

判断是否存在所述第一账户对应的已创建业务，所述第一业务与所述已创建业务的业务类型相同；

若是，则创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联；

若否，则创建所述第一账户对应的业务类型、以及创建所述第一账户对应的所述第一业务，并将所述第一业务与所述业务类型关联。

9.根据权利要求8所述的方法，其特征在于，所述创建所述第一账户对应的业务类型、以及创建所述第一账户对应的所述第一业务之后，包括：

若不存在所述第一账户对应的总账户，则创建所述总账户、确定所述总账户对应的第四对象数量，并将所述第一账户与所述总账户关联。

10.根据权利要求9任一项所述的方法，其特征在于，所述根据所述第一对象数量更新所述第二对象数量及所述第一账户对应的第三对象数量，包括：

判断所述第一对象数量是否大于所述第二对象数量；

若是，则更新所述第二对象数量、所述第三对象数量及所述第四对象数量。

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

接收模块，用于接收终端设备发送的第一业务对应的第一业务请求，所述第一业务请求包括待请求对象的第一数量和第一账户的标识；

查询模块，用于根据所述第一账户的标识和所述第一业务的标识，在预设数据库中查询获取所述第一账户在所述第一业务下的第一剩余对象数量；

第一确定模块，用于确定所述第一业务对应的业务类型，所述查询模块还用于根据所述第一账户的标识和所述业务类型，在所述预设数据库中查询获取所述第一账户在所述业务类型下的第二剩余对象数量；

第一处理模块，用于根据所述第一数量、所述第一剩余对象数量和所述第二剩余对象数量，对所述第一业务请求进行业务处理。

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

获取模块，用于接收终端设备发送的第一业务对应的业务创建请求，所述业务创建请求中包括第一账户的标识和所述第一账户在所述第一业务下的第一对象数量；

第二确定模块，用于确定所述第一账户对应的第三对象数量，所述第一业务对应的业务类型、以及所述业务类型对应的第二对象数量及所述第一账户对应的第三对象数量；

第二处理模块，用于根据所述业务创建请求创建所述第一业务，以及更新模块用于根据所述第一对象数量更新所述第二对象数量。

13.一种业务处理设备，其特征在于，包括：

存储器，用于存储程序；

处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如权利要求1至6中任一所述的业务处理方法，或者，如权利要求7至10任一项所述的业务处理方法。

14.一种计算机可读存储介质，其特征在于，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至6中任一所述的业务处理方法，或者，如权利要求7至10任一项所述的业务处理方法。

15.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6中任一所述的业务处理方法，或者，如权利要求7至10任一项所述的业务处理方法。

Images