在訂單生成之後，訂單的流轉過程中會出現不同的逆向流程。如圖10-5所示，待付款狀態下取消訂單；待發貨狀態下取消訂單；待收貨狀態下申請退貨或退款；交易成功狀態下申請退貨或退款。在不同節點出現退、換貨，系統的處理方式不同。訂單逆向流程分為用戶主動發起與客服發起等兩種方式，下面以用戶主動發起售後為例，聊聊訂單逆向流程。
圖10-5 訂單逆向流程
【待付款取消訂單】
當用戶提交訂單後主動取消訂單或者用戶超時未支付時，訂單的狀態變更為「已取消」，不需要經過客服審核，如圖10-6所示。
圖10-6 待付款取消訂單
【待發貨取消訂單】
當訂單在「待發貨」狀態時，用戶申請取消訂單，如圖10-7所示。由於用戶在支付訂單後，發貨單可能已經推送至WMS，甚至已經交接發貨，狀態未及時回傳更新。為避免貨款兩失，要先暫停訂單出庫，在調度中查詢訂單是否推送至倉庫，若尚未推送，則停止推送；若已經推送，則去WMS攔截發貨，暫停出庫流程。若暫停失敗，則拒絕「取消訂單」申請，回復原因「訂單已出庫」；若暫停成功，「取消訂單」申請通過，進入退款流程，同時通知調度中心該訂單取消，WMS訂單進入返庫流程。
圖10-7 待發貨取消訂單
很多平台支持訂單部分商品退款，這種情況下訂單逆向流程比較複雜。當SKU全退時，原訂單的狀態直接變成「交易關閉」。當發生訂單中部分商品退款時，原訂單的狀態不變，維持「待發貨」狀態，同時生成部分售後訂單。加 入 會 員 微 信
【待收貨/交易成功退貨】
當訂單在「待收貨」或「交易成功」的狀態時，用戶申請退貨，如圖10-8所示。首先解釋下「待收貨」狀態下為什麼允許申請退貨？當發貨之後，用戶不想「確認收貨」，想直接退貨，這是很常見的用戶心理。
圖10-8 待收貨/交易成功退貨
用戶提交退貨申請之後，需經過客服審核。審核不通過，回到原狀態；審核通過後，告知用戶退貨地址（倉庫）或者上門取件，用戶填寫退貨信息（物流單號等），才正式進入退貨核心流程。系統生成退貨入庫單，當倉庫收到退貨之後，進行退款。
很多平台支持訂單部分商品退貨，當SKU全退時，原訂單的狀態直接變成「交易關閉」。當發生訂單中部分商品退貨、退款時，原訂單的狀態不變，維持「待收貨」或「交易成功」狀態，同時生成部分售後訂單。剩餘的訂單商品仍然允許進行售後。
【待收貨/交易成功退款】
當訂單在「待收貨」或「交易成功」的狀態時，用戶申請退款，如圖10-9所示。這時候會有一個疑問，都發貨了為什麼會允許僅退款不退貨這種情形？這種情形偶爾會發生，如快遞丟件、錯發漏發、定制產品寄回來無用等。
圖10-9 待收貨/交易成功退款
用戶提交退款申請之後，需經過客服審核。審核不通過，回到原狀態；審核通過後，系統進行退款。同樣很多平台支持訂單部分商品退款，當SKU全退時，原訂單的狀態直接變成「交易關閉」。當發生訂單中部分商品退貨、退款時，原訂單的狀態不變，維持「待收貨」或「交易成功」狀態，同時生成部分售後訂單。剩餘的訂單商品仍然允許進行售後。
在訂單逆向流程處理時，涉及系統財務數據的變化，而每一次數據的變化，都不能直接在原數據上直接修改，而需要生成相應單據憑證。例如退款要追溯售後單號及退款單號，退貨要有退貨入庫單等。在設計逆向流程時，應保證數據變化的可追溯性，否則會對財務數據和訂單統計數據造成影響。