PLM与SAP BOM接口：从EBOM到物料BOM的集成实践

简介：面向SAP实施顾问、ABAP开发及ERP项目管理人员，这份ERP信息化资料围绕PLM与SAP系统间的BOM接口展开，适用于制造企业在物料主数据同步场景下的需求梳理与方案设计。文档以功能规格说明书（FS）形式呈现，完整覆盖文档概述、详细功能描述、技术说明、确认签字等标准章节；核心给出了PLM端创建或修改BOM后自动传输到SAP系统的流程，并包含权限逻辑字段、自定义表/结构以及开发工作量评估项等落地细节。内容预览中还能看到标准功能是否采用、未采用原因、预计开发天数和确认签字页，方便团队直接作为接口开发与验收的参考模板。包体为单份DOC文件，容量约135KB，轻量便于下载阅读。目前已有135人学习下载，对正在推进SAP与PLM集成项目的团队有直接参考价值，可节省撰写接口设计文档的时间。

1. PLM 与 SAP BOM 接口：这份 ERP 系统信息化资料到底写了什么

在很多制造企业的 ERP 系统里，SAP PP 模块跑不起来，多数不是计划策略配错了，而是 BOM 不齐。设计部门在 PLM 里改一个物料替代，生产计划却还在等人工把变更抄到 SAP 里，稍不留神就出现“设计已改、生产还在跑旧 BOM”的尴尬局面。这份带 SG_PP_FS_PP02 编号的文件，属于典型的 ERP 系统信息化资料，它要解决的就是 PLM 与 SAP BOM 接口这一核心集成任务：把 PLM 维护的设计 BOM 自动、准确、可追溯地写入 SAP 的物料 BOM，同时还要处理工厂、BOM 用途、替代组、有效期这些 SAP 侧才有的概念。适合做 PP 模块顾问、接口开发和 ERP 实施的人看，也适合所有被两套系统对账逼疯的运维。

2. BOM 接口的数据模型：先分清 PLM EBOM 和 SAP 物料 BOM

接口开发有一句老话：80% 的时间花在字段映射上，写代码只是最后一步。PLM 与 SAP BOM 接口尤其如此。PLM 里维护的是 EBOM（工程 BOM），SAP 里要落的是物料 BOM（Material BOM），两边结构相近，但细节口径完全不同。如果不先把数据模型理清楚，后端的 BAPI 调用再标准也接不住脏数据。

2.1 PLM EBOM 与 SAP BOM 的一对多关系

PLM 的 EBOM 以“产品结构”为中心，父件下面挂子件，子件下面还能挂子件，节点上的属性是设计属性，比如设计版本、图纸号、物料分类。SAP 的 BOM 以“物料 + 工厂 + 用途”为唯一键，同一个成品物料在一个工厂里可以有多个 BOM，靠替代组和有效期区分。一个 EBOM 经常要对到 SAP 的多个 BOM 里：工厂 1000 用国产件，工厂 2000 用进口替代件，PLM 里可能只是两个版本，SAP 里却是两张不同 BOM。所以接口不能试图做一对一 copy，必须有一个映射层，至少把工厂、BOM 用途、替代组这些维度在接口配置表里显式维护出来。

另外，PLM 里经常会有虚件（Phantom）结构，SAP 里也有同样的虚件标记，但展开逻辑不同。PLM 展开时虚件可以自动下钻，SAP 里如果虚件没有在物料主数据或 BOM 行项目里正确定义，MRP 展开时就可能把虚件当成真实需求。接口团队最常犯的错是照搬 PLM 的层级，忽略 SAP “按生产物料展开”的规则，导致成品下挂了一层 PLM 才有的“设计分组”，这层在 SAP 里根本不该出现在生产 BOM 中。

2.2 头行映射表：字段先对齐，代码才不会反复返工

下面这张表是我在核对接口字段时常用的基线表，覆盖了 SAP 物料 BOM 创建时最核心的头、行字段。PLM 侧字段名各家不一样，但业务含义基本一致。

