华为MetaERP Oracle EBS R12 OM（销售订单管理）VS Fusion Cloud DOO 分布式订单编排全维度拆解：业务对象→逻辑实体→物理实体（后台表）→核心程序 + 实操示例

Oracle EBS R12 OM（销售订单管理）VS Fusion Cloud DOO 分布式订单编排

全维度拆解：业务对象→逻辑实体→物理实体（后台表）→核心程序 + 实操示例

前置概念定义

第一部分：Oracle EBS R12 OM 销售模块完整拆解

一、整体架构：单体紧耦合架构

EBS OM 基于OU 运营单元数据隔离（ORG_ID），O2C 订单到收款全链路：订单录入→订单 BOOK 登记→可用性检查 ATP→信贷审核→挑库发运 WSH→自动开票 AutoInvoice→AR 收款记账。

1.1 顶层业务对象 BO

1. 销售订单主业务对象
2. 客户主数据对象
3. 定价与折扣业务对象
4. 订单履行（发运 / 库存挑库）对象
5. 开票应收结算对象
6. 订单变更 / 取消 / 暂停业务对象

1.2 逐层拆解：业务对象→逻辑实体→物理表

业务对象 1：标准销售订单

（1）逻辑实体拆分

1. 订单头逻辑实体：订单基础信息、客户收付方、订单类型、状态、付款条款、全局控制参数
2. 订单行逻辑实体：商品、数量、单价、交付日期、库存组织、行状态、定价结果
3. 订单分配逻辑实体：会计科目弹性域、成本归集维度、利润中心分摊
4. 订单附加属性逻辑实体：备注、属性字段、促销备注、外部单号、溯源信息

（2）对应物理实体（核心数据表）

① 订单头物理表：OE_ORDER_HEADERS_ALL（主键：HEADER_ID）

核心关键字段：

sql

ORDER_NUMBER -- 外部订单号 FLOW_STATUS_CODE -- 订单状态：ENTER录入/BOOKED已登记/CANCELLED取消/CLOSED关闭 SOLD_TO_ORG_ID -- 付款客户账户 SHIP_TO_ORG_ID -- 收货地点 BILL_TO_ORG_ID -- 开票地点 ORDER_TYPE_ID -- 订单类型（标准订单/寄售/退货RMA） TERM_ID -- 付款账期 ORG_ID -- OU运营单元隔离 PRICE_LIST_ID -- 绑定价目表ID

② 订单行物理表：OE_ORDER_LINES_ALL（主键 LINE_ID，关联 HEADER_ID）

sql

INVENTORY_ITEM_ID -- 物料ID关联MTL_SYSTEM_ITEMS_B ORDERED_QUANTITY -- 订购数量 PRICE_LIST_UNIT_PRICE -- 定价单价 FLOW_STATUS_CODE -- 行级状态 SHIP_FROM_ORG_ID -- 发货库存组织 LINE_TYPE_ID -- 行类型：实物商品/服务/费用

③ 订单会计分配：OE_ORDER_DISTRIBUTIONS_ALL

存储订单行对应的会计科目弹性域，确定销售收入入账科目。

④ 订单附加属性：OE_ORDER_HEADERS_EXT/OE_ORDER_LINES_EXT

EBS 弹性扩展字段物理表。

业务对象 2：客户主数据（全局共享）

逻辑实体：客户主体、客户账户、业务地点（收票 / 收货）

物理实体表：

1. HZ_PARTIES：法人主体（全局 party）
2. HZ_CUST_ACCOUNTS_ALL：客户账户
3. HZ_CUST_SITE_USES_ALL：地点用途（SHIP_TO/BILL_TO/SOLD_TO）

业务对象 3：定价与折扣

逻辑实体：价目表、定价公式、行级折扣、促销调整

物理表：

QP_PRICE_LISTS_ALL、QP_PRICE_LIST_LINES_ALL、QP_MODIFIERS_ALL（折扣调价）

业务对象 4：订单履行（发运 WSH 联动）

逻辑实体：挑库申请、交货单、发运明细、物流装运

物理表：

1. WSH_DELIVERIES_ALL：交货单头
2. WSH_DELIVERY_DETAILS：交货明细（绑定 OM 订单行）
3. MTL_TXN_REQUEST_HEADERS/LINES：库存挑库申请
4. MTL_MATERIAL_TRANSACTIONS：库存发货扣减事务

业务对象 5：自动开票对接 AR 应收

逻辑实体：开票接口数据、应收发票

物理接口表：RA_INTERFACE_LINES_ALL；正式发票表：RA_CUSTOMER_TRX_ALL

1.3 EBS OM 核心后台程序（并发请求 / PLSQL/API）

1）订单核心业务程序

