CN117114787A - 基于电子发票的供应链管理方法、系统和终端 - Google Patents

Abstract

本申请公开了基于电子发票的供应链管理方法、系统和终端，其中，方法包括：获取开票请求终端发送的发票信息，获取各个电子发票，基于预设的封装规则将每一电子发票封装为待验证交易；获取验票请求，根据验票请求中的验票信息获取目标待验证交易组；调用预设的智能合约对目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。通过本申请提供的技术方案能够获知供应链中哪一交易环节存在异常，进而对异常情况进行预警，提高了供应链的管理效率。

Description

基于电子发票的供应链管理方法、系统和终端

技术领域

本申请属于电子发票技术领域，尤其涉及一种基于电子发票的供应链管理方法、系统和终端。

背景技术

商品供应链通常包括多个环节，企业在各个环节中既可能是上游企业，也可能是下游企业，针对包含多个企业的商品供应链，信息的溯源性和真实性尤为重要。

目前，商品供应链管理系统缺乏电子发票数据来作为交易溯源和交易合法性判定的依据，未对电子发票数据进行充分利用，供应链管理效率欠佳。

发明内容

本申请的实施例提供了一种基于电子发票的供应链管理方法、系统和终端，进而至少在一定程度上可以将电子发票数据作为供应链管理的依据，提高供应链管理效率。

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

根据本申请实施例的第一方面，提供了一种基于电子发票的供应链管理方法，执行于供应链管理终端，所述供应链管理终端用于根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理，所述方法包括：

针对每一上游企业，获取与所述上游企业对应的开票请求终端发送的发票信息，将所述发票信息上传至与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票；

获取各个所述电子发票，基于预设的封装规则将每一所述电子发票封装为待验证交易，将各个所述待验证交易发送到区块链中进行存储；

获取与目标下游企业对应的验票请求终端发送的验票请求，根据所述验票请求中的验票信息获取与所述验票信息匹配的目标待验证交易组，所述目标待验证交易组包括目标上游企业对应的至少一个目标待验证交易，所述目标上游企业为所述目标下游企业的至少一级上游企业；

调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。

在本申请的一些实施例中，基于前述方案，基于预设的封装规则将每一所述电子发票封装为待验证交易，包括：将所述电子发票按照预设格式进行转码，生成满足所述区块链存储格式规则的目标字符段；

将所述目标字符段、当前时刻的时间戳以及所述目标下游企业和所述目标上游企业的哈希地址封装为待验证交易。

在本申请的一些实施例中，基于前述方案，调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理，包括：

调用预设的智能合约判断第一目标待验证交易是否已验证，如果所述第一目标待验证交易已验证，则验证失败，对供应链异常状态进行预警处理，所述第一目标待验证交易为所述目标下游企业的相邻一级上游企业对应的待验证交易；

如果所述第一目标验证交易未验证，则调用预设的智能合约判断第二目标待验证交易中的待验商品余量是否大于所述第一目标待验证交易中的商品余量，所述第二目标待验证交易为所述目标下游企业的相邻两级上游企业的待验证交易；

如果所述第二目标待验证交易中的待验商品余量小于所述第一目标待验证交易中的商品余量，则验证失败，对供应链异常状态进行预警处理。

在本申请的一些实施例中，基于前述方案，在调用预设的智能合约判断第二目标待验证交易中的待验商品余量是否大于所述第一目标待验证交易中的商品余量之后，所述方法还包括：

如果所述第二目标待验证交易中的待验商品余量大于或等于所述第一目标待验证交易中的商品余量，则验证通过，更新所述第二目标待验证交易中的待验商品余量，以及更新所述第一目标待验证交易的验证状态为已验证。

在本申请的一些实施例中，基于前述方案，所述对供应链异常状态进行预警处理，包括：

获取所述目标下游企业以及所述目标上游企业的目标定位信息，根据所述目标定位信息获取与所述目标下游企业以及所述目标上游企业对应的商品监管机构信息；

