CN107437228B - 数据处理方法及装置 - Google Patents

Abstract

本申请提供了一种数据处理方法及装置，该数据处理方法包括：判断用户提交的初始数据处理申请信息是否满足预设条件；如果否，提示用户选择进入设定期限进行信息补充；判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；若累计数据处理申请信息满足所述预设条件，对所述累计数据处理申请信息进行数据处理。利用本申请，可以防止理财产品订单的流失，提高理财产品申购效率。

Description

数据处理方法及装置

技术领域

本发明涉及金融数据处理技术领域，特别涉及一种数据处理方法及装置。

背景技术

现有的理财产品数据处理业务中，要求用户在当前业务数据处理申请时点下提供的申请信息满足一定的设定条件，当用户发生支付困难，用户提供的申请信息将不满足该设定条件，可能会导致业务数据处理申请中断，造成本次数据处理业务失败，浪费了系统资源，降低了业务数据处理申请的成功率。

发明内容

本申请实施例提供一种数据处理方法，包括：

判断用户提交的初始数据处理申请信息是否满足预设条件；

如果否，提示用户选择进入设定期限进行信息补充；

判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；

若累计数据处理申请信息满足所述预设条件，对所述累计数据处理申请信息进行数据处理。

本申请实施例还提供一种数据处理装置，包括：

第一判断单元，用于判断用户提交的初始数据处理申请信息是否满足预设条件；

提示单元，当所述初始数据处理申请信息不满足预设条件时，用于提示用户选择进入设定期限进行信息补充；

第二判断单元，用于判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；

数据处理单元，当累计数据处理申请信息满足所述预设条件时，用于对所述累计数据处理申请信息进行数据处理。

本申请实施例还提供一种理财产品申购方法，包括：

判断用户申购的理财产品的初始申购金额是否满足起购金额要求；

当所述初始申购金额不满足起购金额要求时，提示所述用户选择发起募集待购，进入募集待购期；

判断所述理财产品的累计申购金额是否满足起购金额要求，所述累计申购金额为所述募集待购期内增加的申购金额与所述初始申购金额之和；

当所述累计申购金额满足起购金额要求时，执行该理财产品的代扣支付及申购操作。

本申请实施例还提供一种理财产品申购装置，包括：

第一判断单元，用于判断用户申购的理财产品的初始申购金额是否满足起购金额要求；

提示单元，用于当所述初始申购金额不满足起购金额要求时提示所述用户选择发起募集待购，进入募集待购期；

第二判断单元，用于判断所述理财产品的累计申购金额是否满足起购金额要求，所述累计申购金额为所述募集待购期内增加的申购金额与所述初始申购金额之和；

申购执行单元，用于当所述累计申购金额满足起购金额要求时执行该理财产品的代扣支付及申购操作。

本申请实施例中，对于申购金额不满足起购金额要求的情况下，提示用户选择发起募集待购，可以减少由于用户当前资金不足导致的订单流失，提高了理财产品申购效率。

当然实施本申请的任一产品或者方法必不一定需要同时达到以上所述的所有优点。

附图说明

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

图1为本申请一实施例的数据处理方法流程图；

图2为本申请另一实施例的数据处理方法流程图；

图3为本申请一实施例的数据装置结构示意图；

图4为本申请另一实施例的数据装置结构示意图；

图5为本申请一实施例的理财产品申购方法流程图；

图6为本申请另一实施例的理财产品申购方法流程图；

图7为本申请一实施例的理财产品申购装置结构示意图；

图8为本申请另一实施例的理财产品申购装置结构示意图；

图9为本申请实施例的理财产品申购业务流程图。

具体实施方式

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

图1所示为本申请实施例的数据处理方法流程图，该方法可以应用于客户端与交易处理端之间的理财产品数据处理业务，客户端可以是PC或用户持有的智能终端，交易处理端可以为银行后台服务器，本实施例将以用户持有的智能终端与银行后台服务器之间的数据处理过程进行说明，具体包括如下步骤：

S101：判断用户提交的初始数据处理申请信息是否满足预设条件；

S102：如果否，提示用户选择进入设定期限进行信息补充；

