

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 常见问题和解决方案
<a name="common-issues-and-solutions"></a>

## 常见数据问题
<a name="common-issues-common-data-issues"></a>

### 需求历史记录的日期格式各不相同
<a name="common-issues-demand-history-mixed-date-formats"></a>

源系统可能会将日期导出为 DD/MM/YYYY MM/DD/YYYY、或 YYYY-MM-DD，有时在同一个文件中。系统可能会错误地解析这些内容，从而将订单分配给错误的月份。

**修复：**标准化导出过程中的日期格式。如果您无法控制来源，请在数据流 SQL 中添加日期验证。

### 订单历史记录中的数量为负数
<a name="common-issues-negative-quantities"></a>

贷记单、退货或冲销可能显示为负数。这些可能会扭曲需求平均值并混淆模型。

**修复：**仅筛选为正数，或按订单状态筛选（例如，仅限 Paid/Invoiced 订单）。

### 记录数与您的源系统不匹配
<a name="common-issues-record-counts-dont-match"></a>
+ 最常见的是由复合密钥冲突引起的——如果两条记录共享相同的唯一标识符，则一条记录会覆盖另一条记录。
+ 如果数据映射中的筛选条件排除您期望看到的记录，也会发生这种情况。

提供具体的产品\+网站示例以及您的预期记录数，以便团队可以追踪差异。

### 系统中显示的 ERP 中不存在的订单（反之亦然）
<a name="common-issues-orders-dont-exist-in-erp"></a>
+ 在两次报告运行之间已配送或移除的订单将在下次刷新后消失，但仍可能出现在前一天数据生成的异常中。
+ 新创建的订单要等到下一次数据刷新后才会出现。

这是预期的行为——加载新数据后，异常将在下一个评估周期中更新。

### 计划输入文件包括来自其他工厂或业务部门的产品
<a name="common-issues-plan-inputs-other-plants"></a>

如果您的源系统导出包括预测项目范围之外的产品：
+ **系统将自动筛选到主产品。**只有您的产品主文件中存在的产品才会包含在预测中。但是，如果您的输入文件中有很大一部分超出了范围（例如，50% 以上的行），则表明需要加强源导出。
+ **定期检查您的产品覆盖率。**每次加载数据后，请验证销售和预测输入文件中与基本产品相匹配的产品百分比。如果覆盖率降至 80% 以下，请调查源导出范围是否已更改或基础产品需要更新。
+ **Out-of-scope 计划输入中的产品可能会导致总数膨胀。**如果您的 EDI 或 SIOP 文件包含来自其他工厂的产品，则总体预测信号将高于应有的水平。加载之前，请确保将计划输入文件筛选到与基础产品相同的产品范围。

## 常见的例外和建议问题
<a name="common-issues-exception-recommendation-issues"></a>

### 同一个产品\+网站多次出现在例外列表中
<a name="common-issues-duplicate-exceptions"></a>

当基础规则为预测期内的每个限定日期生成单独的例外情况时，就会发生这种情况。

请联系您的支持团队，调整规则，仅举报每个产品和网站的最早违规日期。

### 推荐与我在图表中看到的不符
<a name="common-issues-recommendation-doesnt-match-chart"></a>

建议由 AI 代理生成，该代理会分析创建例外时的可用数据。如果此后数据发生了变化，则该建议可能会引用已过时的订单或数量。
+ 查看异常的时间戳——如果异常超过一天，则建议可能已过时。
+ 如果建议明显错误（例如，忽略图表中可见的大笔订单），请使用竖起大拇指提供反馈，并将具体的异常情况报告给您的支持团队。

### 影响日期或 “行动截止日期” 似乎有误
<a name="common-issues-impact-date-act-by-wrong"></a>
+ 影响日期显示库存问题何时开始（例如，当库存开始缺货或超出阈值时）。
+ “行动截止日期” 应考虑交货时间，这样您就有时间在问题出现之前采取行动。如果 Act By 等于影响日期，则可能无法计入交货时间，请向您的支持团队报告。

### 我在 ERP 中找不到的推荐参考订单
<a name="common-issues-recommendations-reference-missing-orders"></a>

ERP 快照每天都在变化。昨天建议中提及的订单可能已在今天的 ERP 运行中发货、取消或重新安排。

这是已知 ERP-based 的数据限制。可以添加历史消费数据以提供更好的背景信息。

## 常见的精度问题
<a name="common-issues-common-accuracy-issues"></a>

### Forecast 比简单移动平均线差得多
<a name="common-issues-forecast-worse-than-moving-average"></a>

