CN112070590A - 一种超市托盘共用*** - Google Patents

Abstract

本发明公开了一种超市托盘共用***，包括专业托盘服务商、上游供应商以及若干超市和配送车辆；流程包括托盘租赁、发货、运输、收货和还盘；同时设计托盘共用的软件***和Web界面，托盘共用的软件***包括的功能模块有登录管理模块、交易管理模块、托盘调度模块和钱包。本发明的超市托盘共用***提高了超市托盘利用率和降低整体成本。

Description

一种超市托盘共用***

技术领域

本发明属于物流应用领域，尤其涉及一种超市托盘共用***。

背景技术

在《物流业发展中长期规划(2014-2020年)》中将开展托盘循环共用作为物流行业的发展重点，且近几年我国分别出台了《物流产业调整与振兴规划》、《商贸物流标准化专项行动计划》和《物流标准化中长期发展规划》等文件推进托盘共用***发展。现如今我国推广托盘循环共用已经有4-5年的时间了，多家企业和城市的试点推广都取得了很好的效果。

国家对超市托盘共用***重视的同时，一些大型超市也开始积极进行托盘共用尝试，并取得了不错的效果，例如沃尔玛在中国尝试推行托盘共用后收货率提高了129％，货物装卸率由原来的一车货需要4小时装卸缩短至半小时，同时配送中心的作业能力得到显著的提升，货损率得到了降低，门店响应时间也由原来的32小时缩短至20小时，门店有货率由原来的95％提高至99％。而华润在进行托盘共用后，配送周转时间降低4-6个小时，整体效率提升了2-3倍以上。因此，托盘共用可以为超市节省收货时间，降低货损，提高装卸效率，降低成本。

虽然一些大型超市积极进行托盘共用尝试并且取得了很好的效果，具有很大的潜力，但现在只有少数超市进行托盘共用，多数超市还只将托盘应用在仓库中，仅仅提高了仓库的周转效率，其中还有只将托盘应用在仓库的装卸环节中，这就导致了托盘应用可以带来的效率大打折扣。因此，为了提高超市的装卸效率、降低成本、降低货损，对超市托盘共用***进行设计具有重要意义。

目前托盘在超市中的共用方式主要是交换模式和转移模式。交换模式是超市接收多少供应商的带货托盘，交付给供应商多少空托盘。转移模式是供应商和超市均在托盘租赁公司注册有账号，用来结算托盘的租金，当托盘运输着货物从供应商运输到超市时，托盘的使用方由供应商转移到超市，托盘租金结算也相应的从供应商转移到超市。

这两种模式在使用过程中，交换模式对于托盘的管理相对简单，不需要在托盘租赁企业拥有账户，在供应商运输货物到达超市时当场完成托盘交换，但是对于供应商而言，一方面运输车辆的利用会出现问题，因为供应商有可能对运输配送车辆有其他的安排，假设供应商将货物运输到超市后，运输车辆要去下一个供应商装货，但是由于超市交换了空托盘这样会导致空托盘占用车辆的运输空间，影响接下来环节的运输工作。另一方面需要供应商和超市拥有一定数量的托盘进行日常的托盘交换工作，而且要求供应商到达超市卸货时当场完成托盘交换，这就要求超市本身购买拥有的托盘数量大于接收的带货托盘数量，在一定程度上造成超市前期投入大，流动资金减少。

转移模式虽然不会影响供应商运输车辆接下来的工作，也不需要超市拥有一定数量的托盘，减少购买托盘资金的投入，但是在转移模式中，供应商会持续送货到超市，短时间内会造成超市内托盘数量快速增加，从而导致托盘数量的积压，来不及消化，假如积累的托盘数量超过需求量就会增加托盘的租赁使用费用，而且还会造成托盘利用率降低，社会资源的浪费。

发明内容

针对上述问题，为提高超市托盘利用率和降低整体成本，本发明提供了一种超市托盘共用***。

本发明的一种超市托盘共用***，主体包括专业托盘服务商、上游供应商以及若干超市和配送车辆；流程包括托盘租赁、发货、运输、收货和还盘，流程具体为：

上游供应商向专业托盘服务商租赁托盘，专业托盘服务商提供空托盘给上游供应商，上游供应商将货物装载至托盘上形成带货托盘运输单元，将带货托盘运输至超市，超市接收带货托盘后托盘处理方式分为三种情况：第一种是超市自身需要使用托盘时，将托盘的租赁方由上游供应商转移至超市；第二种是附近的节点有托盘需求，那么进行托盘再分派；第三种是周围节点没有需求自身同样也不需要则跟专业托盘服务商进行还盘操作。

