隨着阿里、京東的崛起，中國電子商務的大門漸漸打開，越來越多的行業使用線上支付，無一例外地會用到電商系統，今天爲大家介紹一下訂單系統在垂直行業間的應用以及需要注意的細節。
今天分享將會分爲以下三個環節來闡述：
1.訂單系統的介紹
2.訂單系統的解構
3.垂直電商訂單系統設計思路
一、什麼是訂單系統？
訂單管理系統(OMS)是物流管理系統的一部分，通過對客戶下達的訂單進行管理及跟蹤，動態掌握訂單的進展和完成情況，提升物流過程中的作業效率，從而節省運作時間和作業成本，提高物流企業的市場競爭力。顧名思義，電商系統就是用戶、平臺、商戶等對於訂單的管控、跟蹤的系統，銜接着商品中心、wms、促銷系統、物流系統等，是電子商務的基礎模塊；
簡單地說訂單管理系統作爲整個電商的核心，管理着所有的交易進出，可以說沒有訂單系統電商就無法流暢地運轉；
一個好的訂單管理系統需要有很好地擴展性和流暢性，在一個電商產品從0-1的過程，訂單系統作爲其基礎模塊需要提前考慮到各系統的擴展，訂單系統如果在前期就能考慮到後面的擴展，相信對於電商的壯大會非常有幫助；
流暢性指的是整個交易鏈路需要很流暢，早期我司的訂單系統做的非常龐大，但是卻沒有考慮到流程的通暢性，導致連基礎的訂單流程都沒有辦法正常走下去，所以，在從0到1地做一套訂單系統時，需要有一些前瞻性，但落地時，以MVP去試錯；
二、訂單系統解構
1.訂單字段
訂單字段
訂單的主要信息包括支付信息 、配送信息、狀態信息、促銷信息、商品信息、用戶信息等；
支付信息：涉及支付的字段信息，主要包括支付方式、支付金額、訂單金額、優惠金額等；
促銷信息：涉及促銷的字段信息，主要包括優惠方式、優惠面額、折扣等；
商品信息：涉及訂單中的商品字段，主要包括商品名稱、單價、數量、所屬店鋪等；
時間信息：涉及訂單流轉中各個時間戳的字段，包括下單時間、支付時間、發貨時間、完成時間等
狀態信息：涉及訂單流轉中狀態變更的字段，主要包括訂單狀態、物流狀態及退款狀態等；
用戶信息：涉及用戶的信息，比如買家姓名、註冊手機號、收件人等信息；
配送信息：涉及訂單配送的基本信息，比如配送方式、物流單號等；
以上這些字段構成了訂單所需要的大部分信息；
2.訂單體系
訂單體系
可以從三個層面來了解電商的訂單管理體系，分別是用戶層、系統層和底層；
用戶層
這個比較好理解，就是用戶日常使用的功能和頁面，主要有訂單列表、訂單詳情和退款詳情等C端用戶購買時會使用到的頁面，系統層和底層模塊爲其提供支持；
系統層
在訂單管理體系中，和訂單最息息相關的交互系統主要有支付系統、訂單系統、倉儲系統；
1.支付系統
主要作用就是爲訂單提供支付支持，方便用戶使用各種支付方式進行支付，用戶支付後會將支付信息給到訂單系統；
2.訂單系統
作爲訂單管理體系的核心，起着至關重要的作用，在訂單系統中會生成訂單，審覈訂單，取消訂單，還涉及到複雜的訂單金額計算以及移庫操作；
倉儲系統：主要用來管理庫存以及發貨，訂單到達一定狀態後給到倉儲系統，用於管理對應訂單的打包、分揀、
備貨、出庫等；
底層模塊
主要包括商品、支付、用戶、營銷、訂單和消息等模塊，這些模塊共同組成了對上層業務、系統的支持；
大公司一般會將底層框架模塊化，比如商品，會構建對應的商品中心，代碼、數據庫等相對獨立，由商品中心開接口和soa，其他模塊需要使用商品中心相關功能的時候調取接口，這樣做的好處是使各個模塊底層相對獨立，便於管理及改動；
3.狀態機
狀態機
下面來說說狀態機，一般電商平臺用戶直觀能看到的狀態有上圖中列舉的幾個，包括待支付、待配送、待收貨、交易完成、退款中；
O2O沒有電商中龐大的倉儲系統，自然比電商的流程簡單些，我將從正流程分別從正流程和逆流程來介紹；
主流程
在電商中，無論是買家端還是賣家端，都會將交易主狀態分爲待付款、待發貨、待確認收貨、交易完成，但是買家端與買家端的展示邏輯稍有不同；
在買家端，買家關心的狀態無非就那麼幾個，即待付款、待發貨、待收貨和待評價，所以淘寶並未像商家端那樣將全部的狀態一一羅列出，而是保留了買家最關心的狀態，保持整個買家端的簡潔性；
而買家端中，主要解決的是商家效率的問題，所以在訂單列表中會將所有的狀態（即待付款、待發貨、已發貨、退款中、需要評價、交易完成、交易關閉）的訂單全部拉出，考慮到商家訂單較多的情況，出於對服務器查詢的考慮以及併發的考慮，增加了三個月內訂單與三個月前訂單的查詢區分；
首先說說待付款狀態，待付款狀態主要是買家下單但是沒有支付的情況，待付款狀態下淘寶的商家也可以進行一系列操作如改價等，買家也可以申請代付、批量操作；
待發貨，該狀態下會展示所有已支付，待發貨的訂單，淘寶目前支持的發貨方式主要有四種，在線下單、手填快遞單號、無紙化物流以及無需物流，操作配送之後交易狀態會變更爲待確認收貨，大型電商平臺已經採用無紙化發貨的形式進行發貨，即使用中端叫單，成功後會展示在已發貨（商家端）和待收貨（買家端）中；
待確認收貨，該狀態出於物流階段，一般會根據業務、活動等來設定自動確認收貨的時間，一般電商默認值是在發貨後的10天爲自動確認收貨時間，在雙十一、雙十二等節日，這個時間會延長到15天，另外海外購、天貓國際等海外購物的訂單自動確認時間也會相對較長，爲25天；
交易完成，該狀態由系統或者用戶觸發，在訂單確認收貨後，訂單狀態變更爲交易成功，此時系統會根據是否評價過判斷是否將訂單展示在買家端的待評價下來引導用戶對商家進行評價反饋；
退款/退貨流程
一般電商中訂單的逆流程主要分爲退款流程和退貨流程，這裏簡單地介紹下，後續會有專題來講述；
發貨前的逆流程
發貨前的狀態一般有待支付和待發貨兩個，待支付的訂單發起逆流程後無需商家確認，直接關閉訂單；
而待發貨的訂單發起後需要走商家的審覈，商家同意後訂單變爲交易關閉，觸發退款；
發貨後的逆流程
發貨後的逆流程主要包括待確認收貨和交易成功的逆流程；
大致分爲需要僅退款和退貨退款；
僅退款：未收到貨或與賣家協商同意後的申請，賣家同意後無需物流；
退貨退款：已收到貨需要退換的情況，賣家同意後需要走物流；
Po上我司的退款流程作爲後續專題的引子吧，敬請期待...
引子
3、某垂直電商設計思路
筆者的公司屬於某個垂直行業的電商，主要以B2B轉單爲主，將線上的訂單轉給線下門店進行配送，所以暫時不涉及商品、庫存、倉庫等；
以下是我司的訂單流程，線上商家將訂單轉給線下門店，涉及的狀態有待派單、待支付、待接單、待配送、待轉賬和交易完成；
在設計主流程的時候並不複雜，根據業務場景進行設計即可，真正複雜的部分在訂單的逆流程與系統間的交互；
由於舊版的系統過於臃腫，沒有辦法在其上進行迭代，加之流程上有很多問題，所以打算從業務流程、系統框架、視覺設計等方面做個大改版，即解決用戶使用流程中的問題，也便於後期業務功能的實現；
我司狀態機
作者：尼大歐
鏈接：https://www.jianshu.com/p/eee33177e78f
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。