如果您的 ASC 预测在 WAPE 总量上跌至 6 个月的移动平均线，请查看以下常见原因：
+ **范围内的低质量volume/inactive 产品太多了。**对于任何型号来说，需求稀少、间歇性的产品都很难超越简单的平均水平。使用预处理规则将预测范围限定为具有重要需求历史记录（例如，至少 6 个月的非零需求）的产品。
+ **关于陈旧或受污染历史的培训。**如果您的订单历史可以追溯到很多年前，那么旧的需求模式可能无法反映当前的现实。考虑使用预处理规则，将训练历史限制在最近的 3-5 年内，或者用标准化值替换异常时期（例如 COVID）。
+ **一次性订单导致需求激增。**单个大批量订单可能会在训练数据中造成虚假的上升趋势。使用预处理规则将异常的月需求值限制为尾随平均值的倍数（例如，5 倍）。
+ **共识规则的应用方向是错误的。**LLM 代理可能会误解规则语言。“减少 27%” 可以作为增加额适用。始终通过比较特定产品和月份，根据基线验证共识结果。使用显式乘法语言（“乘以 0.725”），而不是定向语言（“减少 27.5%”）。

### Over-forecasting 偏差（系统预测值高于实际值）
<a name="common-issues-over-forecasting-bias"></a>

积极的偏见意味着您在整个目录中订购的商品超过了所需的数量。常见原因：
+ **该模型是在生长期训练的。**如果近年来的增长没有持续下去，则该模型推断出一种已不复存在的趋势。
+ **共识规则正在向上调整。**每种增加预测的多条规则（缺货偏差、趋势提振、季节性上涨）可能会复杂化。查看哪些规则有效，并检查它们是否都适用于相同的产品。
+ **Deleted/discontinued 产品仍在范围内。**仍在预测中的具有追踪需求的产品将显示出系统的过度预测。

### Under-forecasting 偏差（预测值系统地低于实际值）
<a name="common-issues-under-forecasting-bias"></a>

负偏差意味着您预测的需求一直低于实际需求，从而导致潜在的缺货和成本的加快。常见原因：
+ **未纳入外部预测信号。**如果您加载了计划输入（例如，EDI 客户预测、SIOP 生产计划），但您的共识规则未应用这些输入，则预测将默认为统计基线，这可能无法捕捉规划人员看到的需求信号。通过将导出与 Forecast（基准） ConsensusForecast 导出进行比较，验证共识规则实际上是在修改输出。如果它们相同，则规则不会生效。
+ **稀疏的产品×站点组合拉低了聚合量。**如果您按产品×地点的粒度进行预测，但许多组合的需求为零或接近零，则该模型会为非活动组合生成较小的非零预测。这些加起来并不算多，而是共同将总预测拖至实际值以下。使用预处理规则排除需求历史记录不足的组合，或者在计划输入中使用有条件的零填充来明确表示 “预计没有需求” 无效组合。
+ **该模型尚未捕捉到最近的增长趋势。**统计模型对历史数据进行加权。如果您的业务在最近几个月中取得了显著增长，但该模式有多年的销量较低的历史，那么它将落后于趋势。随着模型积累更新的数据，这种情况通常会随着时间的推移而改善。在此期间，考虑一条共识规则，该规则使用近期实际值的追踪平均值作为外部预测周的下限。
+ **Year-over-year 季节性不匹配。**如果今年的需求模式与往年不同（例如，较早的季节性增长、新产品发布），则在分歧时期，该模型可能会被低估。检查偏见不足是否集中在与上一年模式不同的特定周或月份。

### 在较长的时间范围内，Forecast 精度会显著降低
<a name="common-issues-accuracy-degrades-longer-horizons"></a>

随着预测范围的增加，准确性会恶化是正常的——第 1 周总是比第 8 周更准确。但是，如果降解幅度比预期的要大：
+ **外部信号只能在短期内起到作用。**如果您的共识规则包含了最初几周的客户预测 (EDI)，那么短期内准确性会明显提高，当规则停止适用时，准确性就会下降。这是可以预料的——考虑使用混合方法（例如，将外部信号和中期周的基线相 50/50 结合）将规则延长到更长的周数。
+ **在较长的时间范围内，基线将恢复为长期平均值。**从长远来看，统计模型变得不那么自信，倾向于历史平均值。如果最近的需求高于历史平均水平，那么外周将显得偏向不足。这是模型行为，而不是配置问题。
+ **需求波动本质上会使更长的视野变得更加困难。**如果您的需求具有较高的周际变异性（变异系数 > 0.5），那么即使是完美的模型也会在更长的时间范围内显示出很高的误差。将准确性评估集中在前 3-4 周，这是大多数操作的可操作计划窗口。

### 在共识规则中使用外部EDI/customer 预测（预测）时无法提高准确性
<a name="common-issues-external-forecast-not-improving"></a>

如果您添加了共识规则以纳入外部预测，但准确性并未提高：
+ **外部信号可能无法覆盖足够的产品。**EDI 或客户预测通常仅涵盖产品目录的一部分（通常为 30-50%）。没有外部信号的产品仍使用基准。检查您的覆盖率——如果覆盖率低于 50%，则对总体准确性的影响将是有限的。
+ **外部信号可能不够准确，无法提供帮助。**在规则中使用外部预测之前，请独立测量其准确性。如果它的 WAPE 比基线差，那么将其纳入会带来伤害而不是帮助。考虑将该规则限制在外部信号明显更好的特定网站或产品（例如，交易量加权WAPE低于50％）。
+ **外部信号不报告零。**许多 EDI 系统只发送有活跃订单的产品的记录，它们会省略需求为零的产品，而不是明确报告需求为零的产品。如果您的共识规则显示 “当 EDI = 0 时，将预测设置为 0”，则它永远不会触发，因为没有零记录。对于没有外部信号且没有近期销售历史记录的产品×站点组合，您需要在预处理中生成合成零记录。
+ **外部信号精度因地平线而异。**客户预测通常在下周最准确（基本上是已确认的订单），并且会迅速降低。在整个星期内直接使用外部信号的规则可能会损害长远的准确性。考虑分层方法：第 1-3 周直接替换，第 4-6 周混合替换，第 7 周以上仅使用基准。