同时设计托盘共用的软件***和Web界面，托盘共用的软件***包括的功能模块有登录管理模块、交易管理模块、托盘调度模块和钱包。

托盘共用的软件***采用区块链技术设计，即分布式存储。

另外，通过搭建Fabric网络以及利用go语言开发和实现***功能。

本发明与现有技术相比的有益技术效果为：

本发明的超市托盘共用***提高了超市托盘利用率和降低整体成本。

附图说明

图1为本发明超市托盘共用***。

图2为本发明超市托盘共用流程。

图3为本发明超市托盘共用***功能示意图。

图4为本发明超市托盘共用***总体架构。

图5为本发明区块链数据区块形成过程图。

图6为本发明登录注册逻辑。

图7为本发明带货托盘交易逻辑。

图8为本发明空盘交易逻辑1。

图9为本发明空盘交易逻辑2。

图10为本发明调度逻辑。

图11为本发明实施例托盘交易实现结果。

图12为本发明实施例可以查询到进行过的所有托盘交易信息。

图13为本发明实施例能够查询具体的托盘交易信息。

图14为本发明实施例托盘去向查询。

图15为本发明实施例托盘信息查询。

图16为本发明实施例用户账户信息查询。

具体实施方式

下面结合附图和具体实施方法对本发明做进一步详细说明。

本发明的一种超市托盘共用***如图1所示，主体包括专业托盘服务商、上游供应商以及若干超市和配送车辆；流程包括托盘租赁、发货、运输、收货和还盘。如图2所示，流程具体为：

上游供应商向专业托盘服务商租赁托盘，专业托盘服务商提供空托盘给上游供应商，上游供应商将货物装载至托盘上形成带货托盘运输单元，将带货托盘运输至超市，超市接收带货托盘后托盘处理方式分为三种情况：第一种是超市自身需要使用托盘时，将托盘的租赁方由上游供应商转移至超市；第二种是附近的节点有托盘需求，那么进行托盘再分派；第三种是周围节点没有需求自身同样也不需要则跟专业托盘服务商进行还盘操作。

在超市托盘共用***中，用户需要登录***，并且在***中能够对托盘交易进行管理，能够对交易进行查询，能够调度托盘和进行托盘租金结算，***功能如图3所示。

1)登录管理

账户注册，在目前有些应用程序中，用户是可以匿名以游客模式访问***，但是由于超市托盘共用***是仅仅为超市供应链用户服务的，是为了能够追溯托盘交易信息，保证托盘交易信息的可信，以及为了信息安全，用户必须登录注册才能够访问***。

用户登录，用户登录时要输入注册时的密钥就可以登录***。对用户进行验证是需要用户再次输入密钥产生的新地址与之前保存的公钥地址进行对比结果一样即可以访问***。

2)交易管理

在这个超市托盘共用***中的核心就是交易，该***主要的交易是托盘交易。其中托盘交易发起者、交易接收者、发送的托盘数量是发起托盘交易的三个必不可少的要素，通常是由发起者输入发送的托盘数量以及接收者的账户地址后，***会对三要素进行合法性校验，主要是要校验发起者和接收者是***的合法用户，以及校验发送者的交易托盘数量是否超过了发起者现有的托盘存储数量，通过校验后，托盘交易发起者会对交易进行数字签名，然后通过点对点网络广播到***中。

交易查询，在***中可以对托盘交易进行查询。

3)托盘调度

在超市托盘共用***中各个节点之间可以进行托盘调度，某一节点A当托盘现有量少于托盘需求预测量时，节点A发布托盘租赁请求，通过托盘共用***验证后，通过点对点网络广播到***各节点中，***匹配附近节点，假设附近节点的存储托盘数量大于自身节点的托盘需求量且大于部分大于等于节点A的托盘调度量，则附近节点进行托盘再分派，由附近节点发起托盘交易，节点A接收交易，配送车辆提供运输服务。假设附近节点均不符合调度需求，那么***通知托盘租赁企业发起托盘交易，由节点A接收接收交易，配送车辆提供托盘运输服务。

4)钱包管理

在本***中的托盘均来自于托盘租赁企业，需要对托盘进行租金支付，以及对于提供托盘调度服务的配送车辆进行服务费用支付。

超市托盘共用***设计：

为了满足超市托盘共用***信任、数据真实，数据可追溯以及分布式存储的需求，本发明的超市托盘共用***采用区块链技术来设计，区块链技术具有去中心化、不可篡改、安全可靠等特点，实质上是分布式存储账本，***总体架构如图4所示。

为实现超市托盘共用***中的链式结构存储，区块就是链式存储结构中的数据元素，数据区块的结构包括区块头和区块体，数据区块对应类应包含相关信息，并能够实现创建新区块、添加有效数据、校验数据、校验Merkle根等功能。在超市托盘共用***中，数据区块形成的过程如下。

