拆零庫存的解決方案：拆零商品的庫存結構和運算邏輯
編輯導語：隨著網際網路的發展，很多行業都開始使用各種網際網路平臺進行管理，比如新零售行業，對於零售商品的統計和商品的錄入以及庫存統計等等，都可以用這種方法來進行；本文作者分享了關於拆零商品的庫存結構和運算邏輯，我們一起來看一下。
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協議