關於訂單業務的一些思考

一、商品業務

 

業務思想：

通常的訂單業務設計：主要分爲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