### 规划规则未生效
<a name="common-issues-planning-rules-not-taking-effect"></a>

如果共识规则似乎没有改变预测：
+ **该规则可能已被优先级较高的规则所取代。**规则按优先顺序应用。后来的规则可以撤消之前的规则。检查规则顺序。
+ **规则条件可能与任何商品都不匹配。**如果该规则引用的产品属性（例如 product\_group\_id）不在商品元数据中，则它将默默匹配任何内容。
+ **规则语言被误解了。**LLM 代理使用自然语言生成代码。措辞模糊可能会产生意想不到的结果。尽可能具体和直截了当。使用精确的字段名称、显式乘数和清除条件。

### 共识计划输出与基准预测相同
<a name="common-issues-consensus-identical-to-baseline"></a>

如果 ConsensusForecast 导出的值与 Forecast（基准）导出的值相同，则共识规则不会执行。常见原因：
+ **联接中的维度不匹配。**共识引擎将计划输入与维度列（产品 ID、站点 ID、日期）的基准相连。如果基准和计划输入之间的列名不同（例如，基准使用 item\_id，而 EDI 使用 product\_id），则联接不会生成任何匹配项，并且所有规则都将使用基线默认值。验证数据流配置中的维度映射是否在两个架构之间正确映射。
+ **日期格式不匹配。**基线可以将日期存储为2026-03-02，而计划输入则将其存储为2026-03-02。T00:00:00.000Z如果联接要求完全匹配，则时区感知日期和时区天真日期将不匹配。在加入之前，请检查日期列是否已转换为相同的格式。
+ **计划输入未加载。**确认您的计划输入文件（EDI、SIOP 等）已成功收录。检查系统中的记录计数 — 如果它们显示计划输入的行数为零，则文件可能无法加载。
+ **共识 forecast\_id 与基线 forecast\_id 相匹配。**如果两个导出共享相同的 forecast\_id，则共识引擎无需处理即可直接生成基准的副本。这表示存在系统级问题，请联系您的支持团队，并提供 forecast\_id 和 demand\_plan\_run\_id。

### 共识规则适用于错误的产品或网站
<a name="common-issues-consensus-wrong-products-sites"></a>

如果仅适用于特定网站或产品类别的规则影响了整个目录：
+ ** site/product 筛选条件可能引用了错误的列。**如果您的规则显示 “适用于 [列表] 中的站点”，但生成的代码检查的列不存在或值不同，则筛选器可能会静默传递所有行。通过抽查一些不应受该规则影响的特定产品进行验证。
+ **规则优先级顺序可能会颠倒。**规则以链的形式应用，后来的规则优先于较早的规则。如果在特定规则（例如，“对这 50 个站点使用 EDI”）之后应用宽泛的规则（例如，“对所有内容使用基准”），则宽泛的规则将撤消特定的规则。确保您的规则描述清楚地说明了优先顺序。

### Forecast 值是分数（例如 2,500.37 个单位）
<a name="common-issues-fractional-forecast-values"></a>

统计模型生成的是连续值，而不是整数。如果您的企业以整件商品、原厂包装或最低订购量进行交易：
+ **添加四舍五入规则作为最终共识步骤。**在所有其他共识规则之后应用一个简单的 “四舍五入到最接近的整数” 规则将清理小数值。低于 0.5 的值将四舍五入为零，这适用于需求量非常低的组合。
+ **考虑四舍五入到可操作数量。**如果您的商品以标准包装尺寸配送（例如，每箱 12 个，托拍为 48 个），则四舍五入到最接近的有效包装尺寸可能会提高预测的可用性和准确性。这需要在您的基础产品中提供包装尺寸数据。与您的支持团队共享您的最小起订量或包装大小数据，以探索此选项。

### 添加预处理规则后，产品覆盖率显著下降
<a name="common-issues-product-coverage-drops"></a>

如果您的数据在产品×站点层面稀少，则筛选训练数据的预处理规则（例如，“仅预测需求量至少为 8 周的产品”）可以显著减少预测中的产品数量：
+ **检查粒度。**一款产品在产品层面可能有 52 周的需求，但对于任何单个产品×场地组合，则只有 3 周的需求。在产品×站点级别应用的最低历史记录阈值将排除大多数组合。可以考虑改为在产品层面应用阈值，或者大幅降低阈值。
+ **在部署之前进行测试。**在激活预处理规则之前，请计算有多少产品×站点组合通过筛选器，以及您当前的总数。如果排除超过 20%，则该规则可能过于激进。从宽松的门槛开始，然后逐渐收紧。