SAP PP中ECN驱动的BOM组件增补实战：CSAP_MAT_BOM_MAINTAIN深度解析

1. 项目概述：为什么在SAP PP中用CSAP_MAT_BOM_MAINTAIN函数模块处理ECN变更下的BOM组件增补？

在制造业ERP实施与运维一线干了十多年，我经手过上百个SAP PP模块的BOM管理场景，从汽车零部件厂的多层级装配BOM，到医疗器械企业的合规性BOM版本控制，再到电子代工厂的ECN（Engineering Change Notice，工程变更通知）高频迭代环境。今天这个标题——“SAP PP CSAP_MAT_BOM_MAINTAIN ECN 增加组件”，表面看只是调用一个标准函数模块往BOM里加一行物料，但背后藏着的是制造企业最敏感、最易出错、也最容易被审计盯上的核心业务逻辑闭环。它不是简单的“新增一条记录”，而是一次受控的、可追溯的、带审批流和影响分析的工程数据变更落地动作。

关键词里反复出现的“ECN”和“BOM”，正是制造业PLM（产品生命周期管理）与ERP系统衔接的咽喉要道。现实中，90%以上的BOM错误不是源于录入疏忽，而是ECN执行不到位：设计部门发了变更单，工艺部门确认了新结构，但SAP里BOM没同步更新，结果车间按旧BOM领料、生产、报工，轻则造成批次性返工，重则引发客户投诉甚至召回。而CSAP_MAT_BOM_MAINTAIN这个函数模块，就是SAP官方为这类场景提供的、唯一被ABAP顾问广泛验证且支持后台批量、程序化调用的标准接口。它不像事务码CS01/CS02那样依赖GUI操作，也不像BAPI_MATERIAL_BOM_MAINTAIN那样对BOM类型、有效性规则、替代组等参数校验过于宽松——它原生内置了PP模块对BOM主数据完整性的全部校验逻辑，包括物料主数据状态检查、工厂/视图可用性判断、BOM使用范围（Usage）匹配、有效性日期冲突预警，甚至能自动触发后续的MRP重排建议。

我见过太多客户踩坑：有项目组图省事，直接用UPDATE语句改AUFM或STKO表，结果导致BOM版本号错乱、MRP跑不出计划订单；也有团队用BAPI硬写，却漏掉了“替代组（Alternative BOM）”字段的必填校验，上线后发现所有替代BOM都失效；更常见的是，开发人员只关注“加进去”，却没处理ECN关联的“生效日期（Valid From）”和“变更理由（Change Reason）”，导致审计时无法回答“这个组件是哪天、因何原因、由谁批准加入的”。所以，这篇内容不是教你怎么点几下鼠标，而是带你从ECN业务流出发，拆解CSAP_MAT_BOM_MAINTAIN的调用前提、参数陷阱、数据一致性保障机制，以及如何把它真正嵌入到你的ECN电子审批工作流中去。适合两类人：一是正在做ECN自动化集成的ABAP开发，需要一份避开80%线上报错的实操指南；二是PP模块顾问或BOM管理员，想搞懂这个函数背后的业务语义，避免被开发甩锅说“接口没问题，是你们BOM主数据不全”。

2. 核心设计思路与方案选型：为什么不用BAPI、不用LSMW，而死磕CSAP_MAT_BOM_MAINTAIN？

在接到“ECN增加组件”需求时，我第一反应不是写代码，而是画一张ECN业务流图：设计工程师在PLM系统提交ECN → 变更经理审批 → 工艺/质量/采购会签 → 最终批准 → 系统自动生成变更任务 → 同步更新SAP BOM。这个流程里，SAP端的“更新BOM”只是最后一步，但它必须满足三个刚性条件：可追溯、强校验、零人工干预。这就直接排除了事务码CS02的手动维护（不可追溯、易漏步骤），也否定了LSMW（Legacy Systems Migration Workbench）这种批导工具（缺乏实时校验、失败后难定位）。至于BAPI_MATERIAL_BOM_MAINTAIN，它确实是SAP公开的标准化接口，但我在三个不同行业的项目里实测过它的局限性：

• 校验粒度太粗：BAPI只检查物料号是否存在、BOM头是否有效，但对“组件是否允许在此工厂使用”、“该组件的采购类型是否匹配BOM用途（如生产用BOM不能挂服务类物料）”、“替代组编号是否已在当前BOM中定义”等PP模块特有规则，完全不校验。我们曾用BAPI批量导入500条ECN变更，结果37%的记录因“替代组未维护”被静默跳过，日志里只显示“成功”，实际BOM根本没变。