这张表的价值在于：PLM 导出的 Excel 里，字段名往往是“编码”“品名”“装配数量”，如果接口文档里没有把这一层对应关系写清楚，开发就会拿列名去猜，然后在测试环境反复试错。我一般会在正式开发前先让 PLM 实施把导出的字段样例给一版，我再手工映射到 SAP 的 BOM 结构和 BAPI 参数上，实践证明这个动作能省掉一半以上的返工。

2.3 BOM 用途、替代组和项目类别是 SAP 特有逻辑

PLM 里通常只有“版本生效”概念，SAP 里却用 BOM 用途、替代组、有效期三个维度共同决定哪张 BOM 在什么条件下被展开。BOM 用途 1 是生产计划最常用的，MRP 和订单都会按它展开；用途 2 一般给设计和工程用，不参与 MRP；用途 3 用于设备维护，工厂维护模块要用。接口默认从 PLM 同步过来的 EBOM 必须落到用途 1，否则会出现“BOM 建好了但 MRP 不认”的诡异现象。很多项目把这个默认值写死在代码里，但遇到要多业务板块共享一套 SAP 时就出问题，工程 BOM 和维护 BOM 都需要走同一接口，这时就应当把用途也做成映射字段，而不是写死。

项目类别（ItemCategory）是最容易被忽略的。PLM 设计 BOM 里除了真实零部件，往往还有“装配说明”“涂装说明”这类文本，如果接口把它当成组件物料去创建，SAP 会报物料不存在。合理做法是把这些行映射成项目类别 T（文本项目），它不挂物料号，只展示文本；不参与 MRP，也不做库存扣减。L 类才是挂在物料主数据上的库存项目。项目类别直接决定 BOM 展开时的行为，所以建议在字段映射表里单独列一列，并给出 PLM 端“文本行”的判断规则，而不是让开发自己去猜。

2.4 物料主数据前置检查：先有物料，才有 BOM

BOM 接口报错里，最典型的错误不是 BAPI 参数错，而是组件物料不存在。PLM 里的新物料可能还没同步到 SAP，或者同步了但物料主数据缺少生产视图。BOM 创建时 SAP 会校验组件物料号，但不会自动帮你扩展视图，一旦缺少就会直接报错。因此在调用 BOM BAPI 前，接口层应该先做一次物料主数据检查。

检查可以直接调 BAPI_MATERIAL_GET_DETAIL，或者通过查询物料表 MARA 和 MARC。对于 PLM 高低版本混合发送的情况，还需要做物料号格式转换：外部传进来的“100200”要转成 SAP 内部 18 位“000000000000100200”，常见做法是调用 CONVERSION_EXIT_MATN1_INPUT 。这个转换不能在调用 BAPI 后才补救，应该在解析报文时就完成，否则同一批次里两条物料编码格式不统一，BAPI 容易返回“物料号不合法”。把前置检查写成一个独立函数，接口主流程只负责调用，会让后续问题排查清晰很多。

3. 用 RFC/BAPI 落地 PLM 与 SAP BOM 接口：一套能跑通的最小实现

数据模型对齐后，就要进入实现层。SAP 对外的接口很多，BOM 创建最常用的是 BAPI 和函数模块。这里我给出一套基于 BAPI_MATERIAL_BOM_CREATE 的最小实现，分别从 ABAP 侧和外部系统侧展开，顺带说清参数坑。

3.1 同步 BAPI 还是异步 IDoc：先看业务量

PLM 与 SAP BOM 接口的主流交互方式有两种：同步 RFC 调用 BAPI，以及异步 IDoc 投递。同步方式适合数据量可控、需要立刻知道结果的场景。比如 PLM 提交一条 BOM，接口直接返回“成功”或“失败”，PLM 侧可以根据返回值刷新界面状态。异步 IDoc 则适合一晚上传几千张 BOM，通过 SAP PI/PO 或中间件把 PLM 数据转成 IDoc 类型，SAP 后台异步处理。缺点是失败消息反馈有延迟，要靠监控程序扫 IDoc 状态。新项目如果节奏不是特别激进，我一般会先按同步 BAPI 做，把数据量测出来以后再去评估要不要改 IDoc。同步接口的排查链路短，出了问题在 SE37 里单测即可，迭代效率高。

