電商後臺:商品上架前的最後準備

電商後臺相關模塊進行維護後,離商品上架越來越近。

电商后台:商品上架前的最后准备

關於電商後臺供應鏈部分前面也總結了幾篇,對於有經驗的同學來說應該是非常簡單容易的;本人通過分享希望能夠與相關同事進行交流,共同學習進步。

在供應商、合同、商品、價稅等都維護完成後,採購部創建採購單,離商品可以上架銷售越來越近了。

本篇再接著梳理一下商品銷售前的最後準備工作(沒考慮促銷),即銷售區域、運費模板與入庫管理部分。

一、區域及模板管理

1. 區域

區域是基礎信息,一般包括四級,即省、市、區縣和鄉鎮;如:“吉林省-〉吉林市-〉蛟河市-〉新站鎮”。

在系統中都是存儲在區域字典表中,包括區域名稱、區域代碼、是否開通、顯示名稱、配送時效、父編碼幾個字段;各級通過父編碼來進行關聯。

對於不同的電商網站,經營的商品不同,服裝類網站一般不受溫控條件的影響,所以只要有貨,對於快遞可以送達的城市地區,基本上都可以覆蓋。

城市是否開通的前提取決於合作的快遞公司以及公司成本的綜合考慮。

對於對配送條件有要求的則需要分類進行設置,譬如糧油食品類、生鮮類的網站對於冷鏈物流要求比較高的網站,都會將商品歸屬在不同的溫控屬性裡。溫控屬性一般分為:常溫(常溫又可以分為普通商品與水果類)、冷藏、冷凍。配送時效:對於時效一般也在區域上進行基礎的設置,如24小時、48小時或72小時,3~7天等。

關於倉庫與城市之間的關係圖如下:

电商后台:商品上架前的最后准备
  • 這裡的倉庫是指RDC,有些公司還會建立DC倉,FDC倉等;
  • 每個倉庫可以覆蓋多個城市;
  • 每個城市可以由一個或多個倉庫覆蓋,當有多個倉庫時,需要設置發貨優先級,譬如上圖中的杭州可以由上海倉、廣州倉送貨(假如是常溫),則當上海無貨時才從廣州發貨。對於是否從哪個倉庫發貨,在下單時就會進行預拆單,簡單的邏輯一般會遵守最小拆單規則為前提,然後根據溫控等進行分組;目標是提高客戶滿意度、降低公司物流成本;
  • 維護倉庫與城市關係時,需要按溫控屬性進行配置(如果有溫控要求)。

2. 銷售區域模板

銷售區域模板也可以叫配送區域模板,是指商品是否可以送達到此城市,每個商品都應該配置對應的模板,以便用戶在前端APP、網站或小程序上搜索商品時可以根據模板進行信息的返回;關於商品、區域模板、區域及倉庫的關係如下圖所示。

电商后台:商品上架前的最后准备

當前端用戶瀏覽時,系統會調用庫存服務,根據用戶選擇的省市區來進行銷售區域模板的匹配,然後再判斷其對應倉所擁有的商品庫存。

  • 對應的區域沒有包含此城市(三級或四級),則顯示無庫存,加入購物車按鈕置灰。
  • 當商品庫存數量<0時,則顯示商品缺貨狀態(如果有多倉,要按倉庫優選級進行判斷)在京東和我買網上各截了個圖,前端展示給用戶方式不同,供參考。
电商后台:商品上架前的最后准备

二、運費模板

在網上購買商品難免會支付運費,所以運費模板是計算運費的基礎。

運費計算方式:

  1. 按金額確定是否收運費,如:滿99元包郵,低於99元收取6元運費。
  2. 按重量確定是否收費,如:首重10KG不收費,後續按重量遞增收取運費。

以上兩種方式在運費模板中一般是組合設置的,同時對於運費模板也是基於區域進行配置的,可能多個區域共用同一個模板,這個可以根據實際情況進行配置。

對於運費模板的主要信息如下:

  • 如果有溫控屬性要考慮溫控條件對配送的影響,一般冷鏈要求比較高,所以運費就會貴一些。這在快遞公司中是屬於不同的物流產品。
  • 設置階梯價格區間(將價格區間與重量區間進行綜合考慮)。
电商后台:商品上架前的最后准备

運費模板可能有許多,因為不同的城市收費標準可能都不一樣,具體模板的樣式可以根據公司的實際業務去設計。一般的公司為了拉新或留存,也可能只設置一個全國通用模板,不收取運費;但在設計系統時不要為了省事就省去相關模板的設計,這些都屬於基礎功能。