将所述目标下游企业的信息、所述目标上游企业的信息、以及所述目标待验证交易组发送至所述商品监管机构对应的监管终端，以便所述监管终端对供应链的异常状态进行监管。

在本申请的一些实施例中，基于前述方案，所述方法还包括：

获取至少一个所述上游企业的交易信息，对所述交易信息进行解析，得到对应的上游企业的各个进项发票和各个销项发票；

调用所述预设的智能合约获取各个所述进项发票以及各个所述销项发票的验证状态，并基于预设的关联规则将各个所述进项发票以及各个所述销项发票进行自动分组；

根据每一分组下的进项发票和销项发票的验证状态，确定当前分组下是否存在票据隐匿的异常情况。

在本申请的一些实施例中，基于前述方案，基于预设的关联规则将各个所述进项发票以及各个所述销项发票进行自动分组，包括：

提取各个所述进项发票以及各个所述销项发票的摘要信息，根据所述摘要信息，基于预设的关联规则匹配对应的目标分组，所述摘要信息至少包括商品批号。

在本申请的一些实施例中，基于前述方案，所述预设的关联规则的建立过程如下：

采集发票摘要信息样本以及目标分组样本；

基于分词算法对所述发票摘要信息样本进行分词，根据样本数量以及摘要信息的词频，设置最小支持度以及最小置信度；

获取分词处理后的摘要信息分词表，根据所述摘要信息分词表、所述最小支持度、所述最小置信度以及所述目标分组样本获取满足条件的关联规则，将满足条件的关联规则输出为所述预设的关联规则。

根据本申请实施例的第二方面，提供了一种基于电子发票的供应链管理系统，设于供应链管理终端，所述供应链管理终端用于根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理，所述系统包括：

第一获取单元，用于针对每一上游企业，获取与所述上游企业对应的开票请求终端发送的发票信息，将所述发票信息上传至与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票；

发送单元，用于获取各个所述电子发票，基于预设的封装规则将每一所述电子发票封装为待验证交易，将各个所述待验证交易发送到区块链中进行存储；

第二获取单元，用于获取与目标下游企业对应的验票请求终端发送的验票请求，根据所述验票请求中的验票信息获取与所述验票信息匹配的目标待验证交易组，所述目标待验证交易组包括目标上游企业对应的至少一个目标待验证交易，所述目标上游企业为所述目标下游企业的至少一级上游企业；

验证单元，用于调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。

根据本申请实施例的第三方面，提供了一种供应链管理终端，包括处理器，所述处理器用于执行如第一方面任一项所述的方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条程序代码，所述至少一条程序代码由处理器加载并执行以实现如上述第一方面任一项所述的方法所执行的操作。

本申请实施例提供的一个或者多个技术方案，至少实现了如下技术效果或者优点：

本申请将供应链中各个上游企业对应的电子发票封装为待验证交易，并将待验证交易存储在区块链中，以便利用区块链的智能合约对与目标下游企业请求所对应的目标待验证交易进行验证，并根据验证结果对供应链异常状态进行预警处理，由于电子发票通常是由前一级的上游企业开具给后一级的下游企业，通过对目标待验证交易进行验证，能够获知供应链中哪一交易环节存在异常，进而对异常情况进行预警，提高了供应链的管理效率。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了本申请实施例中的基于电子发票的供应链管理方法的流程图；

图2示出了本申请实施例中的基于电子发票的供应链管理系统的结构图；

图3示出了适于用来实现本申请实施例的供应链管理终端的结构示意图。

具体实施方式

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

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

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

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

还需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的对象在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在图示或描述的那些以外的顺序实施。

下面将结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

为了解决供应链管理效率欠佳的问题，本申请实施例通过将供应链中各个上游企业对应的电子发票封装为待验证交易，并将待验证交易存储在区块链中，以便利用区块链的智能合约对与目标下游企业请求所对应的目标待验证交易进行验证，并根据验证结果对供应链异常状态进行预警处理，由于电子发票通常是由前一级的上游企业开具给后一级的下游企业，通过对目标待验证交易进行验证，能够获知供应链中哪一交易环节存在异常，进而对异常情况进行预警，提高了供应链的管理效率。

