订单管理（OMS）1——下单流程、订单信息、父子 …
（一）订单管理概述
>> 订单管理（OMS）：通过订单中心，实现对线上订单、线下订单及第三方订单的管理，支持订单接收、订单自动合并与拆分、自动匹配仓库、库存控制、自动匹配快递、结算与支付等订单生命周期中的一系列协同作业。
>> 订单中包含商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据。
>> 在订单生成之后，会随着订单的流转更新状态。不同业务类型的订单状态，例如机票、效劳订单、商品效劳订单等，和最常见的纯实物商品的订单状态会有所区别。
*在收货前退款不能算售后，售后一般走的是效劳单，与订单相关，但不是订单自身的流转。
>> 售后中：用户在付款后发货前申请退款，或商家发货后用户申请退换货，都会产生这种订单状态。订单售后状态又分许多种，后面详述。
>> 订单状态的正常流转是：①待付款、②待发货、③待收货、④交易胜利。但订单会有逆向流程，和发生的时间节点及类型相关，情况也很复杂多变。
>> 订单的售后状态主要有以下几种:
①待审核：用户提交退货、退款申请后，等待审核的状态。在用户已付招待发货状态下，订单未推送至仓库或者在仓库拦截发货胜利，系统可直接审核通过。当审核不通过时，回到正常流程中。
②待退货入库：退货申请审核通过，等待用户退货入库。
③待退款：退货入库胜利后，等待退款给用户。
④待换货入库：换货申请审核通过，等待用户换货入库。
⑤换货出库中：换货入库后，生成换货出库单，订单出库。
⑥售后胜利：当退货、退款胜利或换货胜利后，流转至“售后胜利”状态。退货、退款的售后胜利在主流程下属于“交易关闭”。
>> 在售后管理中，还有一个值得考虑的环节：屡次售后。当换货胜利之后，在流程上还是允许客户有售后环节的。那么在产品设计中，就应该考虑允许用户屡次发起售后。另外系统应设置申述周期，保证商家利益，例如：在发货之后7天自动确认收货，交易胜利15天后售后通道关闭。
（二） 订单下单——用户的一小步，系统的一大步
>>【订单下单流程】
图 订单下单流程
订单下单流程图链接：
>> 【订单信息】
存储的订单信息中，主要包含以下内容：用户信息、订单根底信息、收货信息、商品信息、优惠信息、支付信息、物流信息、其他信息等。
订单的内容复杂精细，在存储时除了表构造的设置，还应该注意信息冗余。
特别是商品信息，由于商品的内容不时编辑变化，要保管下单时的商品快照，防止过长时间后，商品信息丧失。
>> 【父订单与子订单】
当从购物车选中多件商品时，例如选中三个店铺中的商品，会将这次购置行为拆分成三个店铺的订单。这次整体的购置行为记录在父订单下，当系统首次提交订单结算时，会合并子订单，针对父订单停止结算。当提交订单后结算中断，或结算之后，系统在更新订单状态、物流追踪时，针对的就是子订单。
>> 【优惠分摊】
1、计算订单应付金额时：
订单实付金额=商品金额（SKU金额合计）+运费-总优惠金额
其中， 总优惠金额=促销活动优惠金额+优惠券优惠金额+虚拟币抵扣金额
2、优惠后订单发生部分退货如何处置？
规则：优惠分摊，偏向用户。
假设将退货没到达条件的促销优惠条件考虑进去，系统复杂度会成倍增加。从人性的角度，我们相信绝大部分用户不会为了到达优惠条件故意多买，然后恶意退货。
最适宜的处置方法就是下单时就将优惠金额按比例分摊到子订单、商品上，同样实付金额也分摊到子订单、商品上。退货时退还用户实付金额，而不会去追查用户因退单而没满足促销条件，允许用户占平台的廉价。
3、优惠分摊原则
优惠券金额分摊的原则，按商品金额比例分摊：优惠价*（结算价\总结算金额）
>> 关于优惠分摊原则，不但应该按比例分摊，还应在满足优惠条件的商品上，依照商品金额的比例分摊，而不是自觉分摊。
小结：本节主要介绍了订单的正向流程，但是在实际应用中又会衍生出许多变化。例如支付效劳：有第三方支付、分期付款、货到付款等，都影响订单的状态；还有自营平台会将出库状态参与到订单状态中；还有从其他渠道（线下订单、京东等第三方订单）导入到系统的订单，不只涉及与第三方平台的打通，还有对这些订单的管理，以及同步状态至第三方平台。 |
|
|
|
|
|
|
|
|
