CN111402026B - 业务处理方法及因公报销处理方法 - Google Patents

Abstract

本说明书提供业务处理方法及因公报销处理方法，其中所述业务处理方法包括：接收用户在因公业务模式下提交的业务事件的处理请求；按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入。

Description

业务处理方法及因公报销处理方法

技术领域

本说明书涉及业务处理技术领域，特别涉及一种业务处理方法及因公报销处理方法。

背景技术

随着互联网技术的发展，在针对某些事件涉及的资源进行处理的过程中，为了能够提高对业务的处理效率，以及避免资源不足的情况发生，往往需要参与事件的用户主动从账户空间中提取自身持有的资源分担部分资源的消耗，从而促进事件的完成；而由于账户空间中的资源属于用户持有，当针对事件流出部分资源的情况下，需要在事件完成之后，用户提供相应的资源流出凭证才能够收回流出的资源，而在此过程中，不仅消耗的时间周期比较长，并且很容易造成资源流出凭证丢失的问题，以及还需要对资源流出凭证的真实性进行核验，无论是对用户还是对事件的参与方都存在着痛点，故亟需一种有效的方案以解决上述问题。

发明内容

有鉴于此，本说明书实施例提供了一种业务处理方法。本说明书同时涉及一种因公报销处理方法，一种业务处理装置，一种因公报销处理装置，两种计算设备，以及两种计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种业务处理方法，包括：

接收用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额；

按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；

在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

可选的，还包括：

接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

在审核通过的情况下，根据所述申请资源额度对所述账户空间中的资源额度进行更新。

可选的，所述按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出，包括：

在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间更新后的资源额度；

按照所述处理资源数额对更新后的所述资源额度进行资源转出。

可选的，所述按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入步骤执行之后，还包括：

在资源转入完成的情况下，按照所述申请资源额度对所述账户空间中更新后的所述资源额度进行降低处理。

可选的，还包括：

接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

在审核通过的情况下，根据所述申请资源额度在所述账户空间中开通因公业务额度；所述因公业务额度用于在所述因公业务模式下的业务事件。

可选的，所述按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出，包括：

在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间中的所述因公业务额度；

按照所述处理资源数额对所述因公业务额度进行资源转出。

可选的，所述按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入步骤执行之后，还包括：

在资源转入完成的情况下，关闭所述账户空间中的所述因公业务额度。

可选的，所述按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入，包括：

根据与所述用户参与的业务项目签订的资源流动协议，确定所述业务项目的资源流动规则；

基于所述资源流动规则对所述资源转入清单进行审核；

在所述资源转入清单通过审核的情况下，确定所述资源转入清单对应的目标资源数额并发送至所述业务项目；

接收所述业务项目针对所述目标资源数额提交的确认请求；

根据所述确认请求从所述业务项目账户空间向所述账户空间转入与所述目标资源数额对应的转入资源数额。

根据本说明书实施例的第二方面，提供了一种因公报销处理方法，包括：

接收企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额；

按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证；

在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

可选的，还包括：

接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

在审核通过的情况下，根据所述申请额度对所述交易账户中的所述账户额度进行更新。

可选的，所述按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减，包括：

在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户更新后的账户额度；

按照所述交易数额对更新后的所述账户额度进行扣减。

可选的，所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤执行之后，还包括：

在报销处理完成的情况下，按照所述申请额度对所述交易账户中更新后的所述账户额度进行降低处理。

可选的，还包括：

接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

在审核通过的情况下，根据所述申请额度在所述交易账户中开通因公交易额度；所述因公交易额度用于在所述因公交易模式下的交易事件。

可选的，所述按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减，包括：

在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户的所述因公交易额度；

按照所述交易数额对所述因公交易额度进行扣减。

可选的，所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤执行之后，还包括：

在报销处理完成的情况下，关闭所述交易账户中的所述因公交易额度。

可选的，所述获取所述交易事件的交易凭证，包括：

根据对所述账户额度进行扣减的扣减结果，向所述企业员工展示针对所述交易事件的交易页面；

在接收到所述企业员工通过所述交易页面提交的凭证获取指令的情况下，向所述交易事件的被交易方发送凭证获取请求；

接收所述被交易方针对所述凭证获取请求上传的所述交易凭证。

可选的，所述根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单步骤执行之后，且所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤执行之前，还包括：

将所述报销账单发送至所述企业员工所属的企业进行审核处理；

在接收到所述企业针对所述报销账单的审核处理结果为审核通过的情况下，执行所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤。

可选的，所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理，包括：

根据与所述企业员工所属的企业签订的报销协议，确定所述企业的报销条件；

基于所述报销条件对所述报销账单进行审核；

在所述报销账单通过审核的情况下，确定所述报销账单对应的报销金额信息并发送至企业；

接收所述企业针对所述报销金额信息提交的确认请求；

根据所述确认请求将所述报销金额信息对应的报销金额从所述企业账户转至所述交易账户。

根据本说明书实施例的第三方面，提供了一种业务处理装置，包括：

接收处理请求模块，被配置为接收用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额；

资源转出模块，被配置为按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

获取处理凭证模块，被配置为根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；

创建清单模块，被配置为在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

资源转入模块，被配置为按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

根据本说明书实施例的第四方面，提供了一种因公报销处理装置，包括：

接收处理请求模块，被配置为接收企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额；

扣减模块，被配置为按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

获取交易凭证模块，被配置为基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证；

创建账单模块，被配置为在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

报销处理模块，被配置为按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

根据本说明书实施例的第五方面，提供了一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：

接收用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额；

按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；

在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

根据本说明书实施例的第六方面，提供了另一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：

接收企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额；

按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证；

在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

根据本说明书实施例的第七方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现所述业务处理方法的步骤。

根据本说明书实施例的第八方面，提供了另一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现所述因公报销处理方法的步骤。

本说明书一实施例提供的业务处理方法，在接收到用户在因公业务模式下针对业务事件提交的处理请求的情况下，将按照处理请求中携带的处理资源数额，对用户的账户空间中更新后的资源额度进行资源转出处理，并根据资源转出处理结果更新业务清单，同时获取所述业务事件的处理凭证，实现了在处理业务事件的过程中，可以直接获取处理凭证，无需用户主动申请处理凭证，避免用户遗忘处理凭证，同时还可以避免出现用户垫资的情况发生；并且在用户提交转入请求的情况下，将根据转入请求涉及的至少一个业务事件以及其对应的处理凭证创建资源准入清单，最后按照所述资源转入清单进行资源转入处理，实现了在资源转入处理的过程中，减少资源转入处理的周期，有效的提高了资源转入处理的效率。

本说明书一实施例提供的因公报销处理方法，在接收到企业员工在因公交易模式下针对交易事件提交的处理请求的情况下，可以按照处理请求中携带的交易数额，在企业员工的交易账户中扣减与所述交易数额对应的账户额度，并且根据交易事件对企业员工的交易账单进行更新，同时获取交易事件的交易凭证，实现了在进行交易事件的处理过程中，无需企业员工申请交易凭证，即可对交易凭证进行自动获取，同时避免在因公交易模式下企业员工垫付交易数额的情况发生；并在在后续进行报销处理的过程中，可以根据企业员工针对至少一个因公交易模式下的交易事件的报销请求，创建所述企业员工的报销账单，最后按照所述报销账单即可完成报销处理，有效的减少了报销处理周期，并且提高了报销效率，使得整个因公交易模式更加透明化。

附图说明

图1是本说明书一实施例提供的一种业务处理方法的流程图；

图2是本说明书一实施例提供的一种应用于场景一的业务处理方法的处理流程图；

图3是本说明书一实施例提供的一种因公报销处理方法的流程图；

图4是本说明书一实施例提供的一种应用于场景二的因公报销处理方法的处理流程图；

图5是本说明书一实施例提供的一种业务处理装置的结构示意图；

图6是本说明书一实施例提供的一种因公报销处理装置的结构示意图；

图7是本说明书一实施例提供的一种计算设备的结构框图；

图8是本说明书一实施例提供的另一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本说明书中，提供了一种业务处理方法，本说明书同时涉及一种因公报销处理方法，一种业务处理装置，一种因公报销处理装置，两种计算设备，以及两种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本说明书一实施例提供的一种业务处理方法的流程图，具体包括以下步骤：

步骤102：接收用户在因公业务模式下提交的业务事件的处理请求。

实际应用中，在业务项目针对资源进行流动处理的过程中，对于参与业务项目的用户来讲存在着垫资、资源转入困难的情况，对于业务项目的参与方存在着审核困难、凭证归档码放的情况，而对于业务项目的管理方存在着资源管控困难和效率低的情况，严重影响着资源流动处理的高效性。