1. Order Import 订单导入并发程序接口表：OE_HEADERS_INTERFACE_ALL、OE_LINES_INTERFACE_ALL作用：外部系统批量导入销售订单，标准集成入口。
2. Book Order（订单登记）标准 API：OE_ORDER_PUB.PROCESS_ORDERPLSQL 标准 API，完成订单 BOOK，锁定价目、锁定库存 ATP、触发信贷校验、推进工作流。
3. 信贷审核工作流：Order Credit Check Workflow后台异步工作流，校验客户信用额度，拦截超信用订单。

2）履约调度程序

1. Pick Release 挑库发放并发程序：生成挑库单，锁定库存
2. Auto Pick Confirm 自动确认挑库
3. Auto Pack/Auto Ship Confirm 自动装箱 + 自动发运确认

3）财务结算程序

AutoInvoice 自动开票主程序：读取 OM 推送至 AR 接口表，生成正式应收发票，O2C 闭环关键程序。

1.4 EBS 实操 SQL 示例

示例 1：查询已登记有效销售订单 + 客户收货地址

sql

SELECT oh.order_number, oh.flow_status_code order_status, hp.party_name sold_customer, hsu.location ship_to_address FROM oe_order_headers_all oh JOIN hz_cust_site_uses_all hsu ON oh.ship_to_org_id = hsu.site_use_id JOIN hz_cust_accounts hca ON hsu.cust_account_id = hca.cust_account_id JOIN hz_parties hp ON hca.party_id = hp.party_id WHERE oh.flow_status_code = 'BOOKED' AND oh.org_id = 82; -- 指定OU

示例 2：API 简易调用创建订单（PLSQL 伪代码）

plsql

DECLARE l_header_rec oe_order_pub.header_rec_type; l_line_tbl oe_order_pub.line_tbl_type; BEGIN l_header_rec.order_number := 'TEST2026080801'; l_header_rec.sold_to_org_id := 10001; l_line_tbl(1).inventory_item_id := 50001; l_line_tbl(1).ordered_quantity := 10; oe_order_pub.process_order( p_api_version => 1.0, p_header_rec => l_header_rec, p_line_tbl => l_line_tbl ); COMMIT; END; /

第二部分：Oracle Fusion Cloud DOO（Distributed Order Orchestration）分布式订单编排

2.1 架构：云原生 SOA 微服务化

Fusion 销售订单模块全称DOO 分布式订单编排，基于BU 业务单元隔离（替代 EBS 的 OU），解耦订单录入、定价、履约、开票、物流，全链路事件驱动，支持多渠道订单统一编排（电商、线下、第三方平台）。 核心特点：逻辑层编排引擎独立，物理数据分层存储，严格解耦订单层、履约层、开票层。

2.2 业务对象 BO

1. 全局编排销售订单
2. 渠道订单源（电商 / 线下 / 第三方）
3. 订单履约履行行（核心拆分层）
4. 智能定价与优惠引擎
5. 跨组织履约调度（内部调拨、外协发货）
6. 开票应收一体化服务
7. 订单变更动态重编排

2.3 业务对象→逻辑实体→物理实体

业务对象：Fusion 销售订单

（1）三层逻辑实体（Fusion 标志性分层设计）

1. 订单头逻辑实体（Order Header LE）：订单基础属性、客户收付方、渠道来源、全局管控
2. 订单业务行逻辑实体（Order Line LE）：商品、定价、基础交付需求
3. 履约执行行逻辑实体（Fulfillment Line LE）：系统拆解后的可执行履约单元（一张订单行可拆多行履约行，分仓发货、分批交付）

关键差异：EBS 只有订单头 + 订单行两层；Fusion 强制三层逻辑拆分，适配分布式履约。

（2）对应物理实体核心数据表（DOO 前缀）

① 订单头物理表：DOO_HEADERS_ALL（主键 HEADER_ID）

sql

ORDER_NUMBER ORDER_SOURCE_SYSTEM -- 订单来源渠道（电商/ERP线下） BILL_TO_CUSTOMER_ID SHIP_TO_LOCATION_ID ORDER_STATUS_CODE BUSINESS_UNIT_ID -- Fusion业务单元（替代EBS ORG_ID） CANCEL_FLAG

② 订单业务行：DOO_LINES_ALL（LINE_ID 关联 HEADER_ID）

存储客户下单原始商品、数量、定价基础数据。

③履约核心表：DOO_FULFILL_LINES_ALL（Fusion 最核心物理表）

由编排引擎自动拆分生成，每一条代表一条独立可执行履约任务：锁定库存、安排发货、触发开票，是连接订单层与库存 WMS、发运模块的桥梁。

配套明细物理表

