发票报销中的信息处理方法、装置、网关服务器和介质与流程

本公开涉及区块链领域，具体涉及一种发票报销中的信息处理方法、装置、网关服务器和介质。

背景技术：

目前的发票报销有两种报销流程。一种是线下报销，一种是线上报销。在线下报销的情况下，单位的员工在商家为单位买物品，取得商家的电子发票，将电子发票打印出来，拿到单位报销。如果在打印前，员工对电子发票修改后再打印，报销单位无法查证，造成大量虚假发票报销。在线上报销的情况下，员工同样也可以在将电子发票在电脑上修改后，在线上转给单位的财务设备进行报销，造成虚拟发票报销。现有的发票报销机制无法监控报销的发票是否与开出时一致。

另外，还会有重复报销的情况出现。在线下报销的情况下，员工可以打印电子发票后，对抬头进行涂改，在多个单位分别报销，多个单位也难以核实出来。在线上报销的情况下，也有先进的技术手段对电子发票的抬头在电脑中进行修改，从而在不同单位分别报销。现有的发票报销机制也缺乏对于重复报销的监控。

技术实现要素：

本公开的一个目的在于提出一种发票报销中的信息处理技术，它能够防止虚假发票的报销，即报销发票与开票时的发票不一致时拒绝报销发票。

根据本公开实施例的一方面，公开了一种发票报销中的信息处理方法，包括：

接收发票报销请求，所述发票报销请求包含区块链上记录的开出所述发票的事件区块的标识、发票信息、开票事件发票转移信息；

按照所述开出所述发票的事件区块的标识，查找所述区块链上记录的开出所述发票的事件区块；

在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，发送允许所述发票报销的应答。

根据本公开实施例的一方面，公开了一种发票报销中的信息处理装置，包括：

第一接收单元，用于接收发票报销请求，所述发票报销请求包含区块链上记录的开出所述发票的事件区块的标识、发票信息、开票事件发票转移信息；

第一查找单元，用于按照所述开出所述发票的事件区块的标识，查找所述区块链上记录的开出所述发票的事件区块；

第一发送单元，用于在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，发送允许所述发票报销的应答。

根据本公开实施例的一方面，公开了一种区块链网关服务器，包括：存储器，存储有计算机可读指令；处理器，读取存储器存储的计算机可读指令，以执行以上所述的方法。

根据本公开实施例的一方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。

本公开实施例中，将开出发票时的发票信息、开票事件发票转移信息作为开出发票的事件区块的区块主体的至少一部分，记录在区块链上，为该区块生成一个标识。在发票报销时，提供发票信息、以及开票事件发票转移信息。由于区块链的共识机制，开票时写在区块链上的发票信息、开票事件发票转移信息是无法被篡改而且区块链上的所有节点都能看见，因此，可以通过将在发票报销时提供的发票信息、以及开票事件发票转移信息与区块链上记录的开票时的发票信息、以及开票事件发票转移信息相比对，判断出该发票是否是虚假发票，从而避免了虚假发票的报销。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1a-1o示出了根据本公开一个实施例的发票报销中的信息处理方法应用在线上报销应用场景时，从发票发行到发票报销所涉及的各种界面的示意图。

图2a-2g示出了根据本公开一个实施例的发票报销中的信息处理方法应用在线下报销应用场景时所涉及的各种界面的示意图。

图3a示出了根据本公开一个实施例的发票报销中的信息处理方法应用于的体系构架图。

图3b示出了图3a所示的体系构架中发票的完整流转过程图。

图4示出了根据本公开一个实施例的发票报销中的信息处理方法的流程图。

图5示出了根据本公开一个实施例的发票报销中的信息处理方法的流程图。

图6示出了根据本公开一个实施例的图5中步骤450的具体流程图。

图7示出了根据本公开一个实施例的图4中步骤430的具体流程图。

图8示出了根据本公开一个实施例的图7中步骤4301的具体流程图。

图9示出了根据本公开一个实施例的发票报销中的信息处理方法的流程图。

图10示出了根据本公开一个实施例的发票报销中的信息处理方法的流程图。

图11示出了根据本公开一个实施例的发票报销中的信息处理方法的流程图。

图12示出了根据本公开一个实施例的发票报销中的信息处理方法的流程图。

图13a示出了根据本公开一个实施例的在线上报销的情况下员工终端、报销单位终端、区块链网关服务器的交互流程图。

图13b示出了根据本公开一个实施例的在线下报销的情况下员工终端、报销单位终端、区块链网关服务器的交互流程图。

图14示出了根据本公开一个实施例的发票报销中的信息处理装置的框图。

图15示出了根据本公开一个实施例的区块链网关服务器的硬件结构图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下面先参照图3a-3b描述一下本公开实施例所应用的体系构架和整体流程。

图3a示出了本公开实施例所应用的一种体系架构。该体系构架包括区块链发票管理系统4、位于工商机关3的发票发行终端301、位于开票单位(申领发票单位)2的开票终端201、位于发票报销单位1的发票报销单位终端101和员工终端102。区块链发票管理系统4包括区块链网关服务器401、区块链服务器402和银行系统服务器404。区块链发票管理系统4中一般有多个区块链服务器402。该多个区块链服务器402基于区块链技术管理各个用户(包括发票发行终端301、开票终端201、报销单位终端101和员工终端102)的电子发票。区块链网关服务器401用于提供用户与区块链发票管理系统4之间的访问服务，也可以作为本实施环境中的记账节点。银行系统服务器404用于处理发票中涉及的银行付款等问题。

发票发行终端301、开票终端201、报销单位终端101和员工终端102可以是专用终端，也可以是安装了应用之后的通用终端，例如台式电脑、手机、pda、笔记本电脑等。区块链网关服务器401、区块链服务器402和银行系统服务器404中的每一个可以由单台计算机或单台计算机上的一部分(作为虚拟机)实现，也可以由多台联网的计算机实现，还可以由多台联网的计算机各自一部分联合实现。例如，它可以采用虚拟机集群的形式，即从多台物理机上分别划分出一部分作为虚拟机，集体行使其功能。在云环境下，其还可以由云环境中的多台分布式计算设备联合实现。

区块链发票管理系统4和该区块链发票管理系统4的每个用户(包括发票发行终端301、开票终端201、报销单位终端101和员工终端102)可以都是一个区块链节点，即记录所有上区块链记录的发票信息。区块链发票管理系统4和该区块链发票管理系统4的每个用户上可分别存储相同的一条区块链，该区块链由多个区块组成，每个区块均存储有不同的信息，区块链上的区块按照时间顺序进行存储。对于存储相同的区块链的每个设备，称为一个区块链节点。在本发明实施例中，每个区块可以记录发票流转中的一次事件涉及的信息。例如，对于发行发票事件，在区块链上记录一个区块，其记录发行发票事件涉及的信息，包括发票信息、发行发票事件发票转移信息；对于开票事件，在区块链上记录一个区块，其记录开票事件涉及的信息，包括发票信息、开票事件发票转移信息；对于发票报销事件，在区块链上记录一个区块，其记录发票报销事件涉及的信息，包括发票信息、发票报销事件发票转移信息。该区块链发票管理系统4和该区块链发票管理系统4的用户上可分别存储相同的一条区块链，因此，起到了共同监督作用，该区块链上记录的任何信息不能篡改。因此，本公开实施例中，可以利用区块链上的数据不能篡改的特性，在发票报销环节，将发票报销请求含有的发票信息、开票事件发票转移信息与相应开票环节记录的发票信息、开票事件发票转移信息进行对比，对比一致才允许报销，防止了虚假发票报销。

如图3b所示，本公开实施例中，发票的发行、开出、报销等事件都会由区块链网关服务器401记载到各个区块链节点上，使得实施环境中的其他节点可以共享发票信息，从而使得各个节点可以为发票信息提供一致性证明，提高了发票信息的安全性。本公开实施例将发票作为一种资产发行，资产的每一次转移都看成一次事件，由区块链网关服务器401记录到区块链节点上。具体地，发票发行终端301向开票终端201发行发票，同时将发行发票的事件通过区块链网关服务器401记录到各区块链节点中。开票终端201将发票开给报销单位的员工，因此，开票时电子发票转移到员工终端102中，同时开票事件由区块链网关服务器401记录到区块链节点上。员工将发票拿到报销单位终端101报销时，报销单位终端101上报区块链网关服务器401，由区块链网关服务器401调取该发票开票时在区块链上记录的开票事件，将报销的发票信息与开票事件中的信息进行核对，如果无误，说明该发票不是虚假发票。同时，区块链网关服务器401也可以将发票的报销人与目前记录的发票所转移到的人进行核对，如果无误，说明该发票不是重复报销。在发票不是虚假发票，且不是重复报销的情况下，允许发票报销。报销后，发票报销单位终端101将发票报销事件通过区块链网关服务器401记录到区块链节点上。

下面结合图1a-1o、以及图2a-2g，描述根据本公开一个实施例的发票报销中的信息处理方法应用在线上报销应用场景时和线下报销应用场景时的简要过程。从这些图的描述中，能够了解发票从发行到报销的所有环节的一个完成过程。

图1a-1o示出了根据本公开一个实施例的发票报销中的信息处理方法应用在线上报销应用场景时，从发票发行到发票报销所涉及的各种界面的示意图。

