CN111445332A - 一种数据处理方法、装置及服务器 - Google Patents

Abstract

本发明提供一种数据处理方法、装置及服务器，包括：获取交易数据，交易数据指示向具有第一身份标识的第一用户发送特定金额，特定金额由具有第二身份标识的第二用户汇总出且第二用户和第一用户是合作关系；确定与交易数据对应的交易方式，根据交易方式，向用于处理交易数据的服务器发送交易指令，以由服务器根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，接收由第二用户绑定的终端发送的开票申请请求，向税控盘发送开票申请请求，以使税控盘根据开票申请请求中携带的开票信息进行开票操作，实现由对接多个第二用户的对公账户的第三用户绑定的服务器完成，简化并统一交易数据处理和开票申请流程。

Description

一种数据处理方法、装置及服务器

技术领域

本发明涉及数据处理技术领域，具体涉及一种数据处理方法、装置及服务器。

背景技术

目前随着技术的发展和人们对生活水平要求的提高，出现越来越多的个体经营者，个体经营者和企业可以称为合作关系，个体经营者虽然可以完成企业指派的工作，但是个体经营者不是内部员工，在为这部分个体经营者发放需要企业的对公账户开启对私转账功能，这样企业的对公账户才能够给个体经营者的账户转账。

发明内容

有鉴于此，本发明实施例提供一种数据处理方法、装置及服务器，用于简化并统一交易数据处理和开票申请流程。

一方面，本发明提供一种数据处理方法，所述方法包括：

获取交易数据，所述交易数据用于指示向具有第一身份标识的第一用户发放特定金额，所述特定金额由具有第二身份标识的第二用户汇总出，且所述第二用户和所述第一用户是合作关系；

确定与所述交易数据对应的交易方式；

根据所述交易方式，向用于处理所述交易数据的服务器发送交易指令，以由所述服务器根据所述交易指令，从具有第三身份标识的第三用户的对公账户中转移所述特定金额至所述第一用户的个人账户中，所述第三用户的对公账户中的金额来源于所述第二用户的对公账户；

接收开票申请请求，所述开票申请请求由所述第二用户绑定的终端发送；

向税控盘发送开票申请请求，以使所述税控盘根据所述开票申请请求中携带的开票信息进行开票操作。

可选的，所述方法还包括：

对所述交易数据进行校验，以验证所述交易数据是否有效；

若验证所述交易数据有效，触发执行所述确定与所述交易数据对应的交易方式的步骤。

可选的，所述对所述交易数据进行校验，以验证所述交易数据是否有效包括：

从所述交易数据中提取所述第一身份标识和所述第一用户的个人账户的账户信息；

若所述第一身份标识和所述账户信息与已有用户信息中的身份标识和账户信息一致，验证所述交易数据有效。

可选的，所述方法还包括：

响应开票申请请求，向所述第二用户绑定的终端发送开票界面数据，所述开票界面数据用于在所述终端上显示开票界面；

获取所述第二用户在所述开票界面中输入的开票信息；

若验证所述开票信息有效，触发执行所述向税控盘发送开票申请请求的步骤。

可选的，所述若验证所述开票信息有效，触发执行所述向税控盘发送开票申请请求的步骤包括：

若验证所述开票信息中的第二身份标识与已有用户信息中的身份标识一致，触发执行所述向税控盘发送开票申请请求的步骤。

可选的，所述交易方式包括：银行交易方式、支付宝交易方式和微信交易方式中的至少一种。

另一方面，本发明还提供一种数据处理装置，所述装置包括：

获取单元，用于获取交易数据，所述交易数据用于指示向具有第一身份标识的第一用户发放特定金额，所述特定金额由具有第二身份标识的第二用户汇总出，且所述第二用户和所述第一用户是合作关系；

确定单元，用于确定与所述交易数据对应的交易方式；

发送单元，用于根据所述交易方式，向用于处理所述交易数据的服务器发送交易指令，以由所述服务器根据所述交易指令，从具有第三身份标识的第三用户的对公账户中转移所述特定金额至所述第一用户的个人账户中，所述第三用户的对公账户中的金额来源于所述第二用户的对公账户；

