库存预测
基于 STL 季节分解预测 + COC K-Risk 安全库存，模拟多服务水平下的备货策略，输出每个 SKU 的目标库存、总库存天数等 KPI
仿真结果
当前仿真的运行状态与结果。完整预测记录请访问 后台管理
使用指南
快速上手 — 5 步完成一次库存仿真
-
准备 POS 销量数据
导出 Excel 工作簿，包含一个名为「销售数据」的工作表，至少包含以下列：
ids下单时间、8位码、订单数量、门店编码。确保日期格式统一，建议提前去除异常大单。✓ 建议准备至少 6 个月以上的历史数据，效果更准确 -
上传 POS 文件（必填）
在左侧上传区上传 POS Excel 文件，系统会自动读取「销售数据」工作表。上传成功后按钮变绿并显示文件名。
-
（可选）上传辅助文件
门店主数据：用于按「客户分类」过滤门店（如剔除大批发）。
商品主数据：用于接入商品单价，计算库存金额。 -
配置仿真参数
预测区间：设置仿真的起止日期，需在 POS 数据覆盖范围内。
服务水平：输入 1 个或多个，如0.90,0.95,0.98，每个水平独立跑一次仿真。
订货周期 CT：两次下单之间的间隔（天）。
净补货提前期 NRLT：从下单到可销售入库的净时长（天）。
覆盖天数：在 COC 基础覆盖之外额外加的保险天数。 -
运行仿真，解读结果
点击「开始仿真」，等待完成后查看各服务水平的 KPI 摘要、场景对比表和分 SKU 明细。可下载 CSV 用于 Excel 进一步分析。
✓ 建议从 3 个服务水平开始（90%、95%、98%），对比库存成本与服务水平的权衡
新品入库评估
新品上线前，根据同类 SKU 的 COV 和销售趋势，预估合理备货量，降低新品滞销风险。
服务水平权衡分析
对比不同服务水平下的库存天数和缺货率，找到库存成本与缺货风险的最佳平衡点。
安全库存复盘
用历史真实缺货数据验证安全库存设置是否合理，识别哪些 SKU 需要调高或调低。
参数说明
每个参数的作用、取值范围和对结果的影响
| 参数 | 说明 | 默认值 |
|---|---|---|
| 预测起始日 | 仿真区间的第一天（包含）。系统会在此日期之后使用 STL 模型计算每日预测。需确保 POS 数据覆盖此日期。 | 2025-01-01 |
| 预测截止日 | 仿真区间的最后一天（包含）。期间每日计算一次目标库存并进行库存仿真。 | 2025-08-30 |
| 服务水平 | 循环服务水平（Cycle Service Level），即在补货周期内不发生缺货的概率。取值 0~1，数值越高，安全库存越大，缺货概率越低。可输入多个（逗号分隔），每个值独立跑一次仿真。 | 0.90, 0.95, 0.98 |
| 订货周期 CT（天） | 两次下单之间的时间间隔。CT 越长，单次补货需要覆盖的需求越多；同时 CT 会进入 K-Risk 查表目标值计算。 | 7 |
| 净补货提前期 NRLT（天） | 从下单到货物可销售入库的净时长。NRLT 一方面用于安全库存计算，另一方面也用于库存仿真中的到货延迟。 | 3 |
| 覆盖天数（cover） | 额外希望覆盖的未来销售天数。目标库存 = (安全天数 + 覆盖天数) × 预测日均。CT 和 NRLT 不直接参与目标库存计算。 | 0 |
| 最小历史天数 | 用于 STL 季节分解预测的最小回溯窗口天数。若某 SKU 有效历史少于该值，则使用 90 天均值（P90D）替代 STL 预测。 | 90 |
| 最小有销量天数 | 历史数据中实际有销售（订单数量 > 0）的天数要求。若不足，也使用 P90D 替代。 | 60 |
| 剔除门店类型 | 根据「客户分类」字段过滤门店，不纳入仿真。需配合门店主数据使用。例如填写 大批发,团购 可剔除这两类门店的数据。 |
大批发, 团购 |
安全天数（COC 方法）
安全天数 = K × COV × √(7 × NRLT)（界面中的 NRLT 用天输入；内部按 COC 口径换算参与 K-Risk 查表）target = (1-服务水平) × CT / (COV × √(NRLT/7)) 查内置 K-Risk 因子表得到 K 值（系统已锁定出厂表，无需上传）。K 最小取 0，安全天数上限默认 14 天（可调）。目标库存
目标库存 = (安全天数 + 覆盖天数) × 预测日均（CT 和 NRLT 不直接参与目标库存计算，仅用于安全天数推导）A 类（占滚动30天销量 ≤ 80%）：取
high 预测B 类（累计 ≤ 95%）：取
neutral 预测C 类（其余）：取
low 预测neutral = STL 趋势 EWM 平滑值high = 中位数以上季节因子的均值（偏乐观）low = 中位数以下季节因子的均值（偏保守）数据格式说明
各文件所需的工作表结构、列名和示例数据
2025-01-01），避免使用文本格式。商品编码（8位码）建议为数值型，避免前导零丢失。
界面参数输入格式必填
| 参数 | 类型 | 格式要求 | 示例 |
|---|---|---|---|
服务水平 | 文本 | 0~1 之间的小数，多个值用英文逗号分隔 | 0.90,0.95,0.98 |
订货周期 CT | 整数 | 单位：天，范围 1~20 | 7 |
净补货提前期 NRLT | 整数 | 单位：天，范围 1~10 | 3 |
覆盖天数 | 整数 | 单位：天，范围 0~30 | 0 |
POS 销量历史（必填）必填
| 列名 | 类型 | 说明 | 示例 |
|---|---|---|---|
ids下单时间 | 日期 | 订单日期 | 2025-01-01 |
8位码 | 文本/数值 | 商品条码（SKU 唯一标识） | 6901234567890 |
订单数量 | 数值 | 当日该 SKU 的销量（件） | 50 |
门店编码 | 文本 | 门店唯一标识，用于与门店主数据匹配 | 100001 |
门店主数据（可选）可选
| 列名 | 类型 | 说明 | 示例 |
|---|---|---|---|
customer_code | 文本 | 与 POS 中「门店编码」对应的字段名（系统也会自动匹配含"门店编码"、"customer_code"字样的列） | 100001 |
客户分类 | 文本 | 门店分类，用于按类型过滤，如"大批发"、"备库存"、"中小批"、"团购"等 | 备库存 |
商品主数据（可选）可选
| 列名 | 类型 | 说明 | 示例 |
|---|---|---|---|
商品条码 （或 Item Code / barcode） | 文本/数值 | 与 POS 中「8位码」对应的商品条码，用于匹配单价等属性 | 6901234567890 |
单价 （或其他属性列） | 数值 | 商品单价（单位：元），用于计算库存金额 | 12.50 |
结果解读指南
如何看懂仿真输出的各项 KPI，并做出业务决策
实际服务水平
最核心的供货结果指标，表示整体需求里有多少被真正满足。越高越好，适合判断服务水平是否达标。
实际缺货率
整体未满足需求占比，等价于 1 - 实际服务水平。它是"总体缺口率"，不是"发生缺货时的平均严重程度"。
推荐库存（箱）
这是"全周期平均目标库存箱数"，表示在当前服务水平下，组合日均应该持有多少目标库存，不是某一天库存，也不是累计箱数。
推荐金额
推荐库存对应的资金占用，也是全周期平均口径。可直接理解为"当前服务水平下建议日均压多少钱在库存里"。
推荐天数
推荐库存折算后可覆盖多少天平均需求。适合和实际天数一起看，判断目标库存是否偏高或偏低。
实际均存（箱） / 实际天数
这两个指标反映仿真结果里真实持有了多少库存、又能覆盖多少天需求。一个看规模，一个看周转。
平均缺货量（箱）
衡量"缺货一旦发生，平均会缺多少箱"。这里只统计缺货值大于 0 的 SKU-Day，所以反映的是缺货严重程度，不是整体缺货率。
平均缺货金额 / 平均缺货天数
前者反映缺货事件的平均资金损失，后者反映发生缺货的 SKU 平均会缺几天。两个指标都用于看缺货"有多痛"，不是看缺货"有多常见"。
平均缺货天数 = Avg(每个 SKU 的缺货天数 ｜ 仅统计发生缺货的 SKU)
🎯 实际服务水平目标参考
根据行业经验，不同品类的建议服务水平：
| 普通消费品 | ≥ 95% |
| 医药 / 母婴 | ≥ 98% |
| 工业品 / 配件 | ≥ 93% |
| 长尾 / C 类 SKU | ≥ 85% |
📊 库存天数参考
合理的库存天数取决于补货频率和提前期：
| 偏低 | < 提前期 × 1.5 |
| 合理 | 提前期 × 1.5 ~ 提前期 × 3 |
| 偏高 | > 提前期 × 3 |
| 过高 | > 提前期 × 5 |
贡献 80% 销量的核心 SKU，通常占 10%~20% 的 SKU 数量。
建议高服务水平（≥ 97%）
贡献 15% 销量的次要 SKU，通常占 30%~40% 的 SKU 数量。
建议中等服务水平（93%~97%）
贡献 5% 销量的长尾 SKU，通常占 50%~60% 的 SKU 数量。
建议较低服务水平（85%~93%）
常见问题
使用中可能遇到的疑问和解答
.xls 格式（而非 .xlsx 格式），系统未能自动识别。请尝试将文件另存为 .xlsx 格式后再上传。该问题已在 v1.3 中修复，系统已支持自动检测两种格式。
actual（实际销量）作为每日需求，同时用 STL 模型计算预测值。actual 来自 POS 数据，所以仿真期间每日的实际需求会自动取真实值。预测截止日可以早于或等于 POS 数据最后一天，但不应晚于 POS 数据最后一天，否则部分日期的实际需求会为 0。
大批发,团购，可以将这些异常订单排除，使预测更稳定。
建议对比相邻服务水平（如 95% vs 98%）的差距：如果实际服务水平提升很小（如从 97.2% 到 97.8%），但库存天数大幅增加（如从 18 天到 26 天），说明 95% 是更经济的选点。
参考经验：A 类核心 SKU 建议 ≥ 97%，B 类 93%~97%，C 类 85%~93%。
COV 上限设为 1.5，是为了防止某些低销量长尾 SKU 因分母太小而异常放大，导致安全库存过高；如果 COV = 0，系统直接给 0 安全天数。
NRLT：从下单到可销售入库的净补货提前期，用来衡量补货在途期间的需求波动风险。
覆盖天数（Cover Days）：在 CT + NRLT 的基础上，再额外增加的保险覆盖天数。
三者共同决定目标库存：
目标库存 = (安全天数 + CT + NRLT + 覆盖天数) × 预测日均。
8位码 / ids下单时间 / actual（实际销量）/ FCST（预测日均）/ safetydays（安全天数）/ COV（变异系数）/ ct_days / nrlt_days / cover_days / label（ABC 分类）/ target_inv（目标库存）/ cycle_service_level（当前服务水平）/ opening_stock / intransit / closing_stock / purorder / fulfill（实际满足量）
1000 SKU × 240 天 ≈ 10 秒内完成（后台线程运行，不影响 UI）。
若 SKU 数量超过 5000，或仿长时间超过 365 天，建议分批处理或减少仿真天数。仿真在后台线程中运行，页面不会卡死，可以继续浏览使用指南。
cycle_service_level（循环服务水平） 是安全库存的设计目标，而实际 实际服务水平 是仿真结果。两者不完全相等，因为：1. 实际需求波动大于预测误差
2. 补货是离散的（每次补一整批），而非连续补充
3. 安全库存只覆盖需求波动，不覆盖预测偏差
一般实际服务水平会接近但略低于设计服务水平。若差距较大（如设计 98% 但实际服务水平只有 90%），说明预测模型需要优化或历史数据有异常。