下面将对本申请实施例提供的基于电子发票的供应链管理方法进行详细说明。

其中，需要说明的是，本申请实施例提供的基于电子发票的供应链管理方法可应用于任意使用操作系统的终端设备，其中，操作系统包括但不限于Windows系统、Mac系统、Linux系统、Chrome OS系统、UNIX操作系统、IOS系统和安卓系统等，此处不做限定；其中，终端设备包括但不限于IPAD平板电脑、个人移动电脑、工业计算机、个人计算机等，此处不做限定。为便于描述，除特别说明外，本申请实施例均以个人计算机为执行主体进行说明。可以理解，所述执行主体并不构成对本申请实施例的限定，在其他的一些实施例中可以采用其他类型的终端设备作为执行主体。

根据本申请的第一方面，提出了一种基于电子发票的供应链管理方法，优选的，所述基于电子发票的供应链管理方法执行于个人计算机，个人计算机中嵌入了运行所述基于电子发票的供应链管理方法的程序代码，以支撑所述方法的实现。

参见图1，示出了本申请实施例中的基于电子发票的供应链管理方法的流程图。

如图1所示，根据本申请实施例的第一方面，提供了一种基于电子发票的供应链管理方法，执行于供应链管理终端，所述供应链管理终端用于根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理，优选的，所述供应链管理终端可以是能源供应链管理终端，所述能源供应链包括多个环节，例如生产、采购、运输以及零售等环节。

需要说明的是，在通过供应链管理终端根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理之间，本申请实施例中的各个上游企业的用户以及各个下游企业的用户需要提前在供应链管理系统进行用户注册，供应链管理终端对各个用户提供的相关信息进行核准，核准通过后，在区块链网络中为各个用户生成对应的区块链账户，并设置各个用户对于数据的使用权限。

在本申请实施例中，所述基于电子发票的供应链管理方法包括但不限于由步骤S101至步骤S104实现，具体如下：

步骤S101.针对每一上游企业，获取与所述上游企业对应的开票请求终端发送的发票信息，将所述发票信息上传至与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票；

需要说明的是，在商品供应链中，所述上游企业与所述下游企业均为相对的概念，比如：对于采购企业来说，其上游企业为生产企业；对于生产企业来说，其下游企业为采购企业。又比如：对于运输企业来说，其上游企业为采购企业，其下游企业为零售企业。

因此，在步骤S101中，所述每一上游企业是指能够上传发票信息，并请求第三方票据管理系统对应的开票终端进行开票的各个企业，且不限于一个或多个企业。

在本申请实施例中，供应链中的各个上游企业对应的开票请求终端可以与所述供应链管理终端采用异步交互机制进行通信，以降低系统的耦合度，从而隔离系统间的相互依赖和故障影响。

具体的，各个上游企业的用户，例如供应商和采购商，在开票终端的用户交互界面发起开票请求，开票终端通过接口向所述供应链管理终端发送发票信息，所述发票信息包括但不限于受票单位名称、纳税人识别号、企业地址、联系电话、开户行以及账号、商品名称、商品单价、商品数量、企业私钥等。供应链管理终端在获取到所述发票信息之后，调用与第三方票据管理系统连接的接口，通过该接口将所述发票信息上传至所述与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票。

需要说明的是，本申请实施例通过供应链管理终端向第三方票据管理系统对应的开票终端发起开票请求，而非通过各个上游企业直接向第三方票据管理系统对应的开票终端发起开票请求，能够使得供应链管理终端快速获取到电子发票数据，无需通过各个上游企业自行上传电子发票，且利用供应链管理终端来发起开票请求，能够保证电子发票的真实性，防止各个上游企业上传虚假电子发票到供应链管理系统中。

