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全退時,原訂單的狀態直接變成「交易關閉」。當發生訂單中部分商品退貨、退款時,原訂單的狀態不變,維持「待收貨」或「交易成功」狀態,同時生成部分售後訂單。剩餘的訂單商品仍然允許進行售後。

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

《電商產品經理寶典:電商後台系統產品邏輯全解析》