S103：判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；

S104：若累计数据处理申请信息满足所述预设条件，对所述累计数据处理申请信息进行数据处理。

图1所示的S101至S104中，执行主体可以为银行后台服务器。其中，S101中，执行主体可以为用户持有的智能终端，也可以为银行后台服务器，即S101中，可以由用户持有的智能终端对提交的初始数据处理信息进行初步判断，也可以由银行服务器对用户提交的初始数据处理信息进行判断。

需要说明书的是，S101中，用户提交的初始数据处理申请信息并非限定用户首次提交的数据处理申请信息，也可以是用户在某一时间节点前多次提交的数据处理申请信息的叠加。

作为本申请的一个实施例，初始数据处理申请信息可以为用户申购理财产品的初始申购金额，预设条件可以为起购金额，累计数据处理申请信息可以为用户申购该理财产品的累计申购金额，对累计数据处理申请信息进行数据处理可以为执行该理财产品的代扣支付及申购操作。

由图1所示的流程可知，本申请实施例中，判断初始数据处理申请信息不满足预设条件时，可以提示用户进入设定期限进行信息补充；在设定期限内，如果用户递交的累计数据处理申请信息满足预设条件，可以对累计数据处理申请信息进行数据处理。通过该数据处理方法，可以为用户提供一个申请数据处理的“宽限期”，提高了数据处理效率。

一实施例中，上述设定期限可以为固定期限；该固定期限可以为银行后台服务器给定的期限，银行后台服务器可以给定一个期限(例如1个月)，也可以给定多个期限(例如给出1个月、3个与、6个月三个期限)供用户选择，用户可以选择其中的一个期限作为设定。当设定期限届满后，判断用户递交的累计数据处理申请信息是否满足预设条件。若累计数据处理申请信息满足预设条件，对累计数据处理申请信息进行数据处理。如果累计数据处理申请信息仍然不满足预设条件，则无法进行数据处理。本实施例中，通过该设定期限，可以提高数据处理效率，避免资源浪费。

一实施例中，上述设定期限可以为非固定期限，而因应用户递交的累计数据处理申请信息满足预设条件而终止。即设定期限的结束以累计数据处理申请信息是否满足预设条件为要件。当收到用户提交的数据处理申请补充信息时，判断用户提交的累计数据处理申请信息是否满足预设条件，如果累计数据处理申请信息满足预设条件，则对累计数据处理申请信息进行数据处理，该设定期限结束。如果累计数据处理申请信息不满足预设条件，该设定期限可以不终止，用户还可以继续提交数据处理申请补充信息，直至累计数据处理申请信息满足预设条件，对累计数据处理申请信息进行数据处理。本实施例中，为用户提供了更长的“宽限期”，更好的解决了数据处理效率低的问题，节省了资源。

需要说明的是，虽然上述设定期限可以为非固定的期限，但是并非限定只有累计数据处理申请信息满足预设条件该期限才可以终止，银行后台服务器可以根据具体情况终止该期限。

一实施例中，银行可以与用户签订数据处理协议，银行后台服务器可以根据用户签订的数据处理协议执行数据处理操作。基于与用户签订的数据处理协议执行数据处理操作，保证了交易的安全性。

一实施例中，用户在所述设定期限内提交的数据处理申请补充信息包括：用户直接提交的数据处理申请补充信息及通过其他用户提交的数据处理申请补充信息。

一实施例中，如图2所示，本申请的数据处理方法还包括：

S201：将所述数据处理申请补充信息加入用于标识信息用途的场景码；

当银行后台服务器接收到用户直接提交的数据处理申请补充信息及通过其他用户提交的数据处理申请补充信息之后，可以为数据处理申请补充信息加入特定的场景码，用以标识该数据处理申请补充信息的用途，场景码中可以包含业务信息，不同的场景码对应不同的业务信息，通过在数据处理申请补充信息中加入场景码，可以提高了交易的安全性及稳定性。

S202：冻结加入所述场景码的所述数据处理申请补充信息。

冻结加入所述场景码数据处理申请补充信息，可以保证了数据处理的安全性。

