前言訂單產生後，接下來會繼續進行一系列流轉，最後送到用戶手裡。在每個環節都有對應的操作，數據信息也要求其完成性，可以根據訂單的每個狀態變化，來計算分析，進而進行優化供應鏈路徑，以提升訂單處理效率，提高用戶體驗。本篇就依據經驗從訂單信息及訂單狀態兩方面拆解來說下本人對訂單涉及的系統或業務流程。
訂單的流轉效率取決於信息系統的數據流轉同時結合倉庫、快遞的商品流轉，所以有幾個關鍵欄位要提前關注並了解。
訂單生成時簡單說了下訂單信息包括訂單基本信息與訂單商品信息，還包括很多附屬信息，如支付明細、關聯用戶、使用的禮品卡明細等等，具體如下圖。
（1）訂單基本信息
訂單信息即訂單主表信息，我這裡將分為訂單號、下單用戶信息、訂單基礎信息、支付信息、收貨信息和物流信息幾個小部分。
1）訂單號：單獨列出來了，大家可能有疑問，這裡解釋一下。
2）基礎信息：
包括除單號的主要信息如來源、分類、狀態、歸屬、所屬倉庫等，由於訂單表未來是數據量最大的，所以每個欄位設計時需要考慮其真正的意義及是否能夠滿足未來的擴展。
隨著時間的推移及業務的快速變化與增長，未來有很多種可能會迫使你去加欄位或將原欄位進行二次定義，使得此表在開發過程中要進行不斷轉義才可以，大大增加了代碼的複雜度。個人是比較傾向於預定義幾個預留欄位，優劣大家在設計時去衡量吧。
3）支付信息：
支付主要是對在訂單級使用的優惠券、禮品卡、積分及折扣等，在前端訂單進入到結算頁時會根據相關信息進行計算並記錄，同時在單據查時一般遵循：訂單金額 -優惠券-禮品卡-積分=應付金額;訂單金額=訂單商品金額+運費金額;訂單商品金額=商品實際售價*商品售賣數量。
4）收貨信息：
訂單的下單用戶與收貨人可能是不同的，為了更好的提高用戶體驗，有的訂單可以預約送貨時間等，所以此部分信息可以單獨列出來或以附屬信息進行護展。
5）物流信息：
這裡需要記錄快遞公司及物流單號，與物流明細信息進行關聯調用。
（2）訂單商品信息
這個表是交易的明細商品信息，自然包括商品的基本信息，同時包括交易時的商品價格、優惠信息，同時還應包括交易過程中商品參與的活動等信息。
商品信息表是訂單從表，數據量是訂單表的幾倍或十幾倍，同時對於訂單級別的一些優惠金額需要根據商品進行分攤。由於發票是根據商品信息進行的，所以在分攤金額時要注意尾差；同時在訂單發生退換貨時是要根據商品進行金額的重攤重算。
對於退換貨時的重攤重算，這裡囉嗦一下，是針對於用戶下單時已經享受了訂單級或商品的促銷活動，當發生退貨或換貨後由於商品發生變化，使得訂單級或換的商品不能再享受其促銷優惠了，需要重新計算優惠金額的過程。
（3）開票信息
對於開票信息，從京東上截了一張圖片，參考下即可。
（4）支付明細
對於支付，在訂單生成時簡單聊過，這裡強調一下是針對於各種支付方式的支付明細數據。以前說過，涉及到錢的信息不能馬虎，一定要記錄清楚，要有交易流水號（我司或第三方機構的），有狀態變化的過程即支付日誌。
此部分後續會進入到財務系統進行應收對帳，同時發生退款時需要檢驗。對於支付系統如何設計與研發就不囉嗦了，官方的話就是要保證數據的準確、及時以及發生異常後的補償措施；在結算時要儘可能提升響應時間，哪怕1ms也可能大大提升用戶體驗。
對於支付，一般都是按父訂單進行的，後續如果發生拆單，則相關的支付信息還需要通過父單號進行關聯。
（5）物流明細
下面根據狀態分解時，仍會提到，這裡也只展示一張圖片供參考。
（6）訂單附屬表
此部分是根據實際業務情況進行設計，譬如訂單支付過程使用了禮品卡，那麼就需要記錄禮品卡與訂單號的關係，同時記錄使用了多少錢，餘額是多少，什麼時間扣款的，這些需要與禮品卡系統進行關聯，以保證此用戶名下的禮品的金額變化是有跡可循的。
同理，積分支付需要記錄使用積分支付時多少積分抵多少錢，此訂單用了多少積分，用戶還有多少積分餘額等這些時點性的信息。
還是那句話，與錢相關的信息馬虎不得；對於其它需要記錄的信息，如果不方便或不能記錄在訂單請表或商品表中，都可以通過附加表方式。但要清楚附屬表越多，代碼可能會複雜，但對於遷庫遷表可能會容易些。
至此，對於訂單信息的分解就算完成了，訂單一般都會經過拆單即一個訂單會拆分成不同的子訂單，後續的履單都是根據子訂單進行的，下面從狀態的角度再來梳理下。
訂單的狀態，我將其分為三部分：
下面，按照新建到用戶籤收這一個完整過程來分別說下我的理解。
新建：即用戶選擇商品後，提交後產生的新訂單。訂單產生前是根據用戶選擇的收貨地址進行商品的庫存判斷、商品的優惠活動、訂單的優惠活動以及用戶選擇的支付方式、開票信息等生成的，詳細過程大家可以參照《電商後臺-訂單生成》。
支付：用戶支付已提交的訂單，這時就需要記錄支付的詳細信息，支付完成後，訂單狀態就變為已支付，此時訂單距離發貨還需要經歷幾個過程。
待發貨：在此狀態的訂單有可能沒有下發到倉庫，也可能已經下發了。但在此時，訂單都是可以取消的。
看上面的圖中，訂單在發貨前每個狀態理論上都可以取消（用戶主動或被動）。
訂單取消後，狀態就變為取消狀態，這個狀態我理解為是訂單的終結狀態中一個（取消、無效、關閉或籤收）。
在此取消訂單如果沒有發生拆單，則可以根據支付或未支付進行，即涉不涉及用戶退款;如果發生拆單，則訂單是要根據子訂單進行取消了，而且在取消過程中是否要判斷是否可以取消，這就涉及促銷或贈品或訂單分類等信息，細節不說了。
這裡補充一個訂單狀態，即如果訂單發生拆單後其父訂單的狀態是什麼？一般設置為無效訂單，這個也是訂單的一個終結狀態。
接收訂單：這個狀態在WMS系統中可能定義為待分揀或其它名稱，在上位系統就是已下發或待發貨。此時訂單就開始在WMS系統中進行流轉了，但用戶一般不會關注你具體的履單節點，他最關心的是你發貨還是沒發。
分揀/打包/發貨：這幾個狀態都是倉儲或商家的作業過程，其發貨速度是用戶關注的，一般上位系統只關注於何時發貨，如果沒有及時操作會進行提醒。對於這些狀態的變化，雖然是倉儲中的，但是我認為需要同步到OMS系統中，這樣可以分析訂單的時效，而且對於售後也是有幫助的。
一般情況下，在訂單還沒有開始分揀時，用戶或系統仍然可以取消的，具體看訂單取消的環節是如何設計的。
已發貨：當倉庫或商家操作發貨後，訂單便進入到下一個狀態過程，即物流狀態。此時的訂單已經打包完成了，此時訂單是不允許取消了，如果用戶不要，那麼只能進行攔截進行拒收處理。
物流狀態信息：主要是四個節點，「已攬收->運輸中->已派件->已籤收」，這些都是對接第三方物流信息獲取的。這些狀態信息一般與訂單主狀態是分離的，記錄在訂單信息中的物流明細表中。在與物流公司對接時，它們會有很多狀態碼，哪些展示給用戶，哪些不展示給用戶可以根據情況進行篩選。但最好與物流的官方保持一致，因為有的用戶會去快遞的官網查詢，如果有異常會進行投訴。
由於對接的是快遞公司的開放接口，有些信息是要進行脫敏的，有些信息是要保存的，物流狀態的更新需要及時，以便讓用戶看到最新信息。
籤收：用戶收到貨後籤字確認，此單完成。如果後續涉及質量等問題，就需要走售後流程。
拒收：淘寶訂單一般很少有拒收，因為商家一般都要求先籤收拍照後走售後（有的商品可以）。在大的垂直電商網站下單一般自營商品可以拒收。現在基本上沒有貨到付款了，在幾年前購買商品可以選擇貨到付款，對於商品用問題或不滿意的用戶可以非常坦然的拒收，因為你沒有付錢。雖然現在有支付寶等第三方支付了，但是拒收時涉及到與快遞、商家三方的溝通，也是比較麻煩的。
商品拒收後，對於第三方物流是屬於一個新的單子，快遞費誰支付（用戶還是商家）是個問題，所以一般都是先籤收後退。
寫到這裡應該可以簡單的了解了訂單生成後，根據相關的狀態再一次了解了單據流轉過程。
了解了訂單信息的組成以及相關的狀態，相信對於後續業務的理解與方案設計會有一點點幫助，但這些都是非常泛的理解，對於退貨的逆向流程也沒有總結，在設計產品時一般對於正向的標準流程處理基本都是比較容易的，複雜的都是逆向或異常情況的考慮。
為什麼要考慮這麼多的異常情況呢？其實最主要的還是責任及信任。後續針對訂單的售後退換貨流程結合客服系統再進行總結。
感謝您的閱讀！
作者：倔強的大蘿蔔；公眾號：倔強的大蘿蔔
本文由 @倔強的大蘿蔔 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議