拆零庫存的解決方案:拆零商品的庫存結構和運算邏輯

編輯導語:隨着互聯網的發展,很多行業都開始使用各種互聯網平台進行管理,比如新零售行業,對於零售商品的統計和商品的錄入以及庫存統計等等,都可以用這種方法來進行;本文作者分享了關於拆零商品的庫存結構和運算邏輯,我們一起來看一下。

拆零庫存的解決方案:拆零商品的庫存結構和運算邏輯

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的計算。(因為採購的時候只會採購)
03 拆零庫存在多系統之間的交互

以上解決了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兜底完成。
04 結語
  • 電商體系的基礎方案已經成熟。但隨着業務和政策的發展,總會有新的場景出現。
  • 業務決定系統。儘量驅動業務避開復雜的處理方案,系統就會輕鬆。
  • 邊角場景的考慮更需要判斷和鑑別。

以上若存在描述不清或錯誤,歡迎探討。

#專欄作家#

唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產品經理專欄作家,2019年年度作者。《後端產品經理寶典》作者,藥學碩士轉行互聯網產品多年;熟悉跨境電商業務,醫藥領域;擅長大型後台體系,社交APP。

本文原創發佈於人人都是產品經理,未經作者許可,禁止轉載

題圖來自Unsplash,基於CC0協議

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 2335 字。

轉載請註明: 拆零庫存的解決方案:拆零商品的庫存結構和運算邏輯 - 楠木軒