本申请实施例的理财产品申购方法中，可以为用户提供一个申请数据处理的“宽限期”，提高了数据处理效率。

基于与图1所示的数据处理方法相同的发明构思，本申请实施例还提供了一种数据处理装置，如下面的实施例所述。由于该数据处理装置解决问题的原理与数据处理方法相似，因此该数据处理装置的实施可以参见数据处理方法的实施，重复之处不再赘述。

图3为本申请实施例的数据处理装置结构示意图，如图3所示，该数据处理装置包括：第一判断单元301，提示单元302，第二判断单元303及数据处理单元304。

第一判断单元301用于判断用户提交的初始数据处理申请信息是否满足预设条件；

当所述初始数据处理申请信息不满足预设条件时，提示单元302用于提示用户选择进入设定期限进行信息补充；

第二判断单元303用于判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；

当累计数据处理申请信息满足所述预设条件时，数据处理单元304用于对所述累计数据处理申请信息进行数据处理。

一实施例中，上述设定期限可以为固定期限；该固定期限可以为银行后台服务器给定的期限，银行后台服务器可以给定一个期限(例如1个月)，也可以给定多个期限(例如给出1个月、3个与、6个月三个期限)供用户选择，用户可以选择其中的一个期限作为设定。当固定期限届满后，第二判断单元303具体用于判断用户递交的累计数据处理申请信息是否满足预设条件。若累计数据处理申请信息满足预设条件，数据处理单元304对累计数据处理申请信息进行数据处理。如果累计数据处理申请信息仍然不满足预设条件，则无法进行数据处理。本实施例中，通过该设定期限，可以提高数据处理效率，避免资源浪费。

一实施例中，上述设定期限可以为非固定期限，而因应用户递交的累计数据处理申请信息满足预设条件而终止。即设定期限的结束以累计数据处理申请信息是否满足预设条件为要件。当收到用户提交的数据处理申请补充信息时，第二判断单元303判断用户提交的累计数据处理申请信息是否满足预设条件，如果累计数据处理申请信息满足预设条件，数据处理单元304对累计数据处理申请信息进行数据处理，该设定期限结束。如果累计数据处理申请信息不满足预设条件，该设定期限可以不终止，用户还可以继续提交数据处理申请补充信息，直至累计数据处理申请信息满足预设条件，对累计数据处理申请信息进行数据处理。本实施例中，为用户提供了更长的“宽限期”，更好的解决了数据处理效率低的问题，节省了资源。

一实施例中，用户在设定期限内提交的数据处理申请补充信息包括：用户直接提交的数据处理申请补充信息及通过其他用户提交的数据处理申请补充信息。

图4为本申请实施例的数据处理装置另一结构示意图，如图4所示，该数据处理装置还包括：第一判断单元301，提示单元302，第二判断单元303，数据处理单元304，场景码加入单元401及信息冻结单元402。

场景码加入单元401用于将所述数据处理申请补充信息加入用于标识信息用途的场景码；

当银行后台服务器收到数据处理申请补充信息之后，场景码加入单元401可以为数据处理申请补充信息加入特定的场景码，用以标识该信息的用途，场景码中可以包含业务信息，不同的场景码对应不同的业务信息，通过为用户充值金额及他人转账金额加入场景码，可以防止发生资金混了，提高了交易的安全性及稳定性。

信息冻结单元402用于冻结加入场景码的所述数据处理申请补充信息。冻结信息，可以保证信息的安全性。

一实施例中，银行可以与用户签订代扣协议，数据处理单元304可以根据用户签订的数据处理协议执行累计数据处理申请信息的数据处理操作。基于与用户签订的数据处理协议执行该累计数据处理申请信息的数据处理操作，保证了交易的安全性。

利用本申请实施例的数据处理装置，可以为用户提供一个申请数据处理的“宽限期”，提高了数据处理效率。

下面以理财产品申购的技术实现过程详细进行说明。

用户在申购理财产品时，需要选定理财产品并充值。现有技术中，充值金额需要大于该理财产品要求的起购金额，用户才能购买该购买理财产品，也就是说如果用户的充值金额小于该起购金额，申购该购买理财产品的订单将流失。为了解决订单流失的问题，本申请提供了一种理财产品申购方法。图1为本申请实施例的理财产品申购方法流程图，如图5所示，该理财产品申购方法包括：