需要发票的单位(包括企业、事业、国家机关、社会团队)首先在工商机关申领发票。然后，工商机关向该单位发行发票，发行发票时在工商机关的发票发行系统显示的界面如图1a所示。在图1a所示的界面上，工商机关的工作人员需要填写申领发票单位、申领发票单位纳税人识别号、拟为该申领发票单位发行的发票代码、发票号码、发票的使用规则、发行机关。其中，发票代码和发票号码合在一起组成发票标识，是唯一区别该发票与其它发票不同的标志。发票代码是唯一识别发票发行的批次的标志。为申领发票单位发放的一批发票，其发票代码都是相同的。通过发票代码，可以区分发票发放的批次。发票号码是在一个批次中识别具体发票的唯一的标识。在同一批次中，不同发票的发票号码各不相同。利用发票代码加上发票号码，就可以唯一识别该发票。在发行时，发行机关一般不会只对申领发票单位发行一张发票，因此，发票号码往往会填写一个范围。使用规则是发票在开出时必须遵循的规则。例如，可以规定，每张发票的填写额度不得超过10万元，每周发票开出总额不得超过100万元，发票抬头必须是深圳市下属单位，等等。工商机关为申领发票单位定好规则后，申领发票单位在开出发票时，系统就会自动核实该发票是否符合该使用规则。例如，检查发票的填写额度是否没有超过10万元，计算该系统这一周开出的发票总额，审核该总额在该发票开出后是否没有超过100万元，该发票的抬头是否是深圳市下属单位，等等。在填写完毕后，工商机关的工作人员点“确认”按钮，发票发行系统根据界面上填写的信息生成向申请发票单位发放的电子发票，这些电子发票自动传送到申请发票单位的发票开具系统中。同时，发票发行系统将此次发票发行行为作为一个发票发行事件，记录在区块链上，作为一个发行发票的事件区块，该区块中记录有如图1a填写的发票信息、以及发行发票事件发票转移信息。发票转移信息包括发票的转出方信息、转入方信息、转移时间。在发行发票事件中，转出方是工商机关，如图1a所示的“深圳市工商局”，转入方是申领发票单位，如图1a所示的“深圳市绿野有限责任公司”，转移时间是在点击图1a的“确认”按钮后，开始发行发票的时间，该时间是由发票发行系统自动记录的。

在开票时，在开票单位的发票开具系统上显示如图1b所示的界面。左侧界面的开票人、开票人纳税人识别号、发票代码、发票号码、使用规则、地址、电话、开户行及账号是发票开具系统自动填写好的，其中，可以在图1a所示的为该开票单位发放的发票号码的范围中顺序选取未发放的发票号码自动填写在左侧界面，例如按照发票号码由小到大的顺序选取。右侧界面中的信息需要开票单位的负责开票的员工开票时填写，主要有发票抬头名称、发票抬头纳税人识别号、领取人、领取人电话、地址、电话、开户行及账号、金额、用途等。填写完毕后，开票单位的员工点“确认”按钮。发票开具系统根据界面上填写的信息开出开票单位开出的电子发票，这些电子发票通过下文描述的微信扫描等方式转移到领取人(即发票报销单位的员工)的卡包中。同时，发票开具系统将此次开票的行为作为一个开票事件，记录在区块链上，作为一个开票的事件区块，该区块中记录有如图1b填写的发票信息、以及开票事件发票转移信息。发票转移信息包括发票的转出方信息、转入方信息、转移时间。在开票事件中，转出方是开票单位，如图1b所示的“深圳市绿野有限责任公司”，转入方是员工，如图1b所示的“张新”，转移时间是在点击图1b的“确认”按钮后，开始开票的时间，该时间是由发票开具系统自动记录的。

在图1b中，开票单位的员工点“确认”按钮之后，界面上出现图1c所示的二维码。员工用自己的手机，即员工终端102扫描该二维码后，电子发票会自动存入员工手机，例如存在手机的微信卡包中。

当员工用手机扫描图1c中的二维码之后，图1d的界面上出现提示“您已成功扫描二维码，电子发票已存入微信的卡包”。

员工看到图1d的界面后，打开微信，触摸右下角的“我”选项，屏幕上出现“钱包”、“收藏”、“相册”、“卡包”等选项，如图1e所示。

员工选择图1e上显示的“卡包”选项，出现图1f所示的界面。该界面上列出了员工的卡包中的内容，其中包括“卡”、“朋友的优惠券”、“我的票券”等。电子发票在“我的票券”中。

员工在图1f所示的界面上选择“我的票券”，屏幕上显示该员工手机上存储的所有票券，其中有三张发票，用发票标识区分，该发票标识由发票代码-发票号码构成，如图1g所示。

员工选择图1g的界面上显示的一张发票，屏幕上出现如图1h所示的界面。该界面上列出可对该发票进行的动作选项，包括“浏览”、“打印”、“发送到”。“打印”选项一般用于将电子发票打印成纸件线下报销的情况。“发送到”选项一般用于将电子发票发送到报销单位终端上以便进行电子发票报销的情况。“浏览”选项一般用于在打印成纸件或者发送到报销单位之前查看该发票。

员工在图1h所示的界面上输入报销单位终端的注册id，将电子发票发送到报销单位终端报销。这时，在报销单位终端的屏幕上，自动生成如图1i所示的界面。该界面展示的信息包括发票信息和开票事件发票转移信息。其中，发票信息是根据传到报销单位终端的电子发票上的信息自动生成的，它与图1b中的信息基本上是相同的。而开票事件发票转移信息则是报销单位终端的发票报销系统自动生成的。它包括转出方信息、转入方信息、转入方电话、转移时间(未示)等，其中转出方信息是按照发票信息中的开票人信息生成的，与该开票人信息一致，例如图1b中的“深圳市绿野有限责任公司”；转入方信息是按照发票信息中的领取人信息生成的，与领取人信息一致，例如图1b中的“张新”；转入方电话是按照发票信息中的领取人电话生成的，例如图1b中的“13550422355”。

报销单位的财务人员审核图1i的界面，认为无误后，其需要检查这张发票是否是虚假的，以及这张发票是否是重复报销等情况，但报销单位本身不能进行这种检查，需要将请求发送到区块链发票管理系统4，让区块链发票管理系统4进行这种检查，然后将检查结果返回给报销单位终端，以便报销单位的财务人员决定是否应该报销此发票。这时，报销单位的财务人员选择图1i界面的“发送发票报销请求”按钮，这样，报销单位终端向区块链发票管理系统4发送发票报销请求，所述发票报销请求中含有如图1i所示的信息。区块链发票管理系统4开始对该发票报销请求进行审核，判断是否允许报销。

在报销单位的财务人员选择图1i的“发送发票报销请求”后，出现图1j的界面。该界面中显示“平台正在审核您的发票报销请求，请耐心等待”。

区块链发票管理系统4审核该发票时，查找在区块链中存储的该发票的开票时产生的事件区块中的发票信息、开票事件发票转移信息。如果发票报销请求中的发票信息、开票事件发票转移信息与在区块链中存储的该发票的开票时产生的事件区块中的发票信息、开票事件发票转移信息不一致，则该发票是篡改的或虚假的发票。此时，显示如图1k所示的界面，显示“您的发票信息与备案的发票信息不符，因此有篡改行为，审核未通过”。

如果发票报销请求中的发票信息、开票事件发票转移信息与在区块链中存储的该发票的开票时产生的事件区块中的发票信息、开票事件发票转移信息一致，则该发票不是篡改的或虚假的发票。在本公开的一个实施例中，还要验证该发票是否是重复报销的发票。由于在发票报销后，对于线上报销的情况，在完成一次报销后，发票作为一种资产，要将所有权从员工转到报销单位，此时，如果区块链发票管理系统4检查到当前的发票所有者不是报销的员工，很可能说明该发票已经报销过一次，已经完成了所有权的转移，此时，也不允许发票报销。对于线下报销的情况，报销单位报销时可能会向区块链发票管理系统4查询是否应该将该发票报销，但报销后由于该报销单位不在线上，其不关心也不想去向区块链发票管理系统4去落实该发票所有权的转移。因此，在线下报销的情况下，本公开实施例中，就在将电子发票打印出来以供报销的环节，对发票设置锁定状态。在锁定状态下，仅允许报销一次。如果是发票处于锁定状态且第二次被请求报销，这种情况下，就不允许报销所述发票。这样，就防止了重复报销。因此，大大降低了发票报销的风险。图1l示出了显示“您的发票信息已报销过，因此审核未通过”的界面。

由于本公开实施例既防止了虚假发票的报销，又防止了重复报销，如果检验出既没有虚假发票的报销，也不涉及重复报销，则允许报销，此时显示图1m所示的界面，显示“平台已经审核通过您的发票报销请求，是否需要完成发票转移”。

报销单位的财务人员在图1m所示的界面选择“是”，此时出现发票信息和报销事件发票转移信息的确认页面，如图1n。该界面中的发票信息是按照员工向报销单位终端发送的电子发票中的信息自动生成的，其基本对应于图1i所示的界面中的发票信息。该界面中的报销事件发票转移信息包括转出方信息、转入方信息、转出方电话等。转出方信息是按照发票信息中的领取人信息来生成的，转入方信息是按照发票信息中的发票抬头名称来生成的，转出方电话是按照发票信息中的领取人电话来生成的。