在此只是梳理了最重要的兩個模板(銷售區域模板、運費模板),隨著競爭的加劇,各公司都在追求配送時效以及精準配送,所以京東等公司都推出來精準送達服務(但是需要付費的)。

這兩個模板是商品上架銷售前需要進行設置好的,對於商品在哪個渠道上銷售,還涉及渠道庫存管理,渠道選品,渠道佣金等相關的管理,這裡先不討論,後續針對渠道會單獨總結一篇。

三、入庫管理

前面總結了採購管理,先回顧一下。

  1. 供應商、合同、商品等信息已經創建並生效。
  2. 商品的價格及商品稅率已經維護完畢(基準價、促銷進價、進項、銷項稅)
  3. 採購部創建採購訂單,審核後推送到供應商商家管理平臺
  4. 供應商審核後狀態回傳到採購管理模塊
  5. 採購部進行確認,單據生效後推送到倉庫系統(WMS)等待收貨。
  6. 供應商發貨前預約到貨時間(如果自提則由零售商去取貨)。
  7. 入庫管理-見下面流程。
电商后台:商品上架前的最后准备

1. WMS(倉儲系統)

  • 供應商根據採購單把貨物送到倉庫,倉庫人員按採購單進行質檢,對於不合格品達到風控線時,會整單拒收。
  • 對於有差異的採購單,會按實際數量進行入庫,在WMS入庫模塊錄入差異數量、原因等。
  • 可以收貨的商品一般分為整箱,或散貨兩種;倉庫根據包裝將商品放到移動托盤上,通過地牛或叉車等工具進行入庫操作。在倉庫中只要收貨指令開始,就要對商品進行跟蹤,所以一般托盤可以設置為移動庫存(每個托盤都有貨位編號),後續具體上架到固定庫位,只是庫位間的商品移動。如果應用了機器人,倉庫管理中此部分更加細緻與嚴格。
  • 這裡補充說明一下,對於一般的倉庫中,收貨組是與發貨組、庫內作業組是分開的。倉庫分為整庫、零庫,收貨時商品只能先入到整庫,然後經過庫內調撥算法進行庫內補貨,將商品從整庫調到零庫進行銷售。
  • 收貨完成後,WMS系統會進行關單操作,此時WMS系統會將入庫明細通過數據傳輸平臺回傳給SCM系統。

2. 數據傳輸平臺

這個平臺主要是用於WMS倉儲與SCM間的單據傳輸,包括下發商品等基礎信息,下發採購、返廠單、訂單等業務單據,同時接受WMS回傳的出入庫流水數據。這裡集成了很多服務接口,通過消息隊列實現異步傳輸,通過數據核對來保證WMS與SCM數據的一致性。

  1. 接受入庫明細數據,並進行保存;這裡的數據一般要求有,入庫的單據庫、商品、數量、價格、庫位、供應商、生產日期、倉庫、入庫時間等。
  2. 此外數據平臺要根據回傳的數據進行入庫單的彙總生成,此時要與原採購單進行對照,計算出差異以便後續統計。
  3. 是否要進行實時的商品成本核算?此部分我個人覺得可以不做實時的成本核算,只關注數量的計算即可,以減少後續數據不一致的麻煩。

成本核算統一放在FMS財務進銷存系統中進行,可以準實時計算或每日零點以後計算(如果業務不要求實時數據查看等)。對於成本核算的內容,可以查看《FMS財務管理系統:存貨管理》,這裡不多述說。

四、SCM與財務

  • SCM主要是更改採購單狀態,產生SCM商品庫存。
  • 財務是根據出入庫流水單據,進行成本核算,產生財務商品庫存。

在SCM中的庫存數據,需要記錄商品級的庫存、供應商級別的庫存、倉庫級別的庫存等多維度的庫存。

多個庫存間要保證數據的一致,所以對於商品入庫時系統上的操作還是比較複雜的。

每個維度的庫存都有不同的用途,譬如倉庫有批次及貨位庫存,那麼在SCM系統中也需要記錄相關的庫存信息,以便進行庫存對賬,核對差異。

總結

至此,商品銷售前的準備工作基本準備完成,已經可以進行銷售了。

在這裡介紹的銷售區域模板和運費模板也只是滿足企業初期的需求,隨著業務的發展模板會更復雜(如商品單倉發送全國等),同時也會有各種針對商品的模板,如促銷活動模板。

我們應該始終以業務的思維去考慮系統,以用戶的思維去優化系統,後續仍將按照《以商品流轉了解系統模塊》進行相關內容的總結,非常感謝您的關注與閱讀。

本文由 @倔強的大蘿蔔 原創發佈於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基於CC0協議

"


分享到:


相關文章: