数据处理方法、装置、设备和存储介质

本公开涉及数据处理技术领域，具体涉及智慧金融、云平台技术、票据处理等技术领域，尤其涉及一种数据处理方法、装置、设备和存储介质。

发票系统是电子化办公的重要组成部分。针对提供云产品的云平台，其重要目标之一是构建高效易用的发票系统，使得发票开具流程更快捷、查询更方便。

本公开提供了一种数据处理方法、装置、设备和存储介质。

根据本公开的一方面，提供了一种数据处理方法，包括：获取待处理对象的申请信息，所述申请信息包括至少一个申请项；将所述至少一个申请项划分为至少一个分组，所述至少一个分组中各个分组包括至少一个申请项；针对所述各个分组，基于所述待处理对象的属性限制信息，对所述各个分组包括的至少一个申请项进行处理，以生成所述待处理对象的至少一组对象数据。

根据本公开的另一方面，提供了一种数据处理装置，包括：获取模块，用于获取待处理对象的申请信息，所述申请信息包括至少一个申请项；分组模块，用于将所述至少一个申请项划分为至少一个分组，所述至少一个分组中各个分组包括至少一个申请项；生成模块，用于针对所述各个分组，基于所述待处理对象的属性限制信息，对所述各个分组包括的至少一个申请项进行处理，以生成所述待处理对象的至少一组对象数据。

根据本公开的另一方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上述任一方面的任一项所述的方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据上述任一方面的任一项所述的方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据上述任一方面的任一项所述的方法。

根据本公开的技术方案，可以提高数据处理效果。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开第一实施例的示意图；

图2是根据本公开第二实施例的示意图；

图3是根据本公开第三实施例的示意图；

图4是根据本公开第四实施例的示意图；

图5是根据本公开第五实施例的示意图；

图6是根据本公开第六实施例的示意图；

图7是根据本公开第七实施例的示意图；

图8是根据本公开第八实施例的示意图；

图9是根据本公开第九实施例的示意图；

图10是根据本公开第十实施例的示意图；

图11是根据本公开第十一实施例的示意图；

图12是根据本公开第十二实施例的示意图；

图13是用来实现本公开实施例的数据处理方法的电子设备的示意图。

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本公开第一实施例的示意图，本实施例提供一种数据处理方法，该方法包括：

步骤101、获取待处理对象的申请信息，所述申请信息包括至少一个申请项。

步骤102、将所述至少一个申请项划分为至少一个分组，所述至少一个分组中各个分组包括至少一个申请项。

步骤103、针对所述各个分组，基于所述待处理对象的属性限制信息，对所述各个分组包括的至少一个申请项进行处理，以生成所述待处理对象的至少一组对象数据。

本实施例的执行主体可以称为数据处理装置，数据处理装置可以为软件、硬件或者软硬结合，该装置可以位于电子设备中。该电子设备可以为服务器或者用户终端，服务器可以为本地服务器或者云端服务器，用户终端可以包括个人电脑(Personal Computer，PC)、移动设备(如手机、平板电脑)、车载终端(如车机)、可穿戴式设备(如智能手表、智能手环)、智能家居设备(如智能电视、智能音箱)等。

数据处理方法可以应用于多种场景，比如，发票系统。

以待处理对象为发票为例，上述的数据处理装置可以位于云平台提供的发票系统中。

如图2所示，交互系统可以包括：客户关系管理系统201、发票系统202、用户控制台系统和/或运营管理系统(可以表示为用户控制台系统/运营管理系统)203。

客户关系管理系统201和用户控制台系统/运营管理系统203可以称为客户端，可以位于用户终端上，用户终端比如为PC、移动设备等。

进一步地，客户关系管理系统201可以为销售人员使用的客户端；用户控制台系统可以为用户(比如，某个企业)使用的客户端，图2中用户表示为云用户；运营管理系统可以为运营人员使用的客户端。

发票系统202可以称为服务端，可以位于服务器上，服务器比如为云端服务器。

销售人员可以通过客户关系管理系统201向发票系统202申请开具发票，其中，客户关系管理系统201可以向销售人员展示交互界面，交互界面中可以供销售人员填写和/或选择申请开具发票的相关信息，相关信息比如包括：客户信息(比如，某个企业的名称)、开票信息，另外，交互界面还可以提供批量申请按钮，销售人员通过点击批量申请按钮，可以发起批量申请。

销售人员通过客户关系管理系统201发起批量申请后，该批量申请的请求可以发送给发票系统202，发票系统202可以基于该请求，进行申请记录。发票系统202还可以与其他系统进行交互，获取发票拆分所需的相关信息，比如，可以与合同商品系统交互，获取出账方式。发票系统202获取发票拆分所需的相关信息后，可以进行发票拆分(发票拆分的具体内容可以参见后续描述)。发票拆分完成后，发票系统202可以与审批系统进行交互，由审批系统进行运营审批，审批系统将审批结果反馈给发票系统202。若审批结果为通过，发票系统202可以与开具系统进行交互，触发开具系统开具发票。其中，发票可以分为电子发票和纸质发票，电子发票可以通过线上的电子发票开具系统开具，纸质发票可以是发票系统将开具信息发送给发票开具人员，由发票开具人员进行线下开具。开具系统开具发票后，发票系统202可以进行发票存储。

以用户(比如，云用户)为例，运营人员的执行流程可以参照用户的执行流程。云用户可以通过用户控制台系统203向发票系统202请求展示和/或下载(可以表示为展示&下载)发票。其中，用户控制台系统可以提供与云用户的交互界面，该交互界面中可以包括发票详情展示按钮，和/或，电子发票下载按钮。以发票展示为例，云用户可以通过点击发票详情展示按钮，触发发票系统202将存储的发票数据通过用户控制台系统203展示给云用户。

上述对交互系统进行了说明，结合上述说明，对本实施例的数据处理方法说明如下：

待处理对象，是指数据处理所针对的对象，比如为发票。