在一些实施方式中，所述开票终端在根据所述发票信息生成电子发票时，具体包括：

根据所述发票信息生成电子发票版式文件，并调用对应的电子签章在所述电子发票版式文件中进行电子签章，以生成所述电子发票。

具体的，通过发票信息可以获取到发起开票请求的上游企业的信息、商品信息、订单信息等，其中，上游企业的信息可以是供应商身份信息，例如票方名称等，也可以是采购方身份信息，例如票方名称等；商品信息包括但不限于名称、颜色、类别、型号、图片、报价、税率、销售状态、优惠信息和配送状态等；订单信息可以是订单编号、客户编码、商品价格、商品数量、订单金额、客户名称、发票抬头、发票类型、收货地址、收货电话等，通过将交易中需要记载的交易事项固化在交易格式内，自动生成发票版式文件，并调用签章服务器进行电子签章，以生成电子发票。

步骤S102.获取各个所述电子发票，基于预设的封装规则将每一所述电子发票封装为待验证交易，将各个所述待验证交易发送到区块链中进行存储；

在步骤S102的一种可能的实施方式中，基于前述方案，基于预设的封装规则将每一所述电子发票封装为待验证交易，包括：

步骤S1021.将所述电子发票按照预设格式进行转码，生成满足所述区块链存储格式规则的目标字符段；

需要说明的是，由于区块链对于数据存储格式的限制，在将电子发票存储在区块链上之前，需要对电子发票的数据格式进行转码处理，例如转码为十六进制的字符串，即满足所述区块链存储格式规则的目标字符段。

步骤S1022.将所述目标字符段、当前时刻的时间戳以及所述目标下游企业和所述目标上游企业的哈希地址封装为待验证交易。

需要说明的是，在区块链中，各个区块均包括区块头和区块体，区块头包括前一区块的哈希值、本区块计算得到的哈希值、当前时刻的时间戳等；区块体包括供应链中所有电子发票交易的集合，各个电子发票交易分别包括电子发票的具体内容，例如企业信息、商品批号、商品数量、商品单价、发票号码等。

步骤S103.获取与目标下游企业对应的验票请求终端发送的验票请求，根据所述验票请求中的验票信息获取与所述验票信息匹配的目标待验证交易组，所述目标待验证交易组包括目标上游企业对应的至少一个目标待验证交易，所述目标上游企业为所述目标下游企业的至少一级上游企业；

需要说明的是，当下游企业购进商品时，下游企业通常会对下游企业最近一级的上游企业开具的电子发票进行验证，由于各个下游企业对于商品的采购信息通常属于企业内部的私密信息，因此，各个下游企业通常无法获取其他下游企业对同一上游企业同一批号商品的购买信息，在这个过程中，该上游企业有可能利用各个下游企业之间不能进行信息互通的特征，将超过整批发票中标明数量的相同批号的商品销售至某一个或多个下游企业，在下游企业进行电子发票验证时，该上游企业通过提供整批号的电子发票进行验证，从而导致了整批发票的重复验证问题，进而增加了商品的流通环节，扰乱了商品流通秩序。

需要说明的是，商品在从上游企业流转至下游企业的过程中，一方面，上游企业通过供应链管理终端向第三方票务管理系统请求开具电子发票，从而供应链管理终端将电子发票存储在区块链中，另一方面，上游企业与下游企业在交易过程中，将开具的电子发票发送至下游企业，由此，下游企业所在终端以及区块链中均存储有该电子发票。在此过程中，下游企业为了确保获取的电子发票的真实性，通过向供应链管理终端发起验票请求，该验票请求中携带有验票信息，所述验票信息包括但不限于的发票号码和开票人信息，以便供应链管理终端根据所述验票信息对所述电子发票进行验证，从而通过供应链管理终端对电子发票进行验证，而非通过上游企业提供电子发票进行验证，避免了上游企业通过提供整批号的电子发票进行验证，导致整批发票的重复验证问题。