如图5所示，当前区块的前一区块是父块，一个区块包括区块头和区块体，区块头记录区块的元信息，包含当前区块的版本号、时间戳、随机数、Merkle等。其中前一个区块地址是父块区块头数据通过hash算法生成的hash值。区块体记录一定时间内所发生的交易数据，hash形成过程，区块体中通过哈希算法把区块中的交易信息进行加密，通过加密后的交易信息被压缩成一串数字和字母组成的散列字符串。一个区块可以有多个交易信息，通过hash算法对交易信息加密，不断进行hash计算，两两hash计算生成Merkle存入区块头中。

本发明设计的超市托盘共用***应用对客户端发出的托盘交易请求、调度请求、转账等要求中，假设超市托盘共用***中具有N-1个从节点，一个主节点O，从节点根据加入的顺序排序为1.2....N-1。根据实用拜占庭共识算法，最多能容忍的“内奸节点”或者“错误节点”为(N-1)/3个。在不同的用户在客户端向主节点发起托盘交易、托盘调度、租金转账和托盘查询等请求时，主节点接收客户端的请求，并且对请求进行排序分配序列号，主节点将客户端的请求序列号广播给从节点，从节点收到主节点分配的序列并且节点间相互确认消息，如果有一个节点是内奸节点，则不会跟其他节点进行相互确认，之后各个节点对视图内的请求和序列号进行验证，进行Commit消息广播。最后各个节点执行请求并将结果进行回执给客户端，客户端在一段时间内收到F+1个回执消息就可以将结果作为最终结果。

***业务逻辑

本发明的***是基于Fabric进行设计的，在超市托盘共用***中要实现托盘交易，托盘信息查询以及托盘调度的需求，实现这些需求的关键是智能合约，而智能合约是根据实际应用场景的业务逻辑来开发的，所以超市托盘共用***中业务逻辑的设计是实现超市托盘共用***的基础。

登录/注册业务逻辑

为了保证超市托盘共用***用户互相信任，超市托盘共用***只有与超市有配送业务往来的供应商以及超市自身的配送中心能够参与到本***中，并且为保证托盘共用结果可追溯，本***只有供应商和超市配送中心注册后才能参与到超市托盘共用中。每个用户在注册时会产生唯一的私钥、公钥以及地址，私钥主要是用来对发起的交易进行数字签名，公钥是用来对信息进行加密，区块链地址用来对交易记录进行追溯。公钥和区块链地址是通过私钥进行计算得来的，但是公钥和区块链不能反推的到私钥，即区块链使用的是非对称加密技术，区块链地址、公钥与私钥都是唯一的。每个账户的登录/注册流程如图6。

交易逻辑

在超市托盘共用***中的核心是托盘交易，在超市托盘交易中主要是指的带货托盘和空托盘在两个不同节点之间的移动。带货托盘的交易是由节点根据运输货物的需求将托盘交易给接收货物即接收托盘的节点。具体的交易流程如图7。由图7带货托盘的交易流程图可知，在超市托盘共用***中带货托盘交易主要涉及的用户节点主要为供应商节点、配送车辆和超市，带货托盘由上游供应商发往超市，所以由供应商发起托盘交易，超市托盘共用***判断是否符合交易条件即供应商中是否具有足够托盘数量进行托盘交易，超市接收交易，配送车辆根据交易提供服务，最后由超市托盘共用***确认交易。

如图8，当超市节点和供应商节点有托盘租赁需求时，由超市、供应商节点发布租赁需求，超市托盘共用***判断就近满足托盘需求的节点，由就近能满足托盘租赁需求的节点发起托盘交易，超市托盘共用***验证交易以及确认交易，配送车辆根据交易提供服务。

如图9，当供应商或超市节点有还盘需求时，有两种情况，一是附近的***用户有托盘需求且供应商或超市节点能满足附近用户托盘需求，由超市或供应商发起托盘交易，附近用户接收交易，超市托盘共用***验证和确认交易，配送车辆根据交易提供服务。二是附近用户没有托盘需求或者不满足附近用户的托盘需求，就只能将托盘归还至托盘租赁企业，由托盘租赁企业接收交易。

调度逻辑

在超市托盘共用***中，核心是托盘交易，但是要形成托盘的循环共用，托盘调度功能必不可少，在超市托盘共用***中，当***用户出现托盘需求或者还盘需求时，需要进行托盘调度，根据前面章节超市托盘共用调度研究中的调度流程设计调度逻辑，调度逻辑如图10所示。由图10可知，超市托盘共用涉及的主体主要是托盘需求方、附近节点以及专业托盘服务商，满足托盘需求方需求的用户可能是附近节点也可能是专业托盘服务商，根据就近原则选择满足托盘需求的用户发起托盘交易，超市托盘共用***验证交易，托盘需求方接收交易，配送车辆提供服务，最终确认交易完成调度。