申请信息，是指待处理对象的相关信息，以待处理对象为发票为例，申请信息可以称为发票申请信息。

申请项，是指申请信息中所包括的信息项，每个申请项可以是指一行信息，因此还可以称为申请行。以待处理对象为发票、申请信息为发票申请信息为例，申请项可以为发票项。

以申请信息为发票申请信息、申请项为发票项为例，如图3所示，发票申请信息可以包括：合同号、发票抬头、发票项列表、发票介质、地址、申请人等。

其中，发票项列表可以包括一个或多个发票项，每个发票项可以包括一个或多个信息。如未特别说明，本公开实施例中，多个是指至少两个。

每个发票项可以包括：账号、商品名称、商品编号、税率、发票名称(*号前)、服务名称(*号后)、商品规格、商品单位、资源数量、发票项金额等。其中，图3中，以每个发票项包括：账号、商品名称、发票名称(*号前)、服务名称(*号后)、税率、资源数量和发票项金额为例。

发票系统获取的发票申请信息可以是销售人员输入的(销售人员输入的信息可以称为开票信息)，和/或，从其他系统获取的。

比如，上述的合同号、发票抬头、发票介质(纸质发票或电子发票)、地址、申请人可以是销售人员输入的。如未特别说明，本公开实施例中，输入方式不限定，比如，销售人员可以填写相关信息，或者，发票系统通过客户关系管理系统向销售人员提供可选项，销售人员在可选项中进行选择。

发票项中的账号、商品名称、商品编号、发票名称(*号前)、服务名称(*号后)、商品规格、商品单位、资源数量、发票项金额可以是销售人员输入的。

以客户为某个企业为例，账号可以为该企业的各个部门的账号。

发票名称比如包括：技术服务费、应用软件，相应的服务名称可以分别为：信息技术服务、软件服务。

资源数量，为商品的个数，比如，1、0.5、2等。

发票项金额，为该发票项的商品的金额，比如，10w(10万)等。

税率，也可以称为税收分类编码。发票系统可以基于销售人员填写的商品名称在商品库中检索，获得税率，之后，可以将税率在交互界面上显示给销售人员。

发票项中还可以包括账单类型(定制账单、通用账单等)。发票系统可以基于销售人员填写的商品名称确定出账方式(线下出账、线上出账等)，再基于出账方式与账单类型的对应关系确定账单类型，比如，线下出账对应定制账单，线上出账对应通用账单等。

即，对于销售人员来讲，理解容易的信息可以是销售人员输入的，理解困难的信息可以是发票系统自动获取的。

由于发票数据涉及多系统内部复杂交互，销售发起申请时会对账单类型，税率等信息存在疑问，本实施例中，针对销售人员存在疑问的信息(如，账单类型、税率)，可以由发票系统获取，不需要销售人员输入，因此，可以降低销售人员的理解难度，并且，还可以将这些信息展示给销售人员，便于销售人员获悉相关信息。

一些实施例中，所述申请信息包括的至少一个申请项中各个申请项包括：所述待处理对象对应的申请对象的标识信息。

申请对象的标识信息，可以具体为用户标识信息，比如，账号。

以用户(或称为客户)为企业为例，比如，一个企业包括多个部门，每个部门具有一个账号，从而，一个企业可以具有多个账号。

一般来讲，可以由销售人员为客户(如，某个企业)申请开具发票。针对某个企业，该企业可以具有多个账号，比如，该企业有多个部门，每个部门具有一个账号。

相关技术中，发票系统仅支持一次针对一个账号申请发票。比如，某个企业有N(N为正整数)个部门，对应有N个账号，此时，销售人员需要申请N次，每次申请为一个账号开具发票。

相关技术中，每次仅针对一个账号申请发票，即，可以认为是账号级的申请方式。具体地，如图4的上侧所示，相关技术中，账号位于发票项之外，从而，每次仅能申请一个账号的发票。

而本实施例中，如图4的下侧所示，每个发票项包括账号，账号可以由销售人员填写或选择。以填写为例，销售人员可以根据实际需要，填写相同或不同的账号。因此，每次可以申请多个账号的发票，这多个账号可以相同或不同。即，可以一次申请同一账号的多个发票项，可以认为是同一账号的批量申请；或者，一次申请多个账号的多个发票项，可以为认为是多个账号的批量申请。

由于相关技术是针对一个账号申请一次，因此，可以认为是账号级的，而本实施例可以一次针对多个账号进行申请，这多个账号可以对应同一个客户(如企业)，因此，可以认为是客户级的。

在多账号场景下，相关技术中需要发起多次申请，而本实施例可以只发起一次申请，从而可以简化操作，适用于客户级的多账号场景。

通过在申请项中包括申请对象的标识信息，可以实现针对申请对象的批量申请，相对于一次仅能针对一个申请对象的申请方式，可以简化操作，适合复杂的申请场景。

以批量申请(同一账号的多个发票项，或者，多个账号的多个发票项)为例，至少一个申请项具体为多个发票项。

对多个发票项进行数据处理时，可以先将多个发票项划分为至少一个分组，针对所述至少一个分组中各个分组的发票项进行数据处理。

其中，可以基于分组信息，对多个发票项进行分组，分组信息可以包括如下项中的一项或多项：账单类型、税率、发票名称(*号前)和服务名称(*号后)、商品规格、商品单位、账号。

由于可以基于分组信息，对申请项进行分组，因此，分组信息还可以称为拆分粒度。

拆分粒度，可以是预先配置在发票系统中的。

由于拆分粒度可以为上述信息中的一项或多项，或者，还可以根据实际需求配置为其他信息，因此，可以实现多粒度的拆分，或者说，更细粒度的拆分。从而可以对申请项进行更灵活的分组或者说拆分。

基于分组信息对申请项进行分组时，可以是将相同的分组信息的申请项划分为同一个分组。

