一种票据处理的方法及相关装置与流程

本申请涉及区块链技术领域，特别是涉及一种票据处理的方法及相关装置。

背景技术：

随着区块链技术的发展，基于区块链技术研发的电子票据已成为典型落地应用。但在实际的生成经营中，费用报销业务中纸质票据仍是主流。在现有的报销流程中，则需要将纸质票据转为电子票据，对于跨部门的分摊费用、成本借调等还需要关联部分的审批，这样就需要层层流转与审批，使得报销的效率较低。同时，纸质票据的保管与查阅都需要一定的人工成本的投入，加上票据交易不够公开透明，依旧存在一票多发、重复报销、票据业务和贸易背景造假等现象时有发生，故急需一种可以解决上述技术问题的技术方案。

技术实现要素：

本申请主要解决的技术问题是提供一种票据处理的方法及相关装置，可提高报销的效率和可靠性。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种票据处理的方法，所述方法应用于包括至少一个联盟链的区块链系统，每个所述联盟链包括申请节点和审核方节点，所述审核方节点包括财务节点，所述方法包括：

所述申请节点获取报销业务信息，并基于所述报销业务信息生成报销申请；

将所述报销申请发送至与报销业务关联的所述审核方节点进行审核；

判断是否接收到所有与报销业务关联的所述审核方节点的审核通过回执；

若是，则请求所述财务节点执行所述报销申请，并生成报销记账凭证并上链保存所述报销记账凭证。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种票据处理的方法，所述方法应用于包括至少一个联盟链的区块链系统，每个所述联盟链包括一个申请节点和审核方节点，所述审核方节点包括财务节点，所述方法包括：

所述财务节点接收所述申请节点发送的报销申请；

根据智能合约对所述报销申请进行审核，以判断所述报销申请是否符合预设的报销制度，所述智能合约为根据所述报销制度预设并存储的合约；

若符合，则生成审核通过回执且发送至所述申请节点，并响应所述报销申请；或，若不符合，则生成退回报销申请回执。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种电子设备，所述设备包括耦接的存储器和处理器，其中，

所述存储器包括本地储存，且存储有计算机程序；

所述处理器用于运行所述计算机程序，以执行如上所述的方法。

为解决上述技术问题，本申请采用的又一个技术方案是：提供一种计算机可读存储介质，所述计算机可读存储介质存储有能够被处理器运行的计算机程序，所述计算机程序用于实现如上所述的一种区块链网络架构控制方法。

本申请的有益效果是：区别于现有技术的情况，本申请所提供的技术方案，由申请节点获取报销业务信息，并基于报销业务信息生成报销申请，然后申请节点将报销申请发送至与报销业务关联的审核方节点进行审核，并判断是否接收到所有与报销业务关联的审核方节点的审核通过回执；若判断得到接收到所有与报销业务关联的审核方节点的审核通过回执，则申请节点进一步请求财务节点执行报销申请，并生成报销记账凭证并上链保存报销记账凭证，本申请所提供的技术方案通过在联盟链上提起报销申请、到将报销申请发送至审核方节点，再到获取到审核方节点发送的审核通过回执，全部基于联盟链及联盟链上的各个节点执行完成报销流程，进而无需相关人员进行沟通传递纸质报销凭证和单据，可以较好地提高了报销的效率，同时在联盟链内传递报销所需的报销业务信息，也可以较好地增加报销的可靠性，避免出现一票多报等问题。

附图说明

图1为本申请一种区块链系统一实施例中的结构示意图；

图2为本申请一种联盟链的框架示意图；

图3为本申请一种区块链系统的控制方法一实施例中的流程示意图；

图4为本申请一种区块链系统的控制方法另一实施例中的流程示意图；

图5为本申请一种票据处理的方法一实施例中的流程示意图；

图6为本申请一种票据处理的方法另一实施例中的流程示意图；

图7为本申请一种票据处理的方法又一实施例中的流程示意图；

图8为本申请一种票据处理的方法再一实施例中的流程示意图；

图9为本申请一种票据处理的方法一实施例中的流程示意图；

图10为本申请一种票据处理的方法一实施例中的流程示意图；

图11为本申请一种票据处理的方法一实施例中的流程示意图；

图12为本申请一种票据处理的方法另一实施例中的流程示意图；

图13为本申请一种票据处理地方法一实施例中的流程示意图；

图14为本申请一种票据处理的方法一实施例中的流程示意图；

图15为本申请一种票据处理的方法一实施例中的流程示意图；

图16为本申请一种票据处理的方法地交互示意图；

图17为本申请一种电子设备一实施例中的结构示意图；

图18为本申请一种计算机可读存储介质一实施例结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了便于理解本申请所提供的技术方案，首先阐述本申请中所提供的方法所涉及的区块链系统，本申请所提供的方法应用于区块链系统。请参见图1，图1为本申请一种区块链系统一实施例中的结构示意图。

在当前实施例中，本申请所提供的区块链系统包括至少一个联盟链，每个联盟链包括若干节点，联盟链具备去中心化和共识机制的特点，每个联盟链所执行的功能依据联盟链具体的应用场景确定。每个联盟链包括若干节点，若干节点中包括主节点和备用节点。

主节点是用于在工作周期内进行预设信息处理的节点。其中，预设信息处理包括汇集所在联盟链的链内信息和/或进行链外信息交互。

备用节点是用于在主节点故障时或者是新的工作周期到来时承接主节点工作的节点。

进一步地，主节点和从节点是通过预设的选举规则选举得到。具体可以参见下文。

进一步地，在一些实施例中，若干节点中还包括从节点，从节点为不可以在链上与外部联盟链直接进行交互的节点。在一些特定的情形下，用于执行一些特定功能的节点可以与其他联盟链中的用于执行特定功能的从节点在链下进行交互。

其中，需要说明的是，在一些实施例中，本申请所提供的区块链系统中所包括一些联盟链中的节点具备点对点的通信功能。如，一个节点可以与另一个节点直接在区块链下进行交互。

进一步地，每个联盟链中只包括一个主节点、一个备用节点和若干从节点。其中，需要说明的是，在此对于每个联盟链中所包括的从节点的数量不做限定，具体以实际的需求进行设置。

请继续参见图1，如若图1中所示意的区块链系统100是用于企业经营过程中，则图1中所示意的联盟链a可为第一企业联盟链，联盟链b为第二企业联盟链，联盟链c为税务联盟链，联盟d为审计联盟链。其中，联盟链a中的a1为主节点，a2为备用节点，a2至a4为从节点；同理，联盟链b中的b1为主节点，b2为备用节点，b2至b5为从节点；联盟链c中的c1为主节点，c2为备用节点，c2至c5为从节点；联盟链d中的d1为主节点，d2为备用节点，d2至d4为从节点。进一步地，在一些实施例中，会在同一区块链系统中所包括的联盟链的主节点间构建主区块链，如图1所示意的，主节点a1、主节点b1、主节点c1和主节点d1共同组成了区块链系统100中的主链e。

将本申请所提供的包括多个联盟链的区块链系统应用于企业生产经营的各个端点，如开票和票据报销时，可以较好地保障各单位的大量、关联报销业务信息、业务交易信息、报销票据信息、资金流水信息既能够在所属单位内安全存储的同时，也通过跨链技术快速完成跨单位的高效交互。

其中，企业端联盟链(至少包括第一企业联盟链或第二企业联盟链)在企业内部以申请报销节点、财务节点、多个不同级别的管理节点、企业(高层)管理节点构建应用于企业的联盟链。同时通过设置敏感财税数据仅在该联盟链内部流转，提高企业信息安全管理。

税务联盟链包括主要由开票(机构)节点、税务局节点、银行节点组成，用于记录票据信息。

在其他实施例中，区块链系统还可以包括：供应链端联盟链。供应链端联盟链包括供应链上的核心企业、上游供应商等。

审计端联盟链包括合作的审计机构节点、政府监管部分节点和税负节剧节点。

在一实施例中，第一企业联盟链、第二企业联盟链、税务联盟链和审计联盟链的主节点共同构成了主链(一些实施例中，会将主链定义为综合票税服务联盟链，会将主节点定义为中继节点)。

请参见2，图2为本申请一种联盟链的框架示意图。在从架构上阐述联盟链前，首先对本申请说明书中提及的关键术语或技术缩略语进行解释：

区块链技术是随比特币等数字加密货币而兴起的一种新型的分布式数据组织方法及运算方式，联盟链是联盟区块链的简称，联盟链是指共识过程受到预选节点控制的区块链。区块链最大特点是：去中心化，这使得数据能够实现分布式集体维护，极大提高数据运算、管理、维护效率；共识，节点间基于一套共识机制，通过竞争计算共同维护整个区块链，任一节点失效，其余节点仍能正常工作。同时搭载非对称加密技术的区块链具备高安全性、可追溯性，能有效防止数据泄露或非法篡改。也可以将区块链理解为一去中心化的数据库，数据按照时间顺序存储为一系列的区块，每个区块引用前面块的哈希指针以形成一个互连的链条。其中，区块链的每个节点都保存一个完整的副本，区块链可自动同步和验证所有节点上的数据，区块链具有分布式和同步性的特点。本申请提出的一些方法是基于区块链技术的基础之上执行的，来实现对数据进行存储备用节点与主节点之间的切换，或者是基于区块链技术基础上快速完成开票流程，再或者是基于区块链技术基础上实现高效率的票据处理等，具体可详见下文相关实施例中的阐述。

为便于更好地理解本申请中的联盟区块链(下文一些实施例中简称为联盟链)，先对本申请采用的联盟区块链技术进行举例说明。请参见图2，图2为本申请一种联盟链一实施例中的架构示意图。在一具体应用中，电子设备运行该区块链技术以成为该联盟区块链的节点，或是由多个电子设备运行该区块链技术以成为该联盟区块链，该联盟区块链技术架构如图2所示，从下到上依次包括基础支撑服务层21、区块链底层技术平台层22、区块链数字票据服务层23、区块链费用报销服务层24以及企业业务应用层25。其中，需要说明的是，在一些实施例中，可以根据实际需求设计联盟链包括区块链数字票据服务层23、区块链费用报销服务层24以及企业业务应用层25中的若干个或所有。如在一实施例中，可以设计联盟链包括区块链数字票据服务层23，在另一实施例中，可以设计联盟链包括区块链数字票据服务层23和区块链费用报销服务层24。

