一個簡單的取消訂單操作背后的業務邏輯是多么的復雜。

在網購的流程中，大家一般接觸的比較多的都是正向流程，即下單的流程：瀏覽商詳、加入購物車、提交訂單、確認收貨等。但是系統設計的時候往往會發現逆向流程比較正向流程更加的復雜，大家經常接觸的逆向流程一般主要兩類：取消訂單和售后退貨。

今天先跟大家聊下取消訂單背后的邏輯，對用戶來說只是一個簡單的申請取消的按鈕，但是后臺確實做了比較復雜的邏輯。例如要判斷訂單能不能取消？關聯訂單需不需要一起被取消？應該退多少錢給用戶？等等一系列的問題。

下面先看下取消訂單一個比較典型的業務流程，我拿京東作為舉例。

當在京東上下過一單之后，在我的訂單里面可以看到這個訂單的詳情，這時候會看到“申請退款”這個選擇。這里叫法不一樣，有的平臺這里叫做“取消訂單”，這個時候你可以進行申請。

然后你可以看到取消的狀態，剛剛取消后查看狀態為“取消處理中”，下面的進度里面可以看到是正在進行倉庫的攔截。因為訂單已經產生了，系統會將訂單推送到倉庫系統進行生產，庫內作業是有一段時間的，要揀貨、打包等。如果此時訂單還沒出庫，你發起取消訂單的申請，這時候會到倉庫進行攔截，找到這單告訴倉庫的人不要發了。如果訂單已經出庫，這時候你再發起取消訂單的申請，那么你的申請可能會失敗，一般主流的做法是可以收貨的時候進行拒收或者申請售后退貨。但是要付出代價的，有的會扣你的運費，有的會扣經驗值；也有免費的，但是有次數限制。

當取消成功后，取消狀態會變成已經完成，訂單狀態會變成已經取消。

上面只是取消訂單一個比較簡單的場景：一單只有一個商品。

如果一張訂單中有多個商品，并且被拆成多個包裹后事情就變得復雜了。

首先一個問題是，多個包裹支不支持按照包裹維度進行取消？不支持的話只能整單取消，用戶體驗不是很友好，所以主流電商平臺都是支持按照包裹維度進行取消的。

那么問題就來了

先看下運費的問題

原來你因為買了多個商品，達到了免郵的標準，這時候你取消其中一個包裹，那么可能達不到免郵的條件了，這個時候怎么辦？

如果不收運費這其實是一個業務的漏洞，有的電商平臺為了用戶體驗更好些，或者是避免后臺邏輯過于復雜是真的沒有收運費的，主要是靠風控體系來控制風險，如果一個人經常采用這種方式套運費的話是會被拉黑的。但是大部分的電商平臺還是需要收運費的，當發現取消一個子單后，剩下的訂單無法滿足包郵的條件，那么需要用戶支付運費，或者是從取消訂單的退款金額里面把運費扣掉，或者是從你的虛擬賬號里面把運費扣掉（比如扣你的積分）。

促銷的相關問題

另外跟運費類似的是各種促銷，滿減、滿贈、滿返等也存在類似問題。

我們這里以滿減作為例子，如果買了多個商品達到了滿減的條件，享受了滿減的優惠。當取消一個包裹單后如果滿減的條件還滿足，那么就可以正常取消。如果由于取消了這個包裹單滿減條件達不到了，這個時候是需要把關聯訂單也一起取消的，不然也會存在業務漏洞。

資源回退問題

上面的條件都達到了可以正常取消訂單，但是還需要考慮把生成訂單時所占用的資源回退掉，這里主要是庫存、券、積分等。

庫存：生成訂單的時候會先鎖定庫存，保證倉庫可以正常生產，如果取消訂單后，需要把這個庫存釋放，增加前臺銷售庫存的可用量。具體庫存的邏輯可以參考之前的文章電商技術解密—管好庫存沒那么容易

積分：生成訂單后也會給用戶發放一些虛擬資源，例如積分、經驗值。訂單取消后也需要把之前發放的資源進行回收。

優惠券：如果之前下單的時候使用了優惠券，那么訂單取消后也需要把原來用掉的優惠券返還到用戶的賬號中，方便用戶后面繼續使用。

具體流程可以看下面的業務序列圖

可以看到一個簡單的取消訂單操作背后的業務邏輯是多么的復雜。上面的流程是用戶自己發起取消訂單，還有一種情況也會觸發取消訂單這個流程。當你下單后沒有在規定的時間內進行付款，那么系統會自動把你的訂單進行取消。因為要釋放資源，主要是庫存的資源。

取消訂單后臺的業務邏輯就先介紹到這里，可能有些遺漏或者錯誤，歡迎大家拍磚、討論！

相關閱讀：

電商技術解密之庫存系統

電商技術解密之電商網站會存在哪些安全隱患

電商技術解密之跨店鋪促銷

電商技術解密之購物車

電商技術解密之如何快速打開商詳頁

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