售后服务数据处理方法、装置、计算机设备及存储介质

摘要

本申请涉及一种售后服务数据处理方法、装置、计算机设备及存储介质，从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；从所述用户收货视频信息中获取收货信息；获取订单信息；根据所述订单信息，从所述区块链上获取发货信息；根据所述订单信息、收货信息及发货信息，进行售后服务数据处理。本申请能实现自动的售后服务数据处理，且可靠性较高。

说明书

技术领域

本申请涉及区块链技术领域，尤其涉及一种售后服务数据处理方法、装置、计算机设备及存储介质。

背景技术

随着互联网的发展，网络购物也得到了长足的发展，在人们的生活中占据了越来越重要的地位。

和传统的实体购物相比，网络购物依托网络及物流进行，使得售后服务较为不便。而电商的售后服务，需要占用大量资源。售后服务实际上是售后服务数据的处理过程，包括售后服务数据的审核，基于售后服务数据的相应的补偿、处罚等。整个售后服务数据处理过程可以为：用户申请售后服务，电商端根据用户的申请，获得售后服务相关的各种数据，审核售后服务数据，在审核通过后或审核不通过时，进行相应的售后服务数据处理。现有技术中，售后服务数据的处理需要大量人力的参与，还涉及多个环节，耗时耗力；且现有技术中的售后服务数据在获取、传递过程中有可能被篡改或丢失，导致错误。

可见，现有技术中的售后服务数据处理方法耗时耗力，过程繁琐复杂，且数据可靠性较差。

发明内容

本申请提供了一种售后服务数据处理方法、装置及计算机设备及存储介质，基于区块链，能实现自动的售后服务数据处理，且可靠性较高。

第一方面，本申请提供了一种售后服务数据处理方法，所述方法包括：

从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；

从所述用户收货视频信息中获取收货信息；

获取订单信息；

根据所述订单信息，从所述区块链上获取发货信息；

根据所述订单信息、收货信息及发货信息，进行售后服务数据处理。

本申请实施例中，所述获取订单信息，包括:

从所述区块链上获取订单信息，或

从所述区块链上获取物流信息，根据所述物流信息获取所述订单信息；

其中，所述订单信息由用户端上传至所述区块链，或由商户端上传至所述区块链，所述物流信息由物流端上传至所述区块链。

本申请实施例中，从所述区块链上获取发货信息，包括：

从所述区块链上获取发货视频信息；

根据所述发货视频信息，获取所述发货信息；

其中，所述发货视频信息由商户端上传至所述区块链。

本申请实施例中，所述订单信息包括订单物品种类、每个种类的订单数量以及每件货物的订单状态，所述订单状态包括损坏、未损坏、全新及非全新；

所述发货信息包括发货物品种类、每个种类的发货数量以及每件货物的发货状态，所述发货状态包括损坏、未损坏、全新及非全新；

所述根据订单信息、收货信息和发货信息，进行售后服务数据处理，包括：

若所述发货信息和订单信息不一致，则进行第一售后服务数据处理；

若所述发货信息和订单信息一致，则根据所述发货信息和对应的收货信息进行售后服务数据处理；

其中，所述发货信息和订单信息不一致，包括以下不一致中的任意一种或多种：发货物品种类与订单物品种类不一致，每个种类的发货数量与每个种类的订单数量不一致，以及每件货物的发货状态与每件货物的订单状态不一致；

所述发货信息和订单信息一致，包括：发货物品种类与订单物品种类一致、每个种类的发货数量与每个种类的订单数量一致，和每件货物的发货状态与每件货物的订单状态一致。

本申请实施例中，所述收货信息包括收货物品种类、每个种类的收货数量以及每件货物的收货状态，所述收货状态包括损坏、未损坏、全新及非全新，

所述根据发货信息和收货信息进行售后服务数据处理，包括：

若所述发货信息和对应的收货信息一致，则进行第二售后服务数据处理，

若所述发货信息和对应的收货信息不一致，则进行第三售后服务数据处理；

其中，所述发货信息和收货信息一致，包括：所述收货种类与发货种类一致、每个种类的收货数量与每个种类的发货数量一致，和每件货物的收货状态与每件货物的发货状态一致；