• 参数耦合度高：BAPI要求你一次性传入完整的BOM结构（Header+Items），哪怕只增一个组件，也要把整张BOM的Item列表重新组装一遍。这在ECN场景下极其危险——如果上游PLM只推送了变更行，你得先查老BOM、再合并新行、再排序、再补全所有字段（比如ITEM_CAT、COMPONENT_QTY、SCRAP_FACTOR），稍有差池就导致BOM顺序错乱或数量覆盖。

• 事务一致性弱：BAPI内部没有封装完整的数据库锁机制。当多个ECN并发执行时，可能出现两个进程同时读取同一BOM版本、各自添加组件、再分别写回，最终只保留最后一个写入的结果，中间的变更就丢了。我们在某家电厂就遇到过，一天内3个ECN同时生效，结果只有最后一个被记录，前两个的组件“人间蒸发”。

反观CSAP_MAT_BOM_MAINTAIN，它是SAP PP模块内部维护BOM的核心函数，直接调用CS02事务背后的逻辑。它的设计哲学是“最小化变更、最大化校验、原子化提交”。它接受的不是整张BOM，而是明确的“操作类型（INSERT/UPDATE/DELETE）+ 单条组件数据”，所有校验都在数据库提交前完成，且内置了对STKO/STPO/MAST等关键表的行级锁。更重要的是，它原生支持ECN场景必需的两个字段：CHANGE_NUMBER（变更号）和VALID_FROM（生效日期），这两个字段会自动写入BOM组件的变更历史表（STZU），成为审计追踪的黄金证据链。

提示：CSAP_MAT_BOM_MAINTAIN不是BAPI，它没有RFC远程调用能力，必须在SAP应用服务器本地执行。这意味着它天然适合嵌入到SAP自身的增强点（如ECN审批后的USEREXIT），或者通过RFC-enabled wrapper函数封装后供外部系统调用。别试图用它做跨系统直连，那是给自己挖坑。

所以，我们的技术选型结论很清晰：以CSAP_MAT_BOM_MAINTAIN为唯一BOM写入引擎，前端对接PLM的ECN WebService，后端绑定SAP的变更管理（Change Management）模块，中间用自定义Z函数做参数转换与异常捕获。这个架构看似笨重，但换来的是100%的变更可追溯、99.9%的校验准确率，以及审计时一句“所有BOM变更均通过标准函数模块CSAP_MAT_BOM_MAINTAIN执行，符合SAP最佳实践”的底气。

3. 核心参数解析与实操要点：CSAP_MAT_BOM_MAINTAIN的12个必填字段与5个隐藏雷区

CSAP_MAT_BOM_MAINTAIN的函数签名看着简单，只有4个输入参数（IT_HEADER、IT_ITEMS、IT_RETURN、IV_COMMIT），但真正决定成败的是IT_ITEMS内联表里那12个关键字段。我把它拆成三类：基础骨架字段（5个）、ECN专属字段（3个）、PP业务规则字段（4个）。下面逐个说透，全是血泪教训换来的经验。

3.1 基础骨架字段：缺一不可的“身份证”

这5个字段是BOM组件的“法定身份信息”，任何缺失都会导致函数直接报错BOM header not found或Material not maintained in plant。

• MATNR（物料号）：必须是已创建的、状态为“已冻结”或“已发布”的物料主数据。注意：不能是虚拟物料（如KMAT），也不能是仅在MM模块维护、未激活PP视图的物料。我见过最典型的错误是PLM推送的物料号带前后空格，ABAP里用CONDENSE处理后才通过校验。

• WERKS（工厂）：必须与BOM头中的工厂一致。这里有个大坑：有些客户在BOM头里维护的是“集团工厂”，但组件行里填了“分厂代码”，函数会静默忽略该行。正确做法是，先用SELECT SINGLE WERKS FROM T001W WHERE WERKS = ...验证工厂有效性。

• STLAL（BOM用途）：即BOM的“使用范围”，比如'1'代表生产用BOM，'2'代表成本核算用BOM。这个值必须与BOM头（IT_HEADER-STLAL）严格匹配。很多开发人员以为填'1'就行，结果发现BOM头是'5'（销售BOM），导致插入失败。

• STLAN（BOM状态）：通常为'1'（有效），但ECN场景下可能需要'2'（测试）。注意：状态变更会触发BOM版本号递增，必须确保你有权限修改BOM状态。

