Java生鮮電商平臺-訂單配送模塊的架構與設計

Java生鮮電商平臺-訂單配送模塊的架構與設計

 

生鮮電商系統最終的目的仍是用戶下單支付購買，

因此訂單管理系統是電商系統中最爲複雜的系統，其做爲中樞決定着整個商城的運轉，

本文將對於生鮮類電商平臺的訂單設計作一個完整的分析，也對前階段工做作一個覆盤總結

 

 

訂單系統設計的好壞，決定了平臺的可用性、後期的功能拓展和商城價值；訂單系統貫穿於整個商城系統，其餘各個系統的設計也是爲訂單系統提供數據支撐。從用戶提交訂單的那一刻到訂單完成，到售後，都須要訂單管理系統來管理。

訂單管理系統從流程生成過程，大體分爲三部分：

1.階段1、訂單生成過程：用戶經過平臺選擇商品，選擇添加至購物車（某些平臺下單過程無加入購物車流程），生成訂單價格，提交訂單，後臺根據優惠信息、活動信息、會員價等生成訂單金額，通常具體到每一個商品訂單實付金額。

2.階段2、訂單配送過程：用戶支付完成，從倉儲發貨、配送、用戶收貨後訂單完成，如無提起售後流程，通常訂單到此就算完成，正常的訂單到階段二流程即結束了。

3.階段3、訂單異常、售後流程：用戶在前兩個階段過程當中發起支付取消、提起商品售後流程，通常在訂單商品配送過程當中是不容許用戶發起退款，等用戶收到貨物後纔可發起售後，對於生鮮類平臺，可能不會作退貨的功能。

1、訂單生成過程

首先，是用戶在商城內選購商品，這個階段能夠叫作用戶購物行爲。

而後，是系統調取各個系統的數據，計算訂單的最終價格，這個階段能夠叫作數據處理過程。

最後，是將訂單價格在用戶端顯示，這個階段叫作表現層顯示。

 

訂單數據流程

一、訂單提交生成過程

用戶下單後系統須要生成訂單，生成訂單過程需獲取商品信息，商品是否涉及相關優惠活動；獲取用戶會員信息（因爲小程序作了付費會員，付費會員與普通會員購物部分商品有不一樣優惠力度和商品價格差別）。

用戶提交商品訂單時須要考慮商品庫存問題：1.用戶提交訂單時鎖定商品庫存，即下單減庫存。2.用戶付款後鎖定商品庫存。什麼時候鎖定商品庫存得看具體狀況，我的感受下單鎖庫存在商品庫存很少，商品暢銷狀況下用戶體驗更好，避免在用戶支付完成後商家無庫存發貨。因爲社區生鮮類商品，貨損較嚴重，因此設計爲用戶付款後鎖定庫存。

二、支付訂單後是否須要拆單/合單

訂單拆單：客戶同時在多家店鋪下單，不一樣的店鋪的商品在正常狀況下是要拆開的；自營平臺商品的訂單是否須要拆單根據發貨倉是否相同，發貨倉不一樣，也是須要根據商品發貨單進行拆單。總之同一個訂單，會有多個包裹多個運單發貨，就須要將訂單查看。

訂單合單：同一個用戶不一樣訂單須要考慮是否合單發貨，需根據實際狀況而定，訂單合單後，多個訂單生成一個發貨單發貨。

三、訂單商品優惠分攤

1. 爲何要對訂單金額進行分攤？

首要因素是退款，在訂單付款成功以後，若是不針對單個商品進行金額分攤，那麼若是用戶須要退訂單中的部分商品，無法計算須要退的金額。一樣若是隻是單一商品品類券，則根據符合優惠券使用條件的商品進行分攤，其餘商品按照商品售賣價格。

財務對帳：將優惠金額分攤到每一個商品上，能覈算統一訂單下的每一個商品分別分攤的優惠金額，好比：平臺券，一個使用平臺券的訂單最終須要計算每一個商品分攤的優惠金額，以肯定每一個商品的實際付款金額和享受平臺優惠的金額。

覈算成本：經過把優惠金額分攤到每一個商品上去，運營，財務或採購人員能夠評估營銷活動的成本。

2. 優惠金額分攤邏輯

按照最小維度進行分攤：即優惠金額須要分攤到每一個商品，且同一個商品採購數量大於1時，該商品最終只能有一個分攤後的價格

優惠分攤比例：按照商品金額分攤對應比例的優惠，保證不一樣商品享受優惠的公平性，不然會出現商品應分攤的優惠大於商品的銷售價或影響用戶體驗。

偏差處理：減少偏差主要途徑是在算法層面上進行優化，同時也沒法避免偏差，多餘的偏差須要按照不一樣的優惠活動分別存儲起來，在財務對帳和退款的時候須要用到。

這裏必須提一下，這裏訂單商品優惠分攤的前提是訂單中商品符合優惠條件，訂單中不符合優惠條件的商品不參與優惠分攤。

2、訂單配送過程

用戶在下單完成後，限制了用戶退款訂單狀態，只容許用戶在訂單狀態爲：待發貨和配送完成狀態下才能夠申請退款。支付完成後訂單發貨狀態共分爲：待發貨、分揀中、配送中、商品到達代收點、配送完成、用戶已取貨這幾個狀態。

 

訂單生成配送過程

一、針對有缺貨/無貨狀況

避免生鮮水果類商品的貨損過大問題，倉儲通常備貨較少，有時需及時從生產商拿貨，就可能會出現商品不足、無貨的狀況，如發生缺貨、無貨的狀況，是否補單發貨，仍是直接退款給用戶

生成補貨單發貨或者退款：在倉儲發貨分揀發現缺貨、無貨狀況時可發起異常配送流程，針對缺貨、無貨的商品按照訂單生成時間判斷影響了具體哪些用戶訂單，在缺貨、無貨商品訂單中操做想應的補貨或者退款操做

這裏須要說明一點，咱們強調的是客服主動跟受影響的用戶進行溝通，而非系統自動發起補貨或退款。

二、用戶同一天下單屢次的訂單是否須要合單發貨

針對同一用戶同一天內的訂單是否須要合成一個發貨單發貨，須要根據具體場景具體考慮，若是作了合成一個發貨單，幾單包裹在一塊兒是否一個包裹能裝下，若是是須要兩三個包裹裝的話，只有一個發貨單如何處理，都是須要考慮解決方案。

3、訂單異常、售後流程

訂單售後通常包括未支付訂單取消、下單完成後未配送前發起退款申請，配送完成後的訂單申請售後過程，未支付訂單的取消和下單完成後未配送前發起的退款申請，系統在接收到退款申請時會自動給用戶訂單退款；配送完成後的訂單因爲商品性質的緣由，限定了不支持無理由退貨退款，而且沒有作退貨流程的處理，主要考慮到商品退回至倉庫已無價值。

訂單系統逆流程的分支不少，須要兼顧業務場景，通常在從0到1的過程當中，售後流程會先經過線下的方式解決，以便能把資源集中在更核心的部分。