所述发货信息和收货信息不一致，包括：

所述收货种类与发货种类不一致，

所述收货种类与发货种类一致，但是每个种类的收货数量与每个种类的发货数量不一致，

所述收货种类与发货种类一致，每个种类的收货数量与每个种类的发货数量一致，但每件货物的收货状态与每件货物的发货状态不一致。

本申请实施例中，所述进行第一售后服务数据处理，包括：

从商户账户将第一数量的电子货币转移至用户账户；

所述进行第二售后服务数据处理，包括：

结束所述售后服务数据处理；

所述进行第三售后数据处理，包括：

从所述商户账户将第二数量的电子货币转移至所述用户账户。

本申请实施例中，所述从商户账户将第二数量的电子货币转移至用户账户之后，所述方法还包括：

从所述区块链获取物流信息；

根据所述物流信息获取不一致的成因信息；

若所述不一致的成因信息为物流损坏，则从物流账户将第三数量的电子货币转移至所述商户账户，

若所述不一致的成因信息为物流拆单，则在合单后，根据所述发货信息和合单后的收货信息进行售后服务数据处理。

本申请实施例中，所述根据发货信息和合单后的收货信息进行售后服务数据处理，包括：

若所述发货信息和所述合单后的收货信息一致，则从所述用户账户将第二数量的电子货币转移至所述商户账户；

若所述发货信息和所述合单后的收货信息不一致，则向所述商户端和用户端反馈拆单信息，以使所述商户端和用户端根据所述反馈信息决定是否继续订单，

若所述订单继续，则将第三数量的电子货币从所述用户账户转出，并将第四数量的电子货币转入所述商户账户。

本申请实施例中，所述从区块链获取物流信息，包括：

从所述区块链获取物流视频信息；

根据所述物流视频信息获取所述物流信息；

其中，所述物流视频信息由所述物流端上传至所述区块链。

第二方面，提供了一种售后服务数据处理装置，所述装置包括：

视频获取单元，用于从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；

信息获取单元，用于从所述用户收货视频信息中获取收货信息；

订单获取单元，用于获取订单信息；

所述信息获取单元还用于根据所述订单信息，从所述区块链上获取发货信息；

处理单元，用于根据所述订单信息、收货信息和发货信息，进行售后服务数据处理。

第三方面，提供了一种电子设备，包括：处理器、通信组件、存储器和通信总线，其中，处理器、通信组件和存储器通过通信总线完成相互间的通信；所述存储器，用于存储计算机程序；所述处理器，用于执行所述存储器中所存储的程序，实现上述售后服务数据处理方法。

第四方面，提供了一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述的售后服务数据处理方法。

本申请提供了一种售后服务数据处理方法，在本申请的方法中，用户在收到货物之后，将用户收货视频信息传至区块链，从区块链上自动获取收货信息，将收货信息和发货信息相对比，进行售后服务数据处理，从而实现了自动的售后服务数据处理，减少了售后服务数据处理的环节，节约了成本，提高了售后服务数据处理的速度。此外，本申请中，收货信息和发货信息均从区块链上获取，由于区块链的特性，这些信息会在区块链上存证，用来进行售后服务的数据处理，可靠性高。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中基于区块链的查询系统结构示意图；

图2为本申请实施例中区块链结构示意图；

图3为本申请实施例中区块链网络功能结构示意图；

图4为本申请实施例中售后服务数据处理方法的流程图；

图5为本申请实施例中售后服务数据处理方法的流程图；

图6为本申请实施例中售后服务数据处理装置的结构示意图；

图7为本申请实施例中电子设备结构示意图。

具体实施方式

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

在以下的描述中，涉及到“一个具体实施例”，其描述了所有可能实施例的子集，但是可以理解，“一个具体实施例”，其描述了所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

除非另有定义，本文所使用的所有的技术的科学技术与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

在对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

(1)交易(Transaction)，等同于计算机术语“事务”，交易包括了需要提交到区块链网络执行的操作，并非单指商业语境中的交易，鉴于在区块链技术中约定俗称地使用了“交易”这一术语，本申请实施例遵循了这一习惯。