基础支撑服务层21包括云计算iaas层，ca认证、微应用服务。基础支撑服务层21还用于结合大数据和云计算等资源，为联盟区块链提供稳定的后台基础设施，同时为其提供扩展的存储、高效的网络、按序购买弹性伸缩和故障自动恢复的节点等区块链资源。

区块链底层技术平台层22定位于企业级区块链基础平台，其相关区块链核心技术组件包括但不限于以下，如用户身份和权限管理、非对称加密、智能合约、通讯和跨链协议、隐私保护、数字签名、共识机制、及存储机制。

其中，用户身份和权限管理：支持完整的ca证书管理体体系，确保用户通过pki证书体系来保障身份认证合规性。用户通过统一身份认证服务来管理用户对联盟链上的数据资源访问权限。

非对称加密：每个企业和用户都有自己的公钥、私钥。在对信息加密过程中，用信息发送节点的公钥对信息加密，接收节点收到加密信息后用其私钥解密，这样消息即便在传输中被窃取也无法获悉其明文，从而保障数据安全。

智能合约支持java/go/node.js多语言编译，智能合约运行在隔离安全docker容器中，并被系统实时监控智能合约在运行时是否存在高危函数调用和容器逃逸行为，预防恶意智能合约对联盟区块链的威胁。

通讯和跨链协议：网络中的节点之间通过gossip协议来进行状态同步和数据分发。在一些实施例中，本申请所提供的技术方案可以是使用中继协议来完成数据交互跨链。中继是链与链之间的通道，如果通道本身是区块链，那就是中继链。在跨链中，中继充当数据收集者的角色，中继技术不依赖于可信的第三方进行交易验证，目标链可以在拿到发送链的数据后自行验证，自行验证的方式依据系统结构不同而不同。其中，目标链是指接收数据的联盟区块链。

隐私保护：支持sm2/sm3/sm4国密算法、加法同态加密、零知识证明、企业用户签名策略多样性、支持基于硬件的可信计算环境保护密钥安全性等隐私措施，从而满足数据安全传输和交易内容隐私保护等需求。

数字签名：信息发送者使用自己私钥对明文消息进行加密完成数字签名，接收者使用发送者的公钥对加密信息解密，从而验证信息来源是可靠的。

共识机制：支持solo模式、kafka/zookeeper共识、fbft、raft等共识机制，从而完成多节点对即将上链数据的一致性有效确认。

存储机制：支持将数据存储至云弹性文件服务(scalablefileservice,sfs)，其底层数据库为leveldb/couchdb。所有元数据都将写入kv(key-value，键值)数据库中，其中blockhash/txhash将作为后续查询具体数据在dat文件中的索引使用。

以上基础支撑服务层21和区块链底层技术平台层22通过sql和api的接口方式，为上层应用低成本、快速的提供高安全、高可靠、高性能的区块链基础技术服务，也可以支持hyperledegrfabric、腾讯tbaas、百度xuperchain等优秀区块链底层框架。

在一实施例中，当联盟区块链包括用于支撑报销业务的区块链电子票据服务层23时，区块链电子票据服务层23可包括开票申请、票据开具、票据红冲、票据管理、票据真伪验证、票据统计、数据监控、票据预警等功能。由业务交易方或报销经办人发起票据申请。票据开具依据开票机构使用的证书类型不同，可分为开票上链和链上开票两种。票据红冲指的是，当开具原发票有误需要更正时，使用红冲调整账目。

在另一实施例中，当联盟区块链可包括区块链费用报销服务层24时，区块链费用报销服务层24包括报销制度、报销人员身份设置、报销金额预设、规则管理、报销附件管理、报销凭证管理、报销资金预警、员工信用分析等模块。

在又一实施例中，当联盟区块链可包括企业业务应用层时，企业业务应用层可包括对接企业报销系统、财务系统、erp系统、营销系统等信息管理系统，为最终企业和用户提供可信、安全、快捷的区块链应用。

在下文相关实施例中，将拥有区块链核心组件的、能够为建设上层应用提供基础研发的软硬件环境定义为区块链应用服务平台。区块链节点运行在这个区块链应用服务平台来完成数据传输与业务处理。故在一些实施例中也可以将区块链应用服务平台理解为可让用户利用基于云的解决方案在区块链上构建，托管和使用自己的区块链应用、智能合约和功能。

哈希值是一种将任意长度的消息按照设定计算规则压缩到某一固定长度的消息摘要的函数。

请参见图3，图3为本申请一种区块链系统的控制方法一实施例中的流程示意图。

图3所对应的实施例是应用于区块链系统，区块链系统包括至少一个联盟链。如上所述联盟链包括若干节点，若干节点包括主节点和备用节点。在当前实施例中，本申请所提供的区块链系统的控制方法包括：

s31：备用节点判断所在联盟链内的主节点是否发生故障。

其中，主节点用于在工作周期内进行预设信息处理，预设信息处理包括汇集所在联盟链的链内信息和/或进行链外信息的交互。每个联盟链中包括一个主节点和一个备用节点。

在一实施例中，备用节点可以是通过判断是否接收到主节点发送的故障预警来判断主节点是否发生故障。在当前实施例中，如若主节点出现故障，主节点会向备用节点发送故障预警以触发备用节点替换主节点。其中，主节点故障至少包括：断电、断网、网络延迟等中的一种。可以理解的是，在其他实施例中，主节点故障还可以包括其他类型的故障，在此不一一列举。

在另一实施例中，当联盟链中还包括若干从节点时，备用主节点还可以是通过和联盟链中的其他节点共同判断得到主节点故障。具体地，在联盟链中，每个节点均可以与主节点进行交互，如若用于交互的主节点和从节点均是正常的，则从节点可以正常向主节点发送信息，对应的，从节点也可以正常接收到主节点发送的消息回执；反之，如若，当从节点与主节点无法进行交互，则确定双方中有一个故障。由于联盟链中包括多个从节点，如若当超过半数的从节点无法与主节点交互，但是从节点之间可以正常交互时，则可以判断得到此时主节点故障，则会将主节点故障的消息发送至备用节点。备用节点，则可以根据所接收到的主节点故障的消息的从节点数量判断得到主节点是否故障。例如，可以设置备用节点收到超过预设比例以上的从节点发送主节点故障，则备用节点则判断得到主节点故障。其中，预设比例可以根据实际需求进行设定，如，预设比例可以为50％，75％和30％。

s32：判断主节点当前的工作周期是否结束。

若备用节点判断所在联盟链内的主节点没有发生故障，则进一步判断主节点当前的工作周期是否结束。其中，工作周期为预先根据需求设定的主节点切换的周期，工作周期的时间长度是根据经验值预先设定的，在此对于工作周期的时间长度不做限定。

进一步的，由于主节点是用于汇集所在联盟链的链内信息和/或进行链外信息的交互，则主节点的工作周期设置时，可以参考汇集联盟链中所有节点所需的总时间和/或进行链外信息交互的时间长度。

s33：若判断当前的工作周期结束，则在新的工作周期内替换主节点。

若步骤s32中判断得到当前的工作周期结束，则备用节点会在新的工作周期内替换主节点。其中，替换主节点是指承担主节点所承担的进行预设信息处理的功能。如，当主节点用于汇集所在联盟链的链内信息时，备用节点在新的工作周期内会承担汇集所在联盟链的链内信息的功能；如若，当主节点用于进行链外信息的交互，则在新的工作周期内，备用节点用于承担进行链外信息的交互的功能。

需要说明的是，在当前的工作周期结束后，备用节点在新的工作周期内替换主机点后，原来的主节点则转为从节点。

进一步地，在一实施例中，主节点只用于汇集所在联盟链的链内信息和/或进行链外信息的交互，并不参与共识机制。

本申请图3所提供的方法，备用节点通过判断所在联盟链内的主节点是否发生故障，并在判断得到主节点没有发送故障，进一步判断主节点当前的工作周期是否结束，并在当前工作周期结束，则在新的工作周期内由备用节点替换主节点，通过按照设定周期切换主节点可以实现提供更为稳定的区块链系统，避免一直选用的主节点功能不佳无法为用户提供稳定的区块链系统。

进一步地，请继续参见图3，在一实施例中，如若步骤s31中判断得到联盟链内的主节点发生故障，则本申请所提供的方法还包括步骤s34。

s34：直接替换主节点，直至主节点恢复正常。

若判断得到联盟链内的主节点发生故障，则备用节点直接替换主节点，直至主节点恢复正常。

如，在一实施例中，备用节点是通过判断是否接收到主节点发送的故障预警来判断主节点是否发生故障，且经过监测得到当前周期内接收到主节点发送的故障预警，则此时备用节点判断得到主节点故障，备用节点直接替换主节点，直至发生故障的主节点恢复正常或当前工作周期结束。其中，需要说明的是，在主节点故障期间，主节点并不会从联盟链中退出的。

进一步地，在替换主节点之后，在备用节点成为新的主节点并稳定运行后，本申请所提供的方法还包括：自若干节点中选择一个节点作为新的备用节点。其中，在当前实施例中，用于选取新的备用节点的若干节点包括联盟链中所有可以正常运行的从节点。在另一实施例中，用于选取新的备用节点的若干节点包括联盟链中除去故障的主节点以外的所有可以正常运行的从节点。

在替换主节点之后，在备用节点成为新的主节点并稳定运行后，本申请所提供的方法还包括：自至少一个候选节点中选取一个候选节点作为新的备用节点。其中，候选节点是从若干节点中选择得到，候选节点的数量为至少一个，如可以为5个，也可以为3个，还可以是三个，具体在此不做限定。其中，候选节点是预先根据设定的选取规则选取的节点，专门用于候选挑选备用节点使用。