本实施例提供的业务处理方法，为了能够提高资源流动处理的高效性以及透明化，在接收到用户在因公业务模式下针对业务事件提交的处理请求的情况下，将按照处理请求中携带的处理资源数额，对用户的账户空间中更新后的资源额度进行资源转出处理，并根据资源转出处理结果更新业务清单，同时获取所述业务事件的处理凭证，实现了在处理业务事件的过程中，可以直接获取处理凭证，无需用户主动申请处理凭证，避免用户遗忘处理凭证，同时还可以避免出现用户垫资的情况发生；并且在用户提交转入请求的情况下，将根据转入请求涉及的至少一个业务事件以及其对应的处理凭证创建资源准入清单，最后按照所述资源转入清单进行资源转入处理，实现了在资源转入处理的过程中，减少资源转入处理的周期，有效的提高了资源转入处理的效率。

具体实施时，所述因公业务模式具体是指用户在因公出差或者因公采购的情况下，针对因公发生的事件进行处理时所处的模式，相应的，所述业务事件即为因公出差或者因公采购的情况下，所需要进行处理的事件，比如，用户为某企业员工，企业安排用户出差，出差期间的开销由企业承担，此时该员工在出差期间针对一日三餐的花销进行付款的事件均可以理解为业务事件，而员工在通过支付软件进行支付的过程中，为了方便出差结束进行费用报销，在此期间的花销均会处于因公业务模式下进行，即所述处理请求即为员工针对出差期间发生的事件进行支付或者交易过程中提交的针对该事件的处理请求；

或者，用户为某企业员工，企业安排用户针对部分设备进行采购，采购期间的开销由企业承担，此时该员工在采购期间针对采购设备的付款行为均可以理解为业务事件，而员工通过支付软件进行付款的过程中，为了方便采购结束后的费用报销，在此期间的花销均会处于因公业务模式下进行，即所述处理请求即为员工针对采购期间发生的采购事件进行支付过程中提交的支付请求。

其中，所述处理请求中携带有用户标识和处理资源数额，所述用户标识具体是指能够确定所述用户的账户空间的标识，比如，用户出差或者采购期间使用支付软件进行付款的过程中，将根据用户标识确定用户的支付账户，从而方便后续的扣款行为，所述处理资源数额具体是指针对所述业务事件进行处理的过程中所需要花费的资源数额，相应的，资源可以是资金或者积分等。

本实施例提供的业务处理方法，是对在用户已经进入因公业务模式下，针对因公业务模式下的业务事件进行处理的过程，并且当业务事件处理完成之后，用户需要结束因公业务模式，将根据用户的指令进行资源转入处理的过程的描述。

本实施例将以用户为某企业的员工在出差期间，以及出差后进行费用报销的过程进行描述，即用户在出差期间为了能够方便后续的报销过程，将通过支付软件进行出差期间费用的支付，出差期间即为所述因公业务模式，相应的，所述业务事件即为用户在出差期间针对出差期间的花销事件进行付款的事件，处理请求即为付款请求，用户标识即为支付软件中对应该用户的支付账号，处理资源数额即为针对花销事件的支付金额。

基于此，为了能够保证用户在所述因公业务模式下针对所述业务事件无需垫资即可完成资源的转出处理，可以在用户进入所述因公业务模式之前，用户主动申请针对业务事件的申请资源额度，本实施例的一个或多个实施方式中，申请资源额度的具体过程如下所述：

接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

在审核通过的情况下，根据所述申请资源额度对所述账户空间中的资源额度进行更新；

在审核未通过的情况下，将向用户发送更换账户空间的提醒信息。

具体的，在接收到所述用户针对所述因公业务模式提交的资源申请请求的情况下，此时说明用户需要进入因公业务模式进行因公业务事件的处理，根据所述资源申请请求中携带的申请资源额度和所述用户标识确定所述用户的账户空间，并对所述账户空间的属性信息进行审核，在审核通过的情况下，即可根据所述申请资源额度对所述账户空间中的资源额度进行更新。

实际应用中，所述申请资源额度即为用户针对因公业务模式申请的资源额度，用于针对业务事件进行处理的过程中进行资源转出处理，所述账户空间即为用户存储资源的空间，所述属性信息即为所述账户空间对应的信息，比如账户空间安全等级，账户空间实名认证信息等，对所述属性信息的审核即为对所述账户空间的安全情况的审核，相应的，根据所述申请资源额度对所述资源额度进行更新，即为在账户空间的原有额度上增加与所述申请资源额度相同的资源数额。

例如，某企业委派企业员工甲去城市B做市场调查，而在此期间发生的因公事件均由公司报销，此时，为了避免员工甲出现垫资的情况，员工甲可以通过在支付平台申请因公出差的临时额度，附加在员工甲支付账户原有的额度上，支付平台为用户提供额度是指用户可以通过额度进行支付使用，在每个结算周期按照额度与资金的比例进行还款即可；

基于此，此时经过企业估算本次出差将会花费5000元，则员工甲在支付平台申请5000元的出差临时额度，支付平台将根据员工甲的申请请求对员工甲的支付账户进行安全审核，在确定员工甲的支付账户通过审核的情况下，则在员工甲的支付账户中原有额度上增加5000元额度进行出差期间使用。

通过在用户需要进入因公业务模式的情况下，根据用户的资源申请请求为对用户的账户空间进行审核，有效的提高了资源更新的安全性，并且在审核通过的情况下，根据申请资源额度对账户空间进行更新，方便用户在后续针对业务事件进行处理的过程中，无需资源垫付即可实现资源的转出处理。

步骤104：按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出。

具体的，在上述接收到携带有用户标识和处理资源数额的处理请求的基础上，进一步的，将根据所述处理请求对所述业务事件进行处理，具体是指按照所述处理资源数额，对根据所述用户标识确定的账户空间，在进入所述因公业务模式后更新的资源额度进行资源转出处理。

实际应用中，所述资源转出处理具体是指在所述账户空间的资源额度中转出与所述处理资源数额相等的资源，使得对所述业务事件的处理完成；其中，所述账户空间用于存储所述用户持有的资源和用户针对因公业务模式申请的资源。

进一步的，在用户申请到所述申请资源额度的情况下，此时再对所述业务事件进行处理，即可使用所述账户空间中的原资源额度加上所述申请资源额度对所述业务事件进行处理，本实施例的一个或多个实施方式中，具体实现方式如下所述：

在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间更新后的资源额度；

按照所述处理资源数额对更新后的所述资源额度进行资源转出。

具体的，在用户进入所述因公业务模式的情况下，此时所述账户空间也将进入所述因公业务模式，在针对所述业务事件进行处理，将根据所述用户标识确定所述用户的账户空间，同时确定所述账户空间更新后的资源额度，最后按照所述处理资源数额对更新后的所述资源额度进行资源转出处理。

沿用上例，员工甲在出差期间针对早餐进行付款的过程中，将通过支付平台的支付程序进行扫码付款，此时支付平台将根据用户的扫码请求确定用户的支付账户，以及支付账户申请5000元额度后的可用额度；根据扫码请求中携带的此次早餐的价格在支付账户的可用额度上进行扣减，完成早餐费用的支付。

综上，在对所述业务事件进行处理的过程中，将按照更新后的资源额度对所述处理资源数额进行资源转出处理，实现了在因公业务模式下，用户的账户空间中可以有足够的资源对所述业务事件进行处理，避免消耗用户持有的资源情况的发生，有效的提高了用户的体验效果。

步骤106：根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证。

具体的，在上述进行资源转出处理的基础上，进一步的，将根据资源转出处理结果对所述用户的业务清单进行更新，同时获取所述业务事件的处理凭证，其中，所述业务清单具体是指记录所述用户在所述因公业务模式下针对业务事件进行资源转出处理的清单，相应的，所述处理凭证具体是指针对所述业务事件处理完成之后，开具的凭证；所述处理凭证用于证明业务事件处理完成的凭证。

沿用上例，当员工甲针对早餐的费用支付完成之后，此时支付平台将会对本次的支付事件进行记录，记录在员工甲的支付账户对应的账单中，并且由于是在因公业务模式下进行的，故在支付完成之后，支付平台将通过支付完成提醒向早点店发送开具发票提醒，发票的形式可以是纸质发票或者电子发票，支付平台将会对发票进行存根，方便后续报销过程所使用。

此外，在获取所述处理凭证的过程中，可以通过业务处理完成页面配置凭证获取控件，当用户通过点击该控件的情况下，即可向业务事件的参与方请求开具处理凭证；或者在用户进行资源转出之前，选择资源转出方式的过程中选择因公业务模式进行资源转出，可以直接向业务事件的参与方请求开具所述处理凭证。

步骤108：在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单。

具体的，在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，说明此时用户需要针对至少一个业务事件进行资源转入处理，即请求用户所属的业务项目进行账户空间中的资源恢复，而为了能够方便进行资源转入处理，此时将根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单，其中，所述资源转入清单即为针对所述至少一个业务事件进行资源转入处理的清单，使得后续根据该清单即可完成资源转入处理。

