SAP S/4HANA MM模块培训 45 - 可用性检查与缺件检查：静态、动态与收货通知

在 SAP 库存管理中，“系统里有库存”并不等于“这批库存可以承诺给当前需求”。仓库人员关心的是此刻某个库存类型里有没有足够数量；计划人员还要关心未来收货、预留、生产领料和其他计划发货会不会先占用库存；当采购收货到达时，企业又希望立刻识别哪些紧急需求仍处于短缺状态。SAP 用静态库存类型检查、动态可用性检查和缺件检查分别回答这三个问题。

本课视频列出了五项议程，但实际只完成了静态检查理论和一次 MIGO 草稿检查。讲师在系统中查询到物料 125000051 有 100.000 L 非限制使用库存，随后录入 201 成本中心发料 50 L，点击 Check 得到 Document is O.K.。视频没有点击 Post，没有生成物料凭证或会计凭证，也没有完成最后口述的 200 L 测试。动态检查、预留检查设置和缺件检查均没有进入系统演示。

因此，本文先逐帧还原视频真实完成的部分，再用 SAP 官方教程和 SAP Help 补齐中断内容。凡是视频没有讲完的部分，都放在标题以“SAP 官方教程补充”开头的章节中，避免把标准功能误写成视频系统里的既成配置。

视频实录：课程议程与真实完成边界

视频开头给出的议程包括：预留的可用性检查设置、静态可用性检查、动态可用性检查、缺件检查的用途，以及缺件检查的系统设置。从教学设计看，这五项内容本应形成一条完整链路：先说明业务需求，再区分两种检查方式，随后配置预留和货物移动，最后用收货触发缺件通知。

但视频在约 10:22 结束，实际完成度并不等于议程完成度。可以把本课证据分成三层：

1. 视频已讲：预留为什么需要在需求日期检查、静态和动态检查的概念差异、静态库存类型检查的四条规则。
2. 视频已操作：MMBE 查询 100.000 L，MIGO 录入 201 发料 50 L，执行 Check。
3. 视频未完成：动态检查配置与结果、预留检查配置、缺件检查用途和设置、200 L 不足测试、正式过账。

这个边界非常重要。Check 只是校验当前草稿是否满足系统规则，不等于物料移动已经发生。只有成功 Post 后，系统才会生成物料凭证；涉及价值更新时还可能生成会计凭证。视频既没有出现凭证号，也没有返回 MMBE 验证库存，所以本文不会使用“已经发料”“库存从 100 降到 50”之类表述，只说“草稿检查通过”。

同样，讲师最后说“假设我要发出 200”，画面却只在数量字段出现了第一个数字 2，随即切入宣传页。系统没有形成 200，没有再次执行 Check，自然也没有产生可供引用的错误消息。后文关于库存不足时系统如何处理，只能依据 SAP 官方规则解释，不能伪装成视频结果。

视频实录：预留为什么需要按需求日期回答

预留不是只记录“需要多少物料”，还记录物料、数量、工厂、库存地点、移动类型以及需求日期。需求日期决定系统应该在哪一天判断供需，而不是只读取今天的库存快照。

例如，今天仓库有 100 件物料，计划人员为三天后创建 80 件预留。只看今天，100 件似乎足够；但如果明天还有一张 50 件预留先到期，那么三天后的需求就不能被完整覆盖。反过来，如果两天后有一张 100 件采购订单收货，三天后的需求又可能可以满足。由此可见，预留检查至少要回答两个不同层次的问题：

• 当前指定库存类型里有没有数量，这是静态检查擅长的范围；
• 到需求日期为止，把计划收货和计划发货按规则纳入后还能不能满足，这是动态检查的范围。

视频在 01:13–02:28 解释了这层业务动机，但没有进入预留事务、没有创建预留，也没有展示检查组或检查范围设置。因此我们只能确认“为什么要检查”，不能确认视频系统“如何配置了检查”。

实际项目中还要避免把预留与库存锁定混为一谈。预留表达的是未来物料需求并可参与可用性计算，但它不等于仓库中某个实物批次已经被物理隔离。系统如何处理其他需求、是否允许警告后继续、是否在库存地点或工厂层级检查，取决于检查组、检查规则、检查范围和业务应用。理解这一点，才能解释为什么 MMBE 看见库存时，预留仍可能得到不足提示。

视频实录：静态检查与动态检查回答不同问题

