SAP PP替代物料配置与MRP后继切换排查指南

简介：SAP-PP模块替代物料与后继物料配置的实操型手册，面向已具备一定PP基础、需要在生产订单与BOM中落实物料切换方案的顾问、关键用户与计划人员，重点解决物料短缺、供应商切换时的平滑过渡问题。内容围绕平行切换与非平行切换两类场景展开，涵盖CS20b批量替换组件、只消耗不采购时的物料状态与安全库存管控、CS02中非连续标识与后继组的维护、可用性检查的启用条件，以及多供应商供货下按比例拆分消耗的策略取值。文中还点明三种以上物料替换的适用边界，以及物料全部无库存时MRP仍会跑出原始物料需求的风险，并给出用BOM更改编号与生效时间加以控制的替代思路。资源包共1个docx文档、约871KB，篇幅紧凑，便于对照系统界面逐步操作或打印成桌面速查清单。目前已有2557人学习下载。

1. 替代不是替换：为什么 A、B、C 全没库存，MRP 还是跑出 A 的需求

很多人配完 SAP-PP 里的替代物料，第一件事就是把库存清空做验证，结果 MD01 跑完一看，A、B、C 三个物料全部零库存，采购申请还是稳稳挂在 A 头上。这不是配置漏了，恰恰是这套机制的设计前提：替代物料在系统里从来不是「拿一个换掉另一个」，而是「给同一个需求多准备几个供给来源」。需求侧认的永远是 BOM 里那一行正主，替代只发生在供给匹配的一瞬间。这条分界线搞不清楚，后面所有字段——非连续标识、后继物料、使用可能性、优先级——都会变成玄学。SAP 的替代物料体系本质上是把「要什么」和「从哪来」拆成了两个时间点处理，而绝大多数配置事故，都是把这两个时间点混成了一件事。

2. MRP 与非连续标识：需求侧到底认哪个物料

2.1 非连续标识 1 和 3：一个管「自己是终端」，一个管「跟着别人走」

物料主数据 MRP4 视图里那个不起眼的「非连续标识」，是整套后继物料机制的总开关。它的取值不是随意的勾选项，而是定义了物料在 BOM 结构中扮演的角色。取值 1 对应「单一平行终端部分/物料」，意思是这个物料自己就是一个终止点——它用完了，就顺着「后继的物料」字段指向的那一个物料走下去。取值 3 对应「相关平行不连续部分/物料」，意思是这个物料不是主角，它属于某个后继组，切换时点由组里那个标识为 1 的主控物料决定，所以这类物料的「后继的物料」字段必须留空。

这个 1 和 3 的二分法，本质是在回答一个问题：一组物料里，谁有资格当「扳机」。设想一个主板套件下有四个组件，两两成组，A 组和 B 组功能等价。如果四个组件都设成 1，系统就不知道到底该听谁的——每个物料都想独立触发切换，组关系就散了。所以设计上必须指定一个「主控」承担触发责任，其余的挂 3 号标识当跟随者。

值得多说一句的是这个字段的作用域。非连续标识影响的是 MRP 的计划行为，不是 BOM 展开行为。BOM 里写着 A 就是 A，展开出来的需求行不会因为非连续标识而变成 B。设置这个字段之后，MRP 会为 A 建立一条「中止记录」，规划它在库存耗尽或到达中止日期之后的需求去向。但在库存真正清零之前，需求仍然老老实实挂在 A 头上。

提示：非连续标识 3 的物料上如果误填了「后继的物料」，后续组切换会失效，而且系统不会报错。这是排查时最容易漏看的一处。

2.2 后继物料字段与 MRP 的后继计划

「后继的物料」这个字段承载的语义比字段名看上去要窄。它表达的是「我这个物料退役之后，需求请转给谁」，是一条单向的、计划层面的指针，不是运行时的替换指令。MRP 在展开 BOM 时依然算出 A 的需求，然后在中止逻辑里判断：A 的库存还够不够撑到下次补货？中止日期到了没有？只有这些条件触发，后续的需求才会被推到后继物料上。