3.2 ABAP 侧调用 BAPI 创建 BOM 的最小骨架

以下是一段可以直接塞进 ABAP 报告或函数里的代码骨架，作用是用 PLM 传入的数据创建一个单层物料 BOM。注意这里省略了物料号转换和权限检查，聚焦 BAPI 调用本身。

DATA: lv_matnr   TYPE matnr,
      lv_werks   TYPE werks,
      lv_bom     TYPE capid,
      ls_header  TYPE bapi_bom_header,
      ls_item    TYPE bapi_bom_item,
      lt_items   TYPE TABLE OF bapi_bom_item,
      lt_return  TYPE TABLE OF bapiret2.

lv_matnr = '000000000000100200'.
lv_werks = '1000'.

ls_header-bom_usage     = '1'.        " 1 = 生产 BOM
ls_header-bom_category  = 'M'.        " M = 物料 BOM
ls_header-base_quantity = 1.          " 基本数量
ls_header-bom_text      = 'PLM 接口创建'.

ls_item-item_number    = '0010'.      " 4 位项目号
ls_item-component      = '000000000000200100'.
ls_item-item_quantity  = 2.0.         " 组件用量
ls_item-item_unit      = 'PCS'.       " 单位
ls_item-item_category  = 'L'.         " L = 库存项目
APPEND ls_item TO lt_items.

CALL FUNCTION 'BAPI_MATERIAL_BOM_CREATE'
  EXPORTING
    material        = lv_matnr
    plant           = lv_werks
    bom_usage       = ls_header-bom_usage
    bom_header      = ls_header
  IMPORTING
    bom             = lv_bom
  TABLES
    bom_item        = lt_items
    return          = lt_return.

IF NOT line_exists( lt_return[ type = 'E' ] ).
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
ELSE.
  CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ENDIF.

这段代码的逻辑是：先组装 BOM 头结构 ls_header ，再组装一条行项目 ls_item ，然后调用 BAPI 创建，最后通过 RETURN 表判断是否有错误。这里最需要注意的是 RETURN 表的 type 字段： E 代表错误， S 代表成功， W 是警告。很多新手只看 BAPI 有没有抛异常，实际上 BAPI 几乎不会抛异常，业务错误全部是通过 RETURN 表带回来的。因此上面代码先 line_exists 检查是否有 type = 'E' ，有就回滚，没有才提交。

参数说明： material 必须传带前导零的内部格式， plant 必须是四位工厂代码， bom_usage 可以和 bom_header 里的 BOM 用途重复，但两者必须一致，否则 BAPI 会报用途冲突。 bom 是导出参数，创建成功后返回 SAP BOM 号，这个值要回写到接口日志，作为后续变更和删除的主键。 base_quantity 默认是 1，如果 PLM 的基本数量不是 1，比如“100 个成品用 3 个组件”，那么这里的数值要和组件用量一致，否则 BOM 展开比例会出错。

3.3 外部系统用 Python + PyRFC 调 BAPI

如果 PLM 系统不是 SAP 生态，外部接口程序常用 Python 或 Java。Python 的 PyRFC 库可以直连 RFC，适合做快速开发和原型验证。示例代码如下：

from pyrfc import Connection

conn = Connection(
    user='SAP_RFC',
    passwd='your_password',
    ashost='sapapp.example.com',
    sysnr='00',
    client='100'
)

bom_item = [{
    'ITEM_NUMBER': '0010',
    'COMPONENT': '000000000000200100',
    'ITEM_QUANTITY': 2.0,
    'ITEM_UNIT': 'PCS',
    'ITEM_CATEGORY': 'L'
}]

res = conn.call(
    'BAPI_MATERIAL_BOM_CREATE',
    material='000000000000100200',
    plant='1000',
    bom_usage='1',
    bom_header={
        'BOM_CATEGORY': 'M',
        'BASE_QUANTITY': 1.0,
        'BOM_TEXT': 'PLM 接口创建'
    },
    bom_item=bom_item
)

