拒收是點退款還是退貨

01 退貨退款整體流程

比較近一直在加班，主要是處理售后系統的退款和退貨要求。根據公司的業務場景，小q總結了退款退貨的觸發場景，主要分為兩類：

一、客戶在線發起申請，平臺批準；

第二，客戶聯系客服，客服從后臺發起申請。

同時，由于公司業務有自營平臺和三方pop商戶兩種業務模式，以及網上支付和貨到付款的訂單，小q總結整理了整體業務場景藍圖：

列出退貨退款場景

02 退貨退款系統流程詳解

小q根據退貨退款觸發時間的不同，將退貨退款流程分為訂單發貨前、訂單發貨后、訂單收貨后三個節點，并自主設計系統流程。

1.訂單發貨前的退貨退款流程

用戶下單后，在實物訂單發貨前，用戶還沒有拿到實物，訂單還在正向履行過程中，不涉及逆向物流場景。在這種情況下，系統級發起的退貨退款如下：

一、取消訂單；二、退款。

根據訂單所在的履行節點，系統處理邏輯細分為三個子節點：

(1)訂單未支付:是指貨到付款訂單已提交，網上支付訂單已提交但未支付的場景。這時候既然還沒有付款，只需要取消訂單，不涉及退款；

(2)訂單已付款和但尚未下發庫房/商家:此時訂單還在中臺的訂單履行系統中，實物還在倉庫中。在系統級別，處理如下：

取消訂單；

對于網上支付訂單，系統會自動或手動生成退款單，訂單的已付金額經審核后以同樣的方式返回到用戶的支付賬戶(貨到付款訂單尚未支付，無需退款)。

(3)訂單已下發庫房:此時訂單已經產生了發貨和生產的波浪，所以在退款之前，需要確保實物沒有實際發貨，并將貨物退回貨架。為了防止系統信息傳遞過程中的滯后，比較好在取消訂單前檢查倉庫/商戶的真實情況。在系統級別，處理如下：

嘗試取消訂單。如果貨物沒有交付，取消可以成功。否則，注銷失敗，退款失??；

倉庫截獲取消的訂單，將商品退回貨架；

網上支付訂單，生成退款單，審批后以同樣的方式退款到用戶的支付賬戶。

訂單交付前的取消和退款流程

2.訂單拒收的退貨退款流程

訂單交付后，實物已經在運輸中，但用戶尚未簽收。這時候如果用戶拒絕簽收，就會被拒絕。貨到付款訂單被拒絕，不收費也不退款。

系統處理邏輯是：

(1)客服核實拒收原因。如果用戶仍然想繼續索要，他將聯系物流公司重新交付包裹，并正常簽收訂單。這個過程仍然是一個訂單轉發過程，不涉及售后過程。

(2)協商同意退貨的，客服會發起退貨申請，發送到倉庫(自營業務)或商家(三方pop商家業務)。物流退回包裹后，網上支付訂單同樣會退款，貨到付款訂單因為沒有收款，不需要退款。

這里需要注意的是，自營平臺訂單一般在倉庫操作wms系統，退貨入庫狀態可以實時與上游系統溝通，倉庫退貨入庫后可以自動觸發退款；在商家系統中，比較好是在商家明確確認收到實物后觸發退款(商家確認多一步)。

平臺退款后，在與商家結算應收賬款時，需要排除退款訂單。

訂單拒絕退貨和退款流程

(2)平臺或商家審核退貨申請，用戶同意后將包裹寄回。如果是自營平臺訂單，只有平臺審核通過后才能回寄包裹；如果是商家訂單，需要商家的認可。

(3)倉庫/商戶收到退回的包裹后，生成退款單，按照約定的路徑將款項退回到用戶賬戶。原則上要求按原路線返回，但部分是貨到付款單，或者其他情況下可以協商其他網上返回路線。

訂單簽署后的退貨和退款流程

03訂單、退貨和退款

因為3.訂單簽收后的退貨退款流程.所以，小q會分別設計退貨單和退款單，它們獨立存在，與訂單庫相輔相成。

退貨單和退款單是什么關系？小q經過一輪研究發現，并不是每一個退貨單都會產生一個退貨單，也不是每一個退貨單都會有一個退貨單，就像不是每一滴牛奶都叫xx蘇一樣，比如一個貨到付款的訂單，如果退貨，只會有一個退貨單，不需要退貨單；有些情況下，客服只會對客戶的一些訂單進行退款，而不會退貨，比如承諾支付加班費。所以退貨單和退款單在正常退貨退款場景中只是一對一的關系，在具體場景中并沒有很強的相關性。

訂單、退貨訂單和退款訂單

小q根據退貨單的操作狀態，設計待審批、待收貨、待收貨、待拒收的退貨單：