视频在 02:29–04:03 将可用性检查分为静态和动态两类。最简洁的理解是：静态检查回答“现在有没有”，动态检查回答“按需求日期扣除已知供需后还能不能承诺”。

静态库存类型检查直接面向物料移动。系统根据移动类型判断要减少哪一种库存，并检查该工厂、库存地点或特殊库存层级下是否存在足够数量。它只关心录入时已有的相关库存，不读取未来采购订单、生产订单收货或预留发货来构造日期供需曲线。

动态可用性检查则从 MRP 供需角度工作。当前库存只是起点，计划收货会在相应日期增加可用量，计划发货会在相应日期减少可用量。检查结果还受检查组、检查规则、检查范围、补货提前期和消息控制影响。两个系统都显示“100”，并不能推出未来某一天一定有 100 可用。

两种检查并非谁替代谁。静态检查保护账面库存类型不被不合法地减成负数；动态检查保护计划承诺，避免同一数量被多个未来需求重复占用。一次货物发出可能先从计划角度得到动态提示，随后又在正式物料移动时接受静态库存类型检查。项目人员必须明确当前看到的消息来自哪一种检查，否则很容易把配置问题误判成库存数据问题。

还要注意“静态”并不是指规则永远不变，而是指它在检查时只使用当前库存状态；“动态”也不是指后台实时刷新一个单独的库存字段，而是按日期和配置组合供需元素。动态可用量通常是计算结果，不应当被理解为 MMBE 上另一列固定库存。

视频实录：静态库存类型检查的四条规则

视频从 04:04 开始详细讲静态检查。结合 SAP Learning 的官方说明，可以把规则整理为四条。

第一，静态库存类型检查由物料移动自动触发，不需要用户另行打开一个“静态检查”开关。无论是货物发出、转移过账还是其他会减少某种库存的移动，系统都会检查相应库存类型能否被减少。

第二，检查只看录入时已经存在的相关库存。它不会因为下周有采购订单收货，就允许今天把当前库存类型发成负数。计划收货属于动态供需逻辑，不属于静态库存类型检查的输入。

第三，移动类型决定消耗哪个库存类型以及在哪个层级检查。不能只说“总库存足够”。例如，从质量检验库存转到非限制使用库存时，系统检查的是质量检验库存；做成本中心发料时，系统检查发料库存地点的可用库存；若业务涉及项目库存、销售订单库存或寄售等特殊库存，还要看对应特殊库存层级。总量相同但库存类型不同，结果可能完全不同。

第四，相关库存不足时，系统给出错误，阻止该物料移动把库存类型变成不允许的负数。这里的“不足”必须按移动类型、工厂、库存地点和特殊库存口径理解。MMBE 的汇总数字只能作为线索，不能代替对行项目库存层级的核对。

SAP Learning 使用移动类型 321 举例：如果要把 20 件质量检验库存转为非限制使用库存，系统检查指定工厂和库存地点是否确有 20 件质量检验库存。即使该物料另有 100 件非限制使用库存，也不能用来替代质量检验库存完成这笔 321。这说明静态检查不是一个简单的“物料总库存大于发料数量”公式，而是一项与移动类型语义紧密关联的库存保护。

视频中的 201 则是成本中心发料。它要求输入成本中心，并从指定工厂、库存地点的相关库存中发出物料。视频数据为工厂 0001、库存地点 1000、非限制使用库存 100.000 L、发料数量 50 L。在这些录入条件下，草稿通过 Check 与静态规则一致，但仍不能推导出“过账完成”。

视频实录：100 件库存为什么会有两个答案

视频展示了一个关键示例：当前有 100 件非限制使用库存，未来已经有两笔预留发货，数量分别为 30 和 20，今天又计划发出 60。静态库存类型检查只比较当前库存与当前发出数量，因此 100 ≥ 60，静态检查可以通过。动态可用性检查会先把未来计划发货合计 50 从可承诺数量中扣除，于是动态可用量为 50；当天再承诺 60 就会形成 50 < 60 的不足。

这张图依据 SAP Learning 官方图重新用中文制作。它不是视频中的系统结果，也不表示所有系统一定以错误阻断。动态检查究竟给出错误、警告、信息还是其他确认结果，取决于业务事务、检查组、检查规则、检查范围和消息控制。文章只能把 50 作为官方示例的供需计算结果，不能把它写成视频系统已经运行出的 ATP 值。