returns = res.get('RETURN', [])
errors = [r for r in returns if r.get('TYPE') == 'E']
if errors:
    for e in errors:
        print(e['MESSAGE'])
else:
    print('BOM created: ', res.get('BOM'))

这段代码里， conn.call 的第一个参数是 SAP 函数名，后面的关键字参数对应 BAPI 的导入参数和表格参数。 BOM_HEADER 传字典， BOM_ITEM 传列表，这个结构和 ABAP 里的结构、内表是严格对应的。用 PyRFC 时最容易踩的坑是字典 key 大小写不对，RFC 协议要求字段名必须全大写。比如 bom_header 里的 key 不能写成 Bom_Text ，必须是 BOM_TEXT 。另外， passwd 不要硬编码在代码里，生产环境要从密钥管理服务读取。

3.4 Java 和中间件接入方式

Java 团队一般会用 SAP Java Connector（JCo），调用方式和 PyRFC 类似，只是数据对象变成了 JCoTable 和 JCoStructure 。如果你的公司已经有 SAP PI/PO 或 SAP CPI，中间件会承担报文转换：PLM 发 XML/JSON 到中间件，中间件映射成 BAPI 请求，再调用 SAP。这种情况下，接口程序基本不用写代码，但代价是调试链路变长。我倾向于把字段映射表维护在中间件配置里，一旦 PLM 改名，运维可以直接改映射而不用重新发布程序。

4. 接口校验、错误处理与幂等设计：别让重试带来重复 BOM

BOM 接口上线后，最常接到的问题不是“接口断了”，而是“重跑了一遍，出了两张一摸一样的 BOM”。BAPI 本身不天然幂等，PLM 重发、网络超时、人工重投，都可能让 SAP 里多出重复数据。这一章把校验、提交、幂等、变更一起讲清楚，避免低级事故。

4.1 返回消息先分类再决定 COMMIT 还是 ROLLBACK

前面代码里已经有 RETURN 表的判断逻辑，但生产级接口还需要考虑警告和成功消息都写日志。标准做法是循环读取 RETURN 表，区分 S、W、E、I 四种消息类型。可以用下面的循环，把消息和 BOM 号一起落接口日志表。

DATA: lv_bom_saved  TYPE capid,
      lv_error_flag TYPE flag.

LOOP AT lt_return INTO DATA(ls_return).
  CASE ls_return-type.
    WHEN 'E'.
      lv_error_flag = 'X'.
      " 记录错误消息到日志表
      PERFORM log_to_db USING 'E' ls_return-message.
    WHEN 'S'.
      lv_bom_saved = lv_bom.
    WHEN 'W'.
      " 警告不阻断，但要单独记录
      PERFORM log_to_db USING 'W' ls_return-message.
  ENDCASE.
ENDLOOP.

IF lv_error_flag IS INITIAL.
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
  " 更新映射表状态为成功
ELSE.
  CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ENDIF.

这段代码比第一个例子更严谨，它把警告和成功分开处理。BAPI 返回的 RETURN 表里，一条创建请求可能同时返回多条消息，比如物料主数据缺某个视图是警告，但 BOM 还是创建成功了。这时候如果程序一看到非 E 消息就回滚，反而会把有效成功数据丢弃。所以要明确：只有 E 以及个别必须阻断的 A（中止）消息才回滚，W 和 S 都要继续提交，并在日志里保留现场。

4.2 用外部键和映射表做幂等

要让接口可安全重试，必须引入业务幂等键。PLM 的 BOM ID 通常唯一，比如“PLM_BOM_GUID”，这个值应当在第一次调用时就写入一张映射表。常见映射表结构如下：

