CN110009435A - 基于区块链的发票报销方法及装置、电子设备 - Google Patents

Abstract

本说明书一个或多个实施例提供一种基于区块链的发票报销方法及装置、电子设备，该方法可以包括：接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；响应于所述发票报销请求，确定所述目标发票的发票状态；如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

Description

基于区块链的发票报销方法及装置、电子设备

技术领域

本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的发票报销方法及装置、电子设备。

背景技术

区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种基于区块链的发票报销方法及装置、电子设备。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种基于区块链的发票报销方法，所述方法包括：

接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；

响应于所述发票报销请求，确定所述目标发票的发票状态；

如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

根据本说明书一个或多个实施例的第二方面，提出了一种基于区块链的发票报销装置，所述装置包括：

报销接收单元，接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；

状态确定单元，响应于所述发票报销请求，确定所述目标发票的发票状态；

报销单元，如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的方法。

附图说明

图1是一示例性实施例提供的一种基于区块链的发票报销方法的流程图。

图2是一示例性实施例提供的一种发票报销方案的整体架构示意图。

图3是一示例性实施例提供的一种将发票发布至区块链的交互图。

图4是一示例性实施例提供的另一种将发票发布至区块链的交互图。

图5是一示例性实施例提供的另一种基于区块链的发票报销方法的流程图。

图6是一示例性实施例提供的解锁发票的流程图。

图7是一示例性实施例提供的一种设备的结构示意图。

图8是一示例性实施例提供的一种基于区块链的发票报销装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

图1是一示例性实施例提供的一种基于区块链的发票报销方法的流程图。如图1所示，该方法应用于区块链节点，可以包括以下步骤：

步骤102，接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求。

在一实施例中，客户端可以为用户(用户为报销请求方)使用的手机、平板电脑、PC等任意类型的电子设备，本说明书并不对此进行限制。用户通过在电子设备上登录已注册账号，可与接入该电子设备的区块链节点进行交互。

在一实施例中，用户可通过客户端向区块链节点提交发票记录请求(包含发票内容)以使得该区块链节点将该发票内容存证至区块链上，进而在用户存在针对目标发票的报销需求时，通过客户端发起发票报销请求以使得区块链节点对目标发票进行报销处理。

在一实施例中，用户在完成一笔交易后，可通过客户端向区块链节点发送记录请求以使得该区块链节点将该交易的交易信息发布至区块链。例如，交易信息可以包括交易标识、交易平台、交易金额、交易内容、交易参与方、交易时间等。当然，本说明书并不对交易信息的具体内容进行限制。进一步的，用户可通过客户端向区块链节点提交发票创建请求，以使得区块链节点调用智能合约中声明的发票创建逻辑，根据存储的交易内容创建相应的发票，并将创建的发票存证在区块链上。那么，当用户存在针对目标发票的报销需求时，可通过客户端发起发票报销请求以使得区块链节点对目标发票进行报销处理。

通过将发票发布至区块链，使得各个区块链节点均记录有一份完整的发票，那么即使某个节点出现数据损坏的问题，也不会影响整体的数据完整性；同时，可充分利用区块链存储数据的不可篡改性，从而防止不法分子恶意修改发票的内容，保证了发票的安全和透明。而基于发票在链上的存证，当区块链节点接收到针对目标发票的发票报销请求时，可调用智能合约中声明的发票报销逻辑，为目标发票进行报销处理，从而实现基于区块链的发票报销方案。

步骤104，响应于所述发票报销请求，确定所述目标发票的发票状态。

在一实施例中，区块链节点在将发票存证至区块链时，可关联存证发票的发票状态(可以包括未报销状态、已报销状态和已锁定状态)。其中，在关联存证发票的发票状态时，可默认将发票设置为未报销状态；而在确定出需要对发票进行报销处理时，可先将发票由未报销状态更新为已锁定状态以防止对发票的重复报销(例如，在接收到针对某一发票的发票报销请求时，若该发票已经是已锁定状态，则说明在之前已接收到针对该发票的发票报销请求；为了防止重复报销，可直接返回报销失败的提示消息)；在对发票进行报销处理且报销成功后，可将发票更新为已报销状态。

