10.3 訂單售後(退貨退款)

    在訂單生成之後，訂單的流轉過程中會出現不同的逆向流程。如圖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全退時，原訂單的狀態直接變成“交易關閉”。當發生訂單中部分商品退貨、退款時，原訂單的狀態不變，維持“待收貨”或“交易成功”狀態，同時生成部分售後訂單。剩餘的訂單商品仍然允許進行售後。


    在訂單逆向流程處理時，涉及係統財務數據的變化，而每一次數據的變化，都不能直接在原數據上直接修改，而需要生成相應單據憑證。例如退款要追溯售後單號及退款單號，退貨要有退貨入庫單等。在設計逆向流程時，應保證數據變化的可追溯性，否則會對財務數據和訂單統計數據造成影響。