这个示例还揭示了一个常见误区：未来预留没有让当前实物库存从 100 变成 50，所以 MMBE 仍可能显示 100；但从计划承诺角度，已有 50 被未来需求占用，因此新的需求不能再把同一数量重复承诺。静态库存和动态可用量使用不同口径，数字不同并不矛盾。

若未来还有计划收货，动态结果还会随日期改变。例如，采购订单收货在需求日期之前到达且被检查范围纳入，可用量可能增加；如果收货日期晚于需求日期，则不能帮助当前需求。正因为存在日期顺序，动态检查不能被简化为“当前库存 + 所有采购订单 − 所有预留”。

视频实录：MMBE 到 MIGO 的证据链

视频从 06:53 左右进入 SAP GUI，完成了一条可核验的草稿检查链路：先在库存总览中确认数量，再在 MIGO 创建货物发出草稿，最后执行 Check。下面按画面顺序还原，不补写任何视频没有发生的操作。

1. 在 MMBE 输入物料和工厂

讲师在 MMBE 查询物料 125000051，工厂为 0001。视频前面的物料信息还显示描述 PI - 1、物料类型 ROH、基本计量单位 L。MMBE 是库存总览工具，适合确认物料在各组织层级和库存类型下的账面数量。

查询条件本身并不能证明某个移动一定可执行。还必须进入结果树，确认库存地点、库存类型和特殊库存口径。若只读取工厂总计，可能忽略数量分散在不同库存地点，或者存在于质量检验、冻结库存等不能被当前移动直接消耗的库存类型中。

2. 确认库存地点 1000 的 100.000 L

MMBE 结果显示工厂 0001 下的库存地点 1000，描述为 RM location，非限制使用库存为 100.000 L。这一步为后面的 50 L 草稿提供了当前库存证据。

应当注意，MMBE 是查询画面，不是可用性检查结果。它告诉我们当前账面库存分布，但没有在这一步计算未来预留、计划收货或其他供需元素。如果业务问题是“今天能否从库存地点 1000 发出 50 L”，MMBE 很有帮助；如果问题是“下周需求日期能否承诺 50 L”，还需要动态检查。

3. 在 MIGO 选择货物发出与移动类型 201

讲师在 MIGO 选择：

• 操作：A07 Goods Issue
• 参考：R10 Other
• 移动类型：201 / GI for cost center

移动类型 201 表示向成本中心发料，因此后续必须提供成本中心。移动类型不仅影响会计和数量更新，也决定静态库存类型检查要查看哪类库存。此处选择正确的移动类型，是理解后续 Document is O.K. 的前提。

4. 录入物料与数量 50 L

行项目录入物料 125000051，数量 50 L。这时仍然只是待检查的凭证草稿。SAP GUI 中显示的行项目不等于已经产生物料凭证；只有完成必填字段、通过相关检查并执行 Post，才会真正更新库存。

视频里当前库存为 100.000 L，草稿数量为 50 L，所以从静态数量比较看具备通过条件。但系统还会校验库存地点、科目分配、期间、主数据状态等其他业务规则。不能把 100 ≥ 50 当作 MIGO 所有检查的完整替代。

5. 完成库存地点和成本中心

讲师输入库存地点 1000 / RM location，成本中心 SAP-DUMMY。到这里，画面形成一组完整的关键值：物料 125000051、工厂 0001、库存地点 1000、移动类型 201、数量 50 L、成本中心 SAP-DUMMY。

这些值应当作为复现实验时的核对清单，而不是可以直接复制到任何企业系统的模板。SAP-DUMMY 是视频系统里的成本中心；其他系统的成本中心主数据、有效期、控制范围和权限可能不同。读者在练习系统中应使用有效的本地测试主数据。

6. 点击 Check 得到 Document is O.K.

讲师点击 Check 后，状态栏显示 Document is O.K.。这证明在当时画面条件下，MIGO 草稿通过了系统校验。它至少与“库存 100 L、拟发出 50 L”的静态检查逻辑相符。

但 Document is O.K. 不是物料凭证号。视频没有点击 Post，也没有出现“Material document ... posted”之类成功信息，没有展示物料凭证、会计凭证或后续库存。因此，严谨的实验结论只能写成：201 发料 50 L 的草稿检查通过，过账结果未知。

如果要在测试系统完成闭环，应在获得业务授权后执行 Post，记录物料凭证号，再用 MMBE 或物料凭证应用核对库存变化和凭证行项目。本文不替视频补做这些动作，也不假设过账一定成功，因为正式过账还可能遇到权限、期间、账户确定、成本中心有效性等检查。