沿用上例，当员工甲此次出差结束的情况下，将会进行费用报销，在接收到员工甲针对出差期间的10个报销事件提交的报销请求的情况下，将根据这10个报销事件的发票和订单自动创建员工甲的报销清单，进行后续的报销处理即可。

此外，在创建所述用户的资源转入清单的过程中，可以根据用户通过在因公业务模式下的账单中勾选的方式确定转入请求，确定用户勾选的业务事件，此时根据勾选的业务事件及其对应的处理凭证创建所述资源转入请求；还可以在用户针对因公业务模式提交的转入请求的情况下，将自动识别出在因公业务模式下的具有处理凭证的业务事件，再创建所述资源转入清单，更加方便用户进行后续的资源转入处理，有效的节省了资源转入所花费的时间。

步骤110：按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入。

具体的，在上述针对所述至少一个业务事件创建所述用户的资源转入清单的基础上，进一步的，将按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入处理，即将根据所述资源转入清单，通过所述业务项目账户空间向用户的账户空间中进行资源的转入处理，其中，所述资源转入是对所述资源转出的资源额度的恢复。

沿用上例，员工甲在出差期间总花费费用是4800元，并且这4800元均是通过支付账户中的可用额度进行支付的，此时需要员工甲所属的企业向员工甲进行4800元的费用报销，之后员工甲根据获得的报销费用4800元将支付账户中的可用额度4800进行偿还。

进一步的，在进行资源转入的过程中，为了能够保证资源转入清单的准确性，可以对资源准入清单进行审核，本实施例的一个或多个实施方式中，进行资源转入的具体实现方式如下所述：

根据与所述用户参与的业务项目签订的资源流动协议，确定所述业务项目的资源流动规则；

基于所述资源流动规则对所述资源转入清单进行审核；

在所述资源转入清单通过审核的情况下，确定所述资源转入清单对应的目标资源数额并发送至所述业务项目；

接收所述业务项目针对所述目标资源数额提交的确认请求；

根据所述确认请求从所述业务项目账户空间向所述账户空间转入与所述目标资源数额对应的转入资源数额。

实际应用中，为了方便在进行资源转入处理的高效性，可以与用户参与的业务项目签订资源流动协议，根据所述资源流动协议，确定所述业务项目的资源流动规则，此时根据所述资源流动规则对所述资源转入清单进行审核，在所述资源转入清单通过审核的情况下，说明此时资源转入清单是准确的，可以继续进行后续的资源转入处理，则确定所述资源转入清单对应的目标资源数额并发送至所述业务项目，在接收到所述业务项目针对所述目标资源数额提交的确认请求后，根据所述确认请求从所述业务项目账户空间向所述账户空间转入与所述目标资源数额对应的转入资源数额即可完成资源转入的处理；在所述资源转入清单未通过审核的情况下，说明此时资源转入清单是不准确的，可以引入业务项目的审核员进行资源转入清单的再次审核，直至确定准确的资源转入清单后，在进行资源的转入处理。

通过在进行资源转入处理的过程中，根据所述资源流动协议对所述资源转入清单进行审核，实现了避免出现资源转入清单不准确，导致资源转入后资源损失的情况发生，并且通过资源流动协议，可以加快资源转入处理的效率，有效额缩短了资源转入过程中所耗费的时间，进一步提高用户的体验效果。

更进一步的，在资源转入处理完成之后，此时用户的账户空间将需要退出因公业务模式，则需要进行资源额度降低处理，本实施例的一个或多个实施方式中，具体实现方式如下所述：

在资源转入完成的情况下，按照所述申请资源额度对所述账户空间中更新后的所述资源额度进行降低处理。

沿用上例，在员工甲所属的企业对其4800元的费用进行报销完成的情况下，此时员工甲已经对支付账户中的可用额度4800进行偿还，而员工甲的支付账户中还存在临时额度5000，为了方便额度管理，此时则可以根据申请时的5000额度对临时额度5000进行降低处理，使得员工甲的支付账户中的额度恢复为出差前的额度。

综上，通过对所述账户空间中的资源额度进行降低处理，更加方便业务项目对资源的管理。

本实施例提供的业务处理方法，在接收到用户在因公业务模式下针对业务事件提交的处理请求的情况下，将按照处理请求中携带的处理资源数额，对用户的账户空间中更新后的资源额度进行资源转出处理，并根据资源转出处理结果更新业务清单，同时获取所述业务事件的处理凭证，实现了在处理业务事件的过程中，可以直接获取处理凭证，无需用户主动申请处理凭证，避免用户遗忘处理凭证，同时还可以避免出现用户垫资的情况发生；并且在用户提交转入请求的情况下，将根据转入请求涉及的至少一个业务事件以及其对应的处理凭证创建资源准入清单，最后按照所述资源转入清单进行资源转入处理，实现了在资源转入处理的过程中，减少资源转入处理的周期，有效的提高了资源转入处理的效率。

下述结合附图2，以本说明书提供的业务处理方法在场景一中的应用为例，对所述业务处理方法进行进一步说明。其中，图2示出了本说明书一实施例提供的一种应用于场景一的业务处理方法的处理流程图，具体包括以下步骤：

步骤202：接收用户针对因公业务模式提交的资源申请请求。

本实施例将以用户为某企业的员工在出差期间，以及出差后进行费用报销的过程进行描述，即用户在出差期间为了能够方便后续的报销过程，将通过支付软件进行出差期间费用的支付，出差期间即为所述因公业务模式，相应的，所述业务事件即为用户在出差期间针对出差期间的花销事件进行付款的事件，处理请求即为付款请求，用户标识即为支付软件中对应该用户的支付账号，处理资源数额即为针对花销事件的支付金额。

具体的，所述资源申请请求中携带有申请资源额度和用户标识；在接收到所述用户针对所述因公业务模式提交的资源申请请求的情况下，此时说明用户需要进入因公业务模式进行因公业务事件的处理，则在后续需要对所述用户的账户空间进行审核。

步骤204：根据所述用户标识确定所述用户的账户空间，并对所述账户空间的属性信息进行审核。

具体的，在上述接收到所述用户针对因公业务模式提交的资源申请请求的基础上，进一步的，将根据所述用户标识确定所述用户的账户空间并对所述账户空间的属性信息进行审核。

实际应用中，所述申请资源额度即为用户针对因公业务模式申请的资源额度，用于针对业务事件进行处理的过程中进行资源转出处理，所述账户空间即为用户存储资源的空间，所述属性信息即为所述账户空间对应的信息，比如账户空间安全等级，账户空间实名认证信息等，对所述属性信息的审核即为对所述账户空间的安全情况的审核。

例如，某企业委派企业员工甲去城市B做市场调查，而在此期间发生的因公事件均由公司报销，此时，为了避免员工甲出现垫资的情况，员工甲可以通过在支付平台申请因公出差的因公业务额度，该因公业务额度将单独在支付账户中存在，员工甲出差期间因公事件的费用都可以通过因公业务额度进行消费，便于报销阶段的报销处理；

基于此，此时经过企业估算本次出差将会花费5000元，则员工甲在支付平台申请5000元的因公业务额度，此时将对员工甲的支付账户进行安全审核，通过对员工甲的支付账户进行安全等级验证，从而实现审核。

步骤206：在审核通过的情况下，根据所述申请资源额度在所述账户空间中开通因公业务额度。

具体的，在上述对所述账户空间的属性信息进行审核的基础上，进一步的，在审核通过的情况下，根据所述申请资源额度在所述账户空间中开通因公业务额度。其中，所述因公业务额度用于在所述因公业务模式下的业务事件。

沿用上例，在员工甲申请5000元的因公业务额度的情况下，通过对员工甲的支付账户进行安全审核，确定员工甲的支付账户安全等级符合申请标准，此时则再员工甲的支付账户中开通5000元的因公业务额度，专用于出差期间因公的支付。

步骤208：接收用户在因公业务模式下提交的业务事件的处理请求。

具体的，接收到所述用户在因公业务模式下提交的业务事件的处理请求，确定用户在因公业务模式下针对业务事件需要进行处理，所述处理请求中携带有用户标识和处理资源数额。

其中，所述用户标识具体是指能够确定所述用户的账户空间的标识，比如，用户出差或者采购期间使用支付软件进行付款的过程中，将根据用户标识确定用户的支付账户，从而方便后续的扣款行为，所述处理资源数额具体是指针对所述业务事件进行处理的过程中所需要花费的资源数额，相应的，资源可以是资金或者积分等。

沿用上例，员工甲在出差期间，需要针对早餐进行付款时，将通过支付平台的支付程序进行扫码付款，支付平台根据员工甲的扫码请求，确定员工甲的支付账户，以及支付金额，则在后续将根据支付金额以及支付账户进行早餐费用的扣款。

步骤210：在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间中的所述因公业务额度。

步骤212：按照所述处理资源数额对所述因公业务额度进行资源转出。