接收单元，用于接收开票申请请求，所述开票申请请求由所述第二用户绑定的终端发送；

所述发送单元，还用于向税控盘发送开票申请请求，以使所述税控盘根据所述开票申请请求中携带的开票信息进行开票操作。

可选的，所述发送单元，还用于响应开票申请请求，向所述第二用户绑定的终端发送开票界面数据，所述开票界面数据用于在所述终端上显示开票界面；

所述获取单元，还用于获取所述第二用户在所述开票界面中输入的开票信息，并且若所述开票信息有效，触发所述发送单元向税控盘发送开票申请请求。

可选的，所述装置还包括：校验单元，用于对所述交易数据进行校验，以验证所述交易数据是否有效，并且若验证所述交易数据有效，触发所述确定单元。

再一方面，本发明还提供一种服务器，所述服务器包括：处理器和通信装置；

所述处理器，用于获取交易数据，确定与所述交易数据对应的交易方式，所述交易数据用于指示向具有第一身份标识的第一用户发放特定金额，所述特定金额由具有第二身份标识的第二用户汇总出，且所述第二用户和所述第一用户是合作关系；

所述处理器，还用于根据所述交易方式，通过所述通信装置向用于处理所述交易数据的服务器发送交易指令，以由用于处理所述交易数据的服务器根据所述交易指令，从具有第三身份标识的第三用户的对公账户中转移所述特定金额至所述第一用户的个人账户中，所述第三用户的对公账户中的金额来源于所述第二用户的对公账户；

所述处理器，还用于在通过所述通信装置接收到开票申请请求后，通过所述通信装置向税控盘发送开票申请请求，所述开票申请请求由所述第二用户绑定的终端发送，以使所述税控盘根据所述开票申请请求中携带的开票信息进行开票操作。

从上述技术方案可知，获取交易数据，交易数据用于指示向具有第一身份标识的第一用户发送特定金额，特定金额由具有第二身份标识的第二用户汇总出且第二用户和第一用户是合作关系；确定与交易数据对应的交易方式，根据交易方式，向用于处理交易数据的服务器发送交易指令，以由服务器根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，实现由第三用户的对公账户向第一用户的个人账户进行转账操作，这样第二用户的对公账户就不需要开通对私转账功能且第三用户的对公账户可以对接多个第二用户的对公账户，从而借助第三用户的对公账户实现没有开通对私转账功能的对公账户向个人账户的转账。并且还可以接收由第二用户绑定的终端发送的开票申请请求，向税控盘发送开票申请请求，以使税控盘根据开票申请请求中携带的开票信息进行开票操作，这样第二用户绑定的终端就无需与税控盘连接，统一由对接多个第二用户的对公账户的第三用户绑定的服务器连接税控盘进行开票操作，实现由对接多个第二用户的对公账户的第三用户绑定的服务器统一完成多个第二用户的对公账户交易数据处理和多个第二用户的开票申请，这些多个第二用户的对公账户就无需开通对私转账功能且多个第二用户绑定的终端也无需连接税控盘，简化并统一交易数据处理和开票申请流程。

附图说明

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

图1为本发明实施例提供的数据处理方法对应的数据处理系统的架构图；

图2为本发明实施例提供的一种数据处理方法的流程图；

图3为本发明实施例提供的一种数据处理装置的结构示意图。

具体实施方式

目前对公账户在向个人账户转账之前需要开启对私转账功能，对私转账功能会降低对公账户的账户安全，且对公账户在进行转账之后需要开具发票进行抵税，这就需要对公账户对应的设备(如终端或服务器)与税控盘进行连接，那么对于每个需要向个人账户转账的对公账户都需要开启对私转账功能且对应设备都需要与税控盘进行连接。为此本发明实施例提供一种数据处理方法，能够通过一个中间的对公账户辅助向个人账户转账且由中间的对公账户对应的服务器进行开票操作，相对应的数据处理系统的架构图如图1所示，可以包括：第一服务器10、第二服务器20、第三服务器30和税控盘40。