视频实录：末尾 200 L 测试没有形成结果

视频最后一句字幕是“假设我要发出 200”。这句话容易让人误以为后面已经演示了库存不足。但逐帧检查显示，SAP 数量字段只出现首位数字 2，随即切入宣传页。没有证据表明字段曾形成 200，也没有第二次点击 Check。

因此，视频能够证明的只有：

• MMBE 查询到 100.000 L；
• MIGO 草稿曾录入 50 L；
• Check 显示 Document is O.K.；
• 没有执行 Post。

视频不能证明的包括：

• 200 L 已完整录入；
• 系统对 200 L 给出静态库存不足错误；
• 动态可用性检查已经运行；
• 库存被减少；
• 缺件检查已经触发。

依据 SAP 官方规则，如果相关库存类型和层级只有 100 L，而用户确实尝试发出 200 L，静态库存类型检查应阻止不允许的负库存。但这是标准规则推论，不是本视频的实际画面结果。测试文档必须把“预期结果”和“实际结果”分栏记录，不能用讲师口述替代系统证据。

SAP 官方教程补充：动态可用性检查如何按日期计算

动态可用性检查的核心不是读取一个固定字段，而是构建按日期排列的供需序列。可以把计算理解为：从某个初始可用量开始，按时间先后加入被检查范围纳入的收货元素，再扣除被纳入的发货元素；在每个需求日期判断累计可用量是否覆盖需求。

SAP Learning 的官方时间轴示例从今天 100 PC 库存开始：第 2 天有 80 PC 预留发货，第 4 天有 50 PC 采购订单收货。若新增一笔 30 PC 预留，不同需求日期会得到不同结果。

• 第 1 天：现有 100 尚未被第 2 天的 80 消耗，从日期序列看有数量；具体是否允许及如何确认仍受规则控制。
• 第 3 天：第 2 天发货已经把可用量降为 20，所以新增 30 不足。
• 第 5 天：第 4 天采购收货 50 已进入供需序列，可用量恢复，新增 30 可能可用。
• 检查地平线或补货提前期之后：结果取决于系统是否使用完整确认、是否忽略检查地平线等配置。

这个例子说明，同一物料、同一数量，只改变需求日期就可能得到不同结果。项目排查时必须同时记录物料、工厂、库存地点、检查组、检查规则、需求日期和供需元素；只发一张 MMBE 截图通常不足以解释 ATP 结果。

动态检查纳入哪些元素并非固定。检查范围可以决定是否考虑特定库存、采购申请、采购订单、计划订单、生产订单、预留、销售需求等。企业配置不同，供需曲线就不同。即使两个系统的当前库存相同，只要检查范围不同，结果也可能不同。

还应区分“可用性检查”和“确认”。检查负责判断数量与日期；某些业务应用还会根据结果形成确认数量、替代日期或消息。库存管理、销售、生产和当前 aATP 应用可能使用不同规则，不能把某一应用的确认逻辑直接套到另一应用。

排查动态结果时，建议按以下顺序：先确认需求日期是否正确，再确认检查组与检查规则组合，然后查看检查范围纳入的收货和发货，最后核对补货提前期、消息类型与应用专属行为。这个顺序比反复修改库存更容易找到根因。

SAP 官方教程补充：动态检查生效的四个配置前提

SAP Learning 将动态检查的生效条件拆成四个相互依赖的配置点。任何一个缺失，都可能让用户看不到预期提示。

第一，事务分配。系统需要知道在哪一种业务事务中执行哪条检查规则。货物发出、货物收货和预留的业务入口不同，不能只配置一处就假设所有事务都生效。缺件检查中的 MIGO 收货还涉及后台事务 MIGO_GR。

第二，物料检查组。检查组维护在物料主数据的 MRP 数据中，用来表达该物料采用哪一种可用性检查策略。若物料没有合适的检查组，即使事务侧配置存在，也可能无法按预期组合出动态检查。

第三，检查范围。检查范围由检查组与检查规则组合决定，定义哪些库存、计划收货和计划发货被计入。它是动态结果差异最常见的来源。某系统考虑采购订单而另一系统不考虑，两个系统对相同需求日期自然会给出不同答案。

第四，消息控制。系统要根据移动类型或相关业务规则决定不可用时是错误、警告还是信息。错误通常阻止继续；警告允许用户确认后继续；信息只提示。用户说“系统没有拦截”时，可能不是检查未执行，而是消息严重性被配置为警告。

