简介《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 PC202006193.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 负责兑现。从实现角度看这个设计还带来一个副作用检查结果高度依赖参数而非数据本身。同一个库存、同一组订单只改一个提前期天数或一个勾选项结论就反转。这意味着任何一次“系统算错了”的质疑都应该先去看参数而不是先去看数据。我自己的习惯是遇到可用性检查相关的报错先把需求日期、基线库存、提前期天数、检查组这四个值抄在纸上按“收货项比较基准是需求日期加提前期需求项比较基准是需求日期”这条线手动算一遍。算出来的结果和系统一致问题就在配置不一致问题才在数据。这个笨办法救过我很多次从那以后每次碰可用性检查我都会强制先走一遍这条手工推演再去动配置。希望帮到你。本文还有配套的精品资源点击获取