具体的，此时所述账户空间也将进入所述因公业务模式，在针对所述业务事件进行处理，将根据所述用户标识确定所述用户的账户空间，同时确定所述账户空间更新后的因公业务额度，最后按照所述处理资源数额对更新后的所述因公业务额度进行资源转出处理即可。

沿用上例，根据扫码请求中的支付账号确定员工甲的支付账户，并确定支付账户中开通的因公业务额度5000，根据扫码请求携带的此次早餐费用的价格在支付账户中的因公业务额度上进行扣款，完成早餐费用的支付。

在针对业务事件进行处理的过程中，将按照开通的因公业务额度对所述处理资源数额进行资源转出处理，实现了在因公业务模式下，可以将因公资源转出处理和因私资源转出处理进行分离，从而保证后续资源转入处理的精准度以及处理效率。

步骤214：根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证。

具体的，在上述进行资源转出处理的基础上，进一步的，将根据资源转出处理结果对所述用户的业务清单进行更新，同时获取所述业务事件的处理凭证，其中，所述业务清单具体是指记录所述用户在所述因公业务模式下针对业务事件进行资源转出处理的清单，相应的，所述处理凭证具体是指针对所述业务事件处理完成之后，开具的凭证；所述处理凭证用于证明业务事件处理完成的凭证。

沿用上例，当员工甲针对早餐的费用支付完成之后，此时支付平台将会对本次的支付事件进行记录，记录在员工甲的支付账户对应的账单中，并且该笔费用是从因公业务额度中扣减，故该账单也是与因公业务额度所对应，方便出差结束进行报销处理，在支付完成之后，支付平台将通过支付完成提醒向早点店发送开具发票提醒，发票的形式可以是纸质发票或者电子发票，支付平台将会对发票进行存根，方便后续报销过程所使用。

此外，由于所述资源转出处理是从所述因公业务额度中转出的，故在获取所述处理凭证的过程中，无需用户过多操作，业务项目即可根据因公业务额度自动向业务事件的参与方请求开具处理凭证。

步骤216：在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单。

具体的，在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，说明此时用户需要针对至少一个业务事件进行资源转入处理，即请求用户所属的业务项目进行账户空间中的因公业务额度的恢复，而为了能够方便进行资源转入处理，此时将根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单，其中，所述资源转入清单即为针对所述至少一个业务事件进行资源转入处理的清单，使得后续根据该清单即可完成资源转入处理。

沿用上例，当员工甲此次出差结束的情况下，将会进行费用报销，在接收到员工甲针对出差期间的10个报销事件提交的报销请求的情况下，将根据这10个报销事件的发票和订单自动创建员工甲的报销清单，进行后续的报销处理即可。

此外，由于用户在因公业务模式下处理业务事件的过程，都是通过因公业务额度进行的资源转出处理，故在创建所述资源转入清单的过程中，无需用户进行操作，业务项目即可根据用户提交的转入请求，自动对因公业务模式下涉及的业务事件进行汇总，根据具有处理凭证的业务事件，再创建所述资源转入清单，更加方便用户进行后续的资源转入处理，有效的节省了资源转入所花费的时间。

步骤218：按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入。

具体的，在上述针对所述至少一个业务事件创建所述用户的资源转入清单的基础上，进一步的，将按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入处理，即将根据所述资源转入清单，通过所述业务项目账户空间向用户的账户空间中进行资源的转入处理，其中，所述资源转入是对所述资源转出的资源额度的恢复。

沿用上例，员工甲在出差期间总花费费用是4800元，并且这4800元均是通过支付账户中的因公业务额度进行支付的，此时需要员工甲所属的企业向员工甲进行4800元的费用报销，之后员工甲根据获得的报销费用4800元将支付账户中的因公业务额度4800进行偿还。

步骤220：在资源转入完成的情况下，关闭所述账户空间中的所述因公业务额度。

具体的，在员工甲所属的企业对其4800元的费用进行报销完成的情况下，此时员工甲已经对支付账户中的因公业务额度4800进行偿还，而员工甲的支付账户中还开通有因公业务额度，为了方便额度管理，此时则可以关闭因公业务额度。

本实施例提供的业务处理方法，实现了在账户空间中开通因公业务额度，更加方便在资源转入处理时的处理过程的便捷性，并且只要是在因公业务模式下的业务事件使用因公业务额度进行资源转出处理，均可以自动获取处理凭证，减少了用户的操作步骤，有效的提高了用户的体验效果，最后按照业资源转入清单进行资源转入处理，实现了在资源转入处理的过程中，减少资源转入处理的周期，有效的提高了资源转入处理的效率。

图3示出了根据本说明书一实施例提供的一种因公报销处理方法的流程图，具体包括以下步骤：

步骤302：接收企业员工在因公交易模式下提交的交易事件的处理请求。

实际应用中，由于因公交易场景的广泛性，导致在因公交易场景中无论是对员工还是对企业都存在着一定的痛点，对员工来讲存在着垫资(垫资周期长，无法及时报销)、繁琐(发票遗失、漏开整理困难)；对企业财务存在着审核难(发票的真实性)、凭证归档麻烦；对企业存在着费用管控难(费用靠预测)、效率低(报销审核周期长、报销笔数多)等问题，严重影响着因公报销处理的高效性。

本实施例提供的因公报销处理方法，为了能够提高报销处理的效率，以及透明化，在接收到企业员工在因公交易模式下针对交易事件提交的处理请求的情况下，可以按照处理请求中携带的交易数额，在企业员工的交易账户中扣减与所述交易数额对应的账户额度，并且根据交易事件对企业员工的交易账单进行更新，同时获取交易事件的交易凭证，实现了在进行交易事件的处理过程中，无需企业员工申请交易凭证，即可对交易凭证进行自动获取，同时避免在因公交易模式下企业员工垫付交易数额的情况发生；并在在后续进行报销处理的过程中，可以根据企业员工针对至少一个因公交易模式下的交易事件的报销请求，创建所述企业员工的报销账单，最后按照所述报销账单即可完成报销处理，有效的减少了报销处理周期，并且提高了报销效率，使得整个因公交易模式更加透明化。

具体实施时，所述因公交易模式具体是指企业员工在因公出差或因公采购期间，针对因公发生的交易事件进行处理时所处的模式，相应的，所述交易事件即为因公出差或者因公采购的情况下，所需要进行交易的事件，比如，企业员工在出差期间针对一日三餐的花销进行付款的事件可以理解为交易事件，而企业员工在通过支付软件进行支付的过程中，为了方便出差结束进行费用的报销，在此期间的花销均会处于因公交易模式下进行，即所述处理请求即为企业员工针对出差期间发生的交易事件进行交易过程中提交的针对该事件的处理请求；

其中，所述处理请求中携带有员工身份标识和交易数额；所述员工身份标识具体是指确定所述企业员工的交易账户的标识，相应的，所述交易数额具体是指在因公交易模式下针对交易事件进行处理过程中所需要花费的费用数额。

本实施例将以企业员工在出差期间，以及出差后进行费用报销的过程进行描述，即企业员工为了能够加快后续的报销过程，将通过支付软件进行出差期间费用的支付，出差期间即为所述因公交易模式，相应的，交易事件即为企业员工在出差期间针对花销事件进行付款的事件，处理请求即为付款请求，员工身份标识即为支付软件中对应该企业员工的支付账号，交易数额即为针对交易事件的支付费用。

基于此，为了能够保证企业员工在所述因公交易模式下针对所述交易事件无需垫资即为完成费用的支出，可以在企业员工进入所述因公交易模式之前，主动申请针对交易事件的申请额度，本实施例的一个或多个实施方式中，具体实现方式如下所述：

接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

在审核通过的情况下，根据所述申请额度对所述交易账户中的所述账户额度进行更新；

在审核未通过的情况下，将向所述企业员工发送更换交易账户的提醒信息。

具体的，在接收到所述企业员工针对所述因公交易模式提交的额度申请请求的情况下，此时说明企业员工需要进入因公交易模式进行交易事件的处理，则根据所述额度申请请求中携带的申请额度和员工身份标识确定所述企业员工的交易账户，并对所述交易账户的账户信息进行审核，在审核通过的情况下，根据所述申请额度对所述交易账户中的所述账户额度进行更新即可。

实际应用中，所述申请额度即为企业员工针对因公交易模式申请的花销额度，用于针对交易事件进行交易处理过程中的扣减，所述交易账户即为企业员工进行支付所使用的账户，所述账户信息即为所述交易账户对应的信息，比如账户安全等级，账户实名认证信息或者账户资金存储信息等，对所述账户信息进行审核即为对所述交易账户的安全情况进行审核，相应的，根据所述申请额度对所述交易账户中的所述账户额度进行更新，即为在所述交易账户原有的账户额度上增加与所述申请额度相同的可用额度。