需要说明的是，由于下游企业可能有多级上游企业，例如零售企业至少具有运输企业、采购企业以及生产企业等多级上游企业。对于下游企业来说，其上一级的上游企业的商品来源是上两级的上游企业，例如运输企业上一级的采购企业的商品来源是生产企业，商品在流转过程中，每一级上游企业均会开具发票，因此，对于目标下游企业而言，其对应的电子发票可能不仅是其上一级的上游企业，还包括上两级甚至多级的上游企业开具的电子发票，因此，在目标下游企业发起验票请求时，与验票信息对应的目标待验证交易组可能包括多个待验证交易，由此可以对商品流通中逐级开具的电子发票分别进行验证，以对供应链的每一环节进行监管，提高供应链的管理效率。

步骤S104.调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。

在本申请实施例中，所述预设的智能合约通过Solidity语言编写得到，通过Solidity语言编写所述预设的智能合约的程序代码，所述程序代码包含了智能合约涉及的函数以及变量等定义，具体的，通过对智能合约的数据结构、数据名称、数据类型、约束条件以及数据说明等进行预先定义，得到所述预设的智能合约。

在步骤S104一种可能的实施方式中，调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理，包括：

步骤S1041.调用预设的智能合约判断第一目标待验证交易是否已验证，如果所述第一目标待验证交易已验证，则验证失败，对供应链异常状态进行预警处理，所述第一目标待验证交易为所述目标下游企业的相邻一级上游企业对应的待验证交易；

在一些实施方式中，在调用预设的智能合约判断第一目标待验证交易是否已验证之前，所述方法包括：

将所述验票信息输入所述预设的智能合约，以使所述预设的智能合约判断是否已存储所述目标待验证交易组，如果未存储所述目标待验证交易组，则根据所述验票信息从区块链中获取对应的目标待验证交易组，并将所述目标待验证交易组的状态信息存储在智能合约中，所述状态信息包括所述目标待验证交易组中各个目标待验证交易的验证状态。

所述第一目标待验证交易已验证是指：所述目标下游企业的相邻一级上游企业开具的电子发票已被其他同级下游企业提交过验证请求，说明该目标下游企业的相邻一级上游企业开具的电子发票存在重复交叉问题，例如开具整批号商品，商品实际数量与发票中标明数量不符的情况，因此供应链在此环节可能存在交易异常。

步骤S1042.如果所述第一目标验证交易未验证，则调用预设的智能合约判断第二目标待验证交易中的待验商品余量是否大于所述第一目标待验证交易中的商品余量，所述第二目标待验证交易为所述目标下游企业的相邻两级上游企业的待验证交易；

步骤S1043.如果所述第二目标待验证交易中的待验商品余量小于所述第一目标待验证交易中的商品余量，则验证失败，对供应链异常状态进行预警处理。

可以理解的是，商品在逐级流转的过程中，同一上游企业的商品可能流转至不同的下游企业，本申请实施例针对同一上游企业的商品的待验证余量进行记录，即当其中一个下游企业对其获取的电子发票中的商品数量进行验证后，则对该上游企业中的商品待验证余量进行扣减和更新，则当另外的下游企业对其获取的电子发票的商品数量进行验证时，如果该上游企业的商品待验证余量小于某下游企业的电子发票中记载的商品数量，说明该上游企业输出的商品数量与各个下游企业购进的商品数量不符，下游企业可能存在重复验证的问题，则供应链在该环节可能存在异常的风险。

在本申请的一些实施例中，基于前述方案，在调用预设的智能合约判断第二目标待验证交易中的待验商品余量是否大于所述第一目标待验证交易中的商品余量之后，所述方法还包括：

如果所述第二目标待验证交易中的待验商品余量大于或等于所述第一目标待验证交易中的商品余量，则验证通过，更新所述第二目标待验证交易中的待验商品余量，以及更新所述第一目标待验证交易的验证状态为已验证。

在本申请的一些实施例中，基于前述方案，所述对供应链异常状态进行预警处理，包括：