比如，分组信息包括：发票名称和服务名称(可以表示为发票名称*服务名称)，如图5所示，假设发票项包括三个发票项，第一个发票项和第二个发票项的发票名称和服务名称均为：A*B，第三个发票项的发票名称和服务名称为：C*D，其中，A和C分别为不同的发票名称，B和D分别为不同的服务名称，则，可以将第一个发票项和第二个发票项组成一个分组，用第一分组表示，将第三个发票项组成另一个分组，用第二分组表示。

通过将至少一个申请项划分为至少一个分组，可以以分组为粒度，对申请项进行处理，以生成对象数据。

针对发票，存在一些属性限制信息，可以参见表1。

表1

属性字段 要求 电子发票单张发票上限 99999.99 纸质发票单张发票上限 1000000.00(100w) 电子发票的发票项 数量上限＝8项 纸质发票的发票项 无上限 税率 一张发票仅包含一种税率 资源数量 2位小数 资源单价/发票项金额/总发票金额 2位小数

待处理对象为发票时，对象数据为发票数据，由于发票的上述属性限制信息，在生成发票数据时，可以参考上述的属性限制信息，比如，针对纸质发票，每张发票(同一组发票数据)的发票项金额的总金额不能超过100w(100万)。

本实施例中，通过对申请项进行分组，针对各个分组包括的申请项进行处理，以生成对象数据，可以实现以分组为粒度的处理，由于在数据处理时不仅考虑了属性限制信息，还考虑了分组，从而数据处理方式更精细化，可以提高数据处理效果。

图6是根据本公开第六实施例的示意图，本实施例提供一种数据处理方法，本实施例以待处理对象为发票为例，相应地，待处理对象的申请信息为发票申请信息，申请项为发票项，申请对象的标识信息为账号，对象数据为发票数据。本实施例的方法包括：

步骤601、获取发票申请信息，所述发票申请信息包括至少一个发票项。

其中，如图3或图4所示，至少一个发票项中各个发票项可以包括账号，从而，销售人员可以为多个账号批量申请开具发票。每个发票项具有一个账号，不同发票项具有的账号可以相同或不同。

多个账号可以是同一企业的多个部门的账号，从而，可以实现客户级的多账号合并处理。

步骤602、将所述至少一个发票项划分为至少一个分组，所述至少一个分组中各个分组包括至少一个发票项。

其中，可以基于预设的分组信息，对至少一个发票项进行分组。

分组信息可以包括如下项中的一项或多项：账单类型、税率、发票名称(*号前)和服务名称(*号后)、商品规格、商品单位、账号。

假设分组信息为：发票名称和服务名称(可以表示为发票名称*服务名称)，如图5所示，可以三个发票项划分为第一分组和第二分组。

一些实施例中，针对各个分组，可以对各个分组内的发票项按照发票项金额从大到小的顺序排列。比如，针对同一分组内的第一发票项和第二发票项，若第一发票项的发票项金额大于第二发票项的发票项金额，则可以将第一发票项排序在第二发票项的前面。

通过对各个分组内的发票项按照发票项金额排序，结合后续的处理方式，可以使得每张发票的发票项的总金额尽量接近金额上限，从而可以提高资源利用率。

一些实施例中，由于分组信息是可设置的，若分组信息不包含税率，比如，分组信息设置为上述的发票名称和服务名称，此时的分组信息即不包含税率。但是，由于发票的属性限制信息中，需要限定每张发票仅具有一个税率，则，除了分组信息，还需要基于税率进行分组。比如，基于不包含税率的分组信息，将第一发票项和第二发票项划分为同一个分组，但是，若第一发票项和第二发票项的税率不同，则继续对第一发票项和第二发票项进行分组，即，第一发票项为一个分组，第二发票项为另一个分组。

通过基于税率对发票项进行分组，可以满足发票的属性限制信息，避免一张发票上具有多个税率的发票项。

基于上述步骤，可以将至少一个发票项划分为至少一个分组。

针对至少一个分组中各个分组，可以执行如下的步骤603～604。

其中，如图6所示，假设分组的数量为N(N为正整数)，则步骤603～604将执行N次。

步骤603、对所述各个分组包括的至少一个申请项中各个申请项，进行数据预处理，以获得各个预处理后的申请项。

其中，数据预处理可以包括第一预处理和第二预处理。

如表1所示的属性限制信息中，资源单价最多为2位小数，为此，第一预处理用于解决资源单价的小数位数2位除不尽的问题。

如表1所示的属性限制信息中，单张发票存在金额上限，其中，电子发票的金额上限为99999.99，纸质发票的金额上限为1000000.00；以及，如表1所示的属性限制信息中，发票项金额最多为2位小数。为此，第二预处理用于解决资源单价大于金额上限且发票项金额的小数位数大于2位的问题。

以数据预处理包括第一预处理和第二预处理为例，可以先执行第一预处理，再对第一预处理后的发票项进行第二预处理。

关于第一预处理，可以执行：

针对所述各个申请项：

若所述申请项的资源单价的小数位数小于或等于预设小数位数，保持所述申请项不变，将所述保持不变的申请项作为第一预处理后的申请项；或者，

若所述申请项的资源单价的小数位数大于预设小数位数，将所述申请项拆分为两个申请项，作为第一预处理后的申请项。

其中，以申请项为发票项为例，发票项中可以包括资源单价，此时，可以直接从发票项中获得资源单价。或者，发票项中可以包括：资源数量和发票项金额，此时，可以采用如下的计算公式获得资源单价：

资源单价＝发票项金额/资源数量。

上述计算公式中，发票项金额可以最多保留2位小数，资源数量最多保留1位小数，资源单价最多保留2位小数。如未特别说明，本公开实施例中，保留小数位是向下取，比如，若资源单价为0.625，则保留2位小数为0.62。

预设小数位数比如为2位，则，若资源单价的小数位数不超过2位，比如，某个发票项的发票项金额＝10，资源数量＝2，此时，由于资源单价＝10/2＝5，不包含小数位，因此可以保持该发票项不变，将保持不变的发票项作为第一预处理后的发票项。