这就解释了开头那个反直觉现象。A、B、C 三件物料都零库存的时候，MRP 跑出来的仍然是 A 的需求——因为「库存为零」这件事对 MRP 来说不是切换信号，它只是「需要补货」的信号。真正的切换信号是生产订单执行可用性检查的那一刻，那是另一套时钟。

我一般会这么理解这个字段的设计动机：MRP 是长周期的、批量跑的、面向未来的，它天然保守，不愿意轻易改变计划对象；而可用性检查是短周期的、单订单的、面向当下的，它必须灵活。让 MRP 保持稳定、让检查负责应变，是 SAP 在这两个模块之间做的一次职责划分。代价就是计划员看到的计划和车间看到的执行会不一致，这需要靠管理流程去弥合，而不是靠配置去消除。

2.3 为什么必须开可用性检查 02

可用性检查的设置位置在物料主数据 MRP3 视图，不是 MRP4。这个细节本身就说明了它的定位：它不属于「中止数据」这套主数据语义，而属于「库存与供给」这一侧。

规则 02 是「单个需求/个别需求」检查，针对单个订单行做 ATP 校验，正好对应生产订单组件这个场景。规则留空表示不做检查，那么订单保存和下达时根本不会去问「A 的库存够不够」，自然也不会触发替代组的分配逻辑。原文里反复强调「如果不检查不会替代」，说的就是这个因果关系——替代逻辑是挂在检查结果上的一个后处理步骤，检查不跑，后处理就不存在。

把执行时序摊开看会更清楚：

1. CO01 创建生产订单，BOM 展开，生成组件需求行，此时行里写明的是 A，需求数量按 BOM 用量算；
2. 订单保存或下达时，执行可用性检查（规则 02）；
3. 检查发现 A 的可用库存为 45，需求是 100，缺口 55；
4. 系统拿着这个缺口去查 BOM 项目上的替代项目组，按组内的策略、优先级、使用可能性挑选候选物料；
5. 分配结果回写到订单组件行，B 补 55，A 保留 45。

第 3 步和第 4 步之间是整条链路的咽喉。如果第 2 步没发生，第 3 步无从谈起，第 4、5 步全部静默跳过。这也是为什么很多配置看起来「设置全对但不生效」——字段都对，就是开关没开。

3. BOM 项目层：替代组是怎么把多行 BOM 粘成一个整体的

3.1 替代项目组、优先级、策略、使用可能性：四个字段各管什么

进入 CS02 双击组件行的数量字段，弹出的明细界面里有四个字段，它们的关系是层层递进的，不是并列的选项。

替代项目组是第一道门。组名相同，几行 BOM 才互相可见；组名不同，哪怕物料完全一样，系统也当它们毫无关系。这是纯粹的关系表设计——组名就是那个 join key。

优先级和策略是一对绑定关系。策略为 1（手工维护/按用途可能性）时，优先级形同虚设，分配完全由使用可能性决定；策略为 2（100% 检查）时，优先级生效，系统按 1、2、3 的顺序逐个尝试，找到一个能覆盖全额的物料就停。原文里那个「优先级 1/2/3、策略 2、使用可能性留空」的配置，就是典型的择一模式。

使用可能性只在策略 1 下有实际意义。它的数值不要求总和等于 100，系统内部会做归一化——这一点原文专门验证过，50% 和 25% 的组合会算成 0.667 和 0.334。但归一化带来的是精度问题，下面还会展开。

3.2 策略 1 与策略 2：比例拆分和 100% 检查是两种不同的分配算法

这两种策略对应两种完全不同的业务假设，混用是最常见的翻车来源。

策略 1 假设「这些物料是可以混着用的」。典型场景是多供应商供货，物料号不同但东西一样，今天到这家明天到那家，车间不在乎用哪个，只要总量够。这种情况下系统按比例把总需求切成几份，各物料各自承担自己的份额，MRP 也各自跑各自的采购。原文里 50+30+20 拆 200 个需求得到 100/60/40，就是这个逻辑的直接体现。

