订单系统作为一个业务子系统,在电商、零售、餐饮、教育、医疗saas系统中都非常常见。
只要平台存在交易行为,那么必然逃不开订单系统,因为最终都需要通过创建订单,并支付,从而完成交易。
由于订单系统的高出现频率,且不同业务的订单设计思路大同小异,所以我们可以把它作为一个底层系统进行抽象,建立一套订单的设计模型,便于我们快速应用到各个业务系统之中。
一、订单系统架构
以电商为例:
订单作为电商最复杂的核心系统(或者称之模块),它建立其他系统模块之上。
包括但不限于商品、优惠券、会员、营销活动、地址信息、积分、运费、购物车、支付、发收货等模块,都和订单息息相关,任何一个模块的改动,都可能影响到订单。不夸张的说,订单是交易平台最核心的子系统。
订单包含的信息:
电商订单系统架构:
因此做好订单管理,最重要的是覆盖的全面性、和极强的可扩展性。
二、订单系统模块拆分
订单主要分:订单创建和订单管理两部分.
1、订单创建
订单创建可以由C端用户、以及B端使用者发起创建,并在订单系统中生成。
订单创建的节点,在页面上的展示,就是提交订单页面点击“提交订单”按钮那一刻,订单就会被创建。
当然表面上看,点击“提交订单”就触发了订单创建,但背后,创建过程会调用前面所说的各个模块,并且夹杂了大量的逻辑判断。
提交订单页原型:
以下为订单生成的校验:
即在“提交订单”那一刻,会进行多个信息的逻辑判断
配送信息:配送方式和配送地址。
需判断是否填写了配送方式和地址;(如果是外卖)配送地址是否超过配送范围;
商品
(1)、需判断商品是否是上架状态;
(2)、商品是否售罄;
(3)、商品库存是否小于订单中的商品数量;(如有赠品赠送)需判断赠品是否库存不足;
运费
(1)、选择收获地址后,会根据后台的运费模版自动进行运费计算,并回显在【提交订单】页;
(2)、提交订单时需要校验运费信息是否变动;
促销活动
需判断当前该用户、该订单商品适用的所有促销活动。促销活动一般分平台级、店铺级2个层级
(1)、平台级:针对平台内商品的促销活动;
(2)、店铺级:针对店铺内商品的促销活动。
当然一般这类活动还有一些限制条件,比如
(1)、订单满多少金额才可以参与
(2)、只限一定等级的会员
(3)、只限某些类目,或指定商品才可以参与
(4)、如果同时满足多个活动参与的条件,则只能参与优先级最高的活动;
等等,视促销活动数量和复杂度而定。
会员优惠
提交订单时需判断会员等级及相应优惠权益是否变动,需判断可用积分数量是否变动。
优惠券
(1)、需要判断优惠券是否已核销;
(2)、是否已过期;
(3)、是否在适用时段内;
(4)、是否已被使用等。
一旦提交订单后,则订单即完成创建,这个时候订单模块还会发起指令要求其他模块进行相应的配合:
(1)、订单中的商品库存需要在商品模块中进行冻结处理
(2)、订单中使用的优惠券需要在优惠券模块中进行状态变更
(3)、订单中使用的促销活动权利应该标记为已使用该权利
(4)、订单中扣减的积分应该在用户积分中进行扣减等
当然对于外卖而言,还需要在提交订单的时候对店铺是否在休息时间、店铺是否开启该配送方式、订单价格是否满足起送价等各种情况进行确定,如存在变动则给出用户相应提示。
2、订单管理
当订单被创建后,即进入订单管理阶段。
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元
关于拆单
在电商平台中,只要有购物车功能,就会出现买家跨店购买商品的情况。
比如一笔订单买了甲店的商品A一件,买了乙店的商品B一件,对于买家来说,他只是下了一笔订单;但是对平台来说,需要把A的订单信息推送给甲店,把B的订单信息推送给乙店,这就需要对买家的订单进行拆单。
另外对于提交给甲店的订单来说,如果订单包含多个商品A、B、C,可能还会涉及到发货单的拆单,比如A、B一起发货,C单独发货。
-END-
【转载说明】  若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com