订单是电商体系的核心，有了订单才有业绩和盈利。

订单中包含商品、优惠、用户、收货信息、支付信息等一系列实时数据。通过订单中心，实现对线上订单、线下订单及第三方订单的管理，支持订单接收、订单自动合并与拆分、自动匹配仓库、库存控制、自动匹配快递、结算与支付等订单生命周期中的一系列协调作业。依靠灵活多变的订单产品设计架构，可满足电商企业百万级的订单业务处理需求，提升订单流转的工作效率。

在订单生成之后，会随着订单的流转更新状态。不同业务类型的订单状态，例如机票、服务订单、商品服务订单等，和最常见的纯实物商品订单状态会有所区别。以实物商品为例，我们来讨论下订单状态的流转。订单状态主要有以下几种类型。

（1）待付款：用户刚提交订单，尚未付款，等待用户支付。由于待付款状态会锁定库存，所以一般会设置超时自动取消功能。

（2）待发货：用户付款之后，等待商家发货。

（3）待收货：上级已发货，等待用户收货

（4）交易成功：用户确认收货之后，订单已完成交易

（5）已取消：付款之前取消订单。超时未付款或用户取消订单都会产生这种订单状态

（6）售后中：用户在付款后发货前申请退款，或商家发货后用户申请退款、换货，都会产生这种订单状态。

（7）交易关闭：当售后完成后的订单状态。“已取消”的订单状态可以合并到“交易关闭”中。

订单状态的正常流转是：待付款、待发货、待收货、交易成功。但是订单会有逆向流程，和发生的时间节点及类型相关，情况也很复杂。

订单的售后状态主要有以下几种。

（1）待审核：用户提交退货、退款申请之后，等待审核的状态。在用户已付款待发货的转台下，订单未推送至仓库或者在仓库拦截发货成功，系统可直接审核通过。当审核不通过时，回到正常流程中。

（2）待退货入库：退货申请审核通过，等待用户退货入库。

（3）待退款：退货入库成功后，等待退款给用户

（4）待换货入库：换货申请审核通过，等待用户换货入库

（5）换货出库中：换货入库之后，生成换货出库单，订单出库。

（6）售后成功：当退货、退款成功或换货成功之后，流转至“售后成功”状态。退货、脱困的售后成功在主流程下属于“交易关闭”。

在售后管理中，还有一个值得思考的环节：多次售后。当换货成功之后，在流程上还是允许客户有售后环节的。那么在产品设计中，就应该考虑允许用户多次发起售后。

一、订单下单

（1）在订单过程中进行安全校验，主要是检测用户是否在黑名单上、用户购买行为是否正常等，当检测到不正常时，终止下单。

（2）从商品中心获取商品信息（sku、规格、价格）

（3）从营销中心获取商品、订单促销信息（优惠券、促销活动），判断是否满足优惠条件，计算优惠金额。

（4）在会员中心回去会员权益，例如平台抵扣积分，折扣条件等。

（5）在调度中心校验销售层库存，按照调度规则锁定区域库存。

（6）根据拆单规则（商家、仓库、订单类型等）将订单拆分成若干个子订单，根据运费模板计算运费，根据商品金额、运费、优惠金额计算应付金额（实付款）。

订单包含的所有信息内容如下：

用户信息：用户账号、用户等级

订单基础信息：父订单与子订单、订单编号、订单状态

收货信息：收货地址、收货人姓名、联系电话、邮编

商品信息：sku信息、规格、商品数量、价格、商品图片、商家

优惠信息：优惠券、促销活动、虚拟币抵扣金额

支付信息：支付方式、支付单号、商品金额、实付金额、总、优惠金额

物流信息：物流公司、物流单号、物流状态

其它信息：发票信息、下单平台、分销渠道

【父订单与子订单】

当从购物车选中多件商品时，例如选中三个店铺中的商品，会将这次购买行为拆分成三个店铺的订单。这次整体的购买行为记录在父订单下，当系统首次提交订单结算时，会合并子订单，针对父订单进行结算。当提交订单结算中断，或结算之后，系统在更新送单状态、物理追踪时，针对的就是子订单。

【优惠分摊】

在计算订单应付金额时：

订单实付金额=商品金额（sku金额合计）+运费—总优惠金额

其中：

总优惠金额=促销活动优惠金额+优惠券优惠金额+虚拟币抵扣金额

到这里，算是完成了订单计算的第一步。但是这里又出现了一个问题。当优惠后的订单发生部分退货时，应该怎么退款给用户？

1.优惠后订单发生部分退货如何处理：促销活动（如满减）涉及很多商品，优惠券也涉及很多商品，有时甚至跨店优惠。甚至还有整单能享受优惠，部分退货后就不满足优惠条件了，这时怎样平衡用户、商品、平台之间的利益，在退货、退款时应该怎么处理？

两个场景：

（1）发生售后有可能是平台的原因，不是用户不买，而是店铺的的商品由问题