S501：判断用户申购的理财产品的初始申购金额是否满足起购金额要求；

S502：如果否，提示所述用户选择发起募集待购，进入募集待购期；

S503：判断所述理财产品的累计申购金额是否满足起购金额要求，所述累计申购金额为所述募集待购期内增加的申购金额与所述初始申购金额之和；

S504：当所述累计申购金额满足起购金额要求时，执行该理财产品的代扣支付及申购操作。

图5所示的S501至S504中，执行主体可以为银行后台服务器。其中，S501中，执行主体可以为用户持有的智能终端，也可以为银行后台服务器，即S501中，可以由用户持有的智能终端对初始申购金额进行初步判断，也可以由银行服务器对初始申购金额进行判断。

需要说明书的是，S501中，用户申购的理财产品的初始申购金额并非限定用户首次充值的申购金额，也可以是用户在某一时间节点前多次充值的申购金额的叠加。

由图5所示的流程可知，本申请实施例中，判断初始申购金额不满足起购金额要求时，提示用户选择发起募集待购，进入募集待购期；在募集待购期内，判断理财产品的累计申购金额是否满足起购金额要求，并在累计申购金额满足起购金额要求时执行该理财产品的代扣支付及申购操作。通过该理财产品申购方法，可以防止理财产品订单的流失，提高理财产品申购效率。

本申请实施例中，理财产品有很多种类，包括：基金、股票、国债、外汇等。

本申请实施例中，用户在申购理财产品时，同样需要选定理财产品并充值，充值金额可以称为初始申购金额，银行后台服务器在接收到该初始申购金额后，会将该初始申购金额转到余额宝或者理财产品的账户并冻结该初始申购金额。冻结该初始申购金额，可以防止该部分资金被动用，保证了资金的安全性。

冻结该初始申购金额后，银行后台服务器将会进行起购金额判断，判断该初始申购金额是否满足起购金额要求，若初始申购金额大于或者等于起购金额，则初始申购金额满足起购金额要求。当判断得到该初始申购金额满足起购金额要求时，则可以直接发起申购，用户成功购买该理财产品。

如果该初始申购金额不满足起购金额要求，将会询问用户是否选择发起募集待购，如果用户选择发起募集待购，则进入募集待购期。在该募集待购期内，用户可以通过多种方式增加申购金额，例如可以通过用户充值或者他人转账的方式增加申购金额，增加的申购金额与初始申购金额之和称为累计申购金额。当银行后台服务器判断累计申购金额满足起购金额要求时，可以执行该理财产品的代扣支付及申购操作，完成理财产品的申购。

一实施例中，上述募集待购期可以为设定期限，该设定期限可以为银行后台服务器给定的期限，银行后台服务器可以给定一个期限(例如1个月)作为募集待购期，也可以给定多个期限(例如给出1个月、3个与、6个月三个期限)供用户选择，用户可以选择其中的一个期限作为募集待购期。当上述募集待购期届满后，银行后台服务器判断理财产品的累计申购金额是否满足起购金额要求，如果累计申购金额满足起购金额要求，则执行该理财产品的代扣支付及申购操作。如果累计申购金额仍然不满足起购金额要求，则交易结束，订单失效。本实施例中，通过设定募集待购期，可以减少由于用户当前资金不足导致的订单流失，提高了理财产品申购效率。

一实施例中，上述募集待购期并非为固定的期限，该募集待购期可以因应理财产品的累计申购金额满足起购金额要求而终止，即募集待购期的结束以累计申购金额是否满足起购金额要求为条件。当理财产品的申购金额发生变动时，银行后台服务器判断变动后的累计申购金额是否满足起购金额要求，如果累计申购金额满足起购金额要求，则执行该理财产品的代扣支付及申购操作。如果累计申购金额不满足起购金额要求，上述募集待购期可以不终止，用户还可以继续增加申购金额，直至累计申购金额满足起购金额要求，执行该理财产品的代扣支付及申购操作。本实施例中，为用户提供了更长的资金准备期限，更好的解决了因为用户当前资金不足而导致订单流失的问题。

