一个订单系统的设计并不简单，它需要一批又一批的人去维护、去优化，根据公司的业务情况做出改变与兼容。这篇文章主要与大家分析一下电商订单系统该如何设计。

在一个电商所有模块中，订单系统作为最为核心的模块，它决定了整个流程能不能顺畅的执行，起着承上启下的作用。

订单系统设计订单系统时需要考虑几个模块。只有明确考虑所有模块，才能保证订单系统的稳定性和可扩展性。

1. 订单字段

实际上，界面上显示的订单信息由各种订单字段组成。完成订单字段在某种程度上代表着订单流程的完整。

订单字段包括几个部分，其中金额信息因为特殊性，单独来讲解，本质上，金额信息也是属于商品信息的。

商品信息：商品信息属于订单系统的上游端。所有订单都是从商品演变而来的。从商品到订单，订单系统必须收集相关的商品信息，包括商店信息，商品ID，商品规格，商品数量和商品价格。获得的商品信息将显示在订单详细信息页面上。形成订单信息后，仓库可以方便地进行拣选和打包。

用户信息：用户信息包括购买用户的ID，收货人，收货人地址和联系信息。某些平台的用户成长系统是根据平台上的用户活跃度来计算的。例如，京东（http://JD.com）具有类似的增长指标，例如会员级别和积分卡。此时，除了普通信息字段外，还需要获得用户信息。获取用户级别，购买后获得的积分以及用户所在等级可以从订单中扣除的折扣等，然而这些具体操作取决于公司的业务方向。

金额信息：由于金额信息的特殊性，理论上认为金额信息应该属于商品信息。金额信息的特殊性在于它不代表金额，涉及到商品的金额，折扣金额和付款金额等。折扣金额所涉及的信息更为复杂。例如，具有自营和第三方结算的电子商务平台将具有商家折扣和跨商店折扣。这些折扣分为不同的类型，例如现金扣减和消费者优惠券扣减，点数获取，礼品卡扣减或以上各项的组合。如果要很好地涉及此内容，则需要根据公司的当前业务状况列出支持的优惠类型，然后枚举各种组合下的优惠类型以确保流程的完整性。

时间信息：记录各个状态点下的时间，一是记录，二也是方便售后验证与客户分析。订单时间是根据订单状态改变而改变的。时间信息看起来不重要，其实是订单系统一个重要的组成部分，具体看以下：下单未付款：即订单创建时间、下单时间；待发货状态：订单创建时间、下单时间、支付时间；待收货状态：订单创建时间、下单时间、支付时间、发货时间；交易完成状态：订单创建时间、下单时间、支付时间、发货时间、完成时间；待退款状态：退款订单创建时间、申请退款时间；交易关闭-用户取消：订单创建时间、下单时间、用户取消时间；交易关闭-仅退款：订单创建时间、下单时间、支付时间、退款申请时间、退款成功时间；交易关闭-退货退款（包含部分仅退款）：订单创建时间、下单时间、支付时间、交易完成时间、退款申请时间、退款时间。

订单信息：订单信息在订单系统是最为核心，订单信息最重要的又是订单的状态。一个电商系统中，订单状态分别有以下几种状态：【待付款】、【待发货】、【待收货】、【待评价】、【交易完成】、【用户取消】、【仅退款】、【退货退款】。而我们一般会将后三种统一放在订单售后独立呈现，方便平时商家操作的便捷性。下面看看流程图：

2. 订单流程

订单流程是指从订单生成到完成的过程，包括前正向流程和反向流程。

正向流程就是正常的网购的步骤：订单生成->付款订单->卖方发货->确认收货->交易成功。

而逆向流程则是各种退款退货的流程。

（1）正向流程

订单生成：用户下单后，系统需要生成订单，此时需要先获取下单中涉及的商品信息，然后获取该商品所涉及到的优惠信息，如果商品不参与优惠信息，则无此环节。

接着获取该账户的会员权益（这里其实需要注意的是：优惠信息与会员权益是有区别的，就好比商品满减是优惠信息，新人立减是会员权益，一个是针对商品，另一个是针对账户）。

支付订单：用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，往往还有一种情况存在，很正常却也比较复杂，就是订单拆单。

