故障 1：补货量异常（太多或太少）
现象：某个商品突然补了一大堆远超过正常销量的货，或者库存见底了也不触发补货。
- 先查 DMS：是不是 N 天内有异常销量（促销、团购）拉高了平均值？用 SQL 查最近 N 天的日销量明细。
- 再查 ABC：商品是否被错误分类？A 类误判为 C 类会导致补货不足。
- 查生命周期：商品状态是否为"暂停进货"？季节性商品过季自动暂停是设计行为，不是 bug。
- 查库存上下限参数：安全库存日、系数、陈列量是否被人为调过？查看参数变更记录（如果系统有的话）。
- 查额外备货：是否有活动的额外备货审批在生效？活动结束后是否及时取消？
根因方向：补货量异常 90% 是参数问题而非系统 bug。先排查 "谁改了什么参数"，再排查数据源头（销量/库存数据是否准确）。
故障 2：补货申请单未生成
现象：到了补货时间点，OPL 没有自动生成补货申请单，或者生成后又消失了。
- 查日结：前一日日结是否正常完成？日结未完成或失败 → OPL 拿不到最新库存和销量 → 不触发补货。
- 查商品状态：是否处于"暂停进货"或"作废"状态？批量检查方法：按门店+类目查询生命周期状态。
- 查供应商：供应商档案是否正常？供应商退场/停用会导致关联商品不参与补货。
- 查合同：合同是否过期？过期合同绑定的商品同样不受补货管理。
- 查补货参数：补货周期/订货日是否正确配置？参数变更链路（门店→数据组→信息）是否存在信息丢失？
日结是第一顺位排查项：OPL 依赖日结后的库存和销量数据。日结不完成 = OPL 用旧数据 = 可能不触发或算错。先确认日结状态再查其他。
故障 3：参数变更后补货反常
现象：调完某个参数后，补货行为完全不符合预期，甚至比调之前更差。
- 确认改了什么：找到变更记录（谁、什么时候、哪个参数、从多少改到多少）。如果系统没有变更记录，靠"我记得上次调过"来排查极其困难。
- 回滚验证：如果无法确认根因，优先恢复到变更前的参数值，观察补货是否恢复正常。
- 小范围测试：大范围调参前，先选 1-2 个品类/门店做试点，确认效果后再推广。
治理缺口：当前 OPL 参数变更多环节传递（门店/采购→数据组→信息），缺系统级变更记录。这是已知的优化方向——建立参数变更台账，每次变更记录操作人、时间、对象、旧值、新值、变更原因。
故障 4：物流模式分流错误
现象：标品走了配送模式（多了一个中转环节），或生鲜走了直送模式（供应商无法履约）。
- 查物流模式配置：在商品采购信息中确认物流模式（直送/直配/配送）是否正确。
- 生鲜 vs 标品规则：当前示例零售集团：生鲜走配送中心中转，标品走直送。如果某个品类配反了，订货单会发到错误的物流节点。