需要说明的是，虽然上述募集待购期可以为非固定的期限，但是并非限定只有累计申购金额满足起购金额要求该期限才可以终止，银行后台服务器可以根据用户的具体情况终止该期限。

一实施例中，银行可以与用户签订代扣协议，银行后台服务器可以根据用户签订的代扣协议执行该理财产品的代扣支付及申购操作。基于与用户签订的代扣协议执行该理财产品的代扣支付及申购操作，保证了交易的安全性。

一实施例中，用户在募集待购期增加的申购金额可以包括：用户充值金额及他人转账金额。

一实施例中，如图6所示，本申请的理财产品申购方法还包括：

S601：将所述用户充值金额及他人转账金额加入用于标识资金用途的场景码；

当银行后台服务器收到用户充值及他人转账之后，可以为用户充值金额及他人转账金额加入特定的场景码，用以标识该笔资金的用途，场景码中可以包含业务+订单信息。不同的场景码对应不同的订单信息，通过为用户充值金额及他人转账金额加入场景码，可以防止发生资金混了，提高了交易的安全性及稳定性。

S602：将所述用户充值金额及他人转账金额加入用于标识资金用途的场景码。

冻结用户充值金额及他人转账金额，可以防止该部分资金被动用，保证了资金的安全性。

本申请实施例的理财产品申购方法中，对于申购金额不满足起购金额要求的情况下，提示用户选择发起募集待购，可以减少由于用户当前资金不足导致的订单流失，提高了理财产品申购效率。

基于与图5所示的理财产品申购方法相同的发明构思，本申请实施例还提供了一种理财产品申购装置，如下面的实施例所述。由于该理财产品申购装置解决问题的原理与理财产品申购方法相似，因此该理财产品申购装置的实施可以参见理财产品申购方法的实施，重复之处不再赘述。

图7为本申请实施例的理财产品申购装置结构示意图，如图7所示，该理财产品申购装置包括：第一判断单元701，提示单元702，第二判断单元703及申购执行单元704。

第一判断单元701用于判断用户申购的理财产品的初始申购金额是否满足起购金额要求；

提示单元702用于当所述初始申购金额不满足起购金额要求时提示所述用户选择发起募集待购，进入募集待购期；

第二判断单元703用于判断所述理财产品的累计申购金额是否满足起购金额要求，所述累计申购金额为所述募集待购期内增加的申购金额与所述初始申购金额之和；

申购执行单元704用于当所述累计申购金额满足起购金额要求时执行该理财产品的代扣支付及申购操作。

一实施例中，上述募集待购期可以为设定期限，该设定期限可以为银行后台服务器给定的期限，银行后台服务器可以给定一个期限(例如1个月)作为募集待购期，也可以给定多个期限(例如给出1个月、3个与、6个月三个期限)供用户选择，用户可以选择其中的一个期限作为募集待购期。当上述募集待购期届满后，第二判断单元具703判断所述理财产品的累计申购金额是否满足起购金额要求，如果累计申购金额满足起购金额要求，申购执行单元704执行该理财产品的代扣支付及申购操作。如果累计申购金额仍然不满足起购金额要求，则交易结束，订单失效。本实施例中，通过设定募集待购期，可以减少由于用户当前资金不足导致的订单流失，提高了理财产品申购效率。

一实施例中，上述募集待购期并非为固定的期限，该募集待购期可以因应理财产品的累计申购金额满足起购金额要求而终止，即募集待购期的结束以累计申购金额是否满足起购金额要求为条件。当理财产品的申购金额发生变动(指金额在初始申购金额基础上增加)时，第二判断单元703判断变动后的累计申购金额是否满足起购金额要求，如果累计申购金额满足起购金额要求，申购执行单元704执行该理财产品的代扣支付及申购操作。如果累计申购金额不满足起购金额要求，上述募集待购期可以不终止，用户还可以继续增加申购金额，直至累计申购金额满足起购金额要求，执行该理财产品的代扣支付及申购操作。本实施例中，为用户提供了更长的资金准备期限，更好的解决了因为用户当前资金不足而导致订单流失的问题。