1張訂單可能會產生多次退貨，每次退貨會生成1張退貨單。同時，1張訂單也有可能觸發多次退款:在訂單沖銷過程中，客戶或客服新發起退貨申請，系統生成退貨訂單的初始狀態；

待審核:返回文件被批準和返回被同意的狀態。這時，等待客戶包裹寄回；

待入庫:包裹送回倉庫，倉庫已入庫完畢；

入庫完成:拒絕退貨申請的情況。

退貨訂單狀態圖

根據退款節點，退款單的狀態設計為審批、退款、退款和拒絕：

(1)剛剛提交的駁回退款申請的初始狀態；

待審核：退款單經財務審核通過，同意退款；

待退款：由財務部門手動或系統自動觸發，退款成功后的狀態；

退款完成："s退款申請被拒絕。

退款表狀態圖

駁回：

訂單簽約前取消和拒收導致的退款為全退(全額退款)。但是對于簽約后的退貨，會因為一些商品問題出現部分退貨(半退)。如果優惠券，扣款，積分等。在下訂單時使用，也有必要考慮將它們返回到用戶的帳戶。

全額退款的退款處理相對簡單。小q給出的解決方案是：按訂單退還已付總額；未到期的優惠券、積分等優惠信息以同樣方式返還。

半退的情況下退款處理比較復雜。經過對阿輝、老a等電商老鐵的咨詢討論，小q總結如下：

(1)如果沒有組合優惠信息，按商品已付金額退款；

如果使用組合優惠信息(如全券優惠)，有兩種主流處理方式：

a.折扣按商品金額比例分攤，分攤后按已付金額退款；

b.退換貨時要考慮剩余商品是否符合折扣，重新計算折扣后再退。

為了加強理解，請舉例說明：

a.折扣按商品金額比例分攤，分攤后按實繳金額退款。(參考：淘寶)

比如某用戶購買了一件商品a\b\c，使用了150多減20的優惠券。按比例分配后的支付金額如下：

如上，退a就退90元；退b的話，退到54元；退c的話會退到46元。

在此規則簡單易實現，但存在湊單刷優惠券的風險。,用戶使用優惠券收集賬單，然后退回其他不需要的商品。一般規避方案如下：因用戶責任造成的退貨運費由用戶承擔；惡意刷券退貨、降級用戶或加入黑名單的行為。

b.退款時重新計算折扣。如果剩余sku繼續滿足折扣，將按原價退款；否則，折扣將被扣除，然后退款。如果扣除的金額不夠優惠，產品不能單獨退貨。參考：jd。計算機輸出縮微膠片

例1:用戶每購買一件產品a\b\c，使用150多減20的優惠券。支付金額如下：

(1)如果退回c，剩余的a、b，原金額合計160，仍符合優惠條件，故退還40元；

如果退還b，剩余的a和c，原金額合計140，不再符合優惠條件，需要扣除優惠待遇，所以退還金額=6020=40元。

例2:用戶每購買一個產品a\b，使用100多減50的優惠券。支付金額如下：

如果退還a，剩余b(原金額為40)不再符合優惠條件，需要扣除優惠待遇。可退金額=60-50=10元

若退還b，剩余a(原金額為60)不再符合優惠條件，應扣除優惠待遇。但由于b的原金額(40)小于優惠金額(50)，不允許單獨退款b。

此規則可預防刷優惠券的情況，但規則較復雜，解釋成本和系統實現成本較大。

在以上兩個方案中，小q更傾向于方案a，因為在醫行業，品一旦售出，原則上是不退換的，所以原退換是低概率事件。此外，由于用的特殊性，領取一張優惠券并返還的概率更低。系統設計也遵循簡單的原則。當平臺發布促銷優惠時，只要能覆蓋整體成本，系統不需要設計得太復雜。

對于項目驅動的加班，小q從不拒絕。項目高峰期，為了在計劃時間內產生成果，我無數次自告奮勇加班，在比較后一班地鐵到家后繼續挑燈夜戰；我也是連續打了24個小時。在酒店短暫休息后，自覺去了項目現場，只擔心新上線項目的失誤；更有甚者，他們戰斗了一個月，直到凌晨三點，只為了在別人下班的時候騰出時間進行系統聯合調整。那些日子是苦的，但回憶起來都是甜的，都是心在驅使，無怨無悔。

‘996’的矛盾在網上升級到icu層面，就成了企業和員工的階級矛盾，正反雙方各執一詞，互相對立。對于996，小q有自己的理解。相比自上而下灌輸的政策和自下而上的對策，小q崇尚有意義的自我驅動價值觀，不希望制度成為企業與員工博弈的舞臺。

縱觀歷史，一切以反人類為出發點的制度都是歷史的絆腳石，終將被歷史所淘汰。不管是9點還是6點，上下班時間應該只是自我價值的記錄，凌晨4點的街道不應該是capi