1. DOO_FULFILL_LINE_DETAILS：履约行序列号、批次、属性明细
2. DOO_BILLING_PLANS：分期开票计划物理表
3. DOO_PRICING_ADJUSTMENTS：折扣、调价记录

配套上下游核心物理表

1. 物料主数据：EGP_SYSTEM_ITEMS_B（替代 EBS MTL_SYSTEM_ITEMS_B）
2. 库存事务：INV_MATERIAL_TXNS
3. Fusion 应收开票接口：RA 系列表结构沿用 EBS 命名，但由云服务自动调用 AutoInvoice 服务

2.4 Fusion DOO 核心后台程序 / 云服务 / API

1）标准导入服务

1. Import Orders 云计划作业接口表：DOO_HEADERS_INTERFACE、DOO_LINES_INTERFACE云定时作业自动拉取外部接口数据生成正式订单。
2. DOO Orchestration Engine 分布式编排引擎（核心后台常驻服务）自动执行：ATP 库存校验、分仓拆分行、信贷检查、分配发货仓库、触发履约流程、订单变更自动重编排，无人工并发请求，事件驱动执行。

2）标准公共 API（REST API 为主，弱化传统 PLSQL）

1. REST API：/fscmRestApi/resources/latest/salesOrders主流集成方式，创建 / 修改 / 取消订单；
2. PLSQL API：DOO_ORDER_PUB兼容传统开发模式。

3）关键云调度作业

1. 库存预留自动调度：Create Reservations
2. 自动发运确认：AutoShipConfirm Cloud Job
3. 自动开票一体化服务：同步推送应收云模块生成发票，无需手动跑 AutoInvoice 并发。

2.5 Fusion 实操 SQL 示例

查询订单 + 履约行关联数据

sql

SELECT dh.order_number, dl.line_number order_line_no, dfl.fulfill_line_id, dfl.status_code fulfill_status, dfl.requested_ship_date FROM doo_headers_all dh JOIN doo_lines_all dl ON dh.header_id = dl.header_id JOIN doo_fulfill_lines_all dfl ON dl.line_id = dfl.order_line_id WHERE dh.order_number = 'FUSION2026080801';

REST API 极简创建订单请求示例

json

{ "OrderNumber": "API20260808", "BillToCustomerId": 100001, "ShipToLocationId": 200002, "BusinessUnitId": 300001, "OrderLines": [ { "ItemNumber": "ITEM001", "OrderedQuantity": 20, "UnitSellingPrice": 99.0 } ] }

第三部分：EBS OM VS Fusion DOO 全维度横向对比

3.1 四层架构对齐对比表

3.2 关键业务逻辑差异

1. 订单拆分机制EBS：一条订单行只能整单发货，分批发货需手动拆行； Fusion：编排引擎自动按库存、仓库、交期拆分多条履约行，自动分批履约。
2. 订单变更处理EBS 变更后需重新跑信贷、ATP 校验； Fusion 变更触发事件流，局部重编排，仅校验受影响履约行，性能更高。
3. 多渠道订单统一管理EBS 需二开整合电商、线下订单； Fusion 原生支持多渠道订单来源标记，统一一套履约体系。

3.3 表映射关系（非一对一映射）

EBS 一张 OE 订单行 ≈ Fusion 一条 DOO 订单行 + N 条 DOO 履约行，不存在严格一一对应字段映射，仅业务含义对齐：

1. OE_ORDER_HEADERS_ALL ↔ DOO_HEADERS_ALL
2. OE_ORDER_LINES_ALL ↔ DOO_LINES_ALL
3. WSH 交货明细 ↔ DOO_FULFILL_LINES_ALL + WSH 云发货表

第四部分：典型 O2C 全链路数据流流转

4.1 EBS 数据流

外部导入→OE 接口表→Order Import→OE 正式订单表→BOOK 登记→信贷校验→挑库 WSH→库存事务 MTL→RA 开票接口→AR 发票→收款核销总账

4.2 Fusion 数据流

第三方渠道→REST / 接口表→云导入作业→DOO_HEADERS/LINES→编排引擎生成 DOO_FULFILL_LINES→库存预留 / 发货→自动推送应收云开票→总账入账

第五部分开发实施落地建议

1. EBS 二次开发：优先使用标准 PLSQL API（OE_ORDER_PUB），禁止直接 DML 修改 OE 底层表，避免状态错乱；
2. Fusion 开发：优先 REST API 与标准云作业，尽量少直写 DOO 物理表，编排引擎会自动维护数据一致性；
3. 数据迁移 EBS→Fusion：先迁移主数据（客户、物料、价目），再迁移历史订单至 DOO 接口表，通过标准导入程序转正，禁止跨库直接同步物理表。