进一步地，本申请所提供的方法还包括：基于联盟链中各个节点的存储容量和/或性能评分，选取至少一个节点作为候选节点。

更进一步地，候选节点可以是按照设定的时间周期进行选取，即每间隔设定的时间周期进行选取新的候选节点，在同一个设定的时间周期内则是会保持候选节点不变。在当前实施例中，通过设定按照设定的时间周期选取新的候选节点可以一定程度上减少选取备用节点的工作量，同时可以自联盟链中选出较佳的节点成为备用节点，进而成为主节点，进而更好地提高联盟区块链系统地稳定性，且按照设定地时间周期进行选取新的候选节点可以较好地考虑联盟链中新加入的节点，可以使得新加入的且存储容量和/或性能评分较好地节点成为候选节点。

进一步地，设定的时间周期长度可以为工作周期的整数倍。在另一是市里中，也可以使得设定的时间周期恰好比工作周期时间点提前一定时长，避免在工作周期结束备用节点切换为新的主节点，候选节点尚未确定进而影响备用节点选取的情况出现。如可以设定的时间周期恰好比工作周期时间点提前半个工作周期的时间长度。

请参见图4，图4为本申请一种区块链系统的控制方法另一实施例中的流程示意图。在当前实施例中，本申请所提供的方法包括：

s41：备用节点判断所在联盟链内的主节点是否发生故障。

s42：直接替换主节点，直至主节点恢复正常。

在当前实施例中，步骤s41与上述步骤s31相同，步骤s42与图3所示意的步骤s34相同，具体可以参见上文对应部分的阐述，在此不再赘述。在当前实施例中，备用节点替换主节点之后，本申请所提供的方法还包括步骤s43至步骤s45。

s43：判断当前的工作周期是否结束。

在备用节点替换了主节点之后，该备用节点还会继续判断当前的工作周期是否结束。若判断得到当前的工作周期没有结束，则会执行下述步骤s44及步骤s45；反之，如若判断得到当前的工作周期结束，则执行下述步骤s46。

s44：判断被替换的主节点是否恢复正常。

若当前的工作周期没有结束，该备用节点(当前执行主节点功能的备用节点，也可以理解为新的主节点)进一步判断被替换掉的主节点是否恢复正常。具体可以是该备用节点向被替换掉的主节点发送信息，并判断是否可以接收到被替换掉主节点的回执消息，若可以，则判断得到被替换的主节点恢复正常，反之，若是在设定的时间间隔内没有收到回执消息，则判断得到被替换的主节点尚未恢复正常。

在另一实施例，该备用节点可以通过监测是否接收到被替换的主节点的消息，判断被替换主节点是否恢复正常。

s45：停止替换主节点。若被替换的主节点恢复正常，则备用节点停止替换主节点。

若判断得到被替换的主节点恢复正常，则该备用节点停止继续替换原主节点，以使得恢复正常的主节点在当前工作周期内继续执行预设信息处理的功能；反之，如若判断得到被替换的主节点没有恢复正常，则备用节点继续替换该故障主节点，直至主节点在当前工作周期内恢复正常或当前工作周期结束。

其中，当该备用节点停止替换主节点后，备用节点成为从节点，继续参与联盟链中的共识机制。

如若一实施例中，区块链系统包括多个联盟链，且主节点会参与主链的共识机制时，上述步骤停止替换主节点之后，本申请所提供的方法还包括：将执行预设信息处理时存储的区块信息发送至恢复正常的主节点，以使恢复正常的主节点将区块信息保存至区块中。

在当前实施例中，通过设置该备用节点停止替换主节点之后，将该备用节点执行预设信息处理时存储的区块信息发送至恢复正常的主节点，进而可以较好地使得主节点的区块与其他联盟链的区块长度保持一致，更好地参与主链的共识机制。其中，主链为多个联盟链的主节点构成的区块链。

进一步地，为了更好地参与主链的共识机制，则在一实施例中，本申请所提供的技术方案中，在备用节点与主节点之间切换时，均会将存储的最新的区块以及最新区块之前的设定个数区块中所包括的区块信息发送至下一主节点，进而使得新的主节点可以更好地参与主链耳朵共识机制。

在另一实施例中，各个联盟链的主节点不参与主链的共识机制，则在停止替换之后，不会将存储的区块信息发送至回复正常的主节点。

s46：当前备用节点停止作为主节点，并触发新的备用节点切换为新的主节点。

若步骤s43中判断得到当前的工作周期结束，则会触发新的备用节点切换为新的主节点。其中，新的备用节点为自若干节点中选取的一个节点，或者是自至少一个候选节点中选取的一个候选节点。

在一实施例中，为了在周期性切换主节点过程中可获得一个性能更为稳定的主节点，本申请所提供的技术方案中进一步引入对节点进行性能评分的步骤。具体地，在步骤s51备用节点判断所在联盟链内的主节点是否发生故障之后，本申请所提供的方法包括：若判断主节点发生故障，则记录主节点的故障，并根据主节点的故障记录更新主节点的性能评分。具体地，如若主节点发送故障，则对应在当前性能评分基础上减去预设分数，并将所得的差作为新的性能评分更新为该故障主节点的新的性能评分。如，如若某一节点发生一次故障，性能评分积分增加-5分(也可以理解为在原有的基础上减少5分，性能评分的起始分数为零，性能评分总分可以低于零)。

进一步地，如某一主节点可以正常运行一个工作周期，则本申请所提供的方法还包括：若判断主节点正常执行一个工作周期，则记录主节点的运行完好，并根据主节点的正常运行记录更新主节点的性能评分。具体地，当主节点在一个工作周期内运行完好，则会对应在当前性能评分基础上加上预设分数，并将所得的和作为新的性能评分并更新为该主节点的新的性能评分。在当前实施例中，通过增加节点的性能评分，可以实现根据性能评分快速选取到性能稳定的节点作为备用节点或主节点。

进一步地，当如若新的节点要加入当前区块链系统，则本申请所提供的方法还包括：若备用节点在替换主节点之前接收到新节点的接入请求，则备用节点向新节点反馈主节点的地址，以使新节点按照主节点的地址向主节点发送接入请求。

在另一实施例中，本申请所提供的方法还包括：若备用节点在替换主节点之后接收到新节点的接入请求，则根据接入请求核查新节点的身份，并在联盟链内广播新节点的公钥地址，以使得联盟链内的所有节点确定是否通过接入请求。

下文举例说明，新节点加入联盟链的流程如下：

在一实施例中，当有一新节点期望加入某联盟链时，其发送接入请求至该联盟链的任一节点，接收到接入请求的节点向新节点返回当前联盟链中主节点的地址。

新节点获取到主节点的地址后，会按照主节点的地址向主节点发送加入申请、自身的公钥地址及身份认证信息。联盟链的当前主节点则会进一步核查其身份后，将新节点的公钥写入联盟链的区块头部的注册表，并用自身的私钥(该联盟链当前的主节点的私钥)加密新节点的公钥地址，在联盟链中进行广播(指的是在新节点准备申请加入的业务联盟链/从链中进行广播)。联盟链上各节点用主链节点的公钥进行解密，得到新节点的公钥。新节点再用自己的私钥加密申请信息，并广播至联盟链上的所有节点。联盟链上的从链节点用得到的公钥进行解密，若解密成功则回复新节点回执信息。只有在新节点收到联盟链中所有节点的回执信息，则接入联盟链成功。

在一实施例中，主节点的切换流程如下：

以图1所示意的区块链系统为例，各个联盟链的主节点共同构成珠帘，上述各联盟链作为从链(从链除主节点外的节点全部为从节点)，构成主从多链的区块链系统。同时，各从节点可以记录各所属联盟链里企业内部数据。主节点(如图1中的企业节点、)负责该所属联盟链上的全部信息的发送与接收，从节点负责本节点产生信息的上传与读取。如：当需要做票据报销业务时，具体核验信息暂时存在主链上并在从链节点上保存，而报销兑付后的最终结果经共识其一致性后永久保存在主链节点上。主链节点为具有大容量存储、高效传输功能的电子设备(一些实施例也可以定义为服务器)，该联盟链内的其他(机构、部门、用户)节点均为从节点。其中，核验信息指的是报销审核时所必须的验证的电子单据上的业务信息。例如：原始凭证(包括行政事业型收费统一票据、车票、增值税发票等)、发票号码、报销金额、审批邮件、责任中心、支出项目/费用项目、增值税专用发票税金、税后成本费等。

本申请所设计的主从多链的区块链系统，除去可以实现对企业敏感数据进行更好隐私保护，还可以对跨企业的大量“营、业、财”数据进行多链分流处理，提升整个区块链系统对数据上链处理性能。

在一实施例中，当联盟链是应用于企业时，在选用候选节点时，根据各企业是否具有该类型的服务器以及是否有能力对服务器进行维护，确定候选节点名单，并在确定备用节点时从候选名单中挑选至少1个主节点与1个备用节点。其中，挑选的原则是，节点在以往担任主链节点期间的故障率越低，其被选为下一周期的主链概率越高。在一些实施例中，当为节点设置了评分系统的话，可以参考评分系统和系统容量确定主节点和备用节点。

当数据仅在所属联盟链内部流通上链时，链内的从节点与备用节点(注：这里备用节点仅在主节点正常运行时参与共识流程)将需要上传的数据经共识算法验证其有效性后，打包进从链区块，并将其上链存证、链内广播。

