電商系統中，由于場景多樣導致了業務流程比較復雜，而為了優化開發成本、用戶體驗、供應鏈鏈路，掌握各類細分場景，進而梳理出業務流程為各類棘手問題提供解決方案顯得格外重要。

本文將復盤自己親身負責過自營多供應商（倉庫）的垂直電商產品，在做整個電商后臺時，無論業務流程還是功能當時都感到很大壓力，接觸比較深的是庫存、會員、積分、訂單、促銷活動中心（券、拼/殺/限時、活動頁）、分銷、財務這幾塊業務。

尤其會員用戶升降級，外加上促銷活動下的商品參與，與運營反復溝通，自己也反復考慮場景與漏洞，最后結算還是搞得接口PHP反復修改。

在做分銷上下級關系與分傭，也是好多場景沒有想到。那段時間與技術團隊鬧得特別厲害，運營與技術、測試也不停撕逼。最后還是成了半個背鍋俠。

一、訂單概述

對于自營或平臺電商的后臺訂單模塊來說，除采購、倉庫、評論、內容、CMS模塊，可以說牽扯到了整個電商所有模塊，是名副其實的核心模塊。

前端（H5、APP、小程序）一個訂單，會經過用戶管理、商品管理、庫存管理、配送中心、支付中心、財務管理、風控、促銷活動、評論、發票管理及備注信息。

這么多的模塊，訂單模塊是把這些模塊進行了鏈接，最終讓平臺上的商品流動到客戶手中達成交易。

二、訂單流程概述

用戶從購物車或商品詳情下單，進入訂單頁面填寫收貨地址，選擇優惠券、發票、配送方式時間等，最后選擇支付方式進行支付。

此時前臺訂單正式生成，系統推向后臺倉庫，倉庫再推送到物流中心發貨，最后用戶確認收貨或平臺默認收貨。

此時訂單完成，這是一個普通且正常的訂單流程。

但在實際購物中，由于規格、質量等各種原因，經常會出現退貨、換貨、退貨退款，當然也會出現奇葩現象（包裹消失、配送異地、用戶找不到…），給我們訂單處理增加了難度，出現了商品回流，既訂單的逆向流程。

三、訂單的整體業務流程

四、訂單與庫存之間流程

當商品供應商多個時，優先發出供應商權重高的，權重根據評論、物流、倉庫位置三個維度打分。

供應商庫存不足，單個訂單用戶會收到多個快遞現象，前端也會顯示多個物流單號。

訂單在庫存、倉儲模塊正向流程不同階段下，發起的逆向訂單流程：

五、訂單狀態

用戶在前端購買商品下訂單，會有以下狀態：

未付款，已付款；未發貨，已發貨；未簽收，已簽收；交易成功；取消訂單；退款、換貨；換貨、退貨退款；交易關閉；

1-4為正向流程，5-8為逆向流程。

當用戶或平臺客服發起訂單逆向時，用戶發起時，前端訂單詳情頁有相應的售后按鈕，進入后分出退款、退貨退款、換貨3個入口。

用戶選擇相應原因提交后，平臺審核、審核通過后，貨物寄送至平臺倉庫、平臺退款或換貨，退款不需要用戶確認，退款成功后交易關閉。

換貨需用戶確認收貨，確認后售后入口仍然打開，從確認收貨算起，向后15天后無退貨退款換貨，則交易關閉。

六、訂單逆向流程中的狀態01

發起逆向流程的有兩個角色，平臺和用戶。逆向流程有4種狀態——取消、退款、退貨退款、換貨；除取消外，其它3種都在售后里面。實際購物場景中經常會出現以下場景：

1）未發貨

2）已發貨未簽收/物流中

3）已簽收狀態

02

出現以上場景，在訂單正向流程的不同階段，用戶發起逆向流程進入售后處理，選擇取消、退貨、換貨、退貨退款后，會有以下幾種狀態：

在未付款時，發起的取消訂單可以直接取消訂單，取消后交易關閉。

在未發貨時，發起的換貨、退貨退款：

1）訂單換貨狀態：全退（等價）

2）訂單換貨狀態：部分換（正差價/負差價）

3）訂單退貨退款狀態：全退（等價）

4）訂單退貨退款狀態：部分退（正差價/負差價）

03

在已發貨時，發起的換貨、退貨退款：

1）訂單換貨狀態：（等價）

2）訂單換貨狀態：（正差價/負差價）

3）訂單退貨退款狀態：（等價）

4）訂單退貨退款狀態：（正差價/負差價）

七、訂單逆向退貨退款、換貨業務流程

支付差價，考慮過退差價的處理方法，最后統一結算。

但如果商品參與活動，結算起來比較麻煩，擔心中間有差價或其它問題，只好搬倒樹摸老鴰退一個結算一個。

最后選擇了換完就退款（流程圖如下），當訂單內有商品參與過促銷活動模塊退款時，如使用了優惠券或折扣時，需要拆解出參與單獨每個商品sku或spu實際付款金額，退款時按照實付款返還。此時訂單有換貨入口，進入重新下單，支付后，合并訂單。

換貨后新商品合并到原訂單，原訂單退換的商品需要保留記錄對賬，打上取消標簽，增加新商品，重新計算整個訂單金額，對于促銷活動商品 滿減券仍可用，這里就不寫太詳細了。

八、總結

當我們把不同狀態下的實際場景中，總結出來業務流程，細分到訂單流程不同階段，最后梳理成流程圖。當時做的電商后臺距現在已不久，其實我的拆分法比較繁瑣，并不是最優，還有很多內容和細節寫的也不到位，像財務資金流出、平臺發起的逆向、退款時每個SKU價格計算等都沒寫清楚。

這篇文章更多的是希望提供一些思路，能幫助大家多想一些場景，有了多場景思維方式的術，想到更多場景，能更全面的完善產品。場景之后就是解決方案了，這些可以交給時間或者團隊一起完成。

電商后臺這套系統很類似傳統供應鏈中ERP的一些模塊，像CRM/WMS/采購/物流等系統。在實際業務中可能要面臨技術團隊的成本預估，及運營提出的一些參考。多思考各種場景下的細分場景，可以給出更多更好解決方案。最終達到優化我們開發成本、用戶體驗以及整個供應鏈鏈路。