接口调用顺序变成：先根据 PLM_BOM_ID 查询映射表，如果已有成功记录，直接返回已有 SAP BOM 号；如果没有，才调用 BAPI，然后写入映射表。写入动作要和 BAPI 的提交放在同一个 SAP LUW 里，否则可能出现 BAPI 提交成功但映射表没写进去，导致重投时再次创建。这一点在 ABAP 中要特别注意：调用 BAPI_TRANSACTION_COMMIT 之前，所有 INSERT/UPDATE 语句都处于同一事务中，提交后一起生效。如果映射表写入失败，BAPI 提交也要回滚，保证两边一致。

4.3 常见错误码、原因和重投原则

说几个我实际遇到过的失败场景，以及对应的排查方向：

重投建议做到“原样重发 + 接口日志修正”。不要在生产环境手工改 BAPI 入参，也不要让运维在函数里临时改逻辑。正确做法是保留原始请求报文，分析失败原因后修正映射规则，再重新推送。错误归集越靠近源头，BOM 数据质量越好。

4.4 变更场景：改 BOM 而不是删了重建

PLM 发起工程变更后，SAP 里已有 BOM 的处理不能一刀切。有些接口实现很粗暴：“先删旧 BOM，再建新 BOM。”这在测试环境没问题，一进生产就炸了——SAP 里 BOM 往往被生产版本、销售 BOM、成本估算引用，直接删除会导致联动报错。常见的可靠方案有两种。第一种是用 BAPI_MATERIAL_BOM_MAINTAIN 去修改已有 BOM 的行项目，适合只是数量或者组件替换的场景。第二种是创建一张新的替代 BOM，按新的有效期启用，并把旧 BOM 的结束日期改为新 BOM 生效日的前一天。第二种在离散制造里更常见，因为历史数据可以被保留，生产订单展开时仍然能找到当时生效的 BOM 版本。无论选哪种，都要在接口文档里写明“变更策略”，而不是让 BAPI 开发自己拍脑袋决定。

5. 文件名里的 V1.0 和 PP02：接口文档、版本与上线检查清单

标题里的文件名本身就很有信息量： SG_PP_FS_PP02 PLM 与 SAP BOM 接口_PP02_V1.0_20180903.doc 。这类 ERP 系统信息化资料的命名不是随便起的，它通常包含了项目代号、模块、类型、接口编号、版本号和定稿日期。很多甲方上线后才发现，接口代码和文档版本对不上，问题单只能靠人工去猜。

5.1 从文件名读出接口上下文

SG 在常见命名规则里是项目或系统标识， PP 代表生产模块， FS 是功能规格说明， PP02 是接口流程编号， V1.0 是文档版本， 20180903 是日期。这意味着接口从设计之初就应当有清晰的版本基线。当 SAP 侧代码经过传输请求（Transport Request）发布到生产后，接口文档版本必须和代码版本绑定。否则换个顾问接手，看到 V1.0 文档里的字段映射表和实际代码里的不同，排查方向很容易跑偏。

5.2 接口文档里必须出现的几张表

我经手的 BOM 接口项目里，文档做得好的都有一个共识：至少包含字段映射表、错误码表、接口日志表、权限对照表。字段映射表前面已经给过，错误码表要细化到“SAP 返回消息号 + 原因 + 处理责任方”。接口日志表设计要包含请求报文、响应报文、BOM 号、处理状态、处理耗时、重试次数。权限对照表则是记录 RFC 用户或者 ABAP 程序里调用的授权对象，方便审计。这四张表缺了任何一张，上线排障都会像大海捞针。

5.3 上线前的检查清单

下面这张检查清单适用于大多数 PLM 与 SAP BOM 接口的首轮上线，也可以用于半年后的例行复核：

• 物料主数据：所有 BOM 涉及的父件和组件在 MARA、MARC 中都已经存在。
• 配置：BOM 用途、状态、项目类别、替代组在相关配置表里维护正确。
• 权限：RFC 用户和对话用户都具备 BOM 创建、修改、删除的授权。
• 单条测试：用 SE37 手工调一次 BAPI，检查 RETURN 表类型。
• 正反校验：用 CS03 和 CS12 查看 BOM 结构，确认层级和数量。
• 业务验证：跑一次 MRP，确认组件需求能正常展开。
• 回滚方案：准备好停用或删除 BOM 的脚本，并对 BOM 号做好登记。