四…3410 tokens truncated…； 8. 缺件场景的收件人消息。

这种证据结构能把“系统应该这样”与“系统实际这样”分开。视频只覆盖了其中的 MMBE、MIGO 50 L 草稿和 Check 三项，所以本文把其他测试都明确列为官方补充方案。

SAP 官方教程补充：用供需台账手工复核动态结果

当动态检查结果与业务直觉不一致时，最有效的办法不是先改配置，而是把系统正在考虑的供需元素整理成一张按日期排序的台账，手工计算累计可用量。台账至少包含日期、元素类型、单据号、收货数量、发货数量、累计可用量、是否被检查范围纳入七列。

假设今天初始库存为 100，第二天预留发货 80，第四天采购订单收货 50，第五天新增预留 30。如果三个元素都被当前检查范围纳入，累计过程为：今天 100；第二天扣 80 后为 20；第四天加 50 后为 70；第五天扣 30 后为 40。因此，第五天新增 30 在这个简化示例中可以覆盖。若把需求日期改到第三天，采购收货尚未到达，第二天后只有 20，新增 30 就形成 10 的不足。

现在只改变一个配置：检查范围不纳入采购订单。到第五天累计量仍为 20，新增 30 依旧不足。这说明用户所说的“采购订单明明存在”并不足以证明系统应该把它算进来。必须确认该收货元素的类型、日期、开放数量和检查范围标识。

再改变一个事实：第四天采购订单数量是 50，但已有 20 完成收货，开放数量只剩 30。动态检查通常关注仍有效的供需数量，不能始终使用订单原始数量。手工台账应记录系统当时的开放数量和状态，不应从旧截图复制总量。

对发货元素也要做同样核对。预留若已删除、最终发料或不在相关组织层级，是否继续形成需求取决于其状态和应用逻辑。销售需求、生产订单组件、库存调拨等元素也有各自状态。排查人员应从系统供需清单获取有效元素，而不是把所有历史单据都相加。

如果手工台账与系统结果一致，问题通常是业务对检查范围或日期规则的理解不同；如果不一致，再继续核对检查组、检查规则、组织层级、补货提前期和应用版本。这样可以把“数据问题”和“配置问题”分开，避免通过临时增加库存掩盖真正原因。

SAP 官方教程补充：组织层级、库存类型与特殊库存

静态和动态检查都离不开组织层级。工厂是计划和库存管理的重要层级，库存地点描述工厂内库存的物理或逻辑分区，特殊库存还可能属于供应商、客户、销售订单或项目。数量相同但归属层级不同，不一定能满足当前业务。

视频中的证据十分明确：物料 125000051、工厂 0001、库存地点 1000、非限制使用库存 100.000 L。随后 MIGO 行项目也使用库存地点 1000。正是因为查询口径和发料口径一致，50 L 草稿通过静态数量检查具有清晰解释。如果 MMBE 的 100 L 位于另一个库存地点，而 MIGO 从 1000 发料，工厂总计足够也不能证明库存地点 1000 足够。

库存类型同样不能混用。非限制使用库存通常可直接用于常规发料；质量检验库存和冻结库存受不同业务控制。移动类型决定要减少哪一种库存，因此排查静态错误时，应在 MMBE 展开到与移动类型相对应的库存类型。SAP Learning 的 321 示例正是检查质量检验库存，而不是物料全部库存。

特殊库存需要额外的归属对象。项目库存、销售订单库存、寄售库存等即使属于同一物料和工厂，也不等于企业自有非限制使用库存。若移动类型或行项目要求某种特殊库存，系统会在相应归属层级检查。测试报告要记录特殊库存标识和对象编号，不能只写物料与数量。

当前预留应用还可能在库存地点层级和工厂层级执行不同检查。若库存地点层级通过后又执行工厂层级检查，用户可能看到一个层级“看起来足够”而最终仍收到提示。排查时应确认检查发生在哪个层级，以及检查范围是否在两个层级都一致。

建议把组织口径写进每个测试用例的标题，例如“工厂 0001 / 库存地点 1000 / 非限制使用 / 201 发料”。这种命名比“物料 125000051 可用性测试”更精确，能直接暴露使用了错误库存地点或库存类型的情况。

SAP 官方教程补充：消息严重性与用户操作决策