在一实施例中，可通过存证发票标识与发票状态的映射关系来关联存证发票的发票状态。换言之，区块链中存证了发票标识与发票状态的映射关系，而基于发票报销请求中包括目标发票的标识信息，可通过以下方式确定目标发票的发票状态：响应于所述发票报销请求，调用发布在区块链上的智能合约中声明的发票查询逻辑，查询所述区块链上是否存证了与所述发票报销请求中的所述目标发票的标识信息对应的目标发票；如果是，进一步基于所述发票报销请求中的所述目标发票的标识信息查询所述映射关系，确定所述目标发票的发票状态。其中，发票标识为针对发票内容，或者发票内容中的唯一性信息进行hash计算得到的hash值。例如，唯一性信息可以包括：发票号码、发票代码、发票日期、不含税金额等信息。当然，本说明书并不对发票内容以及发票内容中唯一性信息的具体形式进行限制。

需要说明的是，上述查询区块链上是否存证有目标发票的操作以及基于映射关系确定发票状态的操作，还可由区块链节点自身执行，本说明书并不对此进行限制。

步骤106，如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

在一实施例中，用户可通过客户端填入报销单据标识(发票报销请求中包括报销单据标识)，进而使得区块链节点基于与该报销单据标识对应的报销单据对目标发票进行报销处理。而为了防止重复报销，在对目标发票进行报销处理之前，可调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存报销单据标识与目标发票的绑定关系，并在保存绑定关系后将目标发票的发票状态由未报销状态更新为已锁定状态。其中，在目标发票与任一报销单据标识绑定且被更新为已锁定状态后，区块链节点仅能够基于对应于该任一报销单据标识的报销单据对目标发票进行报销处理。进一步的，在将目标发票的发票状态由未报销状态更新为已锁定状态后，可调用发布在区块链上的智能合约中声明的发票报销逻辑，针对目标发票进行报销处理。

在一实施例中，如果确定出目标发票的发票状态为已报销状态或者已锁定状态，向客户端返回报销失败的提示信息。其中，当发票状态为已报销状态时，返回的报销失败的提示信息可以是用于提示用户目标发票已被报销；当发票状态为已锁定状态时，返回的报销失败的提示信息可以是用于提示用户目标发票已被锁定(即无法进行报销处理)。

在一实施例中，当用户通过客户端提交发票报销请求使得目标发票被锁定后，只有该用户具有解除目标发票处于已锁定状态的权限。那么，当用户通过客户端提交发票报销请求以请求对目标发票进行报销处理但报销失败后(例如，不在设定的报销期限内、报销金额超出额度等)，由于目标发票处于已锁定状态(与报销单据标识绑定)，若该用户需重新请求对目标发票进行报销处理(例如，调整在设定的报销期限内、调整报销金额等)，则需要先对目标发票进行解锁处理。因此，区块链节点可接收用户在目标发票报销失败后通过客户端发起的针对目标发票的解锁请求，以及响应于该解锁请求，调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定解锁请求的发送方是否为发票报销请求的发送方(即确定解锁请求的发送方是否具有解锁的权限)；如果是，删除报销单据标识与目标发票的绑定关系，将目标发票的发票状态由已锁定状态更新为未报销状态，并向客户端返回解锁成功的提示信息。进一步的，在对目标发票成功进行解锁后，该用户可通过客户端再次提交发票报销请求(包括其他报销单据标识)以对目标发票进行报销处理。

在一实施例中，上述区块链可以为联盟链，联盟链的节点成员可以包括支付平台、税务机关等。

需要说明的是，区块链中的交易，存在狭义的交易以及广义的交易之分。狭义的交易是指用户向区块链发布的一笔价值转移；例如，在传统的比特币区块链网络中，交易可以是用户在区块链中发起的一笔转账。而广义的交易是指用户向区块链发布的一笔具有业务意图的业务数据；例如，运营方可以基于实际的业务需求搭建一个联盟链，依托于联盟链部署一些与价值转移无关的其它类型的在线业务(比如，租房业务、车辆调度业务、保险理赔业务、信用服务、医疗服务等)，而在这类联盟链中，交易可以是用户在联盟链中发布的一笔具有业务意图的业务消息或者业务请求。

图2是一示例性实施例提供的一种发票报销方案的整体架构示意图。如图2所示，报销请求方可在客户端21中输入目标发票的发票内容，客户端21基于用户输入的发票内容向服务器22发送发票报销请求；而服务器22(作为区块链节点)在接收到发票报销请求后确定区块链中存证的目标发票的发票状态，进而在目标发票的发票状态为未报销状态时对目标发票进行报销处理，并在报销成功后将目标发票更新为已报销状态。