例如，部署(Deploy)交易用于向区块链网络中的结点安装指定的智能合约并准备好被调用；调用(Invoke)交易用于通过调用智能合约在区块链中追加交易的记录，并对区块链的状态数据库进行操作，包括更新操作(包括增加、删除和修改状态数据库中的键值对)和查询操作(即查询状态数据库中的键值对)。

(2)区块链(Blockchain)，是由区块(Block)形成的加密的、链式的交易的存储结构。

(3)区块链网络(Blockchain Network)，通过共识的方式将新区块纳入区块链的一系列的节点的集合。

(4)账本(Ledger)，是区块链(也称为账本数据)和与区块链同步的状态数据库的统称。其中，区块链是以文件系统中的文件的形式来记录交易；状态数据库是以不同类型的键(Key)值(Value)对的形式来记录区块链中的交易，用于支持区块链中交易的快速查询。

(5)智能合约(Smart Contracts)，也称为链码(Chaincode)或应用代码，部署在区块链网络的节点中的程序，节点执行接收的交易中所调用的智能合约，来对状态数据库的键值对数据进行更新或查询操作。

(6)共识(Consensus)，是区块链网络中的一个过程，用于在涉及的多个节点之间对区块中的交易达成一致，达成一致的区块将被追加到区块链的尾部，实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Proof of Stake)、股权授权证明(DPoS，Delegatd Proof-of-Stake)、消逝时间量证明(PoET，Proof of Elapsed Time)等。

下面说明本申请实施例，提供的区块链网络的示例性应用，如图1所示，图1是本申请实施例提供的售后维权系统示意图，包括区块链网络101、共识节点102，认证中心103、业务主体104、客户端节点104-1，业务主体105和客户端节点105-1，下面分别进行说明：

区块链网络101的类型是灵活多样的，例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例，任何业务主体的电子设备例如用户终端和服务器，都可以在不需要授权的情况下接入区块链网络101；以联盟链为例，业务主体在获得授权后其下辖的电子设备(例如终端/服务器)可以接入区块链网络101，此时，成为区块链网络101中的客户端节点。

在一些实施例中，客户端节点104可以只作为区块链网络101的观察者，即提供支持业务主体发起交易(例如，用于上链存储数据或查询链上数据)功能，对于区块链网络101的共识节点102的功能，例如排序功能、共识服务和账本功能等，客户端节点可以缺省或者有选择性(例如，取决于业务主体的具体业务需求)地实施。从而，可以将业务主体的数据和业务处理逻辑最大程度迁移到区块链网络101中，通过区块链网络101实现数据和业务处理过程的可信和可追溯。

区块链网络101中的共识节点接收来自不同业务主体，例如图1中示出的业务主体104的客户端节点104-1提交的交易，执行交易以更新账本或者查询账本，执行交易的各种中间结果或最终结果可以返回业务主体104的客户端节点104-1中显示。

例如，客户端节点104-1可以订阅区块链网络101中感兴趣的事件，例如区块链网络101中特定的组织/通道中发生的交易，由共识节点102推送相应的交易通知到客户端节点104-1，从而触发客户端节点104-1中相应的业务逻辑。

作为区块链的示例，如图2所示，图2是本申请实施例提供的区块链网络101中区块链的结构示意图，每个区块的头部既可以包括区块中所有交易的哈希值，同时也包含前一个区块中所有交易的哈希值，新产生的交易的记录被填充到区块并经过区块链网络中节点的共识后，会被追加到区块链的尾部从而形成链式的增长，区块之间基于哈希值的链式结构保证了区块中交易的防篡改和防伪造。

下面说明本申请实施例提供的区块链网络的示例性的功能架构，如图3所示，图3是本申请实施例提供的区块链网络101的功能架构示意图，包括应用层301、共识层302、网络层303、数据层304和资源层305，下面分别进行说明：

应用层301封装了区块链网络能够实现的各种业务，包括交易的溯源、存证和验证等。