策略 2 假设「这些物料是替代关系，不是并存关系」。物料 A 是正主，A 没了才轮到 B，B 没了才轮到 C。同一时刻订单上只有一个物料在供货，不会出现 A 供一半 B 供一半的混合状态。原文的连续替代场景——66000031 用完用 66000032，用完再用 66000034——严格来说每次只能消耗一个物料的库存量，超出就报错，订单都下达不了。

两者的运行差异用一句话概括：策略 1 是「分摊」，策略 2 是「择一」。分摊关心的是总量守恒，择一关心的是单料可满足性。

注意：同一替代组内的各行必须使用相同的策略。如果一行填 1 一行填 2，系统的行为会退化成按行独立判断，组关系名存实亡。

3.3 终止数据 / 中止组 / 后继组：组对组切换的键值设计

这是整套机制里设计感最强的一块。操作路径是：CS02 双击 66000031 的数量进入子项目，点「终止数据」，在「中止组」里填 A；再双击 66000034 进入子项目，点「物料后继数据」，在「后继组」里填 A。两组代码必须一模一样，否则链接不上。

为什么用「组代码」而不是直接指定「31 换成 34」？因为业务上要换的是整组。主板套件里 A 组是两个零件，B 组也是两个零件，切换时必须整组换，不能让 31 配 35 这种跨组组合出现——那在物理装配上就是错的。用组代码做键，SAP 表达的语义是「A 组整体被 B 组整体替代」，至于组内谁对谁，系统不关心，也不需要关心。

这个设计带来的直接后果就是整组触发。原文的测试数据很能说明问题：31 库存 0、32 库存 100，34 库存 200、35 库存 300，下 100 台的生产订单各需 200，检查后 31 和 32 一起切到 34 和 35。32 明明还有 100 的库存，照样被切走了。原因就是扳机在 31 身上——31 是标识为 1 的主控物料，它断料，整组跟着走。

从工程角度看，这是一个典型的「牺牲局部最优换整体一致性」的取舍。如果允许 32 继续用、只切 31，库存利用率会更高，但装配线上就会出现 A 组零件新旧混用的情况，追溯和质量管理都会变复杂。SAP 选择了保守方案。

还有一个实操上的坑：如果 BOM 项目上已经设置了替代项目组，「终止数据」按钮会变灰点不动。必须先把替代项目组清空，才能进入中止数据的维护界面。这两套机制在 BOM 项目层是互斥的，不能并存。

4. 三种典型形态的实现差异：单料后继、后继组、比例拆分

4.1 单料后继：累加扣减为什么只适合两个物料

单料后继的配置链路最短：MM02 在 A 的 MRP4 视图设非连续标识 1、后继物料填 B，A 的 MRP3 视图可用性检查设 02，B 维护好工作计划视图，BOM 里两行都留着，搞定。

它的分配行为是「累加扣减」：需求 100，A 有 45，先扣光 A 的 45，剩下的 55 记到 B 头上。A 和 B 各自算各自的账，互不干扰。原文那个「需要 100 个，A 只有 45，自动补充 B 55 个」就是标准输出。

这个方法的能力边界非常明确——只支持两个物料。原因藏在数据模型里：「后继的物料」是物料主数据上的一个单值字段，A 只能指向一个 B，B 想再指向 C，就得让 B 自己也变成非连续物料，形成一条链。链式结构在数学上没问题，但在可用性检查的实现上会退化成逐级递归，每一级都要重新判断库存和缺口，逻辑复杂度和出错面都上去了。SAP 显然没打算在这条路上走远，三个及以上物料的场景直接用替代组更省事。

原文还有一句关键提示：如果 A 和 B 在 BOM 里的用量不相等（比如 A 用 2 个、B 用 3 个），这套设置就不够用了，还得在 BOM 里做额外配置。这时候作者的建议是用第二种方法（替代组）更简单，这个判断是对的——用量不等意味着换算关系存在，而累加扣减的默认前提是 1:1。