为了便于理解，下面针对客户端21、服务器22分别在发票报销过程中实现的操作和功能，结合图3-6对本说明书的发票报销方案进行详细说明。图3是一示例性实施例提供的一种发票上链的交互示意图。如图3所示，该交互过程可以包括以下步骤：

步骤302，客户端21与服务器22之间实现对绑定关系的建立。

在一实施例中，所需建立的绑定关系为用户的身份信息与客户端21的设备信息之间的绑定关系。基于该绑定关系，使得服务器22在接收到客户端21后续发送的发票记录请求、发票创建请求和发票报销请求时，可以确认这些请求对应于该用户。

举例而言，用户可以预先在服务器22处进行账号注册，得到与自身唯一对应的已注册账号。然后，用户可以通过在客户端21上登录该已注册账号，而服务器22基于该已注册账号在客户端21上的登录信息，确定该已注册账号(对应于该用户)与客户端21之间建立了绑定关系。

步骤304，客户端21获取待记录的发票。

在一实施例中，用户在完成一笔交易并开具发票后，可通过客户端21输入发票内容，客户端21进而向服务器22提交发票记录请求(包含发票内容)，以使得服务器22将待记录的发票发布至区块链中。其中，用户可以预先注册得到唯一对应的数字身份，该数字身份由一组公私钥对进行表征。相应地，客户端21在获取到用户输入的发票内容后，可生成发票记录请求并通过对应于该用户的数字身份的私钥对发票记录请求进行签名。

步骤306，客户端21向服务器22提交发票记录请求。

步骤308，服务器22验证签名。

在一实施例中，服务器22上运行有区块链的客户端，使得该服务器22被配置为一区块链节点。服务器22在接收到发票记录请求后，可基于上述步骤302建立的绑定关系确定出用户的身份，从而通过对应于该用户的公钥进行验签，以确定该发票记录请求已由该用户进行授权，而并非由不法分子冒充该用户的身份进行发送。

步骤310，服务器22将发票发布至区块链。

步骤312，服务器22将发票标记为未报销状态。

在一实施例中，服务器22可通过调用智能合约中声明的映射建立逻辑，根据发票内容中的唯一性信息(发票号码、发票代码、发票日期、不含税金额等信息)进行hash计算得到相应的hash值(作为发票标识)，并建立各发票的hash值与发票状态的映射关系。其中，可将发布至区块链的发票默认设定为未报销状态。

请参见图4，图4是一示例性实施例提供的另一种发票上链的交互示意图。如图4所示，该交互过程可以包括以下步骤：

步骤402，客户端21与服务器22之间实现对绑定关系的建立。

步骤404，客户端21获取待记录的交易信息。

在一实施例中，用户在完成一笔交易后，可通过客户端21输入交易信息，客户端21进而向服务器22提交交易记录请求(包含交易信息)，以使得服务器22将待记录的交易发布至区块链中。

步骤406，客户端21向服务器22提交交易记录请求。

步骤408，服务器22验证签名。

在一实施例中，客户端21对交易记录请求进行签名，以及服务器22验证签名的原理与上述类似，在此不再赘述。

步骤410，服务器22将交易信息发布至区块链。

步骤412，客户端21向服务器22提交发票创建请求。

在一实施例中，当用户需要针对某一交易开具发票时，可通过客户端21向服务器22提交针对该交易的发票创建请求，以使得服务器22调用智能合约中声明的发票创建逻辑为该交易创建发票。其中，发票创建请求中可以包括交易标识和用户通过客户端输入的发票创建信息。

步骤414，服务器22验证签名。

步骤416，服务器22调用智能合约中声明的发票创建逻辑，根据发票创建信息创建发票并将创建的发票发布至区块链。

在一实施例中，该智能合约可由支付机构和税务机关预先部署于区块链。

在一实施例中，用户输入的发票创建信息可以包括发票的抬头信息和交易信息，服务器22在接收到发票创建请求后将发票创建信息中包含的交易信息与区块链上存证的交易信息(与交易标识相对应)进行对比，当对比结果为两者一致时，直接根据发票创建信息中包含的交易信息和抬头信息创建发票。例如，服务器22在接收到针对目标交易的发票创建请求后，读取发票创建信息中包含的交易信息并计算得到第一哈希值，将该第一哈希值与区块链上存证的交易信息(与交易标识相对应)的第二哈希值进行对比，当第一哈希值与第二哈希值相等时，可确定用户输入的交易信息即为目标交易的交易信息，那么可直接根据用户输入的交易信息和抬头信息为目标交易创建发票，而无需读取区块链上存证的目标交易的交易信息，从而提高创建发票的效率。