共识层302封装了区块链网络101中的节点102对区块达成一致性的机制(即共识机制)、交易管理和账本管理的功能。共识机制包括POS、POW和DPOS等共识算法，支持共识算法的可插拔。交易管理用于验证节点101接收到的交易中携带的数字签名，验证业务主体104的身份信息，并根据身份信息判断确认其是否具有权限进行交易(从业务主体身份管理读取相关信息)；对于获得接入区块链网络101的授权的业务主体而言，均拥有认证中心颁发的数字证书，业务主体利用自己的数字证书中的私钥对提交的交易进行签名，从而声明自己的合法身份。账本管理用于维护区块链和状态数据库。对于取得共识的区块，追加到区块链的尾部；执行取得共识的区块中的交易，当交易包括更新操作时更新状态数据库中的键值对，当交易包括查询操作时查询状态数据库中的键值对并向业务主体的客户端节点返回查询结果。支持对状态数据库的多种维度的查询操作，包括：根据区块序列号(例如交易的哈希值)查询区块；根据区块哈希值查询区块；根据交易序列号查询区块；根据交易序列号查询交易；根据业务主体的账号(序列号)查询业务主体的账号数据；根据通道名称查询通道中的区块链。

网络层303封装了点对点(P2P，PointtoPoint)网络协议、数据传播机制和数据验证机制、接入认证机制和业务主体身份管理的功能。

其中，P2P网络协议实现区块链网络101中节点102之间的通信，数据传播机制保证了交易在区块链网络101中的传播，数据验证机制用于基于加密学方法(例如数字证书、数字签名、公/私钥对)实现节点102之间传输数据的可靠性；接入认证机制用于根据实际的业务场景对加入区块链网络101的业务主体的身份进行认证，并在认证通过时赋予业务主体接入区块链网络101的权限；业务主体104身份管理用于存储允许接入区块链网络101的业务主体104的身份、以及权限(例如能够发起的交易的类型)。

数据层304封装了实现账本的各种数据结构，包括以文件系统中的文件实现的区块链，键值型的状态数据库和存在性证明(例如区块中交易的哈希树)。

资源层305封装了实现区块链网路101中的各个节点102的计算资源、存储资源和通信资源。

基于上述架构，本申请实施例提出了以下的实现方式。

本申请实施例提供了一种售后服务方法，图4所示为本申请实施例的售后服务方法的流程图，如图4所示，所述方法包括：

步骤410，从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；

步骤420，从所述用户收货视频信息中获取收货信息；

步骤430，获取订单信息；

步骤440，根据所述订单信息，从所述区块链上获取发货信息；

步骤450，根据所述订单信息、收货信息及发货信息，进行售后服务数据处理。

本申请实施例中，用户在收到货物之后，将用户收货视频信息传至区块链，从区块链上自动获取收货信息，将收货信息和发货信息相对比，从而进行售后服务数据处理，从而实现了自动的售后服务数据处理，减少了售后服务数据处理的环节，节约了成本，提高了售后服务数据处理的速度。此外，本申请中，收货信息和发货信息均从区块链上获取，由于区块链的特性，这些信息会在区块链上存证，用来进行售后服务数据处理，可靠性高。

本申请实施例中，从用户收货视频信息中获取收货信息，可以采用现有技术中的任一种方法，例如AI视频分析方法，或图像识别技术。图像识别技术可以是采用获取每帧的图片方式，用图像识别，提取关键特征的方法。本申请实施例中，还可以采用其他方法，在此不再赘述。

本申请实施例中，所述获取订单信息，包括:

从所述区块链上获取订单信息，或

从所述区块链上获取物流信息，根据所述物流信息获取所述订单信息；

其中，所述订单信息由用户端上传至所述区块链，或由商户端上传至所述区块链，所述物流信息由物流端上传至所述区块链。

订单信息可以是用户端直接上传至区块链，或者可以是商户端直接上传至区块链的；或者可以是根据物流信息获取的。

物流信息记录了物品的发货地、发货时间、收货时间、收货地点以及整个物流的路径等，从上述信息中可以确定收货视频对应的订单信息。

本申请实施例中，步骤420中，从所述区块链上获取发货信息，包括：

从所述区块链上获取发货视频信息；

根据所述发货视频信息，获取所述发货信息；

其中，所述发货视频信息由商户端上传至所述区块链。

