核心要点
根据库存、销量等数据自动计算各门店补货建议数量的系统机制，是补货业务的核心引擎。
关联概念
- 触发方式：定时任务（通常每日凌晨）或手动触发，批量计算所有门店建议补货量
- 计算逻辑：综合当前库存、历史销量、安全库存、在途量等因子，输出建议数量
- 执行周期：固定周期运行（如每日 02:00），运行时长 10-30 分钟
- 失败影响：算法未执行或中断，补货建议数据不更新，门店看到旧数据
应用场景
- 卡折扣供应商承担折让未生效排查：同类对比——同为业务规则匹配问题
- OPL自动补货参数体系：延伸应用
- OPL补货计算实例：同类对比
- 系统日结机制：前置基础
- 分店订单统一录入逻辑：延伸应用——订单录入影响补货算法入参
- 库存同步任务：前置基础——库存同步是补货算法的数据来源
- 库存同步延迟导致补货数据异常：延伸应用——同步异常致补货建议异常
- 补货单生成排查（旧单据影响）：延伸应用——算法正常但单据生成受阻的排查
常见误区
- 场景1：门店反馈补货建议数量异常时，检查算法是否正常执行
- 场景2：补货建议数据长时间未更新，确认算法调度是否中断
- 场景3：调整补货参数（如安全库存阈值）后，验证算法输出变化
参考来源
- 误区1：算法执行失败=系统崩溃 → 正确做法：算法失败通常是调度中断或数据异常，检查日志即可恢复
- 误区2：手动触发算法有风险 → 正确做法：手动触发是标准运维操作，但需在业务低峰期执行
变更日志
- 运维知识库冷启动（零售补货业务场景）
关键参数
- 2026-08-03：初始创建（补全知识网络前置概念）
操作速查
| 参数 | 含义 | 维护位置 | 调优方向 |
|---|---|---|---|
| 运行频率 | 算法每日执行次数 | 调度系统 | 增加→建议更及时；减少→系统压力小 |
| 安全库存系数 | 库存缓冲比例 | 系统配置 | 增大→降低缺货风险；减小→降低库存成本 |
排查指引
- 检查算法执行日志：查询
replenishment_algorithm_log - 确认算法调度状态：检查调度系统任务是否正常
- 手动触发算法：调用
sp_manual_replenishment_algorithm
正文
- 症状：补货建议数据未更新
- 检查：算法执行日志（查
replenishment_algorithm_log，筛选最近24小时） - 处理：无记录 → 检查调度；有记录但失败 → 查看
error_msg定位原因