可用性检查发现不足后，系统如何与用户交互，取决于消息控制。最常见的严重性可以理解为错误、警告和信息，但项目中必须以本系统的实际配置和消息文本为准。

错误意味着当前操作不能按原样继续。用户需要修改数量、日期、库存地点、移动类型或其他业务条件，或者先完成合法的补货与库存处理。错误不应通过反复点击或忽略消息绕过；若业务确需允许负库存，应走正式配置和审批，而不是把错误改成不受控的信息。

警告表示系统识别了风险，但允许具备权限和责任的用户确认后继续。警告不是“系统没检查”，恰恰说明检查发生了，只是控制策略允许业务承担后果。项目必须明确哪些角色可以继续、继续后是否记录原因、是否需要后续计划人员处理。

信息只提供提示，通常不会阻止操作。若用户反馈“缺件检查没有拦截”，先确认业务设计是否本来就只要求通知。缺件场景的目标常常是让仓库和 MRP 控制员获知紧急需求，而不是一律禁止收货；因此前台提示、后台消息和业务处置要一起设计。

同一不足在不同事务中可能有不同消息行为。预留创建关注未来承诺，货物发出关注当前物料移动，收货缺件检查关注到货后的紧急分配。把所有事务都配置为同一严重性，可能不符合业务目标。配置矩阵应按事务、移动类型、检查规则和组织范围记录预期消息。

测试记录不能只写“有弹窗”或“没有弹窗”。应保存消息编号、完整文本、严重性、出现时点、用户可否继续以及继续后的结果。MIGO 中还要写明消息是在录入时自动出现，还是点击 Check 后出现。SAP Learning 对缺件检查的说明强调了 Check 动作，这个时点差异会直接影响用户培训。

最后，消息设计必须与职责匹配。仓库人员需要知道当前凭证该如何处理，MRP 控制员需要知道哪些需求受影响，配置团队需要能从消息编号追溯规则。只有消息、收件人和处置流程三者闭环，检查功能才真正产生业务价值。

SAP 官方教程补充：常见问题与排查顺序

MMBE 有库存，为什么动态检查仍然不足？

先确认 MMBE 中的数量是否位于当前需求的工厂、库存地点和库存类型。然后查看需求日期之前是否已有预留、销售需求或生产发货占用，以及检查范围是否纳入这些发货元素。MMBE 显示实际库存，动态检查计算可承诺数量，两者不要求相等。

明明有采购订单，为什么系统仍提示不足？

检查采购订单的计划收货日期是否早于需求日期、收货元素是否被当前检查范围纳入、数量是否仍开放，以及检查是否在正确组织层级执行。晚于需求日期的采购收货不能满足更早需求；未被检查范围纳入的收货也不会增加动态可用量。

有检查组，为什么 MIGO 没有动态提示？

检查组只是前提之一。还要核对事务是否分配检查、检查组与检查规则的检查范围是否维护、移动类型消息控制是什么、当前业务是货物发出还是收货。若是缺件收货，还要核对 MIGO_GR 和是否点击 Check。

MIGO 点击 Check 没有缺件警告，怎么办？

按顺序核对：工厂是否启用缺件检查；物料是否有检查组；检查规则是否分配给 MIGO_GR；移动类型是否覆盖事务规则；检查地平线是否包含短缺需求日期；检查范围是否纳入该需求；消息类型是否被设置为可见提示。不要先假设“系统 bug”。

仓库看到警告，MRP 控制员却没有消息

检查物料主数据中的 MRP 控制员、MRP 控制员对应的邮件用户、工厂中央缺件催办员，以及消息是汇总还是非汇总。系统识别短缺与消息成功送达是两个环节，任何一个主数据映射缺失都可能让通知链中断。

同一用例在两个系统结果不同

对比物料检查组、检查规则、检查范围、消息类型、补货提前期、检查地平线、库存地点/工厂层级、供需元素日期和产品版本。不要只比较当前库存。若一个系统使用经典逻辑，另一个系统的 Fiori 预留应用启用了 aATP，应用模型差异也必须纳入分析。

Check 通过是否意味着可以安全过账？

Check 说明当前草稿通过当时可执行的校验，但正式 Post 仍可能触发权限、锁、期间、账户确定、主数据有效期或并发库存变化等问题。只有成功过账并得到凭证号，才能说物料移动完成。视频只到 Check，所以不能给出过账结论。

SAP 官方教程补充：配置变更、传输与回归验证