若资源单价的小数位数大于2位，可以将发票项拆分为两个发票项，作为第一预处理后的发票项。

以某个发票项、且该发票项的资源单价基于该发票项中包括的发票项金额和资源数量计算为例，假设第一预处理之前的发票项称为原始发票项，则针对原始发票项的第一预处理的具体流程可以包括：

步骤A1：计算资源单价＝原始发票项的发票项金额(最多两位小数)/原始发票项的资源数量(最多一位小数)，资源单价最多保留两位小数；

步骤A2：计算新发票项金额＝A1计算出的资源单价(最多两位小数)×原始发票项的资源数量(最多一位小数)；

步骤A31：若新发票项金额＝原始发票项金额，则保持原始发票项不变，即，针对该原始发票项，其第一预处理后的发票项与原始发票项一致。

步骤A32：若新发票项金额不等于原始发票项金额，则将原始发票项拆分为两个发票项，假设这两个发票项分别用发票项-11和发票项-12表示，则发票项-11和发票项-12采用如下方式确定：

步骤A321：资源单价保留A1计算出的资源单价的1位小数；

步骤A322：针对发票项-11，确定其资源数量＝原始发票项的资源数量；以及，确定其发票项金额＝A321计算出的资源单价保留1位小数后的值*原始发票项的资源数量；

步骤A323：针对发票项-12，计算原始发票项的发票项金额与发票项-11的发票项金额的差值，将该差值作为发票项-12的发票项金额，以及，确定发票项-12的资源数量＝1。

比如，参见图7，原始发票项的资源数量＝0.7，发票项金额＝1111111.11，此时的资源单价＝发票项金额/资源数量＝1111111.11/0.7＝1587301.58(保留2位小数)；

新发票项金额＝1587301.58×0.7＝1111111.106；

由于新发票项金额(1111111.106)与原始发票项的发票项金额(1111111.11)不同，则需要将原始发票项拆分为两个发票项，分别用发票项-11和发票项-12表示。

其中，发票项-11的资源数量＝原始发票项的资源数量＝0.7；

发票项-11的发票项金额＝计算出的资源单价保留1位小数后的值×原始发票项的资源数量＝1587301.5×0.7＝1111111.05。

其中，发票项-12的资源数量＝1；

发票项-12的发票项金额＝原始发票项的发票项金额-发票项-11的发票项金额＝1111111.11-1111111.05＝0.06。

即，参见图7，经过第一预处理，可以将图7的上侧部分所示的原始发票项拆分为图7的中间部分所示的两个第一预处理后的发票项。

关于第二预处理，可以执行：

针对所述第一预处理后的申请项：

若所述第一预处理后的申请项的资源单价小于或等于金额上限，保持所述第一预处理后的申请项不变，作为第二预处理后的申请项；

若所述第一预处理后的申请项的资源单价大于金额上限，将所述第一预处理后的申请项拆分为两个申请项，作为第二预处理后的申请项。

其中，第二预处理是在第一预处理的基础上执行，具体流程可以包括：

步骤B1：计算资源单价＝第一预处理后的发票项的发票项金额(最多两位小数)/原始发票项的资源数量(最多一位小数)，资源单价最多保留一位小数；

步骤B2：若B1计算出的资源单价大于发票金额上限，则计算新资源数量＝发票金额上限/B1计算出的资源单价，新资源数量最多保留两位小数；

步骤B3：计算新发票项金额＝B1计算出的资源单价×B2计算出的新资源数量；

步骤B41：若新发票项金额的小数位数不大于2，则保持第一预处理后的发票项不变，即，第二预处理后的发票项与第一预处理后的发票项一致。

步骤B42：若新发票项金额的小数位数大于2，则将第一预处理后的发票项拆分为两个发票项，假设这两个发票项分别用发票项-21和发票项-22表示，则发票项-21和发票项-22采用如下方式确定：

步骤B421：针对发票项-21，确定其资源数量＝第一预处理后的发票项的资源数量；以及，确定其发票项金额＝B1计算出的资源单价的整数部分×第一预处理后的发票项的资源数量；

步骤B422：针对发票项-22，确定其资源数量＝1；以及，确定其发票项金额＝B1计算出的资源单价的小数部分×第一预处理后的发票项的资源数量。

比如，参见图7，以纸质发票为例，即发票金额上限＝100w。

针对图7的第一预处理后的发票项中的第二个发票项，即发票项-12，其发票项金额＝0.06，资源数量＝1，则发票项-12的资源单价＝0.06/1＝0.06，不超过发票金额上限，则针对发票项-12保持不变，作为第二预处理后的发票项。

针对图7的第一预处理后的发票项中的第一个发票项，即发票项-11，其发票项金额＝1111111.05，资源数量＝0.7，因此，其资源单价＝1111111.05/0.7＝1587301.5，此时的资源单价超出金额上限(1000000)；

新资源数量＝1000000/1587301.5＝0.63；

新发票项金额＝1587301.5×.63＝999999.945，小数位数超过2；

由于新发票项金额的小数位数超过2，则需要对该第一预处理后的发票项(发票项-11)进行拆分，将其拆分为两个发票项，分别用发票项-21和发票项-22表示。

其中，发票项-21的资源数量＝第一预处理后的发票项(发票项-11)的资源数量＝0.7；

发票项-21的发票项金额＝计算出的资源单价的整数部分×发票项-21的资源数量＝1587301×0.7＝1111110.7。

其中，发票项-22的资源数量＝1；

发票项-22的发票项金额＝计算出的资源单价的小数部分×第一预处理后的发票项的资源数量＝0.5×0.7＝0.35。

即，参见图7，经过第二预处理，可以将图7的中间部分所示的两个第一预处理后的发票项中的一个需要第二预处理的发票项拆分为图7的下侧部分所示的两个第二预处理后的发票项，由于第一预处理后的发票项中的一个发票项保持不变，为此，经过第二预处理后，会生成三个发票项。

