訂單基本概念

設計訂單系統時包含幾個大的方向需要考慮，這些內容決定了訂單系統的穩定性和可持續性。

訂單欄位

訂單欄位包含了訂單中需要記錄的資訊，他的作用主要用於溝通其他系統，為下游系統提供資訊依據。

訂單資訊

訂單號作為訂單識別的標識，往往由一串數字組成，根據訂單的增加進行自增，也可以在設計訂單號的時候考慮訂單加密設定（否則別人通過訂單編號就能計算出你們家的銷售量）。訂單號後續用作訂單唯一標示用於對接 WMS 和 TMS 時的訂單識別。

訂單狀態機在下面章節會詳細描述，這裏不做展開。

使用者資訊

這裏指購買人的相關資訊，主要包括姓名、地址、手機號。 O2O 還會多一種情況就是自提點，這樣地址則會變為自提點的地址。地址資訊在後續會作用在 WMS 和 TMS 上用於區分割槽域和配送安排。

購買商品資訊

這裏指購買商品的基本資訊和庫存，金額由於比較特殊所以我把金額獨立在商品資訊以外説，不過邏輯上其實都屬於商品資訊範疇。商品資訊主要影響庫存更新和 WMS 生產。

金額資訊

訂單產生的商品資訊，這裏面除了要記錄最終的金額，過程金額也需要記錄。比如商品分攤的優惠金額、支付金額，應付金額等。在後續的訂單結算、退換貨、財務等環節都需要使用。

時間資訊

記錄訂單每個節點的觸發時間。

 

訂單流程

訂單流程是指整個訂單從產生到完成整個流轉過程。他包括正向流程和逆向流程。

正向流程

訂單正常生產到配送的過程。這裏面列舉的模組是一般電商通用的功能，部分可能根據實際業務場景有所增加調整。 020 場景下出庫、合包裹、發票準備等工作是由商家方進行，部分工作是屬於線下場景。

整個流程涉及到的環節非常多。這裏面提幾個細節上需要注意的地方：

訂單生成環節存在超時未支付自動取消的過程。庫存的佔用會在訂單取消後釋放。

如果選擇 COD（貨到付款）則支付環節相應轉移到訂單配送之後，而過程中所有與款項相關的邏輯變為只操作金額數字，不對結算和賬户進行打退款操作。

金額分攤需要到品，這個在之前解構電商、 O2O 使用者端 “背後” 的邏輯中有説明，這裏就不細説了。

訂單系統稽核主要使用者對惡意使用者或者刷單情況進行處理。系統可根據白名單、黑名單、消費頻次、促銷品購買量當方面做風控規則。如果後續會進入到人工稽核，則規則上可以適當從寬。當觸發規則需要進行訂單退訂的行為。此處設計時要小心對使用者體驗的損害，往往前台文案上説明當前節點是稽核狀態或者是等待接單。

在 O2O 領域有催單的概念，而傳統電商則是通過關聯第三方物流的物流資訊進行跟蹤。催單觸發考慮到實際場景，一般會設定一定的時間間隔，間隔時間內只觸發一次催單的請求。

預售等貨和移倉需要做成 SOA 服務，以便在交易頁面計算預計時間和預計到貨時間。移倉處理依賴倉庫的情況，也會涉及到後續拆分和合幷包裹的邏輯。

訂單生產時先要判斷報缺情況，如果出現報缺問題則要考慮整單報缺、部分報缺、換貨或者換轉退的情況（庫存，倉促調撥和退款）。報缺情況分為系統報缺和實物報缺，這是承接但相對獨立的兩個環節。

電商系統要考慮 7 天無理由退貨的情景，即訂單狀態完成後申請退貨。此時主要涉及的是金額上的計算以及一些財務程式（如發票等）問題的處理。

逆向流程

逆向流程則指訂單發生取消、退貨等情況時引發的訂單流程過程。在設計逆向流程時建議和正向獨立分開，通過訂單號等資訊進行關聯，避免耦合過多邏輯無法延展設計。

逆向流程的觸發主要有幾種情況

使用者自主取消訂單（整單）

風控系統觸發取消訂單（整單）

客服接到客訴仲裁後觸發取消訂單（整單）

超時未支付取消訂單（整單）

換貨報缺轉為退單（整單、部分報缺）

觸發條件考慮兩個方面

訂單狀態機（某一節點後如訂單生產後不允許取消訂單）

訂單生成時間（主要是 O2O 方面，考慮到配送時間和線下流程的不規範，有可能出現狀態機沒觸發更新但實際流程在流轉的情況）

其他要注意的一些內容

當退單被商家拒絕後需要轉入客服仲裁的環節

部分退的訂單促銷一般保持享用狀態，但金額按照分攤的金額進行退款。

 

訂單狀態機

關於狀態機，我在百度上搜尋了下定義。

關於狀態機的一個極度確切的描述是它是一個有向圖形，由一組節點和一組相應的轉移函式組成。狀態機通過響應一系列事件而 “執行” 。每個事件都在屬於 “當前” 節點的轉移函式的控制範圍內，其中函式的範圍是節點的一個子集。函式返回 “下一個”（也許是同一個）節點。這些節點中至少有一個必須是終態。當到達終態， 狀態機停止。