报销单位的财务人员核查该信息无误后，选择图1n中的“发送报销发票转移请求”按钮，向区块链发票管理系统4发送报销发票转移请求。所述报销发票转移请求包括发票信息、报销事件发票转移信息。区块链发票管理系统4将所述发票信息、报销事件发票转移信息作为报销所述发票的事件区块，记录在区块链上。这样，就实现了发票的所有权从员工到报销单位的转移，向报销单位的财务人员显示“已成功完成发票转移”的界面，如图1o所示。

图2a-2g示出了根据本公开一个实施例的发票报销中的信息处理方法应用在线下报销应用场景时所涉及的各种界面的示意图。

如果员工在如图1h所示的发票的处理选择界面选择“打印”以便进行线下报销，如果此时员工的终端显示“请连接数据线到打印机进行打印”，如图2a所示。同时，向区块链发票管理系统4发送发票线下打印请求，区块链发票管理系统4将所述发票记录为锁定状态。锁定状态的特点是，仅允许对处于锁定状态的发票报销一次，或者说，由报销单位的终端向区块链发票管理系统4发送发票报销请求一次，超过一次不予报销，从而实现了在线下报销的情况下避免重复报销的目的。

假设员工已将终端通过连接线连接到打印机，在图2a所示的界面上选择“已连接，开始打印”，这时打印机开始打印电子发票。打印出的发票上有一个二维码，其代表区块链上记录的开出所述发票的事件区块的区块主体摘要值，该摘要值相当于开出所述发票的事件区块的标识，对于该开出所述发票的事件区块是唯一的，通过它可以找到开出所述发票的事件区块。

在线下报销时，员工将打印出的电子发票拿到报销单位的财务人员处。财务人员在发票报销系统中选择“报销”，出现图2b所示的界面，显示“请用连接的扫描仪扫描需报销发票上的二维码”。这时，财务人员用扫描仪扫描二维码，识别出开出所述发票的事件区块的所述区块主体摘要值。

然后，在图2c的界面中，报销单位的财务人员填写发票信息、开票事件发票转移信息。发票信息是根据打印出的发票上的信息填写的，开票事件发票转移信息的转出人信息是根据打印出的发票中的开票人信息填写的，转入方信息是根据打印出的发票中的领取人信息填写的，转入方电话是根据打印出的发票中的领取人电话填写的。财务人员然后选择界面上的“发送发票报销请求”，向区块链发票管理系统4发送发票报销请求，所述发票报销请求包含扫描二维码得到的区块主体摘要值、在图2c的界面上填写的发票信息、开票事件发票转移信息。

然后，报销单位终端显示如图2d所示的界面，显示“平台正在审核您的发票报销请求，请耐心等待”。

如果区块链发票管理系统4发现发票报销请求中的发票信息、开票事件发票转移信息与在区块链中存储的该发票的开票时产生的事件区块中的发票信息、开票事件发票转移信息不一致，则该发票是篡改的或虚假的发票。此时，显示如图2e所示的界面，显示“您的发票信息与备案的发票信息不符，因此有篡改行为，审核未通过”。

如果发票报销请求中的发票信息、开票事件发票转移信息与在区块链中存储的该发票的开票时产生的事件区块中的发票信息、开票事件发票转移信息一致，则该发票不是篡改的或虚假的发票。在本公开的一个实施例中，还要验证该发票是否是重复报销的发票。验证是否重复报销的方法可以包括判断发票当前的所有者是否是该员工(发票的领取人)，并判断该发票是否是处于未锁定状态或者虽处于锁定状态但是第一次请求报销。如果发票当前的所有者是该员工，并且该发票处于未锁定状态或者虽处于锁定状态但是第一次请求报销，则不是重复报销。如果发票当前的所有者不是该员工，或者该发票处于锁定状态且不是第一次请求报销，则是重复报销，显示“您的发票信息已报销过，因此审核未通过”的界面，如图2f所示。

如果检验出既没有虚假发票的报销，也不涉及重复报销，则允许报销，此时显示图2g所示的界面，显示“平台已经审核通过您的发票报销请求”。

如图4所示，根据本公开的一个实施例，提供了一种发票报销中的信息处理方法。该方法是由区块链网关服务器(例如图3a中的区块链网关服务器401)执行的。该方法包括：

步骤410、接收发票报销请求，所述发票报销请求包含区块链上记录的开出所述发票的事件区块的标识、发票信息、开票事件发票转移信息；

步骤420、按照所述开出所述发票的事件区块的标识，查找所述区块链上记录的开出所述发票的事件区块；

步骤430、在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，发送允许所述发票报销的应答。

下面分别对这些步骤进行详细描述。

在步骤410中，接收发票报销请求，所述发票报销请求包含区块链上记录的开出所述发票的事件区块的标识、发票信息、开票事件发票转移信息。

发票报销请求是发票报销单位终端101向区块链网关服务器401发送的用于验证该发票是否能报销的请求。

在发票线上报销的应用场景中，发票报销请求是响应于报销单位的财务人员在图1i的界面上选择“发送发票报销请求”而发送的。

事件区块的标识是区分事件区块的唯一的符号，不同的事件区块的标识不同。

在一个实施例中，事件区块的标识是对事件区块的区块主体进行摘要运算而得到的摘要值。开出所述发票的事件区块的标识就是对开出所述发票的事件区块的区块主体进行摘要运算而得到的摘要值。由于不同的字符串经摘要运算后得到的摘要值不同，因此该摘要值能够作为事件区块的标识。

在另一个实施例中，事件区块的标识是对事件区块进行摘要运算而得到的摘要值，即对包括区块头和区块主体的整个事件区块进行摘要运算而得到的摘要值。开出所述发票的事件区块的标识就是对开出所述发票的事件区块(包括区块主体和区块头)进行摘要运算而得到的摘要值。

在另一个实施例中，事件区块的标识是事件区块在区块链上的高度。开出所述发票的事件区块的标识是开出所述发票的事件区块在区块链上的高度。可以理解的是，事件区块的标识还可以通过其他方式获得，本发明实施例对此并不限定。

发票信息是图1i中的发票信息，开票事件发票转移信息是如图1i中的开票事件发票转移信息。发票信息是从员工终端102转发到发票报销单位终端101的电子发票中读出，并由发票报销单位的财务人员核实的。开票终端201将电子发票放置在员工终端102的卡包中，该电子发票中含有发票信息。如果员工没有篡改而是直接转发到发票报销单位终端101，从该电子发票中就可以直接读出发票信息。开票事件发票转移信息则是报销单位终端的发票报销系统自动生成的。它包括转出方信息、转入方信息、转入方电话等，其中转出方信息是按照发票信息中的开票人信息生成的，与该开票人信息一致；转入方信息是按照发票信息中的领取人信息生成的，与领取人信息一致；转入方电话是按照发票信息中的领取人电话生成的。开出所述发票的事件区块的区块主体摘要值是在开票终端201开票给报销单位的员工时利用摘要算法(例如哈希算法等)生成的，它是事件区块区别于其它事件区块的、代表该事件区块的标识。该区块主体摘要值可以直接印在电子发票上，这样，报销单位终端101就可以直接读出该区块主体摘要值放在发票报销请求中。该区块主体摘要值也可以转化成二维码印在电子发票上。这样，将电子发票传送到报销单位终端101中，报销单位终端101自动识别电子发票上的二维码，将二维码代表的区块主体摘要值放置在发票报销请求中发送给区块链网关服务器401。

在发票线下报销的应用场景中，发票报销请求是响应于报销单位的财务人员在图2c的界面上选择“发送发票报销请求”而发送的。发票信息和开票事件发票转移信息是图2c中财务人员根据打印出来的发票信息填写的信息。开票事件发票转移信息包括转出方信息、转入方信息、转入方电话等，其中转出方信息是按照打印出的发票中的开票人信息生成的，与该开票人信息一致；转入方信息是按照打印出的发票中的领取人信息生成的，与领取人信息一致；转入方电话是按照打印出的发票中的领取人电话生成的。开出所述发票的事件区块的区块主体摘要值是在开票终端201开票给报销单位的员工时利用摘要算法(例如哈希算法等)生成的，它是事件区块区别于其它事件区块的、代表该事件区块的标识。该区块主体摘要值也转化成二维码印在电子发票上。这样，当员工打印该电子发票后，该二维码就印在打印出的发票上。如图2b所示，报销单位的财务人员用扫描仪扫描打印发票上的二维码之后，报销单位终端101自动识别电子发票上的二维码，将二维码代表的区块主体摘要值放置在发票报销请求中发送给区块链网关服务器401。

在步骤420中，按照所述开出所述发票的事件区块的标识，查找所述区块链上记录的开出所述发票的事件区块。

如上所述，开出所述发票的事件区块的标识是该开出发票的事件区块区别于其它事件区块的符号，因此，区块链网关服务器401根据该标识就可以找到区块链上记录的开出所述发票的事件区块。