• IDNRK（组件物料号）：即你要添加的子件物料号。它必须已在系统中存在，且其物料主数据的“基本视图”和“MRP视图”已维护。特别提醒：如果子件是采购件，其采购类型（BSART）必须是'F'（外购）或'E'（委外），否则函数会报错Component material is not a procurement type。

3.2 ECN专属字段：审计追踪的“时间戳”

这三个字段是ECN合规性的命脉，漏填或填错，审计时会被直接认定为“非受控变更”。

• CHANGE_NUMBER（变更号）：必须是SAP中已创建的ECN号，通过事务码CC01创建。不能是PLM系统生成的任意字符串。函数会校验该ECN号的状态是否为“已批准（Released）”，未批准的ECN会被拒绝。我们曾用一个测试ECN号调试，结果函数返回Change number not released，折腾了两小时才发现ECN状态问题。

• VALID_FROM（生效日期）：格式必须为YYYYMMDD，且不能早于ECN的批准日期，也不能晚于BOM头的VALID TO（如果BOM头设了截止日期）。最常犯的错误是传入SY-DATUM（当前日期），但ECN要求下月1日生效，结果组件当天就生效了，打乱生产计划。

• CHANGE_REASON（变更理由）：这是一个2字符的代码，必须在SPRO中配置（路径：PP → Production Orders → Master Data → Define Change Reasons）。常见值有'01'（设计优化）、'02'（供应商变更）、'03'（法规要求）。填错代码会导致函数报错Invalid change reason，且该字段会写入STZU表，成为审计证据。

3.3 PP业务规则字段：决定BOM能否跑通MRP的“基因”

这4个字段不填不会导致函数报错，但填错会让BOM在后续MRP运行中彻底失效。

• MENGE（组件数量）：单位必须与BOM头的基准单位（BASE_UOM）一致。例如BOM头基准单位是'EA'（件），这里就不能填'KG'。更隐蔽的坑是：如果子件物料主数据的“基本计量单位”是'KG'，但BOM头基准单位是'EA'，函数会强制将数量转换为'EA'，可能导致小数点后精度丢失。建议统一用CONVERT_TO_LOCAL_CURRENCY类似逻辑做单位换算。

• MEINH（组件单位）：必须与子件物料主数据的“基本计量单位”完全一致。我见过最离谱的案例：子件物料单位是'ROL'（卷），开发人员填了'ROLL'，函数没报错，但MRP计算时把1卷当成1件，导致领料量爆炸。

• SCRAP_FACTOR（废品率）：格式是小数，如5%填0.05，不是5。这个值会直接影响MRP计算的需求数量。ECN变更时，如果新组件工艺更复杂，废品率可能从3%升到8%，这个字段必须同步更新，否则MRP会低估需求。

• ITEM_CAT（行项目类别）：这是PP模块的“隐形开关”。'L'代表常规组件，'N'代表非库存组件（如外协工序），'D'代表文档组件。填错会导致MRP不考虑该组件（如填'D'），或者成本核算错误（如该组件本应计入生产成本，却因类别错被忽略）。

注意：所有日期字段（VALID_FROM、VALID_TO）必须用CONVERT_DATE_TO_INTERNAL转换为SAP内部格式（YYYYMMDD），不能直接拼字符串。我试过用|{ sy-datum }|拼接，结果在跨年时因月份位数不足（如'202451'）导致函数崩溃。

4. 完整实操流程：从ECN审批完成到BOM组件落地的7步闭环

现在我们把前面所有知识点串起来，走一遍真实的ECN组件增加流程。这不是理论推演，而是我在某汽车零部件厂上线时，带着开发团队逐行调试、最终稳定运行的生产脚本。整个过程分为7个阶段，每个阶段都有明确的输入、输出、校验点和容错机制。

4.1 阶段一：ECN审批完成事件捕获

起点不是PLM推送，而是SAP自身ECN状态变更。我们在SAP中创建一个增强点（Enhancement Spot），监听事务码CC02的保存事件。当ECN状态变为“已批准（Released）”时，触发自定义程序Z_ECNEVENT_HANDLER。这个程序不做任何BOM操作，只做三件事：

1. 读取ECN主数据（表CAUFVD），提取CHANGE_NUMBER、VALID_FROM、CHANGE_REASON；
2. 查询该ECN关联的所有BOM变更行（表CAUFV中的OBJNR字段关联BOM对象）；
3. 将这些数据写入自定义透明表ZECN_BOM_QUEUE，状态设为‘WAITING’。