例如，企业员工乙接受了企业分配的出差任务，出差期间的因公产生的费用均由企业报销，此时，为了避免企业员工乙出现垫付而影响企业员工乙的正常消费，企业员工乙可以通过支付平台申请因公出差的临时额度，该额度将附加在企业员工乙的交易账户的原有额度上，支付平台为企业员工提供的额度是指企业员工可以通过额度进行支付使用，在每个结算周期按照额度与资金的比例进行还款即可；基于此，经过企业估算本次出差将会花费5000元，则企业员工乙在支付平台申请5000元的出差使用的临时额度，支付平台将根据企业员工乙的申请请求对其对应的支付账户进行安全审核，在确定企业员工乙的支付账户通过审核的情况下，在企业员工乙的支付账户原有的额度上增加5000额度进行出差期间支付使用。

通过在企业员工需要进入因公交易模式的情况下，根据企业员工的额度申请请求为交易账户进行审核，有效的提高了额度申请的安全性，并且在审核通过的情况下，根据申请额度对所述交易账户的账户额度进行更新，方便后续针对交易事件进行交易处理的过程中，无需进行费用的垫付即可完成费用的扣减。

步骤304：按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减。

具体的，在上述接收到携带有员工身份标识和交易数额的处理请求的基础上，进一步的，将根据所述处理请求对所述交易事件进行交易处理，具体是按照所述交易数额，对根据所述员工身份标识确定的交易账户，在进入所述因公交易模式后更新的账户额度进行扣减处理；实际应用中，所述扣减处理具体是指在所述交易账户中转出与所述交易数额对应的额度，使得对所述交易事件处理完成。

进一步的，在企业员工申请到申请额度的情况下，此时再对所述交易事件进行处理，即可使用所述交易账户中原账户额度加上所述申请额度对所述交易事件进行交易处理，本实施例的一个或多个实施方式中，具体实现方式如下所述：

在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户更新后的账户额度；

按照所述交易数额对更新后的所述账户额度进行扣减。

沿用上例，企业员工乙在出差期限对早餐进行付款的过程中，将通过支付平台的支付程序进行扫码付款，此时支付平台将根据企业员工乙的扫码请求确定企业员工的支付账户，以及支付账户申请5000额度后的可用额度，根据扫码请求中携带的此次早餐的价格在支付账户的可用额度上进行扣减，完成早餐费用的支付。

综上，在对所述交易事件进行处理的过程中，将按照更新后的账户额度对所述交易数额进行扣减处理，实现了在因公交易模式下，企业员工的交易账户中可以有足够的额度对所述交易事件进行交易处理，有效的提高了用户的体验效果。

步骤306：基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证。

具体的，在上述进行账户额度扣减处理的基础上，进一步的，将根据所述交易事件更新所述企业员工的交易账单，同时获取所述交易事件的交易凭证，其中，所述交易账单具体是指记录所述企业员工在所述因公交易模式下针对交易事件进行额度扣减处理的账单，相应的，所述交易凭证具体是指针对所述交易事件处理完成之后，开具的凭证，所述交易凭证是用于证明交易事件处理完成的凭证。所述交易凭证可以是针对交易事件处理完成之后开具的发票。

进一步的，在获取所述交易凭证的过程中，需要根据企业员工的获取请求实现，本实施例的一个或多个实施方式中，具体实现方式如下所述：

根据对所述账户额度进行扣减的扣减结果，向所述企业员工展示针对所述交易事件的交易页面；

在接收到所述企业员工通过所述交易页面提交的凭证获取指令的情况下，向所述交易事件的被交易方发送凭证获取请求；

接收所述被交易方针对所述凭证获取请求上传的所述交易凭证。

具体的，首先确定对所述账户额度的扣减结果，再根据所述扣减结果向所述企业员工展示针对所述交易事件的交易页面，所述交易页面具体是指完成交易处理后展示的页面；其次在接收到所述企业员工通过所述交易页面提交的凭证获取指令的情况下，说明此时企业员工需要获取此次交易事件的交易凭证，则根据所述凭证获取指令向交易事件的被交易方发送凭证获取请求，所述被交易方具体是指交易事件中涉及的费用收款方，最后接收所述被交易方针对所述凭证获取请求上传的所述交易凭证即可。

沿用上例，企业员工乙在早餐店完成付款之后，企业员工乙的手机上将展示支付完成的付款页面，在此页面中包含有开具发票控件，当企业员工乙针对此控件进行点击的情况下，表明企业员工乙需要针对此次的交易事件进行开具发票，则支付平台根据企业员工乙的指令向早餐店发送发票开具请求，早餐店可以根据该请求直接对企业员工乙开具电子发票，支付平台将对该电子发票进行存储，以便企业员工乙后续的费用报销。

在获取交易凭证的过程中，根据企业员工通过交易页面提交的凭证获取指令即为完成交易凭证的获取，实现了通过交易页面即可提醒企业员工在因公交易模式下进行凭证的获取，并且无需企业员工进行凭证的存储，也可以在报销处理过程中获取到该交易事件的交易凭证，更进一步的提高了用户的体验效果。

步骤308：在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单。

具体的，在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，说明此时企业员工需要针对至少一个交易事件进行报销处理，为了能够提高报销处理过程的高效性，将根据至少一个交易事件及其对应的交易凭证创建报销账单，使得后续根据该报销账单即可完成报销处理。

此外，在创建完成所述报销账单之后，为了保证报销账单真实性的问题，可以对所述报销账单进行审核，本实施例的一个或多个实施方式中，具体实现方式如下所述：

将所述报销账单发送至所述企业员工所属的企业进行审核处理；

在接收到所述企业针对所述报销账单的审核处理结果为审核通过的情况下，执行下述步骤310；在接收到所述企业针对所述报销账单的审核处理结果为审核未通过的情况下，则重新创建所述报销账单，直至创建出的报销账单符合审核条件，在进行后续的报销处理。

沿用上例，当企业员工乙此次出差结束的情况下，将会进行费用报销，在接收到企业员工乙针对出差期间的10个报销事件提交的报销请求的情况下，将根据这10个报销事件的发票和订单自动创建企业员工乙的报销账单，并将所述报销账单发送至企业员工乙所属的企业进行审核，在接收到企业返回的审核通过的情况下，此时可以对10个报销事件涉及的费用进行后续的报销处理。

通过对所述报销账单进行进一步的审核，可以有效的保证报销账单的真实性，更进一步的提高了后续报销处理过程的高效性。

步骤310：按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

具体的，在上述针对所述至少一个交易事件创建所述企业员工的报销账单的基础上，进一步的，将按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理，即将根据所述报销账单，通过所述企业员工所属企业的企业账户向所述交易账户中进行费用的报销。

进一步的，在进行报销处理的过程中，为了能够保证加快报销处理过程，可以在进行报销处理之前，与企业签订报销协议，在符合协议要求的情况下，直接进行报销处理，从而加快报销处理过程，提高用户的体验效果，本实施例的一个或多个实施方式中，具体实现方式如下所述：

根据与所述企业员工所属的企业签订的报销协议，确定所述企业的报销条件；

基于所述报销条件对所述报销账单进行审核；

在所述报销账单通过审核的情况下，确定所述报销账单对应的报销金额信息并发送至企业；

接收所述企业针对所述报销金额信息提交的确认请求；

根据所述确认请求将所述报销金额信息对应的报销金额从所述企业账户转至所述交易账户。

实际应用中，为了加快报销处理过程，可以根据与所述企业员工所属的企业签订的报销协议，确定所述企业的报销条件；在基于所述报销条件对所述报销账单进行审核，在所述报销账单通过审核的情况下，说明此时报销账单的真实性是可以保障的，则将所述报销账单对应的报销金额信息发送至企业；在接收所述企业针对所述报销金额信息提交的确认请求的情况下，根据所述确认请求将所述报销金额信息对应的报销金额从所述企业账户转至所述交易账户即可。

此外，为了加快报销处理过程，可以与企业员工签订报销协议，根据所述报销协议对所述报销账单审核通过的情况下，即可直接进行报销处理，即从企业账户向企业员工的交易账户直接进行报销费用的转账，无需企业进行再次审核，而在此过程中，一定要保证报销账单的真实性，故需要根据所述报销协议对所述报销账单进行更细致的审核。

通过在进行报销处理的过程中，根据所述报销协议对所述报销账单进行再次审核，实现了避免出现报销费用不准确，而导致企业发生损失的情况发生，并且通过所述报销协议，可以加快报销处理的效率，有效的缩短了报销处理过程中所耗费的时间，进一步提高用户的体验效果。

更进一步的，在报销处理完成之后，此时企业员工的交易账户中将需要降低账户额度，便于企业员工下次在因公交易模式下进行额度的申请，本实施例的一个或多个实施方式中，具体实现方式如下所述：

在报销处理完成的情况下，按照所述申请额度对所述交易账户中更新后的所述账户额度进行降低处理。

沿用上例，在企业员工乙所属的企业对其4800元的费用进行报销完成的情况下，此时企业员工乙已经对支付账户中的可用额度4800进行偿还，而企业员工乙的支付账户中还存在临时额度5000，为了方便额度管理，此时则可以根据申请时的5000额度对临时额度5000进行降低处理，使得企业员工乙的支付账户中的额度恢复为出差前的额度。

