华为MetaERP Oracle EBS 与 Fusion OM 销售模块关键业务对象按 O2C（Order to Cash）链路，可把关键业务对象归为五类。两代产品的对象语义相通，但承载方式不同：

Oracle EBS 与 Fusion OM 销售模块关键业务对象

按 O2C（Order to Cash）链路，可把关键业务对象归为五类。两代产品的对象语义相通，但承载方式不同：EBS 多用共用物理表 + 类型字段区分，Fusion 则拆成独立的逻辑业务对象并由服务暴露。

一、订单交易主对象（核心）

业务对象

EBS 承载

Fusion 承载

基数关系

最关键的差异：Fusion 把"客户意图"与"如何执行"分开——订单行保留客户原意，履约行记录执行方式，编排流程决定"何时、由谁、做哪些步骤"。因此 EBS 的 LINE_TYPE_ID=RETURN 一行不能机械映射为 Fusion 的一张独立 RETURN_ORDER_LINE 表。

二、定价与促销对象

• 价目表（Price List）：EBS 为 QP_LIST_HEADERS_B/_TL + QP_LIST_LINES；Fusion 由 Pricing 服务管理。
• 定价公式 / 修饰符（Modifier）、促销（Promotion）、协议价（Agreement / GSA）。
• 价格调整（Price Adjustment）：EBS 存 OE_PRICE_ADJUSTMENTS（混合头级/行级粒度，需按应用标志过滤）；Fusion 为订单行下的子对象，经 OSO 返回。
• 价格瀑布（Price Waterfall）：列表价 → 折扣 → 附加费 → 手工价 → 净价，是报价与毛利分析的事实来源。
• 运费（Freight）：EBS 常为特殊行类型；Fusion 由运输与履约对象协同。

三、履约与执行对象（OM 的后向链条）

环节

EBS 对象/表

Fusion 对象

基数要点：EBS 中一个订单行可对应多个 WSH_DELIVERY_DETAILS、多个 shipment、多个 MTL_MATERIAL_TRANSACTIONS；Fusion 中一个订单行默认 1 个履约行，拆分后 1 ∶ N，多个履约行回指同一订单行。

四、控制与例外对象

• 冻结（Hold）：OE_ORDER_HOLDS_ALL，可分订单级 / 行级，含冻结来源（OE_HOLD_SOURCES_ALL）、释放记录、生效标志。Fusion 为 Hold 子对象。
• 信用检查（Credit Check）：与 AR 信用额度、冻结联动。
• 审批 / 工作流：EBS 为 Workflow（推进 FLOW_STATUS_CODE）；Fusion 为 BPM / 编排流程定义与流程实例。
• 变更单（Change Order）：EBS 多为 UPDATE + 工作流；Fusion 为显式对象，是否可改由 OSO 的 ChangeOrderAllowed / ChangeOrderAttributeAllowed 按当前履约状态判定——同一行能否改数量、客户、仓库、日期，取决于执行阶段。
• 取消 / 关闭 / 部分取消：表现为状态、取消数量、工作流与接口处理，非物理删除。

五、主数据对象（被引用，非 OM 私有）

• 客户：EBS TCA —— HZ_PARTIES（当事方）、HZ_CUST_ACCOUNTS（客户账户）、HZ_CUST_ACCT_SITES_ALL（账户地点）、HZ_CUST_SITE_USES_ALL（地点用途：ship-to / bill-to / deliver-to）；Fusion 为 TCA 服务化对象。
• 物料 / 库存组织 / 仓库 / 子库 / 批次 / 序列号：INV / Product Hub。
• 订单类型 / 订单来源 / 支付方式 / 运输方式 / 币种 / 税率：EBS 为 OE_TRANSACTION_TYPES_ALL、OE_ORDER_SOURCES 等。
• 组织与多组织控制：EBS 为 _ALL 表 + ORG_ID + VPD/MOAC；Fusion 为租户 + 业务单元（BU）安全上下文。

六、两代产品的对象建模差异（一句话总结）

