拆零库存的解决方案：拆零商品的库存结构和运算逻辑
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。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
