退貨預(yù)收模式(云倉/三方倉)

0 評論 2881 瀏覽 17 收藏 9 分鐘

本篇文章,作者分析目前退貨入庫存在的問題,提出優(yōu)化退貨流程的一些方法,在最后,作者提供了一些相關(guān)的解決方案,希望能對你有所幫助。

一、退貨預(yù)入庫

退貨預(yù)入庫是什么?

是指貨品退到倉庫WMS先預(yù)收,再聯(lián)系前端OMS售后進行下一步處理的動作。

  1. 由于前端貨主推退換單的時間不及時,所以存在貨先退回到倉庫,此時一般由倉庫收入后核對貨品后聯(lián)系前端貨主進行推單。
  2. 涉及到客退件的貨品可能存在數(shù)量、質(zhì)量上的問題,需要倉庫拆包核驗后才能接收正式入庫,所以需要倉庫負責(zé)處理退貨的人進行拍照、取證,特殊的甚至要進行質(zhì)檢。
  3. 涉及到運輸過程中的破損索賠問題,包裹實際到庫會區(qū)分客退、原退。原退即退回時為發(fā)出時的同一物流單號,未經(jīng)過任何拆包,如存在破損情況,一般是由物流公司承擔(dān)。預(yù)入庫了可以直觀的看到對應(yīng)貨品明細,區(qū)分正殘。

二、目前現(xiàn)存痛點

目前大多數(shù)退貨流程都是從上至下,從前往后的順向流程。也就是由買家在平臺發(fā)起退貨退款申請,逐步將退換單推向下游軟件。

涉及錢款流向的,平臺根據(jù)買家信用等級,允許進行極速退款,錢款在支付時從買家暫存至平臺,發(fā)起退款時,平臺則將此錢款退回到了買家。

而在訂單履約流程上,ERP仍需要從平臺上自動抓取原始退換單,根據(jù)不同ERP的規(guī)則設(shè)置,可以自動創(chuàng)建退換單或手動創(chuàng)建退換單,但退貨信息是會有部分缺失的。

比如買家單獨退回平臺是沒有填入物流單號的或者買家偷偷退回后面才反饋給客服;又或者買家分了多個包裹依次退回而ERP的限制不允許自動建多張退換單,此時只能手工建單……

多種情況導(dǎo)致建立退換單時并非都有相應(yīng)的單號進行對應(yīng)。

如果是原退,即貨還未到買家手里,買家發(fā)起退款,此時是由賣家發(fā)起物流攔截,退回到原發(fā)出點。

只要ERP創(chuàng)建后正常情況下會推送到WMS,存在2種情況導(dǎo)致推單不及時:

  1. 特殊訂單在不同ERP上只能手工建單,不同商家售后資源有限,特別是大促期間更是會導(dǎo)致退貨量激增,來不及推單。
  2. 即使在ERP建了單也未即使推到WMS。

此種情況下,會導(dǎo)致存在許多的無頭件流到倉庫,倉庫收了一臉懵逼,不收吧占用大片空間,越堆越亂。

且對于倉庫來說無法知道前端什么時候推單過來,這是個持續(xù)性的事情,今天推的單可能包含昨天前天的,陸續(xù)的。

所以倉庫就要對每個包裹逐個嘗試入庫,推的才能自動關(guān)聯(lián)匹配;不推的如果直接進行入庫會直接增加庫存的變化。前端若是沒有關(guān)聯(lián)該類型,會使得前端ERP的庫存增加后還莫名其妙,無法判斷其來源。

對于財務(wù)方面來說,庫存即是錢,盤虧盤盈都是錢的流動,更何況是涉及到退貨,稍大一點的公司都會需要對退貨方面的帳表進行核對,明確它的來源及變動原因。

即使我們系統(tǒng)對象是倉庫,但是倉庫的上游則是貨主,倉庫如果直接回傳庫存變化,快是快了,庫存卻亂了。

貨主的單子白建了也不知道后面的整體流轉(zhuǎn)情況,對于分析退貨情況十分不利。

所以本次的預(yù)入庫優(yōu)化則是包含了半逆向流程,即貨到倉庫先收貨,再聯(lián)系貨主推單。

三、流程優(yōu)化

經(jīng)過上面分析及結(jié)合現(xiàn)有系統(tǒng)功能,我們劃分了三種退貨入庫方式:

  1. 完全等前端貨主推單后才能進行入庫,完全限定順向流程。
  2. 按現(xiàn)有模式的預(yù)入庫,針對微型、小型客戶來說,如果對貨品客單價不高且不敏感的貨主來說,比如紙巾、日常小百貨等,可以直接入庫,ERP都不需要推退換單而是直接進行入庫操作,最后都能達到兩個系統(tǒng)庫存的一致,貨主側(cè)也節(jié)省了建單的工作量。
  3. 允許先進行預(yù)入庫,后推退換單再進行自動關(guān)聯(lián)預(yù)入庫的貨品。此功能最大的好處則是保證了退貨流程的閉合性,貨到倉庫收入、登記,發(fā)給貨主,貨主根據(jù)明細再進行建單、推單。WMS關(guān)聯(lián)后正?;貍?,以倉庫收到貨為主導(dǎo),是真實有效的貨品才最有說服力。

前端如果直接推單有個問題,如買家退回時貨品影響了二次銷售或退回數(shù)量不一樣。倉庫收到時進行核對后需要反復(fù)溝通才能明確到具體問題,繼而返廠還是報廢處理等,且過程中需要留用取證等,都需要較大的溝通成本。

對于退貨占比較高的商家來說,有效減少退貨成本和優(yōu)化退貨配置也是很重要的一部分。

四、解決方案

  1. 允許預(yù)入庫但非正式入庫,只做一次入庫掃描,節(jié)省掃描、核對工作量,利用預(yù)收包裹的詳情導(dǎo)出給到貨主建單,推過來后關(guān)聯(lián)后完成退換單回傳,退貨可以直接拉去上架。
  2. 大多數(shù)ERP與WMS對接都是支持常規(guī)退貨的類型,適用于大部分倉庫及貨主使用。
  3. 預(yù)收后可以通過退回周期放置在暫存的庫位或容器,在推單后能直接進行上架,節(jié)省再次入庫匹配單據(jù)的時間。
  4. 針對人為誤操作的單據(jù),匹配不上時會有對應(yīng)提醒,快速了解到異??梢越o到貨主、倉庫核對,不需要像之前那樣未退貨不知道是沒到貨還是少建貨品等。

五、總結(jié)

此退貨流程也是為在現(xiàn)有流程上進行的優(yōu)化處理,依然會存在一定問題。

理想狀態(tài)下,貨主根據(jù)貨到倉庫的明細去建單,而如果貨主建單與預(yù)收不一致,此時去找到具體貨品是存在一定難度的。

因為預(yù)收貨品可能已經(jīng)拆包了,同款貨品多人退回,存在匹配不上的情況。

不過一般退貨過程中都會有攝像錄制,也能結(jié)合PDA預(yù)入庫從而減少表格登記的緩慢。

另外,其實退貨過程中,對退回包裹貨品進行分類也是較為繁瑣的事情,在不影響二次銷售的情況下通常會直接上架到揀貨區(qū)。

而不同貨品分散、多雜分布在不同揀貨通道,劃分適合數(shù)量的通道集合容器以便退貨人員進行上架,也是需要考慮的。

作者:在樹上唱歌;微信公眾號:CherylSays

本文由 @在樹上唱歌 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!