第一服务器10，用于处理具有第二身份标识的第二用户的对公账户和具有第三身份标识的第三用户的对公账户之间的交易，第二用户的对公账户和第三用户的对公账户之间的交易为对公转账，第二用户的对公账户和第三用户的对公账户之间的对公转账的交易方式可以是银行交易方式、微信交易方式和支付宝交易方式中的至少一种，则第一服务器10是第二用户的对公账户和第三用户的对公账户之间进行转帐所采用的交易方式对应的服务器。

第二服务器20，用于处理具有第一身份标识的第一用户的个人账户和具有第三身份标识的第三用户的对公账户之间的交易，第三用户的对公账户和第一用户的个人账户之间的交易为对私转账，说明第三用户的对公账户开启了对私转账功能，同样的第三用户的对公账户和第一用户的个人账户之间的对私转账的交易方式可以是银行交易方式、微信交易方式和支付宝交易方式中的至少一种，则第二服务器20是第三用户的对公账户和第一用户的个人账户之间进行转帐所采用的交易方式对应的服务器。

第三服务器30，用于在获取到指示向第一用户发放特定金额的交易数据的情况下，指示第二服务器20完成第三用户的对公账户向第一用户的个人账户转账特定金额，并与税控盘40连接，完成第二用户的开票申请。交易数据以及开票申请操作可以是由第二用户绑定的设备(如终端或服务器)发送。

例如上述图1所示的数据处理系统中，第一用户是一个个体经营者，第二用户和第三用户分别是一个企业，作为第二用户的企业通过作为第三用户的企业的对公账户向个体经营者的账户转账，且在作为第三用户的企业转账之后，由作为第三用户的企业申请开票以向作为第二用户的企业开具发票，并且由作为第三用户的企业给作为第一用户的个体经营者进行纳税申报和提供纳税凭证。

基于上述图1所示的数据处理系统，本实施例提供一种数据处理方法，该数据处理方法应用于上述数据处理系统中的第三服务器30中，即具有第三身份标识的第三用户绑定的服务器，通过数据处理方法来完成向第三用户的个人账户的转账以及开票。

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

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

请参阅图2，其示出了本发明实施例提供的一种数据处理方法的流程图，用于简化并统一交易数据处理和开票申请流程，可以包括以下步骤：

201：获取交易数据，其中交易数据用于指示向具有第一身份标识的第一用户发放特定金额，特定金额由具有第二身份标识的第二用户汇总出，且第二用户和第一用户是合作关系，第一用户完成第二用户指派的工作。例如第一用户是一个企业，第二用户是一个个体经营者。

在本实施例中，第一身份标识和第二身份标识用于对第一用户和第二用户进行区分，第一身份标识可以是第一用户的名称，例如若第一用户是个人，则第一身份标识可以是第一用户的姓名，若第一用户是企业，则第一身份标识可以是第一用户的企业名称；同样的，第二身份标识可以是第二用户的名称，如第一用户相类似，此处不再详述。

因第二用户向第一用户指派工作，第二用户可根据第一用户的绩效计算出对应的特定金额，计算出的特定金额可携带在交易数据中发送给上述第三服务器，其中交易数据中还可以携带第一用户的第一身份标识(如姓名)、身份信息(如身份证号码、护照号和台胞证中的至少一种)、收款账号和特定金额。

在本实施例中，第三服务器可以向第二用户绑定的终端展示一个Web页面，在Web页面中展示交易参数，如上述第一身份标、收款账户和特定金额等参数，由第二用户在Web页面中输入第一用户相关的信息，从而使得第三服务器获取到交易数据；又或者在本实施例中通过HTTP(HyperText Transfer Protocol，超文本传输协议)接口接收交易数据。对于第二用户绑定的终端来说，其发送交易数据的时机本实施例不进行限定，如第二用户绑定的终端发送交易数据的时机可以是周期性的，如每个月发送一次交易数据，又或者是在第一用户所属项目组完成项目之外发送。

202：确定与交易数据对应的交易方式，其中交易方式用于指示向第一用户的个人账户的转账方式，如交易方式可以是银行交易方式、支付宝交易方式和微信交易方式中的至少一种。