• EBS：数据库即语义载体。ORDER_HEADER(1) — ORDER_LINE(N) — {SCHEDULE, PRICE_ADJUSTMENT, HOLD}(0..N) — WSH/MTL/RA。标准销售、RMA、服务、运费、配置子行共用头行表，靠类型 + 流程 + 状态区分。SQL 直观，但履约粒度、退货生命周期、跨仓拆分容易依赖状态组合。
• Fusion：服务化业务对象。源订单 → 销售订单 → 订单行 → 履约行 → 编排流程​ 双树映射。订单捕获与履约执行解耦，拆分、退货、重编排更灵活；但 DOO_HEADERS_ALL、DOO_LINES_ALL、DOO_FULFILL_LINES_ALL 等属内部实现表，不保证跨季度稳定，生产应以 salesOrdersForOrderHub REST、OSO SOAP、FBDI、OTBI 主题域为入口。

口径：EBS R12（参考 12.2.2 ETRM），Fusion 26C 公开 Help Center，信息截止 2026-10-04。具体环境的 RMA、调度、OTBI 主题域名与 FBDI 模板列，须以本机 ETRM / MOS / Help Center 复核。

示例一：订单头 ↔ 订单行（唯一数据库级外键）

OE_ORDER_HEADERS_ALL(1) — OE_ORDER_LINES_ALL(N)，通过 HEADER_ID 关联。订单行是事实粒度，报表事实键为 HEADER_ID+LINE_ID；配置订单中 LINE_ID = TOP_MODEL_LINE_ID 形成自连接父子行。

示例二：订单行 ↔ 价格调整 / 冻结（0..N 可选子实体）

OE_PRICE_ADJUSTMENTS、OE_ORDER_HOLDS_ALL 都是混合粒度——LINE_ID 非空为行级，为空为头级。LINE_ID IS NULL 不是脏数据，聚合时必须分别处理头级与行级，否则金额翻倍。

示例三：订单行 ↔ 发运 ↔ 库存（跨模块，应用级关联）

OE_ORDER_LINES_ALL → WSH_DELIVERY_DETAILS → WSH_DELIVERY_ASSIGNMENTS → WSH_NEW_DELIVERIES；预留走 MTL_RESERVATIONS，过账走 MTL_MATERIAL_TRANSACTIONS。关联键是 SOURCE_HEADER_ID / SOURCE_LINE_ID，不是数据库外键。一个订单行可对应多个发运明细、多个 shipment、多个库存事务，因此"已发运数量"必须按事务类型+数量符号聚合。

示例四：订单行 ↔ 应收开票（O2C 收口）

OM 行 → RA_INTERFACE_LINES_ALL（临时接口表，勿报表化）→ RA_CUSTOMER_TRX_ALL + RA_CUSTOMER_TRX_LINES_ALL。收入确认时点 = 发票行过账时点。

示例五：Fusion 双树 ER（关键差异）

源订单(1)→源订单行(N) →（提交转换）→ 销售订单(1)→销售订单行(N) →（编排）履约行(1:1 默认，拆分后 1:N) → 编排流程实例(N:1) → 流程定义；退货由退货履约行表达。这些都是逻辑业务对象（OSO/REST 返回），非物理表名；DOO_* 禁止作为生产契约。

最易踩的坑：LEFT JOIN 多张 0..N 子表后直接 SUM → 笛卡尔放大金额翻倍；把 EBS LINE_TYPE_ID='RETURN' 映射成 Fusion 独立 RMA 表 → 语义错误。正确顺序是先按 LINE_ID 聚合子表再去 JOIN。

示例 ① EBS 头—行（主外键） ② 价格调整与冻结 ③ 发运与库存（跨模块） ④ 开票与收入 ⑤ Fusion 双树 ER ⑥ EBS 完整 ER ⑦ 反模式与校验

示例一：EBS 订单头 ↔ 订单行（最稳定的主外键关系）

OE_ORDER_HEADERS_ALL 是主表（父），OE_ORDER_LINES_ALL 是子表（事实表）。ETRM 明确：LINE_ID 为系统生成的行标识，HEADER_ID 是指向订单头表的外键。基数 1 ∶ N（一个头通常对应多行，极少为 1）。