可用性检查配置会同时影响仓库执行和计划承诺，不能在生产系统里为了通过单个用例直接改消息或检查范围。任何变更都应先说明业务问题、影响事务、目标组织范围和预期结果，再进入开发或配置系统验证。

变更检查范围时，必须列出新增或移除的供需元素。例如，将采购订单纳入后，需求日期之前的开放采购数量可能提高可用量；将预留发货纳入后，未来需求会提前占用可承诺数量。配置说明不能只写“优化 ATP”，而要写清楚哪些元素从什么日期开始参与计算。

变更消息类型时，要评估用户是否从“被阻止”变成“可确认后继续”。这不仅是界面变化，也改变业务风险承担方式。如果错误改为警告，必须定义谁可以继续、是否需要记录原因、后续由谁处理短缺。若警告改为错误，则要确认仓库和生产是否存在必须紧急发料的例外流程。

配置通常需要通过传输请求进入后续系统。传输记录应包含对象、源客户端、目标系统、依赖主数据和测试用例。检查组定义被传输后，物料主数据中的检查组并不会自动为所有物料补齐；MRP 控制员的用户分配也可能是目标系统独立数据。配置传输成功不等于端到端功能已经可用。

回归测试至少覆盖受影响的货物发出、转移过账、货物收货和预留。若启用了缺件检查，还要验证 MIGO_GR、检查地平线、前台 Check 警告和后台收件人消息。若当前预留应用使用 aATP，还要单独验证 F4839、F5601 与经典 GUI 流程的结果差异。

建议把回归结果整理成四列：原配置结果、目标配置结果、实际测试结果、业务批准。数量和日期必须固定，不能在测试过程中临时更换物料后仍沿用原预期。失败用例要保留完整消息编号与供需台账，便于判断是配置未传输、主数据缺失，还是业务预期本身不成立。

上线后还应观察缺件消息量和警告继续率。消息过多可能表示地平线、检查范围或收件人设计过宽；警告几乎总被继续可能表示严重性与业务风险不匹配；关键短缺没有消息则要回到事务分配、检查组和日期范围逐项核对。监控数据只能用于验证规则效果，不能替代正式变更审批。

SAP 官方教程补充：按业务问题选择正确检查

实际支持中，用户经常只说“可用性不对”。为了快速定位，应先把问题改写成一个可以验证的业务问题，再决定看哪类数据。

如果问题是“为什么这笔货物发出不能过账”，首先看静态库存类型检查：移动类型消耗什么库存、行项目使用哪个工厂和库存地点、是否涉及特殊库存、相关库存类型是否足够。此时未来采购订单通常不能解决今天的静态库存不足，除非先合法完成收货或库存转移。

如果问题是“为什么未来预留没有完整确认”，首先看动态可用性检查：需求日期、检查组、检查规则、检查范围以及需求日前的收货和发货。MMBE 可以提供初始库存，但不能单独解释未来确认。排查结果应输出按日期排序的供需台账。

如果问题是“采购收货后为什么没人知道生产仍缺料”，首先看缺件检查：工厂是否启用、规则是否分配给 MIGO_GR、需求是否在检查地平线内、MIGO 是否执行 Check、MRP 控制员或中央缺件催办员是否有有效用户。这里的目标是识别和通知，不是重新判断采购订单能否收货。

如果问题是“Check 已经通过，为什么 Post 仍失败”，则不要继续讨论可用量，而要查看正式过账阶段新增的消息。可能原因包括期间关闭、账户确定、成本中心无效、权限不足、对象被锁或并发业务改变库存。必须使用实际消息编号继续排查，不能把 Document is O.K. 当作所有后续检查的保证。

如果问题是“经典事务和 Fiori 应用结果不一致”，先确认两边是否使用相同产品逻辑。当前预留应用可能使用 aATP，而经典库存管理流程使用相应的检查组、规则和范围。比较前要统一物料、组织层级、需求日期、供需元素和检查配置；否则只是比较两个不同上下文的结果。

可以用下面的判断顺序收口：

1. 是否已经发生物料移动？没有凭证号时先按草稿或检查结果处理。
2. 问题发生在当前库存、未来承诺还是收货通知？三者分别对应静态、动态和缺件检查。
3. 数量属于哪个工厂、库存地点、库存类型或特殊库存？
4. 是否涉及需求日期和计划供需？若涉及，就不能只看 MMBE。
5. 当前消息是错误、警告还是信息？用户是否可以继续？
6. 是否存在版本或应用差异，例如经典 GUI 与 aATP 预留应用？

