简介：《SAP可用性检查应用测试.docx》是一份面向SAP顾问、供应链计划及MM/SD/PP模块学习者的专题文档，聚焦静态可用性检查与动态可用性检查的区别、配置思路与测试验证，帮助读者理解库存承诺、预留与采购计划对可用性的影响。压缩包仅含1个docx文档，大小约536KB，结构紧凑，便于按主题查阅。文档围绕IM层静态检查与MRP层动态检查展开，覆盖移动类型、检查规则、可用性检查组等配置要点，并通过库存、预留、采购订单及需求日期等测试场景说明补货提前期的作用，适合用于功能理解、方案验证与问题排查。文档还梳理检查组关键参数、静态与动态检查的结果差异及报错触发条件，便于对照验证与复盘。已有3063人学习下载，可为SAP供应链可用性检查的入门梳理和实操验证提供参考。
1. 可用性检查：为什么库存明明够，系统却提示不够
有一类场景，在 SAP 里做运维或咨询的人基本都遇到过：物料在仓库里明明有 100 PC，可用性检查却卡在某个未来的需求日期上，提示“库存不足”。第一反应往往是“系统算错了”，但把时间轴摊开来看，系统算的往往是对的——它算的不是“现在有多少”，而是“需求那一天还能剩多少”。
这就是 SAP 可用性检查真正要解决的问题：把一次订单动作，从“占不占得到库存”变成“在某个未来时点上，供给减去需求是否还为正”。静态检查只做即时余额校验，动态检查则把采购订单、采购申请、预留、生产订单、计划订单这些预计划的收发货全部拉进来，按日期排布后逐日累加。
这份文档最有价值的地方，不是罗列功能，而是用一组可以复现的日期与数量，把“补货提前期”“检查规则”“需求日期”三个参数之间的耦合关系摊开给人看。搞懂这套逻辑，配置错误导致的销售订单超卖、生产缺料、预留建了却用不上这些玄学问题，才有排查的落脚点。
2. 静态与动态：两条检查路径到底差在哪一层
2.1 静态检查本质是一次库存余额的即时比对
静态可用性检查发生在 IM（库存管理）层面，文档里给的例子很直白：某工厂的库存地点有 100 PC，用 MIGO 做 201 移动类型向成本中心发料 105 PC，系统直接提示还差 5 个库存。
这条路径的机制非常朴素——它只读当前库存数量，不做任何时间维度的推演，也不关心未来有没有补货、有没有别的需求压在后面。发料这一刻库存是多少，就按多少判断，判断完就结束。
正因为如此，静态检查不需要任何后台配置。系统不需要知道检查规则、不需要知道可用性检查组、不需要知道需求日期，它连“需求日期”这个概念都没有真正参与计算。这也是为什么很多刚接触 SAP 的人以为可用性检查是个很轻的功能——他们最先接触到的就是这一层，简单到几乎不会出问题。
但一旦业务从“我现在要发货”变成“我承诺客户某天交货”，静态检查立刻失效。因为发货是即时动作，而承诺交货是未来动作，未来那一刻的库存还没形成，系统必须去推算。这就必须切到 MRP 层面。
2.2 动态检查把库存拆成了供给项和需求项
动态可用性检查的机制核心是把物料在某个时间点的“可用量”拆成一组带正负号的项，再按日期累加。文档里对这些项做了分类，这个分类本身就值得拆开看。
库存侧要区分的是“能不能用”：非限制使用库存是可直接动用的；质检库存、冻结库存属于账上有但不可自由支配；安全库存是一条不得随意突破的保底线；在途库存、外包库存属于已经在路上但尚未入库的部分。这几种库存参与不参与检查、以什么符号参与，取决于检查规则的设置。
预计划侧拆得更细，收货类包括采购订单、采购申请、计划订单、生产订单、库存传输订单；发货类包括相关需求、手工预留、独立需求、SD 提货单、货运通知单、基于订单的自动预留。文档特别点出了第四项和第八项的差异：手工预留是人建的，基于订单的预留是系统随订单自动生成的，两者在数据表里是同一类对象的不同来源，但在检查时会被分别统计。
提示：手工预留与订单自动预留的差异，是最容易被忽略的一处。业务上看起来都是“预留”，但它们在 MRP 元素层面归属不同，一旦检查规则里对某类元素的参与方式做了开关设置，表现出的差异就会非常显眼。
2.3 检查规则是这张正负号清单的开关面板
真正决定“哪些项算、哪些项不算”的，是检查规则。文档给出的配置路径是：移动类型 → 检查规则 → 定义检查规则，也就是先明确哪些业务动作会触发检查，再定义这套检查要纳入哪些元素。
配置过程里有一个很容易翻车的点，文档明确写了出来：不管是新建还是复制检查组，新定义的可用性检查组后面那几个参数——总计销售、总交货需求、冻结需求——都是默认值且改不了。这意味着检查组的粒度并不是完全自由的，系统在出厂逻辑上就锁定了某些元素必须参与。
常见的实现思路是，这几个被锁定的参数对应的是“销售订单占用”与“交货需求”这类最基础的需求来源，如果允许关闭，动态检查就退化成了只算库存加采购的简化版，失去了 MRP 层面的意义。所以系统干脆在 UI 层锁死，避免配置出一个语义上自相矛盾的检查组。
3. 一次预留测试：把日期轴上的加减法走完
3.1 测试基线：库存、提前期与检查组的绑定
文档准备的测试条件是：物料编码 G0120030，计划交货时间 6 天，并把这个物料分配到前面定义的可用性检查组。
这里有两个参数必须一起看。计划交货时间 6 天，就是所谓的补货提前期——它不是一个展示用的字段，而是会真实参与可用量推算的偏移量。检查组则决定了这次检查按哪张开关面板执行。
基线库存是 2020 年 6 月 19 日的静态库存，100 PC。这个日期是整个推演的起点，后面所有需求日期的可用量，都是从这个起点往后推的。
配置与数据的绑定关系可以先这样理解：
| 配置对象 | 作用 | 本次测试取值 |
|---|---|---|
| 可用性检查组 | 决定哪些元素参与检查 | 自定义检查组 |
| 检查规则 | 按移动类型/业务类型触发 | 关联到预留创建 |
| 计划交货时间 | 补货提前期的天数偏移 | 6 天 |
| 基线库存 | 推演的起始可用量 | 100 PC（20200619） |
3.2 逐日推演：100 减 80 加 50 是怎么算出来的
推演分五步，每一步都在时间轴上落一个点。
第一步，确认 6 月 19 日的静态库存为 100 PC，这是起点。
第二步，建预留单，单号 19，需求日期 6 月 21 日，数量 80。此时时间轴上出现第一个负项：6 月 21 日 −80。
第三步，建采购订单，数量 50，需求日期 6 月 25 日。系统根据预计交货日期自动带出这个日期，时间轴上出现第一个正项：6 月 25 日 +50。
第四步，再建一个预留，需求日期 6 月 20 日，数量 30。系统报错。原因文档写得很清楚：6 月 20 日的可用库存 = 6 月 19 日的 100 减去 6 月 21 日的预留 80，等于 20，小于 30。
这一步最值得停下来想一秒。为什么 6 月 20 日的检查，会扣掉 6 月 21 日的需求？因为可用性检查做的是“截至该时点的累计可用量”，它把需求日期之前（含之后已确认的需求按 MRP 逻辑归集）的所有需求都视为已经占用。6 月 20 日虽然在 6 月 21 日之前，但系统在评估 6 月 20 日这一天的承诺能力时，已经把整条时间轴上的需求纳入了占用池。这就是为什么 80 这个需求会提前“吃掉” 6 月 20 日的额度。
这里的机制可以抽象成一句伪代码，方便记住顺序：
可用量(需求日期 D) = 基线库存 + 所有收货日期 <= D + 补货提前期 的收货项 - 所有需求日期 <= D 的需求项代码本身是伪代码，重点在三个位置：基线库存只取一次；收货项的比较基准是 D 加上补货提前期；需求项的比较基准是 D 本身。三者的差异，就是后面两次测试结果不同的全部原因。
第五步，再建预留，需求日期 6 月 26 日，数量 30，系统通过。因为 6 月 26 日这个日期，落在 6 月 25 日采购订单收货（+50）之后，所以可用量 = 100 − 80 + 50 = 70，大于 30。
3.3 补货提前期：那个让结果反转的偏移量
补充测试是整份文档里最见功力的一笔：把“不含补货提前期”勾上，再在 6 月 26 日建同样数量的需求，系统报错。
同一个日期，同一个数量，只改了一个勾选项，结果从通过变成报错。这说明 6 月 26 日这个需求之所以能被满足，并不是因为 6 月 25 日的采购订单在当天就到货，而是因为系统把收货项的可用时点往前推了 6 天——采购订单的实际可用时间被当作 6 月 19 日左右就已经可以计入供给，从而覆盖了 6 月 26 日的需求。
一旦勾掉补货提前期，收货项的可用时点回退到 6 月 25 日，6 月 26 日的需求在计算时虽然还在收货之后，但推演链条被切断，可用量归零或不足，于是报错。
这个偏移量的业务含义是：系统认为补货需要时间，所以对未来的需求，允许提前把在途的收货算作可用。它的代价是——如果供应商真的延迟，账面上“可用”的那部分其实是空的。这就是动态检查的取舍所在：它用提前期换取更高的承诺弹性，同时把风险留给了执行环节。
4. 避坑与排查：五条血泪经验
4.1 现象：检查规则改了，前台行为没变
原因通常是检查组和物料的绑定关系没生效，或者移动类型没有关联到新的检查规则。检查规则是通过移动类型或业务类型触发的，物料上挂的检查组只是“用哪套面板”，而“什么时候触发检查”由移动类型决定。只改一边，前台不会有任何变化。
解决方式是两头对齐：先确认物料主数据上的可用性检查组已更新，再确认对应业务动作所用移动类型指向的检查规则里，确实开启了这套检查。改完记得清缓存或重进事务，避免读到旧配置。
4.2 现象：新定义的检查组参数是灰的，改不动
这是文档明确记录的现象：总计销售、总交货需求、冻结需求三处默认勾选且不可修改。很多人以为是权限问题或界面 bug，反复折腾。
原因在于这几个参数被系统锁定为基础需求来源，不允许在检查组层面关闭。理解这一点之后，配置时就不该在这三个字段上耗费时间，而应该把注意力放到可调整的元素上——比如安全库存是否参与、质检与冻结库存如何处理、收货类元素是否纳入。
解决方式是接受这三个锁定项，把差异化的检查诉求通过其他可配置元素表达，必要时拆成多个检查组，按物料或业务场景分别绑定。
4.3 现象：需求日期在采购订单到货之后，仍然报库存不足
最常见的原因是补货提前期被勾掉了，或者物料的计划交货时间被维护成了 0。文档的补充测试就是这个现象的复现：6 月 26 日明明在 6 月 25 日收货之后，勾掉提前期后依然报错。
解决方式是回到物料主数据确认计划交货时间，再确认检查配置里补货提前期的开关状态。两者缺一不可——提前期天数为 0 时，开关勾不勾都没有偏移效果。
4.4 现象：同一物料，销售订单能建，预留建不了
原因在于不同业务动作走的是不同的检查规则，纳入的元素范围不同。销售订单和预留虽然都触发可用性检查，但它们的检查规则可以分别定义，允许参与的需求与供给元素并不一致。
解决方式是分别检查这两条业务链路对应的检查规则，把各自的元素开关列出来对比，而不是假设“同一个物料应该表现一致”。
4.5 现象：手工预留和订单自动预留的数量对不上
这就是文档特意点出的第四项与第八项的差异。手工预留是人建的，自动预留是系统随订单生成的，两者在检查时的归集口径可能不同。
解决方式是在排查时先按来源把预留分类统计，再和检查规则里的元素开关逐项对照。如果规则里只纳入了其中一类，账面可用量和直观感受必然对不上，这时要改的是规则口径，而不是去调整预留数据本身。
5. 设计取舍：可用性检查为什么必须“宁可算错”
把整条链路走完，会发现这套机制有一个明显的性格：它偏向于在承诺端给出更宽松的结果，而在执行端保留风险。补货提前期把未来的收货提前计入供给，就是一个典型例子。
这个取舍并不难理解。可用性检查服务的是“能不能接单、能不能排产”这个决策点，如果它过于保守，每一笔未来需求都会被判为不可用，销售没法承诺、生产没法排期，系统就退化成了一个只会说不的看门人。反过来，它把提前期纳入计算，等于用历史补货周期做了一次概率性担保，赌的是“以往 6 天能到，这次大概率也能到”。
风险由此转移到了执行侧。账面可用而实物未到的情况一旦发生，缺料就发生在生产线上，而不是发生在订单录入的那一刻。这也是为什么这套机制必须和 MRP 的收货确认、供应商交期跟踪配合使用——可用性检查负责拍板，MRP 负责兑现。
从实现角度看，这个设计还带来一个副作用：检查结果高度依赖参数而非数据本身。同一个库存、同一组订单，只改一个提前期天数或一个勾选项，结论就反转。这意味着任何一次“系统算错了”的质疑，都应该先去看参数，而不是先去看数据。
我自己的习惯是，遇到可用性检查相关的报错，先把需求日期、基线库存、提前期天数、检查组这四个值抄在纸上，按“收货项比较基准是需求日期加提前期，需求项比较基准是需求日期”这条线手动算一遍。算出来的结果和系统一致，问题就在配置；不一致，问题才在数据。这个笨办法救过我很多次，从那以后每次碰可用性检查，我都会强制先走一遍这条手工推演，再去动配置。希望帮到你。
本文还有配套的精品资源，点击获取