OE_ORDER_HEADERS_ALL（主表）PK HEADER_IDORDER_NUMBERORG_IDORDER_TYPE_IDSOLD_TO_ORG_IDOE_ORDER_LINES_ALL（子表 / 事实粒度）PK LINE_IDFK HEADER_ID ──┐INVENTORY_ITEM_IDORDERED_QUANTITYSHIPPED_QUANTITYUNIT_SELLING_PRICETOP_MODEL_LINE_ID（配置父子自连接）1N关系：数据库级外键（ETRM 已核验）。HEADER_ID+LINE_ID 构成报表事实键。

— 伪 SQL：头行 JOIN（EBS 标准写法，含多组织过滤）
SELECT h.order_number, h.header_id,
l.line_id, l.line_number,
l.ordered_quantity, l.shipped_quantity, l.unit_selling_price,
l.ordered_quantity * l.unit_selling_price AS extended_price
FROM oe_order_headers_all h
JOIN oe_order_lines_all l ON l.header_id = h.header_id — 主外键
WHERE h.org_id = :p_org_id
AND h.booked_flag = 'Y'
AND l.cancelled_flag = 'N';

要点：① 订单行是唯一适合做数量、收入、交付分析粒度的事实表；② 头表既承载"合同/订单身份"，也承载默认的收货、开票、运输与组织控制，行可覆盖默认值（"头默认、行覆盖"分层）；③ 配置订单中 LINE_ID = TOP_MODEL_LINE_ID 形成自连接父子行。

示例二：订单行 ↔ 价格调整 / 冻结（0..N 可选子实体）

OE_PRICE_ADJUSTMENTS 与 OE_ORDER_HOLDS_ALL 都是订单行的子表，但基数是 0..N——不能假定每个订单行都存在。且两者都是混合粒度：既可有头级记录（LINE_ID IS NULL），也可有行级记录（LINE_ID 非空）。

OE_ORDER_LINES_ALLPK LINE_IDFK HEADER_ID（同时是配置父行时 TOP_MODEL_LINE_ID = 自身 LINE_ID）OE_PRICE_ADJUSTMENTSPK PRICE_ADJUSTMENT_IDFK HEADER_ID （头级调整时 LINE_ID 为空）FK LINE_ID （行级调整）LIST_LINE_ID, ADJUSTMENT_AMOUNT, ADJUSTMENT_TYPE0..NOE_ORDER_HOLDS_ALLPK ORDER_HOLD_IDFK HOLD_SOURCE_ID → OE_HOLD_SOURCES_ALLFK HOLD_RELEASE_ID （释放记录）FK HEADER_ID / LINE_ID （可为空=头级冻结）RELEASED_FLAG, HOLD_UNTIL_DATE0..N⚠ 报表聚合时必须分别聚合"头级"与"行级"调整/冻结，LINE_ID IS NULL 不是脏数据。 ⚠ 价格调整记录"价格瀑布"：列表价 − 折扣 ± 附加费 − 手工价 = 净价，是毛利分析的事实源。

— 伪 SQL：订单行 + 价格瀑布 + 冻结（注意混合粒度）
SELECT l.line_id,
SUM(CASE WHEN pa.line_id IS NOT NULL THEN pa.adjustment_amount ELSE 0 END) line_adj,
SUM(CASE WHEN pa.line_id IS NULL THEN pa.adjustment_amount ELSE 0 END) header_adj,
COUNT(DISTINCT oh.order_hold_id) active_holds
FROM oe_order_lines_all l
LEFT JOIN oe_price_adjustments pa ON pa.header_id = l.header_id
AND (pa.line_id = l.line_id OR pa.line_id IS NULL)
LEFT JOIN oe_order_holds_all oh ON oh.header_id = l.header_id
AND (oh.line_id = l.line_id OR oh.line_id IS NULL)
AND NVL(oh.released_flag,'N') = 'N'
WHERE l.header_id = :p_header_id
GROUP BY l.line_id;