（2）假设双11时，用户分别在A和B店铺买了参加满1000减200活动，各买了500元的货品，后来在A店退了价值100元的东西。这种情况下，退货后已不满足活动条件，是否要求用户给补100元？如果用户补款，又补给谁？

从上面的例子可以看出，如果将退货没达到条件的促销优惠条件考虑进去，系统复杂度会成倍增加。从人性的角度考虑，我们相信绝大部分用户不会为了达到优惠条件故意多买，然后恶意退货。

最合适的处理方法就是下单时就将优惠金额按比例分摊到子订单、商品上。退货时退还用户实付金额，而不会去追究用户因退单而没有满足促销条件，允许用户占平台的便宜。

2.优惠券分摊原则

关于优惠券分摊原则，不但应该按比例分摊，还应在满足优惠条件的商品上，按照商品金额的比例分摊，而不是盲目分摊。

先来看一个案例场景。

订单中有甲乙两店的商品A/B/C/D，包邮。商品A/D参加跨店满200减40的活动（活动1），商品B/C参加满100减10的活动（活动2），另外用户还使用了100元的现金券。

如图所示：

二、订单拆单

订单拆单在电商订单中很常见。拆单有两次，一次是在用户提交订单之后、支付之前拆单，这次是拆分的订单；另一次是在用户下单之后，商家发货之前，去拆分发货单（sku层面）。

两次拆单的原则不同，第一次拆单是为了区分平台商家、方便财务结算，第二次拆单是为了按照最后的发货包裹进行拆单，如不同仓库、不同运输要求的sku、包裹重量体积限制等因素

【为什么要拆单】

方便发货和结算

影响拆单的因素主要有以下几点。

（1）店铺商家。由于商品归属权不同，涉及财务结算和发货的问题。店铺商家不同，需要拆分订单。

（2）仓库。由于发货仓库不同，按照商品归属的仓库进行拆单，若多仓有货，还应按照地域时效选择仓库进行拆单。

（3）品类。由于商品属性和价值的不同，同样会产生拆单需求。

（4）物流因素。不同物流公司对单个包裹的重量或体积计算包裹总重量和体积，超出物流公司限制的也需要拆单

（5）商品价值。跨境海淘商品（单次限额）

【拆单流程】

【拆单之后的前端显示】

在用户提交订单之后、支付之前的拆单，需要及时显示给用户，若用户中断支付，再回到支付环节，就需要分开支付。

在支付之后，系统根据一些影响因素进行拆单，同一个子订单可能会对应多个物流单，在订单显示页面查看物流信息时，需要展示多个物流信息。但是现在许多平台只能一个订单对应一个物流单，有些订单商品数量过多或商品体积过大，一个包裹装不下。仓库分多包裹发货，反馈前端就一个物流单号，信息反馈上就有瑕疵。可以通过一个订单对应多包裹实现。

三、订单售后（退货退款）

在订单生成之后没订单的流转过程会出现不同的逆向流程。

【待付款取消订单】

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

【待发货取消订单】

当订单在“待发货”状态时，用户申请取消订单。由于用户在支付订单后，发货单可能已经推送至WMS，甚至已经交接发货，状态未及时回传更新。未避免货款两失，要先暂停订单出库，在调度中查询订单是否推送至仓库，若尚未推送，则停止出库流程。若暂停失败，则拒绝“取消订单”申请，回复原因“订单已出库”；若暂停成功，“取消订单”申请通过，进入退款流程，同时通知调度中心该订单取消，WMS订单进入返库流程。

【待收货/交易成功退货】

当订单在“待收货”或“交易成功”的状态时，用户申请退货。

【待收货/交易成功退款】

当订单在“待收货”或“交易成功”的状态时，用户申请退款

四、线下服务订单

纯服务订单是指线上购买服务，线下接受服务。对于纯服务订单，当提交订单付款之后，系统生成核销码，如二维码或者一串字母数字组合。当用户到店接受服务之后，店铺进行核销，核销码失效，订单交易成功。

商品服务订单是指在线上购买商品，商品收货之后，去指定门店接受商品附加服务。

对于商品服务订单，商品发货之后将服务核销码发送给用户，当商品到货后，提醒用户进行商品附加服务。服务核销之后，交易流程才算结束。

在系统中，可以将服务当做一种特殊类型的sku来处理。这类商品与服务之间的关系，可在商品中心进行维护。当购买此类商品后，订单进入商品服务订单流程。在下单时客户可选择服务门店，也可以不选，后期通过人工客服指定门店。当选择门店之后，可选择送货到家或直接送到么蒂娜，当商品到货后，进行商品服务。

商品服务订单流程不同于一般商品的流程在于：当实物商品发生售后时，服务核销仍有效。服务商提供服务后，还涉及相应服务的结算，为避免服务商刷单，应提供相应核销码作废功能。

五、订单数据统计

常规统计倾向于财务统计，主要包括销售额、毛利、成本、纯利润、客单价等。流量分析统计更多是为了指导电商平台运营工作，分析用户行为，订单流量等。在订单流量中又分为三个维度，分别从订单交易维度、商品维度、订单来源等三个方面来分析。