实操心得：不要依赖PLM主动推送！PLM系统可能宕机、网络中断、或推送延迟。SAP自身ECN状态变更才是最可靠的事件源。我们曾因PLM推送失败，导致3个ECN的BOM变更遗漏，后来改成监听SAP事件，再没出过问题。

4.2 阶段二：BOM头数据预加载与校验

程序从ZECN_BOM_QUEUE读取一条待处理记录，第一步不是操作组件，而是锁定并校验BOM头。调用函数CSAP_MAT_BOM_READ，传入MATNR、WERKS、STLAL、STLAN、DATUV（参考日期，用ECN的VALID_FROM）。这个函数返回完整的BOM头结构（STKO）和所有现有组件（STPO）。我们重点校验：

• BOM头STLST（状态）是否为'1'（有效）；
• DATUV是否在BOM头的DATUV（生效日期）和DATUB（失效日期）范围内；
• STLAL是否与ECN要求的BOM用途一致（如ECN指定更新“生产用BOM”，则STLAL必须为'1'）。

如果任一校验失败，程序将记录错误日志（写入BALHDR/BALLOG），并将队列状态改为‘ERROR’，同时发送邮件告警。这一步拦截了约40%的无效请求，比如ECN填错了工厂代码，或BOM头已过期。

4.3 阶段三：组件数据清洗与映射

拿到干净的BOM头后，开始处理ECN推送的组件数据。PLM通常以XML格式推送，我们用CL_XML_DOCUMENT解析，然后映射到CSAP_MAT_BOM_MAINTAIN的IT_ITEMS内联表。关键清洗逻辑：

• MATNR和IDNRK去除首尾空格，并用TRANSLATE ... TO UPPER CASE统一大小写（SAP物料号全大写）；
• MENGE字段用MOVE-CORRESPONDING转换为数值类型，避免字符串比较；
• VALID_FROM用CONVERT_DATE_TO_INTERNAL转换，再与BOM头DATUV比较，确保不早于BOM头生效日；
• 如果PLM未提供ITEM_CAT，默认赋值 'L'（常规组件），但记录日志提醒工艺部门补充。

实操心得：永远不要相信上游系统的数据质量！我们给PLM接口加了数据质量看板，实时监控空值率、格式错误率。当IDNRK空值率超过5%，自动触发PLM数据治理流程。

4.4 阶段四：CSAP_MAT_BOM_MAINTAIN函数调用

这是核心步骤。我们构建IT_HEADER和IT_ITEMS，然后调用函数。关键代码片段如下：

DATA: lt_header TYPE STANDARD TABLE OF csap_mat_bom_header, lt_items TYPE STANDARD TABLE OF csap_mat_bom_item, lt_return TYPE STANDARD TABLE OF bapiret2. " 构建BOM头（复用CSAP_MAT_BOM_READ返回的STKO） ls_header-matnr = ls_stko-matnr. ls_header-werks = ls_stko-werks. ls_header-stlan = ls_stko-stlan. ls_header-stlal = ls_stko-stlal. ls_header-datuv = ls_ecn-valid_from. " 生效日期作为BOM头参考日期 APPEND ls_header TO lt_header. " 构建组件行（IT_ITEMS） LOOP AT lt_plm_items INTO ls_plm. CLEAR ls_item. ls_item-matnr = ls_plm-matnr. ls_item-werks = ls_plm-werks. ls_item-stlan = ls_plm-stlan. ls_item-stlal = ls_plm-stlal. ls_item-idnrk = ls_plm-idnrk. ls_item-menge = ls_plm-menge. ls_item-meinh = ls_plm-meinh. ls_item-scrapp = ls_plm-scrapp. ls_item-item_cat = ls_plm-item_cat. ls_item-change_number = ls_ecn-change_number. ls_item-valid_from = ls_ecn-valid_from. ls_item-change_reason = ls_ecn-change_reason. APPEND ls_item TO lt_items. ENDLOOP. " 调用函数 CALL FUNCTION 'CSAP_MAT_BOM_MAINTAIN' EXPORTING iv_commit = 'X' " 关键！必须提交，否则不写库 TABLES it_header = lt_header it_items = lt_items it_return = lt_return. " 检查返回 READ TABLE lt_return WITH KEY type = 'E' TRANSPORTING NO FIELDS. IF sy-subrc = 0. " 有错误，记录并退出 PERFORM log_error USING lt_return. EXIT. ENDIF.