需要说明的是，由于发票项除了上述的资源数量、发票项金额、资源单价，还可以存在其他信息，比如，税率等。针对其他信息，在拆分为新的发票项时，可以保持不变，比如，原始发票项存在税率，第一预处理后的发票项和第二预处理后的发票项中的税率可以保持与原始发票项中的税率一致。

通过对申请项进行数据预处理，可以使得预处理后的申请项满足属性限制信息，为后续更合理、有效地生成对象数据提供数据基础。

数据预处理方式可以包括一种或多种，从而可以根据实际情况进行更合理有效的数据预处理，提高预处理后的申请项的准确度。

针对第一预处理，可以解决资源单价的小数位数超过属性限制信息的问题。

针对第二预处理，可以解决资源单价大于金额上限且申请项金额的小数位数超过属性限制信息的问题。

步骤604、基于所述待处理对象的属性限制信息，对所述各个预处理后的申请项进行处理，以生成所述待处理对象的至少一组对象数据。

其中，可以基于所述待处理对象的属性限制信息，对所述各个预处理后的申请项，执行至少一次的生成过程，以生成所述至少一次中各次生成过程对应的所述待处理对象的至少一组对象数据。

假设针对某个分组，其生成过程用M(M为正整数)表示，如图6所示，针对该分组的预处理后的申请项，可以执行M次生成过程，每次生成过程可以生成至少一组对象数据。

针对各次生成过程，可以包括：

步骤6041：在所述各个预处理后的申请项中，确定所述各次生成过程对应的待处理申请项。

步骤6042：基于所述待处理对象的属性限制信息，对所述待处理申请项进行处理，以生成所述至少一组对象数据。

其中，针对各个分组，各次生成过程可以是串行执行的，针对某次生成过程，其待处理申请项，可以是各个分组中的全部预处理后的申请项中，除了已处理申请项之外的剩余申请项。其中，已处理申请项可以为已累加的申请项，或者为已拆分的申请项。

比如，针对某个分组，该分组的全部预处理后的申请项包括：第一申请项、第二申请项、第三申请项。

第一次生成过程中，由于第一次生成过程是首次生成过程，不存在已处理的申请项，则将全部预处理后的申请项，即，上述的第一申请项～第三申请项作为第一次生成过程对应的待处理申请项。

假设第一次生成过程中，对第一申请项和第二申请项进行了累加处理，则第二次生成过程中，由于第一申请项和第二申请项是已处理申请项，则将第三申请项作为第二次生成过程对应的待处理申请项。

确定出各次生成过程对应的待处理申请项后，可以基于待处理申请项生成对象数据。

其中，所述属性限制信息可以包括金额上限，所述待处理申请项可以包括申请项金额，且所述待处理申请项基于所述申请项金额排序，之后，可以基于待处理申请项的资源单价是否超过金额上限，对待处理申请项进行累加或者拆分处理。

本实施例中，针对各个分组，可以以分组为粒度进行数据处理。并且，针对各个分组，可以执行至少一次的生成过程，每次生成过程可以生成一组或多组的对象数据，由于可以执行一次或多次生成过程，从而生成过程更准确和全面，进而可以生成准确、全面的对象数据。

参见图8，基于所述待处理对象的属性限制信息，对所述待处理申请项进行处理，以生成所述各组对象数据，可以包括：

步骤801、确定待处理申请项的资源单价。

其中，以申请项为发票项为例，若发票项中包括资源单价，则可以直接从发票项中获取资源单价。或者，

若发票项中包括发票项金额和资源数量，则可以采用计算公式：资源单价＝发票项金额/资源数量，计算资源单价。

若属性限制信息中包括对资源单价的限制，比如，资源单价最多为2位小数，则资源单价最多保留2位小数。

步骤802、判断所述资源单价是否小于或等于金额上限，若是，执行步骤803～步骤804，否则，执行步骤805～步骤807。

其中，若资源单价不超过金额上限，即，小于或等于金额上限，可以对待处理申请项进行累加处理；若资源单价超过金额上限，即大于金额上限，可以对待处理申请项进行拆分处理。

若资源单价不超过金额上限，具体地，可以执行：

步骤803、基于所述申请项金额，按序累加整数个待处理申请项，直至达到累加结束条件，所述累加结束条件包括：不超过所述属性限制信息，且与所述属性限制信息最接近。

步骤804、将达到所述累加结束条件的所述整数个待处理申请项，合并为一组对象数据。

其中，以申请项为发票项为例，属性限制信息假设包括：单张发票的总金额不超过金额上限，以及，单张发票的发票项的总项数不超过数量上限。

相应地，累加结束条件包括：单组对象数据的总金额不超过金额上限，且与金额上限最接近，以及，单组对象数据的总项数不超过数量上限，且与数量上限最接近。

需要说明的是，由于纸质发票不限制数量上限，则针对纸质发票可以不考虑发票项的总项数，即，针对纸质发票，累加结束条件可以为：单组对象数据的总金额不超过金额上限，且与金额上限最接近。

比如，参见图9，以纸质发票为例，针对某个分组的某次生成过程，假设其待处理申请项包括如图9所示的第一发票项、第二发票项和第三发票项。

针对待处理申请项，可以是按序对各个待处理申请项进行处理，即，可以按序处理第一发票项、第二发票项和第三发票项。其中，上述实施例中已经说明，各个分组内的申请项可以是按照申请项金额从大到小的顺序，按序排列的。因此，按序处理各个待处理申请项时，可以是按照申请项金额从大到小的顺序进行处理。

其中，可以创建并初始化如下变量：当前发票、当前发票的发票项集合、当前发票项的剩余额度、当前发票的累计金额。其中，当前发票的初始值可以为空；当前发票的发票项集合的初始值也可以为空；当前发票项的剩余额度的初始值可以为当前发票项的发票项金额，即原始值；当前发票的累计金额的初始值可以为0。

针对第一发票项，由于其资源单价＝60w，不超过纸质发票的金额上限(100w)，则可以将第一发票项累加到当前发票的发票项集合中；此时的当前发票的累计金额从0更新为第一发票项的发票项金额，即60w，未超过金额上限，可以累加；

