当前位置:首页 > 经验

超详解析订单系统架构 电商订单系统产品架构

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

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

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

订单系统架构

No. 1

以电商为例:

订单作为电商最复杂的核心系统(或者称之模块),它建立其他系统模块之上。

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

订单包含的信息:

订单系统详解

电商订单系统架构:

订单系统详解

因此做好订单管理,最重要的是覆盖的全面性、和极强的可扩展性。

订单系统模块拆分

No. 2

订单主要分:订单创建和订单管理两部分.

一、订单创建:

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

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

当然表面上看,点击“提交订单”就触发了订单创建,但背后,创建过程会调用前面所说的各个模块,并且夹杂了大量的逻辑判断。

提交订单页原型:

订单系统详解

以下为订单生成的校验:

订单系统详解

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

配送信息:配送方式和配送地址。

需判断是否填写了配送方式和地址;(如果是外卖)配送地址是否超过配送范围;

商品

  1. 需判断商品是否是上架状态;
  2. 商品是否售罄;
  3. 商品库存是否小于订单中的商品数量;(如有赠品赠送)需判断赠品是否库存不足;

运费

  1. 选择收获地址后,会根据后台的运费模版自动进行运费计算,并回显在【提交订单】页;
  2. 提交订单时需要校验运费信息是否变动;

促销活动

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

  1. 平台级:针对平台内商品的促销活动;
  2. 店铺级:针对店铺内商品的促销活动。

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

  1. 订单满多少金额才可以参与
  2. 只限一定等级的会员
  3. 只限某些类目,或指定商品才可以参与
  4. 如果同时满足多个活动参与的条件,则只能参与优先级最高的活动;

等等,视促销活动数量和复杂度而定。

会员优惠

提交订单时需判断会员等级及相应优惠权益是否变动,需判断可用积分数量是否变动。

优惠券

  1. 需要判断优惠券是否已核销;
  2. 是否已过期;
  3. 是否在适用时段内;
  4. 是否已被使用等。

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

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

当然对于外卖而言,还需要在提交订单的时候对店铺是否在休息时间、店铺是否开启该配送方式、订单价格是否满足起送价等各种情况进行确定,如存在变动则给出用户相应提示。

二、订单管理

当订单被创建后,即进入订单管理阶段。

C端页面:

订单系统详解

B端的订单管理页:

订单系统详解

订单轮转流程:

订单系统详解

关于订单状态

从用户端(买家)角度看,电商平台的订单流转中间状态一般有如下6大状态:

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

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

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

假如买家收到货一直不点确认,那么一般平台会有一个周期(淘宝是14天),14天后系统自动确认收货,变更为交易成功。

4)退款中:一共两种情况会导致订单变更为“退款中”的状态。

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

5)交易完成:一共有两种情况会导致订单变更为”交易成功“

  1. 是用户确认收货;
  2. 是买家申请部分退款,退款流程结束,且剩余商品确认收货后,订单变更为“交易成功”。

6)交易关闭:一共有3种情况会出现“交易关闭”

  1. 是“交易成功”后发起全额退款,完成退款流程变更为“交易关闭”;
  2. 是在”待支付“的时候买家取消订单/订单超时过期);
  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单独发货。

声明:此文信息来源于网络,登载此文只为提供信息参考,并不用于任何商业目的。如有侵权,请及时联系我们:fendou3451@163.com
标签:

  • 关注微信

相关文章