示例三：订单行 ↔ 发运 ↔ 库存（跨模块，应用级关联，非外键）

OM 的后向执行链：OE_ORDER_LINES_ALL → WSH_DELIVERY_DETAILS（发运明细）→ WSH_DELIVERY_ASSIGNMENTS → WSH_NEW_DELIVERIES（交货/行程）；预留走 MTL_RESERVATIONS，实际过账走 MTL_MATERIAL_TRANSACTIONS。关键：这些都不是数据库外键，而是应用级连接键。

OE_ORDER_LINES_ALLPK LINE_IDFK HEADER_IDWSH_DELIVERY_DETAILSPK DELIVERY_DETAIL_IDAK SOURCE_HEADER_ID ┐AK SOURCE_LINE_ID ┘ 应用级连接键WSH_DELIVERY_ASSIGNMENTSPK DELIVERY_ASSIGNMENT_IDFK DELIVERY_DETAIL_IDWSH_NEW_DELIVERIESPK DELIVERY_IDMTL_RESERVATIONSPK RESERVATION_IDINVENTORY_ITEM_ID, SUBINVENTORY, LOT, SERIALMTL_MATERIAL_TRANSACTIONSPK TRANSACTION_IDTRANSACTION_TYPE_ID, TRANSACTION_QUANTITY10..NN1N10..11N关联键：WSH_DELIVERY_DETAILS.SOURCE_HEADER_ID = OE_ORDER_LINES_ALL.HEADER_ID 且 SOURCE_LINE_ID = LINE_ID。虚线为应用级/高置信实现关联，须本机 ETRM 复核。

— 伪 SQL：订单行 → 发运明细 → 交货，还原"已发运、未发运、分批发运"
SELECT l.line_id, l.ordered_quantity, l.shipped_quantity,
NVL(dd.picked_quantity,0) picked_qty,
NVL(dd.shipped_quantity,0) delivery_shipped_qty,
nd.delivery_id, nd.delivery_name, nd.status AS delivery_status
FROM oe_order_lines_all l
LEFT JOIN wsh_delivery_details dd ON dd.source_header_id = l.header_id
AND dd.source_line_id = l.line_id
LEFT JOIN wsh_delivery_assignments da ON da.delivery_detail_id = dd.delivery_detail_id
LEFT JOIN wsh_new_deliveries nd ON nd.delivery_id = da.delivery_id
WHERE l.header_id = :p_header_id;

为什么不能只 JOIN 一张"发货表"？ 一个订单行可能对应：① 多个 WSH_DELIVERY_DETAILS（分批发运）；② 多个 shipment / 行程停点；③ 多个 MTL_MATERIAL_TRANSACTIONS（退货还会产生负数量事务）。因此"已发运数量"必须按事务类型 + 数量符号聚合，而非简单 COUNT。

示例四：订单行 ↔ 应收开票（O2C 收口）

开票是跨模块链路：OM 行 → RA_INTERFACE_LINES_ALL（应收接口行，临时）→ RA_CUSTOMER_TRX_ALL（发票头）+ RA_CUSTOMER_TRX_LINES_ALL（发票行）。接口表不应作为长期报表事实表。

OE_ORDER_LINES_ALLPK LINE_IDFK HEADER_IDRA_INTERFACE_LINES_ALLINTERFACE_LINE_ID（临时，勿报表化）FK ORDER_HEADER_ID / ORDER_LINE_IDRA_CUSTOMER_TRX_ALLPK CUSTOMER_TRX_IDTRX_NUMBER, TRX_DATEFK BILL_TO_CUSTOMER_IDCT_LINESPK LINE_IDFK HEADER_ID10..NN11N收入确认时点 = 发票行过账时点。比较"订单行金额 vs 发票行金额"可发现未开票、部分开票、跨期收入。

示例五：Fusion OM 双树 ER（源订单 → 订单行 → 履约行 → 编排流程）

Fusion 不存在"一行对应一张发货表"的全局固定映射。订单提交后被转换为销售订单，再被编排为履约行；拆分后 1 个订单行 → N 个履约行，多个履约行回指同一订单行。

