訂單全流程業務拆解
業務系統中,訂單系統屬于核心模塊,訂單記錄了交易信息的業務單據,保證了交易鏈路的完整以及可追溯。同時還需要考慮根據公司的業務情況做出改變與兼容。本文主要根據個人負責項目,總結訂單設計時需要考慮的因素及模塊。
01 訂單信息架構
基于電商業務,抽象出的訂單基礎信息結構如下:
02 訂單狀態
定義:為適應組織分工,可以將交易業務流程拆分成若干個可控的環節
用戶下單流程圖如下:
(1)在訂單過程中進行安全校驗,主要是為了檢測用戶是否在黑名單上,用戶購買行為是否正常等,當檢測到不正常時終止下單;
(2)從商品中心獲取商品信息(SKU,規格,價格等)
(3)從營銷中心獲取商品,訂單促銷信息(優惠券,促銷活動),判斷是否滿足優惠條件,計算出優惠金額。
(4)在會員中心獲取會員權益,例如平臺抵扣積分,優惠券折扣條件等。
(5)在調度中心檢驗銷售層庫存,按照調度規則鎖定區域庫存。
(6)根據拆單規則(商家,倉庫,訂單類型等)將訂單拆分成若干個子訂單,根據運費模板計算運費,根據商品金額,運費,優惠金額計算應付金額(實付款)。
2.1 訂單正向狀態
- 待付款:用戶提交訂單后,尚未付款,等待用戶支付,由于待付款訂單會鎖定庫存,所以會設置超時自動取消功能。
- 待發貨:用戶付款之后等待商家發貨。
- 待收貨:商家已發貨,等待用戶收貨。
- 已完成:用戶確認收貨后,訂單交易完成。
- 已取消:付款之前取消訂單。超時未付款或用戶取消訂單都會產生這種訂單狀態。
- 售后中:用戶在付款后發貨前申請退款,或商家發貨后用戶申請退,換貨。
2.2 訂單售后狀態
- 待審核:用戶提交退換貨申請后,等待審核的狀態,在用戶已付款待發貨的狀態下,訂單尚未推送至倉庫或在倉庫攔截發貨成功,系統可直接審核通過。當審核不通過時,回轉至正常流程中。
- 待退貨入庫:退貨申請審核通過之后,等待用戶退貨入庫。
- 待退款:退貨入庫成功后,等待退款給用戶。
- 待換貨入庫:換貨申請審核通過,等待用戶換貨入庫。
- 換貨出庫中: 換貨入庫之后,生成換貨出庫單,訂單出庫。
- 售后成功:當退貨,退款成功之后,流轉至售后成功狀態,退貨,退款的售后成功在主流程下屬于交易關閉。
03 訂單拆單規則
根據訂單的發貨與結算,根據一定的規則,將訂單拆分成多個發貨單進行后續的業務;
- 不同倉庫:若同一訂單分散在不同
- 由于商品歸屬權不同,涉及財務結算和物流發貨的問題,需要根據店鋪歸屬問題對訂單進行拆單。例如淘寶,天貓的商品在下單時會將訂單根據不同店鋪進行拆分成若干個子訂單。
04 訂單流程
4.1 訂單逆向流程
定義:逆向流程為了解決在訂單流程中出現的退貨退款的業務流程,在前端訂單狀態下,各個環節都有可能觸發訂單的逆向,且不同的節點觸發的逆向流程處理方式不同。
(1)待付款取消訂單
說明:待付款訂單取消分為兩種情況
用戶主動取消:超時系統自動取消,此時訂單狀態變更為已取消;
待付款訂單狀態下,取消訂單無需客服審核,流程圖如下:
(2)待發貨取消訂單
說明:在待發貨訂單狀態下取消訂單時,此時應根據訂單此時所在的節點作出處理,由于訂單在支付完成后,發貨單可能已經推送至 WMS,甚至已經交接發貨,狀態未及時回傳更新。為避免貨款兩失,要先暫停訂單出庫,在調度中心查詢訂單是否推送至倉庫。
若尚未推送至倉庫,則停止推送至倉庫;若已經推送至倉庫,則去 wms 中心去攔截,攔截成功則暫停出庫。
若暫停失敗,則拒絕取消訂單申請,回復“訂單已經出庫”;
若暫停成功,取消訂單申請通過,則進入退款流程,同時通知調度中心該訂單取消。WMS 訂單進入返庫流程。
(3)待收貨/交易成功退貨
說明:在用戶提交退貨申請后,需經過客服審核。審核通過則回到原有狀態,審核通過后則進入退貨流程并告知用戶退回地址及收件信息,此時進入退貨流程。系統生成退貨入庫單,當倉庫收貨后,進行退款。
重點:在待收貨狀態下仍需考慮退貨是否全退的問題。當 SKU 全退時,原訂單則中止進入交易關閉狀態。當訂單中發生部分退貨時,原訂單的狀態不變,維持待收貨或交易成功狀態,同時退貨的部分生成交易售后訂單。剩余未退貨部分仍然允許申請售后。
05 總 結
訂單的作用是用于給到消費者查看、并展示交易鏈路與交易結算
業務類型新增時,如訂單流程與原來不一致,需要新增訂單類型來適配業務的擴張
在訂單的逆向處理流程上,需要考慮業務的審核與財務的合規,為了保證財務數據的真實性及可追溯性(這與會計數據的處理原則有關,具體問下會計或者財務同學),都不能直接在原訂單狀態下修改,因此在設計訂單逆向流程時應注意這一點。
本文由 @RICK 原創發布于人人都是產品經理。未經作者許可,禁止轉載
題圖來自 Pexels,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!