【交易分析（订单层面）】

交易维度分析需要统计一下几个数据。

（1）统计周期内的订单销售额（统计周期可以是日、周、月或自定义）

（2）订单量：统计周期内的订单量

（3）客单价：统计周期内，翼支付的ID你滚蛋平均金额

（4）下单用户数与支付用户数

下单用户数：统计时间内，提交订单的去重买家人数，一个人购买多件或多笔，只算一个人

支付用户数：统计时间内，提交订单并支付的去重买家人数，一个人支付多件或多笔，只算一个人

（5）支付新用户数与支付老用户数

支付新用户数：统计时间内支付一次且在最近365天内首次支付的用户去重人数。可能会存在以前有下单未支付而统计时间段内来支付的用户

支付老用户数：统计时间内支付多次或最贱364天内有过支付且统计时间内再次支付的用户去重人数

（6）订单金额分布：订单金额在各价位之间的占比。可以更清楚的知道店铺用户的购买价值分布，可以针对性地提高用户客单价

（7）地域分布：分析各区域的购买转化率及订单量、客单价，有针对性性地进行营销

【商品分析（商品层面）】

商品维度分析需要统计以下数据

（1）被下单商品数：统计周期内，被下单数大于0的商家商品数总和

（2）被支付商品数：统计周期内被支付订单数大于0的上架商品数总和

（3）被访商品数：统计周期内，被访问uv大于0的上架商品数总和

（4）商品收藏次数：统计周期内，商品被来访者收藏的次数

（5）商品销量统计：统计周期内，按照单一商品维度统计上架商品的销售数量，按品类统计销售额、销量

（6）加购件数：统计周期内，，买家加入购物车商品件数之和

【订单来源分析】

订单来源分析需要统计以下数据

（1）统计出每个订单的来源，包括订单的来源媒介（站外广告渠道）、用户端（APP、H5商城、PC端等）

（2）记录每个订单的产生流程，包括在的那个单创建之前的商品浏览、加入购物车、提交购物车等关键步骤的数据分析

（3）追踪订单来源，包括来源的媒介、来源关键词、来源网站等。

六、扩展：购物车

【购物车的妙用】

1.凑单

用户浏览商品详情页的时候，有两种选项：一种是“立即购买”，另一种是“加入购物车”。当用户本身需求较多，想一次购买多种商品，或者参与到优惠活动中，这时候将商品加入购物车进行凑单

2.促销

购物车还有促销方面的功能，用于提高客单价。当有粗次奥活动时，用户将商品加入购物车之后，可以查看是否满足优惠条件和优惠之后的金额

3.收藏

对于大部分用户来说，购物车发挥更多的是收藏哪个的作用

【购物车的设计】

1.通用显示

购物车在展示时，基本的展示信息主要有：商品标题、商品图片、价格、规格、数量、商家、库存状态。购物车的选中策略有三种：打开时默认全选、打开时默认全不选、云端同步选中状态。用户的购物车数据需要记录在数据库中，保证APP端和web端同步，下次登录后不会丢失。

2.离线购物车

离线购物车指的是用户在未登录状态下把商品加入购物车，一般通过创建虚拟用户实现。为了更好的用户体验，需要让用户在下单之前，允许未登录先将商品加入购物车。

用户登录之后，涉及离线购物车和在线购物车合并。首先判断当前是否有离线购物车。然后将离线购物车的数据和在线购物车的数据进行合并

3.库存监控

由于商品库存会发生变动，在库存紧张或无货的时候，会在前端给与提示。除了提醒用户，在库存紧张时还有促单的功效。购物车更新时，去查询对应的商品库存，判断当前商品的数量，当库存数大于0并小于提醒值时，提醒用户库存不足，请尽快下单；当库粗数等于0时，提醒无货；当商品下架后，提示商品无效。无效商品进入无效商品列表中，可批量清除。

4.排序分类

商品在购物车中显示有几个维度：（1）商家店铺，将不同店铺的商品分开；（2）优惠不同，在购物车中将优惠活动相同的商品聚合在一起；（3）加入时间，按照加入购物车的时间倒序排列，最近添加的商品排列在前

5.促销信息

购物车中显示促销相关信息，类似满减、满赠、赠品等信息。

6.商品推荐

在购物车底部，是最好的商品宣传位，可以添加为商品推荐区域。至于商品推荐的内容，会根据用户数据做定向推荐

7.价格监控

购物车的商品价格变动时给用户提示

8.编辑

编辑购物车时主要可以机型的操作：产出商品、加减商品数量、更改商品规格等。

【购物车的结算】

在购物车选中商品时，会实时算出订单金额。在购物车中计算时，需要将优惠金额算进去，但是这部分优惠只包括满减的部分。

在购物车中未将优惠券的优惠金额算入，主要是因为实际场景中可能有多种优惠券满足订单的情况，用户可根据需要自由选择相应的优惠券。