注意：iv_commit = 'X'是生死线。不提交，函数只做校验，不写数据库。我们曾因开发人员误删了这行，导致所有ECN“看似成功”，实则BOM纹丝未动，生产计划照旧跑错。

4.5 阶段五：变更结果验证与日志归档

函数调用成功后，绝不直接认为万事大吉。我们立即执行双重验证：

• 正向验证：再次调用CSAP_MAT_BOM_READ，读取刚更新的BOM，检查新组件是否出现在STPO表中，且VALID_FROM、CHANGE_NUMBER字段与ECN一致；
• 反向验证：查询变更历史表STZU，确认该组件的变更记录已生成，CHANGENR字段等于ECN号。

双验证通过后，将队列状态更新为‘SUCCESS’，并将完整的操作日志（包括ECN号、BOM头、新增组件、执行时间、操作用户）写入自定义审计表ZECN_AUDIT_LOG。这张表按月分区，保留5年，是每次内外部审计的必查项。

4.6 阶段六：MRP触发与影响分析

BOM更新只是开始，真正的价值在于驱动下游。我们在此步自动触发：

• 对该物料执行MD01（单层MRP），确保新组件被纳入需求计算；
• 调用BAPI_MRP_RUN启动后台MRP作业，参数指定MATNR和WERKS；
• 发送通知给计划员：物料 {MATNR} 的BOM已按ECN {CHANGE_NUMBER} 更新，MRP已重排，预计影响 {COUNT} 个计划订单。

实操心得：MRP触发必须异步！不能在BOM更新事务内同步执行MD01，否则会锁表导致系统卡死。我们用SUBMIT RSM13000 AND RETURN提交后台作业，既保证及时性，又不影响前台响应。

4.7 阶段七：异常处理与人工介入通道

再完美的流程也会遇到意外。我们为每种可能的错误设计了分级响应机制：

• 一级错误（可自动恢复）：如数据库锁等待超时（DBIF_RSQL_SQL_ERROR），程序自动重试3次，间隔5秒；
• 二级错误（需人工确认）：如BOM头状态异常、ECN未批准，程序暂停，发送邮件给BOM管理员，附带错误详情和修复指引（如“请检查ECN {NUM} 状态，路径：CC02 -> 输入变更号 -> 查看状态栏”）；
• 三级错误（阻断性）：如物料主数据缺失、单位不匹配，程序终止，标记队列为‘BLOCKED’，必须由PP顾问手动介入，填写《BOM变更异常处理单》后才能解封。

这个机制让我们的ECN自动化成功率从最初的72%提升到99.8%，剩下0.2%的阻断性错误，全部是上游数据质量问题，与SAP程序无关。

5. 常见问题与排查技巧实录：那些让你凌晨三点还在看STPO表的真问题

在ECN自动化项目上线后的三个月里，我和团队处理了137个BOM相关报错。我把它们归为5类高频问题，并附上我的现场排查笔记。这些不是手册里的标准答案，而是我在服务器日志里一行行扒出来的真相。

5.1 问题一：“BOM header not found” —— 表面是BOM不存在，实际是工厂/用途错配

现象：函数返回BOM header not found，但用CS03能查到该物料的BOM。

我的排查过程：

1. 先查STKO表：SELECT * FROM STKO WHERE MATNR = 'XXX' AND WERKS = 'YYY' AND STLAL = '1'—— 返回空。
2. 再查STKO所有记录：SELECT * FROM STKO WHERE MATNR = 'XXX'—— 发现WERKS是'ZZZ'（分厂），STLAL是'5'（销售BOM）。
3. 对比ECN推送的参数：WERKS确实填了'YYY'，STLAL填了'1'。

根因：PLM系统配置错误，将“生产工厂”和“销售工厂”混用了。ECN本应更新分厂'ZZZ'的生产BOM，却推到了总厂'YYY'。

解决方案：

• 在程序开头加校验：SELECT COUNT(*) FROM STKO WHERE MATNR = @matnr AND WERKS = @werks AND STLAL = @stlal，为0则报错并提示“BOM头不存在，请确认工厂与BOM用途”；
• 同步推动PLM修正主数据映射规则。

小技巧：用事务码CS12（BOM比较）快速查看同一物料在不同工厂的BOM差异，比查表快十倍。

5.2 问题二：“Component material is not maintained in plant” —— 子件物料“隐身”了

现象：函数报错，但子件物料在MM03里能查到，且工厂视图已维护。

我的排查过程：