这套问题可以防止团队一开始就进入 SPRO 盲目寻找开关。先确定业务问题，再核对数据和规则，最后才决定是否需要配置变更，能够减少误改和重复测试。

SAP 官方教程补充：实施时的职责与控制点

可用性与缺件检查跨越仓库、计划、主数据和配置团队，最好在上线前明确职责。

仓库团队负责定义哪些货物移动必须被阻断、哪些场景允许警告继续，以及缺件收货时现场如何处理到货。MRP 团队负责定义哪些供需元素应纳入、检查地平线多长、谁接收缺件消息。主数据团队负责检查组、MRP 控制员和物料组织层级数据。配置团队负责事务分配、检查范围、消息类型和传输。测试团队负责用日期化供需场景验证，不只测试“库存足够”一种情况。

还应建立三条控制线：

1. 数量控制：静态库存类型检查不得让不允许的库存层级变成负数。
2. 承诺控制：动态检查避免未来供需被重复承诺，并按业务规则给出确认或消息。
3. 响应控制：缺件检查在收货时把紧急短缺交给仓库和计划人员处理。

如果只配置第一条，账面库存可能安全，但计划承诺仍会冲突；如果只关注第二条，收货后的紧急短缺可能无人处理；如果只发送缺件消息而主数据收件人失效，系统有结果却没有业务闭环。

上线验收不应以“事务能打开”为完成标准，而应以可复现业务结果为标准。每条规则至少有一个通过用例和一个不通过用例，并记录完整消息。对警告类场景，还要明确用户是否可以继续、继续后谁负责、是否需要日志审计。

SAP 官方教程补充：本课复盘——把库存、承诺和通知分开

本课最值得记住的不是某个事务码，而是三个问题不能混在一起：

• 静态库存类型检查：当前指定库存类型和层级有没有足够数量完成物料移动？
• 动态可用性检查：按需求日期把计划收货和计划发货纳入后，还能不能承诺这笔需求？
• 缺件检查：收货发生时，哪些紧急需求仍未被库存覆盖，需要通知仓库和计划人员？

视频真实完成的是第一层的一次草稿验证：物料 125000051 在工厂 0001、库存地点 1000 有 100.000 L，MIGO 以移动类型 201 录入 50 L 和成本中心 SAP-DUMMY，点击 Check 得到 Document is O.K.。它没有过账，也没有完成 200 L、动态检查或缺件检查。

官方补充部分说明了后两层如何建立：动态检查需要事务分配、物料检查组、检查范围和消息控制；缺件检查建立在动态检查之上，通过 OMBC、MIGO_GR、检查地平线和收件人配置，把收货时的短缺信息交给仓库人员与 MRP 控制员。当前 Fiori 预留应用还要结合 aATP 和检查规则 03 理解，不能与经典 GUI 演示混写。

只要在项目中始终标明“当前库存”“动态可用量”“检查消息”和“正式凭证”分别来自哪里，就能避免大多数误判。看到 MMBE 的 100，不要直接承诺未来 100；看到 Document is O.K.，不要直接声称已经过账；看到缺件配置，也要继续验证收件人和现场处置是否闭环。

SAP 官方教程补充：参考资料与适用边界

本文的动态可用性检查、经典配置入口、补货提前期、缺件检查、MIGO 消息和当前预留应用说明，依据以下 SAP 官方资料核对：

1. SAP Learning：Checking Availability and Missing Parts
2. SAP Learning：Checking Availability
3. SAP Help：Availability Check（Inventory Management）
4. SAP Learning：Adjusting the Output of Messages in Inventory Management
5. SAP Help：Manage Reservation Items（F5601）
6. SAP Help：Manage Manual Reservations（F4839）

官方页面中的三张相关非软件图已保存为来源证据，并分别重制为中文 1920×1080 信息图；官方英文原图不直接放入正文。官方页面没有与本课直接相关、可原样使用的 SAP GUI/Fiori 软件截图，因此正文中的软件界面全部来自视频 1920×1080 完整原帧。

不同 S/4HANA 版本、部署模式和企业配置可能改变菜单、应用、检查范围及消息行为。读者应以本系统版本的 SAP Help、IMG 文档和已批准配置为准。本文说明标准逻辑和视频证据，不代表任何生产系统已经启用相同检查组、aATP、缺件消息或负库存策略。

视频来源：https://www.youtube.com/watch?v=tF_7w5s-dPA