关于订单业务的一些思考

1、商品业务

 

业务思想：

一般的订单业务设计：主要分为3part， 主订单表， 子订单表， 订单详情表。

                                                   图(1)

售前：拿货
售中：卖货
履约：给货
售后：退换

 

1，下单减库存，如唯品会，减30分钟，JD，减1天，天猫，减3天。

2，付款减库存，如时效性特别高的秒杀，很少见。

总结：何时减库存，最终的目的是要保障每个商品都能卖出去（卖方利益），每个人都能买到想要买的商品（买方利益），需要在买方与卖方之间权衡，现在大部分的做法就是下单减库存（保障你每个人都能买到-买方利益），但会有一定的时间限制（保障每个商品都能卖出去-卖方权益）。

 

关于下单时，订单信息+ 商品快照的使用

涉及领域 订单中心、商品中心

场景：

 

订单的逻辑的拆分：

根据以上的规则，订单逻辑上面应该按照这样的方式来拆分。

                                                                图(2)

根据以上的规则，订单逻辑上面应该按照这样的方式来拆分。

订单的金额拆分：

                                                     图(3)

这里会引入部分商品打折，部分商品搞活动，部分商品有优惠券，这种情况发生，基于这种考虑需要引入子订单的概念。

例子：营销那边有很多的优惠券和营销工具，商户可以通过营销系统的各种工具把各种优惠券派发到用户手上，怎么派发我们不管，用户手上就是一张买满500 赠送一本书的券，券A。

此时用户把sku1价值400的蛋糕（常价，非特价商品）和价值200的酒sku2(特价商品)，加入到购物车，此时用户sku1标注，买2件非特惠价的商品，可以打8折，用户就把sku3价值150的枕头加入到购物车。此时，sku1+sku3 总价打8折，sku1+sku2+sku3 8折后符合满赠，送了一本书价值0元。

同时，该用户是该店的老客户了，商城系统有积分抵扣的规则，目前该用户有200积分，按规则每10积分抵扣1毛钱，既能抵扣2块钱。

总订单：     支付金额638     金额：640     积分抵扣金额2块     运费0	子订单1：     sku1    蛋糕     总价320   商品价格400   优惠类型：优惠8折（订单表关联到某优惠类型，这里的优惠类型是优惠8折）	子订单2：   sku2  酒  总价200  商品价格200 优惠类型： 特惠价（订单表关联到某优惠类型，这里的优惠类型是特价商品）	子订单3：    sku3    枕头   总价120   商品价格150   优惠类型：优惠8折（订单表关联到某优惠类型，这里是优惠8折）	子订单4：     sku4    书   总价0   商品价格0   优惠类型：赠品（订单表关联到某优惠类型，这里是满赠）

优惠券的价值

是优惠，不是现金。

请注意电商领域通俗意义上的优惠券是指下单可以优惠金额的券，使用即作废。不是那种可以充值到账户的现金券，也不是可以使用多张的折扣券。

退款的时候优惠的金额怎么处理

如果不处理，那用户下单100+50-20优惠，如果全部退款则是退款150，很明显对商家造成营收上面的损失。

如果处理则按照”哪里优惠回哪里”的规则来处理：

• 如果是指定某件商品/某类商品的优惠券，那优惠金额肯定由该商品承担的。当退该商品，需减去优惠券金额。
• 如果是指定某些（分类、商户、活动等），那优惠金额分摊到符合资格的商品上。
• 如果是全店铺通用，那优惠金额分摊到每一个购买商品上。

分摊金额的算法有两种：

• 按照符合优惠券的商品金额进行均摊
• 按照订单剩余部分是否符合优惠券

举例：顾客购买了A商品1件90元，B商品1件30元，使用了一张优惠券满100元减20元。如果顾客想退款A商品：

• 按照算法1，提交退款的最多金额为90*(90+30-20)/(90+30)=75元。
• 按照算法2，因为商品B＜100元，则提交退款的最多金额为90-20=70元。

实际情况中方案A和B的金额，有高有低。如果由于特殊原因需要给用户多退，客服可在后台修改。

采用的是第一种，对用户比较公平，体验比较好。

    

常用的交易流程：

                                                            图(4)

我们项目现状需求的流程：

                                                           图(5)

上面的状态扭转时间是可以根据需要来调整，并设计job来做一定的自动补偿（job定时跑任务实现）和人工手动补偿（Oem页面手动触发补偿）的机制，实物商品取消订单，要考虑退款的时效性。      

 

                                                                  图(6)

对于目前项目现状的实现方案：

订单单品的思路：

mall_product_order + product_order作为订单主表（这2张表后面需要改造，可以分步进行）

字段名	类型	允许空值	默认值	是否主键	注释
orderNo					订单中心的OrderId
customerId					买家用户Id
status					订单状态
totalFee					主订单金额
create_time
update_time

 

sub_product_order（字段待补充）

字段名	类型	允许空值	默认值	是否主键	注释
orderNo					订单中心的OrderId
subOrderNo					子订单Id
totalFee					订单金额
subOrderType					子订单状态
					积分
					折扣

备注：子订单为母订单拆分出来的一个订单，子订单也含有多个商品，一个商品sku会有一个订单明细即sub_product_order_detail。

 

sub_product_order_detail(看是和sub_product_order 合并还是独立出来，字段待补充)

字段名	类型	允许空值	默认值	是否主键	注释
subOrderNo					子订单号
shopId					商户Id
goodId					商品Id
skuiId					规格Id
goods_version					商品变更的历史版本号
totalFee					商品金额
amount					单商品sku数量
be_salse_status					售后状态
					审核状态

备注: goods_version 商品库存做版本化，除上架下架操作外，商品信息没做一次修改都会生成一个版本。

 

举个例子：比如订单有A 2X10元   B 1X20元  C 3X30元 的商品， 目前对 B C 商品进行退款，  那么sub_product_order 有 A B C 3个单品的单， 对B C（BC单独发起还是合并发起都可以） 发起退款，就是按原来的全量退款来做，这样退款和订单就分离开来了，原来的退款逻辑不变。

思路还不成熟，需要考虑。

涉及修改的逻辑：

1：下单逻辑需要再调整，需要对购物车List商品进行拆单，insert到子订单表中。

2： 

 

参考文章：

B2C自营商城的订单设计方案 https://zhuanlan.zhihu.com/p/26470223?utm_source=wechat_session&utm_medium=social

大众点评订单系统分库分表实践 https://zhuanlan.zhihu.com/p/24036067?utm_source=wechat_session&utm_medium=social

B2C自营电商APP的优惠券设计方案(上篇) https://zhuanlan.zhihu.com/p/25083430

B2C自营商城的商品设计方案：http://www.woshipm.com/pd/628034.html

转载于:https://my.oschina.net/u/1187675/blog/1618297