部分功能实现

基于超市托盘共用***总体架构、***需求以及对业务逻辑设计的基础上，对超市托盘共用***的部分原型进行开发。超市托盘共用***的开发主要分为两部分，一是超级账本Fabric搭建，二是web客户端开发。

在Fabric中，智能合约就是链码，链码在Fabric中分为***链码和用户链码，而根据现实场景定义业务逻辑的链码通常指的是用户链码。链码是用来访问超级账本的方法，是用来实现规定接口的代码。应用层通过调用链码来访问和管理账本，链码与链码在有权限的情况下也可以互相调用。由于GO是Fabric的官方语言，所以本文选用go语言进行链码开发。

由于电科信链智能合约底层架构是Fabric，并且使用的共识机制是PBFT，与本文的Fabric底层环境以及调用的PBFT共识机制一致，以及在云环境中搭建的Fabric环境不能直观地展示托盘交易以及托盘查询功能，所以本文将链码部署在电科信链智能合约快速开发平台上进行实现。

(1)带货托盘交易实现

将根据带货托盘的交易逻辑开发且定义了托盘的数据结构的链码部署到平台上，可以实现信息查询、托盘交易功能。根据托盘交易逻辑，在超市托盘共用***中是将托盘作为交易Token，直接进行用户间的托盘交易，在带货托盘交易流程中，托盘是由供应商用户交易给超市，初始化两个用户owner1和owner2，带货托盘交易实现结果如图11所示。

如图11所示，通过invoke函数调用链码，托盘实现了由owner1到owner2之间的流转，实现了一次交易过程，即实现了ID为“tray1”的托盘由owner1交易到owner2。

(2)交易信息查询

在***通过调用链码实现托盘交易后，***会产生交易日志，也就是交易记录，能够对交易信息进行查询，实现***的查询功能中的交易查询功能，查询结果如图12-13所示。

在图12和图13中，图12可以查询到进行过的所有托盘交易信息，图13能够查询具体的托盘交易信息，查询结果包括具体交易信息，其中包括交易Hash、交易时间、交易结果以及所在区快的具体信息，其中交易hash是通过对交易信息进行加密计算得到的hash值，交易时间是交易发生的时间。

(3)托盘溯源

同时在进行托盘交易后，对于托盘的去向通过调用链码，也能够进行查询，如图14所示。在图中，通过query函数调用链码，可以得到ID为tray1的托盘，托盘流转从owner1流向owner2。实现对托盘流向查询，即能够对托盘进行溯源。

(4)托盘信息查询

链码中定义托盘数据结构，链码部署后，初始化数据，可以通过query函数调用链码，进行托盘信息查询，查询结果如图15所示。由图15，可以看出定义的托盘信息，托盘的ID、托盘租赁价格以及托盘的所有者，实现托盘信息查询功能。

(5)用户账户信息查询

在链码中托盘数据结构定义托盘的所有者，以及定义了用户的id、用户姓名，通过query函数调用链码，对Owner1用户进行查询，能够实现对用户账户信息的查询功能。由图16所示，实现用户账户信息查询，能够查询到owner1的id，对应的现实用户name，以及能够查询用户账户中的托盘，实现账户用户信息查询功能。

Claims (3)

1.一种超市托盘共用***，其特征在于，主体包括专业托盘服务商、上游供应商以及若干超市和配送车辆；流程包括托盘租赁、发货、运输、收货和还盘，流程具体为：

上游供应商向专业托盘服务商租赁托盘，专业托盘服务商提供空托盘给上游供应商，上游供应商将货物装载至托盘上形成带货托盘运输单元，将带货托盘运输至超市，超市接收带货托盘后托盘处理方式分为三种情况：第一种是超市自身需要使用托盘时，将托盘的租赁方由上游供应商转移至超市；第二种是附近的节点有托盘需求，那么进行托盘再分派；第三种是周围节点没有需求自身同样也不需要则跟专业托盘服务商进行还盘操作；

同时设计托盘共用的软件***和Web界面，托盘共用的软件***包括的功能模块有登录管理模块、交易管理模块、托盘调度模块和钱包。

2.根据权利要求1所述的一种超市托盘共用***，其特征在于，所述托盘共用的软件***采用区块链技术设计，即分布式存储。

3.根据权利要求1所述的一种超市托盘共用***，其特征在于，通过搭建Fabric网络以及利用go语言开发和实现***功能。

Images