上线前还可以用一个简单 ABAP 报表核对当天同步的 BOM 清单。下面这段代码从映射表里读数据，快速列出当天写入的 BOM 信息，用于和 PLM 侧导出的清单做对账。

SELECT plm_bom_id, sap_matnr, plant, bom_number, status
  FROM zplm_bom_map
  INTO TABLE @DATA(lt_map)
  WHERE create_date = @lv_date.

LOOP AT lt_map INTO DATA(ls_map).
  WRITE: / 'PLM:' , ls_map-plm_bom_id,
           'SAP:',  ls_map-sap_matnr,
           'BOM:',  ls_map-bom_number,
           '状态:', ls_map-status.
ENDLOOP.

这段逻辑很直接：从映射表按日期过滤，输出接口核心字段。它的价值在于给运维一个“30 秒确认当天是否全部同步成功”的入口，而不是去数据库里写临时 SQL。很多项目把这段逻辑放到一个自定义事务码里，再配一个定时后台作业，每天自动输出异常清单，比出了问题再排查高效得多。

5.4 接口版本和传输请求怎么绑定

SAP 侧每次改 BAPI 调用逻辑，都会生成一个新的传输请求。我建议在接口文档的修订记录里直接写上传输入、请求号、变更内容。这样一旦生产环境出现数据偏差，可以直接用 SE03 查询请求对应的对象列表，确认这次改动的影响范围。PLM 侧如果改了 BOM 导出的字段，也要同步更新接口文档，而不是只改一个 Excel 模板就上线。版本管理最忌“只改代码不改文档”，这类文档本身是 ERP 系统信息化资料的组成部分，缺失后审计和灾备都会出现断层。

6. SAP BOM 接口上线后的三个验证技巧

接口上线不代表结束，日常验证才是长期稳定运行的关键。这里分享三个我常用的验证动作，不复杂，但能快速定位多数 BOM 同步问题。

6.1 用 CS03 和 CS12 做反向核对

在 SAP GUI 里输入事务代码 CS03，输入父件物料号、工厂和 BOM 用途，就能看到接口写入的 BOM 头和行项目。如果只想看结构，用 CS12 做多层展开，可以一次性看到整棵 BOM 树。建议在接口测试文档里把这两个事务代码列为必做动作，每次接口改版后都按“新建 BOM → CS03 核对 → CS12 展开 → 检查数量和单位”的顺序走一遍。这一步能过滤掉大约 60% 的低级错误。

6.2 用 MD04 确认 BOM 参与 MRP

BOM 创建成功不代表 MRP 会认。在 SAP 里输入 MD04，输入成品物料，查看 MRP 需求明细。如果组件需求能从库存/需求清单中带出，说明 BOM 已经参与了 MRP 展开；如果只有成品需求没有组件需求，就要检查 BOM 用途是否真的是 1、有效期是否覆盖当前日期，以及生产版本是否已维护好对应的 BOM。类似地，MD07 可以汇总查看多个物料的覆盖情况，适合批量核对。这一步是业务侧最关心的验证，因为 BOM 不参与 MRP，直接下游缺料时会看不到原因。

6.3 把验证固化到接口回归用例

最后，建议把上述 CS03、CS12、MD04 三个事务代码对应的操作，固化成接口回归用例的一部分。具体做法是维护一张场景表，每条场景写上“PLM 下发数据样例—预期 SAP BOM 结果—回归命令”。比如一条场景是“PLM 新增一个子件，数量 2，单位 PCS”，回归命令就是“执行接口——CS03查看——MD04确认”。每次代码发布前跑一遍这组场景，比上线后人工翻 BOM 省力得多。更进一步，可以用 Python 脚本调 SAP RFC 里的 BOM 展开函数，让脚本自动比对 PLM 快照和 SAP BOM 展开结果，输出差异行。把 MD04、CS12 和这段 diff 脚本写进变更单里，作为 BOM 接口每次改动的必做回归项，能最大限度避免“改了一个字段，带崩整棵 BOM”的回归事故。

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