一实施例中，用户在募集待购期增加的申购金额可以包括：用户充值金额及他人转账金额。

图8为本申请实施例的理财产品申购装置另一结构示意图，如图8所示，该理财产品申购装置包括：第一判断单元701，提示单元702，第二判断单元703，申购执行单元704，场景码加入单元801及资金冻结单元802。

场景码加入单元801用于将所述用户充值金额及他人转账金额加入用于标识资金用途的场景码；

当银行后台服务器收到用户充值及他人转账之后，场景码加入单元401可以为用户充值金额及他人转账金额加入特定的场景码，用以标识该笔资金的用途，场景码中可以包含业务+订单信息。不同的场景码对应不同的订单信息，通过为用户充值金额及他人转账金额加入场景码，可以防止发生资金混了，提高了交易的安全性及稳定性。

资金冻结单元802用于冻结加入所述场景码的所述用户充值金额及他人转账金额。冻结用户充值金额及他人转账金额，可以防止该部分资金被动用，保证了资金的安全性。

一实施例中，银行可以与用户签订代扣协议，申购执行单元704可以根据用户签订的代扣协议执行该理财产品的代扣支付及申购操作。基于与用户签订的代扣协议执行该理财产品的代扣支付及申购操作，保证了交易的安全性。

利用本申请实施例的理财产品申购装置，可以减少由于用户当前资金不足导致的订单流失，提高了理财产品申购效率。

为了更清楚的说明本申请，下面结合具体的申购业务进行描述。图9为本申请实施例的理财产品申购业务流程图。如图9所示，理财产品申购业务流程包括如下步骤：

S901：用户通过终端选定理财产品并充值，充值金额可以称为理财产品的初始申购金额。

S902：银行后台服务器将充值金额转入到理财产品账户并冻结该部分充值金额，理财产品账户可以为余额宝、基金账户等。将充值金额冻结，可以防止该部分资金被动用，保证了资金的安全性。

S903：银行后台服务器判断用户申购的理财产品的充值金额是否满足起购金额要求，如果是，执行步骤S904，否则，执行步骤S908。

S904：提示用户是否选择进入募集待购期。在该募集待购期，用户可以进行募集待购。如果用户选择进入募集待购期，则执行募集待购操作，如果用户不选择进入募集待购期，本次交易结束。

S905：募集待购。该步骤中，可以通过用户自己充值或者他人转账的方式增加申购金额，使得累计申购金额满足起购金额。增加的申购金额需要加入场景码，该场景码中可以包含业务+订单信息，用于标识资金用途。

募集待购期前，都可进行募集待购操作，一实施例中，上述募集待购期可以为设定期限，该设定期限可以为银行后台服务器给定的期限，银行后台服务器可以给定一个期限(例如1个月)作为募集待购期，也可以给定多个期限(例如给出1个月、3个与、6个月三个期限)供用户选择，用户可以选择其中的一个期限作为募集待购期。当上述募集待购期届满前，用户都可进行募集待购操作，通过自己充值或者他人转账的方式增加申购金额。

另一实施例中，上述募集待购期并非为固定的期限，该募集待购期可以因应理财产品的累计申购金额满足起购金额要求而终止，即募集待购期的结束以累计申购金额是否满足起购金额要求为条件，因此用户可以随时通过自己充值或者他人转账的方式增加申购金额。

S906：判断累计申购金额是否满足起购金额。

如果累计申购金额满足起购金额，则进行S907，发起代扣。

对于募集待购期为设定期限的情况，在募集待购期届满后，如果累计申购金额不满足起购金额，则交易失败，结束交易。对于募集待购期并非为固定的期限的情况，只要累计申购金额在原始申购金额的基础上增加，就需要判断累计申购金额是否满足起购金额，如果累计申购金额不满足起购金额，可以结束交易，也可以继续处于募集待购状态，等待用户后续加入申购资金。

S907：发起代扣。可以根据与用户签订的代扣协议发起代扣操作。

S908：发起申购，购买用户选定的理财产品。