本实施例提供的因公报销处理方法，在接收到企业员工在因公交易模式下针对交易事件提交的处理请求的情况下，可以按照处理请求中携带的交易数额，在企业员工的交易账户中扣减与所述交易数额对应的账户额度，并且根据交易事件对企业员工的交易账单进行更新，同时获取交易事件的交易凭证，实现了在进行交易事件的处理过程中，无需企业员工申请交易凭证，即可对交易凭证进行自动获取，同时避免在因公交易模式下企业员工垫付交易数额的情况发生；并在在后续进行报销处理的过程中，可以根据企业员工针对至少一个因公交易模式下的交易事件的报销请求，创建所述企业员工的报销账单，最后按照所述报销账单即可完成报销处理，有效的减少了报销处理周期，并且提高了报销效率，使得整个因公交易模式更加透明化。

下述结合附图4，以本说明书提供的因公报销处理方法在场景二中的应用为例，对所述因公报销处理方法进行进一步说明。其中，图4示出了本说明书一实施例提供的一种应用于场景二的因公报销处理方法的处理流程图，具体包括以下步骤：

步骤402：接收企业员工针对因公交易模式提交的额度申请请求。

本实施例将以企业员工在出差期间，以及出差后进行费用报销的过程进行描述，即企业员工为了能够加快后续的报销过程，将通过支付软件进行出差期间费用的支付，出差期间即为所述因公交易模式，相应的，交易事件即为企业员工在出差期间针对花销事件进行付款的事件，处理请求即为付款请求，员工身份标识即为支付软件中对应该企业员工的支付账号，交易数额即为针对交易事件的支付费用。

具体的，所述额度申请请求中携带有申请额度和所述员工身份标识；在接收到所述企业员工针对因公交易模式提交的额度申请请求的情况下，此时说明企业员工需要进入因公交易模式进行交易事件的处理，则在后续需要对所述企业员工的交易账户进行审核。

步骤404：根据所述员工身份标识确定交易账户，并对所述交易账户的账户信息进行审核。

具体的，在上述接收到所述额度申请请求的基础上，进一步的，根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核。

实际应用中，所述申请额度即为企业员工针对因公交易模式申请的花销额度，用于针对交易事件进行交易处理过程中的扣减，所述交易账户即为企业员工进行支付所使用的账户，所述账户信息即为所述交易账户对应的信息，比如账户安全等级，账户实名认证信息或者账户资金存储信息等，对所述账户信息进行审核即为对所述交易账户的安全情况进行审核。

例如，企业员工乙接受了企业分配的出差任务，出差期间的因公产生的费用均由企业报销，此时，为了避免企业员工乙出现垫付而影响企业员工乙的正常消费，企业员工乙可以通过支付平台申请因公出差的临时额度，该额度将附加在企业员工乙的交易账户的原有额度上，支付平台为企业员工提供的额度是指企业员工可以通过额度进行支付使用，在每个结算周期按照额度与资金的比例进行还款即可；基于此，经过企业估算本次出差将会花费5000元，则企业员工乙在支付平台申请5000元的出差使用的临时额度，支付平台将根据企业员工乙的申请请求对其对应的支付账户进行安全审核。

步骤406：在审核通过的情况下，根据所述申请额度在所述交易账户中开通因公交易额度。

具体的，在上述对所述交易账户的账户信息进行审核的基础上，进一步的，在审核通过的情况下，根据所述申请额度在所述交易账户中开通因公交易额度，其中，所述因公交易额度用于在所述因公交易模式下的交易事件。

沿用上例，在确定企业员工乙的支付账户通过审核的情况下，确定企业员工乙的支付账户安全等级符合申请标准，在企业员工乙的支付账户中开通5000元的因公交易额度，专用于出差期间因公的支付事件。

步骤408：接收企业员工在因公交易模式下提交的交易事件的处理请求。

具体的，接收到企业员工在因公交易模式下提交的交易事件的处理请求，确定企业员工在因公交易模式下针对所述交易事件需要进行交易处理，所述处理请求中携带有员工身份标识和交易数额。

沿用上例，企业员工乙在出差期间，需要针对早餐进行付款时，将通过支付平台的支付程序进行扫码付款，支付平台根据企业员工乙的扫码请求，确定企业员工乙的支付账户，以及支付金额，则在后续将根据支付金额以及支付账户进行早餐费用的扣款。

步骤410：在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户的所述因公交易额度。

步骤412：按照所述交易数额对所述因公交易额度进行扣减。

具体的，此时所述交易账户夜间进入所述因公交易模式，在针对所述交易事件进行处理，将根据所述员工身份标识确定交易账户，同时确定所述交易账户更新后的因公交易额度，最后按照所述交易数额对更新后的所述因公交易额度进行扣减处理即可。

沿用上例，根据扫码请求中的支付账号确定企业员工乙的支付账户，并确定支付账户中开通的因公业务额度5000，根据扫码请求携带的此次早餐费用的价格在支付账户中的因公业务额度上进行扣款，完成早餐费用的支付。

通过按照开通的因公交易额度对所述交易事件进行处理，实现了在因公交易模式下，可以将因公交易额度和账户额度进行分离，从而更加方便后续的报销处理过程。

步骤414：基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证。

具体的，在上述进行额度扣减的基础上，进一步的，将根据所述交易事件更新所述企业员工的交易账单，同时获取所述交易事件的交易凭证，其中，所述交易账单具体是指记录所述企业员工在所述因公交易模式下针对交易事件进行额度扣减处理的账单，相应的，所述交易凭证具体是指针对所述交易事件处理完成之后，开具的凭证，所述交易凭证是用于证明交易事件处理完成的凭证。所述交易凭证可以是针对交易事件处理完成之后开具的发票。

沿用上例，当企业员工乙针对早餐的费用支付完成之后，此时支付平台将会对本次的支付事件进行记录，记录在企业员工乙的支付账户对应的账单中，并且该笔费用是从因公交易额度中扣减，故该账单也是与因公交易额度所对应，方便出差结束进行报销处理，在支付完成之后，支付平台将通过支付完成提醒向早点店发送开具发票提醒，发票的形式可以是纸质发票或者电子发票，支付平台将会对发票进行存根，方便后续报销过程所使用。

此外，由于额度扣减是从所述因公交易额度中完成的，故在获取所述交易凭证的过程中，无需用户过多操作，支付平台即可根据因公交易额度自动向交易事件的参与方请求开具交易凭证。

步骤416：在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单。

具体的，在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，说明此时企业员工需要针对至少一个交易事件进行报销处理，为了能够提高报销处理过程的高效性，将根据至少一个交易事件及其对应的交易凭证创建报销账单，使得后续根据该报销账单即可完成报销处理。

沿用上例，当企业员工乙此次出差结束的情况下，将会进行费用报销，在接收到企业员工乙针对出差期间的10个报销事件提交的报销请求的情况下，将根据这10个报销事件的发票和订单自动创建企业员工乙的报销账单，进行后续的报销处理即可。

此外，由于企业员工在因公交易模式下处理交易事件的过程，都是通过因公交易额度完成的，故在创建所述报销账单的过程中，无需用户进行操作，支付平台即可根据企业员工提交的报销请求，自动对因公交易模式下设计的交易事件进行汇总，创建报销清单进行报销处理，有效的节省了报销处理的消耗时间。

步骤418：按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

具体的，在上述针对所述至少一个交易事件创建所述企业员工的报销账单的基础上，进一步的，将按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理，即将根据所述报销账单，通过所述企业员工所属企业的企业账户向所述交易账户中进行费用的报销。

步骤420：在报销处理完成的情况下，关闭所述交易账户中的所述因公交易额度。

具体的，在企业员工乙所属的企业对其4800元的费用进行报销完成的情况下，此时企业员工乙已经对支付账户中的因公业务额度4800进行偿还，而企业员工乙的支付账户中还开通有因公交易额度，为了方便对额度管理，此时可以关闭因公交易额度。

本实施例提供的因公报销处理方法，实现了在交易账户中开通因公交易额度，更加方便在报销处理时的报销处理的便捷性，并且只要是在因公交易模式下的交易事件使用因公交易额度进行数额的扣减，均可自动获取交易凭证，减少了用户的操作步骤，有效的提高了用户的体验效果，最后按照报销账单进行报销处理，有效的减少了报销处理周期，并且提高了报销效率，使得整个因公交易模式更加透明化。

与上述方法实施例相对应，本说明书还提供了业务处理装置实施例，图5示出了本说明书一实施例提供的一种业务处理装置的结构示意图。如图5所示，该装置包括：

接收处理请求模块502，被配置为接收用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额；

资源转出模块504，被配置为按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

获取处理凭证模块506，被配置为根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；

创建清单模块508，被配置为在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

资源转入模块510，被配置为按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

一个可选的实施例中，所述业务处理装置，还包括：

