简介：这份PPT资料面向Oracle EBS初学者、实施顾问及企业信息化人员，系统讲解物料清单管理模块的标准功能与操作逻辑，帮助读者快速建立对生产数据管理与工程数据管理的整体认知。资源包内含1个pptx文件，约955KB，以图文幻灯片形式呈现，便于培训讲解与自学查阅。内容围绕BOM与ENG两大模块展开，涵盖物料编码与250多个物料属性的分组逻辑、物品状态与属性控制级别、物料定义与删除步骤，以及标准BOM、计划BOM、模型BOM、选件类BOM等种类划分，并涉及替代物料清单、成批更改、工作日历维护等实用功能。目前已有237人学习，适合需要理解Oracle EBS物料清单体系、梳理Item与BOM维护流程的读者参考使用。
1. 从一份 PPT 说起：Oracle EBS 物料清单到底管的是什么
很多人第一次接触 Oracle EBS 的物料清单，是从一份内部培训 PPT 开始的。PPT 上画着 BOM 层级树、组件行、替代料，看着像那么回事，真到系统里一查，发现BILL_OF_MATERIALS里翻不到自己想要的字段，BOM_COMPONENTS和BOM_STRUCTURES_B的关系也对不上。这篇笔记就围绕 Oracle EBS 物料清单管理系统这个主题，把 BOM 的数据模型、建单流程、API 调用和常见翻车点讲清楚。
Oracle EBS 里的物料清单不是一张表，而是一组互相引用的结构表加业务实体。它解决的核心问题是：一个成品由哪些半成品和原材料构成、每种用多少、在哪个工序消耗、什么时候生效。适合制造、电子装配、流程行业的实施顾问和二次开发人员，也适合刚接手 EBS 制造模块、需要快速定位 BOM 数据的 DBA。下面从数据模型开始，一路走到 API 建单和排查。
2. Oracle EBS 物料清单的数据模型与建单路径
2.1 五张核心表撑起一棵 BOM 树
Oracle EBS 的 BOM 数据不是单表存储，而是通过结构表、组件表、替代料表、工艺路线关联表组合出来的。理解这几张表的关系，是后面所有查询和开发的前提。
| 表名 | 作用 | 关键字段 |
|---|---|---|
BOM_BILL_OF_MATERIALS | BOM 头信息，一个物料可有多个 BOM 版本 | BILL_SEQUENCE_ID、ASSEMBLY_ITEM_ID、ORGANIZATION_ID |
BOM_STRUCTURES_B | 结构关系，定义父子层级 | STRUCTURE_ID、COMPONENT_ITEM_ID、COMPONENT_SEQUENCE_ID |
BOM_COMPONENTS_B | 组件明细，含用量、损耗率 | COMPONENT_SEQUENCE_ID、COMPONENT_QUANTITY |
BOM_SUBSTITUTE_COMPONENTS | 替代料定义 | SUBSTITUTE_ITEM_ID、SUBSTITUTION_SET_ID |
BOM_OPERATION_SEQUENCES | 工序与组件的关联 | OPERATION_SEQ_NUM、DEPARTMENT_ID |
BOM_BILL_OF_MATERIALS存的是 BOM 的头部，一个成品物料在同一个库存组织下可以有多个 BOM 版本，靠ALTERNATE_BOM_DESIGNATOR区分。BOM_STRUCTURES_B是核心，它把父项和子项连起来，COMPONENT_SEQUENCE_ID是组件的唯一序号，后续所有组件级操作都靠它定位。BOM_COMPONENTS_B存用量和损耗，注意COMPONENT_QUANTITY是相对于 BOM 头的基础数量，不是单件用量，算单件用量要除以BASIS_QUANTITY。
查询一棵完整 BOM 树，最直接的方式是用CONNECT BY递归：
-- 查询指定成品在指定组织下的完整 BOM 层级 SELECT LEVEL AS bom_level, LPAD(' ', (LEVEL - 1) * 2) || msi.segment1 AS item_code, msi.description, bc.component_quantity, bc.component_yield_factor FROM bom_structures_b bs, bom_components_b bc, mtl_system_items_b msi WHERE bs.bill_sequence_id = :bill_sequence_id AND bs.component_sequence_id = bc.component_sequence_id AND bc.component_item_id = msi.inventory_item_id AND msi.organization_id = :org_id AND TRUNC(SYSDATE) BETWEEN bs.effective_date AND NVL(bs.disable_date, SYSDATE + 1) START WITH bs.component_item_id = :assembly_item_id CONNECT BY PRIOR bs.component_item_id = bs.assembly_item_id AND PRIOR bs.bill_sequence_id = bs.bill_sequence_id;这段 SQL 的逻辑是：从成品物料出发，沿COMPONENT_ITEM_ID向下递归，每一层都关联组件表和物料主数据表。LEVEL是伪列，表示当前层级深度。effective_date和disable_date的过滤不能省，否则会把历史失效版本也查出来。component_yield_factor是良率因子，实际用量 =component_quantity / component_yield_factor，这个字段在算料时经常被忽略，导致采购数量偏少。
2.2 用 BOM API 建单比直接插表靠谱
直接往BOM_STRUCTURES_B和BOM_COMPONENTS_B插数据，短期能跑通，但会漏掉很多 EBS 内部逻辑：序列号生成、弹性域校验、并发程序触发、物料属性检查。血泪经验是，直接插表建出来的 BOM，在跑 MRP 时经常报“组件无效”或“组织未定义”，排查起来很痛苦。
标准做法是调用BOM_BOM_PUB包里的过程。建一个单层 BOM 的典型调用如下：
DECLARE l_bill_sequence_id NUMBER; l_component_seq_id NUMBER; l_return_status VARCHAR2(10); l_msg_count NUMBER; l_msg_data VARCHAR2(2000); BEGIN -- 第一步：创建 BOM 头 BOM_BOM_PUB.CREATE_BILL( p_api_version => 1.0, p_init_msg_list => FND_API.G_TRUE, p_commit => FND_API.G_FALSE, p_organization_id => 101, p_assembly_item_id => 10001, p_alternate_bom_designator => NULL, p_bom_version => '1', x_bill_sequence_id => l_bill_sequence_id, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data ); IF l_return_status <> FND_API.G_RET_STS_SUCCESS THEN DBMS_OUTPUT.PUT_LINE('建头失败: ' || l_msg_data); RETURN; END IF; -- 第二步：添加组件 BOM_BOM_PUB.CREATE_COMPONENT( p_api_version => 1.0, p_init_msg_list => FND_API.G_TRUE, p_commit => FND_API.G_FALSE, p_bill_sequence_id => l_bill_sequence_id, p_component_item_id => 20001, p_component_quantity => 2, p_component_yield_factor => 1, p_operation_seq_num => 10, x_component_sequence_id => l_component_seq_id, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data ); IF l_return_status = FND_API.G_RET_STS_SUCCESS THEN COMMIT; DBMS_OUTPUT.PUT_LINE('组件创建成功，SEQ_ID=' || l_component_seq_id); ELSE ROLLBACK; DBMS_OUTPUT.PUT_LINE('组件创建失败: ' || l_msg_data); END IF; END; /参数说明：p_organization_id是库存组织 ID，不是法人主体 ID，搞错会报组织无效。p_assembly_item_id是成品物料的内码 ID，不是物料编码。p_component_quantity是基础数量下的用量，如果 BOM 头基础数量是 100，这里填 200，表示做 100 个成品用 200 个组件。p_operation_seq_num关联工序，不填则默认挂在第一个工序。p_commit建议传FALSE，在业务逻辑全部成功后再统一提交，避免部分成功导致数据不一致。
调用 API 前，物料必须已经在MTL_SYSTEM_ITEMS_B里建好，且BOM_ITEM_TYPE属性正确。成品要设成BOM_ITEM_TYPE = 1（模型）或2（成品），组件要设成4（组件）。这个属性在物料属性表单的“物料属性控制”里设置，漏设会导致 API 返回“物料不是有效组件”。
2.3 替代料和工序关联的建法
替代料在 EBS 里通过BOM_SUBSTITUTE_COMPONENTS表管理，一个组件可以挂多个替代料，用SUBSTITUTION_SET_ID分组。建替代料同样走 API：
BEGIN BOM_BOM_PUB.CREATE_SUBSTITUTE( p_api_version => 1.0, p_init_msg_list => FND_API.G_TRUE, p_commit => FND_API.G_FALSE, p_component_sequence_id => :component_seq_id, p_substitute_item_id => 30001, p_substitution_set_id => 1, p_substitute_quantity => 2, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data ); END; /p_substitution_set_id相同的替代料属于同一组，MRP 运算时会在组内按优先级选择。p_substitute_quantity是替代料用量，可以和主料不同。注意替代料物料也必须在同一库存组织下有效，且BOM_ITEM_TYPE为组件。
工序关联通过BOM_OPERATION_SEQUENCES表，建工序时用BOM_OPERATION_SEQUENCES_PUB包。常见做法是先在工艺路线里定义工序，再在 BOM 组件上引用工序号。如果组件不挂工序，默认在第一个工序消耗。对于流程行业，工序和组件的对应关系直接影响成本卷积，挂错工序会导致成本算到错误的部门。
3. 物料清单查询、展开与成本卷积的实操
3.1 用标准展开程序还是自己写递归
EBS 提供了标准 BOM 展开程序，比如“BOM 展开”并发程序和BOM_BOM_EXPLOSION_PUB包。标准程序的好处是自动处理生效日期、替代料、可选组件、包含工艺路线等逻辑。自己写递归 SQL 的好处是灵活，可以按业务需求定制输出字段。
我一般会先看需求：如果只是查一棵树的组件清单，自己写CONNECT BY够用；如果要算多层成本、考虑替代料和损耗，用标准展开程序更稳。标准展开程序的入口是BOM_BOM_EXPLOSION_PUB.EXPLODE_BILL，调用时需要传p_explosion_type，常用值有BOM_EXPLOSION_ALL（全部展开）、BOM_EXPLOSION_CURRENT（当前层）、BOM_EXPLOSION_IMPLODED（反查）。
一个常见的坑是：自己写递归时忘了过滤IMPLEMENTATION_DATE和DISABLE_DATE，把历史版本也查出来，导致组件数量翻倍。标准程序会自动过滤，但需要正确设置p_explosion_date参数。
3.2 成本卷积时组件用量怎么算
成本卷积的核心公式是：组件成本 = 组件单价 × 单件用量 / 良率因子。单件用量 =COMPONENT_QUANTITY / BASIS_QUANTITY。BASIS_QUANTITY在BOM_BILL_OF_MATERIALS表里，默认是 1，但很多实施项目会改成 100 或 1000，方便录入小数用量。
-- 计算指定 BOM 下每个组件的单件用量和扩展成本 SELECT msi.segment1 AS component_code, bc.component_quantity, bom.basis_quantity, bc.component_quantity / bom.basis_quantity AS unit_usage, bc.component_yield_factor, bc.component_quantity / bom.basis_quantity / bc.component_yield_factor AS actual_usage, cst.item_cost, cst.item_cost * bc.component_quantity / bom.basis_quantity / bc.component_yield_factor AS extended_cost FROM bom_structures_b bs, bom_components_b bc, bom_bill_of_materials bom, mtl_system_items_b msi, cst_item_costs cst WHERE bs.bill_sequence_id = bom.bill_sequence_id AND bs.component_sequence_id = bc.component_sequence_id AND bc.component_item_id = msi.inventory_item_id AND msi.organization_id = :org_id AND cst.inventory_item_id = bc.component_item_id AND cst.organization_id = :org_id AND cst.cost_type_id = :cost_type_id AND bs.bill_sequence_id = :bill_sequence_id;cst_item_costs里的ITEM_COST是当前成本类型的单位成本。cost_type_id要选对，标准成本用1，平均成本用2，具体看成本方法。如果组件是采购件，成本来自采购价；如果是自制件，成本来自滚动卷积。注意cst_item_costs里一个物料可能有多个成本类型，不加cost_type_id过滤会返回多行。
3.3 反查某个组件用在了哪些成品上
反查 BOM（Where-Used）是物料清单管理里高频需求。EBS 标准功能里有“BOM 反查”并发程序，但很多顾问需要直接查数据。反查的逻辑是从组件出发，沿BOM_STRUCTURES_B向上递归：
SELECT LEVEL AS up_level, LPAD(' ', (LEVEL - 1) * 2) || msi.segment1 AS parent_item, msi.description FROM bom_structures_b bs, mtl_system_items_b msi WHERE bs.assembly_item_id = msi.inventory_item_id AND msi.organization_id = :org_id AND TRUNC(SYSDATE) BETWEEN bs.effective_date AND NVL(bs.disable_date, SYSDATE + 1) START WITH bs.component_item_id = :component_item_id CONNECT BY PRIOR bs.assembly_item_id = bs.component_item_id AND PRIOR bs.bill_sequence_id = bs.bill_sequence_id;这里START WITH是组件，CONNECT BY PRIOR的方向和展开相反。注意PRIOR bs.bill_sequence_id = bs.bill_sequence_id这个条件不能少，否则跨 BOM 版本递归会串数据。反查结果里可能出现同一个成品多次，因为一个组件可能通过不同路径用在同一成品上，这是正常的，去重看业务需求。
4. 物料清单管理系统的避坑与排查
4.1 现象：BOM 展开报“组件无效”，原因：物料属性没设对
现象是调用展开 API 或跑 MRP 时，报错“组件物料无效”或“组件不在当前组织”。原因通常是组件的BOM_ITEM_TYPE不是4，或者物料没有分配到当前库存组织。解决方法是查MTL_SYSTEM_ITEMS_B的BOM_ITEM_TYPE和ORGANIZATION_ID，确保组件物料在当前组织下存在且类型正确。如果物料是刚建的，可能还需要跑“物料组织分配”并发程序。
4.2 现象：BOM 树查出来层级翻倍，原因：生效日期没过滤
现象是自己写递归 SQL 查 BOM，发现同一组件出现两次，层级也比预期深。原因是BOM_STRUCTURES_B里同一父子关系可能有多个生效版本，没有过滤EFFECTIVE_DATE和DISABLE_DATE。解决方法是在WHERE里加TRUNC(SYSDATE) BETWEEN bs.effective_date AND NVL(bs.disable_date, SYSDATE + 1)。注意DISABLE_DATE可能为空，要用NVL兜底。
4.3 现象：API 建单返回成功但查不到数据，原因：没提交或组织不对
现象是调用BOM_BOM_PUB.CREATE_BILL返回SUCCESS，但查BOM_BILL_OF_MATERIALS查不到。原因通常是p_commit传了FALSE但后续没有COMMIT，或者查询时用的ORGANIZATION_ID和建单时不一致。解决方法是确认建单后执行了COMMIT，并且查询时带上正确的ORGANIZATION_ID。EBS 的 BOM 数据是按库存组织隔离的，跨组织查不到是正常的。
4.4 现象：成本卷积结果为零，原因：成本类型或成本缺失
现象是跑成本卷积，组件扩展成本为零。原因是CST_ITEM_COSTS里没有该组件在对应成本类型下的成本记录，或者COST_TYPE_ID传错。解决方法是先查CST_ITEM_COSTS确认组件有成本，再确认成本类型 ID 和当前成本方法匹配。对于采购件，如果还没采购过，成本可能为零，需要先维护采购价或跑“更新标准成本”。
4.5 现象：替代料在 MRP 里不生效，原因：替代料组或优先级没设
现象是建了替代料，但 MRP 运算时还是只用主料。原因是替代料的SUBSTITUTION_SET_ID没设，或者替代料物料的BOM_ITEM_TYPE不对。解决方法是检查BOM_SUBSTITUTE_COMPONENTS里SUBSTITUTION_SET_ID是否非空，同一组的替代料要设相同的组 ID。另外 MRP 选择替代料还受“替代料优先级”和“计划百分比”影响，这些在物料属性里设置。
5. 用 PL/SQL 批量校验 BOM 数据完整性的一个技巧
实施项目上线前，BOM 数据校验是绕不过去的。手工一条条查太慢，我一般会写一个批量校验脚本，把常见问题一次性扫出来。下面这个脚本检查四类问题：组件物料无效、用量为零、生效日期倒挂、替代料组为空。
-- BOM 数据完整性批量校验脚本 SELECT '组件物料无效' AS issue_type, bs.bill_sequence_id, bs.component_sequence_id, msi.segment1 AS item_code FROM bom_structures_b bs, mtl_system_items_b msi WHERE bs.component_item_id = msi.inventory_item_id(+) AND msi.inventory_item_id IS NULL AND bs.bill_sequence_id = :bill_sequence_id UNION ALL SELECT '组件用量为零', bc.bill_sequence_id, bc.component_sequence_id, NULL FROM bom_components_b bc WHERE NVL(bc.component_quantity, 0) = 0 AND bc.bill_sequence_id = :bill_sequence_id UNION ALL SELECT '生效日期倒挂', bs.bill_sequence_id, bs.component_sequence_id, NULL FROM bom_structures_b bs WHERE bs.disable_date IS NOT NULL AND bs.disable_date < bs.effective_date AND bs.bill_sequence_id = :bill_sequence_id UNION ALL SELECT '替代料组为空', sc.component_sequence_id, sc.substitute_component_sequence_id, NULL FROM bom_substitute_components sc WHERE sc.substitution_set_id IS NULL AND sc.component_sequence_id IN ( SELECT component_sequence_id FROM bom_components_b WHERE bill_sequence_id = :bill_sequence_id );这个脚本用UNION ALL把四类检查合并输出，issue_type标明问题类型，bill_sequence_id和component_sequence_id用于定位。mtl_system_items_b用外连接，msi.inventory_item_id IS NULL表示组件物料在物料主数据里不存在。用量为零的检查用NVL兜底空值。日期倒挂检查disable_date < effective_date。替代料组为空的检查通过子查询限定在当前 BOM 范围内。
跑完这个脚本，把结果导出到 Excel，按issue_type分组处理。组件物料无效的，去物料主数据补建或修正组织分配；用量为零的，确认是数据录入错误还是有意为之；日期倒挂的，修正生效日期；替代料组为空的，补上组 ID。这个脚本我一般会在上线前跑三遍：第一遍全量扫，第二遍修复后复查，第三遍在正式环境跑确认。
参数说明：:bill_sequence_id是 BOM 头 ID，可以从BOM_BILL_OF_MATERIALS查。如果要做全组织校验，把bill_sequence_id条件去掉，加上organization_id过滤。脚本执行时间取决于 BOM 数据量，大组织建议分批跑，避免长时间锁表。
一个习惯：每次接手新项目的 BOM 数据，先跑这个校验脚本，再跑标准“BOM 一致性检查”并发程序，两边结果对比。标准程序报的错更权威，但自己写的脚本能定位到具体行，排查更快。希望帮到你。
本文还有配套的精品资源，点击获取