具体地，当所述开出所述发票的事件区块的标识是开出所述发票的事件区块的区块主体摘要值时，所述开出所述发票的事件区块的区块主体摘要值是对包含发票信息和开票事件发票转移信息的区块主体进行摘要运算生成的。该摘要运算的一个例子是哈希运算。在开出所述发票的环节，在区块链上增加一个开出发票的事件区块。该事件区块包括区块头和区块主体。将所述发票信息、开票事件发票转移信息，作为所述开出所述发票的事件区块的区块主体的至少一部分记录到区块链上。该区块主体还可以包括其它部分，例如报销终端签名信息、产生该区块时的备注信息等。在一个实施例中，计算出的所述开出所述发票的事件区块的区块主体的摘要值以及与所述区块链上未记录所述开出所述发票的事件区块之前的最后一个区块的摘要值，作为所述开出所述发票的事件区块的区块头的至少一部分。所述区块头还可以包括其它部分，例如奇偶校验码等。在另一个实施例中，计算出的所述开出所述发票的事件区块的区块主体的摘要值以及与所述区块链上未记录所述开出所述发票的事件区块之前的最后一个区块的区块主体的摘要值，作为所述开出所述发票的事件区块的区块头的至少一部分。在另一个实施例中，计算出的所述开出所述发票的事件区块的摘要值以及与所述区块链上未记录所述开出所述发票的事件区块之前的最后一个区块的摘要值，作为所述开出所述发票的事件区块的区块头的至少一部分。在另一个实施例中，计算出的所述开出所述发票的事件区块的摘要值以及与所述区块链上未记录所述开出所述发票的事件区块之前的最后一个区块的区块主体的摘要值，作为所述开出所述发票的事件区块的区块头的至少一部分。

由于区块链上的所有发票的事件按时序记录，且一个区块链上可能记录多个发票的事件，因此，在区块链上未记录所述开出所述发票的事件区块之前的最后一个区块不一定是当前发票的，可能是其它发票的。例如，区块链已经记录有6个区块，按照时序分别是：

1)发票1的发行；

2)发票2的发行；

3)发票1的开票：

4)发票3的发行；

5)发票1的报销；

6)发票2的开票。

当前发票是发票3。将发票3开票时，需要在区块链上增加一个区块，即发票3的开票事件的区块，作为第7个区块，而在区块链上未记录第7个区块之前的最后一个区块是第6个区块，是关于第2发票的。正因为不管区块链上未记录所述开出所述发票的事件区块之前的最后一个区块是不是关于当前发票的，在一个实施例中，都将其摘要值(或其区块主体的摘要值)与当前区块的区块主体的摘要值(或当前区块的摘要值)记录在一起作为当前区块的区块头的至少一部分，因此，区块链上的每一区块都含有区块链中的上一个区块的信息，其本身信息也被区块链上的下一个区块所记录，区块之间形成紧密的印证关系，因此，区块链记录的区块很难被篡改，大大提高了发票信息在区块链上存储和验证的安全性。按照所述开出所述发票的事件区块的区块主体摘要值，就可以查找到所述区块链上记录的开出所述发票的事件区块。

在步骤430中，在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，发送允许所述发票报销的应答。

如果查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致,就说明员工在线上报销的情形下没有线上篡改开票时的发票信息，在线下报销的情形下打印出电子发票后没有人工涂改该打印的发票，否则会造成查找到的事件区块中的信息与所述发票报销请求中的信息不一致。在二者一致的情况下，向报销单位终端101发出允许发票报销的应答。这样，就检验出了发票篡改的情况，避免了发票篡改后报销的情况。

如图5所示，根据本公开的一个实施例，所述方法在步骤430之后，还包括：

步骤440、接收报销发票转移请求，所述报销发票转移请求包括发票信息、报销事件发票转移信息；

步骤450、将所述发票信息、报销事件发票转移信息记录在区块链上的报销所述发票的事件区块中。

所述报销所述发票的事件区块具有对包括所述发票信息、报销事件发票转移信息的区块主体进行摘要运算得到的报销所述发票的事件区块的区块主体的摘要值。

下面对步骤440-450详细描述。

在步骤440中，接收报销发票转移请求，所述报销发票转移请求包括发票信息、报销事件发票转移信息。

报销单位终端101在得到是否允许发票报销的应答后，还要将发票报销事件如图3b所示及时上链。如果不上链，发票流转后续环节就无法得知该发票流转环节中的全部信息，在后续环节需要验证时由于信息缺失会导致错误的结论。因此，报销单位终端101需要向区块链网关服务器401发出报销发票转移请求。

在线上报销的情况下，该报销发票转移请求是响应于财务人员在图1m的界面上选择“是”进行的。在线下报销的情况下，由于报销单位没有上线，它不会也不关心将报销事件向区块链记录。它为了验证发票是否被篡改或是否重复报销，可能会利用本公开实施例的方法向区块链网关服务器401查询是否允许报销，但不会向区块链记录报销事件。

所述报销发票转移请求包括发票信息、报销事件发票转移信息。如图1n所示，该发票信息是按照员工向报销单位终端发送的电子发票中的信息自动生成的。该界面中的报销事件发票转移信息包括转出方信息、转入方信息、转出方电话等。转出方信息是按照发票信息中的领取人信息来生成的，转入方信息是按照发票信息中的发票抬头名称来生成的，转出方电话是按照发票信息中的领取人电话来生成的。发票信息、报销事件发票转移信息上链对于后续环节(例如审计环节、抵税环节、重复报销环节)的验证具有重要作用。发票信息的上链保证了后续环节能够验证后续环节涉及的发票是否是无篡改发票，而发票转移信息对于验证重复报销具有重要信息，这一点会在后续详细描述。

在步骤450中，将所述发票信息、报销事件发票转移信息记录在区块链上报销所述发票的事件区块中，所述报销所述发票的事件区块具有对包括所述发票信息、报销事件发票转移信息的区块主体进行摘要运算得到的报销所述发票的事件区块的区块主体的摘要值。

如图6所示，在一个实施例中，步骤450可以包括：

步骤4501、对包括所述发票信息、报销事件发票转移信息的区块主体进行摘要运算，生成报销所述发票的事件区块的区块主体的摘要值；

步骤4502、将所述报销所述发票的事件区块的区块主体的摘要值、与所述区块链上未记录所述报销所述发票的事件区块之前的最后一个区块的摘要值一起，作为所述报销所述发票的事件区块的区块头的至少一部分；

步骤4503、将所述发票信息、报销事件发票转移信息，作为所述报销所述发票的事件区块的区块主体的至少一部分；

步骤4504、将所述区块头和所述区块主体串联，作为报销所述发票的事件区块，以记录在区块链。

下面对这些步骤进行详细描述。

步骤4501中的摘要运算可以是哈希算法等。它可以是与以上开票环节中对发票信息、开票事件发票转移信息进行的摘要运算是同一个运算。在一个实施例中，也可以针对不同发票针对不同摘要算法，在同一个发票的发行、开票、报销等环节，设置同样的摘要算法。区块链网关服务器401可以维护一个发票标识与摘要算法对应关系表。当在4501中需要进行摘要运算时，根据发票信息中的发票标识(发票代码+发票号码)查找该对应关系表，获得摘要算法，进行摘要运算。针对不同发票针对不同摘要算法的好处是，使得摘要值难以被破解，进一步提高区块记录信息的安全性。

步骤4502中，类似于上述开票事件区块记录的情形，将所述报销所述发票的事件区块的区块主体的摘要值、与所述区块链上未记录所述报销所述发票的事件区块之前的最后一个区块的摘要值一起，记录在所述报销所述发票的事件区块的区块头中的意义在于，区块链上的每一区块都含有区块链中的上一个区块的信息，其本身的区块信息也被区块链上的下一个区块所记录，区块之间形成紧密的印证关系，因此，区块链记录的区块很难被篡改，大大提高了发票信息在区块链上存储和验证的安全性。

区块头除了记录所述报销所述发票的事件区块的区块主体的摘要值、与所述区块链上未记录所述报销所述发票的事件区块之前的最后一个区块的摘要值之外，还存储着时间戳、校验码等。时间戳记录着生成该区块的时间，在生成该区块时自动记录到区块头的时间戳字段。校验码是对包括区块头的其它部分的位(除该校验码的位)和区块主体的位利用奇偶校验算法生成的位，该位用于校验该区块是否发生了变化，如该区块发生了改动，利用奇偶校验算法对其它部分的位(除该校验码的位)和区块主体的位进行运算，得到的结果就会与该校验码不同。通过这种方式，进一步防止了该区块被篡改。

步骤4503和4504中区块主体与区块头的形成方式与上述开票事件区块记录的情形也类似，故不赘述。

上述实施例只是避免了虚拟发票报销的情况，在进一步的一个实施例中，还能够避免发票重复报销。它是通过在区块链网关服务器401判断是否允许发票报销时，不仅判断查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息是否一致，还判断目前登记的发票归属方信息与实际报销人信息是否一致进行的。

该实施例中，所述发票报销请求还可以含有报销人信息。这样，在图1i和图2c的界面上，可能多出一个填写“报销人信息”的框(图中未示)。报销单位的财务人员需要将实际请求报销的员工信息填写在“报销人信息”的框中。这样，向区块链网关服务器401发送的发票报销请求就含有报销人信息。

这样，如图7所示，步骤430可以包括：

步骤4301、在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，查询所述发票的归属方信息；

步骤4302、在查询出的归属方信息与所述报销人信息一致时，发送允许所述发票报销的应答。

在步骤4301中的查询所述发票的归属方信息可以有多种实现方式。

在一个实施例中，查询所述发票的归属方信息可以通过查询区块链中记录的该发票的事件区块中最晚一个区块的发票转入方信息实现。如上所述，在发票的发行、开票、报销等环节，都要求将事件上链，而上链时不仅要将发票信息上链，而且要将发票转移信息上链。发票信息中含有发票标识。如上所述，发票转移信息中可以含有发票转出方信息和转入方信息等。整个区块链上发票信息中具有所述发票报销请求中的发票标识的那些区块，就是该发票目前记录在区块链上的所有事件区块。在这些事件区块中找到记录时间最晚的事件区块，其中的发票转移信息中的发票转入方信息就是当前发票的归属方信息。