当联盟链(一些实施例中也会将联盟链定义为从链)与主链进行跨链交互时，从链将其上链的数据上传至主链节点处，该主节点负责汇集与中继其信息。主节点读取从链区块头部的信息，并将其区块体中的数据添加到主链区块中，同时更新主链区块链的区块头部分，或生成新的主链区块(前提是该区块存储容量已满，无法再添加更新信息)，并在主链中进行广播。其中，从节点将需要交互的数据打包进联盟链区块，将其上链并上传至主节点处。主节点读取联盟链区块头部的信息，并将其区块体中的数据添加到主链区块中，同时更新主链区块的区块头部分。当主节点同时收到多个待中继转发数据时，主链节点可以按照待中继转发的数据的优先级依次转发。

若该主节点在运行过程(即上述更新主链区块信息的过程)中发生故障，则由备用节点立即接任主节点工作(即更新/生成主链区块工作)并进行广播，完成信息的汇集和中继(这里备用主链节点具有继承或候补功能，目的是保障区块链系统稳定正常运行)；待新的主链节点正常运行后，立即选择备用主链节点；备用主链节点进行广播。

若该主节点未发生故障，则主链节点在正常连续运行1个工作周期后，备用节点接任主节点工作并广播(这里主节点正常运行期间，备用主链节点在功能上与其他从链节点相同)，然后选择下一周期的备用主链节点；备用主链节点进行广播。

其中，主节点和备用节点等的选择方法需在联盟链中达成共识，形成共识机制并写入联盟链的智能合约中，每当系统检测到主节点出现故障或正常连续工作1个周期后，其会自动更换主链节点并在剩余候选节点中随机选取备用节点，从而保证基于区块链系统的自主性与高效性，并提高了稳定性。

在企业生产经营或我们日常生活的过程中，常常会因为在链下发生一些业务交易产生票据，如签订采购合同、签订服务合同、签订购售电合同、日常消费等对应的业务交易，在这些业务交易的过程中，当购买方对应支付了资金之后，销售方往往需要给购买方开具发票。然而现在的开票过程往往需要多方机构链下配合，使得开票效率较低，同时也无法保证可靠性。

而为了解决现有技术中开票效率较低的问题，本申请基于上述任意一实施例中所提供的区块链系统结构，提出了一种票据处理的方法。首先，需要说明的是，本申请所提供的方法所应用的区块链系统中至少包括一个企业联盟链和税务联盟链，区块链系统的控制方法和区块链系统中联盟链之间的交互方法具体可以参见上文图1至图4及其所对应的任意一个实施例。对应的，企业联盟链和税务联盟的架构同时可以参见上文图1至图4及其所对应的任意一个实施例所阐述的联盟链架构，企业联盟链和税务联盟链各自链内节点的交互，也可以对应参见上文对应部分的阐述。

本申请所提供的一种票据处理的方法应用于销售方的第一企业联盟链，第一企业联盟链包括主节点和财务节点，主节点用于进行所在联盟链与其他联盟链间的信息交互，其他联盟链包括税务机构所在的税务联盟链。其中，第一企业联盟链代指销售方的企业联盟链，当区块链系统中同时包括购买方企业联盟链，则会如下文所述利用第二企业联盟链代指购买方的企业联盟链。

具体请参见图5，图5为本申请一种票据处理的方法一实施例中的流程示意图。在当前实施例中，以销售方所在的企业联盟链的角度进行阐述本申请所提供的技术方案，本申请所提供的方法包括：

s51：财务节点获取购买方发送的开票申请。

当购买方完成资金支付，购买方向销售方发送开票申请。其中，开票申请是用于申请开票的请求。进一步地，在一实施例中，开票申请可以是特指开具电子发票的请求。更进一步地，在另一实施例中，开票申请是指开具区块链发票的请求。

在一实施例中，当购买方可以直接与销售方的财务节点进行链下交互时，购买方则直接向销售方的财务节点发送开票申请。进一步地，上述步骤s51包括：获取购买方直接发送至财务节点的开票申请。

在另一实施例中，当购买方是与第一企业联盟链中的其他节点进行交互时，购买方可以是将开票申请发送至第一企业联盟链中的其他节点，然后第一企业联盟链中的其他节点在获取到购买方的开票申请后，则会在链内转发至财务节点。故对应的，上述步骤s51包括：获取第一企业联盟链内的业务节点转发的来自购买方的开票申请。

具体地，业务节点在接收到开票申请后，可以是直接链下发送至财务节点，也可以是通过链上转发至财务节点，使得财务节点自联盟链上获取到开票请求。其中，链下发送是指两个节点直接点对点进行交互，且交互的数据无需其他的节点共同参与。

其中，业务节点指的是与购买方进行交互的、且接收到购买方发送的开票申请的节点。如按照企业部门的职能划分企业联盟链上的节点时，则业务节点可以是销售节点、客服节点、售后服务节点等等的任意一个。需要说明的是，不同企业的部门职能划分不同，故业务节点还可以包括企业中用于承担其他职能的节点，具体可以根据企业职能划分和企业联盟链中的设定为准。

进一步地，需要说明的是，开票申请中至少包括购买方的基本信息。其中，购买方的基本信息至少包括可以用于标识购买方身份的唯一标识信息。如当购买方为个人时，购买方的基本信息包括购买方的姓名和身份证号码；当购买方为企业或单位时，购买方的基本信息包括购买方的名称和纳税人身份标识。更进一步地，开票申请中包括购买方的基本信息和需要开票的交易的基本信息，其中，需要开票的交易的基本信息至少包括订单号或是合同编号等。

s52：根据开票申请获取开票业务信息，并基于开票业务信息生成开票请求。

财务节点接收到开票申请之后，根据开票申请获取开票业务信息，并基于开票业务信息生成开票请求。其中，开票业务信息指的是开票所必须的信息，开票业务信息可以是全部自开票申请中获取，也可以是根据开票申请中所包括的购买方的基本信息和交易的基本信息，进一步对第一企业联盟链进行链上访问获得的。开票业务信息所包括的信息种类具体以税务局的开票要求为准。

开票请求是发送至税务联盟链以使得税负联盟链响应开票的请求。具体地，可以预先设定开票请求的数据格式，故在财务节点根据开票申请获取开票业务信息之后，直接将所获取的开票业务信息填入至开票请求的格式中即可生成开票请求。根据我们国税务现行的发票类型，开票请求中会设定所需开具的发票类型。其中，发票类型是由销售方企业的规模、经营向税务部分申报确定的。当销售方企业可以同时开具多种不同类型的发票时，则本申请所提供的技术方案中，会预先设定不同类型的业务所对应的发票类型，这样在财务节点接收到开票申请并获取到开票业务信息后，可快速确定当前所需开具的发票类型。如，当销售方企业可以同时对外出售检测设备和检测服务，且预先设定检测服务的出售业务对应增值税专用发票，检测设备的出售业务则对应普通发票，则在接收到购买方的开票申请后，进一步确定需要开票的业务类型，然后根据确定的需要开票业务类型确定发票类型。

s53：将开票请求发送至主节点以转发至税务联盟链。

财务节点将开票请求发送至第一企业联盟的主节点，使得第一企业联盟链的主节点转发开票请求至税务联盟链。在一实施例中，财务节点可以是直接将开票请求发送至主节点的。在另一实施例中，财务节点也可以是将开票请求上链，进而使得主节点通过上链访问获得开票请求，并将开票请求转发至税务联盟链的主节点。

第一企业联盟链的主节点收到开票请求后，将开票请求转发至税务联盟链的主节点，税务联盟链主节点再将开票请求转发至开票节点，进而使得开票节点响应开票请求开具发票。其中，第一企业联盟链和税务联盟链之间是通过各自的主节点进行交互，其中，第一企业联盟链和税务联盟链分别包括一个主节点。在一实施例中，第一企业联盟链的主节点可以是直接将开票请求直接发送至税务联盟链的主节点。在另一实施例中，第一企业联盟链的主节点可以是将开票请求在主链内进行广播，进而使得税务联盟链的主节点获得。在又一实施例中，第一企业联盟链的主节点可以是将开票请求进行上链存储至主链上，然后税务联盟链的主节点通过访问主链获得。其中，主链是区块链系统中各个联盟链的主节点共同组成，在一些实施例中，可以限定主链只进行数据传输交互和存储，不进行节点共识。

s54：获取税务联盟链响应开票请求生成的发票链信息，并将发票链信息填至票据版式模板以生成发票，并将发票反馈至购买方。

第一企业联盟链的主节点将开票请求转发至税务联盟链后，会进一步反馈成功转发回执至财务节点。税务联盟链获取到开票请求后生成发票链信息，进一步经过税务联盟链的主节点和第一企业联盟链的主节点，将发票链信息传输至财务节点。财务节点获取到税务联盟链响应开票请求生成的发票链信息后，进一步将发票链信息填至票据版式模板以生成发票。

其中，票据版式模板为开票申请中申请的业务对应的发票类型所对应的模板。如，开票申请中申请的业务对应的是普通发票，则步骤s54中则会将所接收到的发票链信息回填至普通发票对应的票据模板中。再或者，当开票申请中申请的业务对应的是增值税专用发票，则对应的s54中会将所接收到的发票链信息回填至增值税专用发票对应的票据模板中。

其中，发票链信息为发票中的关键信息，是必须由税务机关生成下发的关键信息。如，发票链信息包括“二维码内容、发票代码和号码、校验码、密文区”等信息。可以理解的是，当发票的关键信息发生改变，则对应的发票链信息对应调整，故在此对于发票链信息不做特别限定。

进一步地，在步骤s53之后和步骤s54之前，本申请所提供的方法还包括：获取开票申请中申请的业务对应的发票类型的票据版式模板。其中，票据版式模板中可以是加盖了销售方公章的模板。在其他实施例中，票据版式模板也可以是没有加盖销售方公章的模板，只有在完成发票链信息填写后方会直接在企业联盟链内加盖公章即可。

更进一步地，在步骤s54中的将发票链信息填至票据版式模板以生成发票之前，本申请所提供的方法还包括：校核当前所获取的票据模板和发票链信息对应的发票类型是否一致，若一致则执行s54中的将发票链信息填至票据版式模板以生成发票，反之，若校验得到所获取的票据模板和发票链信息对应的发票类型不一致，则会暂停生成发票，并发送异常提醒给财务人员。