步骤418，服务器22将发票标记为未报销状态。

在一实施例中，服务器22可通过调用智能合约中声明的映射建立逻辑，根据发票内容中的唯一性信息(发票号码、发票代码、发票日期、不含税金额等信息)进行hash计算得到相应的hash值(作为发票标识)，并建立各发票的hash值与发票状态的映射关系。其中，可将发布至区块链的发票默认设定为未报销状态。

基于将发票发布至区块链，用户可进一步针对目标发票请求进行报销处理。请参见图5，图5是一示例性实施例提供的基于区块链的另一种发票报销方法的流程图。如图5所示，该方法应用于区块链节点(以服务器22为例)，可以包括以下步骤：

步骤502，接收用户通过客户端21发起的针对在区块链中存证的目标发票的发票报销请求。

在一实施例中，发票报销请求中包括目标发票的发票内容，或者为客户端根据用户输入的发票内容中的唯一性信息(发票号码、发票代码、发票日期、不含税金额等信息)进行hash计算得到的hash值，以及报销单据标识。

步骤504，获取目标发票的发票标识。

在一实施例中，当发票报销请求中记录的是目标发票的发票内容时，读取发票内容中的唯一性信息进行hash计算以得到目标发票的发票标识；当发票报销请求中记录有目标发票的发票标识(客户端根据用户输入的发票内容中的唯一性信息进行hash计算得到的hash值)时，直接读取该发票标识即可。

步骤506，若区块链上存证了与获取到发票标识对应的目标发票，则转入步骤510；否则转入步骤508。

在一实施例中，可调用发布在区块链上的智能合约中声明的发票查询逻辑，查询区块链上是否存证了与获取到发票标识对应的目标发票。当然，也可以由服务器22自身来执行上述查询目标发票的操作，本说明书并不对此进行限制。

步骤508，向客户端21返回发票不存在的提示消息。

步骤510，根据区块链上存证的发票标识与发票状态的映射关系，确定对应于获取到的发票标识的发票状态。

举例而言，假定区块链上存证的映射关系如表1所示：

发票标识(hash值)	发票状态
		发票a	未报销状态
发票b	已锁定状态(发票b与报销单据标识b绑定)
		发票c	已报销状态
……	……

表1

步骤512，若发票状态为未报销状态，则转入步骤514；否则，转入步骤526。

步骤514，调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存报销单据标识与目标发票的绑定关系，并在保存该绑定关系后，将目标发票的发票状态由未报销状态更新为已锁定状态。

以发票a为例，承接于上述举例，区块链上存证的映射关系如表2所示：

发票标识(hash值)	发票状态
		发票a	已锁定状态(发票a与报销单据标识a绑定)
发票b	已锁定状态(发票b与报销单据标识b绑定)
		发票c	已报销状态
……	……

表2

步骤516，若目标发票为已锁定状态，则转入步骤520；否则，转入步骤518。

步骤518，向客户端返回锁定失败的提示信息。

在一实施例中，当通过步骤514执行锁定目标发票的操作后，可能出现锁定失败的情况(需要说明的是，该情况区别于发票在之前已经被锁定的情况；例如，服务器22因被占用过多处理资源导致已无法再继续调用智能合约)，因此，在应当执行锁定操作(此时目标发票为未报销状态)而执行的结果为锁定失败时，可向客户端21返回锁定失败的提示信息。那么用户在客户端21侧接收到该提示消息后，可后续再重新提交针对目标发票的发票报销请求。

步骤520，在将目标发票的发票状态由未报销状态更新为已锁定状态后，调用区块链上的智能合约中声明的发票报销逻辑，针对目标发票进行报销处理。

步骤522，若报销成功，则转入步骤524；否则，转入步骤526。

步骤524，在报销成功后将目标发票由已锁定状态更新为已报销状态。

步骤526，向客户端21返回报销失败的提示信息。

在一实施例中，承接于步骤512，当目标发票为已锁定状态时，说明在(步骤502)之前已接收到针对目标发票的发票报销请求；因此，为了防止重复报销，可直接返回用于提示用户目标发票已被锁定的提示消息。当发票状态为已报销状态时，可返回用于提示用户目标发票已被报销的提示消息。