为了保证向第一用户的转账是一笔真实有效的交易，本实施例在确定交易方式之前，需要对交易数据进行校验，以验证交易数据是否有效；若验证交易数据有效，说明当前获取到的交易数据是由第二用户发起的一个真实有效的交易，此时可以触发执行确定与交易数据对应的交易方式的步骤；若验证交易数据无效，说明当前获取到的交易数据不是由第二用户发起的或者虽由第二用户发起但确是无效交易，此时禁止向交易数据指示的第一用户转账，可以向第一用户绑定的终端发送提示信息，以提示交易数据有误。

在本实施例中，对交易数据进行校验以验证交易数据是否有效的过程如下：从交易数据中提取第一身份标识和第一用户的个人账户的账户信息；若第一身份标识和账户信息与已有用户信息中的身份标识和账户信息一致，验证交易数据有效。

其中账户信息包括但不限于：收款账号、收款银行和开户行中的至少一种，尤其是收款账号。已有用户信息是上述第三服务器辅助完成转账和开票所签订的合同信息中记录的用户信息，需要在第三服务器辅助完成转账和开票之前记录在第三服务器中，已有用户信息包括但不限于：第一用户至第三用户的身份标识、第一用户和第二用户的账户信息中的至少一种，具体的已有用户信息包括的内容与验证交易数据有效的信息类型一致，例如若通过身份标识验证交易数据有效，则已有用户信息可以是第一用户至第三用户的身份标识，通过这些身份标识来确定交易数据是否由第二用户发起转账给第一用户，且第二用户是否要通过第三用户的对公账户转账。

若交易数据中的第一用户的第一身份标识与已有用户信息中的一个身份标识一致，进一步的交易数据中的第二用户的第二身份标识信息也与已有用户信息中的一个身份标识一致，说明交易数据有效。

203：根据交易方式，向用于处理交易数据的服务器发送交易指令，以由服务器(上述第二服务器)根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，第三用户的对公账户中的金额来源于第二用户的对公账户。

第三用户的对公账户可以是一个虚拟子账户，也可以是一个实体账户。第三用户的对公账户中的金额可以是由第二用户转账给第三用户，在第三用户的对公账户收到第二用户的转账之后从第三用户的对公账户中向第一用户的个人账户转账，或者第三用户的对公账户先垫资向第一用户的个人账户转账，然后第二用户在向第三用户的对公账户转账。第三用户的第三身份标识的说明请参见上述第一身份标识的说明，对此本实施例不再阐述。

在这里需要说明的一点是：第三服务器可以对第二用户向第三用户的对公账户的转账进行核实，若核实后为无效转账，则第三服务器可以指示退回第二用户的转账。对于核实是否为有效转账还是无效转账，可通过转账请求中的用户信息与已有用户信息是否一致来验证，具体请参见上述对交易数据校验的说明，此处不再阐述。

204：接收开票申请请求，开票申请请求由第二用户绑定的终端发送，以通过第三服务器触发开票流程来给第二用户开具发票，完成抵税。

205：向税控盘发送开票申请请求，以使税控盘根据开票申请请求中携带的开票信息进行开票操作。其中开票申请请求中携带的开票信息用于指示纳税方和抵税金额等等，纳税方即为第二用户，在本实施例中开票信息包括但不限于：第一用户的第一身份标识、身份信息、收款账号、金额(即上述特定金额)、第二用户的第二身份标识等等，以指示由哪个第二用户向哪个第一用户转账多少金额，身份信息包括但不限于：身份证号码、护照号和台胞证中的至少一种。

在本实施例中，开票信息可通过HTTP接口接收第二用户绑定的终端输入的开票信息，或者本实施例采用如下方式来获取到开票信息：

响应开票申请请求，向第二用户绑定的终端发送开票界面数据，开票界面数据用于在终端上显示开票界面；获取第二用户在开票界面中输入的开票信息，这样第二用户可通过开票界面来输入开票数据，从而可通过界面方式获取到开票信息。

在获取到开票信息后，可以验证开票信息是否有效，若验证开票信息有效，触发执行向税控盘发送开票申请请求的步骤。其中验证开票信息是否有效的过程包括：验证开票信息中的第二身份标识是否与已有用户信息中的身份标识一致，若一致说明开票信息有效，此时可以触发执行向税控盘发送开票申请请求的步骤。

已有用户信息是上述第三服务器辅助完成转账和开票所签订的合同信息中记录的用户信息，需要在第三服务器辅助完成转账和开票之前记录在第三服务器中，已有用户信息包括但不限于：第一用户至第三用户的身份标识、第一用户和第二用户的账户信息中的至少一种，具体的已有用户信息包括的内容与验证开票信息有效的信息类型一致，例如若通过身份标识验证开票信息有效，则已有用户信息可以是第一用户至第三用户的身份标识，通过这些身份标识来确定开票信息是否由第二用户发起且是否请求向第一用户转账的发票，若确定开票信息是由第二用户发起且请求向第一用户转账的发票，则说明身份标识一致，此时验证开票信息有效。

从上述技术方案可知，获取交易数据，交易数据用于指示向具有第一身份标识的第一用户发送特定金额，特定金额由具有第二身份标识的第二用户汇总出且第二用户和第一用户是合作关系；确定与交易数据对应的交易方式，根据交易方式，向用于处理交易数据的服务器发送交易指令，以由服务器根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，实现由第三用户的对公账户向第一用户的个人账户进行转账操作，这样第二用户的对公账户就不需要开通对私转账功能且第三用户的对公账户可以对接多个第二用户的对公账户，从而借助第三用户的对公账户实现没有开通对私转账功能的对公账户向个人账户的转账。并且还可以接收由第二用户绑定的终端发送的开票申请请求，向税控盘发送开票申请请求，以使税控盘根据开票申请请求中携带的开票信息进行开票操作，这样第二用户绑定的终端就无需与税控盘连接，统一由对接多个第二用户的对公账户的第三用户绑定的服务器连接税控盘进行开票操作，实现由对接多个第二用户的对公账户的第三用户绑定的服务器统一完成多个第二用户的对公账户交易数据处理和多个第二用户的开票申请，这些多个第二用户的对公账户就无需开通对私转账功能且多个第二用户绑定的终端也无需连接税控盘，简化并统一交易数据处理和开票申请流程。

与上述方法实施例相对应，本发明实施例还提供一种数据处理装置，其结构如图3所示，可以包括：获取单元301、确定单元302、发送单元303和接收单元304。

获取单元301，用于获取交易数据，交易数据用于指示向具有第一身份标识的第一用户发放特定金额，特定金额由具有第二身份标识的第二用户汇总出，且第二用户和第一用户是合作关系，第一用户完成第二用户指派的工作。例如第一用户是一个企业，第二用户是一个个体经营者。对于第一身份标识、第二身份标识以及特定金额的说明请参见上述方法实施例，对此本实施例不再阐述。

确定单元302，用于确定与交易数据对应的交易方式，其中交易方式用于指示向第一用户的个人账户的转账方式，如交易方式可以是银行交易方式、支付宝交易方式和微信交易方式中的至少一种。

为了保证向第一用户的转账是一笔真实有效的交易，本实施例提供的数据处理装置中的校验单元在确定交易方式之前，需要对交易数据进行校验，以验证交易数据是否有效；若验证交易数据有效，说明当前获取到的交易数据是由第二用户发起的一个真实有效的交易，此时可以触发确定单元302确定与交易数据对应的交易方式；若验证交易数据无效，说明当前获取到的交易数据不是由第二用户发起的或者虽由第二用户发起但确是无效交易，此时禁止向交易数据指示的第一用户转账，可以向第一用户绑定的终端发送提示信息，以提示交易数据有误。在本实施例中，对交易数据进行校验以验证交易数据是否有效的过程请参见上述方法实施例，对此本实施例不再阐述。

发送单元303，用于根据交易方式，向用于处理交易数据的服务器发送交易指令，以由服务器根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，第三用户的对公账户中的金额来源于第二用户的对公账户。

第三用户的对公账户可以是一个虚拟子账户，也可以是一个实体账户。第三用户的对公账户中的金额可以是由第二用户转账给第三用户，在第三用户的对公账户收到第二用户的转账之后从第三用户的对公账户中向第一用户的个人账户转账，或者第三用户的对公账户先垫资向第一用户的个人账户转账，然后第二用户在向第三用户的对公账户转账。第三用户的第三身份标识的说明请参见上述第一身份标识的说明，对此本实施例不再阐述。

