电子商务的订单拆单

拆分订单服务是为了适应不同商品、库区及灵活的发货方式,我们将对订单状况进行更加细致的跟踪。同时向客户提供准确的商品预计发货时间和预计送达时间,使我们能更及时地兑现对客户的承诺。

业务上我们有自营及商家在平台上进行售卖商品,我们有自已的供应链和仓储系统,因此我们要适应这两种模式,同时不能推翻订单状态对整个业务生命周期的决定作用,还要兼顾售后和财务结算需求,我们一开始只有商家进驻业务这时各方可能考虑不能全盘,因此我们现在处处受困,一动就牵动全局,但是现在我们业务在做大,做全,因此调整还是要站在全盘的角度去考虑问题。

从原则上来说我们还是要业务解耦,并且增强未来需求的可扩展性、前瞻性、灵活性;

1、用户将商家加入购物袋,去结算,创建订单主数据;

 购物袋有5件商品: 

1、自营 鞋子 广州仓

2、自营 雨伞 湖北仓

3、商家A 冰箱

4、商家A 大电视

5、商家B 垃圾桶

创建完订单后,用户的订单主数据有1个订单,5件商品;没有任何拆单逻辑;在没有流入OMS之前,可以取消订单;一旦到OMS拆单中,状态为“审核”不可取消订单;

此时,用户展示的就是下单时原原本本下单的数据;

2、订单主数据流入OMS自动拆单系统;

   异步通知OMS对订单主数据进行拆分,拿到订单号后,OMS根据自动规则进行拆分:

A、商家发货的按商家拆单,自营的根据订单发货地址及商品所在的仓库及库存拆单;拆单后的订单状态为:“待发货”;

B、没有库存的商品需要拆单,有库存的可先发货;

其他规则不细说

自动拆单后订单根据规则拆分成4个订单:

订单1 自营 鞋子 广州仓 发货;

订单2、自营 雨伞 湖北仓发货;

订单3、商家A 冰箱 大电视;

订单4、商家B 垃圾桶;

系统异步拆单后,OMS维护主数据订单与子单之间的关系,回写到订单,订单库中就有4个订单,同时告知用户前端,你的订单因为XXXX原因,为了方面你跟踪,我们拆分了订单,订单的状态为“待发货”,此时用户展示有4个订单;

3、根据不同的平台,分流到进行发货;

由上面拆分后的订单可以看出,订单1,订单2均为自营的,因此自营订单可以流入到WMS系统,仓库根据入库单进行发货,那么此时自营的订单1,发了1个包裹,订单1就有了包裹信息了,并且订单状态更新为“已发货”,订单2也是如此;

(如果是订单1和订单2在同一仓库,那么可能会进行同一个包裹发货,此时,订单1,订单2对应一个物流包裹)订单3,订单4 分别由商家A、商家B进行发货,商家A因为有大件的冰箱和大电视,需要分2个包裹进行发货,那么商家此时可以根据发货的不同商品对应的包裹信息进行2次拆单的操作。   

2次拆单后订单根据发货包裹情况分成5个订单:

订单1 自营 鞋子 广州仓 发货;

订单2、自营 雨伞 湖北仓发货;

订单3、商家A 冰箱

订单4、商家A大电视;

订单5、商家B 垃圾桶;

商家ERP进行发货后,包裹信息有了,并且订单状态更新为“已发货”;

此时,用户前端可以看到5个订单,对应5个包裹信息,整个业务流程还是根据每个子单的状态进行衔接和流转。

至于财务需要的数据,可以在2次拆单并且确认收货后的状态数据上,做一中间层进行清洗,按商家、档期(订单上不管自营还是商家都有商家ID,订单商品上有档期ID)行拆分即满足结算的需求;

至此大体思路比较清晰,业务系统解耦:

服务化:主要是处理核心交易流程(成单、支付、取消),和用户支付过程,拆单逻辑原理在订单上同步处理,理论上如果不处理拆单逻辑,肯定性能有所提高;

OMS:订单管理系统,处理核心的自动拆单流程,维护主数据订单与子单之间的关系,有拆单规则配置,处理2次拆单按实际包裹拆单,并且回写订单库,所有订单的拆分合并核心业务都在此系统上处理,上对订单服务化,下接商家ERP和WMS,同时以后还要支持扩展用户按最快发货方式,用户手动拆单,已经在“发货”状态的订单不能拆分;

商家ERP:接受OMS的商家订单,承接商家订单后台的发货功能,需要调整为可以根据商品按批次发货,并且通知OMS,OMS根据实际发包情况进行2次拆分;

WMS:接受OMS的入仓出库单,并且根据仓库实际操作情况发包裹,如果有拆包或者合包的过程,通知OMS进行2次拆单,如果没有,那么自动拆单的订单会挂上包裹信息;

前端用户展示:

1、成单时,用户看到一个总订单,如果未进入OMS进行拆单,可以进行取消(因为OMS异步返回时间也是非常短,因此可以不考虑主单取消的情况);

2、自动拆单后,用户会看到因为某些原因主订单被拆分,分别跟踪;

3、如果有2次拆单的情况,用户会看到订单再次被拆分,分别跟踪,单独对拆分的订单也就是对应到包裹进行确认收货;

售后、客服:可以根据拆分后子订单进行售后;

财务:可以在2次拆单并且确认收货后的状态数据上,做一中间层进行清洗,按商家、档期(订单上不管自营还是商家都有商家ID,订单商品上有档期ID)行拆分即满足结算的需求。

边界定义清晰,剩下的就是具体各子系统之间业务交互的具体实现,包括正常流程、和异常流程的考虑。全盘梳理及重新设计肯定是要大决心去推翻原来的东西,但是,如果设计和规划不合理,后面的扩展性很差,那工作量将不可想象,业务模型不正确的情况下,最关键的数据模型落地后是无法扭转过来的,请三思。

参考其他电商的一些拆单规则

1. 您的订单中含有不可以同时打包配送的商品(高价值商品、大件商品、食品、危险品如香水等不可以和其他商品一起打包配送),系统将自动拆分订单;

2. 您的订单中的包裹重量超重,体积超大,商品数量超量,系统将自动拆分订单;

3. 您的订单中部分商品可以随时发货,其他商品没有库存或者暂时没有上市需要等待货源,等待时间超过10天仍没有发货,系统将自动拆分订单;

4. 您的订单中商品超过了预计发货期,系统将在第二天的晚间自动拆分订单,将可以发货的商品先行发货;

5. 您的订单中商品需要从不同库房发出,系统将自动拆分订单;

6. 您的订单中商品其中一个在订购时库存显示只有一个,如果同时有多个订单订购,该商品需要等系统的分配,系统将自动拆分订单;

7. 您的订单中包含了入驻卖家的商品(卖家独立配送)和平台负责配送的商品,系统将自动拆分订单

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