一、主流电商产品的订单状态
淘宝的订单状态主要有待付款、待发货、待收货、待评价、已关闭、以及退款中。
image
京东的订单状态主要有待付款、待收货、已完成、已取消等。
有赞的订单状态主要有待付款、待接单、待发货、待收货等。
image
二、最常见的订单状态
根据以上平台以及大家平常的网购经验，不难理解电商平台都会包含以下5种状态。
-
待付款：代表买家下单了但是还没有付款。
-
待发货（同待接单）：代表买家付款了卖家还没有发货。
-
已发货（同待收货）：代表卖家已经发货并寄出商品了。
-
已完成（同待评价）：代表买家已经确认收到货了。
-
已关闭（同已取消）：代表订单过期了买家也没付款、或者卖家关闭了订单。
三、主流订单状态变化
知道了订单状态还不够，PM还需要了解这些订单状态如何变化，以及相应的触发条件。
image
3.1 从无到待付款
触发条件：下单
当用户生成了订单，产生第一个订单状态“待付款”，该状态为开始状态，即每个订单的第一个状态都会是该状态。
image
3.2 从待付款到待发货
触发条件：付款
当买家付款成功了，订单状态从待付款变成待发货。
根据实际业务可以细分触发条件，所谓付款成功是根据付款结果回调来判断的，那么可以详细的列出每种付款渠道：比如余额/支付宝/微信/额度等。
image
3.3 从待发货到已发货
触发条件：发货
当卖家发货了并在系统上输入相关信息后，订单状态从待发货变成已发货。
根据实际业务可以细分触发条件，所谓发货成功有可能包含无需物流和需要物流两种情况，分别对应虚拟商品和实物商品。
image
3.4 从已发货到已完成
触发条件：确认收货
当买家收到商品并在系统上确认收货后，订单状态从已发货变成已完成。
根据实际业务可以细分触发条件，所谓确认收货有可能包含买家点击了“确认收货”按钮，或者超过指定时间后系统自动确认收货，另外部分B2C自营物流商城会根据物流签收状态来自动确认收货，比如京东自营商品。
image
3.5 从待付款到已关闭
触发条件：关闭订单
当用户超时不付款，订单就会自动从待付款变成已关闭。当然某些电商平台也允许卖家手动关闭订单，或者买家手动关闭订单。
image
四、其他订单状态变化
除了上述常见的订单状态变化外，还有一些支线需要考虑。尤其是部分发货和退款。
4.1 从待发货到部分发货
触发条件：选择部分商品发货
当卖家选择了订单中部分商品进行发货，此时订单状态有个子状态叫做部分发货，当卖家把剩余的商品都发货成功，此时订单状态才变成已发货。
image
4.2 从待发货到退款中
触发条件：选择某个商品退款
当买家在待发货的时候，选择了订单中某个SKU进行退款，此时订单进入子状态：退款中。
image
4.3 从已发货到退款中
触发条件：选择某个商品退货/退款
当买家在已发货的时候，选择了订单中某个SKU进行退货/退款，此时订单进入子状态：退款中。
有了商品之后才有可能产生交易。所以先讲了《B2C自营商城的商品设计方案》，这篇讲解我们的订单模块怎么设计。
一、订单是什么
订单的本意是指你购买商品之后生成的单据凭证，只是在电商中，它是虚拟的。
主流的下单方式
整个电商体系中常见的下单方式有2种，购物车下单和直接下单。
淘宝称之为购物车结算和立即购买，正常情况下你可以任选一种去购物。但是在秒杀之类的特殊场景中，只支持直接下单。
京东也称之为购物车结算和立即购买，不同的是，正常情况下你必须通过购物车去结算，秒杀情况下你可以选择立即购买和购物车结算。
订单的类型
由于不同的下单方式，其实导致订单的类型有2种。
简单来说购物车结算的订单肯定包含了基于sku不同的多个子订单，而每个子订单包含n件同一sku。而立即购买的订单是包含n件同一sku。
然后淘宝的PM因为后续增加了购物车结算这一下单方式，而不得不想出一套规则，那就是父订单和子订单。当然还有很多其他原因。
此次购物，整体称之为交易，生成了一个父订单号。如果它是购物车结算，那么有N个子订单。如果他是立即购买，那么只有1个子订单。
从技术角度来定义，那就是trade称为父订单，order称为子订单，或者说trade是一笔交易单，子订单是每笔交易中的商品明细单，trade与order可以是一对多的关系，trade是由使用购物车生成。
当一笔交易只有一个子订单，那么tid=oid，这个时候主要看trade结构体里面的内容,当一笔交易有多笔子订单(类似于购物车购买方式)，那么tid=oid，这个时候主要看order结构体里面的内容。
二、订单的逻辑拆分
根据以上的规则，订单逻辑上面应该按照这样的方式来拆分。
image
基于这样的设计方式，才可以去支持退款退货，以及设计活动、优惠券等营销功能。
三、订单的金额拆分
进而得到订单的金额是如何拆分的，其中营销得来的优惠拆分到每一个子订单，以及每一个sku的实际支付单价。
image
四、订单状态机
订单的状态是一个很复杂的事情，决定着用户，商家的每一个操作。
不含退款退货
如果你们的商城比较特殊，无需提供退款退货功能，那么订单状态机比较简单。
image
包含退款退货
那么比较复杂，相当于多了一层状态机。具体可以查看我的另外一篇文章《如何绘画状态机来描述业务变化》。
image
五、总结
订单模块的架构设计，以上基本上把主要的内容讲了一遍。按照这样的方式去设计，至少可以兼顾大部分商城的订单需求。
以上内容可以点击我的订单模块原型来详细查看。
至于订单模块和商品模块，和营销模块的耦合，后续的文章会再讲讲。
主要讲讲服务端的架构设计以及商品呈现逻辑。可能对某些PM来说有点难理解，但是我认为这是设计商城系统的PM必须具备的架构能力，而且算是比较基础和底层的部分。
一、商品的基本概念
1.1、对用户而言
一般来说有产品、商品、赠品等概念。
1.2、对数据库而言
可能只有spu，sku两个概念，这是最底层的实体。
-
SPU（Standard Product Unit）是指标准化产品单元，是商品信息聚合的最小单位。比如iPhone6。
-
SKU（Stock Keeping Unit）是指库存量单位，即库存进出计量的基本单元。比如iPhone6国行白色16G。
1.3、对功能而言
至少有产品，标准化商品，下单商品3个概念。
-
下单商品。肯定是一个spu下的sku，对应着商品编码。
-
标准化产品。对应着spu，是几个sku的集合。
-
产品。显示在商城货架上，可能是一个spu，可能是不同spu的组合。
注意所谓的sku可能不是单个物理实体，比如美妆行业经常把2款化妆品用胶布绑在一起作为一个sku，存入仓库。
二、商品的存储
一般而言，B2自营商城选择租用第三方仓库并对接其系统，当规模很大的时候才会考虑自建仓库。
目前我们业务刚刚起步没多久，所以只有一个仓库，比较简单。
如果仓库有多个的时候，一般会根据“选择最近仓库-库存是否足够”的原则来处理配货发货，当然可能还涉及到合并包裹的问题。
三、商品的实体关系
以上讲了商品架构中需要涉及到的实体，而他们的属性和关系决定着数据库中商品表该如何设计。
image
可以参考这篇文章《如何用ER图绘制业务实体模型 》，了解关于实体关系模型的更多知识。
四、商品状态机
商品的上下架状态是用来区分商品是否展示给用户，以及是否可以成功下单。
image
赠品是一种特殊的spu，支持上架并支持用户购买，但是建议设为已下架并且是正确价格。
需要说明的是，售完下架和我下架的，是为了方便运营客服童鞋操作商城运营系统而设计的，采用了和淘宝卖家的商品状态机相似的做法。
可以参考这篇文章《如何绘画状态机来描述业务变化》来了解其原理。
五、商品的呈现
image
大部分电商的商品详情，呈现逻辑是相似的。
另外京东自营会根据收货地址和仓库的位置进行匹配、部分电商会在进入该页面的时候会选中sku并且自动跳过库存不足的。
我没有讲到类目、商品标签、商品关键属性、销售属性、其他属性，包括商品库存。
不是觉得不重要，而是我只讲了最基础最底层的设计，其他的都是根据业务在此基础上面演变而来。
六、总结
以上就是电商平台的常见订单状态，以及他们之间是如何变化的逻辑。希望通过拆分讲解的方式，让大家有个快速的入门。
—————END—————
https://mp.weixin.qq.com/s/1bJNMqNrnFsbDdVYkJHh_Q
本文分享自微信公众号 -PM28产品经理
原文出处及转载信息见文内详细说明，如有侵权，请联系yeweigen0909@126.com删除。
网友评论