商户在发货时，会将装箱、包装视频主动上传至区块链存证，便于后续的售后服务数据处理。

本申请实施例中，所述订单信息包括订单物品种类、每个种类的订单数量以及每件货物的订单状态，所述订单状态包括损坏、未损坏、全新及非全新，

所述发货信息包括发货物品种类、每个种类的发货数量以及每件货物的发货状态，所述发货状态包括损坏、未损坏、全新及非全新；

步骤450中，所述根据订单信息、收货信息和发货信息，进行售后服务数据处理，包括：

若所述发货信息和订单信息不一致，则进行第一售后服务数据处理；

若所述发货信息和订单信息一致，则根据所述发货信息和对应的收货信息进行售后服务数据处理；

其中，所述发货信息和订单信息不一致，包括以下不一致中的任意一种或多种：发货物品种类与订单物品种类不一致，每个种类的发货数量与每个种类的订单数量不一致，以及每件货物的发货状态与每件货物的订单状态不一致；

所述发货信息和订单信息一致，包括：发货物品种类与订单物品种类一致、每个种类的发货数量与每个种类的订单数量一致，和每件货物的发货状态与每件货物的订单状态一致。

本申请实施例中，进行售后服务数据处理首先要判断订单信息和发货信息是否一致，如果不一致，说明商户端发货有错误，用户端需要售后服务数据处理。如果一致，则根据收货信息和发货信息来进行售后服务数据处理。

本申请实施例中，订单状态和发货状态都可以包括损坏、未损坏、全新及非全新，是因为某些特定的应用场景中，例如该订单是物品返修订单，是由物品使用者发回到厂家或商家的订单，此时订单里的物品可能是损坏的，是非全新的。在另一种应用场景中，例如二手商品出售，物品也是非全新的。

本申请实施例中，订单信息中还可以包括订单标识，例如订单号，用来区别不同的订单。同样的，发货信息和收货信息中也包括发货标识和收货标识，和对应的订单相匹配。

本申请实施例中，所述根据发货信息和收货信息判断是否需要售后服务，包括：

所述根据发货信息和收货信息进行售后服务数据处理，包括：

若所述发货信息和对应的收货信息一致，则进行第二售后服务数据处理，

若所述发货信息和对应的收货信息不一致，则进行第三售后服务数据处理；

其中，所述发货信息和收货信息一致，包括：所述收货种类与发货种类一致、每个种类的收货数量与每个种类的发货数量一致，和每件货物的收货状态与每件货物的发货状态一致；

所述发货信息和收货信息不一致，包括：

所述收货种类与发货种类不一致，

所述收货种类与发货种类一致，但是每个种类的收货数量与每个种类的发货数量不一致，

所述收货种类与发货种类一致，每个种类的收货数量与每个种类的发货数量一致，但每件货物的收货状态与每件货物的发货状态不一致。

本申请实施例中，所述进行第一售后服务数据处理，包括：

从商户账户将第一数量的电子货币转移至用户账户；

所述进行第二售后服务数据处理，包括：

结束所述售后服务数据处理；

所述进行第三售后数据处理，包括：

从所述商户账户将第二数量的电子货币转移至所述用户账户。

本申请实施例中，第一类售后服务数据处理，包括从商户账户将第一数量的电子货币转移至用户账户，具体可以是由商户端按照第一数量的金额赔付用户；第二类售后服务包括结束所述售后服务数据处理，即不需要其他的售后服务了；第三售后数据处理包括从所述商户账户将第二数量的电子货币转移至所述用户账户，即商户要赔付第二数量的金额给客户。

本申请实施例中，发货信息和订单信息一致的情况下，若所述发货信息和收货信息一致，进行第二售后服务数据处理，即不需要售后服务，此时可以通知用户端、商户端和物流端无需售后服务。本申请实施例中的此处的售后服务指的是针对该订单的发货、到货、运输过程是不需要售后的，但是对于商品本身，如果是在质保期内，还可能有其他售后，例如七天无理由退换货，或其他质量问题退换货，或保质期内的维修等。为便于区分，商品本身质保期内的售后，本申请实施例中称其为运维。在确认不需要售后服务之后，本申请实施例中可以将该订单转至运维端处理。

在商户端发货信息和订单信息一致时，如果发货信息和收货信息不一致，即用户端收到的物品和订单信息不一致，此时也由商户账户将第二数量的电子货币转移至用户账户。

第一数量的电子货币、第二数量的电子货币可以是预先约定的规则中的，预先约定的规则可以是商户端上传至区块链中的，该规则是商户端、用户端和物流端共同认可的，可以是区块链中的共识。

本申请实施例中，所述从商户账户将第二数量的电子货币转移至用户账户之后，所述方法还包括：

从所述区块链获取物流信息；

根据物流信息获取不一致的成因信息；

若所述不一致的成因信息为物流损坏，则从物流账户将第三数量的电子货币转移至所述商户账户，

若所述不一致的成因信息为物流拆单，则在合单后，根据所述发货信息和合单后的收货信息进行售后服务数据处理。

所述根据发货信息和合单后的收货信息进行售后服务数据处理，包括：

若所述发货信息和所述合单后的收货信息一致，则从所述用户账户将第二数量的电子货币转移至所述商户账户；

若所述发货信息和所述合单后的收货信息不一致，则向所述商户端和用户端反馈拆单信息，以使所述商户端和用户端根据所述反馈信息决定是否继续订单，

若所述订单继续，则将第三数量的电子货币从所述用户账户转出，并将第四数量的电子货币转入所述商户账户。

在发货信息和订单信息一致的情况下，发货信息和收货信息应该是一致的，如果不一致，肯定是有原因的。通常发货的商户端和收货的用户端之间是提供物流服务的物流端，因此本申请实施例中，如果发货信息和收货信息不一致，在将商户账户中的电子货币转移至用户账户后，即商户对用户端赔付之后，还会获取物流信息。

本申请实施例中，物流信息也是上传至区块链上的，以保证信息不被篡改。

物流过程中，可能由于暴力运输、暴力分拣、包装不合格、运输车的车祸、不合理保管、运输途中丢失等众多原因，都可能会造成物品的损坏或缺失，从而造成发货信息和收货信息的不一致，本申请实施例中，以上都称为物流损坏，如果不一致的原因是物流损坏，则由物流端承受损失。

物流运输过程中，由于一些特殊原因，例如跨境购物，在入境的时候可能会有海关查验，或者航空运输过程中，因为包裹的体积、重量等不符合航空运输要求，会对物品的包括进行分拆，从而造成发货物品的拆单。本申请实施例中，拆单指的是将一个订单拆分成多个包裹，是将一个订单的数据拆分成多个子订单数据。

实际中，由于购物种类、数量太多，或者由于仓库存货、缺货等原因，在商户端发货时也有可能会对订单对应的货物拆分，分成多个包装，但这种商户端拆分货物，也会对订单拆分。这种应用场景下，商户端对订单、货物的拆分会通知用户端，同时发货信息也会因此而更改，用户端收货后的收货信息也会更改，因此不会影响到是否需要售后服务的结果。例如用户一个订单A购买了二十件B产品，但是由于包装限制，一个包裹中只能装十件B产品，所以在商户端会将订单A拆分为订单A1和订单A2，每一个包裹中装十件B产品。此时，订单分成了两个，订单A1对应的发货包裹B1，订单A2对应的发货包括B2，订单A1中记录是十件B产品，包裹B1对应的发货信息B1中也是十件B1。此时订单信息A1和发货信息B1是一致的，同理，此时订单信息A2和发货信息B2是一致的。

但是物流运输过程中的拆单，即使通知到商户端和用户端，但商户端发货信息是无法更改的，这就导致商户端的发货信息和用户端的收货信息是无法一致的。例如上述实施例中，订单信息是A，发货信息B中均为二十件产品B，但是在物流运输过程中被物流端拆分为订单A11和订单A22，由于物流端拆单是在商户端发货之后的，此时发货信息已经上传至区块链，不可更改，而用户端收货是在物流端拆单之后，用户端收到A11包裹的收货信息与发货信息B是不可能一致的。