• 订单拆单分两种：一种是用户挑选的商品来自于不同渠道（自营与商家，商家与商家），此时就需要拆分订单，并分开结算，这里还涉及父子订单的说法，这里不再赘述。
• 另一种是在SKU层面上拆分订单：不同仓库，不同运输要求的SKU，包裹重量体积限制等因素都需要将订单拆分。比如：商品A只在甲仓库有，商品B又只在乙仓库有，此时会将商品A与商品B拆分成两个订单。或者有些企业的做法是将商品A/B调拨到另外一个仓库统一发货，也方便了用户。

订单拆单看起来简单，其实里面涉及到底层的系统支持，如你需要对每一个仓库的货品进行相对准确的盘点，且做到实时同步（涉及到仓库精细化管理），对商品进行准确分类与摆放，对商品信息记录准确无误等。

这其中哪一模块都是一个浩大的工程，PM一般进入一家公司都会在原有（半成品）的基础上进行优化，大家不妨多思考一下底层业务，只有在底层做好精细化管理，才能支持线上丰富的用户需求。

商家发货：商家发货过程也有一个标准化的流程，上面也有讲到，订单拆分时会涉及到仓库间调拨，然后仓库会对商品进行打单、拣货、包装、交接快递配送。这套标准化流程如果优化好，也是一个大工程，这里不再赘述，建议大家看看库存与仓库管理方面的书籍，详细了解。

确认收货：商家发货后，就是等快递配送了，订单系统需要接入一些常用快递企业的接口，方便用户与商家在站内查询快递信息。

交易成功：收到货后，不是一个服务的结束，相反是一个服务的开始。订单系统需要在快递被签收后提醒用户对商品做评价，这里要注意，确认收到货不代表交易成功，交易成功是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程就算走完了。

（2）逆向流程

一个电商的基本逆向流程如上图所示，订单的逆向流程复杂就在于它几乎允许在正向流程的任何环节出现。有人会问：用户未收到货为什么还能退款？

其实我们换位思考，也很容易理解。假想你是用户，买了一双鞋子，付了款发了货，正在美滋滋的等待收快递，然后刚好路过一家鞋店看到刚买的同款鞋子大促销，于是你就拿起手机点击退款，买下了这双促销的鞋子。

这种场景其实是很普通也很正常的用户日常，所以我们的订单系统就必须得支持用户各种丰富的场景需求，也十分考验PM的业务渗透能力，好在电商的先行者淘宝已经做了很多基础建设和用户教育，我们直接可以拿来套用，不过还是要根据各个公司的业务情况进行修改。

取消订单：用户提交订单时，在跳转至支付前直接退出，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回即可。

支付失败：用户进行支付时退出，或者取消支付，我们将其列为支付失败状态，此时处理同上，将扣减的库存补回可销售库存即可。

付款后退款：用户支付成功后，商家还未发货，支持用户申请退款，此时如果仓库与客服是分离的，则需要先检查仓库是否已经发货，若已发货则应与客户沟通是否可以收到货后再进行退款，如果仓库还未发货，则可直接同意用户退款。或者企业接入菜鸟物流，实行截件功能，不过这种操作还不成熟，成本会比较大，不适合中小创业型公司。

缺货退款：用户支付成功后，商家发货时发现仓库缺货（如果提交订单扣减库存，则会减少缺货情况，为什么是减少而不是避免？因为仓库管理商品时没办法做到100%精准，所以信息有时候会不准确，导致线上的可销售库存显示有库存而仓库已经售空的状态），则需要与用户协商是否退款。

这个流程订单系统可以做到流程化、自动化，连接消息中心和仓库管理系统去实现，难点在于消息的实时性。我就遇到过在淘宝买过一件上衣，一天过去了，商家跟我说没货了，我当时杀人的心都有了。

待收货退款：这个问题目前还没有特别完美的解决方法，商家发了货之后，用户还未收到货，此时货在路上。大体上分为两种做法：一种是用户收到货后重新寄回；另一种是用户直接拒收包裹，包裹直接退回原地址。

退货退款：用户收到货后，想要申请售后，则此时需要提供让用户输入售后原因，包括上传凭证的功能，如果与商家协商无果，还需要增加平台客服的入口，方便用户进行申诉。而协商结果/申诉成功后直接触发自动退款机制，退款后触发消息通知，同时触发交易关闭状态，整个售后过程才算结束。

系统的学习PHP

1、全流程开发 TP6.0实战高并发电商服务系统

2、产品经理高清实战

3、设计模式实例剖析与深入解读

4、Git&GitHub视频教程
 
5、尚硅谷Redis

6、SQL 注入及如何防止

领取方式：点赞关注小编后私信【资料】获取资料领取方式！