拆零庫存的解決方案:拆零商品的庫存結構和運算邏輯
編輯導語:隨着互聯網的發展,很多行業都開始使用各種互聯網平台進行管理,比如新零售行業,對於零售商品的統計和商品的錄入以及庫存統計等等,都可以用這種方法來進行;本文作者分享了關於拆零商品的庫存結構和運算邏輯,我們一起來看一下。
SKU拆零銷售的場景多有發生,尤其是醫藥電商行業。
主要特點是:採購入WMS時,只登記原商品。但銷售層面卻拆零下賬。
網上沒找到拆零銷售庫存方案的文章,本文做個總結。
如今電商系統(C端、B端)已經很成熟,產品圈子裏電商系統產品文章很多。
但多數寫到SKU、SPU、拆單、拆包、扣/鎖庫存、最優物流這些。
實際上電商業務還有很多特殊場景,值得探討和改善。
想象一個常見的場景:
新冠疫情以來,口罩一直暢銷。
到藥店,顧客可以買一整包口罩,也可以只買一個。
倘若一包口罩內含10個,藥店只剩下1個庫存。
服務員撕開包裝,賣掉1個,那麼:
- 按整包計,庫存是0;
- 按拆零口罩計,庫存還為9。
- 整包口罩,和拆零口罩,在數據層面,是對應兩個不同的商品編碼的。
- 二者分別計算,但同源,相互影響。
那麼是不是入庫時候,就應該分成兩個商品編碼,按照兩個有關聯的商品進行錄入,就順理成章了呢?
功能上可以,但合規上(可能)存在阻力。
01 拆零庫存的數據結構醫療器械和藥品的採購,是比較嚴格的GSP規範的。
從藥廠採購口罩的時候,一定是按包的。所以基礎資料庫中商品編碼只會有A,不會有B。
原因是:藥廠無法提供單個口罩B對應的首營資料和採購單據。一旦調查,則無法圓説。
因此,只會創建成包的口罩的商品信息,不創建單個口罩商品編碼 。
(事實上所有銷售範圍的商品品種,都應該有進銷存對應票據的。)
但是行業又支持拆零銷售,避免物資浪費。
2013年6月,新版的《藥品經營質量管理規範》中,再次明確藥品零售企業在營業場所應設立拆零專櫃。
為了解決以上問題,入庫系統(wms)為每個商品提供標示拆零屬性的字段:拆零庫存、拆零係數。
也就是下圖的輔助單位、換算率。
這樣一來,一個商品編碼A,入庫的時候,就會對應自身庫存和拆零庫存。
比如A包含10個口罩,拆零係數為5,則表示拆成5份銷售,每份兩個。
那麼如果A有1個,B就有5個。
這個也就是隻在庫存上形成了聯動,在關係上是從屬。
解決了存儲結構的問題,那麼如何動態換算本商品庫存和拆零庫存呢?
02 拆零庫存的計算我們還以上面的例子來看,B的庫存實際來源於A。
若A中有10個B,拆零係數是10。那每扣減一個A,就要觸發扣減10個B的庫存;
同樣,每扣減一個B,就要觸發扣減1/10=0.1個A的庫存。
還拿口罩一包10個的例子,假設整包A的庫存為2,換算出拆零B的庫存就為20。
單個賣掉3個,那麼單個口罩的庫存就是17。整包庫存就是2-0.3=1.7個。
這時對於C端銷售平台,只需要向下取整顯示1個即可。
庫存的計算問題似乎解決了。但是……
如果一包有3個口罩呢?上述公式就會出問題。
若一個A中有3個B,那每扣減一個B,就要觸發扣減1/3=0.33個A的庫存。
3這個數字除不盡,會導致第三個B出售的時候,A還剩下0.01個。但實際A已經是0。
如果這0.01個累加到100次,就會錯誤地多出1個A的庫存。
這個誤差傳遞給WMS的時候,WMS並不知道如何消除。
而我們又不能依賴WMS的盤點去消除。
於此同時,還存在一個問題,就是如果一包含有1000個,那麼小數要支持4位嗎?數據表字段屬性難以確定位數。
總結以上問題:
- 存在除不盡,導致計算差異的問題;
- 拆分的係數導致小數位不確定的問題。
怎麼辦呢?
解決辦法就是當扣B的庫存,計算A的時候,不按照減量,而是按照B的存量,反向推算A。
當A賣掉的時候,扣減A的庫存,觸發按係數算出B的庫存;將二者同步到C端。
當B賣掉的時候,扣減B的庫存,用B的餘量,換算出A的庫存;將二者同步到C端。
這就要創建一個倉庫餘量反推機制:
- A的庫存增加、扣減,則觸發B庫存的計算;
- B庫存的增加,不觸發A的計算;但B庫存的扣減觸發A的計算。(因為採購的時候只會採購)
以上解決了WMS對拆零庫存的計算問題。還要解決系統庫存數據傳輸問題。
正常情況下,一個WMS會為多個銷售渠道服務。
這些銷售渠道會把訂單對接給統一的OMS中台,商品和庫存統一對接給PDM中台。
於是三方形成一個庫存流向四角關係:
在銷售平台,是需要展示出B的,但在WMS只存在B與A的關係,不存在具象的商品編碼B。
這就意味着,OMS拿到的訂單中的商品B,就要連同拆零係數、B的扣減個數,一併提供給WMS。
WMS自行按照上文描述的規則進行扣減運算。
WMS算好後,連同拆零關係和各自的庫存一併提供給PDM。
PDM再通過相應的映射,對應到銷售平台的A和B。
是不是很麻煩,之所以會這樣,實際是源自於如下侷限:
- 採購入口層面:出於採購合規,WMS只能創建一個A商品編碼,不能創建拆零編碼B;
- 銷售層面:A和B都有銷售場景且銷售合規。
- 存在拆零係數的除不盡,導致不能按減量扣減再計算;只能按拆零商品的餘量,反向推算出原商品。
- 這種餘量的推算,不能在銷售平台完成,只在WMS兜底完成。
- 電商體系的基礎方案已經成熟。但隨着業務和政策的發展,總會有新的場景出現。
- 業務決定系統。儘量驅動業務避開復雜的處理方案,系統就會輕鬆。
- 邊角場景的考慮更需要判斷和鑑別。
以上若存在描述不清或錯誤,歡迎探討。
#專欄作家#唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產品經理專欄作家,2019年年度作者。《後端產品經理寶典》作者,藥學碩士轉行互聯網產品多年;熟悉跨境電商業務,醫藥領域;擅長大型後台體系,社交APP。
本文原創發佈於人人都是產品經理,未經作者許可,禁止轉載
題圖來自Unsplash,基於CC0協議