获取所述目标下游企业以及所述目标上游企业的目标定位信息，根据所述目标定位信息获取与所述目标下游企业以及所述目标上游企业对应的商品监管机构信息；

将所述目标下游企业的信息、所述目标上游企业的信息、以及所述目标待验证交易组发送至所述商品监管机构对应的监管终端，以便所述监管终端对供应链的异常状态进行监管。

可以理解的是，本申请实施例通过将供应链管理系统与商品监管机构建立通信，使得在供应链管理系统监测到供应链中各个环节存在交易异常时，可以直接将异常信息发送至供应链中各企业对应的商品监管机构，以使商品监管机构基于自身监管职能对异常状态采集监管措施，提高监管机构的工作效率。

在本申请的一些实施例中，基于前述方案，所述方法还包括：

步骤SA1.获取至少一个所述上游企业的交易信息，对所述交易信息进行解析，得到对应的上游企业的各个进项发票和各个销项发票；

需要说明的是，在本申请实施例中，如果供应链管理终端拟对某一个或多个上游企业的整体交易情况进行管理，则可以通过获取各个上游企业的交易信息，并对交易信息的状态进行查询来实现。具体的，通过对交易信息进行解析，能够得到企业的进项发票和销项发票中的信息，包括进项发票对应的可验证商品余量、销项发票的验证状态等。

步骤SA2.调用所述预设的智能合约获取各个所述进项发票以及各个所述销项发票的验证状态，并基于预设的关联规则将各个所述进项发票以及各个所述销项发票进行自动分组；

在步骤SA2中，所述预设的关联规则的建立过程如下：

（1）采集发票摘要信息样本以及目标分组样本；

需要说明的是，所述发票摘要信息包括但不限于受票单位名称、纳税人识别号、企业地址、联系电话、开户行以及账号、商品名称、商品批号、商品单价、商品数量、企业私钥等，所述目标分组样本是指不同类别发票对应的样本。

（2）基于分词算法对所述发票摘要信息样本进行分词，根据样本数量以及摘要信息的词频，设置最小支持度以及最小置信度；

在本申请实施例中，所述分词算法可以采用jieba分词算法，其算法原理为现有的算法原理，此处不再赘述。

需要说明的是，本申请实施例中的支持度是指电子发票属于其中一个目标分组占全部分组可能事件的比例，通过设置最小支持度，使得电子发票与目标分组建立对应关系。本申请实施例中的置信度是指电子发票与目标分组同时出现的概率，通过设置最小置信度，使得电子发票与目标分组建立对应关系。

（3）获取分词处理后的摘要信息分词表，根据所述摘要信息分词表、所述最小支持度、所述最小置信度以及所述目标分组样本获取满足条件的关联规则，将满足条件的关联规则输出为所述预设的关联规则。

需要说明的是，通过最小支持度以及最小置信度，能够获取摘要信息分词表与目标分组样本之间的对应关系，从而建立预设的关联规则。

在本申请的一些实施例中，基于前述方案，基于预设的关联规则将各个所述进项发票以及各个所述销项发票进行自动分组，包括：

提取各个所述进项发票以及各个所述销项发票的摘要信息，根据所述摘要信息，基于预设的关联规则匹配对应的目标分组，所述摘要信息至少包括商品批号。

步骤SA3.根据每一分组下的进项发票和销项发票的验证状态，确定当前分组下是否存在票据隐匿的异常情况。

可以理解的是，通过分组建立进项发票与销项发票之间的对应关系，根据进项发票和销项发票的验证状态，可以清晰获知每一商品批号的验票情况，如果存在商品流通过程中，企业将销项发票归于同一批号的进项发票的情形，则认为存在票据隐匿的异常情况。

