个部分详解电商订单管理流程
⇨⇦
本文详解了电商系统订单模块中的各项流程，包括了订单的概念、构成、状态、流程、逆向订单、订单拆单等内容。
一、订单概述
电商所有模块中，订单模块是核心中的核心，电商所有模块都是直接或者间接为订单模块服务的。
订单模块看似简单，很多新人产品经理包括我自己，都觉得订单模块不就是浏览商品、加购、支付、订单列表不就完了吗？
后来随着接触的增多，发现订单模块并不是想象中的简单，觉得简单的只是看到了冰山的海面部分，其庞杂的体系都隐匿在海面一下。今天根据我的经验，来和大家订单做详细的说明。
电商系统涉及到3流，分别时信息流，资金流，物流，而订单系统作为中枢将三者有机的集合起来，订单系统就从这三流开始吧。
订单模块是电商系统的枢纽，在订单这个环节上需求获取多个模块的数据和信息，同时对这些信息进行加工处理后流向下个环节，这一系列就构成了订单的信息流通。我们从以下几个环节对订单信息流动进行详细的说明
1. 订单场景
订单场景的说明不言而喻，不同场景下订单表现形式和数据传递方式也不相同，目前主流的订单场景包括线上电商订单、O2O电商订单。
（1）线上电商订单
这种电商就像淘宝、京东等，通过线上下单、支付后由自建物流或者第三方物流进行配送。这种电商系统通过，展示电商系统的商品模块引导用户对商品进行订单模块的处理，订单模块处理完成后将信息传递给WMS系统进行处理，当用户收到货品后在订单系统进行确认。通过以上系统的协同处理来完成整个订单信息的处理。如果是虚拟物品的话需要调用其他系统进行对接，通过接口返回参数方式完成信息的处理，比如充话费、买点卡等。
（2）O2O电商订单
这种电商包括两种外卖订单和团购订单。
外卖订单和线上电商订单有些类似，线上订单处理完成后只是没有经过仓库环节进行处理，而是需要生产环节对数据进行处理，生产完成后将信息传递给物流环节，用户确认收货后再对订单信息进行处理。
而团购订单则是线上获取商品信息后，通过订单系统处理完成，将信息传递给wms系统进行库存处理，只是对库存进行信息处理而没有物流配送环节，用户线下到店后对订单系统进行核销处理，从而完成整个订单信息的闭环。
二、订单构成
我们先从订单整个架构进行了解，以下是整个订单系统的构成：
1. 用户信息
用户信息包括用户账号、用户等级、用户的收货地址、收货人、收货人电话等组成，用户账户需要绑定手机号码，但是用户绑定的手机号码不一定是收货信息上的电话。用户可以添加多个收货信息，用户等级信息可以用来和促销系统进行匹配，获取商品折扣，同时用户等级还可以获取积分的奖励等。
2. 订单基础信息
订单基础信息是订单流转的核心，其包括订单类型、父/子订单、订单编号、订单状态、订单流转的时间等。
（1）订单类型包括实体商品订单和虚拟订单商品等，这个根据商城商品和服务类型进行区分。
（2）同时订单都需要做父子订单处理，之前在初创公司一直只有一个订单，没有做父子订单处理后期需要进行拆单的时候就比较麻烦，尤其是多商户商场，和不同仓库商品的时候，父子订单就是为后期做拆单准备的。
（3）订单编号不多说了，需要强调的一点是父子订单都需要有订单编号，需要完善的时候可以对订单编号的每个字段进行统一定义和诠释。
（4）订单状态记录订单每次流转过程，后面会对订单状态进行单独的说明。
（5）订单流转时间需要记录下单时间，支付时间，发货时间，结束时间/关闭时间等等。
3. 商品信息
商品信息从商品库中获取商品的SKU信息、图片、名称、属性规格、商品单价、商户信息等，从用户下单行为记录的用户下单数量，商品合计价格等。
4. 优惠信息
优惠信息记录用户参与的优惠活动，包括优惠促销活动，比如满减、满赠、秒杀等，用户使用的优惠券信息，优惠券满足条件的优惠券需要默认展示出来，具体方式已在之前的优惠券篇章做过详细介绍，另外还虚拟币抵扣信息等进行记录。
为什么把优惠信息单独拿出来而不放在支付信息里面呢？
因为优惠信息只是记录用户使用的条目，而支付信息需要加入数据进行计算，所以做为区分。
5. 支付信息
（1）支付流水单号，这个流水单号是在唤起网关支付后支付通道返回给电商业务平台的支付流水号，财务通过订单号和流水单号与支付通道进行对账使用。
（2）支付方式用户使用的支付方式，比如微信支付、支付宝支付、钱包支付、快捷支付等。支付方式有时候可能有两个——余额支付+第三方支付。
（3）商品总金额，每个商品加总后的金额；运费，物流产生的费用；优惠总金额，包括促销活动的优惠金额，优惠券优惠金额，虚拟积分或者虚拟币抵扣的金额，会员折扣的金额等之和；实付金额，用户实际需要付款的金额。
用户实付金额=商品总金额+运费-优惠总金额
6. 物流信息
物流信息包括配送方式，物流公司，物流单号，物流状态，物流状态可以通过第三方接口来获取和向用户展示物流每个状态节点。
三、订单状态
1. 待付款
用户提交订单后，订单进行预下单，目前主流电商网站都会唤起支付，便于用户快速完成支付，需要注意的是待付款状态下可以对库存进行锁定，锁定库存需要配置支付超时时间，超时后将自动取消订单，订单变更关闭状态。
2. 已付款/待发货
用户完成订单支付，订单系统需要记录支付时间，支付流水单号便于对账，订单下放到WMS系统，仓库进行调拨，配货，分拣，出库等操作。
3. 待收货/已发货
仓储将商品出库后，订单进入物流环节，订单系统需要同步物流信息，便于用户实时知悉物品物流状态
4. 已完成
用户确认收货后，订单交易完成。后续支付侧进行结算，如果订单存在问题进入售后状态
5. 已取消
付款之前取消订单。包括超时未付款或用户商户取消订单都会产生这种订单状态。
6. 售后中
用户在付款后申请退款，或商家发货后用户申请退换货。
售后也同样存在各种状态，当发起售后申请后生成售后订单，售后订单状态为待审核，等待商家审核，商家审核通过后订单状态变更为待退货，等待用户将商品寄回，商家收货后订单状态更新为待退款状态，退款到用户原账户后订单状态更新为售后成功。
四、订单流程
订单流程是指从订单产生到完成整个流转的过程，从而行程了一套标准流程规则。而不同的产品类型或业务类型在系统中的流程会千差万别，比如上面提到的线上实物订单和虚拟订单的流程，线上实物订单与O2O订单等，所以需要根据不同的类型进行构建订单流程。
不管类型如何订单都包括正向流程和逆向流程，对应的场景就是购买商品和退换货流程，正向流程就是一个正常的网购步骤：订单生成–>支付订单–>卖家发货–>确认收货–>交易成功。而每个步骤的背后，订单是如何在多系统之间交互流转的，可概括如下图：
1. 订单创建
订单创建是从用户下单开始的，当用户对商品进行下单后，系统会引导用户来到确认订单页面，此时系统会获取用户预下单的商品信息，同时判断商品是否涉及到优惠促销的信息，这些优惠券包括促销活动，优惠券，积分抵扣等。
除了获取优惠信息外，还需要判断用户等级权益，比如VIP用户8折优惠，新用户立减优惠等，其中的券别在于一个是针对商品，一个针对的用户等级权益，电商系统在开发初期如果不涉及用户等级折扣而又有新用户促活优惠的话，建议使用优惠券来做。而在优惠活动需要遵循配置的叠加规则和优先级规则，在预下单操作是需要做判断。
在预下单操作时，需要对库存进行查询，而库存从什么时候进行增减，目前主流有两种方式：
下单减库存，用户预下单成功时减少库存数量，优点是系统逻辑比较简单，库存实时展示用户体验好，同时也带来了恶意下单的风险。
付款减库存，用户支付完成后再减少库存，优点减少恶意下单的风险，缺点是第三方支付回调采取的是异步回调方式，回调结果返回系统需要时间，并发下单情况下可能导致库存不足引发退款和投诉。
个人比较倾向于下单减库存的方式，在电商这个竞争激烈的环境下，保障用户体验才是第一位的，同时需要做好相对的措施，预下单后马上对库存进行锁定，锁定时间同步订单支付的限定时间。
比如淘宝的15分钟，限定时间内没有付款，将锁定库存进行回滚释放。这种下单减库存的方式，可以减少用户因为下单后仓库没有货的情况，减少用户的挫败感。
2. 订单支付
订单支付在支付层面涉及的方面比较多，比如默认支付渠道，支付渠道的路由，组合支付等，在这里就不多加叙述，订单支付过程做需要选择支付方式，支付完成后通过支付渠道会返回支付流水号，支付完成时间。系统需要记录订单同时生成支付流水，方便与支付渠道进行对账。
支付完成后下一步是等待卖家发货或者是订单下放到仓库，在此过程中，会涉及到拆单过程，一般拆单分为两次拆单：
一次拆单：订单层面的拆单，这个拆单主要是因为组合商品时，各个商品属于不同商家，此时订单需要使用父子订单进行区分
二次拆单：商品层面的拆单，这个拆单由于商品分属不同的仓库，重量/体积限制，商品品类要求比如易燃或者贵重物品需要单独打包，商品库存原因，比如需要有些商品当天发生，有些商品48小时后发送，另外对于海淘来说还存在关税问题需要拆单的。
对于拆单后面还会继续进行说明。
3. 卖家发货/仓储处理
这个过程从线下走向线下，商家发货过程已经形成一个标准化的流程，订单内容会下放到仓库，仓库对商品进行打单、拣货、包装、交接快递进行配送。
目前很多WMS系统都与主流电商系统进行了对接，订单下单成功后直接进入到WMS系统，在此过程中会涉及到合并订单，比如同一买家同一收货信息分多笔下单的订单，订单审核，订单重新分仓，下放库房，生成批检单，订单打印等等。关于物流仓储方面后面物流篇讲进行详述。
4. 确认收货
订单通过仓储环节，已经发货了，在订单系统中会涉及到对物流信息的获取，包括配送方式/物流公司/物流单号/物流状态的实时显示。
记得淘宝没有打通物流查询环节时，那时候想知道包裹到哪里，需要根据商家提供的物流公司和物流单号，在物流公司官网进行查询，而现在很多物流公司开放了物流接口，可以根据物流接口获取物流状态信息。当用户收到货后，可以根据物流公司反馈的签收结果，设置提醒用户确认收货。
5. 订单完成
用户确认收货后，这个订单总算完了，NO,NO,NO，演出才刚刚开始。
订单完成后会涉及到需要提醒用户进行订单的点评，同时可能会涉及到订单的售后问题。
交易成功是指在收货后N天后，此时除去售后问题外，渠道侧会涉及到平台和支付渠道结算的问题，货款需要从支付渠道流入平台账户；商户侧会涉及到平台需要生成待结算清单问题，明细该笔订单商户结算款是多少。如果涉及到三级分销的话，还需要考虑到各级代理分润问题。
五、逆向订单
订单逆向过程是个非常头痛的问题，每次涉及订单的时候，每次都傻傻地问boss可以不做退款退货流程吗？
老板很鄙夷地回答：没有买卖就没有伤害。有人的地方就有江湖，有订单的地方就有退款退货一个道理，所以安心设计好逆向流程才是王道。
关于订单逆向流程，想想线下一些购买场景理解起来就方便很多了，接下来就举例说明逆向订单：
大傻去电脑城去买个笔记本电脑，在千挑万选后终于在奸商小K的说服下，准备下单购买一台联想小新air，故事就这么发生了……
CASE1 修改订单
这个时候在小K的说服下大傻选购小新air，突然大傻对小新air配置还有一些优惠提出了新的疑问，好吧……正准备开单的小K为了促成这个交易在单子上面给大傻填写赠送鼠标，背包…
修改订单发生在预下单过程中，用户没有提交订单，可以对订单一些信息进行修改，比如配送信息，优惠信息，及其他一些订单可修改范围的内容，此时只需对数据进行变更即可。
CASE2 订单取消
待支付情况下，各种单据都填好了，小K说：哥，你该付款了。大傻一摸口袋，钱包不见了。小K心里想，哥，你逗我玩呢？
这个时候有3种情况：
第一，大傻回去拿钱后给了小K钱。
第二，大傻说这个电脑不要了，单据作废吧。
第三，大傻说我回去拿钱，返回后结果门店下班了，单据也作废了。
这个状态下对应电商场景下的 用户主动取消订单和用户超时未支付，两种情况下订单都会取消订单，而超时情况是系统自动关闭订单，所以在订单支付的响应机制上面要做支付的限时处理，尤其是在前面说的下单减库存的情形下面，可以保证快速的释放库存。
另外需要需要处理的是促销优惠中使用的优惠券，权益等视平台规则，进行相应补回给用户。
CASE3 退款
待发货情况下，大傻及时付完款了，小K心里乐开了花，在去仓库的路上一蹦一跳的，心里琢磨着这笔单下来晚上可以好好喝一杯了，结果跑到仓库拿货，仓库告诉小K没有货了，小K心里一万匹草泥马在奔驰着。没有办法，小K只好回去告诉大傻，完了大傻对小K一顿咆哮，最终小K还是把钱退给了大傻。
故事还有另外一个版本：大傻及时付完款了，小K心里乐开了花，在去仓库的路上一蹦一跳的，心里琢磨着这笔单下来晚上可以好好喝一杯了。还没有到仓库，前台小姐姐给他打电话，大傻说隔壁王阿姨的姑姑的表姐的女儿出了车祸要借钱，所以大傻不要笔记本了，小K心里一万匹草泥马在奔驰着。没有办法，小K只好给大傻退款。
在待发货订单状态下取消订单时，分为商户缺货退款和用户申请退款。
商户缺货退款由于订单系统和WMS系统商品没有进行及时同步导致，或者是仓管和客服分开产生的，这个情况下需要与用户协商处理退款。
用户申请退款，用户下单后，商家还未发货，系统应该支持用户申请退款，如果发货单已经下发到wms系统，但是尚未推送至仓库，则应该挺推送至仓库，推送至仓库则需要WMS中进行拦截，拦截成功则暂定出库，同步订单系统 同意取消订单，同时进入退款流程。
如果是全部退款则订单更新为关闭状态，若只是做部分退款则订单仍需进行进行，同时生成一条退款的售后订单，走退款流程。退款金额需原路返回用户的账户。
CASE4 发货后的退款
我们继续那个故事：当小K从仓库将笔记本电脑领出来后，将电脑拿给大傻，大傻一看包装破破烂烂的啥玩意啊，老子不要了，不管小K好说歹说，大傻坚决不要了，拗不过他，小K最终还是给大傻退了钱。
发货后的退款，发生在仓储已经货物的配送，在配送过程中商品遗失，用户拒收，用户收货后对商品不满意，这样情况下用户发起退款的售后诉求后，需要商户进行退款的审核，双方达成一致后，系统更新退款状态，对订单进行退款操作，金额原路返回用户的账户，同时关闭原订单数据。
仅退款情况下暂不考虑仓库系统变化。如果发生双方协调不一致情况下，可以申请平台客服介入。在退款订单商户不处理的情况下，系统需要做限期判断，比如5天商户不处理，退款单自动变更同意退款。
CASE5 退款退货
故事还没有完，大傻没有在小K家买成笔记本，又去了阿狸家买成了笔记本电脑，谁知道阿狸家笔记本更黑，翻新机做新机卖给大傻，大傻回去后笔记本没用到1晚上就直接挂了。
火大的大傻第二天就找到阿狸要退货，阿狸各种忽悠还是没有忽悠到大傻这颗要退款退货执着的心，万般不情愿下阿狸终于将笔记本重新入库后，给大傻退了钱。
用户退款退货的流程和用户仅退款的流程差不多，需要与商户进行协商，如果协商过程存在争议平台客服介入进行协调。如无争议，商户审核通过后告知用户退货流程及退回的收件信息，进入退货流程后，商家收到用户退货商品后，库存系统进行补回，退货入库，订单系统确认后进行退款，同时关闭订单。
当订单中发生部分退货时，原订单的状态不变，维持待收货或交易成功状态，同时退货的部分生成交易售后订单。剩余未退货部分仍然允许申请售后。如果退货商品在验收环节存在用户导致的问题，可以通过线下协商后，将商品重新发回给用户，或者进行退部分款项。
之前在聊促销活动时，说到过优惠金额的处理方式，之前只是针对平台类和单店铺模式进行说明，本节对优惠券和促销进行订单逆向的退款退货进行说明，主要进行部分退款进行说明。
讲解前先列公式，便于计算：
单个商品优惠金额 = 总优惠金额 * （单个商品价格 / 商品总价）
单个商品实付金额 = 单个商品售价 – 单个商品优惠金额
好了公式列完了开始讲故事了：
618大促时夏天正好快到了，王小胖在某商城进行血拼，在618之前王小胖已经领取几张优惠券分别时平台服饰类优惠券满500减50，小猫门店满800减200优惠券，小花花门店满400减100优惠券。
以下就是罗列每件商品的优惠券金额和实付金额：
如果王小胖对小猫门店休闲长裤不满意，退款只需要退款149.31元即可。
到这里关于订单正向和逆向流程已经说明完毕，抛出一个问题，如果同一个SKU里面有多件商品，需要对某件商品进行退款怎么操作？
六、订单拆单
为什么要拆单呢？
因为电商平台存在购物车进行合并付款，如果不拆单会遇到无法跟踪物流或者会存在多个物流，另外做结算时不方便进行核账等，哪怕时同一家店铺也会存在发货时间、分不同物流发货问。这个时候我们需要进行拆单。
从订单表层面，我们需要将订单建立父子订单，加购后提交订单时需要创建父子订单和编号，这个从用户体验角度来说方便用户进合并付款，减少用户操作提高转化率。
拆单的原因包括：
店铺：在多商户商场下，商品归属不同商户，所以涉及到商户后台的财务结算和物流发货问题。
仓库：商品不在同一个仓库时需要按照仓库归属进行拆单
属性：有些商品需要单独运配送，购买沙发和衣柜都需要独立包装，商品不在一起需要进行拆单
价值：这个涉及跨进电商，政策对跨境电商有单次限额，超过金额翻，也需要对订单进行拆单。
第一次拆单 订单层面拆单
订单层面拆单主要加购下单后存在上面说的对应不同的商户和不同仓库，用户完成支付后可以订单中有多个不同的子订单。
父订单是记录一次下单和合并支付的依据，同样在促销层面来说可以通过父订单享受购物的优惠，然后通过子订单进行分摊，而子订单是跟踪物流，售后、结算的依据。所以在设计订单设计需要所有订单都设计父子订单。
从物流层面来说订单生成后，订单会进行下放。对于平台会将订单推送到调度系统进行处理，多商户商城可以将订单导出安排发货，在更新发货信息；自接系统会将订单同步WMS系统或者ERP里，安排发货。
第二次拆单 物流层面拆单
订单推送至调度层后，调度中心需要进行审核处理，审核通过后订单开始进行调拨和配货，这个时候需要仓储需要根据发货单进行拆单，这次拆单会包括商品属性/价值/体积/重量/库存进行拆单，子订单包括多个包装，也存在多个物流信息。
以上就是整个订单信息流的说明，关于订单还包括订单结算，订单支付等流程，这块属于支付和结算体系需要考虑的范畴，有机会再后面会进行支付和结算体系的说明。