针对上述由于物流拆单造成的发货信息和收货信息不一致，可以将物流拆单后的拆单包裹合并后再获取收货信息，再根据合并后的收货信息和发货信息，进行售后服务数据流程，即将上述A11包括的收货信息和A22的收货信息合并，和发货信息B来对比，如果一致，则从所述用户账户将第二数量的电子货币转移至所述商户账户。

用户端收到A11之后，已经由商户账户给用户账户赔付了第二数量的电子货币，用户端收到A22之后合单，合单后的收货信息和发货信息一致，说明用户收到了全部订单的物品，此时需要从用户账户把已经收到的电子货币退回给商户账户。

但是，物流端拆单过程中，有可能遗失拆单后的某一个包裹，也可能两个包裹没有同时送达用户端，且收货时间会相隔很久，此种情况下，是没有办法合单的，由于无法合单，会造成发货信息和收货信息的不一致，此时，则向商户端和用户端反馈拆单信息，以使所述商户端和用户根据所述反馈信息决定是否继续订单，若所述订单继续，即用户端需要等待一段时间但是仍然会收取到拆单后的部分物品，此时将第三数量的电子货币从所述用户账户转出，并将第四数量的电子货币转入所述商户账户。如果用户端或者商户端决定订单不继续，此时拆单后的部分物品会根据预先的预定丢弃，例如生鲜，或者退回商户端，此时会从物流账户转移电子货币至用户账户，即物流端会对用户端进行赔付。

本申请实施例中，第二数量的电子货币和第三约定金额可以一致，或可以不一致；第二数量的电子货币和第四数量的电子货币可以一致，或可以不一致。是否一致，根据用户端、物流端和商户端之间的预设规则确定，即区块链中的共识来决定，例如上述约定金额中可以包括对物流端有惩罚措施，或由于保价后造成的金额不同，或者对用户端由于超时收货的补偿等。

本申请实施例中，在用户端收到的物品和发货物品不一致时，先由商户端对用户端进行赔付，可以提高用户的使用满意度；从商户账户至用户账户进行电子货币的转移之后，会根据物流信息，来获得不一致的原因。针对不同的不一致原因，有不同的处理方式：在原因是物流损坏时，由所述物流账户转移电子货币至商户账户，可以避免商户端的损失；在原因是物流拆单时，可以根据合单后的收货信息来判断是否需要售后服务，根据不同的售后从用户账户中转出的电子货币，和/或转移电子货币至商户账户，从而避免商户端的损失。

本申请实施例的售后服务数据处理方法，可以给用户更好的售后服务体验，还可以避免用户和商户的损失，同时如果发货信息和订单信息不一致而造成的收货信息和发货信息不一致，在不同账户间进行电子货币数据的转移，也可以避免物流商的损失。

本申请实施例中，所述从区块链获取物流信息，包括：

从所述区块链获取物流视频信息；

根据所述物流视频信息获取物流信息；

其中，所述物流视频由物流端上传至所述区块链。

本申请实施例中，物流视频信息也是上传至区块链的，可以固定证据，从而保证售后服务的公正性和可靠性。

图5所示为本申请实施例的售后服务数据处理方法的流程图，如图5所示，所述方法包括：

步骤510，用户收到货物之后，将用户收货视频信息上传至区块链。

步骤520，售后服务数据处理装置从区块链上获取收货视频信息和订单信息，从收货视频信息中获取收货信息，判断订单信息和收货信息是否一致，如果一致，则转至步骤530，如果不一致，则转至步骤570。

步骤530，售后服务数据处理装置从区块链上获取发货视频信息，从发货视频信息中获取发货信息，判断收货种类与发货种类是否一致，如果一致则转至步骤540，如果不一致则转至步骤580。

步骤540，判断每个种类的收货数量与每个种类的发货数量是否一致，如果一致则转至步骤550，如果不一致则转至步骤580。

步骤550，判断每件货物的收货状态与每件货物的发货状态是否一致，如果一致则转至步骤560，如果不一致则转至步骤580。

步骤560，不需要售后服务。

步骤570，从商户账户中转移电子货币至用户账户。

步骤580，从商户账户中转移电子货币至用户账户。从区块链上获取物流视频信息，根据物流视频信息获取物流信息，获取发货信息和收货信息不一致的原因。如果不一致的原因是物流损坏，则转至步骤591，如果不一致的原因是物流拆单，则转至步骤592。