因此，如图8，在该实施例中，步骤4301包括：

步骤43011、确定区块链上具有所述发票报销请求中的发票标识的事件区块中记录时间最晚的一个事件区块；

步骤43012、将确定的事件区块中的发票转入方信息，作为所述发票的归属方信息。

该实施例利用区块链中记录的该发票的事件区块中最晚一个区块的发票转入方信息来查找发票的归属方信息，在无需进行额外的链外记录的情况下，实现了归属方信息的确定，有利于优化资源利用效率。

另外，在其它实施例中，也可以利用区块链外记录发票归属方的方式来实现发票归属方信息的查找。

在一个实施例中，可以采用链外的发票归属表来记录。在发票归属表中，每一张发票的发票标识与归属方信息相对应地记录。这就要求，发票发行、开票、报销事件上链的同时，也要更新该发票归属表。这时，当需要查找当前的发票归属方时，由于发票归属表已经记录与每个发票标识对应的更新的发票归属方，因此，可以从该发票归属表直接读出与发票标识对一个的归属方信息。

在该实施例中，所述方法在步骤440之后，还包括：用所述报销事件发票转移信息中的所述发票转入方信息替换在所述区块链之外设置的与发票标识对应的发票归属表中的归属方信息。

在发票报销事件发生时，所述报销事件发票转移信息中的所述发票转入方信息代表了发票最新流转到的一方，即报销单位的终端，因此，用该转入方信息代替发票归属表中与相应发票标识对应的归属方信息，就可以达到归属方信息更新的目的。

相应地，所述查询所述发票的归属方信息包括：按照所述发票标识，查询所述发票归属表，以获得所述归属方信息。这样，如果员工以同一发票重复报销时，如果前一次报销是线上进行的，即完成了发票所有权的转移，或者说，将前一报销中已经将与该发票标识对应的发票归属表中的归属方信息改成了报销单位而不是员工本身了，而在本次报销中，报销人仍是该员工，这样就会造成报销人与发票归属方不一致，因而不予报销。通过这种方式避免了前一次报销是线上进行的情况下的重复报销。至于前一次报销是线下报销的情况，如何避免重复报销，在后文中描述。

以上描述了在发票报销环节，如何在事件上链的同时更新发票归属表。在发票发行和开票的环节，也同样要求在事件上链的同时更新发票归属表。

在开票的环节事件上链的同时更新发票归属表的过程如图9所示。在步骤410之前，所述方法包括：

步骤404、接收开出发票请求，所述开出发票请求包含区块链上记录的发行所述发票的事件区块的标识、发票信息、发行事件发票转移信息；

步骤405、按照所述发行所述发票的事件区块的标识，查找所述区块链上记录的发行所述发票的事件区块；

步骤406、在查找到的事件区块中的发票信息、发行事件发票转移信息分别与所述开出发票请求中的发票信息、以及发行事件发票转移信息一致时，发送允许开票的应答；

步骤407、接收开出发票转移请求，所述开出发票转移请求包括发票信息、开票事件发票转移信息，所述开票事件发票转移信息包括发票转入方信息；

步骤408、将所述发票信息、开票事件发票转移信息作为开出所述发票的事件区块的区块主体的至少一部分记录在区块链上，所述开出所述发票的事件区块具有开出所述发票的事件区块的区块主体摘要值，作为开出所述发票的事件区块的标识，所述开出所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、开票事件发票转移信息的区块主体进行摘要运算得到；

步骤409、用所述开票事件发票转移信息中的发票转入方信息替换与发票标识对应的发票归属表中的归属方信息。

下面对这些步骤进行详细描述。

在步骤404中接收开出发票请求是响应于开票单位的员工在开票终端201的如图1b所示的界面上选择“确认”按钮而实现的。由于在发行发票时，工商机关一次性发放发票号码连续的多张发票给开票单位。在开票终端201上一般是按照这多张发票的顺序由小到大依次开出，即将这连续的多张发票中目前还未开出的发票号码最小的一张发票的发票号码显示在图1b的界面上。图1b左侧的内容是发票开具系统根据发票开具系统中固有的信息自动生成的，右侧的内容是开发票的员工在开发票时根据实际需要填写的。当选择“确认”按钮后，图1b的内容就会作为发票信息发送到区块链网关服务器401。

在一个实施例中，发行所述发票的事件区块的标识就是对发行所述发票的事件区块的区块主体进行摘要运算而得到的摘要值。

在另一个实施例中，发行所述发票的事件区块的标识就是对发行所述发票的事件区块(包括区块主体和区块头)进行摘要运算而得到的摘要值。

在另一个实施例中，发行所述发票的事件区块的标识是发行所述发票的事件区块在区块链上的高度。

发行事件发票转移信息包括发票转出方信息、发票转入方信息等，其中发票转出方信息是根据工商机关的名称生成的，与工商机关的名称一致；发票转入方信息是根据领取人(开票人)生成的，与领取人(开票人)一致。发行所述发票的事件区块的区块主体摘要值如上所述，是对包括发票信息、发行事件发票转移信息的区块主体进行摘要运算而生成的。

在步骤405中，由于区块主体摘要值能唯一识别出发行所述发票的事件区块，因此，根据该区块主体摘要值，就可以找到所述区块链上记录的发行所述发票的事件区块。

在步骤406中，在查找到的事件区块中的发票信息、发行事件发票转移信息分别与所述开出发票请求中的发票信息、以及发行事件发票转移信息一致时，发送允许开票的应答。

如果查找到的事件区块中的发票信息、发行事件发票转移信息分别与所述开出发票请求中的发票信息、以及发行事件发票转移信息一致，说明开票单位没有伪造变造发票的行为，该发票是合法的，允许开出。

在步骤407中，接收开出发票转移请求，所述开出发票转移请求包括发票信息、开票事件发票转移信息，所述开票事件发票转移信息包括发票转入方信息。

发票转移请求是将开出发票的事件上链记录的请求。在步骤404中发出的开出发票请求仅仅是请求对发票是否有问题进行验证，没有问题则允许开出。但其没有在区块链上记录这一发票转移过程。如果不记录这一过程，后续的报销、审计等环节则会缺少比对、核对的基础，不利于后续环节的进行。因此，开票终端201会向区块链网关服务器401发出发票转移请求，将发票信息和开票事件发票转移信息记录在区块链上一个区块上。发票信息可以按照图1b所示的界面上的信息生成。开票事件发票转移信息包括发票转出方信息、转入方信息、转入方电话等。发票转出方信息是由开票终端201的发票开具系统根据图1b所示的开票人自动生成的。发票转入方信息是由开票终端201的发票开具系统根据图1b所示的领取人自动生成的。转入方电话是由开票终端201的发票开具系统根据图1b所示的领取人电话自动生成的。

在步骤408中，将所述发票信息、开票事件发票转移信息作为开出所述发票的事件区块的区块主体的至少一部分，记录在区块链上，所述开出所述发票的事件区块具有开出所述发票的事件区块的区块主体的摘要值，作为开出所述发票的事件区块的标识，所述开出所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、开票事件发票转移信息的区块主体进行摘要运算得到。

在一个实施例中，可以将包括所述发票信息、开票事件发票转移信息的区块主体进行摘要运算，得到区块主体摘要值。然后，在区块链上新生成一个区块。将该得到的区块主体摘要值与区块链上前一个区块的摘要值作为新区块的区块头的至少一部分。将所述发票信息、开票事件发票转移信息作为新区块的区块主体的至少一部分。

在步骤409中，用所述开票事件发票转移信息中的发票转入方信息替换与发票标识对应的发票归属表中的归属方信息。

发票归属表中记录着发票标识和发票最新的归属方信息。在开票之前，该发票归属表中记录的相应发票标识的归属方信息是开票单位，但在开票之后，发票的归属方发生了变化，其变成发票领取人，即开票事件发票转移信息中的发票转入方信息。因此，开票后，除了开票事件需要上链外，还需要用所述开票事件发票转移信息中的发票转入方信息替换与发票标识对应的发票归属表中的归属方信息，完成发票归属方更新。这样，为后续的验证环节中需要核对发票的归属方时提供了方便。

在发行发票的环节事件上链的同时更新发票归属表的过程如图9所示。在步骤404之前，所述方法包括：

步骤401、接收发行发票请求，所述发行发票请求包含发票信息、发行事件发票转移信息；

步骤402、将所述发票信息、发行事件发票转移信息作为发行所述发票的事件区块的区块主体的至少一部分，记录在区块链中，其中，发行所述发票的事件区块具有发行所述发票的事件区块的区块主体的摘要值，作为发行所述发票的事件区块的标识，所述发行所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、发行事件发票转移信息的区块主体进行摘要运算得到；

步骤403、将所述发行事件发票转移信息中的发票转入方信息写入与发票标识对应的发票归属表中作为归属方信息。

下面对步骤401-403进行详细描述。