针对第二发票项，由于其资源单价＝30w，不超过纸质发票的金额上限，则可以将第二发票项也累加到当前发票的发票项集合中；此时的当前发票的累计金额更新为：60+30＝90w，未超过金额上限，可以累加；

针对第三发票项，由于其资源单价＝20w，不超过纸质发票的金额上限，但是，若将第三发票项累加到当前发票的发票项集合中，则累计金额＝90+20＝110w，超过金额上限。因此，第三发票项不能累加到当前发票的发票项集合中。

因此，基于图9所示的待处理申请项，可以将第一发票项和第二发票项合并为一组发票数据，用第一组发票数据表示，相应地，在开具发票后，第一发票项和第二发票项开具在同一张发票上。

由于第三发票项不能累加，所以，第三发票项可以作为下次生成过程的待处理申请项，类似上述处理，生成另一组发票数据，用第二组发票数据表示，从而将第三发票项开具到另一张发票上。

由于按照申请项金额，按序累加待处理申请项，可以累加尽量多的申请项金额较大的申请项，因此，可以获得总金额更接近金额上限的同组对象数据，可以提高资源利用率。另外，通过累加整数个待处理申请项，可以以申请项为粒度进行累加，而在累加时并不需要对申请项进行拆分，可以简化操作，提高效率。

若资源单价超过金额上限，可以将所述待处理申请项拆分为至少一个拆分申请项，将所述至少一个拆分申请项作为所述至少一组对象数据。

由于资源单价超过金额上限，即超过属性限制信息，此时，通过对待处理申请项进行拆分，可以避免待处理申请项的相关信息超过属性限制信息，满足实际对象数据的要求。

具体可以执行：

步骤805、判断所述待处理申请项的资源单价是否为整数，若是，执行步骤806，否则，执行步骤807。

其中，若资源单价不包含小数，即为整数，否则不为整数。

步骤806、确定所述待处理申请项对应的拆分申请项包括第一拆分申请项和第二拆分申请项，第一拆分申请项和第二拆分申请项可以采用如下方式确定：

针对所述第一拆分申请项，将所述金额上限作为所述第一拆分申请项的申请项金额，以及，基于所述金额上限和所述待处理申请项的资源单价，确定所述第一拆分申请项的资源数量；

针对所述第二拆分申请项，基于所述待处理申请项的资源数量和所述第一拆分申请项的资源数量，确定所述第二拆分申请项的资源数量，以及，基于所述待处理申请项的资源单价和所述第二拆分申请项的资源数量，确定所述第二拆分申请项的申请项金额。

比如，参见图10，待处理申请项的资源数量＝0.1，发票项金额＝200w，此时的资源单价＝200/0.1＝2000w，以纸质发票为例，由于超过金额上限(100w)，则需要对该待处理申请项进行拆分。又由于资源单价为整数，则可以将该待处理申请项拆分为第一拆分申请项和第二拆分申请项。

其中，第一拆分申请项的项数可以为一项或多项，第二拆分申请项的项数为一项，即，可以对待处理申请项不断进行拆分，每次拆分确定一个第一拆分申请项，第一拆分申请项的申请项金额为金额上限，直至待处理申请项的剩余金额不超过金额上限，作为最后一个拆分申请项，最后一个拆分申请项即为第二拆分申请项。

参见图10，基于上述示例，第一拆分申请项的发票项金额＝金额上限＝100w，第一拆分申请项的资源数量＝金额上限/待处理申请项的资源单价＝100/2000＝0.05。

第二拆分申请项的资源数量＝待处理申请项的资源数量-(第一拆分申请项的个数×第一拆分申请项的资源数量)＝0.1-(1×0.05)＝0.05，第二拆分申请项的发票项金额＝第二拆分申请项的资源数量×待处理申请项的资源单价＝0.05×2000＝100。

每个拆分申请项可以作为一组对象数据，参见图10，可以将图10所示的待处理申请项拆分为2组发票数据。

在资源单价为整数时，基于金额上限进行拆分，可以使得第一拆分申请项的申请项金额为金额上限，提高资源利用率，并且，可以将待处理申请项拆分为尽量少的拆分申请项，可以降低资源开销。

步骤807、确定所述待处理申请项对应的拆分申请项包括第三拆分申请项、第四拆分申请项和第五拆分申请项，所述第三拆分申请项、第四拆分申请项和第五拆分申请项可以采用如下方式确定：

将去掉小数的资源单价作为新资源单价；

针对所述第三拆分申请项，基于所述金额上限和所述新资源单价，确定所述第三拆分申请项的资源数量；以及，基于所述第三拆分申请项的资源数量和所述新资源单价，确定所述第三拆分申请项的申请项金额；

针对所述第四拆分申请项，基于所述待处理申请项的资源数量和所述第三拆分申请项的资源数量，确定所述第四拆分申请项的资源数量；以及，基于所述新资源单价和所述第四拆分申请项的资源数量，确定所述第四拆分申请项的申请项金额；

针对所述第五拆分申请项，将所述第五拆分申请项的资源数量确定为1，以及，基于所述待处理申请项的资源单价的小数部分以及所述待处理申请项的资源数量，确定所述第五拆分申请项的申请项金额。

比如，参见图11，待处理申请项的资源数量＝1，发票项金额＝500000.55，此时的资源单价＝500000.55/1＝500000.55，以电子发票为例，由于超过金额上限(99999.99)，则需要对该待处理申请项进行拆分。又由于资源单价包含小数，则可以将该待处理申请项拆分为第三拆分申请项、第四拆分申请项和第五拆分申请项。

其中，第三拆分申请项的项数可以为一项或多项，第四拆分申请项的项数为一项，第五拆分申请项的项数为一项。第三拆分申请项和第四拆分申请项类似上述的第一拆分申请项和第二拆分申请项，区别在于，资源单价采用实际的资源单价的整数部分。

