订单系统详解

订单系统作为一个业务子系统，在电商、零售、餐饮、教育、医疗saas系统中都非经常 见。

只要平台存在交易行为，那么必定 逃不开订单系统，因为最终都需要通过创建  订单，并支付，从而完成交易。

由于订单系统的高涌现 频率，且不合  业务的订单设计思路年夜 同小异，所以我们可以把它作为一个底层系统进行抽象，建立一套订单的设计模型，便于我们快速应用到各个业务系统之中。

订单系统架构

No. 1

以电商为例：

订单作为电商最庞杂 的核心系统（或者称之模块），它建立其他系统模块之上。

包含 但不限于商品、优惠券、会员、营销活动、地址信息、积分、运费、购物车、支付、发收货等模块，都和订单息息相关，任何一个模块的修改 ，都可能影响到订单。不夸张的说，订单是交易平台最核心的子系统。

订单包含  的信息：

电商订单系统架构：

因此做好订单治理 ，最重要的是笼罩 的全面性、和极强的可扩展性。

订单系统模块拆分

No. 2

订单主要分：订单创建  和订单治理 两部分  .

一、订单创建  ：

订单创建  可以由C端用户、以及B端使用者提议 创建  ，并在订单系统中生成。

订单创建  的节点，在页面上的展示，就是提交订单页面点击“提交订单”按钮那一刻，订单就会被创建  。

当然外面 上看，点击“提交订单”就触发了订单创建  ，但背后，创建  进程 会挪用 前面所说的各个模块，并且  夹杂了年夜 量的逻辑判断。

提交订单页原型：

以下为订单生成的校验：

即在“提交订单”那一刻，会进行多个信息的逻辑判断

配送信息：配送方法 和配送地址。

需判断是否填写了配送方法 和地址；（如果是外卖）配送地址是否跨越 配送范围  ；

商品

需判断商品是否是上架状态；商品是否售罄；商品库存是否小于订单中的商品数量；（如有赠品赠送）需判断赠品是否库存不足；

运费

选择收获地址后，会依据 后台的运费模版自动进行运费计算，并回显在【提交订单】页；提交订单时需要校验运费信息是否更改 ；

促销活动

需判断当前该用户、该订单商品适用的所有促销活动。促销活动一般分平台级、商号 级2个层级

平台级：针对平台内商品的促销活动；商号 级：针对商号 内商品的促销活动。

当然一般这类活动还有一些限制条件，比如  

订单满若干 金额才可以介入 只限一定品级 的会员只限某些类目，或指定商品才可以介入 如果同时满足多个活动介入 的条件，则只能介入 优先级最高的活动；

等等，视促销活动数量和庞杂 度而定。

会员优惠

提交订单时需判断会员品级 及相应优惠权益是否更改 ，需判断可用积分数量是否更改 。

优惠券

需要判断优惠券是否已核销；是否已过时 ；是否在适用时段内；是否已被使用等。

一旦提交订单后，则订单即完成创建  ，这个时候订单模块还会提议 指令要求其他模块进行相应的配合：

订单中的商品库存需要在商品模块中进行冻结处理  订单中使用的优惠券需要在优惠券模块中进行状态变革 订单中使用的促销活动权利应该标记  为已使用该权利订单中扣减的积分应该在用户积分中进行扣减等

当然对于外卖而言，还需要在提交订单的时候对商号 是否在休息时间、商号 是否开启该配送方法 、订单价格是否满足起送价等各类 情况进行确定，如存在更改 则给出用户相应提示。

二、订单治理

当订单被创建  后，即进入订单治理 阶段。

C端页面：

B端的订单治理 页：

订单轮转流程：

关于订单状态

从用户端（买家）角度看，电商平台的订单流转中间状态一般有如下6年夜 状态：

1）待付款：当用户提交订单后，支付之前，都属于待付款状态，商家端也是待付款状态。

2）待发货：当用户完成支付后，订单状态变革 为待发货，商家端也同步更新为“待发货”状态。

3）待收货：当商家在后台确认发货后，订单状态在买家端的显示就会酿成 “待收货”状态，在卖家端会显示“已发货”，这里两边的展示会有一个区别。

假如买家收到货一直不点确认，那么一般平台会有一个周期（淘宝是14天），14天后系统自动确认收货，变革 为交易胜利 。