接收单元304，用于接收开票申请请求，开票申请请求由第二用户绑定的终端发送，从而触发开票流程来给第二用户开具发票，完成抵税。

发送单元303，还用于向税控盘发送开票申请请求，以使税控盘根据开票申请请求中携带的开票信息进行开票操作。

其中开票申请请求中携带的开票信息用于指示纳税方和抵税金额等等，纳税方即为第二用户，在本实施例中开票信息包括但不限于：第一用户的第一身份标识、身份信息、收款账号、金额(即上述特定金额)、第二用户的第二身份标识等等，以指示由哪个第二用户向哪个第一用户转账多少金额，身份信息包括但不限于：身份证号码、护照号和台胞证中的至少一种。

在本实施例中，开票信息可通过HTTP接口接收第二用户绑定的终端输入的开票信息，或者本实施例采用如下方式来获取到开票信息：

通过发送单元响应开票申请请求，向第二用户绑定的终端发送开票界面数据，开票界面数据用于在终端上显示开票界面；通过获取单元获取第二用户在开票界面中输入的开票信息，这样第二用户可通过开票界面来输入开票数据，从而可通过界面方式获取到开票信息。

在获取到开票信息后，可以验证开票信息是否有效，若验证开票信息有效，可以由获取单元触发发送单元向税控盘发送开票申请请求的步骤。其中验证开票信息是否有效的过程请参见上述方法实施例，此处不再阐述。

从上述技术方案可知，获取交易数据，交易数据用于指示向具有第一身份标识的第一用户发送特定金额，特定金额由具有第二身份标识的第二用户汇总出且第二用户和第一用户是合作关系；确定与交易数据对应的交易方式，根据交易方式，向用于处理交易数据的服务器发送交易指令，以由服务器根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，实现由第三用户的对公账户向第一用户的个人账户进行转账操作，这样第二用户的对公账户就不需要开通对私转账功能且第三用户的对公账户可以对接多个第二用户的对公账户，从而借助第三用户的对公账户实现没有开通对私转账功能的对公账户向个人账户的转账。并且还可以接收由第二用户绑定的终端发送的开票申请请求，向税控盘发送开票申请请求，以使税控盘根据开票申请请求中携带的开票信息进行开票操作，这样第二用户绑定的终端就无需与税控盘连接，统一由对接多个第二用户的对公账户的第三用户绑定的服务器连接税控盘进行开票操作，实现由对接多个第二用户的对公账户的第三用户绑定的服务器统一完成多个第二用户的对公账户交易数据处理和多个第二用户的开票申请，这些多个第二用户的对公账户就无需开通对私转账功能且多个第二用户绑定的终端也无需连接税控盘，简化并统一交易数据处理和开票申请流程。

此外，本发明实施例还提供一种服务器，服务器包括：处理器和通信装置。其中处理器，用于获取交易数据，确定与交易数据对应的交易方式，交易数据用于指示向具有第一身份标识的第一用户发放特定金额，特定金额由具有第二身份标识的第二用户汇总出，且第二用户和第一用户是合作关系。

处理器，还用于根据交易方式，通过通信装置向用于处理交易数据的服务器发送交易指令，以由用于处理交易数据的服务器根据交易指令，从具有第三身份标识的第三用户的对公账户中转移特定金额至第一用户的个人账户中，第三用户的对公账户中的金额来源于第二用户的对公账户。

处理器，还用于在通过通信装置接收到开票申请请求后，通过通信装置向税控盘发送开票申请请求，开票申请请求由第二用户绑定的终端发送，以使税控盘根据开票申请请求中携带的开票信息进行开票操作。

本发明实施例还提供一种存储介质，存储介质中存储有计算机程序代码，计算机程序代码被运行时实现上述数据处理方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

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

获取交易数据，所述交易数据用于指示向具有第一身份标识的第一用户发放特定金额，所述特定金额由具有第二身份标识的第二用户汇总出，且所述第二用户和所述第一用户是合作关系；

确定与所述交易数据对应的交易方式；

