临时卷料入库连续出现条码规则、旧卷料号覆盖和零库存判断问题。表面上是三个小修复，背后其实是同一个工程难题——“什么才算一盘可用、可追溯、可继续流转的物料”。

仓库系统最危险的 bug，不是报错，而是把不该入库的物料顺利放进去了。​

01  问题是怎么暴露出来的？

临时卷料入库入口在 IssueController 的 ScanTemporaryReel 相关流程。第一眼看，它只是接收条码、查物料、写入库存；但现场数据一复杂，三个“默认假设”就会失效：条码格式并不固定、旧卷料可能带着错误料号、库存记录可能存在数量为 0 的历史行。

如果只在入口加一条 if，代码能通过，现场却可能继续出问题。因为校验必须同时回答：条码是否符合当前工厂规则？旧数据是否需要覆盖？数量为 0 的记录到底算不算有库存？​

02  三个真正容易改错的点

坑一  ·  把条码规则写死在代码里

项目最初需要对内销成品入库的临时条码做非法字符校验。直接把正则写在 Controller 里看似最快，但一旦不同产线、不同标签规则需要调整，就得重新发版。实际修复中，规则被放进 IMS_LOOKUP：程序运行时按 TYPE=TEMPORARY_REEL_BARCODE_REGEX、CODE=1 读取，并对“未配置”和“正则配置错误”分别报错。

坑二  ·  只校验新条码，不处理旧卷料号

临时收货并不是“新建一盘料”这么简单：系统里可能已经存在同条码、但料号过期或不正确的卷料记录。项目后续修复把旧卷料号覆盖纳入 ReelManager 与 IssueController 的联动处理，避免条码、料号、库存三者互相矛盾。

坑三  ·  把“有库存记录”当成“有可用库存”

StockManager 中，库存行存在不代表物料可用。项目提交记录明确补了“zero quantity reel as no stock”：数量为 0 的卷料必须按无库存处理，否则上层拣料、可用量判断会被一条历史空记录误导。​

03  这次修复真正沉淀下来的方法

• 把规则与代码解耦：可变的业务规则放配置表，代码负责读取、校验和异常提示。

• 把对象看完整：条码、料号、库存数量和业务单据必须一起判断，不能只修一个字段。

• 把“存在”和“可用”分开：数据库有记录、库存大于零、允许继续流转，是三个不同概念。

• 把异常路径写清楚：未配置、格式错误、旧数据冲突、零库存，都要给现场人员可执行的提示。

这也是 AI 参与老系统改造时最值得借鉴的地方：先让它把调用链、配置项、数据状态和历史兼容关系找全，再生成最小改动。否则，AI 很容易只修复“当前报错”，却遗漏下一层业务边界。

​

04  对客户来说，这类修复意味着什么？

仓库现场真正关心的不是代码改了几行，而是扫码时能不能及时发现问题、错误物料会不会进入库存、后续拣料和对账会不会被脏数据拖住。把条码规则、旧数据修复和零库存语义补齐后，系统才从“能操作”变成“可控地操作”。

​

05  真正专业的交付，体现在“边界被补齐”

这次项目没有一个“惊天动地”的大功能，只有几处看起来很小的修改：动态条码正则、旧卷料号覆盖、零库存按无库存处理。但它们共同解决的是仓储系统最核心的可信度问题：系统里的每一盘料，为什么被允许进入下一步。

如果你的 WMS、MES 或 ERP 也在经历“偶发错料、历史数据难清、规则一变就要发版”，优先排查的往往不是页面，而是这些隐藏在数据和状态里的业务边界。

仓储系统的专业，不在于流程看起来复杂，而在于每个边界都能被验证。
​

​