一个订单系统的设计并不简单，它需要一批又一批的人去维护、去优化，根据公司的业务情况做出改变和兼容。本文主要分析一下电商订单系统该如何设计。
电商所有模块中，订单系统作为最为核心的模块，决定了整个流程能不能顺畅的执行，起着承上启下的作用。相信很多PM都不陌生，到了一家电商公司，总会觉得公司现有的流程有不少问题，因为问题来自四面八方，一下子摸不着到底是哪里出了问题，PM就跟补丁师傅一样，遇到一个补一个。
其实很多日常开发和测试提得需求都是表面需求，而这些表面上呈现出的各种问题，都是源自于流程上的不完整或者流程上某个环节上的缺失导致的。订单系统作为一个承上启下的模块，流程上出了问题，它肯定脱不了干系。
订单系统分为用户端和商家端，今天我们从商家端简单分析一下订单系统该如何设计和完善，才能不断适应公司的业务发展，减少因为流程导致的不必要的返工和“补丁”。
为什么说订单系统是承上启下的作用，上游是什么，下游又是什么？
这里我们先把问题放在这，后面讲到再作解释。
订单系统
设计订单系统需要考虑几个模块，只有所有模块都考虑清晰了，才能保证订单系统的稳定性和可扩展性。
1. 订单字段
其实呈现在界面上的订单信息，都是由各种订单字段组合而成。订单字段齐全从某个程度上代表着订单流程的完整。
订单字段信息
订单字段包括几个部分，其中金额信息因为特殊性，独立出来讲，实质上金额信息属于商品信息。
商品信息：商品信息属于订单系统的上游端，所有订单都是从商品演进而来，从商品到订单，订单系统必须搜集相关的商品信息，包括店铺信息，商品id，商品规格，商品数量，商品价格。获取到的商品信息将在订单详情页内展示，形成订单信息后供仓库方便拣货，包装。
用户信息：用户信息包括购买用户的ID，收货人，收货地址，联系方式。有些平台的用户成长体系是基于用户对平台的活跃度来计算的，例如京东，它有会员等级及积分卡等类似的成长标识，此时获取到的用户信息除了普通的信息字段外，还需要获取该用户的等级，该次购买后所获得的积分，以及该用户所在等级能在该订单上扣除的优惠等信息，具体怎么操作取决于公司的业务方向。
金额信息：因为金额信息的特殊性，所以独立出来讲，理论上金额信息应归属商品信息。金额信息的特殊性在于其不止一种金额，其涉及到商品金额，优惠金额，支付金额。而优惠金额中涉及到的信息较复杂，像有自营和第三方入驻的电商平台，都会有商家优惠和跨店优惠，而这些优惠又分不同类型，例如现金扣减，消费券扣减，积分获取，礼品卡扣减，或者以上几种的组合使用。想要涉及好这一块内容，需要根据目前自己公司的业务情况，列出所支持的优惠类型，再枚举出各种组合下的优惠类型，才能保证流程的完整性。
时间信息：记录各个卡点下的时间，一是记录，二也是方便售后验证和客户分析。订单时间是根据订单状态改变而改变的，比如：我们常见的用户。
- 下单未付款：即展示订单创建时间、下单时间；
- 待发货状态：展示订单创建时间、下单时间、支付时间；
- 待收货状态：展示订单创建时间、下单时间、支付时间、发货时间；
- 交易完成状态：展示订单创建时间、下单时间、下单时间、支付时间、发货时间、完成时间；
- 待退款状态：展示退款订单创建时间、申请退款时间；
- 交易关闭-用户取消：展示订单创建时间、下单时间、用户取消时间；
- 交易关闭-仅退款：订单创建时间、下单时间、支付时间、退款申请时间、退款成功时间；
- 交易关闭-退货退款（包含部分仅退款）：订单创建时间、下单时间、支付时间、交易完成时间、退款申请时间、退款时间。
时间信息看起来不重要，其实是订单系统一个重要的组成部分，原因大家可以思考一下。
订单信息：订单信息在订单系统最为核心，订单信息最重要的又是订单状态。很多公司都有订单状态机的说法，那到底什么是订单状态机？
我个人的理解是：在订单中，通过各种购物情景，触发订单状态，将订单的流转可视化，是订单状态机的一种具体呈现形式，而它实质就是在描述订单状态的转换。
电商购物中，订单状态分别有以下几种：【待付款】、【待发货】、【待收货】、【待评价】、【交易完成】、【用户取消】、【仅退款】、【退货退款】。而我们一般会将后三种统一放在订单售后独立呈现，去方便平时商家操作的便捷性。
电商订单流程
2. 订单流程
订单流程是指从订单产生到完成整个流转的过程，其中包括正想流程和逆向流程。正向流程就是一个正常的网购步骤：订单生成–>支付订单–>卖家发货–>确认收货–>交易成功。
而逆向流程则是各种退款流程。
（1）正向流程
订单正向流程
整个订单设计的流程其实是非常多的，接下来我们将从比较具体的描述一下各个环节下的实际情况。
订单生成：用户下单后，系统需要生成订单，此时需要先获取下单中涉及的商品信息，然后获取该商品所涉及到的优惠信息，如果商品不参与优惠信息，则无此环节。
接着获取该账户的会员权益（这里其实需要注意的是：优惠信息与会员权益是有区别的，就好比商品满减是优惠信息，新人立减是会员权益，一个是针对商品，另一个是针对账户）。
库存扣减是指可销售库存数量-1，严格来讲库存扣减目前分为两种：
- 一种是下单减库存；
- 另一种是付款减库存。
个人觉得中小创业者也许竞争者不比淘宝中的卖家，在电商这个存量市场，需要精细化的运营才能存活下来，如此说保证用户体验才是根本。所以我这里的观点是生成订单扣减库存，这种做法会避免用户支付成功商家却没货的情况。然后计算运费，订单生成成功。
支付订单：用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，往往还有一种情况存在，很正常却也比较复杂，就是订单拆单。
- 订单拆单分两种：一种是用户挑选的商品来自于不同渠道（自营与商家，商家与商家），此时就需要拆分订单，并分开结算，这里还涉及父子订单的说法，这里不再赘述。
- 另一种是在SKU层面上拆分订单：不同仓库，不同运输要求的SKU，包裹重量体积限制等因素都需要将订单拆分。比如：商品A只在甲仓库有，商品B又只在乙仓库有，此时会将商品A与商品B拆分成两个订单。或者有些企业的做法是将商品A/B调拨到另外一个仓库统一发货，也方便了用户。
订单拆单看起来简单，其实里面涉及到底层的系统支持，如你需要对每一个仓库的货品进行相对准确的盘点，且做到实时同步（涉及到仓库精细化管理），对商品进行准确分类与摆放，对商品信息记录准确无误等。
这其中哪一模块都是一个浩大的工程，PM一般进入一家公司都会在原有（半成品）的基础上进行优化，大家不妨多思考一下底层业务，只有在底层做好精细化管理，才能支持线上丰富的用户需求。
商家发货：商家发货过程也有一个标准化的流程，上面也有讲到，订单拆分时会涉及到仓库间调拨，然后仓库会对商品进行打单、拣货、包装、交接快递配送。这套标准化流程如果优化好，也是一个大工程，这里不再赘述，建议大家看看库存与仓库管理方面的书籍，详细了解。
确认收货：商家发货后，就是等快递配送了，订单系统需要接入一些常用快递企业的接口，方便用户与商家在站内查询快递信息。
交易成功：收到货后，不是一个服务的结束，相反是一个服务的开始。订单系统需要在快递被签收后提醒用户对商品做评价，这里要注意，确认收到货不代表交易成功，交易成功是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程就算走完了。
目前我也没有研究过，不过我的经验告诉我订单系统对售后订单的处理并不比正产订单少，身为电商PM，我们的工作就是去优化这些流程，提高用户粘性。本身售后订单的出现，在某种程度上已经伤害到了用户，如果流程还一团糟的话，我们根本没有机会等到用户的复购。
（2）逆向流程
订单逆向流程
一个电商的基本逆向流程如上图所示，订单的逆向流程复杂就在于它几乎允许在正向流程的任何环节出现。有人会问：用户未收到货为什么还能退款？
其实我们换位思考，也很容易理解。假想你是用户，买了一双鞋子，付了款发了货，正在美滋滋的等待收快递，然后刚好路过一家鞋店看到刚买的同款鞋子大促销，于是你就拿起手机点击退款，买下了这双促销的鞋子。
这种场景其实是很普通也很正常的用户日常，所以我们的订单系统就必须得支持用户各种丰富的场景需求，也十分考验PM的业务渗透能力，好在电商的先行者淘宝已经做了很多基础建设和用户教育，我们直接可以拿来套用，不过还是要根据各个公司的业务情况进行修改。
取消订单：用户提交订单时，在跳转至支付前直接退出，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回即可。
支付失败：用户进行支付时退出，或者取消支付，我们将其列为支付失败状态，此时处理同上，将扣减的库存补回可销售库存即可。
付款后退款：用户支付成功后，商家还未发货，支持用户申请退款，此时如果仓库与客服是分离的，则需要先检查仓库是否已经发货，若已发货则应与客户沟通是否可以收到货后再进行退款，如果仓库还未发货，则可直接同意用户退款。或者企业接入菜鸟物流，实行截件功能，不过这种操作还不成熟，成本会比较大，不适合中小创业型公司。
缺货退款：用户支付成功后，商家发货时发现仓库缺货（如果提交订单扣减库存，则会减少缺货情况，为什么是减少而不是避免？因为仓库管理商品时没办法做到100%精准，所以信息有时候会不准确，导致线上的可销售库存显示有库存而仓库已经售空的状态），则需要与用户协商是否退款。
这个流程订单系统可以做到流程化、自动化，连接消息中心和仓库管理系统去实现，难点在于消息的实时性。我就遇到过在淘宝买过一件上衣，一天过去了，商家跟我说没货了，我当时杀人的心都有了。
待收货退款：这个问题目前还没有特别完美的解决方法，商家发了货之后，用户还未收到货，此时货在路上。
我曾经在一些交流群里提出过这个问题，大家的看法都不一样，大体上分为两种做法：
- 一种是用户收到货后重新寄回；
- 另一种是用户直接拒收包裹，包裹直接退回原地址。
我个人倾向于第一种，第一种比较灵活，因为用户未收到货就退款的原因一般与商品质量关系不大，所以如果允许用户直接拒收退回，相当于商家需要承担回退运费，而本身可能与商家并无太大关系。
另外一个原因就是，有些商家发货地址与退货地址不在同个地方，不支持直接退回。尽管如此，在到处强调用户体验的今天，增加用户的售后成本也是在消耗用户对平台的耐心，大家不妨去思考一下，有没有更好的解决方法。
用户拒收：同上。
退货退款：用户收到货后，想要申请售后，则此时需要提供让用户输入售后原因，包括上传凭证的功能，如果与商家协商无果，还需要增加平台客服的入口，方便用户进行申诉。而协商结果/申诉成功后直接触发自动退款机制，退款后触发消息通知，同时触发交易关闭状态，整个售后过程才算结束。
我上面有好几处都提到与消息中心的对接，消息的触发等，其实这也算是订单系统设计的一部分内容，称之为订单推送。当订单状态机发生变化时，需要将对应的变化情况告知给相关人员以便了解当前订单的情况，这也是订单推送的作用。
3. 订单推送
订单推送的触发依赖于状态机的改变，涉及到的信息包括：
- 推送对象（用户、商家、仓库）；
- 推送方式（站内消息、push、短信、微信）；
- 推送节点（状态机）。
本文主讲订单系统的核心模块设计逻辑，订单推送的具体设计就不再此处赘述。
结言
一个订单系统的设计绝非这么简单，它需要一批又一批的人去维护、去优化，根据公司的业务情况做出改变和兼容。
大家平时在做产品设计的时候可以多深入了解一下公司的具体业务场景，这样才能做出适用自己企业的订单系统，自己也才能成长，而不是一直套用别人的逻辑结果。
写完文章已经完美进入周日了，下一篇文章会对上次有所保留的拼团活动进行更加详细的分析。
本文由 @野蛮非先生 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
,
