简介面向SAP顾问、供应链与仓储业务人员的可用性检查实操测试文档围绕静态检查与动态检查两条主线展开帮助读者理清系统在销售订单、预留、生产订单场景下如何判断物料在需求日期是否可用。内容从IM层面的静态检查讲起说明其无需后台配置、仅比对当前库存的特点再延伸到MRP层面的动态检查逐项拆解安全库存、在途、质检、冻结、非限制使用、外包库存等库存维度以及采购订单、采购申请、预留、独立需求、SD提货单、计划订单、生产订单等预计划收货与发货因素并区分手工预留与订单自动产生的预留。文中给出移动类型、检查规则与可用性检查组的配置路径并以预留单配合采购订单的日期推演为例演示可用库存100-805070的算法与报错条件以及补货提前期勾选与否带来的结果差异。资源包为1个docx文档约536KB已有3063人学习。1. 从一张 100 PC 的库存说起这份 SAP可用性检查 测试文档能解决什么同一个物料、同一个库存地点、同一个事务代码两个人先后建预留一个被系统直接放行另一个弹出“库存不足缺少 5 PC”。差别不在权限而在背后那套 SAP可用性检查 的检查组和检查规则。这份《SAP 可用性检查应用测试》文档把静态检查、动态检查、后台四步配置和一组带日期的实测数据串成了一条线适合刚接手 MM/SD 模块、需要给业务解释“为什么这单能下、那单不能下”的顾问和关键用户也适合已经会用 CO09 看数、但说不清补货提前期到底改了什么的熟手。2. 静态检查与动态检查两条判定线在第几层分叉2.1 IM 层面的静态检查只看当下这一笔库存静态检查的判定对象只有一个当前库存地点里能用的那部分非限制使用库存不往前看也不往后看。文档里的例子很直白——1000 工厂 A001 库存地点有 100 PC走 MIGO 用移动类型 201 向成本中心发 105 PC系统立刻拦下提示还差 5 PC。整个过程没有任何后台配置参与因为 IM 层面的检查是写死在库存移动逻辑里的只要移动类型本身要求检查库存系统就会做这个减法。这类检查的边界要记清楚它只对“发料”这种即时动作负责不关心明天会不会到货也不关心后天有一张销售订单在排队。很多人第一次接触时会有个误解以为在物料主数据里配了检查组就万事大吉结果发现 201 发料照拦不误、销售订单却一点提示都没有——因为销售订单根本不走 IM 这一层它走的是 SD 的可用性检查两套逻辑互不干扰。判断某个场景到底走哪条线最省事的办法是看事务代码MIGO、MB1A 这类库存移动走静态VA01、VA02、MB21、CO01 这类单据创建走动态。静态检查还有一个容易被忽略的细节它看的是“库存地点级”的可用数不是工厂级。同一个工厂下两个库存地点一个 100 PC 一个 0 PC在 A 地点发料不会去 B 地点借。这一点在多库存地点布局的仓库里经常引发争议业务方觉得“厂里明明有货”系统就是不认。2.2 MRP 层面的动态检查可用量是一条随时间变化的曲线动态检查回答的是另一个问题在某个未来日期这个物料还能不能支撑一笔新需求。它的算法不是拿当前库存减一下而是把“库存 该日期之前的所有计划收货 - 该日期之前的所有计划发货”滚动累加得到一个随时间变化的可用量曲线再拿新需求去这条曲线上比。按这份文档的表述动态检查同时看两类东西。一类是库存侧的构成包括安全库存、在途库存、质检库存、冻结库存、非限制使用库存、外包库存另一类是预计划的收货和发货收货侧有采购订单、采购申请发货侧有相关需求、预留、独立需求、SD 提货单、货运通知单、基于订单的预留、库存传输订单、计划订单、生产订单。这两张清单决定了动态检查的精度上限——配置得越宽判定越保守配置得越窄判定越松。这里有一个新手最容易绊倒的地方动态检查并不是逐日精确滚动到每一个自然日实际计算是按期间段汇总的。也就是说需求日期落在同一个段里的所有收货和发货会被一起放进算式。文档里步骤 4 的现象就是从这个特性来的新预留的需求日期是 20200620报错理由却是“100 - 20200621 预留需求 80 20 30”21 号的 80 PC 需求影响了 20 号的判断。按日粒度直觉去推这算术说不通按期间段汇总去推就通了。我在给业务做培训时一般会先讲这个段的概念否则后面所有数字他们都觉得是玄学。动态检查的第二个特性是“找得到就往前找”。当某个日期的可用量不够时系统会沿着时间轴往后找第一个能满足的日期如果找到了单据照样能建只是确认日期被推后如果整个检查范围内都找不到才硬报错。所以看到“系统没报错”不等于“库存够”很可能只是可用日期被挪到了几周之后。2.3 库存六类与预计划单据清单哪些数进公式把文档里的两张清单摊开看动态检查的算式其实就是一个加减法难点全在“谁算分子、谁算分母、谁两边都不算”。下表是我按常见配置整理的元素归属具体到自家系统还要以检查规则里的勾选为准元素归属是否默认计入可用量非限制使用库存供给计入质检库存供给默认不计入需在检查规则中放开冻结库存供给默认不计入在途库存供给视移动类型和检查规则而定外包库存供给通常计入取决于特殊库存标识安全库存供给扣减项计入直接压低可用量采购订单预计划收货计入受补货提前期约束采购申请预计划收货视检查规则而定默认常不计入手工预留MB21 建预计划发货计入订单自动产生的预留预计划发货计入但要防止与订单本身重复独立需求预计划发货视检查规则而定生产订单 / 计划订单预计划发货计入SD 提货单 / 货运通知单预计划发货计入安全库存单独列一行是有原因的它不是一个“有多少货”的概念而是一个“永远不许动”的下限。很多现场抱怨“明明账面有 100系统只认 60”八成是安全库存压了 40。这类问题的排查顺序永远是先看物料主数据 MRP 视图的安全库存字段再看检查规则。2.4 手工预留与订单预留第 4 项和第 8 项为什么要分开列文档特意提醒了预计划发货清单里第 4 项和第 8 项的差异第 4 项是手工预留由人在 MB21/MB22 里建需求日期、数量、科目分配都是人填的第 8 项是基于订单的预留由系统在创建生产订单、流程订单这类单据时自动带出来数量和日期跟着订单走。分开列不是因为它们的数据结构不同而是因为它们在算式里会打架。假设一张生产订单有 100 PC 的组件需求系统会给这个组件自动生成一条预留。如果检查规则里同时把“预留”和“生产订单”都勾成需求元素这 100 PC 就被扣了两次可用量凭空少一半。我在一个模拟项目上见过更极端的因为重复扣减一个明明够用的物料在系统里永远是负数计划员每天手工改单改了一个月才发现是配置问题。常见做法是二选一要么认订单层把相关需求和订单纳入预留层排除要么认预留层把预留纳入订单层排除不要两套都开。改完之后一定要用 MD04 对一遍元素明细看同一笔需求是不是只出现一次。3. 后台四步配置移动类型、检查规则、检查组与事务代码怎么串3.1 四步配置的先后顺序与对应节点文档给的配置路径是四步移动类型、检查规则、定义检查规则、事务代码。这四步不是并列关系而是“谁引用谁”的关系顺序搞反了会出现改了不生效的情况。下表是这四步的实际含义和我常用的入口步骤配的是什么常用入口关键动作1移动类型上挂的检查规则OMJJ打开移动类型明细看“检查规则”字段填了哪条2检查规则本身包含哪些元素可用性检查配置节点下的检查规则维护勾选或取消收货、发货、预留、订单等元素3定义检查组并分配检查规则OVZ2新建或复制检查组把检查规则分配到具体业务事务4事务代码走哪套检查组物料主数据 MRP3 视图 OVZ2物料上填检查组事务上认检查规则顺序上的原则是先定检查规则决定算什么再定检查组决定谁用这套规则最后把检查组挂到物料和移动类型上。反过来先建检查组会发现里面能选的规则还是那几条旧的改不动。OMJJ 里那个“检查规则”字段最容易出事。它的默认值往往是一个通用规则测试环境里改着玩没感觉上了生产才发现某类移动类型全被拦。我一般会先把移动类型导一份清单出来标出哪些挂了检查规则、挂的是哪条再决定动哪一条而不是直接在 OMJJ 里逐个点开看。3.2 定义检查组时那三个灰色字段文档里有一句很关键的提醒不管是新建还是复制新定义的可用性检查组后面的参数默认是“总计销售A”“总交货需求A”“冻结需求传默认勾选”这三处改不了。第一次遇到的人多半会以为配置坏了或者权限不够反复退出重进。实际上这是设计使然检查组在 SAP 的模型里不是一个“开关集合”而是一个“需求分类的容器”——它负责回答“哪些需求类型要参与检查”而不是“参与检查时怎么算”。那三个字段的值由系统在需求分类层面固定下来界面上只是把它们显示出来所以是灰的。真正的开关比如要不要算质检库存、要不要算采购申请、要不要考虑补货提前期全在检查规则那一层。理解了这层分工后面很多困惑会自动消失想让某类需求不参与检查去动需求分类和检查组想让某类收货不算可用去动检查规则。两件事别混着改混着改的后果是过两个月谁也说不清当初为什么这么配。3.3 检查规则才是真正的开关集合检查规则是这套机制里唯一真正“能改出结果”的地方。它决定四件事哪些收货算供给、哪些发货算需求、特殊库存怎么处理、补货提前期要不要考虑。文档里那个“把不含补货提前期勾选”的动作改的就是检查规则。配置时我一般按三个问题过一遍这个物料的需求主要来自哪个模块SD 订单、生产订单还是手工预留这些需求对应的单据在系统里是不是都会生成预留补货周期有多长、采购订单的交货日期准不准三个问题的答案基本就决定了检查规则该开哪几项。反过来如果不问需求来源就把所有元素全勾上得到的不是“更严格”而是“重复计算加误杀”。检查规则的编码是系统预置的几位数字或字母预留、生产订单、销售订单各对应一条。具体哪条对应哪个事务不要凭记忆填去 OVZ2 里看分配关系最稳。3.4 计划交货时间与补货提前期两个时间参数怎么参与判定文档里的物料 G0120030 有一个关键字段计划交货时间 6 天。这个值在物料主数据 MRP2 视图里维护和收货处理时间一起构成补货提前期的两个组成部分。它的含义是“今天下一张采购订单最快几天能到货架上”。这个参数直接决定了动态检查对“未来到货”的信任程度。按文档的记录测试基准日是 20200619加上 6 天正好是 20200625而步骤 3 建的那张 50 PC 采购订单交货日期恰好也是 20200625。这不是巧合是系统按预计交货日期自动带出来的。所以 20200626 的需求可以把这 50 PC 算进可用量20200620 的需求就不行——后者落在补货提前期之内物理上不可能有货。补货提前期在检查规则里对应一个勾选项文案是“不含补货提前期”。这句话读起来别扭理解成“勾上之后不再把提前期内的收货当可用”就顺了。这个开关的杀伤力很大因为它改的是全局行为同一条检查规则下所有走这个事务的物料判定结果全部平移。所以改之前一定先把原值记下来改完立刻用一组已知数据回归别等业务报错才发现。4. 用 G0120030 的一组数据跑通五个步骤与两次反转4.1 数据准备库存、两张预留和一张采购订单复现这套逻辑不需要太复杂的数据一份库存、两张预留、一张采购订单就够。文档用的物料是 G0120030计划交货时间 6 天可用性检查组分配为前面新定义的那一套测试基准日 20200619静态库存 100 PC。下表是我按文档整理的数据准备清单照着填就能复现编号单据类型数量需求/交货日期说明1静态库存100 PC20200619基线非限制使用2预留 1980 PC20200621手工预留走 MB213采购订单50 PC20200625交货日期由计划交货时间带出4预留30 PC20200620预期报错5预留30 PC20200626预期通过准备数据时有两点要注意。一是预留的需求日期和采购订单的交货日期必须落在同一检查范围里如果检查范围只开了几周20200626 这条就跑到范围外去了结果不可比。二是物料的检查组要在测试前就分配好中途改检查组会让前面建的单据按新规则重算前后数据混在一起就没法解释现象了。4.2 步骤复现20200620 报错、20200626 通过按文档的五个步骤走每一步的结果如下。步骤 1 和 2 只是铺数据真正的判定发生在步骤 4 和 5步骤操作需求日期系统可用量结果1查静态库存20200619100基线2建预留 1980 PC20200621100 - 80 20成功3建采购订单50 PC20200625供给 50成功4建预留30 PC20200620100 - 80 20报错缺 105建预留30 PC20200626100 - 80 50 70成功步骤 4 是整份文档里最值得停下来想一下的地方。新预留的需求日期是 20200620比已有那张 80 PC 预留的 20200621 还早一天按日粒度推20 号这天应该只有 100 PC 库存、没有任何需求30 PC 绰绰有余。系统却把 21 号的 80 PC 扣掉了理由是同一期间段汇总。这个现象我在现场解释过很多次业务方第一反应都是“系统算错了”实际上是检查粒度的问题。步骤 5 验证的是补货提前期的正向作用。20200626 已经过了补货提前期20200619 6 天 20200625那张 50 PC 的采购订单可以被信任可用量从 20 抬到 7030 PC 的需求顺利通过。这条数据说明动态检查不是一味从严它对“确定会到”的货是认账的。复现时还有个小技巧步骤 4 报错之后不要急着改数量重试先退出来用 CO09 看一眼这个物料在检查范围里的逐段可用量把系统算出来的数和手算的数对一遍。CO09 的明细里能直接看到每一段有哪些收货、哪些发货参与计算比在报错弹窗上猜快得多。4.3 把补货提前期开关翻一次结果为什么会反转文档最后补了一个反向验证把“不含补货提前期”勾上再在 20200626 建一张 30 PC 的预留系统报错。按文档记录的结果勾选之后可用量从 70 掉回 20也就是那张 50 PC 的采购订单不再被算作可用供给。道理不难理解勾上这个选项等于告诉系统“别信提前期内的到货承诺”哪怕采购订单的交货日期写在 20200625系统也不再把它当成立即可用的供给。于是 20200626 这条需求面对的仍然是 100 - 80 20。这次反转的价值在于它把“物料有货”和“系统认不认这货”两件事彻底分开了。业务方看到采购订单已经建了理所当然认为货在路上就该算数系统的判断标准是这张订单的交货日期相对于补货提前期处在什么位置以及检查规则愿不愿意为这个位置背书。这两种视角没有对错但必须对齐否则每一次报错都会变成一场关于“系统不准”的争论。这个开关的另一个副作用是影响面它挂在检查规则上不挂在物料上。改一次所有走这条规则的物料、所有走这个事务的单据同时变。所以做反向验证时我一般会在测试客户端做验证完立刻改回来绝不在生产客户端上边试边看。5. 排查与避坑五条从报错现场带回来的记录5.1 检查压根没触发现象建预留、建销售订单一路绿灯系统完全没有做任何可用性判断哪怕把数量填成库存的十倍也照过。原因通常有两个层次。第一层在物料主数据MRP3 视图里的“可用性检查组”字段是空的或者填了一个不启用检查的组这样所有动态检查都不会对这个物料生效。第二层在事务侧OVZ2 里对应的事务比如预留、销售订单没有分配到检查组和检查规则或者分配了但移动类型在 OMJJ 里挂的检查规则是另一条导致前台走的是“无检查”那条路。解决顺序是从物料查到事务MM03 看 MRP3 的检查组 → OVZ2 看这个检查组分配给哪些事务、配的哪条规则 → OMJJ 看移动类型的检查规则字段。三层对齐了还不触发再去看是不是单据类型层面把检查关掉了。这套顺序我踩过一次坑一开始只查了物料发现检查组填得好好的折腾半天才想起销售订单走的是另一套事务分配物料的检查组在 SD 那边根本没被引用。5.2 数量算出来对不上现象CO09 显示的可用量比手算的少一大截或者 MD04 里同一笔需求出现了两次。第一类偏差来自库存构成。安全库存、质检库存、冻结库存默认都不进可用量在途库存要看检查规则放不放行。遇到过账面 100 PC 系统只认 40 PC 的情况最后查出来是 40 PC 安全库存加 20 PC 质检库存。这类问题不需要改配置先去 MM03 的 MRP 视图和工作中心视图把安全库存、质检库存的状态捋一遍。第二类偏差来自重复计算就是前面说的手工预留和订单预留同时被纳入。判断方法很简单在 MD04 里找到那笔需求看它是以“预留”的形式出现还是以“订单”的形式出现如果两种都有就是配置重复了。第三类偏差来自期间段。同一段内的收货和发货被合并计算所以看起来“日期在后面的需求”影响了“日期在前面的判定”。这一类不是错误是粒度设定要改只能改检查范围的时间粒度代价是整体性能和其他场景的判定结果不建议轻易动。5.3 参数改不动和改错现象一新建检查组时后面那三个参数是灰的怎么点都改不了怀疑是权限问题。原因在 3.2 节已经说过那是系统固定值不是权限。解决方式是去检查规则里改真正的开关别在检查组界面上耗时间。现象二在检查规则里勾了“不含补货提前期”忘了改回来第二天另一个业务线的人跑来说所有订单的确认日期都推迟了。这类事故的共同点是改动没有记录、没有回归。我现在改检查规则前会做两件事截图存原值用一组已知数据跑一遍对比。听起来笨但比事后追查省时间得多。现象三直接在生产客户端复制一个检查组改参数改完发现不生效因为复制出来的检查组没分配给物料物料还挂在旧组上。这个坑在新顾问身上出现频率很高。稳妥的做法是配置走传输请求别在两个客户端之间手工同步。6. 把检查组固化成模板三条自检数据和一条复用边界配置改完之后我习惯用三条最小用例做自检跑通了才算这套检查组能用。这三条用例不依赖具体业务数据任何物料都能套用例构造方式期望结果验证点库存充足需求日期当天可用量大于需求量建单成功确认日期等于需求日期检查组是否正常生效库存不足需求量超出当前可用量且检查范围内无补货报错提示缺口数量缺口数量与手算是否一致跨补货提前期需求日期落在提前期之后提前期内有采购订单建单成功采购订单被计入供给提前期开关的方向是否正确第三条用例最容易被跳过但它恰恰是区分“能跑”和“跑对”的分界线。前两条只能验证检查是否触发、数量是否扣对第三条验证的是时间维度上的判断逻辑。我在一个模拟项目上就是因为只跑了前两条上线后才发现提前期开关的方向配反了所有跨月订单的确认日期全错返工修数据花的时间是配置时间的好几倍。复用边界这件事值得单独说一句。检查组是可以跨物料、跨工厂复用的但不要跨业务场景复用。销售订单和预留对“什么算可用”的诉求本来就不一样前者关心承诺给客户的日期能不能兑现后者关心车间领料时有没有货。用同一个检查组覆盖两种场景最后一定是两边都不满意。常见做法是按业务场景建三到五个检查组每个组配一条专用检查规则物料主数据里按物料类型分配这样出问题时影响面可控。从那以后我每次动检查规则之前都强制先在 CO09 里把这组三条用例跑一遍、把改动前的数值截下来再动配置改完立刻重跑对比。这个习惯救过我两次一次是发现提前期开关被误勾一次是发现复制的检查组没分配给物料。SAP 的可用性检查不算复杂复杂的是它同时被四五个模块引用任何一次随手改动都会沿着这些引用扩散出去。希望帮到你。本文还有配套的精品资源点击获取
简介面向SAP顾问、供应链与仓储业务人员的可用性检查实操测试文档围绕静态检查与动态检查两条主线展开帮助读者理清系统在销售订单、预留、生产订单场景下如何判断物料在需求日期是否可用。内容从IM层面的静态检查讲起说明其无需后台配置、仅比对当前库存的特点再延伸到MRP层面的动态检查逐项拆解安全库存、在途、质检、冻结、非限制使用、外包库存等库存维度以及采购订单、采购申请、预留、独立需求、SD提货单、计划订单、生产订单等预计划收货与发货因素并区分手工预留与订单自动产生的预留。文中给出移动类型、检查规则与可用性检查组的配置路径并以预留单配合采购订单的日期推演为例演示可用库存100-805070的算法与报错条件以及补货提前期勾选与否带来的结果差异。资源包为1个docx文档约536KB已有3063人学习。1. 从一张 100 PC 的库存说起这份 SAP可用性检查 测试文档能解决什么同一个物料、同一个库存地点、同一个事务代码两个人先后建预留一个被系统直接放行另一个弹出“库存不足缺少 5 PC”。差别不在权限而在背后那套 SAP可用性检查 的检查组和检查规则。这份《SAP 可用性检查应用测试》文档把静态检查、动态检查、后台四步配置和一组带日期的实测数据串成了一条线适合刚接手 MM/SD 模块、需要给业务解释“为什么这单能下、那单不能下”的顾问和关键用户也适合已经会用 CO09 看数、但说不清补货提前期到底改了什么的熟手。2. 静态检查与动态检查两条判定线在第几层分叉2.1 IM 层面的静态检查只看当下这一笔库存静态检查的判定对象只有一个当前库存地点里能用的那部分非限制使用库存不往前看也不往后看。文档里的例子很直白——1000 工厂 A001 库存地点有 100 PC走 MIGO 用移动类型 201 向成本中心发 105 PC系统立刻拦下提示还差 5 PC。整个过程没有任何后台配置参与因为 IM 层面的检查是写死在库存移动逻辑里的只要移动类型本身要求检查库存系统就会做这个减法。这类检查的边界要记清楚它只对“发料”这种即时动作负责不关心明天会不会到货也不关心后天有一张销售订单在排队。很多人第一次接触时会有个误解以为在物料主数据里配了检查组就万事大吉结果发现 201 发料照拦不误、销售订单却一点提示都没有——因为销售订单根本不走 IM 这一层它走的是 SD 的可用性检查两套逻辑互不干扰。判断某个场景到底走哪条线最省事的办法是看事务代码MIGO、MB1A 这类库存移动走静态VA01、VA02、MB21、CO01 这类单据创建走动态。静态检查还有一个容易被忽略的细节它看的是“库存地点级”的可用数不是工厂级。同一个工厂下两个库存地点一个 100 PC 一个 0 PC在 A 地点发料不会去 B 地点借。这一点在多库存地点布局的仓库里经常引发争议业务方觉得“厂里明明有货”系统就是不认。2.2 MRP 层面的动态检查可用量是一条随时间变化的曲线动态检查回答的是另一个问题在某个未来日期这个物料还能不能支撑一笔新需求。它的算法不是拿当前库存减一下而是把“库存 该日期之前的所有计划收货 - 该日期之前的所有计划发货”滚动累加得到一个随时间变化的可用量曲线再拿新需求去这条曲线上比。按这份文档的表述动态检查同时看两类东西。一类是库存侧的构成包括安全库存、在途库存、质检库存、冻结库存、非限制使用库存、外包库存另一类是预计划的收货和发货收货侧有采购订单、采购申请发货侧有相关需求、预留、独立需求、SD 提货单、货运通知单、基于订单的预留、库存传输订单、计划订单、生产订单。这两张清单决定了动态检查的精度上限——配置得越宽判定越保守配置得越窄判定越松。这里有一个新手最容易绊倒的地方动态检查并不是逐日精确滚动到每一个自然日实际计算是按期间段汇总的。也就是说需求日期落在同一个段里的所有收货和发货会被一起放进算式。文档里步骤 4 的现象就是从这个特性来的新预留的需求日期是 20200620报错理由却是“100 - 20200621 预留需求 80 20 30”21 号的 80 PC 需求影响了 20 号的判断。按日粒度直觉去推这算术说不通按期间段汇总去推就通了。我在给业务做培训时一般会先讲这个段的概念否则后面所有数字他们都觉得是玄学。动态检查的第二个特性是“找得到就往前找”。当某个日期的可用量不够时系统会沿着时间轴往后找第一个能满足的日期如果找到了单据照样能建只是确认日期被推后如果整个检查范围内都找不到才硬报错。所以看到“系统没报错”不等于“库存够”很可能只是可用日期被挪到了几周之后。2.3 库存六类与预计划单据清单哪些数进公式把文档里的两张清单摊开看动态检查的算式其实就是一个加减法难点全在“谁算分子、谁算分母、谁两边都不算”。下表是我按常见配置整理的元素归属具体到自家系统还要以检查规则里的勾选为准元素归属是否默认计入可用量非限制使用库存供给计入质检库存供给默认不计入需在检查规则中放开冻结库存供给默认不计入在途库存供给视移动类型和检查规则而定外包库存供给通常计入取决于特殊库存标识安全库存供给扣减项计入直接压低可用量采购订单预计划收货计入受补货提前期约束采购申请预计划收货视检查规则而定默认常不计入手工预留MB21 建预计划发货计入订单自动产生的预留预计划发货计入但要防止与订单本身重复独立需求预计划发货视检查规则而定生产订单 / 计划订单预计划发货计入SD 提货单 / 货运通知单预计划发货计入安全库存单独列一行是有原因的它不是一个“有多少货”的概念而是一个“永远不许动”的下限。很多现场抱怨“明明账面有 100系统只认 60”八成是安全库存压了 40。这类问题的排查顺序永远是先看物料主数据 MRP 视图的安全库存字段再看检查规则。2.4 手工预留与订单预留第 4 项和第 8 项为什么要分开列文档特意提醒了预计划发货清单里第 4 项和第 8 项的差异第 4 项是手工预留由人在 MB21/MB22 里建需求日期、数量、科目分配都是人填的第 8 项是基于订单的预留由系统在创建生产订单、流程订单这类单据时自动带出来数量和日期跟着订单走。分开列不是因为它们的数据结构不同而是因为它们在算式里会打架。假设一张生产订单有 100 PC 的组件需求系统会给这个组件自动生成一条预留。如果检查规则里同时把“预留”和“生产订单”都勾成需求元素这 100 PC 就被扣了两次可用量凭空少一半。我在一个模拟项目上见过更极端的因为重复扣减一个明明够用的物料在系统里永远是负数计划员每天手工改单改了一个月才发现是配置问题。常见做法是二选一要么认订单层把相关需求和订单纳入预留层排除要么认预留层把预留纳入订单层排除不要两套都开。改完之后一定要用 MD04 对一遍元素明细看同一笔需求是不是只出现一次。3. 后台四步配置移动类型、检查规则、检查组与事务代码怎么串3.1 四步配置的先后顺序与对应节点文档给的配置路径是四步移动类型、检查规则、定义检查规则、事务代码。这四步不是并列关系而是“谁引用谁”的关系顺序搞反了会出现改了不生效的情况。下表是这四步的实际含义和我常用的入口步骤配的是什么常用入口关键动作1移动类型上挂的检查规则OMJJ打开移动类型明细看“检查规则”字段填了哪条2检查规则本身包含哪些元素可用性检查配置节点下的检查规则维护勾选或取消收货、发货、预留、订单等元素3定义检查组并分配检查规则OVZ2新建或复制检查组把检查规则分配到具体业务事务4事务代码走哪套检查组物料主数据 MRP3 视图 OVZ2物料上填检查组事务上认检查规则顺序上的原则是先定检查规则决定算什么再定检查组决定谁用这套规则最后把检查组挂到物料和移动类型上。反过来先建检查组会发现里面能选的规则还是那几条旧的改不动。OMJJ 里那个“检查规则”字段最容易出事。它的默认值往往是一个通用规则测试环境里改着玩没感觉上了生产才发现某类移动类型全被拦。我一般会先把移动类型导一份清单出来标出哪些挂了检查规则、挂的是哪条再决定动哪一条而不是直接在 OMJJ 里逐个点开看。3.2 定义检查组时那三个灰色字段文档里有一句很关键的提醒不管是新建还是复制新定义的可用性检查组后面的参数默认是“总计销售A”“总交货需求A”“冻结需求传默认勾选”这三处改不了。第一次遇到的人多半会以为配置坏了或者权限不够反复退出重进。实际上这是设计使然检查组在 SAP 的模型里不是一个“开关集合”而是一个“需求分类的容器”——它负责回答“哪些需求类型要参与检查”而不是“参与检查时怎么算”。那三个字段的值由系统在需求分类层面固定下来界面上只是把它们显示出来所以是灰的。真正的开关比如要不要算质检库存、要不要算采购申请、要不要考虑补货提前期全在检查规则那一层。理解了这层分工后面很多困惑会自动消失想让某类需求不参与检查去动需求分类和检查组想让某类收货不算可用去动检查规则。两件事别混着改混着改的后果是过两个月谁也说不清当初为什么这么配。3.3 检查规则才是真正的开关集合检查规则是这套机制里唯一真正“能改出结果”的地方。它决定四件事哪些收货算供给、哪些发货算需求、特殊库存怎么处理、补货提前期要不要考虑。文档里那个“把不含补货提前期勾选”的动作改的就是检查规则。配置时我一般按三个问题过一遍这个物料的需求主要来自哪个模块SD 订单、生产订单还是手工预留这些需求对应的单据在系统里是不是都会生成预留补货周期有多长、采购订单的交货日期准不准三个问题的答案基本就决定了检查规则该开哪几项。反过来如果不问需求来源就把所有元素全勾上得到的不是“更严格”而是“重复计算加误杀”。检查规则的编码是系统预置的几位数字或字母预留、生产订单、销售订单各对应一条。具体哪条对应哪个事务不要凭记忆填去 OVZ2 里看分配关系最稳。3.4 计划交货时间与补货提前期两个时间参数怎么参与判定文档里的物料 G0120030 有一个关键字段计划交货时间 6 天。这个值在物料主数据 MRP2 视图里维护和收货处理时间一起构成补货提前期的两个组成部分。它的含义是“今天下一张采购订单最快几天能到货架上”。这个参数直接决定了动态检查对“未来到货”的信任程度。按文档的记录测试基准日是 20200619加上 6 天正好是 20200625而步骤 3 建的那张 50 PC 采购订单交货日期恰好也是 20200625。这不是巧合是系统按预计交货日期自动带出来的。所以 20200626 的需求可以把这 50 PC 算进可用量20200620 的需求就不行——后者落在补货提前期之内物理上不可能有货。补货提前期在检查规则里对应一个勾选项文案是“不含补货提前期”。这句话读起来别扭理解成“勾上之后不再把提前期内的收货当可用”就顺了。这个开关的杀伤力很大因为它改的是全局行为同一条检查规则下所有走这个事务的物料判定结果全部平移。所以改之前一定先把原值记下来改完立刻用一组已知数据回归别等业务报错才发现。4. 用 G0120030 的一组数据跑通五个步骤与两次反转4.1 数据准备库存、两张预留和一张采购订单复现这套逻辑不需要太复杂的数据一份库存、两张预留、一张采购订单就够。文档用的物料是 G0120030计划交货时间 6 天可用性检查组分配为前面新定义的那一套测试基准日 20200619静态库存 100 PC。下表是我按文档整理的数据准备清单照着填就能复现编号单据类型数量需求/交货日期说明1静态库存100 PC20200619基线非限制使用2预留 1980 PC20200621手工预留走 MB213采购订单50 PC20200625交货日期由计划交货时间带出4预留30 PC20200620预期报错5预留30 PC20200626预期通过准备数据时有两点要注意。一是预留的需求日期和采购订单的交货日期必须落在同一检查范围里如果检查范围只开了几周20200626 这条就跑到范围外去了结果不可比。二是物料的检查组要在测试前就分配好中途改检查组会让前面建的单据按新规则重算前后数据混在一起就没法解释现象了。4.2 步骤复现20200620 报错、20200626 通过按文档的五个步骤走每一步的结果如下。步骤 1 和 2 只是铺数据真正的判定发生在步骤 4 和 5步骤操作需求日期系统可用量结果1查静态库存20200619100基线2建预留 1980 PC20200621100 - 80 20成功3建采购订单50 PC20200625供给 50成功4建预留30 PC20200620100 - 80 20报错缺 105建预留30 PC20200626100 - 80 50 70成功步骤 4 是整份文档里最值得停下来想一下的地方。新预留的需求日期是 20200620比已有那张 80 PC 预留的 20200621 还早一天按日粒度推20 号这天应该只有 100 PC 库存、没有任何需求30 PC 绰绰有余。系统却把 21 号的 80 PC 扣掉了理由是同一期间段汇总。这个现象我在现场解释过很多次业务方第一反应都是“系统算错了”实际上是检查粒度的问题。步骤 5 验证的是补货提前期的正向作用。20200626 已经过了补货提前期20200619 6 天 20200625那张 50 PC 的采购订单可以被信任可用量从 20 抬到 7030 PC 的需求顺利通过。这条数据说明动态检查不是一味从严它对“确定会到”的货是认账的。复现时还有个小技巧步骤 4 报错之后不要急着改数量重试先退出来用 CO09 看一眼这个物料在检查范围里的逐段可用量把系统算出来的数和手算的数对一遍。CO09 的明细里能直接看到每一段有哪些收货、哪些发货参与计算比在报错弹窗上猜快得多。4.3 把补货提前期开关翻一次结果为什么会反转文档最后补了一个反向验证把“不含补货提前期”勾上再在 20200626 建一张 30 PC 的预留系统报错。按文档记录的结果勾选之后可用量从 70 掉回 20也就是那张 50 PC 的采购订单不再被算作可用供给。道理不难理解勾上这个选项等于告诉系统“别信提前期内的到货承诺”哪怕采购订单的交货日期写在 20200625系统也不再把它当成立即可用的供给。于是 20200626 这条需求面对的仍然是 100 - 80 20。这次反转的价值在于它把“物料有货”和“系统认不认这货”两件事彻底分开了。业务方看到采购订单已经建了理所当然认为货在路上就该算数系统的判断标准是这张订单的交货日期相对于补货提前期处在什么位置以及检查规则愿不愿意为这个位置背书。这两种视角没有对错但必须对齐否则每一次报错都会变成一场关于“系统不准”的争论。这个开关的另一个副作用是影响面它挂在检查规则上不挂在物料上。改一次所有走这条规则的物料、所有走这个事务的单据同时变。所以做反向验证时我一般会在测试客户端做验证完立刻改回来绝不在生产客户端上边试边看。5. 排查与避坑五条从报错现场带回来的记录5.1 检查压根没触发现象建预留、建销售订单一路绿灯系统完全没有做任何可用性判断哪怕把数量填成库存的十倍也照过。原因通常有两个层次。第一层在物料主数据MRP3 视图里的“可用性检查组”字段是空的或者填了一个不启用检查的组这样所有动态检查都不会对这个物料生效。第二层在事务侧OVZ2 里对应的事务比如预留、销售订单没有分配到检查组和检查规则或者分配了但移动类型在 OMJJ 里挂的检查规则是另一条导致前台走的是“无检查”那条路。解决顺序是从物料查到事务MM03 看 MRP3 的检查组 → OVZ2 看这个检查组分配给哪些事务、配的哪条规则 → OMJJ 看移动类型的检查规则字段。三层对齐了还不触发再去看是不是单据类型层面把检查关掉了。这套顺序我踩过一次坑一开始只查了物料发现检查组填得好好的折腾半天才想起销售订单走的是另一套事务分配物料的检查组在 SD 那边根本没被引用。5.2 数量算出来对不上现象CO09 显示的可用量比手算的少一大截或者 MD04 里同一笔需求出现了两次。第一类偏差来自库存构成。安全库存、质检库存、冻结库存默认都不进可用量在途库存要看检查规则放不放行。遇到过账面 100 PC 系统只认 40 PC 的情况最后查出来是 40 PC 安全库存加 20 PC 质检库存。这类问题不需要改配置先去 MM03 的 MRP 视图和工作中心视图把安全库存、质检库存的状态捋一遍。第二类偏差来自重复计算就是前面说的手工预留和订单预留同时被纳入。判断方法很简单在 MD04 里找到那笔需求看它是以“预留”的形式出现还是以“订单”的形式出现如果两种都有就是配置重复了。第三类偏差来自期间段。同一段内的收货和发货被合并计算所以看起来“日期在后面的需求”影响了“日期在前面的判定”。这一类不是错误是粒度设定要改只能改检查范围的时间粒度代价是整体性能和其他场景的判定结果不建议轻易动。5.3 参数改不动和改错现象一新建检查组时后面那三个参数是灰的怎么点都改不了怀疑是权限问题。原因在 3.2 节已经说过那是系统固定值不是权限。解决方式是去检查规则里改真正的开关别在检查组界面上耗时间。现象二在检查规则里勾了“不含补货提前期”忘了改回来第二天另一个业务线的人跑来说所有订单的确认日期都推迟了。这类事故的共同点是改动没有记录、没有回归。我现在改检查规则前会做两件事截图存原值用一组已知数据跑一遍对比。听起来笨但比事后追查省时间得多。现象三直接在生产客户端复制一个检查组改参数改完发现不生效因为复制出来的检查组没分配给物料物料还挂在旧组上。这个坑在新顾问身上出现频率很高。稳妥的做法是配置走传输请求别在两个客户端之间手工同步。6. 把检查组固化成模板三条自检数据和一条复用边界配置改完之后我习惯用三条最小用例做自检跑通了才算这套检查组能用。这三条用例不依赖具体业务数据任何物料都能套用例构造方式期望结果验证点库存充足需求日期当天可用量大于需求量建单成功确认日期等于需求日期检查组是否正常生效库存不足需求量超出当前可用量且检查范围内无补货报错提示缺口数量缺口数量与手算是否一致跨补货提前期需求日期落在提前期之后提前期内有采购订单建单成功采购订单被计入供给提前期开关的方向是否正确第三条用例最容易被跳过但它恰恰是区分“能跑”和“跑对”的分界线。前两条只能验证检查是否触发、数量是否扣对第三条验证的是时间维度上的判断逻辑。我在一个模拟项目上就是因为只跑了前两条上线后才发现提前期开关的方向配反了所有跨月订单的确认日期全错返工修数据花的时间是配置时间的好几倍。复用边界这件事值得单独说一句。检查组是可以跨物料、跨工厂复用的但不要跨业务场景复用。销售订单和预留对“什么算可用”的诉求本来就不一样前者关心承诺给客户的日期能不能兑现后者关心车间领料时有没有货。用同一个检查组覆盖两种场景最后一定是两边都不满意。常见做法是按业务场景建三到五个检查组每个组配一条专用检查规则物料主数据里按物料类型分配这样出问题时影响面可控。从那以后我每次动检查规则之前都强制先在 CO09 里把这组三条用例跑一遍、把改动前的数值截下来再动配置改完立刻重跑对比。这个习惯救过我两次一次是发现提前期开关被误勾一次是发现复制的检查组没分配给物料。SAP 的可用性检查不算复杂复杂的是它同时被四五个模块引用任何一次随手改动都会沿着这些引用扩散出去。希望帮到你。本文还有配套的精品资源点击获取