第一接收申请请求模块，被配置为接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

第一账户空间审核模块，被配置为根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

资源额度更新模块，被配置为在审核通过的情况下，根据所述申请资源额度对所述账户空间中的资源额度进行更新。

一个可选的实施例中，所述资源转出模块504，包括：

第一确定单元，被配置为在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间更新后的资源额度；

第一转出单元，被配置为按照所述处理资源数额对更新后的所述资源额度进行资源转出。

一个可选的实施例中，所述业务处理装置，还包括：

降低处理模块，被配置为在资源转入完成的情况下，按照所述申请资源额度对所述账户空间中更新后的所述资源额度进行降低处理。

一个可选的实施例中，所述业务处理装置，还包括：

第二接收申请请求模块，被配置为接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

第二账户空间审核模块，被配置为根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

开通模块，被配置为在审核通过的情况下，根据所述申请资源额度在所述账户空间中开通因公业务额度；所述因公业务额度用于在所述因公业务模式下的业务事件。

一个可选的实施例中，所述资源转出模块504，包括：

第二确定单元，被配置为在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间中的所述因公业务额度；

第二转出单元，被配置为按照所述处理资源数额对所述因公业务额度进行资源转出。

一个可选的实施例中，所述业务处理装置，还包括：

关闭模块，被配置为在资源转入完成的情况下，关闭所述账户空间中的所述因公业务额度。

一个可选的实施例中，所述资源转入模块510，包括：

确定规则单元，被配置为根据与所述用户参与的业务项目签订的资源流动协议，确定所述业务项目的资源流动规则；

审核清单单元，被配置为基于所述资源流动规则对所述资源转入清单进行审核；

发送单元，被配置为在所述资源转入清单通过审核的情况下，确定所述资源转入清单对应的目标资源数额并发送至所述业务项目；

接收单元，被配置为接收所述业务项目针对所述目标资源数额提交的确认请求；

转入单元，被配置为根据所述确认请求从所述业务项目账户空间向所述账户空间转入与所述目标资源数额对应的转入资源数额。

本实施例提供的业务处理装置，在接收到用户在因公业务模式下针对业务事件提交的处理请求的情况下，将按照处理请求中携带的处理资源数额，对用户的账户空间中更新后的资源额度进行资源转出处理，并根据资源转出处理结果更新业务清单，同时获取所述业务事件的处理凭证，实现了在处理业务事件的过程中，可以直接获取处理凭证，无需用户主动申请处理凭证，避免用户遗忘处理凭证，同时还可以避免出现用户垫资的情况发生；并且在用户提交转入请求的情况下，将根据转入请求涉及的至少一个业务事件以及其对应的处理凭证创建资源准入清单，最后按照所述资源转入清单进行资源转入处理，实现了在资源转入处理的过程中，减少资源转入处理的周期，有效的提高了资源转入处理的效率。

上述为本实施例的一种业务处理装置的示意性方案。需要说明的是，该业务处理装置的技术方案与上述的业务处理方法的技术方案属于同一构思，业务处理装置的技术方案未详细描述的细节内容，均可以参见上述业务处理方法的技术方案的描述。

与上述方法实施例相对应，本说明书还提供了因公报销处理装置实施例，图6示出了本说明书一实施例提供的一种因公报销处理装置的结构示意图。如图6所示，该装置包括：

接收处理请求模块602，被配置为接收企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额；

扣减模块604，被配置为按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

获取交易凭证模块606，被配置为基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证；

创建账单模块608，被配置为在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

报销处理模块610，被配置为按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

一个可选的实施例中，所述因公报销处理装置，还包括：

第一接收申请请求模块，被配置为接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

第一账户审核模块，被配置为根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

更新账户额度模块，被配置为在审核通过的情况下，根据所述申请额度对所述交易账户中的所述账户额度进行更新。

一个可选的实施例中，所述扣减模块604，包括：

第一确定单元，被配置为在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户更新后的账户额度；

第一扣减单元，被配置为按照所述交易数额对更新后的所述账户额度进行扣减。

一个可选的实施例中，所述因公报销处理装置，还包括：

降低处理模块，被配置为在报销处理完成的情况下，按照所述申请额度对所述交易账户中更新后的所述账户额度进行降低处理。

一个可选的实施例中，所述因公报销处理装置，还包括：

第二接收申请请求模块，被配置为接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

第二账户审核模块，被配置为根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

开通模块，被配置为在审核通过的情况下，根据所述申请额度在所述交易账户中开通因公交易额度；所述因公交易额度用于在所述因公交易模式下的交易事件。

一个可选的实施例中，所述扣减模块604，包括：

第二确定单元，被配置为在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户的所述因公交易额度；

第二扣减单元，被配置为按照所述交易数额对所述因公交易额度进行扣减。

一个可选的实施例中，所述因公报销处理装置，还包括：

关闭模块，被配置为在报销处理完成的情况下，关闭所述交易账户中的所述因公交易额度。

一个可选的实施例中，所述获取交易凭证模块606，包括：

展示交易页面单元，被配置为根据对所述账户额度进行扣减的扣减结果，向所述企业员工展示针对所述交易事件的交易页面；

发送请求单元，被配置为在接收到所述企业员工通过所述交易页面提交的凭证获取指令的情况下，向所述交易事件的被交易方发送凭证获取请求；

接收交易凭证单元，被配置为接收所述被交易方针对所述凭证获取请求上传的所述交易凭证。

一个可选的实施例中，所述因公报销处理装置，还包括：

审核账单模块，被配置为将所述报销账单发送至所述企业员工所属的企业进行审核处理；

在接收到所述企业针对所述报销账单的审核处理结果为审核通过的情况下，运行所述报销处理模块610。

一个可选的实施例中，所述报销处理模块610，包括：

确定报销条件单元，被配置为根据与所述企业员工所属的企业签订的报销协议，确定所述企业的报销条件；

审核账单单元，被配置为基于所述报销条件对所述报销账单进行审核；

确定报销金额信息单元，被配置为在所述报销账单通过审核的情况下，确定所述报销账单对应的报销金额信息并发送至企业；

接收确认请求单元，被配置为接收所述企业针对所述报销金额信息提交的确认请求；

报销处理单元，被配置为根据所述确认请求将所述报销金额信息对应的报销金额从所述企业账户转至所述交易账户。

本实施例提供的因公报销处理装置，在接收到企业员工在因公交易模式下针对交易事件提交的处理请求的情况下，可以按照处理请求中携带的交易数额，在企业员工的交易账户中扣减与所述交易数额对应的账户额度，并且根据交易事件对企业员工的交易账单进行更新，同时获取交易事件的交易凭证，实现了在进行交易事件的处理过程中，无需企业员工申请交易凭证，即可对交易凭证进行自动获取，同时避免在因公交易模式下企业员工垫付交易数额的情况发生；并在在后续进行报销处理的过程中，可以根据企业员工针对至少一个因公交易模式下的交易事件的报销请求，创建所述企业员工的报销账单，最后按照所述报销账单即可完成报销处理，有效的减少了报销处理周期，并且提高了报销效率，使得整个因公交易模式更加透明化。

上述为本实施例的一种因公报销处理装置的示意性方案。需要说明的是，该因公报销处理装置的技术方案与上述的因公报销处理方法的技术方案属于同一构思，因公报销处理装置的技术方案未详细描述的细节内容，均可以参见上述因公报销处理方法的技术方案的描述。

图7示出了根据本说明书一实施例提供的一种计算设备700的结构框图。该计算设备700的部件包括但不限于存储器710和处理器720。处理器720与存储器710通过总线730相连接，数据库750用于保存数据。

计算设备700还包括接入设备740，接入设备740使得计算设备700能够经由一个或多个网络760通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备740可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备700的上述部件以及图7中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图7所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备700可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备700还可以是移动式或静止式的服务器。

其中，处理器720用于执行如下计算机可执行指令：

接收用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额；

按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；

在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的业务处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述业务处理方法的技术方案的描述。

图8示出了根据本说明书一实施例提供的另一种计算设备800的结构框图。该计算设备800的部件包括但不限于存储器810和处理器820。处理器820与存储器810通过总线830相连接，数据库850用于保存数据。

计算设备800还包括接入设备840，接入设备840使得计算设备800能够经由一个或多个网络860通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备840可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备800的上述部件以及图8中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图8所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备800可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备800还可以是移动式或静止式的服务器。

其中，处理器820用于执行如下计算机可执行指令：

接收企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额；

按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证；

在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

上述为本实施例的另一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的因公报销处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述因公报销处理方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时以用于：

接收用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额；

按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

根据资源转出结果对所述用户的业务清单进行更新，并获取所述业务事件的处理凭证；

在接收到针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的业务处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述业务处理方法的技术方案的描述。

本说明书一实施例还提供另一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时以用于：

接收企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额；

按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

基于所述交易事件更新所述企业员工的交易账单，并获取所述交易事件的交易凭证；