进一步地，在一实施例中，在步骤将发票链信息填至票据版式模板以生成发票之后，本申请所提供的方法还包括：基于业务凭证和发票，生成业务交易凭证。其中，业务交易凭证包括发票、业务凭证和销售方的支付凭证。

生成业务交易凭证后，财务节点将生成的业务交易凭证存储至第一企业联盟链上。在当前实施例中，通过将业务交易凭证存储至第一企业联盟链上(即上链)，可以较好地实现供后续需要调用业务交易凭证时，只需要通过访问第一企业联盟链即可快速获取，同时通过上链实现资源共享和管理，减少了人工管理成本的投入。

进一步地，当购买方的企业也部署有企业联盟链，即可以理解为区块链系统中的其他联盟链包括购买方所在的第二企业联盟链时，步骤将发票反馈至购买方进一步包括：将发票发送至主节点以转发至第二企业联盟链。即财务节点将发票链信息填至票据版式模板后，并加盖自身的发票专用公章后，将生成的发票上链发送至主节点。主节点接收到发票后，会进一步将所获得的发票计算求取哈希值，然后将发票的哈希值上链存储至主链上，第二企业联盟链的主节点通过对主链访问即可获取到该发票哈希值，进而基于哈希值即可获取到该发票。可以理解的是，在其他的实施例中，第一企业联盟链的主节点也可以是直接将发票发送至第二企业联盟链的主节点处，进而使得购买方获取到发票。

可以理解的是，在其他实施例中，财务节点生成发票之后，也可以是通过链下直接反馈至购买方。

图5所提供的技术方案，基于本申请所提供的区块链系统和区块链系统中所包括的联盟链，第一企业联盟链中的财务节点通过获取购买方发送的开票申请，根据开票申请获取开票所需要的开票业务信息，并基于开票业务信息生成开票请求，然后将开票请求发送至第一企业联盟链中的主节点，以使得第一企业联盟链中的主节点将开票请求转发至税务联盟链，从而使得税务联盟链响应开票请求生成的发票链信息，财务节点经过主节点中继转发获取到税务联盟链响应开票请求生成的发票链信息；财务节点获取税务联盟链生成的发票链信息之后，财务节点进一步将发票链信息填至票据版式模板以生成发票，并将发票反馈至购买方完成开票，在本申请所提供的技术方案中，利用企业联盟链和税务联盟链，完全实现从购买方至税务方的链上开票，提高了开票的效率，且开票请求和开票所需的开票业务信息均采用链上传输，可较好地保证数据的安全传输，进而提高了链上开票的可靠性。

请参见图6，图6为本申请一种票据处理的方法另一实施例中的流程示意图。具体地，在当前实施例中，着重展示的是上述步骤s52根据开票申请获取开票业务信息，并基于开票业务信息生成开票请求所包括的步骤。在当前实施例中，上述步骤s52进一步包括步骤s61至步骤s63。

s61：解析开票申请，以获得购买方的基本信息和开票申请对应的业务凭证。

其中，开票申请中包括至少一种可标识购买方身份的基本信息。

在一实施例中，在获取到购买方发送的开票申请后，进一步解析开票申请，以获得可标识购买方身份的基本信息，然后再基于可标识购买方身份的基本信息在第一企业联盟链上获取开票所需的购买方的其他基本信息和/或开票申请对应的业务凭证。如，财务节点解析开票申请后，只获得购买方企业的名称和纳税人身份标识，财务节点进一步基于购买方企业的名称和/或纳税人身份标识进一步获取购买方企业的地址、开户行账号、需要开票的事项说明等基本信息，财务节点同时还会基于购买方企业的名称和纳税人身份标识确定需要进行开票的业务和需要开票的业务对应的业务凭证。

在另一实施例中，解析开票申请获得开票所需的购买方的全部基本信息，然后基于所获取的购买方的基本信息中可标识其身份的信息，在第一企业联盟链上获取开票申请对应的业务凭证。

在又一实施例中，当开票申请中包括开票所需的购买方的全部基本信息和开票申请对应的业务凭证时，则步骤s61为包括解析开票申请直接获得开票所需的购买方的全部基本信息和开票申请对应的业务凭证。

其中，开票申请对应的业务凭证为购买方和销售方进行业务交易时的凭证，业务凭证可以是购买方添加至开票申请中，财务节点直接自开票申请中获得；业务凭证也可以是财务节点根据开票申请中所包括的购买方的基本信息在第一企业联盟链上获取得到。

其中，业务凭证包括交易合同和交易单据中的至少一种，可以理解的是，在其他实施例中，业务凭证还可以包括其他类型的凭证，在此不一一列举。此外，在此对于业务凭证种类的数量也不做任何限定，以开票申请所需的数量为准，如，当企业设定签订合同的是销售方和购买方各一份，开票时必须基于双方所持合同复印件、以及合同对应的订单复印件方可进行开票时，则业务凭证包括三种。

交易合同包括双方签订的销售合同、采购合同任意一种，交易单据包括采购订单、购买订单等中任意一种。

s62：根据业务凭证确定开票业务信息。

获取到业务凭证后，对业务凭证进行识别以确定开票业务信息。其中，开票业务信息至少包括事项说明、购买金额和销售方基本信息。其中，开票业务信息是由财务节点和/或业务节点根据购买方与销售方之间的业务交易进程存储于第一企业联盟链上的信息，且可以是由财务节点和/或业务节点共同维护更新的。如第一企业联盟链对应的企业的子公司也共用同样的区块链节点时，则需要根据业务凭证确定当前的销售方基本信息，避免开错票。

其中，事项说明包括“货物、或应税劳务、服务名称”、“规格型号”、“数量”、“单位”、“单价”，购买金额包括：“金额”，销售方基本信息包括销售方名称、纳税人识别号、地址、开户行账号等。其中，如若“规格型号”、“数量”、“单位”在业务凭证中没有体现，可以体现财务人员操作填写，也可以直接选用默认选项，如“数量”默认为1、“单位”默认为“个”，“单价”可以根据“金额”和“数量”自动计算求得并填入。

进一步地，根据业务凭证确定开票业务信息，包括：根据业务凭证获取开票业务信息；对开票业务信息进行校核，以确定开票业务信息所对应的业务交易符合开票条件。其中，开票业务信息是由财务节点和/或业务节点根据购买方与销售方之间的业务交易进程存储于第一企业联盟链上的信息。

进一步地，请参见图7，图7为本申请一种票据处理的方法又一实施例中的流程示意图。在当前实施例中，上述步骤对开票业务信息进行校核，以确定开票业务信息所对应的业务交易符合开票条件，进一步包括：

s71：判断购买方是否完成开票申请对应的业务交易的资金支付。

根据所获取的开票业务信息确定购买方是否完成资金支付。具体地，可以通过上链查询订单号和/或合同编号，确认是否收到对应的款项，并且确定收到的款项与业务凭证中的应收款项金额是否相同。

更进一步地，在其他实施例中，对开票业务信息进行校核还包括，校核当前开票申请对应的业务是否开过票，若经过上料查询得到当前业务已经开过票了，则会停止开票进程并将查询结果反馈至购买方。

s72：进一步确定购买方基本信息和销售方基本信息是否准确。

若步骤s71中判断得到购买方完成开票申请对应的业务交易的资金支付，且没有申请过对当前业务的开票，则会进一步确定购买方基本信息和销售方基本信息是否准备无误。其中，具体可以将自开票申请中解析获得购买方基本信息与业务凭证的购买方的基本信息进行比对，如若相同，则判断购买方基本信息准确无误。销售方的基本信息可以是直接与本地系统预存的基本信息进行比对即可，或者也可以是以弹窗的形式提示用户校核。

s73：若确定准确，则判断业务交易符合开票条件，并将通过校验的业务信息输出。

若经过确定购买方基本信息和销售方基本信息准确无误，则可以判断得到当前开票申请对应的业务交易符合开票条件，进而将通过校验的业务信息输出，以生成开票请求。在当前实施例中，通过对购买方基本信息和销售方基本信息的校验，可以较好地保证发送至税务联盟链的开票请求中的所包括的信息准确可用，避免因这些基础信息不准确耽误开票的进度，可较好地提高可靠性和开票的效率。

s63：根据购买方的基本信息、销售方的基本信息和开票业务信息生成开票请求。

经过校验的购买方的基本信息、销售方的基本信息和开票业务信息填入至开票请求模板中，然后并打包成区块以生成开票请求。其中，开票请求中包括：购买方的基本信息、销售方的基本信息、事项说明、购买金额和销售方基本信息。

请参见图8，图8为本申请一种票据处理的方法再一实施例中的流程示意图。在当前实施例中，本申请所提供的方法包括：

s81：财务节点获取购买方发送的开票申请。

s82：解析开票申请，以获得购买方的基本信息和开票申请对应的业务凭证。

s83：根据业务凭证获取开票业务信息，对开票业务信息进行校核，以确定开票业务信息所对应的业务交易符合开票条件。

在当前实施例中，步骤s81与上述步骤s51相同，步骤s82与上述步骤s61相同，步骤s83与上述步骤s52及图7所对应的实施例中包括的步骤相同，具体可以参见上文对应部分的阐述，在此不再重复。

s84：若开票业务信息所对应的业务交易符合开票条件，则根据开票申请，获取至少一个发票号段。其中，发票号段为空白的没有开具的发票号段。在当前实施例中，发票号段可以是企业预先向税务机构申请的。可以理解的是，在其他实施例中发票号段也可以是当企业申请开票时由税务机构实时下发的。

若步骤s83中确定了开票业务所对应的业务交易符合开票条件，则财务节点会根据开票申请获取至少一个发票号段。进一步地，是根据开票申请所对应的业务，获取至少一个对应该业务的发票号段。如当开票申请对应的业务对应的发票类型为增值税专用发票，则步骤s84对应获取增值税专用发票的票号；如若开票申请对应的业务对应的发票类型为普通发票，则步骤s84对应获取普通发票的票号。

进一步地，如若当前开票申请对应的开票金额大于每张发票限定的额度，则步骤s84之前还包括计算所需开具的发票的数量，对应的步骤s84为获取计算对应数量的发票号段。其中，所获取的发票号段的最大面额的总值大于或等于所需开票金额。如，需要开票的金额为13万，但是销售方企业的发票根据税务机构的要求限定每张最大额度为5万，则此时需要开3张发票，则步骤s84对应获取3个发票号段。

进一步地，由于企业每个月向税务机构申报的发票数量都是固定的，如若经过获取发票号段得知，当月发票不够使用，则会发送提醒给财务人员以重新向税务机关申报新的发票号段。

进一步地，如若当月发票号段的已经用完，此时税务机关尚未下发新的发票号段，则本申请所提供的方法还包括，暂停开票进程，并将发票用完开票需要等待反馈给购买方。更进一步地，在向购买方反馈发票用完开票需要等待时，可以给出一个预估完成开票的时间，以便购买方可以及时跟进开票进程。

s85：根据所获取的发票号段、购买方的基本信息、销售方的基本信息和开票业务信息生成开票请求。

在获取得到发票号段之后，进一步根据所获取的发票号段、购买方的基本信息、销售方的基本信息和开票业务信息生成开票请求。在当前实施例中，会将所获取的发票号段直接写入开票请求中并发送至税务联盟链。

s86：将开票请求发送至主节点以转发至税务联盟链。

s87：获取税务联盟链响应开票请求生成的发票链信息，并将发票链信息填至票据版式模板以生成发票，并将发票反馈至购买方。

在当前实施例中，步骤s86和步骤s87分别与上述步骤s53和步骤s54相同，具体可以参见上文对应部分的阐述，在此不再重复。

请参见图9，图9为本申请一种票据处理的方法一实施例中的流程示意图。当前实施例中，本申请所提供的方法应用于税务机构所在的税务联盟链，当前实施例中是从税务联盟链的角度阐述本申请所提供的方法。

其中，税务联盟链包括主节点和开票节点，主节点用于汇集所在联盟链内的信息，还用于进行所在联盟链与其他联盟链间的信息交互，开票节点用于响应企业联盟链发送的开票请求并生成发票链信息，如上所述发票链信息为发票中的关键信息，是必须税务机构生成的信息。其他联盟链至少包括企业联盟链。在当前实施例中，本申请所提供的一种票据处理的方法包括：

s91：开票节点接收主节点从企业联盟链接收到的开票请求。

开票节点接收到税务联盟链的主节点转发的开票请求。其中，开票请求是企业联盟链中的财务节点发送的用于申请发票的请求消息。

s92：解析开票请求，以获取销售方的基本信息、业务信息和购买方的基本信息。

开票节点解析所接收到的开票请求，进而获取到销售方的基本信息、业务信息和购买方的基本信息。

进一步地，在另一实施例中，当开票请求中包括发票号段时，则步骤s92还包括解析开票请求，以获取发票号段、销售方的基本信息、业务信息和购买方的基本信息。

s93：根据销售方的基本信息、业务信息和购买方的基本信息，响应开票请求生成发票链信息。

根据销售方的基本信息、业务信息和购买方的基本信息，响应开票请求生成发票链信息。其中，发票链信息至少包括：“二维码内容、发票代码和号码、校验码、密文区”等信息。

进一步地，发票链信息的生成规则可以是基于税务联盟链内的智能合约进行生成，税务联盟链内的智能合约是根据现行的“二维码内容、发票代码和号码、校验码、密文区”等信息生成规则设定的合约，并存储至税务联盟链中，具体在此不再详述。

s94：将发票链信息发送至主节点以转发至销售方的第一企业联盟链。

开票节点生成发票链信息之后，进一步将发票链信息发送至主节点以转发至销售方的第一企业联盟链。其中，开票节点可以是直接将所生成的发票链信息发送至税务联盟链主节点，税务联盟链主节点然后将所接收的发票链信息发送至第一企业联盟链。

在另一实施例中，开票节点也可以是将所生成的发票链信息上链存储至税务联盟链内，然后税务联盟链主节点通过访问税务联盟链后获得发票链信息，然后将所获取的发票链信息发送至第一企业联盟链的主节点处。在其他实施例中，税务联盟链主节点也可以是将所获取的发票链信息存储至主链，然后第一企业联盟链通过访问主链，进而获得发票链信息并转发至第一企业联盟链内的财务节点。其中，主链为区块链系统中不同联盟链的主节点共同构成的区块链。

进一步地，由于一个税务联盟链会下设有不同区域的企业，本申请所提供的技术方案中，会预先将不同的企业联盟链按照区域进行划分，然后将若干开票节点分别与不同区域的企业联盟链进行关联，这样在税务联盟链接收到企业联盟链的开票请求后，直接将该开票请求转发至对应的开票节点或转发至对应的几个开票节点，供开票节点自动认领开票请求。

进一步地，由于企业每年所需要的发票数量是有迹可循的，具体可以根据企业往年的经营情况确定当年的预估数量，或者是确定每个月的所需要的发票数量，故税务联盟链中的开票节点在接收到开票申请后，进一步判断开票申请所对应的销售方当月的发票数量是否到达数量阈值，若是，则暂停为销售方开票并发送提醒给销售方，进而使得销售方重新申请新的发票号段，若否，则继续执行开票流程。

进一步地，在其他实施例中，开票节点在接收到开票请求后，进一步基于开票申请中所包括的开票金额，判断销售方当月的额度是否大于或等于额度阈值，若是，则暂停为销售方开票并发送提醒给销售方，进而使得销售方重新申请发票额度，若否，则继续执行开票流程。

请参见图10，图10为本申请一种票据处理的方法一实施例中的流程示意图。在图10中，具体展示的是销售方、购买方和税务方的联盟间的交互示意图。在当前实施例中，财务节点是第一企业联盟链内的节点，开票节点为税务联盟链内的节点。本申请所提供的方法包括：

1.获取购买方直接发送至财务节点的开票申请，或获取第一企业联盟链内的业务节点转发的来自购买方的开票申请。

2.解析开票申请，以获得购买方的基本信息和开票申请对应的业务凭证。

3.根据业务凭证确定开票业务信息。

4.根据购买方的基本信息、销售方的基本信息和开票业务信息生成开票请求。

5.将开票请求发送至主节点以转发至税务联盟链。

6.第一企业联盟链的主节点转发开票请求至税务联盟链的主节点。

7.税务联盟链主节点将开票请求转发至开票节点。

8.开票节点接收主节点从企业联盟链接收到的开票请求。

9.解析开票请求，以获取销售方的基本信息、业务信息和购买方的基本信息。

10.根据销售方的基本信息、业务信息和购买方的基本信息，响应开票请求生成发票链信息。

11.将发票链信息发送至主节点以转发至销售方的第一企业联盟链。

12.将发票链信息发送至第一企业联盟链的主节点。

13.将发票链信息发送至财务主节点。

14.将发票链信息填至票据版式模板以生成发票，并将发票反馈至购买方。

在企业的生产经营中，时常会有票据需要报销入账。在对单据进行报销入账的过程中，常常会出现一票多报的问题，且由于报销往往需要多方进行审核，需要多方进行配合这就造成报销过程繁琐、效率较低等技术问题。为解决上述技术问题，本申请还提供了一种票据处理的方法。

请参见图11，图11为本申请一种票据处理的方法一实施例中的流程示意图。本申请所提供的一种票据处理的方法应用于包括至少一个联盟链的区块链系统，每个联盟链包括申请节点和审核方节点。首先需要说明的是，审核方节点包括财务节点，本申请所提供的方法适用于任何具备报销流程的联盟链，如企业联盟链、事业单位的联盟链和税务联盟链。本申请所提供的方法包括：

s111：申请节点获取报销业务信息，并基于报销业务信息生成报销申请。

其中，申请节点为提起报销申请的节点。具体地，当某一职工需要完成某一报销任务时，可以通过登录自身具备权限的节点账号，然后在节点上填写报销申请单并提起报销申请。其中，该节点为申请节点。在职工填写完报销申请单之后、且申请节点在提起报销申请前，申请节点首先获取报销业务信息。其中，报销业务信息为需要报销的事项所对应的凭证信息。凭证信息具体可以包括凭证的哈希值，也可以包括凭证的图像和图像的哈希值。

其中，用户在报销申请单中填写了报销事项以及对应的明细，报销申请单为电子申请单。当本申请方法是应用于企业单位时，所需报销的事项至少包括为企业采购代付的费用事项、因公事产生的消费事项和项目奖励事项。报销事项对应的明细至少包括：报销事项发生的时间、地点，如若报销事项为项目奖励事项，则报销事项对应的明细对应包括项目名称、项目周期、项目类型和项目总额。进一步地，报销事项对应的明细还可以包括报销事项对应的单据编号或项目编号。

在一实施例中，申请节点根据职工填写的报销申请单获取报销业务信息，并基于所获取的报销业务信息生成报销申请。更进一步地，申请节点根据职工填写的报销申请单在联盟链上获取报销业务信息。

在获取到报销业务信息之后，进一步将报销申请表和报销业务信息生成报销申请，其中报销申请为申请节点发送至审核方节点的请求。

进一步地，报销业务信息至少包括：采购凭证信息和/或票据凭证信息。请参见图12，图12为本申请一种票据处理的方法另一实施例中的流程示意图。在当前实施例中，上述步骤s111申请节点获取报销业务信息，并基于报销业务信息生成报销申请包括步骤s121和步骤s122。

s121：自联盟链内获取需要报销的采购凭证信息和/或票据凭证信息。

本申请所提供的方法，如若产生票据，则会将所产生的票据上传联盟链进行上链存储。如当预先将采购凭证和票据凭证存储于联盟链上，申请节点只需要访问联盟链即可获取到需要报销所需的采购凭证信息和/或票据凭证信息。如若采购凭证和/或票据凭证为传统的纸质，则本申请所提供的方法还包括：利用图像处理设备对采购凭证和/或票据凭证进行处理以获取采购凭证和/或票据凭证的电子图像数据，并进行上链存储。在另一实施例中，如若采购凭证和/或票据凭证存储于其他外部系统中，则本申请所提供的方法还包括：通过区块链系统集成，用api接口调用其他外部系统里存储的这些信息。

进一步地，在其他实施例中，当采购凭证或票据凭证开具的一方也部署于联盟链，且采购凭证或票据平局开具的一方所在的联盟链与当前的联盟链可以进行数据交互，采购凭证或票据凭证也可以是通过开具凭证的联盟链直接传输至当前联盟链的，当前联盟链获取到以后则直接进行存储上链即可。

其中，采购凭证信息至少包括采购凭证的哈希值和采购凭证的图像，票据凭证信息至少包括票据凭证的哈希值和票据凭证的图像。

s122：将采购凭证信息和/或票据凭证信息进行封装和签名，生成报销申请。

将所获取的采购凭证信息和/或票据凭证信息进行封装和签名，以生成报销申请。在一些实施例中，也会将报销申请理解为未记账的报销记账凭证。

其中，需要说明的是如果报销事项只有采购凭证信息，则只需将采购凭证信息进行封装和签名。在另一实施例中，当报销事项同时产生了采购凭证信息和票据凭证信息，则具体是将采购凭证信息和票据凭证信息进行封装和签名，生成报销申请。

s112：将报销申请发送至与报销业务关联的审核方节点进行审核。

其中，与报销业务关联的审核方节点的数量为至少一个。如，如若预先设定报销申请只需要财务节点进行审核时，则此时与报销业务关联的审核方节点仅包括财务节点，故只需要将报销申请发送至财务节点进行审核。

在另一实施例中，如若设定报销申请需要管理节点进行业务审核，同时还需要财务节点进行金额审核，则步骤s112进一步包括，将报销申请发送至财务节点和用于审核业务的管理节点进行审核。其中，将报销申请发送至财务节点和用于审核业务的管理节点的顺序不做限定，具体依据实际的设置，如可以是将报销申请同时发送至管理节点和财务节点进行审核。在其他实施例中，还可以是将报销申请发送至管理节点，管理节点通过之后，再由申请节点或管理节点发送至财务节点进行审核。其中，审核报销申请的顺序可以预先写入智能合约。

s113：判断是否接收到所有与报销业务关联的审核方节点的审核通过回执。

在将报销申请发送至与报销业务关联的审核方节点进行审核之后，申请节点进一步监测判断是否接收到所有与报销业务关联的审核方节点的审核通过回执。其中，审核通过回执是审核方节点审核通过报销申请后，发送至申请节点以告知申请节点报销申请的审核通过。

为保证报销的准确度，故步骤s113需要判断是否接收到所有的与报销业务关联的审核方节点发送的审核通过回执。

s114：若是，则请求财务节点执行报销申请，并生成报销记账凭证并上链保存报销记账凭证。

若判断申请节点已经接收到所有与报销业务关联的审核方节点的审核通过回执，则申请节点会进一步请求财务节点执行报销申请，将报销资金转至报销职工的账户。

进一步地，在其他实施例中，当报销申请通过后，则无需申请节点提出请求，财务节点自动执行报销申请。可以理解的，企业的财务是按照设定时间进行资金的操作，古在报销申请通过后，也可以是由财务节点记入待支付资金事项，等待统一支付报销金额。

进一步地，在另一实施例中，一些企业中，报销是在发工资时直接和工资叠加发送，则本申请中的请求财务节点执行报销申请包括：将审核通过的报销金额添加至职工的工资绩效上，等待与工资一起发放。

本申请图11所提供的技术方案，由申请节点获取报销业务信息，并基于报销业务信息生成报销申请，然后申请节点将报销申请发送至与报销业务关联的审核方节点进行审核，并判断是否接收到所有与报销业务关联的审核方节点的审核通过回执；若判断得到接收到所有与报销业务关联的审核方节点的审核通过回执，则申请节点进一步请求财务节点执行报销申请，并生成报销记账凭证并上链保存报销记账凭证，本申请所提供的技术方案通过在联盟链上提起报销申请、到将报销申请发送至审核方节点，再到获取到审核方节点发送的审核通过回执，全部基于联盟链及联盟链上的各个节点执行完成报销流程，进而无需相关人员进行沟通传递纸质报销凭证和单据，可以较好地提高了报销的效率，同时在联盟链内传递报销所需的报销业务信息，也可以较好地增加报销的可靠性，避免出现一票多报等问题。

进一步地，请参见图13，图13为本申请一种票据处理地方法一实施例中的流程示意图。在当前实施例中，上述步骤s122将采购凭证信息和/或票据凭证信息进行封装和签名，生成报销申请包括：

s131：对采购凭证的图像和/或票据凭证的图像进行识别获取报销信息。

获取到采购凭证的图像和/或票据凭证的图像之后，进一步进行识别以获取报销信息。其中，用于图像识别的算法为预先存储在申请节点的。报销信息包括：报销金额和报销事项说明。

132：基于报销信息、报销模版生成报销申请表。

在当前实施例中，直接基于报销信息、报销模板生成报销申请表。其中，根据报销类型的不同，报销模板也能不同。其中，报销类型包括：个人报销、项目报销、部门报销。对应的，则可以预先为各种报销对应的报销模板。

在当前实施例中，可以直接基于报销信息确定报销类型。如若，采购凭证为购买办公用品个人代付的凭证，则确定是个人报销。如若，报销凭证为部门项目活动需要申请的预付资金，则确定报销类型为项目报销。可以理解的是，在其他实施例中，报销类型的确定还可以依据其他的方式。

在另一实施例中，也可以是由报销职工直接写名报销类型，然后申请节点基于职工填写的报销类型获取对应的报销模板，然后生成报销申请表。

133：利用私钥将报销申请表、采购凭证的哈希值和票据的哈希值封装并签名，生成报销申请。

在生成报销申请表之后，申请节点利用私钥将报销申请表、采购凭证的哈希值和票据凭证的哈希值封装并签名，进而生成报销申请。其中，私钥为节点用于加密的密钥，接收节点可以直接利用自身存储的该节点的公钥则可以直接对报销申请进行解密。

进一步地，在其他实施例中，申请节点在生成报销申请时，需要同步确定报销申请的审核方。如提起报销申请的员工为研发部，则对应可以确定得到该报销申请的审核方节点至少包括研发部门的管理节点和财务节点。需要说明的是，根据预先设定，报销申请不可以跨部门审核，如a部门的报销申请不可以是由b部门的管理节点进行审核。

进一步地，请参见图14，图14为本申请一种票据处理的方法一实施例中的流程示意图。在当前实施例中，审核方节点还包括与报销业务关联的至少一个管理节点，本申请所提供的方法包括：

s141：申请节点获取报销业务信息，并基于报销业务信息生成报销申请。步骤s141于上述步骤s111相同，在此不再重复，具体可以参见上文对应部分的阐述。

在当前实施例中，上述步骤s122将报销申请发送至与报销业务关联的审核方节点进行审核，进一步包括s142和步骤s143。

s142：将报销申请发送至与报销业务关联的所有管理节点进行审核。

在一实施例中，审核方节点还包括与报销业务关联的至少一个管理节点，则步骤s142也可以理解为是将报销申请同时发送至将报销申请发送至与报销业务关联的所有管理节点进行审核。其中，管理节点至少用于对报销申请进行业务审核，以审核报销申请所对应的报销事项是否可以进行报销。

在另一实施例中，按照与报销业务关联的管理节点设定的次序，依序将报销申请发送至与报销业务关联的管理节点进行审核，直至完成对所有与报销业务关联的管理节点发送后停止发送。如，与报销业务关联的管理节点包括q、r和p，且q、r和p级别依次降低，则步骤s142可以是将报销申请同时发送至q、r和p进行审核；或者是按照级别依次增高的顺序发送给p、r和q进行审核。

进一步地，如若是同时发送至将报销申请发送至与报销业务关联的所有管理节点进行审核，则可以在与报销业务关联的所有管理节点之间利用共识机制，判断管理节点最终是否通过报销申请。如，在一实施例中，当所有与报销业务关联的所有管理节点均通过报销申请，则该报销申请通过审核，反之，如若有一个与报销业务关联的所有管理节点没有通过，则申请节点判断得到该报销申请没有通过审核。在另一实施例中，则选用依据级别最高的节点的审核结果为准，以上述p、r和q为例，如若级别最高的节点q通过了报销申请，则申请节点判断得到报销申请通过，反之，如若级别最高的节点q打回了报销申请，则报销申请没有通过。

s143：若收到所有管理节点反馈的审核通过回执，则将报销申请和所有管理节点反馈的审核通过回执发送至财务节点审核。

在当前实施例中，在将报销申请发送至与报销业务关联的所有管理节点进行审核之后，本申请所提供的方法还包括：若收到所有管理节点反馈的审核通过回执，则表示所有与报销业务关联的管理节点认为当前报销申请的业务，管理节点对于报销申请中的报销事项没有异议。申请节点则会将报销申请和所有管理节点反馈的审核通过回执发送至财务节点审核。其中，在当前实施例中，财务节点主要审核报销金额。可以理解的是，在其他实施例中，财务节点还可以同时用于审核报销申请的业务和事项。

进一步地，在另一实施例中，若审核方节点包括多个不同级别的管理节点，财务节点为在所有审核方节点中级别最高的节点，对应的上述步骤s112还包括：按照与报销业务关联的管理节点的级别，由低至高依次将报销申请发送至与不同级别的管理节点进行审核。

