WMS批次管理看似基础，实则暗藏玄机。当内部批次号生成规则遇上调拨退货、供应商字段空值挑战百分百溯源、SKU-库位-批次表面临海量数据考验时，你的设计思路是否经得起灵魂拷问？本文从实战场景出发，拆解批次属性设计、库存表分层与SaaS多租户架构的避坑指南，帮你用‘抓大放小’的务实策略破解管理迷思。
最近有一位《海外仓OTWB项目实战》的读者朋友，跟我咨询了几个WMS的批次管理和库存表设计的问题，这几个问题都很有代表性。
我在之前的项目中也遇到过，也思考过。而且我认为其他在做相关项目的朋友应该也会遇到，所以我就把他和我的对话，以及我自己的一些思考和延伸的内容都整理出来，分享给大家。
问题1：内部批次号的生成规则是什么？
同一产品每次入库都会产生唯一的内部批次号吗？像调拨、销售退货等入库是不是也会产生内部批次号？如果会的话，那这些批次号是否需要记录供应商？
问题2：供应商为空的批次怎么处理？
如果我想用供应商作为批次属性，方便做按供应商冻结库存的功能。但调拨和销售退货没有供应商信息，这样入库后产生的批次，供应商字段就是空的。那按供应商召回产品，是不是就做不到百分百冻结了？
问题3：SKU-库位-批次库存表的设计问题这张表是一张表里有SKU、库位、批次等字段吗？数据量会不会非常庞大？某行记录库存数变0了，需要删除吗？SaaS模式下，是所有租户共用一张表，还是分表？
关于问题1：批次号是否生成、怎么生成，取决于你对批次属性的定义。供应商可以作为批次属性之一，但不是唯一因素。调拨、退货等入库场景，同样会生成批次，只不过供应商字段默认为空。其他属性（如生产日期、入库时间等）不同，批次号也会不同。
关于问题2：供应商本身只是批次属性之一，不会所有批次都有这个信息。退货、调拨、盘盈等场景天然没有供应商信息。所以，想要百分百按供应商溯源，本身就不太现实。如果业务上确实需要，可以在退货或调拨时，要求指定或分配一个供应商信息。
关于问题3：SKU-库位-批次表确实是最细粒度的库存表，数据量会比较大，这是正常的。库存为0的记录一般不删除，保留0的快照数据，流水记录也会留存，方便后续追溯。SaaS模式下，通常是所有租户共用一张表，按租户ID区分。按租户分库分表成本更高，一般不推荐。
这几个问题背后，有几个知识点可以展开聊聊：
批次属性不是固定的，常见的有：供应商、生产日期、入库日期、生产批号、保质期等。具体选哪些，取决于业务对溯源和管理的需求。
设计原则：够用就好，不要过度设计。
属性越多，批次越细，带来的问题是：库存碎片化严重，同一个SKU可能有几十上百个批次拣货时批次匹配逻辑复杂，效率下降库存周转分析、效期管理的复杂度上升
建议的做法是：先梳理业务场景，明确”为什么要管批次”，再决定需要哪些属性。比如：食品行业：生产日期、保质期是刚需，用于效期管理和先进先出医药行业：生产批号、供应商是刚需，用于质量追溯和召回普通快消品：可能只需要入库日期，做基本的先进先出就够了
核心问题：什么时候生成批次？
常见的做法是：每次入库都生成批次，但批次号的生成规则可以灵活设计。
方案一：入库即生成新批次每次入库（采购、退货、调拨、盘盈）都生成一个新的批次号优点：简单，不用判断是否合并缺点：批次数量多，库存碎片化
方案二：相同属性合并批次如果本次入库的批次属性（供应商、生产日期等）和已有批次完全一致，就合并到同一批次优点：批次数量少，库存集中缺点：逻辑复杂，需要判断属性是否匹配
方案三：按入库单据生成批次同一张入库单的商品归为同一批次优点：批次和单据一一对应，追溯清晰缺点：同一供应商多次送货会产生多个批次
在实际项目中，方案二最为常见，也比较均衡，能适用于不同的业务场景，但是整体带来的工作量也不会很大。
这是群友问的核心痛点：调拨、退货、盘盈等场景没有供应商，批次的供应商字段只能为空。
务实的做法：接受”供应商为空”是正常状态。
原因很简单：调拨入库：货是从其他仓库调过来的，源头供应商信息可能已经丢失销售退货：客户退回来的货，你很难追溯当初是哪个供应商供的盘盈：凭空多出来的库存，根本没有供应商
如果业务上确实需要供应商信息，可以这样处理：调拨：在调拨出库时，把原批次的供应商信息带到调拨单上，调拨入库时继承退货：要求退货时关联原销售订单，再追溯到原采购批次的供应商盘盈：人工指定一个默认供应商，或者标记为”未知供应商”
但要注意，这些做法都会增加系统复杂度和操作成本，需要权衡。在实际的业务中，很多仓库的执行能力都没有预期中的那么高，过多的批次属性，批次信息会带来指数级的管理难度和成本，并不一定是件好事。
很多人在设计批次管理时，会有一个执念：总想要做到百分百溯源，总想要完美精准。但实际上，这是一种成本很高、收益却很有限的做法。
为什么说成本高？
要实现完美溯源，意味着每一个环节都要严格记录、每一次流转都要精确关联。这带来的是：仓库操作复杂度大幅上升（每次拣货、移库都要扫码确认批次）系统开发和维护成本增加（要处理各种异常场景的批次拆分、合并）业务流程变慢（为了记录准确，牺牲了效率）
为什么说回报有限？
在实际业务中，退货、调拨、盘盈等场景会天然打破”完美溯源”的链条。你花了大量成本去维护的溯源体系，在这些场景下根本用不上。更现实的情况是：真正需要溯源的质量事故，一年可能就那么几次，而你为此付出的日常成本却是持续的。
溯源的本质是：出了问题能找到责任方，而不是追求100%的数据完美。
如果你的业务场景是：供应商A的货出了质量问题，需要召回 → 按供应商冻结批次某个生产批号的产品有缺陷，需要下架 → 按生产批号冻结批次
那你需要在入库时把这些关键信息记录清楚就够了。但对于退货、调拨等”二手库存”，溯源链条本身就是断的，系统只能尽力而为——这不是系统的问题，而是业务本身的特性。
建议的产品设计思路：抓大放小，够用就好采购入库：必填供应商、生产批号等关键信息（这是溯源的主要来源）退货/调拨/盘盈：供应商等字段可为空，但要有明确的标识（如”来源：销售退货”）召回/冻结功能：支持按供应商、批次号等条件筛选，但要在界面上提示”可能存在无法匹配的库存”
功能可以做，但不要过度设计。与其追求100%溯源，不如把精力放在”出问题时能快速定位80%的库存”上——这才是性价比最高的方案。
WMS的库存表通常会分成两层：SKU维度库存（汇总层，查总量）SKU-库位-批次维度库存（明细层，查库位分布和批次明细）
不同场景查不同的表，兼顾性能和精度。
为什么要分层？
如果只有一张SKU-库位-批次的明细表，每次查库存总量都要聚合计算，性能会很差。分成两层之后：查”这个SKU还有多少库存” → 查SKU维度表，一条记录搞定查”这个SKU在哪些库位”或”这个批次还剩多少” → 查SKU-库位-批次维度表
两层设计既能满足快速查询总量的需求，又保留了完整的库位和批次明细，避免了三层设计带来的维护复杂度。
数据一致性怎么保证？
每次库存变动，两张表要同步更新。通常的做法是：先更新SKU-库位-批次明细表再同步更新SKU汇总表定期做数据校验，确保两层数据一致
共用一张表+租户ID是最常见的做法，简单、成本低。分库分表虽然隔离性更好，但运维成本高，一般只有超大规模租户才会考虑。
共用表的设计要点：每张表都要有tenant_id字段，所有查询都要带上租户条件索引设计要把tenant_id放在前面，比如(tenant_id, sku_id, warehouse_id)做好数据隔离，防止A租户看到B租户的数据
什么时候考虑分表？单个租户的数据量特别大（比如日均百万级库存变动）租户对数据隔离有强合规要求（比如金融、医疗行业）租户愿意为独立资源付费写在最后
聊了这么多，其实就一句话：批次管理别想太复杂，够用就好。
很多时候我们容易陷入一种执念——觉得系统必须做到”滴水不漏”，每一笔库存都能追溯到源头。但现实是，退货、调拨、盘盈这些场景，天然就会打破你精心设计的溯源链条。与其花大力气去堵这些”漏洞”，不如一开始就接受它们的存在。
系统是为业务服务的，不是为了满足我们的完美主义。
本文由人人都是产品经理作者【PM维他命】，微信公众号：【PM维他命】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。