電商后臺相關模塊進行維護后,離商品上架越來越近。
關于電商后臺供應鏈部分前面也總結了幾篇,對于有經驗的同學來說應該是非常簡單容易的;本人通過分享希望能夠與相關同事進行交流,共同學習進步。
在供應商、合同、商品、價稅等都維護完成后,采購部創建采購單,離商品可以上架銷售越來越近了。
本篇再接著梳理一下商品銷售前的最后準備工作(沒考慮促銷),即銷售區域、運費模板與入庫管理部分。
一、區域及模板管理
1. 區域
區域是基礎信息,一般包括四級,即省、市、區縣和鄉鎮;如:“吉林省-〉吉林市-〉蛟河市-〉新站鎮”。
在系統中都是存儲在區域字典表中,包括區域名稱、區域代碼、是否開通、顯示名稱、配送時效、父編碼幾個字段;各級通過父編碼來進行關聯。
對于不同的電商網站,經營的商品不同,服裝類網站一般不受溫控條件的影響,所以只要有貨,對于快遞可以送達的城市地區,基本上都可以覆蓋。
城市是否開通的前提取決于合作的快遞公司以及公司成本的綜合考慮。
對于對配送條件有要求的則需要分類進行設置,譬如糧油食品類、生鮮類的網站對于冷鏈物流要求比較高的網站,都會將商品歸屬在不同的溫控屬性里。溫控屬性一般分為:常溫(常溫又可以分為普通商品與水果類)、冷藏、冷凍。配送時效:對于時效一般也在區域上進行基礎的設置,如24小時、48小時或72小時,3~7天等。
關于倉庫與城市之間的關系圖如下:
這里的倉庫是指RDC,有些公司還會建立DC倉,FDC倉等;每個倉庫可以覆蓋多個城市;每個城市可以由一個或多個倉庫覆蓋,當有多個倉庫時,需要設置發貨優先級,譬如上圖中的杭州可以由上海倉、廣州倉送貨(假如是常溫),則當上海無貨時才從廣州發貨。對于是否從哪個倉庫發貨,在下單時就會進行預拆單,簡單的邏輯一般會遵守最小拆單規則為前提,然后根據溫控等進行分組;目標是提高客戶滿意度、降低公司物流成本;維護倉庫與城市關系時,需要按溫控屬性進行配置(如果有溫控要求)。
2. 銷售區域模板
銷售區域模板也可以叫配送區域模板,是指商品是否可以送達到此城市,每個商品都應該配置對應的模板,以便用戶在前端APP、網站或小程序上搜索商品時可以根據模板進行信息的返回;關于商品、區域模板、區域及倉庫的關系如下圖所示。
當前端用戶瀏覽時,系統會調用庫存服務,根據用戶選擇的省市區來進行銷售區域模板的匹配,然后再判斷其對應倉所擁有的商品庫存。
對應的區域沒有包含此城市(三級或四級),則顯示無庫存,加入購物車按鈕置灰。當商品庫存數量<0時,則顯示商品缺貨狀態(如果有多倉,要按倉庫優選級進行判斷)在京東和我買網上各截了個圖,前端展示給用戶方式不同,供參考。/
二、運費模板
在網上購買商品難免會支付運費,所以運費模板是計算運費的基礎。
運費計算方式:
按金額確定是否收運費,如:滿99元包郵,低于99元收取6元運費。按重量確定是否收費,如:首重10KG不收費,后續按重量遞增收取運費。
以上兩種方式在運費模板中一般是組合設置的,同時對于運費模板也是基于區域進行配置的,可能多個區域共用同一個模板,這個可以根據實際情況進行配置。
對于運費模板的主要信息如下:
如果有溫控屬性要考慮溫控條件對配送的影響,一般冷鏈要求比較高,所以運費就會貴一些。這在快遞公司中是屬于不同的物流產品。設置階梯價格區間(將價格區間與重量區間進行綜合考慮)。/
運費模板可能有許多,因為不同的城市收費標準可能都不一樣,具體模板的樣式可以根據公司的實際業務去設計。一般的公司為了拉新或留存,也可能只設置一個全國通用模板,不收取運費;但在設計系統時不要為了省事就省去相關模板的設計,這些都屬于基礎功能。
在此只是梳理了最重要的兩個模板(銷售區域模板、運費模板),隨著競爭的加劇,各公司都在追求配送時效以及精準配送,所以京東等公司都推出來精準送達服務(但是需要付費的)。
這兩個模板是商品上架銷售前需要進行設置好的,對于商品在哪個渠道上銷售,還涉及渠道庫存管理,渠道選品,渠道傭金等相關的管理,這里先不討論,后續針對渠道會單獨總結一篇。
三、入庫管理
前面總結了采購管理,先回顧一下。
供應商、合同、商品等信息已經創建并生效。商品的價格及商品稅率已經維護完畢(基準價、促銷進價、進項、銷項稅)采購部創建采購訂單,審核后推送到供應商商家管理平臺供應商審核后狀態回傳到采購管理模塊采購部進行確認,單據生效后推送到倉庫系統(WMS)等待收貨。供應商發貨前預約到貨時間(如果自提則由零售商去取貨)。入庫管理-見下面流程。/
1. WMS(倉儲系統)
供應商根據采購單把貨物送到倉庫,倉庫人員按采購單進行質檢,對于不合格品達到風控線時,會整單拒收。對于有差異的采購單,會按實際數量進行入庫,在WMS入庫模塊錄入差異數量、原因等。可以收貨的商品一般分為整箱,或散貨兩種;倉庫根據包裝將商品放到移動托盤上,通過地牛或叉車等工具進行入庫操作。在倉庫中只要收貨指令開始,就要對商品進行跟蹤,所以一般托盤可以設置為移動庫存(每個托盤都有貨位編號),后續具體上架到固定庫位,只是庫位間的商品移動。如果應用了機器人,倉庫管理中此部分更加細致與嚴格。這里補充說明一下,對于一般的倉庫中,收貨組是與發貨組、庫內作業組是分開的。倉庫分為整庫、零庫,收貨時商品只能先入到整庫,然后經過庫內調撥算法進行庫內補貨,將商品從整庫調到零庫進行銷售。收貨完成后,WMS系統會進行關單操作,此時WMS系統會將入庫明細通過數據傳輸平臺回傳給SCM系統。
2. 數據傳輸平臺
這個平臺主要是用于WMS倉儲與SCM間的單據傳輸,包括下發商品等基礎信息,下發采購、返廠單、訂單等業務單據,同時接受WMS回傳的出入庫流水數據。這里集成了很多服務接口,通過消息隊列實現異步傳輸,通過數據核對來保證WMS與SCM數據的一致性。
接受入庫明細數據,并進行保存;這里的數據一般要求有,入庫的單據庫、商品、數量、價格、庫位、供應商、生產日期、倉庫、入庫時間等。此外數據平臺要根據回傳的數據進行入庫單的匯總生成,此時要與原采購單進行對照,計算出差異以便后續統計。是否要進行實時的商品成本核算?此部分我個人覺得可以不做實時的成本核算,只關注數量的計算即可,以減少后續數據不一致的麻煩。
成本核算統一放在FMS財務進銷存系統中進行,可以準實時計算或每日零點以后計算(如果業務不要求實時數據查看等)。對于成本核算的內容,可以查看《FMS財務管理系統:存貨管理》,這里不多述說。
四、SCM與財務
SCM主要是更改采購單狀態,產生SCM商品庫存。財務是根據出入庫流水單據,進行成本核算,產生財務商品庫存。
在SCM中的庫存數據,需要記錄商品級的庫存、供應商級別的庫存、倉庫級別的庫存等多維度的庫存。
多個庫存間要保證數據的一致,所以對于商品入庫時系統上的操作還是比較復雜的。
每個維度的庫存都有不同的用途,譬如倉庫有批次及貨位庫存,那么在SCM系統中也需要記錄相關的庫存信息,以便進行庫存對賬,核對差異。
今天的分享就到這里了,想了解更多關于
淘寶代運營平臺、武漢代運營等內容,敬請關注火蝠
電商代運營官網。