SOURCE_SALES_ORDERsrc_txn_id, src_txn_number, revision, systemSOURCE_ORDER_LINEsource_order_id, item, qtySALES_ORDERorder_id, order_number, versionSALES_ORDER_LINEorder_id, line_id, qty, unit_priceFULFILLMENT_LINEfulfill_line_id, parent_line_idsplit_from_fulfill_line_idstatus, promised_dateRETURN_FULFILL_LINEreturn_of_fulfill_idreference_invoice / orderORCH_PROCESS_INSTANCEinstance_id, fulfill_line_idtask_status, schedule_dateORCH_PROCESS_DEFprocess_code（元数据）versionCHANGE_ORDER / HISTORYchange_order_id, order_idchanged_attrs, prior/new value1:N提交/转换形成1:1 默认N:11:N（退货）N:1重编排以上都是逻辑业务对象（OSO/REST 返回），非物理表名。内部 DOO_HEADERS_ALL / DOO_LINES_ALL / DOO_FULFILL_LINES_ALL 禁止作为生产契约。

示例六：EBS 销售模块完整 ER（Mermaid 源码，可直接渲染）

%% EBS OM 主表—子表 ER（业务逻辑关系，非全部为数据库外键）
erDiagram
HZ_CUST_ACCOUNTS ||–o{ OE_ORDER_HEADERS_ALL : "sold_to_org_id"
OE_TRANSACTION_TYPES_ALL ||–o{ OE_ORDER_HEADERS_ALL : "order_type_id"
QP_LIST_HEADERS_B ||–o{ OE_ORDER_HEADERS_ALL : "price_list_id"
OE_ORDER_HEADERS_ALL ||–o{ OE_ORDER_LINES_ALL : "header_id (1:N, 数据库外键)"
OE_ORDER_LINES_ALL ||–o{ OE_ORDER_SCHEDULES_ALL : "header_id,line_id (0..N)"
OE_ORDER_LINES_ALL ||–o{ OE_PRICE_ADJUSTMENTS : "header_id,line_id (0..N, 混合粒度)"
OE_ORDER_LINES_ALL ||–o{ OE_ORDER_HOLDS_ALL : "header_id,line_id (0..N)"
OE_ORDER_LINES_ALL ||–o{ WSH_DELIVERY_DETAILS : "source_header_id,source_line_id (应用级)"
WSH_DELIVERY_DETAILS ||–o{ WSH_DELIVERY_ASSIGNMENTS : "delivery_detail_id"
WSH_DELIVERY_ASSIGNMENTS }o–|| WSH_NEW_DELIVERIES : "delivery_id"
OE_ORDER_LINES_ALL ||–o{ MTL_RESERVATIONS : "reservation_id / demand (高置信实现关联)"
OE_ORDER_LINES_ALL ||–o{ MTL_MATERIAL_TRANSACTIONS : "source (应用级)"
OE_ORDER_LINES_ALL ||–o{ RA_INTERFACE_LINES_ALL : "order_header_id,order_line_id"
RA_INTERFACE_LINES_ALL }o–|| RA_CUSTOMER_TRX_ALL : "interface_to_trx"
OE_HOLD_SOURCES_ALL ||–o{ OE_ORDER_HOLDS_ALL : "hold_source_id"
OE_ORDER_LINES_ALL }o–|| OE_ORDER_LINES_ALL : "top_model_line_id (配置父子自连接)"

EBS 主表 / 子表速查

七、常见反模式与自查清单

建模三原则：① 粒度——EBS 以 HEADER_ID+LINE_ID 为事实键，Fusion 必须引入 FULFILL_LINE_ID；② 业务键——跨系统用 ORDER_SOURCE_ID + ORIG_SYS_*（EBS）与 SourceTransactionIdentifier/Number/Revision/System（Fusion）做幂等关联；③ 时间——承诺日期变化、拆分时点、退货冲销应由 change order / 流程实例 / 状态历史独立表承载，不能只留"当前事实表"。