基于上述公开的内容，本申请实施例通过将供应链中各个上游企业对应的电子发票封装为待验证交易，并将待验证交易存储在区块链中，以便利用区块链的智能合约对与目标下游企业请求所对应的目标待验证交易进行验证，并根据验证结果对供应链异常状态进行预警处理，由于电子发票通常是由前一级的上游企业开具给后一级的下游企业，通过对目标待验证交易进行验证，能够获知供应链中哪一交易环节存在异常，进而对异常情况进行预警，提高了供应链的管理效率。通过对企业进项发票和销项发票的全追溯并获取所有发票的验证状态，从而解决同批号商品难以监管的问题。

以下介绍本申请的系统实施例，可以用于执行本申请上述实施例中的方法。对于本申请系统实施例中未披露的细节，请参照本申请上述的方法的实施例。

参见图2，示出了本申请实施例的基于电子发票的供应链管理系统的结构图。

如图2所示，根据本申请实施例的第二方面，提供了一种基于电子发票的供应链管理系统200，设于供应链管理终端，所述供应链管理终端用于根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理，所述系统包括：

第一获取单元201，用于针对每一上游企业，获取与所述上游企业对应的开票请求终端发送的发票信息，将所述发票信息上传至与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票；

发送单元202，用于获取各个所述电子发票，基于预设的封装规则将每一所述电子发票封装为待验证交易，将各个所述待验证交易发送到区块链中进行存储；

第二获取单元203，用于获取与目标下游企业对应的验票请求终端发送的验票请求，根据所述验票请求中的验票信息获取与所述验票信息匹配的目标待验证交易组，所述目标待验证交易组包括目标上游企业对应的至少一个目标待验证交易，所述目标上游企业为所述目标下游企业的至少一级上游企业；

验证单元204，用于调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。

参见图3，示出了适于用来实现本申请实施例的供应链管理终端的结构示意图。

如图3所示，根据本申请实施例的第三方面，提供了一种供应链管理终端，包括处理器，所述处理器用于执行如第一方面任一项所述的方法的步骤。

可以理解的是，图3显示的供应链管理终端400仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图3所示，供应链管理终端400以通用计算设备的形式表现。供应链管理终端400的组件可以包括但不限于：上述至少一个处理单元410、上述至少一个存储单元420、连接不同系统组件(包括存储单元420和处理单元410)的总线430。

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

存储单元420可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)421和/或高速缓存存储单元422，还可以进一步包括只读存储单元(ROM)423。

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

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

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

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条程序代码，所述至少一条程序代码由处理器加载并执行以实现如上述第一方面任一项所述的方法所执行的操作。

计算机可读存储介质可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本申请的计算机可读存储介质不限于此，在本申请中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

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

以上所述仅为本申请的实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种基于电子发票的供应链管理方法，执行于供应链管理终端，所述供应链管理终端用于根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理，其特征在于，所述方法包括：

针对每一上游企业，获取与所述上游企业对应的开票请求终端发送的发票信息，将所述发票信息上传至与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票；

获取各个所述电子发票，基于预设的封装规则将每一所述电子发票封装为待验证交易，将各个所述待验证交易发送到区块链中进行存储；

获取与目标下游企业对应的验票请求终端发送的验票请求，根据所述验票请求中的验票信息获取与所述验票信息匹配的目标待验证交易组，所述目标待验证交易组包括目标上游企业对应的至少一个目标待验证交易，所述目标上游企业为所述目标下游企业的至少一级上游企业；

调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。

2.根据权利要求1所述的方法，其特征在于，基于预设的封装规则将每一所述电子发票封装为待验证交易，包括：

将所述电子发票按照预设格式进行转码，生成满足所述区块链存储格式规则的目标字符段；

将所述目标字符段、当前时刻的时间戳以及所述目标下游企业和所述目标上游企业的哈希地址封装为待验证交易。

3.根据权利要求1所述的方法，其特征在于，调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理，包括：

调用预设的智能合约判断第一目标待验证交易是否已验证，如果所述第一目标待验证交易已验证，则验证失败，对供应链异常状态进行预警处理，所述第一目标待验证交易为所述目标下游企业的相邻一级上游企业对应的待验证交易；