4.2 后继组：为什么一个物料断料会触发整组切换

后继组的完整配置分两层。物料主数据层：66000031 设非连续标识 1、后继物料 66000034；66000032 设非连续标识 3、后继物料留空。BOM 层：31 和 32 在子项目里设中止组 A，34 和 35 设后继组 A。

这里有个容易被忽略的对称性要求：物料主数据上的「后继的物料」指向，和 BOM 项目上的组代码，两条线都要通。主数据上的指针决定了 MRP 层面的计划流向，BOM 上的组代码决定了订单执行时的切换范围，缺一条链路就是不完整的。

切换的触发点在第 2 章讲过的主控物料上。只要 31 的库存不足以覆盖本次需求，整组立刻切到 B 组，不管 32 还有多少存货。这个行为在前面的测试数据里已经验证过了。

从库存管理角度看，这个设计有个副作用值得提前想清楚：被「连坐」切换掉的那部分库存（本例中的 32 的 100 个）会留在原地，成为呆滞料。如果这种组切换在生产中频繁发生，需要通过定期清理或者调整组划分来消化，否则账面库存会越来越难看。

提示：用 CS02 进 BOM，菜单「附加 - 更多的 - 终止信息」可以直观看到组切换后的效果预览。配置完先在这里看一眼，比直接下生产订单验证快得多。

4.3 比例拆分：使用可能性不等于 100 时系统怎么算

策略 1 下的分配算法本身很简单，但归一化的分母选择决定了结果是否符合直觉。很多人以为分母固定是 100，实际上是「组内实际使用可能性之和」。

# 按使用可能性分配替代组需求数量（对应策略 = 1 的场景） def split_by_usage(total_req, usage_map): total_usage = sum(usage_map.values()) if total_usage == 0: # 全为 0 时系统给警告，不阻断，退回默认分配 return {m: 0 for m in usage_map} # 关键：分母是组内实际之和，不是常量 100 return {m: round(total_req * u / total_usage, 3) for m, u in usage_map.items()} # 三个物料按 50:30:20 分摊 200 的需求 print(split_by_usage(200, {"66000031": 50, "66000032": 30, "66000034": 20})) # {'66000031': 100.0, '66000032': 60.0, '66000034': 40.0} # 原文验算：50% 和 25% 分摊 1 个需求 print(split_by_usage(1, {"A": 50, "B": 25})) # {'A': 0.667, 'B': 0.333}

这段逻辑说清楚了两件事。第一，分母用的是实际和，所以 50+25 这种不满 100 的组合不会算出「半个需求」的荒唐结果，系统会自动把比例拉回 100%。第二，round到三位小数之后，如果计量单位是 PC 这种整数单位，0.667 和 0.333 加起来的取整结果可能是 0 和 0，需求数量直接归零——这就是原文说的「比例和不是 100 可能会有问题，所需物料数量不足」。

更隐蔽的一层是：当比例为 0 时，系统会弹警告要求输入使用可能性，但按回车就能过。这个警告容易被当成噪音忽略，实际上它提示的是「这一行物料在本次订单里不会分到任何需求」。如果这一行的物料是必须装配的，后果就是订单缺件。

工程上的稳妥做法是让组内使用可能性之和严格等于 100，同时保证每个非零比例乘以总需求后不小于 1 个最小计量单位。这两条不满足，比例拆分迟早给你颜色看。

5. 避坑与排查：替代没生效时按这个顺序看

5.1 五条踩坑记录

第一条：配置全对，替代完全不触发。现象是生产订单下出来，组件行还是原物料，库存明明不够也不切换。原因是可用性检查规则留空。替代逻辑是挂在检查结果上的后处理，检查不跑就什么都没有。解决方式是 MM02 进 MRP3 视图，把「可用性检查」设为 02，然后重新创建订单验证——已经存在的订单不会回溯生效，必须重建。