在一实施例中，承接于步骤522，在对目标发票进行报销处理时，可能出现报销失败的情况。例如，不在设定的报销期限内、报销金额超出额度等。因此，当报销失败后，可返回用于提示用户目标发票报销失败的提示消息(可具体标明报销失败的原因)。

在一实施例中，当用户通过客户端提交发票报销请求使得目标发票被锁定后，只有该用户具有解除目标发票处于已锁定状态的权限。那么，当用户通过客户端提交发票报销请求以请求对目标发票进行报销处理但报销失败后(例如，不在设定的报销期限内、报销金额超出额度等)，由于目标发票处于已锁定状态(与报销单据标识绑定)，若该用户需重新请求对目标发票进行报销处理(例如，调整在设定的报销期限内、调整报销金额不超过额度等)，则需要先对目标发票进行解锁处理。下面结合图6进行详细说明。

请参见图6，图6是一示例性实施例提供的解锁发票的流程图。如图6所示，该方法应用于区块链节点(以服务器22为例)，可以包括以下步骤：

步骤602，接收用户在目标发票报销失败后通过客户端发起的针对目标发票的解锁请求。

步骤604，若该用户具有解锁的权限，转入步骤606；否则，转入步骤610。

在一实施例中，可调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定解锁请求的发送方是否为发票报销请求的发送方；如果是，删除报销单据标识与目标发票的绑定关系，将目标发票的发票状态由已锁定状态更新为未报销状态，并向客户端21返回解锁成功的提示信息。那么，在对目标发票成功进行解锁后，该用户可通过客户端再次提交发票报销请求(包括其他报销单据标识)以对目标发票进行报销处理。其中，可采用上述步骤302中用户注册得到的账号来确定解锁请求的发送方是否为发票报销请求的发送方，还可以采用步骤306-308中验签的方式。当然，本说明书并不对此进行限制。

步骤606，删除报销单据标识与目标发票的绑定关系，将目标发票的发票状态由已锁定状态更新为未报销状态。

以解锁发票a为例，承接于上述举例，映射关系更新为如表3所示：

发票标识(hash值)	发票状态
		发票a	未报销状态
发票b	已锁定状态(发票b与报销单据标识b绑定)
		发票c	已报销状态
……	……

表3

步骤608，向客户端21返回解锁成功的提示信息。

步骤610，当用户不具有解锁的权限时，向客户端21返回解锁失败的提示信息。

图7是一示例性实施例提供的一种设备的示意结构图。请参考图7，在硬件层面，该设备包括处理器702、内部总线704、网络接口707、内存708以及非易失性存储器710，当然还可能包括其他业务所需要的硬件。处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行，在逻辑层面上形成基于区块链的发票报销装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图8，在软件实施方式中，该基于区块链的发票报销装置可以包括：

报销接收单元81，接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；

状态确定单元82，响应于所述发票报销请求，确定所述目标发票的发票状态；

报销单元83，如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

可选的，所述区块链中存证了发票标识与发票状态的映射关系；所述发票报销请求中包括所述目标发票的标识信息；

所述状态确定单元82具体用于：

响应于所述发票报销请求，调用发布在区块链上的智能合约中声明的发票查询逻辑，查询所述区块链上是否存证了与所述发票报销请求中的所述目标发票的标识信息对应的目标发票；

如果是，进一步基于所述发票报销请求中的所述目标发票的标识信息查询所述映射关系，确定所述目标发票的发票状态。

可选的，所述发票标识为针对发票内容，或者发票内容中的唯一性信息进行hash计算得到的hash值。

可选的，所述发票报销请求包括报销单据标识；

在调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理之前，还包括：

锁定单元84，调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存所述报销单据标识与所述目标发票的绑定关系，并在保存所述绑定关系后，将所述目标发票的发票状态由未报销状态更新为已锁定状态；

所述报销单元83具体用于：在将所述目标发票的发票状态由未报销状态更新为已锁定状态后，调用所述发票报销逻辑，针对所述目标发票进行报销处理。

可选的，还包括：

提示单元85，如果所述目标发票的发票状态为已报销状态或者已锁定状态，向所述客户端返回报销失败的提示信息。

可选的，还包括：

解锁接收单元86，接收用户在所述目标发票报销失败后通过客户端发起的针对所述目标发票的解锁请求；