如果所述第一目标验证交易未验证，则调用预设的智能合约判断第二目标待验证交易中的待验商品余量是否大于所述第一目标待验证交易中的商品余量，所述第二目标待验证交易为所述目标下游企业的相邻两级上游企业的待验证交易；

如果所述第二目标待验证交易中的待验商品余量小于所述第一目标待验证交易中的商品余量，则验证失败，对供应链异常状态进行预警处理。

4.根据权利要求3所述的方法，其特征在于，在调用预设的智能合约判断第二目标待验证交易中的待验商品余量是否大于所述第一目标待验证交易中的商品余量之后，所述方法还包括：

如果所述第二目标待验证交易中的待验商品余量大于或等于所述第一目标待验证交易中的商品余量，则验证通过，更新所述第二目标待验证交易中的待验商品余量，以及更新所述第一目标待验证交易的验证状态为已验证。

5.根据权利要求1所述的方法，其特征在于，所述对供应链异常状态进行预警处理，包括：

获取所述目标下游企业以及所述目标上游企业的目标定位信息，根据所述目标定位信息获取与所述目标下游企业以及所述目标上游企业对应的商品监管机构信息；

将所述目标下游企业的信息、所述目标上游企业的信息、以及所述目标待验证交易组发送至所述商品监管机构对应的监管终端，以便所述监管终端对供应链的异常状态进行监管。

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

获取至少一个所述上游企业的交易信息，对所述交易信息进行解析，得到对应的上游企业的各个进项发票和各个销项发票；

调用所述预设的智能合约获取各个所述进项发票以及各个所述销项发票的验证状态，并基于预设的关联规则将各个所述进项发票以及各个所述销项发票进行自动分组；

根据每一分组下的进项发票和销项发票的验证状态，确定当前分组下是否存在票据隐匿的异常情况。

7.根据权利要求6所述的方法，其特征在于，基于预设的关联规则将各个所述进项发票以及各个所述销项发票进行自动分组，包括：

提取各个所述进项发票以及各个所述销项发票的摘要信息，根据所述摘要信息，基于预设的关联规则匹配对应的目标分组，所述摘要信息至少包括商品批号。

8.根据权利要求7所述的方法，其特征在于，所述预设的关联规则的建立过程如下：

采集发票摘要信息样本以及目标分组样本；

基于分词算法对所述发票摘要信息样本进行分词，根据样本数量以及摘要信息的词频，设置最小支持度以及最小置信度；

获取分词处理后的摘要信息分词表，根据所述摘要信息分词表、所述最小支持度、所述最小置信度以及所述目标分组样本获取满足条件的关联规则，将满足条件的关联规则输出为所述预设的关联规则。

9.一种基于电子发票的供应链管理系统，设于供应链管理终端，所述供应链管理终端用于根据供应链中各个上游企业以及各个下游企业之间的票据流通进行供应链管理，所述系统包括：

第一获取单元，用于针对每一上游企业，获取与所述上游企业对应的开票请求终端发送的发票信息，将所述发票信息上传至与第三方票据管理系统对应的开票终端，以便所述开票终端根据所述发票信息生成电子发票；

发送单元，用于获取各个所述电子发票，基于预设的封装规则将每一所述电子发票封装为待验证交易，将各个所述待验证交易发送到区块链中进行存储；

第二获取单元，用于获取与目标下游企业对应的验票请求终端发送的验票请求，根据所述验票请求中的验票信息获取与所述验票信息匹配的目标待验证交易组，所述目标待验证交易组包括目标上游企业对应的至少一个目标待验证交易，所述目标上游企业为所述目标下游企业的至少一级上游企业；

验证单元，用于调用预设的智能合约对所述目标待验证交易组进行验证，如果验证失败则对供应链异常状态进行预警处理。

10.一种供应链管理终端，其特征在于，包括处理器，所述处理器用于执行如权利要求1至8任意一项所述的方法的步骤。