1. 查子件物料主数据：SELECT * FROM MARA WHERE MATNR = 'ABC'——MTART（物料类型）是'ROH'（原材料），正常。
2. 查工厂视图：SELECT * FROM MARC WHERE MATNR = 'ABC' AND WERKS = 'YYY'——DISPO（MRP类型）为空！
3. 进MM02维护该物料，切换到“MRP视图”，发现DISPO字段是灰色的，未维护。

根因：子件物料虽在工厂存在，但MRP视图未激活。CSAP_MAT_BOM_MAINTAIN在检查组件时，会强制校验MARC-DISPO是否有值，为空即报错。

解决方案：

• 在程序中增加MRP视图检查：SELECT DISPO FROM MARC INTO @lv_dispo WHERE MATNR = @idnrk AND WERKS = @werks，为空则记录警告日志；
• 建立子件物料主数据健康检查报表，每周扫描MARC-DISPO为空的物料。

5.3 问题三：“Change number not released” —— ECN“已批准”是假象

现象：ECN在CC02里状态栏显示“Released”，但函数仍报此错。

我的排查过程：

1. 查ECN主表CAUFVD：SELECT STATU FROM CAUFVD WHERE AUFNR = 'ECN123'——STATU是'CRE'（已创建），不是'REL'（已批准）。
2. 再查状态文本表JEST：SELECT * FROM JEST WHERE OBJNR = '...ECN...' AND STAT = 'I0002'——INACT字段为'X'（非活动），说明状态未真正激活。

根因：SAP的ECN状态是“状态+状态配置”的组合。CC02界面显示“Released”，可能是状态描述文本，但底层状态码未更新。常见于ECN审批流未走完，或状态配置（OSS1）中漏配了'REL'状态。

解决方案：

• 不信界面，只信数据库：校验CAUFVD-STATU = 'REL'且JEST-INACT = ''；
• 在ECN审批增强点里，强制调用BAPI_ECNC_CREATE的提交逻辑，确保状态真正落库。

5.4 问题四：BOM更新成功，但MRP不认新组件

现象：CSAP_MAT_BOM_MAINTAIN返回成功，STPO里能看到新组件，但MD04里没有该组件的需求。

我的排查过程：

1. 查新组件行：SELECT * FROM STPO WHERE MATNR = 'PARENT' AND IDNRK = 'CHILD'——DATUV（生效日期）是'20240601'，正确。
2. 查MRP运行日志：SELECT * FROM MRPLOG WHERE MATNR = 'PARENT' AND LOGDATE > '20240601'—— 发现MRP运行时DATUV是'20240501'，早于组件生效日。
3. 查MRP配置：事务码OMDQ，发现该物料的“MRP类型”是'PD'（净需求），但“计划周期”设为'001'（1天），导致MRP只看当天及之后的需求。

根因：MRP运行时的参考日期（DATUV）与BOM组件生效日期不匹配。MRP默认用当前日期，而新组件下月才生效，MRP自然“看不见”。

解决方案：

• 在触发MRP时，显式传入DATUV = ECN-VALID_FROM；
• 或调整MRP配置，将“计划周期”设为足够长（如'030'），覆盖ECN生效窗口。

5.5 问题五：同一ECN多次执行，BOM组件重复添加

现象：ECN审批后，程序被误触发两次，BOM里出现两条完全相同的组件行。

我的排查过程：

1. 查STPO：SELECT * FROM STPO WHERE MATNR = 'PARENT' AND IDNRK = 'CHILD' AND STLAN = '1'—— 两条记录，POSNR（行号）分别是'0010'和'0020'，其他字段全同。
2. 查变更历史STZU：两条记录的CHANGENR都是'ECN123'，CHANGEDATE相差3秒。

根因：程序未做幂等性控制。ECN审批事件可能被SAP系统重复触发（如网络抖动导致RFC重传），而程序没有检查“该ECN是否已处理过”。

解决方案：

• 在ZECN_BOM_QUEUE表中，将CHANGE_NUMBER + MATNR + WERKS + STLAL设为唯一索引；
• 程序开始时，先INSERT一条记录，若唯一约束冲突，则跳过本次处理；
• 这是最简单、最可靠的幂等方案，比分布式锁、Redis去重都稳。

最后分享一个小技巧：当BOM出现诡异问题时，别急着查代码，先用事务码CS15（BOM多层展开）看一眼。它能直观显示BOM层级、组件数量、废品率，比对着STPO表一行行算快得多。我解决80%的“MRP不认组件”问题，都是靠CS15一眼看出废品率填成了100%（该填0.01，却填了100）。