在步骤401中接收发行发票请求是响应于工商机关的工作人员在图1a所示的发票发行系统的界面选择“确认”按钮而进行的。发行发票请求中含有的发票信息如图1a的界面所示的信息。发行事件发票转移信息包括发票转出方信息、发票转入方信息等。发票转出方信息是开票终端301的发票发行系统自动根据图1a中的发行机关信息生成的。发票转入方信息是开票终端301的发票发行系统自动根据图1a中的申领发票单位信息生成的。

在步骤402中，在一个实施例中，可以将包括所述发票信息、发行事件发票转移信息的区块主体进行摘要运算，得到区块主体摘要值。然后，在区块链上生成一个区块，该区块是该发票在区块链上记录的第一个区块。在一个实施例中，将该得到的区块主体摘要值与区块链上前一个区块的区块主体的摘要值一起放在该区块的区块头中。在另一个实施例中，也可以将该得到的区块主体摘要值与区块链上前一个区块(包括区块主体和区块头)的摘要值一起放在该区块的区块头中。将所述发票信息、发行事件发票转移信息放在该区块的区块主体中。

发票归属表中记录着发票标识和发票最新的归属方信息。在发票发行之前，该发票归属表中没有记录该发票标识对应的任何发票标识与归属方信息的对应关系记录。在发票发行时记录的发票发行事件区块是该发票标识的第一个在发票归属表中的记录。在发票发行之前，发票所有人是工商机关。在发票发行之后，其变成了申领发票单位，即开票单位。因此，发票发行后，除了发票发行事件需要上链便于之后的环节核对发票的真实性之外，还需要将所述发票发行事件发票转移信息中的发票转入方信息写入发票归属表中，作为与发票标识对应的归属方信息。这样，为后续的验证环节中需要核对发票的归属方时提供了方便。

在一个实施例中，除了在链外采用发票归属表外，还可以采用链外的发票转移登记表。在发票转移登记表中，同样能够获取到当前发票的归属方信息。

在该实施例中，在步骤440之后，所述方法还包括：将所述报销事件发票转移信息记录在所述区块链之外设置的与发票标识对应的发票转移登记表中。发票转移登记表记录着与发票标识对应的发生的每个事件的发票转移信息。每个发票标识对应于一个发票转移登记表。例如，与一个发票标识对应的发行、开票、报销事件发票转移信息，记录在这个发票标识对应的发票转移登记表中。发票转移信息包括发票转出方信息、转入方信息等等。当发票发行后，发票转移登记表记录着该发票标识对应的发行事件发票转移信息。当开票后，发票转移登记表不但记录着该发票标识对应的发行事件发票转移信息，还记录着该发票标识对应的开票事件发票转移信息。当报销后，发票转移登记表不但记录着该发票标识对应的发行事件发票转移信息、开票事件发票转移信息，还记录着该发票标识对应的报销事件发票转移信息。它的好处是，不仅记录一个当前时间点的静态信息，还记录着发票整个转移过程的历史。

在该实施例中，所述方法在步骤440之后，还包括：将所述报销事件发票转移信息记录在所述区块链之外设置的与发票标识对应的发票转移登记表中。在记录时，可以将所述报销事件发票转移信息与发票标识对应记录。

相应地，所述查询所述发票的归属方信息包括：按照所述发票标识，查询所述发票转移登记表，所述发票转移登记表中的每个发票转移信息具有发票转入方信息，将所述发票转移登记表最后一个发票转移信息中的发票转入方信息，作为所述归属方信息。发票转移登记表最后一个发票转移信息代表了关于该发票目前发生的最后一个事件，该事件中发票转入方信息就是目前发票的所有权归属方信息。

以上描述了在发票报销环节，如何在事件上链的同时更新发票转移登记表。在发票发行和开票的环节，也同样要求在事件上链的同时更新发票转移登记表。

在开票的环节事件上链的同时更新发票转移登记表的过程如图10所示。在步骤410之前，所述方法包括：

步骤404’、接收开出发票请求，所述开出发票请求包含区块链上记录的发行所述发票的事件区块的标识、发票信息、发行事件发票转移信息；

步骤405’、按照所述发行所述发票的事件区块的标识，查找所述区块链上记录的发行所述发票的事件区块；

步骤406’、在查找到的事件区块中的发票信息、发行事件发票转移信息分别与所述发票报销请求中的发票信息、以及发行事件发票转移信息一致时，发送允许开票的应答；

步骤407’、接收开出发票转移请求，所述开出发票转移请求包括发票信息、开票事件发票转移信息，所述开票事件发票转移信息包括发票转入方信息；

步骤408’、将所述发票信息、开票事件发票转移信息作为开出所述发票的事件区块的区块主体的至少一部分，记录在区块链上，所述开出所述发票的事件区块具有开出所述发票的事件区块的区块主体摘要值，作为开出所述发票的事件区块的标识，所述开出所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、开票事件发票转移信息的区块主体进行摘要运算得到；

步骤409’、将所述开票事件发票转移信息记录在与发票标识对应的发票转移登记表中。

步骤404’-408’分别与步骤404-408基本一致，故不赘述。在步骤409’中，将所述开票事件发票转移信息记录在与发票标识对应的发票转移登记表中。在该开票事件发生之前，该发票转移登记表中记录着与该发票标识对应的发行事件的发票信息、发行事件发票转移信息。在开票事件发生之后，将该发票转移登记表中增加记录与该发票标识对应的开票事件的发票信息、开票事件发票转移信息。这样，为后续的验证环节需要核对发票的归属方、乃至核对发票转移的全过程中的信息都提供了方便。

在发行发票的环节事件上链的同时更新发票转移登记表的过程如图10所示。在步骤404’之前，所述方法包括：

步骤401’、接收发行发票请求，所述发行发票请求包含发票信息、开票事件发票转移信息；

步骤402’、将所述发票信息、开票事件发票转移信息作为发行所述发票的事件区块的区块主体的至少一部分，记录在区块链上，其中，发行所述发票的事件区块具有发行所述发票的事件区块的区块主体摘要值，作为发行所述发票的事件区块的标识，所述发行所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、发行事件发票转移信息的区块主体进行摘要运算得到；

步骤403’、将所述发行事件发票转移信息记录在与发票标识对应的发票转移登记表中。

下面对步骤401’-403’进行详细描述。

步骤401’-402’与步骤401-402类似，故不赘述。在步骤403’中，将所述发行事件发票转移信息记录在与发票标识对应的发票转移登记表中。在发票发行之前，没有发票，也有没有相应的发票标识，因此未创建与该发票标识对应的发票转移登记表。在发票发行之后，创建与发行的各发票标识分别对应的发票转移登记表，将将所述发行事件发票转移信息记录在与发票标识对应的发票转移登记表中。如图1a所示，可能会一起发行发票代码为2873erst2、发票号码为100001-100100的100张发票，为这100张发票分别建立对应的发票转移登记表，并将包括发票转出方和转入方的发行事件发票转移信息写入该发票转移登记表。

在一个实施例中，所述报销事件发票转移信息具有发票转出方信息和发票转入方信息。如图11，在步骤450之后，所述方法还包括：

步骤460、接收报销放款请求，所述放款请求中具有请款人信息；

步骤470、如果区块链中具有所述发票标识的记录时间最晚的事件区块中含有报销事件发票转移信息，所述报销事件发票转移信息中的发票转出方信息与请款人信息一致，所述报销事件发票转移信息中的发票转入方信息与报销放款请求的发送方信息一致，则发出允许放款的应答。

该实施例中，报销放款的处理发生在报销事件上链、登记的发票所有权发生转移后，这有利于确保放款的时候发票作为一种资产已经完成了所有权的转移，即资产转移后，才进行钱财转移，提高了放款的安全性。

在报销事件上链、登记的发票所有权发生转移后，员工可以在员工终端102上操作请求放款，例如可以在卡包中的电子发票的显示界面上进行某种操作(例如触摸界面上的一个“请求放款”按钮)，向报销单位终端101请求放款。接到该员工的请求后，报销单位终端101向区块链网关服务器401发送一个报销放款请求，该请求中自动按照请求放款的员工(员工终端的所有者)，添加一个请款人信息。当区块链网关服务器401接收到该报销放款请求后，首先核实区块链上记载的带有该发票标识的最后一个区块是不是一个报销事件区块(这一点从是否含有报销事件发票转移信息就能判断出来)。如果不是报销事件区块，则说明没有完成报销中发票所有权的转移，不能进行放款。如果是报销事件区块，还要检查所述报销事件发票转移信息中的发票转出方信息是否与请款人信息(员工)一致，所述报销事件发票转移信息中的发票转入方信息是否与报销放款请求的发送方(报销单位)一致。如果都一致，才能放款。如果不一致，拒绝放款。

上述过程在图13a的交互流程图中体现得更为明显。员工需要线上报销时，将电子发票通过电子发票系统传送到报销单位终端101。报销单位终端101向区块链网关服务器401发送发票报销请求，用于让区块链网关服务器401检验发票真伪，同时确定发票是否属于重复报销。如果发票是真，且不属于重复报销，则区块链网关服务器401向报销单位终端101发送允许报销的应答。报销单位终端101向员工终端102发送报销完成的应答。报销单位终端101还向区块链网关服务器401发送报销发票转移请求。区块链网关服务器401接收到该请求后，将发票报销事件上链，且更新相关发票归属信息(例如链外的发票归属表、发票转移登记表等)。在员工终端102请求放款时，报销单位终端101向区块链网关服务器401查询发票是否已进行了所有权转移，即上链并进行归属信息更新。如是，则区块链网关服务器401向报销单位终端101发送已完成转移的应答。然后，报销单位终端101向员工终端102放款，例如通过微信转账等。