第二条：后继组配好了，CS02 里看不到效果。现象是在 BOM 子项目里设了中止组 A 和后继组 A，但「终止信息」里空空如也。原因有两种：一是中止组和后继组的代码大小写或空格不一致，系统认为是两个组；二是 BOM 项目上残留了替代项目组，导致「终止数据」按钮置灰，配置根本没存进去。解决方式是先把替代项目组清空，再重新维护两组代码，确保逐字符一致。

第三条：三个物料想用后继物料法，怎么都配不通。现象是 A 的后继设成 B、B 的后继设成 C，结果订单只切了一级。原因是这个方法的数据模型就是单值的，链式后继不是它的设计目标。解决方式有两个：换成替代组加策略 2 的连续替代方案，或者直接走 BOM 更改编号做版本切换。

第四条：使用可能性加不到 100，订单数量算出来偏小。现象是 BOM 里填了 50 和 25，订单需求 1 个，结果两行各算 0.667 和 0.333，取整后变成 0。原因是归一化后不足一个最小计量单位。解决方式是补齐到 100，或者调整订单批量，让每一份都至少覆盖 1 个计量单位。

第五条：BOM 冻结后再改物料，一改就报错。现象是原物料已经冻结，想更新 BOM 里的组件，系统拒绝。原因是冻结状态锁定了 BOM 的可维护性，这是设计上的保护而非缺陷。解决方式是先解冻再改，或者更规范的做法——用 CS20 做批量组件替换，一次性把涉及的所有 BOM 全部换掉，配合更改编号记录变更。批量替换时执行结果会以颜色反馈，绿色成功，红色失败，失败项要逐条查原因，通常是 BOM 本身已冻结或物料状态不允许。

5.2 一个可复现的验证手法

排查这类问题，我习惯按「主数据 → BOM → 库存 → 订单」的顺序走一遍，每一步都有明确的观察点，不靠猜。

第 5 步是最容易被跳过的一步。很多人以为「库存为零」才会触发，实际上触发条件是「可用库存低于本单需求」，两者不是一回事。另外还要注意非限制库存和质检库存的区别，可用性检查只认前者。

6. 运行时替代与版本控制：两套方案的分界线在哪

配置做到这一步，会遇到一个绕不开的判断：这个物料到底是「暂时缺」还是「以后不用了」。

运行时替代（可用性检查驱动的这一整套）解决的是前者。它的优势是零人工干预，订单下下去自动找料，车间不用等计划员改单。代价则藏在 MRP 那一侧——需求永远认主料，只要主料还有一丁点库存或者中止条件没触发，MRP 就会持续为它跑需求、跑采购申请。一个已经事实上停用两年的物料，如果主数据没清理干净，系统仍然会年复一年地给它生成计划。原文作者的提醒「A、B 物料长久不用的情况下，直接用 BOM 的更改编号、生效时间来控制」，说的就是这个成本。

版本控制走的是另一条路。BOM 的更改编号配合生效日期，可以在某个时间点之后让 BOM 里彻底没有 A，只有 B。这是工程变更管理的标准做法，优点是从源头切断，MRP 从切换日起就只会看到 B，不会再产生任何 A 的需求。缺点是不够灵活——变更时点必须提前定好，中途想反悔得再开一个更改编号。

我倾向于用一条很朴素的判断标准划线：这个物料一年内还会不会回来。会回来，用运行时替代，保留回旋余地；不回来，走版本控制，把历史包袱彻底切干净。最怕的是两种方案混着用——既配了替代组，又在 BOM 里留着一堆过期物料不做版本切换，最后计划员看到的数字谁也解释不清。

早些年我在一个模拟项目上就吃过这个亏。当时为了图省事，把一批已经停用半年的物料保留了替代组配置，只把库存清零了事，结果每个月 MRP 都在给这些物料跑采购申请，采购员以为是系统 bug，来回折腾了好几轮。从那以后我每次做替代物料配置，都会强制走一遍「这个料还会不会回来」的确认，回不来的直接开更改编号切版本，绝不留后门。希望这些经验能帮到你少绕几圈。

本文还有配套的精品资源，点击获取