根据所述交易方式，向用于处理所述交易数据的服务器发送交易指令，以由所述服务器根据所述交易指令，从具有第三身份标识的第三用户的对公账户中转移所述特定金额至所述第一用户的个人账户中，所述第三用户的对公账户中的金额来源于所述第二用户的对公账户；

接收开票申请请求，所述开票申请请求由所述第二用户绑定的终端发送；

向税控盘发送开票申请请求，以使所述税控盘根据所述开票申请请求中携带的开票信息进行开票操作。

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

对所述交易数据进行校验，以验证所述交易数据是否有效；

若验证所述交易数据有效，触发执行所述确定与所述交易数据对应的交易方式的步骤。

3.根据权利要求2所述的方法，其特征在于，所述对所述交易数据进行校验，以验证所述交易数据是否有效包括：

从所述交易数据中提取所述第一身份标识和所述第一用户的个人账户的账户信息；

若所述第一身份标识和所述账户信息与已有用户信息中的身份标识和账户信息一致，验证所述交易数据有效。

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

响应开票申请请求，向所述第二用户绑定的终端发送开票界面数据，所述开票界面数据用于在所述终端上显示开票界面；

获取所述第二用户在所述开票界面中输入的开票信息；

若验证所述开票信息有效，触发执行所述向税控盘发送开票申请请求的步骤。

5.根据权利要求4所述的方法，其特征在于，所述若验证所述开票信息有效，触发执行所述向税控盘发送开票申请请求的步骤包括：

若验证所述开票信息中的第二身份标识与已有用户信息中的身份标识一致，触发执行所述向税控盘发送开票申请请求的步骤。

6.根据权利要求1所述的方法，其特征在于，所述交易方式包括：银行交易方式、支付宝交易方式和微信交易方式中的至少一种。

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

获取单元，用于获取交易数据，所述交易数据用于指示向具有第一身份标识的第一用户发放特定金额，所述特定金额由具有第二身份标识的第二用户汇总出，且所述第二用户和所述第一用户是合作关系；

确定单元，用于确定与所述交易数据对应的交易方式；

发送单元，用于根据所述交易方式，向用于处理所述交易数据的服务器发送交易指令，以由所述服务器根据所述交易指令，从具有第三身份标识的第三用户的对公账户中转移所述特定金额至所述第一用户的个人账户中，所述第三用户的对公账户中的金额来源于所述第二用户的对公账户；

接收单元，用于接收开票申请请求，所述开票申请请求由所述第二用户绑定的终端发送；

所述发送单元，还用于向税控盘发送开票申请请求，以使所述税控盘根据所述开票申请请求中携带的开票信息进行开票操作。

8.根据权利要求7所述的装置，其特征在于，所述发送单元，还用于响应开票申请请求，向所述第二用户绑定的终端发送开票界面数据，所述开票界面数据用于在所述终端上显示开票界面；

所述获取单元，还用于获取所述第二用户在所述开票界面中输入的开票信息，并且若所述开票信息有效，触发所述发送单元向税控盘发送开票申请请求。

9.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：校验单元，用于对所述交易数据进行校验，以验证所述交易数据是否有效，并且若验证所述交易数据有效，触发所述确定单元。

10.一种服务器，其特征在于，所述服务器包括：处理器和通信装置；

所述处理器，用于获取交易数据，确定与所述交易数据对应的交易方式，所述交易数据用于指示向具有第一身份标识的第一用户发放特定金额，所述特定金额由具有第二身份标识的第二用户汇总出，且所述第二用户和所述第一用户是合作关系；

所述处理器，还用于根据所述交易方式，通过所述通信装置向用于处理所述交易数据的服务器发送交易指令，以由用于处理所述交易数据的服务器根据所述交易指令，从具有第三身份标识的第三用户的对公账户中转移所述特定金额至所述第一用户的个人账户中，所述第三用户的对公账户中的金额来源于所述第二用户的对公账户；

所述处理器，还用于在通过所述通信装置接收到开票申请请求后，通过所述通信装置向税控盘发送开票申请请求，所述开票申请请求由所述第二用户绑定的终端发送，以使所述税控盘根据所述开票申请请求中携带的开票信息进行开票操作。

Images