如上所述，如果员工以同一发票重复报销时，如果前一次报销是线上进行的，由于线上报销中必须进行报销事件上链，且发票所有权转移到报销单位，这样，本次的报销人与发票归属方就会不一致。通过这种方式避免了前一次报销是线上进行的情况下的重复报销。但是，如果前一次报销是线下报销，线下报销不会进行报销事件上链且发票所有权登记转移到报销单位，就无法查出是否重复报销的情况。为了在前一次报销是线下报销(将电子发票打印后在一些不具有上线条件的单位报销)的情况下，也能查出重复报销，在一个实施例中，通过这样的方式防止前一次报销是线下报销的情况下的重复报销：一旦电子发票被打印，就将电子发票记录为锁定状态，且发票一旦被记录为锁定状态后，仅允许报销一次，即对锁定后第一次接到的具有该发票标识的接收发票报销请求，发送允许所述发票报销的应答。这样，如果是电子发票打印后第二次接收到发票报销请求，则不允许报销，从而防止前一次报销是线下报销的情况下的重复报销。

如图12所示，在一个实施例中，在步骤410之前，所述方法还包括：

步骤4001、接收发票线下打印请求，所述发票线下打印请求具有发票标识；

步骤4002、将所述发票标识对应的发票记录为锁定状态，所述锁定状态仅允许对在将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求，发送允许所述发票报销的应答；

步骤4003、打印所述发票，所述发票上印有区块链上记录的具有该发票标识的开出所述发票的事件区块的标识对应的图形码。

在步骤4001中，员工在员工终端102如图2a所示，选择“已连接，开始打印”后，向区块链网关服务器401发出发票线下打印请求。由于图1h的微信卡包中存储有包含发票标识的发票信息，该微信卡包可以自动将该发票标识加到发票线下打印请求。区块链网关服务器401接收到该发票线下打印请求后，根据其中的发票标识，将对应的发票记录为锁定状态。记录锁定状态的方法在下文描述。然后，开始打印发票，打印出的发票上印有例如二维码的图形码，该图形码对应着区块链上记录的、具有该发票标识的、开出所述发票的事件区块的标识，该标识唯一识别该开出发票的事件区块。

这样，当员工将打印出的发票拿到报销单位的财务人员处进行报销时，财务人员用扫描仪扫描该图形码，就会获得所述开出所述发票的事件区块的标识。在这种情况下，步骤4302包括：在查询出的归属方信息与所述报销人信息一致时，如果确定所述发票标识对应的发票未处于锁定状态、或虽处于锁定状态但接收到的发票报销请求是将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求，则发送允许所述发票报销的应答。

也就是说，查询出的归属方信息与所述报销人信息一致只能防止前一次报销是线上报销时的重复报销。如果前一次报销是线下报销，可以通过确定是否所述发票标识对应的发票未处于锁定状态、或虽处于锁定状态但接收到的发票报销请求是将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求来防止。如果所述发票标识对应的发票未处于锁定状态，说明没有打印发票线下报销，因此是安全的。如果处于锁定状态，这时就要判断具有该发票标识的接收发票报销请求是第几次被接收。如果是第一次，仍然是安全的。如果是之后的次数，则是重复报销。通过这种方式，防止了前一次报销是线下报销的重复报销。

在一个实施例中，确定所述发票标识对应的发票未处于锁定状态通过如下方式进行：

设置与发票标识对应的锁定信息表，其中将所述发票标识对应的发票记录为锁定状态时，将所述锁定状态记录在于发票标识对应的锁定信息表中；

根据接收到的发票报销请求中的发票标识，查找与所述发票标识对应的锁定信息表；

如果锁定信息表中未记录锁定状态，则确定所述发票标识对应的发票未处于锁定状态。

在一个实施例中，针对每个发票标识设置一个对应的锁定信息表。如果该发票没有被记录为锁定状态，该锁定信息表不存储任何信息。或者，该锁定信息表仅在为发票记录了锁定状态后才生成。当为发票记录了锁定状态后，将所述锁定状态记录在于发票标识对应的锁定信息表中。例如，将锁定信息表的特定字段置1。这时，当需要确定所述发票标识对应的发票是否处于锁定状态时，只需要根据接收到的发票报销请求中的发票标识，查找与所述发票标识对应的锁定信息表，并判断锁定信息表中相应字段是否置1。如果置1说明锁定，如果未置1说明未锁定。

另外，在该实施例中，确定所述发票标识对应的发票虽处于锁定状态但接收到的发票报销请求是将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求也可以通过如下方式进行：

设置与发票标识对应的锁定信息表，其中将所述发票标识对应的发票记录为锁定状态时，将所述锁定状态记录在于发票标识对应的锁定信息表中，且响应于接收到带有该发票标识的发票报销请求，将所述发票报销请求记录在所述锁定信息表中；

根据接收到的发票报销请求中的发票标识，查找与所述发票标识对应的锁定信息表；

如果锁定信息表中记录锁定状态，且所述锁定信息表中未记录有发票报销请求，则确定所述发票标识对应的发票虽处于锁定状态，但接收到的发票报销请求是将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求。

也就是说，锁定信息表不仅记录发票是否处于锁定状态，还记录在处于锁定状态之后接收到的发票报销请求。这样，如果锁定信息表中记录锁定状态，但所述锁定信息表中未记录有发票报销请求，说明该发票标识的发票在锁定后未报销过。如报销过，该锁定信息表中会有发票报销请求。这样，就确定出这种情况不是重复报销，可以允许报销。

上述过程在图13b的交互流程图中体现得更为明显。员工需要线下报销时，将电子发票打印前，向区块链网关服务器401发送发票线下打印请求。区块链网关服务器401接收到该请求后，将发票记录为锁定状态。员工终端102打印发票。员工将打印出的发票拿到报销单位的财务人员处报销。报销单位终端101向区块链网关服务器401发送发票报销请求。区块链网关服务器401要检验发票真伪，确定该发票是否是重复报销(包括判断发票目前是否属于该员工，判断该发票是否处于锁定状态或者虽处于锁定状态但第一次请求报销)。如果发票是真，且不属于重复报销，向报销单位终端101发送允许报销的应答。报销单位终端101向员工终端102发送报销完成的应答。由于是线下报销，报销单位终端101无需而且一般也不会向区块链网关服务器401发送报销发票转移请求。

发票发行终端301、开票终端201、发票报销终端101对发票发行事件、开票事件、发票报销事件中的发票信息和发票转移信息进行上链。但是，有些情况下，由于发票发行终端301、开票终端201、发票报销终端101缺乏记录等原因，可能日后其对区块链上记录的当时它们上链的数据提出质疑，认为与其上链的数据不一致。为了提高它们对上链数据真实性的信赖，在一个实施例中，采用上链时同时传送签名的方式。

在一个实施例中，在每个终端注册时，为每个终端(包括发票发行终端301、开票终端201、发票报销终端101、员工终端102)分配独特的签名算法分别存储各自的终端中。每个终端的签名算法可以互不相同。在该实施例中，所述报销发票转移请求除了发票信息、报销事件发票转移信息之外，还包括对发票信息、报销事件发票转移信息的报销终端签名信息。报销终端签名信息是发票报销终端101用自己分配的签名算法对发票信息、报销事件发票转移信息进行电子签名而得到的。

在该实施例中，步骤450包括：将所述发票信息、报销事件发票转移信息、所述报销终端签名信息，作为报销所述发票的事件区块的区块主体的至少一部分，记录在区块链上，其中，所述报销所述发票的事件区块具有对包括所述发票信息、报销事件发票转移信息、所述报销终端签名信息的区块主体进行摘要运算得到的报销所述发票的事件区块的区块主体摘要值，作为报销所述发票的事件区块的标识。也就是说，在这种情况下，区块链上记录的报销事件区块的区块主体包括所述发票信息、报销事件发票转移信息、所述报销终端签名信息，而不是只包括前两者。该事件区块的区块头中包括的当前区块主体的区块主体摘要值，其不是仅对发票信息、报销事件发票转移信息进行摘要运算得到的，其是对包括发票信息、报销事件发票转移信息、所述报销终端签名信息三者的整个区块主体进行摘要运算得到的。

同样，在该实施例的开票环节，也需要上链开票方签名信息。在该实施例中，所述开出所述发票的事件区块的区块主体摘要值是对包括发票信息、开票事件发票转移信息、以及开票终端对发票信息、开票事件发票转移信息的开票方签名信息的整个区块主体进行摘要运算生成的。所述开出所述发票的事件区块包括：

作为在所述开出所述发票的事件区块的区块头的至少一部分的所述开出所述发票的事件区块的区块主体摘要值以及与所述区块链上未记录所述开出所述发票的事件区块之前的最后一个区块的摘要值，所述开出所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、开票事件发票转移信息、所述开票方签名信息的区块主体进行摘要运算得到；

作为所述开出所述发票的事件区块的区块主体的至少一部分的所述发票信息、开票事件发票转移信息、所述开票方签名信息。

也就是说，该实施例的开票事件区块的区块主体不但包括所述发票信息、开票事件发票转移信息，还包括所述开票方签名信息，区块头包括不仅对发票信息、开票事件发票转移信息，而且还对开票方签名信息进行摘要运算得到的区块主体摘要值。开票方签名信息是由开票终端对发票信息、开票事件发票转移信息利用特定于开票终端的签名算法进行签名得到的。