其中，当低级的管理节点审核通过时再将报销申请发送至高级的管理节点。在当前实施例中，节点的低级和高级是相对概念，即只是两两级别比较的结果。如，上述例子中的管理节点q、r和p，相对其他普通的节点(非管理节点)，这三个节点的级别都比较高，但是在对于报销申请的审核流程中，管理节点q的级别大于管理节点r，管理节点r的级别大于管理节点p，将报销申请发送至管理节点q、r和p进行审核，则首先将报销申请发送至管理节点p，管理节点p通过后，再将报销申请发送至管理节点r，管理节点r通过再发送至管理节点q。其中，每个节点审核报销申请之后，均会对应进行签名，以便追踪审核记录和审核流程。

s144：若收到财务节点发生的审核通过回执，请求财务节点执行报销申请，并生成报销记账凭证并上链保存报销记账凭证。

在当前实施例中，报销执行是需要申请节点发送请求。可以理解的是，在其他实施例中，若报销申请审核通过，则可以是直接由财务节点执行。

需要说明的是，步骤s144和步骤s114及其对应的实施例相同，具体可参见上文对应部分地阐述，在此不再重复。

进一步地，如若步骤s143之后，若接收到一管理节点或财务节点发送的退回报销申请回执，本申请所提供的方法还包括：生成退回提醒，以提示用户调整报销申请。如若某一管理节点或财务节点审核得到当前报销申请无法通过并退回，接收节点则生成退回提醒以提示用户调整报销申请。进一步地，申请节点则生成退回提醒之后，会进一步将退回提醒发送至于申请节点关联额终端。

更进一步地，在一实施例中，若接收到用户重新提出的报销申请，则将用户重新提出的报销申请直接发送至退回的节点。在当前实施例中，通过设计用户重新提出的报销申请直接发送至退回的节点，可以较好地提高报销审核的效率。

再进一步地，审核方节点再退回报销申请时，可以给选定重新提交时的节点。具体地，如若审核方觉得需要其他的节点重新进行审核，则可以为该报销申请选取对应的节点，对应用户重新提出的报销申请时，报销申请可以直接被转发至退回节点所选用的退回重新审核的节点。

更进一步地，在另一实施例中，若接收到用户重新提出地报销申请，将用户重新提出的报销申请发送至最低级别的管理节点以重新进行审核。在当前实施例中，通过设计将用户重新提出的报销申请发送至最低级别的管理节点以重新进行审核，使所有的管理节点再次对更新调整后的报销申请进行重新审核，可以较好地提高报销审核的可靠性。

请参见图15，图15为本申请一种票据处理的方法一实施例中的流程示意图。方法应用于包括至少一个联盟链的区块链系统，每个联盟链包括一个申请节点和审核方节点，审核方节点包括财务节点，该方法包括：

s151：财务节点接收申请节点发送的报销申请。

财务节点可以是接收申请节点直接定向发的报销申请。在另一实施例中，财务节点还可以是将报销申请发送至联盟链上进行上链，然后审核方节点通过上链访问获取，进而对报销申请进行审核。

s152：根据智能合约对报销申请进行审核，以判断报销申请是否符合预设的报销制度。

其中，智能合约为根据报销制度预设并存储的合约。由于不同的企业和单位的报销制度不同，对应的，智能合约也不相同。

s153：若符合，则生成审核通过回执且发送至申请节点，并响应报销申请。

若智能合约判断得到报销申请符合预设的报销制度，则会很生成审核通过回执且发送至申请节点，并响应报销申请。在一实施例中，响应报销申请包括向报销申请职工支付报销金额。在另一实施例中，报销是在发工资时直接和工资叠加发送，则本申请中的响应报销申请包括：将审核通过的报销金额添加至职工的工资绩效上，等待与工资一起发放。

进一步地，响应报销申请之后，方法还包括：生成对应报销申请的已审核报销凭证，并将已审核报销凭证存储至联盟链上。其中，该已审核报销凭证可作为财务部编撰财会报表和报表分析的基础资料，并编制企业预算，从而帮助企业根据历史费用报销财务信息执行异常费用报销预警和精益化预算管理。同时，财务分析报告也能够为企业高层提供经营决策和企业战略规划的参考。

s154：若不符合，则生成退回报销申请回执。

若智能合约判断得到报销申请不符合预设的报销制度，则生成退回报销申请回执并发送至申请节点。

进一步地，审核方节点还包括与报销业务关联的至少一个管理节点，财务节点接收申请节点发送的报销申请，还包括：

财务节点接收管理节点审核通过的报销申请，管理节点审核通过的报销申请是由管理节点或申请节点发送至财务节点。在当前实施例中，在财务节点对报销申请进行审核之前，还会由与报销业务关联的至少一个管理节点对报销申请进行业务审核。

值得注意的是，上述实施例中所提及的智能合约是用于自动审批业务和审核费用。在智能合约自动审批业务和审核费用，需要将该企业、单位的费用报销的制度、规则以及各类限制条件使用代码编译出来提交到联盟链。

例如对于非研发岗位的员工只能报销金额等于或低于￥7500元的办公电脑，这里关键条件为“非研发岗位”、“办公电脑报销”、“≤7500”，而智能合约的执行审核流程时，会负责在该审核方节点接收到报销申请后，获取报销申请中所包括的业务信息或费用金额信息，然后执行合约代码中的审核流程，并自动完成对业务信息、费用金额信息及审批通过交易信息的存储和查询工作。

智能合约的生成主要包括将预设数据结构、预设关联规则，将费用报销制度和规章编译进入源代码中，并预设报销人员基础信息、消费单位相关信息、税务机构相关信息以及银行相关信息，联盟链将根据代码自动推断合约的生成条件，根据代码自动匹配相关业务数据报销范围、报销标准等内容并与电子数据签名身份做核对验证，从而达到自动审核的目的。当一笔费用报销申请发生，数据信息上传至联盟链上的与报销申请关联的管理节点和财务节点，然后管理节点的负责人、财务负责人根据自己的权限，智能合约自动完成业务审批、费用审核工作。如若自动审核出现问题，提交对应节点进行人工审核，审核通过后，审核结果存入区块链中，加上时间戳进行保存。

在一实施例中，如若需要有业务进行报销时，申请节点首先从链上获取事先存证的报销业务信息，如采购凭证(包括传统电子发票和区块链电子发票)的哈希值等，从链上获取传统电子发票的哈希值，或从链上提取区块链电子票据的交易hash值，申请节点用自己的私钥对封装在一起的报销业务信息和票据信息进行封装并数字签名，并生成报销申请，然后在联盟链上执行报销申请，形成未记账的报销单据。

将报销申请发送给与报销业务关联的多个部门管理节点(即关联部门管理人员)，该街道到报销申请的节点用申请节点的公钥对报销申请进行解密，提取其中的哈希值，将其哈希值与链上哈希进行对比校验，一验证对应的报销业务是否为报销的业务，避免出现重复报销或一票多报的情况。若哈希值校验成功，则通过智能合约自动执行业务审批，如若审批通过，则更新为已审批报销单据。

该报销申请也会同步传递给财务节点，该节点用申请节点的公钥对报销申请进行解密，获取其中报销费用金额，该金额与链上存证的业务发生金额(即链上存储的票据凭证或采购凭证上对应的金额)进行对比；若校验成功，则通过智能合约自动执行费用审核(主要依据报销制度审核费用报销额度、报销科目、费用归属部门是否有足够的预算等)，并在审核通过后将报销申请更新为已审核报销单据。

在当前实施例中，有且仅当报销申请通过所有审核方节点的审核之后，且接受到所有审核方节点的审核通过回执后，单据才有效，方可由财务节点执行报销申请支付对应的报销金额。其中，对于报销申请的审核至少包括：业务审批和费用审核。

进一步地，本申请所提供的方法中还包括：依托已审核报销单据，可生成已审核报销凭证。

请参见图16，图16为本申请一种票据处理的方法地交互示意图。图16着重展示的是用于报销的申请节点和审核节点之间的交互。

1.自联盟链内获取需要报销的采购凭证信息和/或票据凭证信息。

2.将采购凭证信息和/或票据凭证信息进行封装和签名，生成报销申请。

3.按照与报销业务关联的管理节点的级别，由低至高依次将报销申请发送至与不同级别的管理节点进行审核。

4.当低级的管理节点审核通过时再将报销申请发送至高级的管理节点。

5.若收到所有管理节点反馈的审核通过回执，则将报销申请和所有管理节点反馈的审核通过回执发送至财务节点审核。

6.财务节点接收申请节点发送的报销申请。

7.根据智能合约对报销申请进行审核，以判断报销申请是否符合预设的报销制度。

8.若符合，则生成审核通过回执且发送至申请节点，并响应报销申请，或若不符合，则生成退回报销申请回执。

9.生成报销记账凭证并上链保存报销记账凭证。

请参见图17，图17为本申请一种电子设备一实施例中的结构示意图。在当前实施例中，本申请所提供的电子设备1700包括耦接的处理器1701和存储器1702。其中，电子设备1700可以是执行图3至图4及其对应的任意一个实施例中所述方法的区块链节点，电子设备1700也可以是执行图5至图7及其对应的任意一个实施例中所述方法的区块链节点，电子设备1700还可以是执行图8至图13及其对应的任意一个实施例中所述方法的区块链节点。

其中，存储器1702包括本地储存(图未示)，且存储有计算机程序，计算机程序被执行时刻实现图1至图9及其所对应的任意一个实施例中所述的方法。

处理器1701与存储器1702耦接，处理器1701用于运行计算机程序，以执行如上图1至图16及其对应的任意一个实施例中所述的方法。

参见图18，图18为本申请一种计算机可读存储介质一实施例结构示意图。该计算机可读存储介质1800存储有能够被处理器运行的计算机程序1801，该计算机程序1801用于实现如上图1至图16及其对应的任意一个实施例中所描述的方法。具体地，上述计算机可读存储介质1800可以是存储器、个人计算机、服务器、网络设备，或者u盘等其中的一种，具体在此不做任何限定。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。