参见图11，基于上述示例，第三拆分申请项的资源数量＝金额上限/新资源单价＝99999.99/500000＝0.19，第三拆分申请项的发票项金额＝第三拆分申请项的资源数量×新资源单价＝0.19×500000＝95000。

如图11所示，基于上述拆分方式，可以获得5个第三拆分申请项。

针对第四拆分申请项，第四拆分申请项的资源数量＝待处理申请项的资源数量-(第三拆分申请项的个数×第三拆分申请项的资源数量)＝1-(5×0.19)＝0.05；第四拆分申请项的发票项金额＝第四拆分申请项的资源数量×新资源单价＝0.05×500000＝25000。

针对第五拆分申请项，第五拆分申请项的资源数量＝1；第五拆分申请项的发票项金额＝待处理申请项的资源单价的小数部分×待处理申请项的资源数量＝0.55×1＝0.55。

每个拆分申请项可以作为一组对象数据，则，参见图11，可以将图11所示的待处理申请项拆分为7组发票数据。

在资源单价包含小数时，基于金额上限进行拆分，可以使得第三拆分申请项的申请项金额尽量接近金额上限，提高资源利用率，并且，可以将待处理申请项拆分为尽量少的拆分申请项，可以降低资源开销。另外，小数部分单独拆分为一个拆分申请项，可以保证整体的拆分申请项的总金额的准确性，从而可以获得更准确、资源利用率更高、资源开销更少的对象数据。

一些实施例中，生成至少一组对象数据后，数据处理方法还可以包括：存储所述至少一组对象数据。

比如，参见图2，发票系统生成发票数据后，可以对其进行存储，图2中用发票存储表示。

一些实施例中，还可以包括：响应于请求方的请求，将所述至少一组对象数据，展示和/或下载给请求方。

比如，参见图2，请求方可以为用户和/或运营人员，以用户为例，用户可以基于用户控制台系统的交互界面上的相关项，比如，发票详情展示，发送查看请求到发票系统，发票系统基于查看请求，将存储的发票数据展示给用户；或者，用户可以通过用户控制台系统的电子发票下载，发送下载请到发票系统，发票系统基于下载请求，将存储的电子发票数据发送给用户控制台系统。

以待处理对象为发票为例，相关技术，由于发票项中不包含账号，销售人员每次仅能为一个账号申请发票，在多账号场景下，需要发起多次申请。而本实施例中，由于发票项中包含账号，销售人员可以根据实际需求输入多个账号，从而，在多账号场景下，可以只发起一次申请，实现对多账号合并的处理，简化销售人员操作。

本实施例中，可以基于分组信息对发票项进行分组，分组信息可以是根据实际需求配置的，从而，在生成发票数据时，不仅可以参考属性限制信息，还可以针对各个分组为粒度进行处理，从而可以实现更细粒度的数据处理，适合复杂开票业务场景。

由于发票数据涉及多系统内部复杂交互，销售发起申请时会对账单类型，发票税率等开票信息存在疑问。本实施例中，针对一些销售人员难以理解的信息，比如，税率、账单类型等，可以是发票系统自动获得的，而不需要销售人员输入，从而，可以降低对销售人员的理解要求。

由于发票金额的统计逻辑的复杂性以及发票本身的一些属性限制(金额、发票项等)，导致用户和/或运营人员对发票金额的解释诉求较高，消耗人力成本进行各种消费记录的查询统计。而本实施例中，通过整合各系统内部交互，可以展示和/或下载发票数据，从而可以对外提供展示和/或下载功能，释放人力成本。

图12是根据本公开第十二实施例的示意图，本实施例提供一种数据处理装置，该装置1200包括：获取模块1201、分组模块1202和生成模块1203。

获取模块1201用于获取待处理对象的申请信息，所述申请信息包括至少一个申请项；分组模块1202用于将所述至少一个申请项划分为至少一个分组，所述至少一个分组中各个分组包括至少一个申请项；生成模块1203用于针对所述各个分组，基于所述待处理对象的属性限制信息，对所述各个分组包括的至少一个申请项进行处理，以生成所述待处理对象的至少一组对象数据。

本实施例中，通过对申请项进行分组，针对各个分组包括的申请项进行处理，以生成对象数据，可以实现以分组为粒度的处理，由于在数据处理时不仅考虑了属性限制信息，还考虑了分组，从而数据处理方式更精细化，可以提高数据处理效果。

一些实施例中，所述生成模块1203进一步用于：针对所述各个分组：对所述各个分组包括的至少一个申请项中各个申请项，进行数据预处理，以获得各个预处理后的申请项；基于所述待处理对象的属性限制信息，对所述各个预处理后的申请项进行处理，以生成所述待处理对象的至少一组对象数据。

通过对申请项进行数据预处理，可以使得预处理后的申请项满足属性限制信息，为后续更合理、有效地生成对象数据提供数据基础。

数据预处理方式可以包括一种或多种，从而可以根据实际情况进行更合理有效的数据预处理，提高预处理后的申请项的准确度。

一些实施例中，所述生成模块1203进一步用于：针对所述各个申请项：若所述申请项的资源单价的小数位数小于或等于预设小数位数，保持所述申请项不变，作为第一预处理后的申请项；或者，若所述申请项的资源单价的小数位数大于预设小数位数，将所述申请项拆分为两个申请项，作为第一预处理后的申请项。

针对第一预处理，可以解决资源单价的小数位数超过属性限制信息的问题。

一些实施例中，所述生成模块1203进一步用于：针对所述第一预处理后的申请项：若所述第一预处理后的申请项的资源单价小于或等于金额上限，保持所述第一预处理后的申请项不变，作为第二预处理后的申请项；若所述第一预处理后的申请项的资源单价大于金额上限，将所述第一预处理后的申请项拆分为两个申请项，作为第二预处理后的申请项。

针对第二预处理，可以解决资源单价大于金额上限且申请项金额的小数位数超过属性限制信息的问题。