同样，在该实施例的发票发行环节，也需要上链发行方签名信息。在该实施例中，发行所述发票的事件区块的区块主体摘要值是对包括发票信息、发票发行事件发票转移信息、以及发行终端对发票信息、发票发行事件发票转移信息的发行方签名信息的区块主体进行摘要运算生成的。所述发行所述发票的事件区块包括：

作为所述发行所述发票的事件区块的区块头的至少一部分的所述发行所述发票的事件区块的区块主体摘要值以及与所述区块链上未记录所述发行所述发票的事件区块之前的最后一个区块的摘要值，所述发行所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、发票发行事件发票转移信息、所述发行终端签名信息的区块主体进行摘要运算得到，其中，所述发行终端签名信息是发行终端利用特定于发行终端的签名算法对所述发票信息、发票发行事件发票转移信息进行电子签名而得到的；

作为所述开出所述发票的事件区块的区块主体的至少一部分的所述发票信息、开票事件发票转移信息、所述开票方签名信息。

通过以上在区块链的区块的区块主体中增加签名信息，区块头中的区块主体摘要值也根据包括发票信息、发票转移信息、签名信息的整个区块主体来生成，提高了区块链中的发票相关记录信息的不可抵赖性。

根据本公开的一个实施例，如图14所示，还提供了一种发票报销中的信息处理装置，包括：

第一接收单元510，用于接收发票报销请求，所述发票报销请求包含区块链上记录的开出所述发票的事件区块的标识、发票信息、开票事件发票转移信息；

第一查找单元520，用于按照所述开出所述发票的事件区块的标识，查找所述区块链上记录的开出所述发票的事件区块；

第一发送单元530，用于在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，发送允许所述发票报销的应答。

在一个实施例中，所述装置还包括：

第二接收单元(未示)，用于接收报销发票转移请求，所述报销发票转移请求包括发票信息、报销事件发票转移信息；

第一记录单元(未示)，用于将所述发票信息、报销事件发票转移信息作为报销所述发票的事件区块的至少一部分，记录在区块链上，所述报销所述发票的事件区块具有对包括所述发票信息、报销事件发票转移信息的摘要主体进行摘要运算得到的报销所述发票的事件区块的区块主体摘要值。

在一个实施例中，第一记录单元进一步用于：

对包括所述发票信息、报销事件发票转移信息的区块主体进行摘要运算，生成报销所述发票的事件区块的区块主体摘要值；

将所述报销所述发票的事件区块的区块主体摘要值、与所述区块链上未记录所述报销所述发票的事件区块之前的最后一个区块的摘要值一起，作为所述报销所述发票的事件区块的区块头的至少一部分；

将所述发票信息、报销事件发票转移信息，作为所述报销所述发票的事件区块的区块主体的至少一部分；

将所述区块头和所述区块主体串联，作为报销所述发票的事件区块，以记录在区块链。

在一个实施例中，所述开出所述发票的事件区块的区块主体摘要值是对包括发票信息、开票事件发票转移信息的区块主体进行摘要运算生成的。所述开出所述发票的事件区块包括：

作为所述开出所述发票的事件区块的区块头的至少一部分的所述开出所述发票的事件区块的区块主体摘要值以及与所述区块链上未记录所述开出所述发票的事件区块之前的最后一个区块的摘要值；

作为所述开出所述发票的事件区块的区块主体的的至少一部分的所述发票信息、开票事件发票转移信息。

在一个实施例中，所述发票报销请求还含有报销人信息。第一发送单元530进一步用于：

在查找到的事件区块中的发票信息、开票事件发票转移信息分别与所述发票报销请求中的发票信息、以及开票事件发票转移信息一致时，查询所述发票的归属方信息；

在查询出的归属方信息与所述报销人信息一致时，发送允许所述发票报销的应答。

在一个实施例中，所述发票信息包括发票标识，所述报销事件发票转移信息包括发票转入方信息。所述查询所述发票的归属方信息包括：

确定区块链上具有所述发票报销请求中的发票标识的事件区块中记录时间最晚的一个事件区块；

将确定的事件区块中的发票转入方信息，作为所述发票的归属方信息。

在一个实施例中，所述发票信息包括发票标识，所述报销事件发票转移信息包括发票转入方信息。所述装置还包括：第一替换单元(未示)，用于用所述报销事件发票转移信息中的所述发票转入方信息替换在所述区块链之外设置的与发票标识对应的发票归属表中的归属方信息。所述查询所述发票的归属方信息包括：按照所述发票标识，查询所述发票归属表，以获得所述归属方信息。

在一个实施例中，所述装置还包括：

第三接收单元(未示)，用于接收开出发票请求，所述开出发票请求包含区块链上记录的发行所述发票的事件区块的标识、发票信息、发行事件发票转移信息；

第二查找单元(未示)，用于按照所述发行所述发票的事件区块的标识，查找所述区块链上记录的发行所述发票的事件区块；

第二发送单元(未示)，用于在查找到的事件区块中的发票信息、发行事件发票转移信息分别与所述发票报销请求中的发票信息、以及发行事件发票转移信息一致时，发送允许开票的应答；

第四接收单元(未示)，用于接收开出发票转移请求，所述开出发票转移请求包括发票信息、开票事件发票转移信息，所述开票事件发票转移信息包括发票转入方信息；

第二记录单元(未示)，用于将所述发票信息、开票事件发票转移信息作为开出所述发票的事件区块，记录在区块链上，所述开出所述发票的事件区块具有开出所述发票的事件区块的区块主体摘要值，作为开出所述发票的事件区块的标识，所述开出所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、开票事件发票转移信息的区块主体进行摘要运算得到；

第二替换单元(未示)，用于用所述开票事件发票转移信息中的发票转入方信息替换与发票标识对应的发票归属表中的归属方信息。

在一个实施例中，所述装置还包括：

第五接收单元(未示)，用于接收发行发票请求，所述发行发票请求包含发票信息、发行事件发票转移信息；

第三记录单元(未示)，用于将所述发票信息、发行事件发票转移信息作为发行所述发票的事件区块的区块主体的至少一部分，记录在区块链上，其中，发行所述发票的事件区块具有发行所述发票的事件区块的区块主体摘要值，作为发行所述发票的事件区块的标识，所述发行所述发票的事件区块的区块主体摘要值通过对包括所述发票信息、发行事件发票转移信息的区块主体进行摘要运算得到；

写入单元(未示)，用于将所述发行事件发票转移信息中的发票转入方信息写入发票归属表中作为与发票标识对应的归属方信息。

在一个实施例中，所述报销事件发票转移信息具有发票转出方信息和发票转入方信息。所述装置还包括：

第六接收单元(未示)，用于接收报销放款请求，所述放款请求中具有请款人信息；

应答单元(未示)，用于如果区块链中具有所述发票标识的记录时间最晚的事件区块中含有报销事件发票转移信息，所述报销事件发票转移信息中的发票转出方信息与请款人信息一致，所述报销事件发票转移信息中的发票转入方信息与报销放款请求的发送方信息一致，则发出允许放款的应答。

在一个实施例中，所述装置还包括：

第七接收单元，用于接收发票线下打印请求，所述发票线下打印请求具有发票标识；

锁定状态记录单元，用于将所述发票标识对应的发票记录为锁定状态，所述锁定状态仅允许对在将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求，发送允许所述发票报销的应答；

打印单元，用于打印所述发票，所述发票上印有区块链上记录的具有该发票标识的开出所述发票的事件区块的标识对应的图形码。

接收到的发票报销请求中的开出所述发票的事件区块的标识是通过扫描该图形码获得的，接收到的发票报销请求中的发票信息包括发票标识。

所述在查询出的归属方信息与所述报销人信息一致时，发送允许所述发票报销的应答，包括：在查询出的归属方信息与所述报销人信息一致时，如果确定所述发票标识对应的发票未处于锁定状态、或虽处于锁定状态但接收到的发票报销请求是将所述发票标识对应的发票记录为锁定状态后第一次接到的具有该发票标识的接收发票报销请求，则发送允许所述发票报销的应答。

在一个实施例中，所述报销发票转移请求还包括对发票信息、报销事件发票转移信息的报销终端签名信息。

所述将所述发票信息、报销事件发票转移信息作为报销所述发票的事件区块的区块主体的至少一部分，记录在区块链上，包括：将所述发票信息、报销事件发票转移信息、所述报销终端签名信息作为报销所述发票的事件区块的至少一部分，记录在区块链上，其中，所述报销所述发票的事件区块具有对包括所述发票信息、报销事件发票转移信息、所述报销终端签名信息的区块主体进行摘要运算得到的报销所述发票的事件区块的区块主体摘要值。

根据本公开实施例的主播标签建立方法可以由图15的区块链网关服务器401实现。下面参照图15来描述根据本公开实施例的区块链网关服务器401。图15显示的区块链网关服务器401仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图15所示，区块链网关服务器401以通用计算设备的形式表现。区块链网关服务器401的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图4中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(rom)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

区块链网关服务器401也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该区块链网关服务器401交互的设备通信，和/或与使得该区块链网关服务器401能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口650进行。并且，区块链网关服务器401还可以通过网络适配器860与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与区块链网关服务器401的其它模块通信。应当明白，尽管图中未示出，可以结合区块链网关服务器401使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本公开的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。