本申请实施例中，对于申购金额不满足起购金额要求的情况下，提示用户选择发起募集待购，可以减少由于用户当前资金不足导致的订单流失，提高了理财产品申购效率。

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

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

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

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

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (8)

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

判断用户提交的初始数据处理申请信息是否满足预设条件；所述初始数据处理申请信息包括理财产品的初始申购金额；

如果否，提示用户选择进入设定期限进行信息补充；所述提示用户选择进入设定期限进行信息补充包括：提示所述用户选择发起募集待购，进入募集待购期；

判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；

若累计数据处理申请信息满足所述预设条件，对所述累计数据处理申请信息进行数据处理；

用户在所述设定期限内提交的数据处理申请补充信息包括：用户直接提交的数据处理申请补充信息及通过其他用户提交的数据处理申请补充信息，所述用户直接提交的数据处理申请补充信息包括用户充值金额，所述通过其他用户提交的数据处理申请补充信息包括他人转账金额，所述数据处理方法还包括：

将所述用户充值金额及他人转账金额加入用于标识信息用途的场景码；场景码中包含业务信息，不同的场景码对应不同的业务信息；

冻结加入所述场景码的所述用户充值金额及他人转账金额。

2.根据权利要求1所述的数据处理方法，其特征在于，所述设定期限为固定期限；判断用户递交的累计数据处理申请信息是否满足所述预设条件，包括：

当所述设定期限届满后，判断用户递交的累计数据处理申请信息是否满足所述预设条件。

3.根据权利要求1所述的数据处理方法，其特征在于，所述设定期限因应用户递交的累计数据处理申请信息满足所述预设条件而终止；判断用户递交的累计数据处理申请信息是否满足所述预设条件，包括：

当收到用户提交的数据处理申请补充信息时，判断用户提交的累计数据处理申请信息是否满足所述预设条件。

4.根据权利要求1所述的数据处理方法，其特征在于，对所述累计数据处理申请信息进行数据处理，包括：根据用户签订的数据处理协议对所述累计数据处理申请信息进行数据处理。

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

第一判断单元，用于判断用户提交的初始数据处理申请信息是否满足预设条件；所述初始数据处理申请信息包括理财产品的初始申购金额；

提示单元，当所述初始数据处理申请信息不满足预设条件时，用于提示用户选择进入设定期限进行信息补充；所述提示用户选择进入设定期限进行信息补充包括：提示所述用户选择发起募集待购，进入募集待购期；

第二判断单元，用于判断用户递交的累计数据处理申请信息是否满足所述预设条件，所述累计数据处理申请信息包括所述初始数据处理申请信息及用户在所述设定期限内提交的数据处理申请补充信息；

数据处理单元，当累计数据处理申请信息满足所述预设条件时，用于对所述累计数据处理申请信息进行数据处理；

用户在所述设定期限内提交的数据处理申请补充信息包括：用户直接提交的数据处理申请补充信息及通过其他用户提交的数据处理申请补充信息，所述用户直接提交的数据处理申请补充信息包括用户充值金额，所述通过其他用户提交的数据处理申请补充信息包括他人转账金额，所述数据处理装置还包括：

场景码加入单元，用于将所述用户充值金额及他人转账金额加入用于标识信息用途的场景码；场景码中包含业务信息，不同的场景码对应不同的业务信息；

信息冻结单元，用于冻结加入所述场景码的所述用户充值金额及他人转账金额。

6.根据权利要求5所述的数据处理装置，其特征在于，所述设定期限为固定期限；所述第二判断单元具体用于：

当所述设定期限届满后，判断用户递交的累计数据处理申请信息是否满足所述预设条件。

7.根据权利要求5所述的数据处理装置，其特征在于，所述设定期限因应用户递交的累计数据处理申请信息满足所述预设条件而终止；所述第二判断单元具体用于：

当收到用户提交的数据处理申请补充信息时，判断用户提交的累计数据处理申请信息是否满足所述预设条件。

8.根据权利要求5所述的数据处理装置，其特征在于，数据处理单元具体用于：根据用户签订的数据处理协议对所述累计数据处理申请信息进行数据处理。

Images