接《訂單系統(tǒng)總結》章節(jié)，上面所講的都是訂單的正向流程中的履單，逆向流程并沒有介紹，今天我們就主要說說訂單逆向流程這些事。
由于歷史原因，官網(wǎng)并未做訂單逆向流程，每天所有的退款都需要客服人員手動錄入系統(tǒng)處理，不但效率低，還容易出錯。因此這次做訂單系統(tǒng)規(guī)劃時（也考慮了逆向流程），主要從以下幾點介紹：
1. 訂單狀態(tài)機
逆向流程節(jié)點及其狀態(tài)確定，見圖：
總結：訂單狀態(tài)的確定，我們當時規(guī)劃的時候和研發(fā)同時開了三次會，最終確定；經(jīng)過就不多說了。主要說下訂單狀態(tài)確定思路吧。
我們當時是先畫了一個訂單的主線流程圖，然后在訂單的主線流程圖每個節(jié)點開始考慮都會存在哪些狀態(tài)；最終前臺確定了這六個狀態(tài)，但后臺的訂單狀態(tài)可遠遠不止這些；基本上要比前臺的狀態(tài)多了一倍還要多；當然會有這么多狀態(tài)，也是因為交互的系統(tǒng)比較多導致；一般初期的電商系統(tǒng)這幾個狀態(tài)也夠用。
2. 退款場景
從狀態(tài)機中不難看出，退款發(fā)生的場景主要有以下幾類
未付款時，取消訂單；系統(tǒng)自動取消訂單一般會根據(jù)自身公司實際情況來決定；我們當時是因為有占存的概念，因此暫定是30分鐘
已付款待發(fā)貨申請：因為公司的倉庫都是自己的，可以控制；因此可以根據(jù)實際情況來做攔單，同時客服審核后可直接退款
已付款且已發(fā)貨申請：這塊一般公司會根據(jù)自己的規(guī)則決定是否先行退款還是是收到退貨后再退，一般業(yè)務會根據(jù)實際情況處理售后。在此，既要考慮用戶體驗，又要考慮商品退貨風險
3. 退款業(yè)務流程
其實，做后臺系統(tǒng)，需求調研的時候，他們也說不出個一二三，除非經(jīng)驗比較深的，或許能提出一些信息點；很多時候是需要產(chǎn)品經(jīng)理主動給出一條思路進行引導的；經(jīng)過和相關部門的溝通，最終確定了業(yè)務流程，具體如圖：
總結：根據(jù)不同的訂單狀態(tài)，顯示不同的退款類型入口。
一般對于退款申請，未發(fā)貨的訂單申請退款都可以整單申請退，邏輯上相對要簡單一些；如果是退款退貨，相對來說比較復雜
A. 無各種優(yōu)惠的時候 ，選擇某一商品申請退款，申請后按業(yè)務流程處理即可；
B. 訂單有優(yōu)惠的時候，選擇某一商品申請退款，則牽涉到退款金額的計算。
如：兩件商品A（20元）、B（80元），訂單共100元；提示滿90包郵；現(xiàn)在用戶申請退A商品，就牽涉到退款金額計算；是按比例退款，還是是按實際售價退；所有的金額計算要和相關業(yè)務部門溝通，根據(jù)實際情況來確定退款金額計算規(guī)則后執(zhí)行。
4. 后臺系統(tǒng)交互
經(jīng)過和其他系統(tǒng)的產(chǎn)品經(jīng)理溝通，最終的交互圖也確定了下來。當然出具的這些流程圖需要根據(jù)公司的實際情況來設計規(guī)劃，提供的只是些可借鑒的圖
5.原型圖和PRD
根據(jù)上述的流程圖大致清楚了列表及其功能點。也就可以逐步出具原型圖和PRD了。
原型和頁面不做過多介紹，其實都是按照上述的流程圖確定頁面和功能點后，按照實際需要來出具原型視圖，畢竟對于業(yè)務來說，這些他們最直觀了解產(chǎn)品的初衷。
客服退款審核列表
客服退款審核詳情
財務退款詳情
總結
1. 用戶填寫的退款申請，是需要區(qū)分是退款還是是退貨的。
未發(fā)貨的退款---可以直接進行系統(tǒng)退款的
而退貨，是需要查詢退貨登記中是否已簽收的
只有已經(jīng)簽收的財務才會去退款，當然，客服也可以根據(jù)實際情況來決定是否要提前給用戶退款
2. 如果公司無多個系統(tǒng)，退款也就不會有多個系統(tǒng)復雜交互；做產(chǎn)品最終還是要根據(jù)公司實際情況考慮，而上面的流程，僅是我工作總結得一部分。
不洗勿噴，有不正確的地方，還請同行們指證。
