电商边角:「整拆零销售」的库存方案和对接机制-技术圈

点击蓝字

关注我们

#98#

分装是生产行为，拆零是经营行为。SKU拆零销售的场景多有发生，尤其是医药电商行业。主要特点是：

采购入WMS时，只登记原商品。但销售层面却拆零下账。

药品拆零分为破坏最外小包装单元，和保留最小包装单元两种情况。网上拆零销售库存方案的文章很少，本文试做小总结。

2020年以来，新冠疫情之下，口罩一直畅销。想象一个常见的场景：倘若一包口罩内含10个，但药店只剩下1个库存（一包）。这时候到药店，顾客可以买一整包口罩，也可以只买一个。假如顾客只买一个，服务员撕开包装，卖掉1个，那么：

按整包计，库存是0；

按拆零口罩计，库存还为9。

整包口罩，和拆零口罩，在数据层面，是对应两个不同的商品编码的。

二者分别计算，但同源，相互影响。

那么是不是入库时候，就应该分成两个商品编码，按照两个有关联的商品进行录入，就顺理成章了呢？功能上可以，但合规上（可能）存在阻力。

01 拆零库存的数据结构

医疗器械和药品的采购，是比较严格的GSP规范的。从药厂采购口罩的时候，一定是按包录入的流程。所以基础资料库中商品编码只会有A，不会有B。原因是：药厂无法提供单个口罩B对应的首营资料和采购单据。一旦调查，则无法圆说。因此，只会创建成包的口罩的商品信息，不创建单个口罩商品编码。（事实上所有销售范围的商品品种，都应该有进销存对应票据的。）但是行业又支持拆零销售，避免物资浪费。

2013年6月，新版的《药品经营质量管理规范》中，再次明确药品零售企业在营业场所应设立拆零专柜。

为了解决以上问题，入库系统（WMS）的办法通常是：为每个商品提供标示拆零属性的字段：拆零系数、拆零库存。
该数据结构对应视觉化，就是下图的辅助单位、换算率。

这样一来，一个商品编码A，在WMS，就会对应自身库存和拆零库存。比如A包含10个口罩，拆零系数为5，则表示拆成5份销售，每份两个。那么如果A有1个，B就有5个。

这个也就是只在库存上形成了联动，在关系上是从属。这里需要注意的是：这种拆零虽然支持，但是否拆以及是否必须拆，还可以加入限制。毕竟拆零的销售业绩不如整卖。也就是，虽然有2包，但是拆零库存可以干预为0-20之间的任何数字（假设一包1个）。解决了存储结构的问题，那么如何动态换算本商品库存和拆零库存呢？

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的库存。

当B卖掉的时候，扣减B的库存，用B的余量，换算出A的库存。

这就要创建一个仓库余量反推机制：

A的库存增加、扣减，则触发B库存的计算；
B库存的增加，不触发A的计算；但B库存的扣减触发A的计算。（因为采购的时候只会采购A）

03 拆零库存在多系统之间的交互

以上解决了WMS对拆零库存的计算问题。还要解决系统库存数据传输问题。正常情况下，一个WMS会为多个销售渠道服务。这些销售渠道会把订单对接给统一的OMS中台，商品和库存统一对接给PDM中台。于是三方形成一个库存流向四角关系：

在销售平台，是需要展示出B的，但在WMS只存在B与A的关系，不存在具象的商品编码B。这就意味着，OMS拿到的订单中的商品B，就要连同拆零系数、B的扣减个数，一并提供给WMS。让WMS看着算。需要注意：拆零系数源于WMS制定规则，但是仍然回传，防止拆零系数不一致。WMS自行按照上文描述的规则进行扣减运算。WMS算好后，连同拆零关系和整与零的库存一并提供给PDM。PDM再通过相应的映射，对应到销售渠道，如实显示A和B分别多少库存。是不是很麻烦，之所以会这样，实际是源自于如下局限：

（1）采购入口层面：出于采购合规，WMS只能创建一个A商品编码，不能创建拆零编码B；

（2）销售层面：A和B都有销售场景且销售合规。

（3）存在拆零系数的除不尽，导致不能按减量扣减再计算；只能按拆零商品的余量，反向推算出原商品。

（4）这种余量的推算，不能在销售平台完成，只在WMS兜底完成。