一些实施例中，所述生成模块1203进一步用于：基于所述待处理对象的属性限制信息，对所述各个预处理后的申请项，执行至少一次的生成过程，以生成所述至少一次中各次生成过程对应的所述待处理对象的至少一组对象数据；其中，针对所述各次生成过程，执行：在所述各个预处理后的申请项中，确定所述各次生成过程对应的待处理申请项；基于所述待处理对象的属性限制信息，对所述待处理申请项进行处理，以生成所述至少一组对象数据。

本实施例中，针对各个分组，可以以分组为粒度进行数据处理。并且，针对各个分组，可以执行至少一次的生成过程，每次生成过程可以生成一组或多组的对象数据，由于可以执行一次或多次生成过程，从而生成过程更准确和全面，进而可以生成准确、全面的对象数据。

一些实施例中，所述属性限制信息包括金额上限，所述待处理申请项包括申请项金额，所述生成模块1203进一步用于：若所述待处理申请项的资源单价小于或等于所述金额上限，执行：基于所述申请项金额，按序累加整数个待处理申请项，直至达到累加结束条件，所述累加结束条件包括：不超过所述属性限制信息，且与所述属性限制信息最接近；以及，将达到所述累加结束条件的所述整数个待处理申请项，合并为一组对象数据。

由于按照申请项金额，按序累加待处理申请项，可以累加尽量多的申请项金额较大的申请项，因此，可以获得总金额更接近金额上限的同组对象数据，可以提高资源利用率。另外，通过累加整数个待处理申请项，可以以申请项为粒度进行累加，而在累加时并不需要对申请项进行拆分，可以简化操作，提高效率。

一些实施例中，所述属性限制信息包括金额上限，所述生成模块1203进一步用于：若所述待处理申请项的资源单价大于所述金额上限，将所述待处理申请项拆分为至少一个拆分申请项，作为所述至少一组对象数据。

由于资源单价超过金额上限，即超过属性限制信息，此时，通过对待处理申请项进行拆分，可以避免待处理申请项的相关信息超过属性限制信息，满足实际对象数据的要求。

一些实施例中，所述拆分申请项包括：第一拆分申请项和第二拆分申请项，所述生成模块1203进一步用于：若所述资源单价为整数，执行：针对所述第一拆分申请项，将所述金额上限作为所述第一拆分申请项的申请项金额；以及，基于所述金额上限和所述待处理申请项的资源单价，确定所述第一拆分申请项的资源数量；针对所述第二拆分申请项，基于所述待处理申请项的资源数量和所述第一拆分申请项的资源数量，确定所述第二拆分申请项的资源数量；以及，基于所述待处理申请项的资源单价和所述第二拆分申请项的资源数量，确定所述第二拆分申请项的申请项金额。

在资源单价为整数时，基于金额上限进行拆分，可以使得第一拆分申请项的申请项金额为金额上限，提高资源利用率，并且，可以将待处理申请项拆分为尽量少的拆分申请项，可以降低资源开销。

一些实施例中，所述拆分申请项包括：第三拆分申请项、第四拆分申请项和第五拆分申请项，所述生成模块1203进一步用于：若所述资源单价包含小数部分，执行：将去掉小数的资源单价作为新资源单价；针对所述第三拆分申请项，基于所述金额上限和所述新资源单价，确定所述第三拆分申请项的资源数量；以及，基于所述第三拆分申请项的资源数量和所述新资源单价，确定所述第三拆分申请项的申请项金额；针对所述第四拆分申请项，基于所述待处理申请项的资源数量和所述第三拆分申请项的资源数量，确定所述第四拆分申请项的资源数量；以及，基于所述新资源单价和所述第四拆分申请项的资源数量，确定所述第四拆分申请项的申请项金额；针对所述第五拆分申请项，将所述第五拆分申请项的资源数量确定为1，以及，基于所述待处理申请项的资源单价的小数部分以及所述待处理申请项的资源数量，确定所述第五拆分申请项的申请项金额。

在资源单价包含小数时，基于金额上限进行拆分，可以使得第三拆分申请项的申请项金额尽量接近金额上限，提高资源利用率，并且，可以将待处理申请项拆分为尽量少的拆分申请项，可以降低资源开销。另外，小数部分单独拆分为一个拆分申请项，可以保证整体的拆分申请项的总金额的准确性，从而可以获得更准确、资源利用率更高、资源开销更少的对象数据。

一些实施例中，所述申请信息包括的至少一个申请项中各个申请项包括：所述待处理对象对应的申请对象的标识信息。

通过在申请项中包括申请对象的标识信息，可以实现针对申请对象的批量申请，相对于一次仅能针对一个申请对象的申请方式，可以简化操作，适合复杂的申请场景。

可以理解的是，本公开实施例中，不同实施例中的相同或相似内容可以相互参考。

可以理解的是，本公开实施例中的“第一”、“第二”等只是用于区分，不表示重要程度高低、时序先后等。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图13示出了可以用来实施本公开的实施例的示例电子设备1300的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字助理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图13所示，电子设备1300包括计算单元1301，其可以根据存储在只读存储器(ROM)1302中的计算机程序或者从存储单元1308加载到随机访问存储器(RAM)1303中的计算机程序，来执行各种适当的动作和处理。在RAM 1303中，还可存储电子设备1300操作所需的各种程序和数据。计算单元1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

电子设备1300中的多个部件连接至I/O接口1305，包括：输入单元1306，例如键盘、鼠标等；输出单元1307，例如各种类型的显示器、扬声器等；存储单元1308，例如磁盘、光盘等；以及通信单元1309，例如网卡、调制解调器、无线通信收发机等。通信单元1309允许电子设备1300通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1301可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1301的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1301执行上文所描述的各个方法和处理，例如数据处理方法。例如，在一些实施例中，数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或者全部可以经由ROM1302和/或通信单元1309而被载入和/或安装到电子设备1300上。当计算机程序加载到RAM 1303并由计算单元1301执行时，可以执行上文描述的数据处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1301可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。