在接收到针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

上述为本实施例的另一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的因公报销处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述因公报销处理方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书并不受所描述的动作顺序的限制，因为依据本说明书，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (24)

1.一种基于支付软件的业务处理方法，包括：

接收参与业务项目的用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额，所述业务项目具有对应的业务项目账户空间，所述用户具有所述用户标识的账户空间；

按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

根据资源转出结果对所述用户的业务清单进行更新，并通过向所述业务事件的参与方请求开具处理凭证以获取所述业务事件的处理凭证；

在接收到所述用户针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

2.根据权利要求1所述的基于支付软件的业务处理方法，还包括：

接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

在审核通过的情况下，根据所述申请资源额度对所述账户空间中的资源额度进行更新。

3.根据权利要求2所述的基于支付软件的业务处理方法，所述按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出，包括：

在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间更新后的资源额度；

按照所述处理资源数额对更新后的所述资源额度进行资源转出。

4.根据权利要求3所述的基于支付软件的业务处理方法，所述按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入步骤执行之后，还包括：

在资源转入完成的情况下，按照所述申请资源额度对所述账户空间中更新后的所述资源额度进行降低处理。

5.根据权利要求1所述的基于支付软件的业务处理方法，还包括：

接收所述用户针对所述因公业务模式提交的资源申请请求；所述资源申请请求中携带有申请资源额度和所述用户标识；

根据所述用户标识确定所述用户的所述账户空间，并对所述账户空间的属性信息进行审核；

在审核通过的情况下，根据所述申请资源额度在所述账户空间中开通因公业务额度；所述因公业务额度用于在所述因公业务模式下的业务事件。

6.根据权利要求5所述的基于支付软件的业务处理方法，所述按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出，包括：

在所述账户空间进入所述因公业务模式后，根据所述用户标识确定所述账户空间，以及所述账户空间中的所述因公业务额度；

按照所述处理资源数额对所述因公业务额度进行资源转出。

7.根据权利要求6所述的基于支付软件的业务处理方法，所述按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入步骤执行之后，还包括：

在资源转入完成的情况下，关闭所述账户空间中的所述因公业务额度。

8.根据权利要求1所述的基于支付软件的业务处理方法，所述按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入，包括：

根据与所述用户参与的业务项目签订的资源流动协议，确定所述业务项目的资源流动规则；

基于所述资源流动规则对所述资源转入清单进行审核；

在所述资源转入清单通过审核的情况下，确定所述资源转入清单对应的目标资源数额并发送至所述业务项目；

接收所述业务项目针对所述目标资源数额提交的确认请求；

根据所述确认请求从所述业务项目账户空间向所述账户空间转入与所述目标资源数额对应的转入资源数额。

9.一种基于支付软件的因公报销处理方法，包括：

接收参与业务项目的企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额，所述业务项目具有对应的业务项目账户空间，所述企业员工具有所述员工身份标识的账户空间；

按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

基于所述交易事件更新所述企业员工的交易账单，并通过向所述业务事件的参与方请求开具处理凭证以获取所述交易事件的交易凭证；

在接收到用户针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

10.根据权利要求9所述的基于支付软件的因公报销处理方法，还包括：

接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

在审核通过的情况下，根据所述申请额度对所述交易账户中的所述账户额度进行更新。

11.根据权利要求10所述的基于支付软件的因公报销处理方法，所述按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减，包括：

在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户更新后的账户额度；

按照所述交易数额对更新后的所述账户额度进行扣减。

12.根据权利要求11所述的基于支付软件的因公报销处理方法，所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤执行之后，还包括：

在报销处理完成的情况下，按照所述申请额度对所述交易账户中更新后的所述账户额度进行降低处理。

13.根据权利要求9所述的基于支付软件的因公报销处理方法，还包括：

接收所述企业员工针对所述因公交易模式提交的额度申请请求；所述额度申请请求中携带有申请额度和所述员工身份标识；

根据所述员工身份标识确定所述交易账户，并对所述交易账户的账户信息进行审核；

在审核通过的情况下，根据所述申请额度在所述交易账户中开通因公交易额度；所述因公交易额度用于在所述因公交易模式下的交易事件。

14.根据权利要求13所述的基于支付软件的因公报销处理方法，所述按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减，包括：

在所述交易账户进入所述因公交易模式后，根据所述员工身份标识确定所述企业员工的所述交易账户，以及所述交易账户的所述因公交易额度；

按照所述交易数额对所述因公交易额度进行扣减。

15.根据权利要求14所述的基于支付软件的因公报销处理方法，所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤执行之后，还包括：

在报销处理完成的情况下，关闭所述交易账户中的所述因公交易额度。

16.根据权利要求9所述的基于支付软件的因公报销处理方法，所述获取所述交易事件的交易凭证，包括：

根据对所述账户额度进行扣减的扣减结果，向所述企业员工展示针对所述交易事件的交易页面；

在接收到所述企业员工通过所述交易页面提交的凭证获取指令的情况下，向所述交易事件的被交易方发送凭证获取请求；

接收所述被交易方针对所述凭证获取请求上传的所述交易凭证。

17.根据权利要求9所述的基于支付软件的因公报销处理方法，所述根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单步骤执行之后，且所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤执行之前，还包括：

将所述报销账单发送至所述企业员工所属的企业进行审核处理；

在接收到所述企业针对所述报销账单的审核处理结果为审核通过的情况下，执行所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理步骤。

18.根据权利要求9所述的基于支付软件的因公报销处理方法，所述按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理，包括：

根据与所述企业员工所属的企业签订的报销协议，确定所述企业的报销条件；

基于所述报销条件对所述报销账单进行审核；

在所述报销账单通过审核的情况下，确定所述报销账单对应的报销金额信息并发送至企业；

接收所述企业针对所述报销金额信息提交的确认请求；

根据所述确认请求将所述报销金额信息对应的报销金额从所述企业账户转至所述交易账户。

19.一种基于支付软件的业务处理装置，包括：

接收处理请求模块，被配置为接收参与业务项目的用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额，所述业务项目具有对应的业务项目账户空间，所述用户具有所述用户标识的账户空间；

资源转出模块，被配置为按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

获取处理凭证模块，被配置为根据资源转出结果对所述用户的业务清单进行更新，并通过向所述业务事件的参与方请求开具处理凭证以获取所述业务事件的处理凭证；

创建清单模块，被配置为在接收到所述用户针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

资源转入模块，被配置为按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

20.一种基于支付软件的因公报销处理装置，包括：

接收处理请求模块，被配置为接收参与业务项目的企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额，所述业务项目具有对应的业务项目账户空间，所述企业员工具有所述员工身份标识的账户空间；

扣减模块，被配置为按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

获取交易凭证模块，被配置为基于所述交易事件更新所述企业员工的交易账单，并通过向所述业务事件的参与方请求开具处理凭证以获取所述交易事件的交易凭证；

创建账单模块，被配置为在接收到所述企业员工针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

报销处理模块，被配置为按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

21.一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：

接收参与业务项目的用户在因公业务模式下提交的业务事件的处理请求；所述处理请求中携带有用户标识和处理资源数额，所述业务项目具有对应的业务项目账户空间，所述用户具有所述用户标识的账户空间；

按照所述处理资源数额，对所述用户标识对应的账户空间在进入所述因公业务模式后更新的资源额度进行资源转出；

根据资源转出结果对所述用户的业务清单进行更新，并通过向所述业务事件的参与方请求开具处理凭证以获取所述业务事件的处理凭证；

在接收到所述用户针对所述业务清单中记录的在所述因公业务模型下提交的至少一个业务事件的转入请求的情况下，根据所述至少一个业务事件及其对应的处理凭证创建所述用户的资源转入清单；

按照所述资源转入清单，进行从所述用户参与的业务项目账户空间至所述账户空间的资源转入；所述资源转入是对所述资源转出的资源额度的恢复。

22.一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：

接收参与业务项目的企业员工在因公交易模式下提交的交易事件的处理请求；所述处理请求中携带有员工身份标识和交易数额，所述业务项目具有对应的业务项目账户空间，所述企业员工具有所述员工身份标识的账户空间；

按照所述交易数额，对所述员工身份标识对应的交易账户在进入所述因公交易模式后更新的账户额度进行扣减；

基于所述交易事件更新所述企业员工的交易账单，并通过向所述业务事件的参与方请求开具处理凭证以获取所述交易事件的交易凭证；

在接收到所述企业员工针对所述交易账单中记录的在所述因公交易模式下提交的至少一个交易事件的报销请求的情况下，根据所述至少一个交易事件及其对应的交易凭证创建所述企业员工的报销账单；

按照所述报销账单，进行从所述企业员工所属的企业账户至所述交易账户的报销处理。

23.一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现权利要求1至8任意一项所述基于支付软件的业务处理方法的步骤。

24.一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现权利要求9至18任意一项所述基于支付软件的因公报销处理方法的步骤。

Images