4）退款中：一共两种情况会导致订单变革 为“退款中”的状态。

是在“待收货”状态下，即商家已经发货后，买家进行退款操作，那么订单状态会直接酿成 退款中；是在“待发货“状态下，买家取消订单／卖家操作全额退款，则进入退款中状态。是买家确认收货后，申请退款，则进入”退款中“状态，一般电商平台都支持确认收货后7天无理由退货

5）交易完成：一共有两种情况会导致订单变革 为”交易胜利 “

是用户确认收货；是买家申请部分  退款，退款流程结束，且剩余商品确认收货后，订单变革 为“交易胜利 ”。

6）交易封闭 ：一共有3种情况会涌现 “交易封闭 ”

是“交易胜利 ”后提议 全额退款，完成退款流程变革 为“交易封闭 ”；是在”待支付“的时候买家取消订单／订单超时过时 ）；是“待发货”的时候买家申请退款，商家确认后订单变革 为“交易封闭 ”。

关于订单中的优惠分摊

为什么要考虑优惠分摊，如果下单的时候使用了某种优惠活动，当订单进行部分  退款的时候，我们肯定不克不及 给买家直接退商品的原价，这样对卖家的损失就很年夜 了。

因此在订单生成时，就会针对使用优惠活动的商品计算优惠分摊。

举例

我们举个最简单的例子，买家购买  了一个商品A100元，一个商品B200元，提交订单时介入 了满100减50的促销活动，那么最后支付了250元。

假如买家收到货后觉得A不满意，申请退款，卖家同意后且完成退款流程后，应该退给A若干 呢？

A的退款金额=100*250/（100+200）=83.33元（保存 2位小数点）

他并不克不及 收到100元，因为假如他收到了100元，相当于最终用了150元买到了B，这是存在漏洞的。

再举个更庞杂 的案例：这个案例涉及到平台跨店促销优惠、商号 促销优惠、优惠券优惠券

举例

买家购买  了1个商品A100元（甲店）、1个商品B200元（甲店）、1个商品C300元（乙店）。

提交订单时，介入 甲店的满200减50的促销活动1，同时还介入 了平台满200减100的促销活动2，此外还使用了一张150元的平台代金券。

那么依据 优先级首先A+B的商品享受甲店的活动1后酿成 了（100+200-50）=250元，然后A+B+C继续介入 平台的活动2后酿成 了（250+300-100）=450元，最终使用一张平台代金券后支付（450-150）=300元，即最终需支付300元。

即依次依照 活动1>活动2>代金券的优先级进行介入 。

假设退款时，是无法退还代金券的，那么在订单生成时，我们来计算下每一层优惠分摊之后，A、B、C的可退金额是若干 ：

第一层：活动1分摊后

商品A=100-50/（100+200）*100=83.33元

商品B=200-50/（100+200）*200=166.67元

商品C=300元

第二层：活动2分摊后

商品A=83.33-100/550*83.33=68.18元

商品B=166.67-100/550*166.67=136.37元

商品C=300-100/550*300=245.46元

注释：83.33+166.67+300=550元

第三层：代金券分摊后

商品A=68.18-150／450*68.18=45.45元

商品B=136.37-150/450*136.37=90.91元

商品C=245.46-150/450*245.46=163.64元

注释：68.18+136.37+245.46=450元

所以经过优先级从高到底的三层优惠分摊后，A最终的实际可退金额为45.45元，B为90.91元，C为163.64元

2、关于拆单

在电商平台中，只要有购物车功能  ，就会涌现 买家跨店购买  商品的情况。

比如  一笔订单买了甲店的商品A一件，买了乙店的商品B一件，对于买家来说，他只是下了一笔订单；然则 对平台来说，需要把A的订单信息推送给甲店，把B的订单信息推送给乙店，这就需要对买家的订单进行拆单。

另外对于提交给甲店的订单来说，如果订单包含  多个商品A、B、C，可能还会涉及到发货单的拆单，比如  A、B一起发货，C零丁 发货。

作者：郑海华，深耕 B 端业务多年，熟悉电商、医疗等业务，具有多个从 0 到 1 的年夜 型产品  孵化经验。

转发了

转发了

转发了

转发了

转发了

转发了

转发了

转发了

转发了