鉴权单元87，响应于所述解锁请求，调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定所述解锁请求的发送方是否为所述发票报销请求的发送方；

解锁单元88，如果是，删除所述报销单据标识与所述目标发票的绑定关系，将所述目标发票的发票状态由已锁定状态更新为未报销状态，并向所述客户端返回解锁成功的提示信息。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

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

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

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (13)

1.一种基于区块链的发票报销方法，所述方法包括：

接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；

响应于所述发票报销请求，确定所述目标发票的发票状态；

如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

2.根据权利要求1所述的方法，所述区块链中存证了发票标识与发票状态的映射关系；所述发票报销请求中包括所述目标发票的标识信息；

所述响应于所述发票报销请求，确定所述目标发票的发票状态，包括：

响应于所述发票报销请求，调用发布在区块链上的智能合约中声明的发票查询逻辑，查询所述区块链上是否存证了与所述发票报销请求中的所述目标发票的标识信息对应的目标发票；

如果是，进一步基于所述发票报销请求中的所述目标发票的标识信息查询所述映射关系，确定所述目标发票的发票状态。

3.根据权利要求2所述的方法，所述发票标识为针对发票内容，或者发票内容中的唯一性信息进行hash计算得到的hash值。

4.根据权利要求1所述的方法，所述发票报销请求包括报销单据标识；

在调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理之前，还包括：调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存所述报销单据标识与所述目标发票的绑定关系，并在保存所述绑定关系后，将所述目标发票的发票状态由未报销状态更新为已锁定状态；

所述调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，包括：在将所述目标发票的发票状态由未报销状态更新为已锁定状态后，调用所述发票报销逻辑，针对所述目标发票进行报销处理。

5.根据权利要求4所述的方法，还包括：

如果所述目标发票的发票状态为已报销状态或者已锁定状态，向所述客户端返回报销失败的提示信息。

6.根据权利要求4所述的方法，还包括：

接收用户在所述目标发票报销失败后通过客户端发起的针对所述目标发票的解锁请求；

响应于所述解锁请求，调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定所述解锁请求的发送方是否为所述发票报销请求的发送方；

如果是，删除所述报销单据标识与所述目标发票的绑定关系，将所述目标发票的发票状态由已锁定状态更新为未报销状态，并向所述客户端返回解锁成功的提示信息。

7.一种基于区块链的发票报销装置，所述装置包括：

报销接收单元，接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；

状态确定单元，响应于所述发票报销请求，确定所述目标发票的发票状态；

报销单元，如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。

8.根据权利要求7所述的装置，所述区块链中存证了发票标识与发票状态的映射关系；所述发票报销请求中包括所述目标发票的标识信息；

所述状态确定单元具体用于：

响应于所述发票报销请求，调用发布在区块链上的智能合约中声明的发票查询逻辑，查询所述区块链上是否存证了与所述发票报销请求中的所述目标发票的标识信息对应的目标发票；

如果是，进一步基于所述发票报销请求中的所述目标发票的标识信息查询所述映射关系，确定所述目标发票的发票状态。

9.根据权利要求8所述的装置，所述发票标识为针对发票内容，或者发票内容中的唯一性信息进行hash计算得到的hash值。

10.根据权利要求7所述的装置，所述发票报销请求包括报销单据标识；

在调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理之前，还包括：

锁定单元，调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存所述报销单据标识与所述目标发票的绑定关系，并在保存所述绑定关系后，将所述目标发票的发票状态由未报销状态更新为已锁定状态；

所述报销单元具体用于：在将所述目标发票的发票状态由未报销状态更新为已锁定状态后，调用所述发票报销逻辑，针对所述目标发票进行报销处理。

11.根据权利要求10所述的装置，还包括：

提示单元，如果所述目标发票的发票状态为已报销状态或者已锁定状态，向所述客户端返回报销失败的提示信息。

12.根据权利要求10所述的装置，还包括：

解锁接收单元，接收用户在所述目标发票报销失败后通过客户端发起的针对所述目标发票的解锁请求；

鉴权单元，响应于所述解锁请求，调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定所述解锁请求的发送方是否为所述发票报销请求的发送方；

解锁单元，如果是，删除所述报销单据标识与所述目标发票的绑定关系，将所述目标发票的发票状态由已锁定状态更新为未报销状态，并向所述客户端返回解锁成功的提示信息。

13.一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如权利要求1-6中任一项所述的方法。