步骤591，从物流账户转移电子货币至商户账户。

步骤592，在合单后，根据合单后的收货信息进行售后服务数据处理。判断发货信息和合单后的收货信息是否一致，如果一致则转至步骤593，如果不一致，则转至步骤591。

步骤593，从用户账户转移电子货币至商户账户。

本申请上述实施例中，并未覆盖到所有售后服务数据处理的流程，只是其中的一部分售后流程的数据处理，其余流程可以参考上述实施例，在此不在赘述。

下面，为了更清楚的说明本申请，首先将智能合约的工作原理进行简单介绍：

构建智能合约：智能合约由区块链内的多个用户共同参与制定，可用于任何用户之间的任何交易。协议当中明确规定了交易双方的权利和义务，开发人员将这些权利和义务以电子化的方式进行编程，代码中包含会触发合约自动执行的条件。

存储智能合约：一旦编码完成，这份智能合约上传至区块链网络上，即全网的每个节点都可以收到这份智能合约。

执行智能合约：智能合约会定期检查是否存在相关事件和触发条件，以满足条件的事件推送到待验证的队列中，区块链上的验证节点先对事件进行签名验证，以确保其有效性，等大多数验证节点对该事件达成共识，智能合约将成功执行，并通知给用户。

本申请实施例中，订单信息、发货视频信息和收货视频信息均上传区块链，订单信息、收货信息、发货信息一致或不一致的判断准则，以及售后服务的具体内容，都可以是区块链中的智能合约。对上述信息的判断，以及售后服务的具体执行，都可以是上述执行智能合约。

本申请实施例中，智能合约可以是区块链中的共识。

本申请实施例还提供了一种售后服务的装置，该装置用于执行上述售后服务的方法，其具体实施可参见方法实施例部分的描述，重复之处不再赘述，如图6所示，该装置主要包括：

视频获取单610，用于从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；

信息获取单元620，用于从所述用户收货视频信息中获取收货信息；

订单获取单元630，用于获取订单信息；

所述信息获取单元610还用于根据所述订单信息，从所述区块链上获取发货信息；

处理单元640，用于根据所述订单信息、收货信息和发货信息，进行售后服务数据处理。

本申请实施例的售后服务数据处理装置，基于区块链自动进行售后服务的数据处理，可靠性高，同时简化了售后数据处理的流程。

基于同一构思，本申请实施例中还提供了一种电子设备，如图7所示，该电子设备主要包括：处理器701、通信组件702、存储器703和通信总线704，其中，处理器701、通信组件702和存储器703通过通信总线704完成相互间的通信。其中，存储器703中存储有可被至处理器701执行的程序，处理器701执行存储器703中存储的程序，实现如下步骤：从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；从所述用户收货视频信息中获取收货信息；获取订单信息；根据所述订单信息，从所述区块链上获取发货信息；根据所述订单信息、收货信息及发货信息，进行售后服务数据处理。

在本申请一个实施例中，电子设备还实现上述方法的步骤，在此不再赘述。

上述电子设备中提到的通信总线704可以是外设部件互连标准(PeripheralComponent Interconnect，简称PCI)总线或扩展工业标准结构(Extended IndustryStandard Architecture，简称EISA)总线等。该通信总线704可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信组件702用于上述电子设备与其他设备之间的通信。

存储器703可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器701的存储装置。

上述的处理器701可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当该计算机程序在计算机上运行时，使得计算机执行上述实施例中所描述售后服务方法，所述收服务方法包括：从区块链上获取用户收货视频信息，所述用户收货视频信息由用户端上传至所述区块链；从所述用户收货视频信息中获取收货信息；获取订单信息；根据所述订单信息，从所述区块链上获取发货信息；根据所述订单信息、收货信息及发货信息，进行售后服务数据处理。

在本申请一个实施例中，计算机可读存储介质还实现上述方法的步骤，在此不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。该计算机可以时通用计算机、专用计算机、计算机网络或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、微波等)方式向另外一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带等)、光介质(例如DVD)或者半导体介质(例如固态硬盘)等。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。