从0到1，学习订单管理体系（来源于网络）

一、概述：

接受客户订单信息，以及仓储管理系统发来的库存信息，然后按客户和紧要程度给订单归类，对不同仓储地点的库存进行配置，并确定交付日期，这样的一个系统称为订单管理系统。订单管理是物流管理的一部分，是电商体系的核心部分，它承载着服务与客户交互的整个过程记录。本文是近段时间的学习和总结，希望通输入-计算-输出的模式，加强对内容的理解。

二、订单系统与其他系统的关系和架构

image

订单系统的作为整个电商体系的中游，对上承接用户信息，将用户信息转化成产品订单，同时管理并跟踪订单数据，对下，与各个系统配合协作，实现整个电商体系的闭环，在整个电商平台起着承上启下的重要地位。

三、订单管理解构：

（一）订单信息

由支付信息、商品信息、订单基本信息、优惠信息、收货信息、用户信息、物流信息和其他信息，这些信息来源于其他系统的信息，一起构成全面的信息记录。

image

（二）订单状态和状态机

订单状态是交易进展的反馈，是订单流程的一个个连接点。不同业务类型的订单状态，例如机票、服务订单、商品服务订单等，和最常见的纯实物商品的订单状态会有所区别，但订单状态总体有以下几种类型：（下图是来源网络）

image

最多 22 列

• 剪切

• 复制

• 粘贴

  请使用 Ctrl+V 粘贴

• 向上插入 1 行

• 向下插入 1 行

• 向左插入 1 列

• 向右插入 1 列

• 插入超链接

• 合并单元格

• 取消合并单元格

• 删除列

• 删除行

• 删除表格

<colgroup><col style="width: 75px;"><col style="width: 113px;"><col style="width: 113px;"><col style="width: 89px;"><col style="width: 113px;"><col style="width: 113px;"></colgroup>
|

订单主状态

|

审核状态

|

付款状态

|

物流状态

|

履行状态

|

结算状态

|
| |

待审核

审核中

审核通过/审核失败

|

待支付

支付中

支付成功/支付失败

|

待发货

运输中

代签收

已签收/拒签收

已丢单

|

未履行

履行中

履行成功/履行失败

|

待结算

结算中

结算成功/结算失败

|

状态机是订单状态逻辑的工具。状态机可以分为三个要素：现状、动作、次态。

·现状：指当前所处的状态；

·动作：指状态发生转变的操作；

·次态：动作满足后新产生的状态。

状态机是流程的一种补充，其设计也需要结合平台的实际业务场景，以一个商品订单为例：

image

通常，订单的状态的变更伴还随着订单的推送，涉及到的信息包括：

· 推送对象（用户，商家，仓库）

**· **推送方式（站内消息，push，短信，微信模板消息）

· 推送节点（状态机变更）

（三）订单流程

订单流程是指整个订单从产生到完成的整个流转过程。不同的服务模式对应的订单流程都会根据自身的业务进行调整。从典型的电商订单流程切入，拆解为正向流程、逆向流程

1、正向流程

（1）正常下单：下图为订单完整的的流程：

image

（2）拆单流程：拆单，指客户在下单之后，出于发货和结算的角度，对订单进行拆分。

1）拆单的影响因素：

商家：商品不属于同一家商家，需将订单拆分，便于商家的结算、和发货管理。如淘宝多家商品一起结算，会以商家为基线，拆成不同的订单。

仓库：同一商家，不同仓库，发货配送不同，商品物流信息和到货时间不一致。

品类：产品为特殊品类的，如易碎品，需与其他商品分开包装。

物流：不同的物流公司对单个包裹的重量或体积有特殊要求，需要根据sku的毛重和体积计算包裹重量和体积，超出物流公司限制的也需要拆单。

2）拆分规则：

①父单必须拆净，即父单商品数量等于子单商品数量之和

②父单商品金额、运费、支付金额、虚拟币金额、优惠金额要与子单金额相等

③子单实付大于0

④第三方订单按商家维度拆分、自营（不包括虚拟和厂商直送、线下交易等特殊订单类型）按库房维度拆分

⑤赠品不分摊优惠，延保必须跟主单

3）拆单流程图：

image

2、逆向流程：在订单生成之后，订单在各个状态的流转过程中，都可能会出现逆向流程，分为仅退款和退货退款。在不同节点发生，系统的处理方式不同。

image

(1)待付款取消订单

当用户提交订单后主动取消订单或者用户超时未支付时，订单的状态变更为“已取消”，无需经过客服审核。

(2)待发货取消订单

当订单在“待发货”状态时，用户申请取消订单，如下图所示，由于用户在支付订单后，发货单可能已经推送至仓储系统，甚至已经交接发货，状态未及时回传更新。为避免货款两失要进行订单拦截，若拦截失败，则拒绝“取消订单”申请，回复原因“订单已库”；若拦截成功，“取消订单”申请通过，进入退款流程，同时通知调度中心该订单取消，订单进入返库流程。

image

(3)待确认收货/交易完成

在待确认收货中申请退款，一般商品已经进入物流配送环节到达用户手中，此时的逆流程分为退款/退货退款，下面分别就两种情况进行说明：

1)退款

这种场景一般是物件损坏、快递丢件、错发漏发。

image

2)退货退款

在待收货或者交易完成后的退款，流程如下，卖家同意退款前的流程与退款的流程类似，但在同意退款后，买家端会看到卖家的退货信息，包括姓名、地址、电话等退货相关信息，用户在寄出商品后，商家会进行验收确认，确认无误后会进行退款，如果在验收环节有问题的话，一般会走线下协商，要么将货品发回给用户，要么退部分款项。

image

以上为主要的售后场景流程，但订单的逆向流程复杂多样，需要兼顾业务场景。期间涉及到与仓储系统、财务系统的配合协作。保证数据变化的可追溯性，每一次数据的变化，都不能直接在原数据上直接修改，而需要生成相应单据凭证。

（四）订单数据

订单沉淀下的数据和信息，对平台的运营和产品的改善起着关键的指导作用。可分为常规统计和流量分析统计。

（1）常规统计：常规统计，一般指财务数据方面的统计，主要包括销售额、毛利、成本、纯利

润、客单价等。

（2）流量分析统计：侧重于指导平台运营的数据，如访客数、浏览量、支付转化率等。在订单流量分析中又分为三个维度，分别从订单交易纬度、商品纬度、订单来源等三方面来分析。

1）订单交易维度：订单销售额、订单数量、客单价、下单用户数与支付用户数、订单金额分布梯度、地域分布。

2）商品维度:被下单商品数、被支付商品数、被访商品数、商品收藏次数、商品销量统计、

3)订单来源：订单的来源媒介和用户端，记录每个订单的产生流程，追踪订单来源。

四、总结

订单系统是看似简单，实际上是一个逻辑复杂的系统，具体的流程设计，应与自身的业务紧密结合，同时涉及到与其他各大系统的紧密配合，需要不断的去优化，让各个系统的配合更加流畅多样。经过这一段时间的学习，也只能了解到一些基本的要素和流程，希望通过整理和输入，帮助自己更好的学习和掌握，也希望对他人有所帮助。

参考资料：

《电商经理产品宝典》

《订单系统：从0到1设计思路》