編輯導讀：訂單管理系統，是整個電商系統的核心系統之一，有一定的複雜性。本文将從六個方面，圍繞訂單管理系統展開分析，希望對你有幫助。

一、 關于訂單管理系統

訂單管理系統即處理訂單的系統，主要管理訂單的輸入，處理，輸出。其在一般電商系統中或在有交易功能的系統中，都是核心系統/功能之一，有一定的複雜度；但是雖然複雜，并不代表理解起來困難。

關于商品的文章裡面，我們已經從商品的輸入、維護、輸出的流程來介紹了商品系統，那訂單也一樣，我們本文把訂單看成一個流程即訂單流來理解。

二、 訂單管理系統與整體系統的關系

訂單系統會與購物車、商品系統，營銷系統、會員系統、支付系統、物流系統、倉庫系統、财務系統、内容系統，具體請看示例圖：

• • 購物車：個人認為是訂單的起點，商品會被加入購物車，然後會被提交。
  • 商品系統：在提交訂單頁面會看到該訂單所包含的商品信息，例如商品名稱、所購買數量、價格、售後信息等。
  • 營銷系統：會顯示商品是否優惠信息，例如滿減、優惠券。
  • 會員系統：會顯示該會員是否有基于會員等級的折扣信息(如淘寶的88會員)，或是否有可抵扣金額的會員點數(如京豆)；會顯示該會員下面的收貨地址信息、也會顯示該會員下面是否有充值卡、運費券等。
  • 倉庫系統：基于收貨地址信息顯示發貨倉庫，自提地點等，并且訂單最終會流轉到該系統進行發貨操作。
  • 支付系統：顯示支付方式(如貨到付款、在線支付等)、并且在支付的時候計算該會員實際應付的金額，以及顯示銀行卡信息等。
  • 物流系統：顯示配送時間、配送方式、運費等，并且在訂單發貨後會顯示實際的配送路徑。
  • 财務系統：顯示開票信息等，在訂單完成後會生成發票。
  • 内容系統：顯示訂單留言等。

三、訂單的輸入

個人認為訂單的輸入(亦可稱之為來源)可分為内部和外部兩種方式：

1. 内部：即自建商城傳輸過來的訂單

• 自建商城的訂單系統涉及的其他系統比較多，基本上上圖所示的系統都涉及到了。
• 自建商城訂單在訂單創建時有着更多的判斷邏輯，如是否需要事先拆單的、優惠信息是否可用、商品庫存是否滿足要求、會員是否正常等。
• 内部訂單由于存在支付的動作，所以會有多出待付款，待評價這2個狀态。
• 内部訂單由于涉及支付和營銷，所以對訂單系統的并發能力、負載能力以及支付能力有相當高的要求，每一步都不允許出錯，一旦出錯就意味着營業額的損失和用戶的流失。
• 訂單數據計算和處理的要求更高，商品多少金額，優惠了多少金額，抵扣了多少金額，實付多少金額等都需要準确計算，在财務報表内能夠清晰展示。

2. 外部：即第三方系統傳輸過來的訂單

一般代表性的就是分銷訂單，如供應商的訂單系統會接收外部系統的訂單。

• 第三方系統傳輸的訂單，由于訂單比較獨立，所以涉及的相關系統會少很多。
• 第三方訂單在訂單接收時主要判斷傳輸方是否有資格，商品是否上架狀态，庫存是否滿足，收貨人信息是否完整等。
• 由于該類訂單相對來說不需要很高的實時性(意思是該類訂單對于消費者來說已經付款了，現在隻是後端處理)，所以對接口負載性能等要求相對就沒有那麼高。
• 訂單數據處理方面，一般都是線下核對賬單，線下結算款項，所以主要在數據記錄和處理的準确性方面有很高要求。

以上就是訂單的輸入，接下來我們聊訂單的處理。

四、 訂單的處理

個人認為主要有3種處理方式：

1. 流轉處理

在訂單系統内，系統會對訂單進行各種邏輯規則判斷，判斷後就會根據業務規則分發訂單，可簡單看示例圖：

基本上訂單的流轉處理是秒級，甚至是毫秒級就能處理完畢的，不能處理的或者處理失敗的都會把訂單歸類到異常訂單。

下面是訂單各狀态的流程圖：

2. 發貨處理

訂單一般流轉到倉庫進行發貨操作，發貨後倉庫會把物流信息回傳到訂單系統，訂單系統接收消息後會對訂單進行發貨：

• 如果是内部訂單則訂單狀态直接改變(消費者端也會同步看到訂單狀态變化)；
• 如果是外部訂單則會通過接口告訴第三方系統該訂單的物流信息；

3. 特殊情況處理

在特殊情況下，就需要對訂單進行人工處理，例如訂單無法流轉到下一級、訂單有備注等。人工處理的結果可能是跟消費者協商後讓其退款，也可能是手動的傳輸訂單等。

五、 訂單的完成

1. 内部訂單

内部訂單的完成并不在發貨後就完成，一般來說在客戶接收到訂單商品後即算完成。

但是對不同類型的商城有所區别：

• 自營商城：一般客戶收貨後就完成訂單，例如京東。
• 非自營商城：客戶需要自己點擊确認收貨或經過一段時間後系統自動确認收貨。

2. 外部訂單

外部訂單系統訂單一般在發貨後就算完成。

六、 訂單管理系統設計想法

在我們設計訂單系統的時候，應該先思考下公司業務類型和邏輯，理清業務上訂單流的起止。

理清後從訂單源頭開始設計訂單系統：

• 如果是自建商城類的那麼訂單模塊會涉及到其他系統，需要與其他系統的産品經理(如多人)去讨論，如何讓訂單系統與他們負責的系統進行對接；如果是供應鍊類型的訂單系統，則需要考慮如何讓訂單能夠從外部順利傳輸到系統，是我們提供統一标準的API呢還是我們去各自對接第三方系統等等。
• 考慮輸入方式後，我們就要依據公司業務運營方式來考慮訂單的處理邏輯，訂單進入系統後如何 讓系統自動處理訂單，依據什麼規則；同時也要考慮對異常訂單的處理。
• 在考慮好訂單處理邏輯後，就要考慮如何輸出訂單，是直接輸出給WMS還是會再輸出給其他ERP等等。由于是自動化的輸出，也就要考慮與其他系統的對接方式。
• 最後，我們就要用把公司業務代入到系統内，看看是否能行程閉環，是否還有欠缺或者是否遺漏了細節等。

訂單管理系統涉及的其他系統比較多，所以在系統設計上應該具有獨立性、拓展型和準确性，獨立性代表訂單系統的維護或者異常不會影響到其他系統；拓展型代表訂單系統在以後增加功能的時候方便快捷；準确性是指訂單數據涉及到财務方面，所以應該嚴謹和準确。

後台系統訂單頁面的設計：

1）訂單列表頁面的設計

根據公司業務需要來設計列表頁展示的數據和布局，以及篩選查詢的關鍵字段，具體可看示例圖：

2）訂單詳情頁的設計

訂單詳情頁一般來說是模塊化的展示設計，訂單基礎信息、商品信息、物流信息、支付信息等都需要有所區分，這樣設計有利于詳情快速查看以及在系統研發的過程中讓開發小哥哥不容易搞錯哦，具體可看示例圖：

3）訂單規則設計

訂單規則根據業務的大小有簡單和複雜，所以具體需要看業務規模。

如果公司現階段剛起步，則訂單規則可直接寫進訂單系統；如起步有一段時間了或者發展比較快，則可事先就開發好訂單規則模塊，以後有新的訂單規則直接通過運營人員設置即可，更加的方便和更快速地适應業務的發展。

本文由 @Milomasson 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

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

查看全部