訂單系統作為電商系統的“中軸線”貫穿了整個電商系統的全部流程。所有的核心系統都是圍繞訂單進行構建的。訂單的發展也是随着電商、O2O行業發展逐漸演變進化的，今天跟大家來解構下這個平台的“生命中軸線”。

訂單基本概念

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

訂單字段

訂單字段包含了訂單中需要記錄的信息，他的作用主要用于溝通其他系統，為下遊系統提供信息依據。

訂單信息

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

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

用戶信息

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

購買商品信息

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

金額信息

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

時間信息

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

訂單流程

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

正向流程

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

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

1. 訂單生成環節存在超時未支付自動取消的過程。庫存的占用會在訂單取消後釋放。
2. 如果選擇COD（貨到付款）則支付環節相應轉移到訂單配送之後，而過程中所有與款項相關的邏輯變為隻操作金額數字，不對結算和賬戶進行打退款操作。
3. 金額分攤需要到品，這個在之前解構電商、O2O用戶端“背後”的邏輯中有說明，這裡就不細說了。
4. 訂單系統審核主要用戶對惡意用戶或者刷單情況進行處理。系統可根據白名單、黑名單、消費頻次、促銷品購買量當方面做風控規則。如果後續會進入到人工審核，則規則上可以适當從寬。當觸發規則需要進行訂單退訂的行為。此處設計時要小心對用戶體驗的損害，往往前台文案上說明當前節點是審核狀态或者是等待接單。
5. 在O2O領域有催單的概念，而傳統電商則是通過關聯第三方物流的物流信息進行跟蹤。催單觸發考慮到實際場景，一般會設定一定的時間間隔，間隔時間内隻觸發一次催單的請求。
6. 預售等貨和移倉需要做成SOA服務，以便在交易頁面計算預計時間和預計到貨時間。移倉處理依賴倉庫的情況，也會涉及到後續拆分和合并包裹的邏輯。
7. 訂單生産時先要判斷報缺情況，如果出現報缺問題則要考慮整單報缺、部分報缺、換貨或者換轉退的情況（庫存，倉促調撥和退款）。報缺情況分為系統報缺和實物報缺，這是承接但相對獨立的兩個環節。
8. 電商系統要考慮7天無理由退貨的情景，即訂單狀态完成後申請退貨。此時主要涉及的是金額上的計算以及一些财務程序（如發票等）問題的處理。

逆向流程

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

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

• 用戶自主取消訂單（整單）
• 風控系統觸發取消訂單（整單）
• 客服接到客訴仲裁後觸發取消訂單（整單）
• 超時未支付取消訂單（整單）
• 換貨報缺轉為退單（整單、部分報缺）

觸發條件考慮兩個方面

• 訂單狀态機（某一節點後如訂單生産後不允許取消訂單）
• 訂單生成時間（主要是O2O方面，考慮到配送時間和線下流程的不規範，有可能出現狀态機沒觸發更新但實際流程在流轉的情況）

其他要注意的一些内容

• 當退單被商家拒絕後需要轉入客服仲裁的環節
• 部分退的訂單促銷一般保持享用狀态，但金額按照分攤的金額進行退款。

訂單狀态機

關于狀态機，我在百度上搜索了下定義。

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

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

電商

O2O

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

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

訂單推送

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

訂單推送的觸發依賴于狀态機的變化，涉及到的信息包括

• 推送對象（用戶、物流人員、商家）
• 推送方式（push，短信）
• 推送節點（狀态機）

訂單的演變

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

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

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

1. 實現訂單的生成、生産
2. 支持訂單審核（初期可支持人工審核即可）
3. 支持用戶端顯示訂單相關信息
4. 支持促銷金額的計算

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

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

• 母單負責訂單整體信息的記錄
• 子單記錄單個商品的詳細信息和金額情況

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

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

1. 提供訂單soa服務
2. 支持跨平台交易單生成（即同一個大交易單内既有商家商品又有自營商品或者是多個商家的商品）
3. 對接多個倉庫，支持移倉模式
4. 根據倉配情況計算預計送達時間（訂單promise服務）
5. 支持拆單、合單邏輯（配送單、支付單等）
6. 支持快遞分單
7. 提供更豐富的訂單推送服務，完善訂單狀态機

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

• 訂單子母單結構，便于将信息進行梳理，減少耦合
• 拆單、合單邏輯主要是用于解決不同系統之間的耦合問題（如配送單主要運用于TMS，支付單提交給支付系統）。他們都通過交易訂單信息項重新組合後添加部分自有系統的信息項而組成，通過訂單編号來做關聯。交易單和支付單是1：1，交易單和物流單也叫配送單則可能是N:N的關系。
• 移倉的邏輯和預計送達時間要依賴倉配結構和運輸能力的測算，當然也可以通過拆包裹分多次發的方式減少移倉的次數，不過要考慮要前台用戶體驗和免責說明。
• 當自營品和商家品或者多個商家品的時候，優惠券的分攤計算要注意。要區分商家券和全場通用券可分攤的比例和優先級。

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

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

預售

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

預售單需要設置預售庫存數和預計到貨時間。用戶下單後不會直接進入生産，将預售訂單放入單獨的訂單庫（或增加預售品标識）。

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

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

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

• JIT模式需要設定JIT波次情況和支持JIT的倉庫
• 相同JIT倉庫訂單按照JIT波次時間點彙總訂單并驅動産生ERP采購訂單；JIT和目标倉告訴采銷系統
• ERP到貨回告訂單系統已到貨
• 訂單釋放進入WMS生産

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

• 訂單告知ERP，生成采購單直接回告供應商
• 供應商物流狀态對應訂單狀态機進行同步更新
• 用戶收貨後通過郵寄方式提供發票
• 該模式不支持換貨行為

結言

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部