由上述定義可以看到，狀態機的概念是用來表示按照一定的方向通過觸發不同節點產生資料流轉的過程。在訂單中通過情景觸發訂單狀態的變化來表達訂單流轉的過程就是訂單狀態機。

電商

O2O

電商和 O2O 的主體流程是相同的，不同的在於物流配送環節電商較 O2O 更為複雜，此處只表明了主要的訂單狀態機，倉儲物流內的物流單流轉不在此範圍內。狀態機原則上使用結果值而不使用過程值，比如使用支付成功作為節點而不使用支付中作為節點。

訂單狀態機要融合訂單流程來設計觸發節點，訂單流程的邏輯點要多於狀態機，一般在當前流程環節完成後最後更新狀態機。

 

訂單推送

當狀態機發生變化時，需要將對應的變化情況告知給相關人員以便了解當前訂單的情況。這就是訂單推送的作用。

訂單推送的觸發依賴於狀態機的變化，涉及到的資訊包括

推送物件（使用者、物流人員、商家）

推送方式（push，簡訊）

推送節點（狀態機）

 

訂單的演變

電商平台的搭建變遷也是訂單逐步穩固發展的過程。我們來看下訂單的發展過程，結算環節由於是一個比較大的話題，這裏面不展開説明了。

 

訂單第一階段：實現訂單流轉

平台搭建的第一階段要實現基本的訂單流轉，支援一些營銷活動的購買（這裏依賴附屬系統的搭建情況，這裏預設認為具備基本功能）。

實現訂單的生成、生產

支援訂單稽核（初期可支援人工稽核即可）

支援使用者端顯示訂單相關資訊

支援促銷金額的計算

這個階段搭建時核心是解決訂單的基本流轉，所以原則上一些功能可以後續再逐步完善。比如催單、拆單、系統稽核等。

另外在搭建訂單結構的時候如果條件允許，在設計之初可以就考慮用子母單的形式，即兩層結構

母單負責訂單整體資訊的記錄

子單記錄單個商品的詳細資訊和金額情況

 

訂單第二階段：平台化搭建

隨著平台的發展，越來越多的接入方需要訂單的支援，POP 平台的商家接入、第三方倉配的接入，更多快遞合作伙伴的接入等等。訂單的功能進入第二階段的擴充。

提供訂單 soa 服務

支援跨平台交易單生成（即同一個大交易單內既有商家商品又有自營商品或者是多個商家的商品）

對接多個倉庫，支援移倉模式

根據倉配情況計算預計送達時間（訂單 promise 服務）

支援拆單、合單邏輯（配送單、支付單等）

支援快遞分單

提供更豐富的訂單推送服務，完善訂單狀態機

這裏説幾個訂單複雜化以後需要注意的細節

訂單子母單結構，便於將資訊進行梳理，減少耦合

拆單、合單邏輯主要是用於解決不同系統之間的耦合問題（如配送單主要運用於 TMS，支付單提交給支付系統）。他們都通過交易訂單資訊項重新組合後新增部分自有系統的資訊項而組成，通過訂單編號來做關聯。交易單和支付單是 1：1，交易單和物流單也叫配送單則可能是 N:N 的關係。

移倉的邏輯和預計送達時間要依賴倉配結構和運輸能力的測算，當然也可以通過拆包裹分多次發的方式減少移倉的次數，不過要考慮要前台使用者體驗和免責説明。

當自營品和商家品或者多個商家品的時候，優惠券的分攤計算要注意。要區分商家券和全場通用券可分攤的比例和優先順序。

 

訂單第三階段：更多型別的訂單模式

當平台發展到足夠大的規模，提效、穩定變成一個重要的話題。這裏面介紹兩種情況：

預售

場景：無實物庫存，但是顧客可以下單預定。當實物到貨後，按照正常訂單進行配送。

預售單需要設定預售庫存數和預計到貨時間。使用者下單後不會直接進入生產，將預售訂單放入單獨的訂單庫（或增加預售品標識）。

預售商品到貨後要判斷涉及到貨庫存和預售訂單是否相等。當實際庫存小雨預售訂單則按下單時間釋放等量訂單進行生產。系統需要回告庫存系統重新計算預售佔用庫存量。

JIT(準時制生產方式 Just In Time 簡稱 JIT）

場景：銷售驅動生產，根據訂單進行生產配送。

JIT 模式需要設定 JIT 波次情況和支援 JIT 的倉庫

相同 JIT 倉庫訂單按照 JIT 波次時間點彙總訂單並驅動產生 ERP 採購訂單；JIT 和目標倉告訴採銷系統

ERP 到貨回告訂單系統已到貨

訂單釋放進入 WMS 生產

這裏面需要説明的是 JIT 場景可以延伸為不入庫直接由 WooCommerce 供應商提供物流配送後續工作，平台提供訂單、發票等服務。這是流程會變為

訂單告知 ERP，生成採購單直接回告 WooCommerce 供應商

WooCommerce 供應商物流狀態對應訂單狀態機進行同步更新

使用者收貨後通過郵寄方式提供發票

該模式不支援換貨行為

 

結言

訂單是電商、 020 的生命中軸線，他主導、串聯了整個全部鏈路的系統。所有的系統都是圍繞訂單進行改建和擴張的。訂單系統的強壯決定了平台的穩定性。