Oracle EBS R12 采购模块 vs Oracle Fusion Cloud Procurement
一、整体架构核心差异总览
| 维度 | Oracle EBS R12 采购 (PO) | Oracle Fusion Cloud Procurement |
|---|---|---|
| 部署形态 | 本地 EBS 整套应用、传统客户端 + Form 界面、数据库直连 | 云原生 SaaS、REST API、UI 网页端、PaaS 底层、无法直连底层数据库 |
| 数据架构 | 经典 Oracle 范式化业务表，多弹性域、触发器、工作流 WF 架构 | 云分区式逻辑表、视图封装、大部分底层物理表不对外暴露，只能通过视图 / API 取数 |
| 技术栈 | PL/SQL、Oracle Forms、Concurrent Request、工作流 WF、XML Publisher、AD 补丁 | REST API、SOAP、OTBI 报表、BIP、Fusion HCM 同款工作流、Groovy、ESS 并发程序 |
| 采购核心流程 | 申请→询价→报价→采购订单→接收→检验→入库→开票匹配 (3Way Match) | 流程一致，但审批、供应商管理、合同、支出分析全面云化，内置智能审批、预算实时校验 |
| 扩展方式 | 开发 FORM、并发程序、触发器、客户化表、弹性域 | 自定义扩展仅支持 Groovy 规则、API 集成、OTBI 自定义分析、第三方集成，禁止直改底层数据 |
第一部分：Oracle EBS R12 PO 采购模块后台核心表体系（全链路）
1.1 整体业务数据流链路
员工采购申请 (Requisition) → 审批 → 创建 PO 采购订单 → 供应商发货 → 收货接收 → 质量检验 → 库存入库 → AP 发票三匹配付款
阶段 1：采购申请模块（PO Requisition）
- PO_REQUISITION_HEADERS_ALL
- 作用：采购申请头表，全局 ALL 表，带 ORG_ID 区分业务 OU
- 关键字段： REQUISITION_HEADER_ID：主键 PREPARER_ID：申请人员工 ID AUTHORIZATION_STATUS：审批状态（APPROVED/INCOMPLETE/REJECTED） ORG_ID：运营组织 REQUISITION_TYPE：物资申请 / 费用申请 APPROVED_DATE：审批通过时间
- PO_REQUISITION_LINES_ALL申请行明细，关联头 ID，物料、数量、预算账户、需求日期
- PO_REQ_DISTRIBUTIONS_ALL申请分配行，核心会计科目、费用账户、项目 WBS、预算占用，财务入账源头
阶段 2：供应商基础数据（采购基础主数据）
- PO_VENDORS：供应商头
- PO_VENDOR_SITES_ALL：供应商地点（付款、收货地点）
- PO_VENDOR_CONTACTS：供应商对接联系人
- AP_SUPPLIERS/AP_SUPPLIER_SITES_ALL：EBS 中供应商实际统一存 AP 表，PO 做引用
阶段 3：采购订单 PO 核心主表（EBS 最核心三张表）
（1）PO_HEADERS_ALL 采购订单头表
主键：PO_HEADER_ID 关键字段：
- PO_TYPE：STANDARD 标准 PO/BLANKET 一揽子协议 / PLANNED 计划 PO/CONTRACT 合同
- AUTHORIZATION_STATUS：PO 审批状态
- VENDOR_ID、VENDOR_SITE_ID：供应商及收货付款地点
- CURRENCY_CODE：订单币种
- APPROVED_FLAG：是否审批通过
- CLOSED_CODE：关闭状态（OPEN/CLOSED/FINALLY CLOSED 取消关闭）
- ORG_ID、SHIP_TO_ORG_ID：收货库存组织
（2）PO_LINES_ALL 采购订单行
PO_LINE_ID 行主键，关联 PO_HEADER_ID 字段：ITEM_ID 物料 ID、QUANTITY 订购数量、UNIT_PRICE 单价、LINE_TYPE（物料 / 费用 / 服务）、NEED_BY_DATE 需求到货日期
（3）PO_LINE_LOCATIONS_ALL 采购订单分配发货计划行（行级拆分收货、税、交货地点）
EBS 采购最重要中间层表，一行 PO 行可以拆多行发货计划 关键：SHIPMENT_ID 主键
- QUANTITY_RECEIVED：已收货数量
- QUANTITY_BILLED：已开票数量
- QUANTITY_CANCELLED：取消数量
- RECEIVING_FLAG：是否需要收货
- TAX_CODE_ID：税码，对接 EBS 税务模块 这张表是三匹配（PO - 收货 - 发票）的核心关联纽带
（4）PO_DISTRIBUTIONS_ALL PO 财务分配行
决定采购费用入账科目、项目、预算、资产化标识
- CODE_COMBINATION_ID：总账会计科目
- PROJECT_ID、TASK_ID、WBS_ELEMENT_ID：项目成本归集
- ASSET_CATEGORY_ID：入库后是否转固定资产
- ACCRUAL_ACCOUNT_ID：暂估入账科目（货到票未到暂估核心）
阶段 4：收货接收模块（Receiving）
- RCV_SHIPMENT_HEADERS供应商送货头
- RCV_SHIPMENT_LINES送货明细
- RCV_TRANSACTIONS收货事务核心表（所有接收、退回、检验、入库动作全部记录于此） TRANSACTION_TYPE：RECEIVE 接收、ACCEPT 检验合格入库、REJECT 拒收、RETURN 退回供应商 关联 PO_LINE_LOCATION_ID，回写 PO_LINE_LOCATIONS_ALL 的 QUANTITY_RECEIVED
阶段 5：配套辅助配置表
- PO_AGREEMENTS_ALL：一揽子采购协议 BPA
- PO_APPROVAL_ASSIGNMENTS：审批层级配置
- PO_POSITION_CONTROLS：采购金额审批权限
- PO_LOOKUP_CODES：PO 模块标准值集（订单状态、关闭类型）
1.2 EBS PO 经典 PL/SQL 开发示例
示例 1：查询已审批未关闭标准采购订单及收货情况
plsql
SELECT ph.po_header_id, ph.segment1 po_number, ph.authorization_status po_status, pl.line_num, pl.item_description, pl.unit_price, pl.quantity ordered_qty, pll.quantity_received received_qty, pll.quantity_billed billed_qty, vs.vendor_site_code FROM po_headers_all ph JOIN po_lines_all pl ON ph.po_header_id = pl.po_header_id JOIN po_line_locations_all pll ON pl.po_line_id = pll.po_line_id JOIN po_vendor_sites_all vs ON ph.vendor_site_id = vs.vendor_site_id WHERE ph.org_id = 82 --替换实际业务OU AND ph.authorization_status = 'APPROVED' AND ph.closed_code <> 'FINALLY CLOSED' AND ph.po_type = 'STANDARD';示例 2：EBS 标准并发请求（Concurrent Program）底层程序
- POAPPROVAL：PO 审批工作流后台并发程序，调用 WF_PO_APPROVAL_PKG 包
- PO_CREATE_RECEIPT：自动创建收货并发程序
- PO_AUTOCREATE_PO：自动由采购申请自动生成 PO，核心包
PO_AUTOCREATE_PUB - 暂估入账并发：PO Accrual Process for Period-End Accruals调用包：
PO_ACCRUAL_PVT，月末货到票未到自动生成总账暂估凭证
示例 3：EBS 标准 API 创建采购申请（公有 API，正式开发推荐，禁止直插表）
EBS 严禁直接 INSERT/UPDATE PO 业务表，必须使用官方 Public API
plsql
-- 创建采购申请标准API包：PO_REQUISITION_PUB.CREATE_REQUISITION DECLARE l_req_header_rec PO_REQUISITION_PUB.req_header_rec_type; l_req_lines_tbl PO_REQUISITION_PUB.req_lines_tbl_type; l_return_status VARCHAR2(1); l_msg_count NUMBER; l_msg_data VARCHAR2(2000); BEGIN --赋值申请头 l_req_header_rec.preparer_id := 12345; --申请人员工ID l_req_header_rec.org_id := 82; l_req_header_rec.requisition_type := 'PURCHASE'; --调用API生成申请 PO_REQUISITION_PUB.CREATE_REQUISITION( p_api_version => 1.0, p_req_header_rec => l_req_header_rec, p_req_lines_tbl => l_req_lines_tbl, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data ); IF l_return_status = 'S' THEN DBMS_OUTPUT.PUT_LINE('采购申请创建成功'); ELSE DBMS_OUTPUT.PUT_LINE('失败：'||l_msg_data); END IF; END; /1.3 EBS PO 核心常用 PL/SQL 包汇总
PO_HEADERS_PVT：PO 头私有处理包PO_LINE_LOCATIONS_PVT：发货计划行业务逻辑PO_WF_APPROVAL_PKG：采购审批工作流核心PO_RCV_TRANSACTIONS_PUB：收货公开 APIPO_CLOSE_PO_PVT：订单关闭、取消逻辑
第二部分：Oracle Fusion Cloud Procurement 采购模块
2.1 Fusion 关键约束：无法直接访问底层物理表
- 客户无数据库直连权限，所有数据获取路径：
- OTBI 分析视图（最常用）
- Fusion REST API
- BIP 数据模型
- 自定义 ESS 作业、Groovy 验证规则
- Fusion 内部逻辑表采用分区、逻辑分区架构，按业务单元、账套做数据隔离
2.2 Fusion 采购对应 EBS 业务的逻辑视图（OTBI 标准逻辑表）
| EBS 业务对象 | Fusion OTBI 逻辑视图名 | 说明 |
|---|---|---|
| 采购申请头 | Procurement - Requisition Header Real Time | 实时申请头数据 |
| 采购订单头 | Procurement - Purchase Order Header Real Time | PO 头实时视图 |
| PO 行、发货计划 | Procurement - Purchase Order Line Real Time | 合并 EBS plines+linelocations |
| 收货事务 | Procurement - Receiving Transactions Real Time | 对应 RCV_TRANSACTIONS |
| 供应商主数据 | Procurement - Supplier Real Time | 供应商、供应商地点 |
| 采购分配财务 | Procurement - PO Distribution Real Time | 对应 PO_DISTRIBUTIONS_ALL 科目分配 |
2.3 Fusion 采购核心 REST API 示例（主流集成场景）
接口 1：查询已审批采购订单（标准 REST）
接口地址
plaintext
GET /fscmRestApi/resources/latest/purchaseOrders关键查询参数：
plaintext
?finder=ApprovedPurchaseOrders &expand=purchaseOrderLines,purchaseOrderLines.receivingShipments &fields=PurchaseOrderNumber,Status,VendorName,OrderedAmount返回 JSON 包含：订单号、审批状态、供应商、订购数量、已收货数量、已开票数量，等价 EBS 多表 JOIN 结果。
接口 2：创建采购申请 REST API
plaintext
POST /fscmRestApi/resources/latest/purchaseRequisitions请求体精简示例：
json
{ "PreparerId": "100001", "BusinessUnitId": "30001", "RequisitionType": "PURCHASE", "requisitionLines": [ { "ItemId": "20005", "Quantity": 10, "UnitPrice": 100, "NeedByDate": "2026-12-31" } ] }2.4 Fusion 后台程序类型（替代 EBS 并发请求）
- ESS 作业（Enterprise Scheduler Service）对应 EBS Concurrent Request，Fusion 标准采购 ESS：
- 采购订单审批同步：
Import Approved Purchase Orders - 收货批量导入：
Import Receiving Transactions - 月末采购暂估：
Period End Accrual for Procurement
- 采购订单审批同步：
- 工作流：Oracle BPM Workflow替代 EBS WF 工作流，可视化拖拽配置审批流，无需 PL/SQL 开发；
- Groovy 脚本验证在 PO 行、申请行新增自定义校验规则（例如单价上限校验、预算校验），Fusion 唯一轻量客户化方式。
2.5 Fusion 三匹配逻辑实现差异
- EBS：数据库层面表字段物理更新（QUANTITY_RECEIVED、QUANTITY_BILLED）；
- Fusion：业务层实时计算，不在物理表固化字段，查询时实时聚合收货、发票事务数据，数据一致性由云事务引擎保障。
第三部分：EBS 与 Fusion 采购关键技术开发对比
3.1 数据查询开发
EBS多表 JOIN SQL 直查，弹性域表（FND_FLEX_VALUES、FND_FLEX_VALIDATION_RULES）关联取值，可做视图、存储过程、定时 DB JOB。 典型关联：PO_HEADERS_ALL+PO_LINES_ALL+PO_LINE_LOCATIONS_ALL+RCV_TRANSACTIONS+PO_DISTRIBUTIONS_ALL 五表联查完整订单生命周期。
Fusion禁止 SQL 直连，方案： ① OTBI 创建分析报表拖拽维度指标； ② BIP 基于逻辑视图写 SQL； ③ 外部系统调用 REST 接口定时拉取数据入库本地数据仓库。
3.2 数据导入集成
- EBS：标准接口表 + 并发导入程序 例如：PO_HEADERS_INTERFACE、PO_LINES_INTERFACE 接口表，运行
Import Purchase Orders并发程序导入正式表； - Fusion：FBDI 模板导入（Excel 模板上传）+ REST 两种方式，无数据库接口表。
3.3 审批架构
- EBS：WF 工作流引擎，PL/SQL 打包审批逻辑，WF_NOTIFICATIONS 发审批通知；
- Fusion：BPM 可视化流程设计，移动端审批、邮件 / OA 消息集成，规则配置化，极少编码。
第四部分：经典业务场景表级追踪示例（EBS 完整链路）
场景：一张标准 PO 下单→收货→开票
- 创建 PO：写入 PO_HEADERS_ALL、PO_LINES_ALL、PO_LINE_LOCATIONS_ALL、PO_DISTRIBUTIONS_ALL；
- 审批通过：更新 PH.AUTHORIZATION_STATUS='APPROVED'；
- 供应商送货，执行接收：插入 RCV_TRANSACTIONS，同步更新 PLL.QUANTITY_RECEIVED；
- AP 录入供应商发票，匹配 PO 行：AP_INVOICES_ALL+AP_INVOICE_DISTRIBUTIONS_ALL，回写 PLL.QUANTITY_BILLED；
- 全额三匹配无误后关闭 PO：更新 PH.CLOSED_CODE='FINALLY CLOSED'。
第五部分实施与开发注意事项
EBS 端
- 所有 ALL 表必须带上 ORG_ID 过滤，多 OU 环境不加 ORG 会跨组织串数据；
- 绝对禁止 DML 直接修改 PO 业务表，必须调用标准 PUB API；
- 弹性域、值集是 EBS 扩展核心，不要自建冗余字段；
- 暂估核心依赖 PO_DISTRIBUTIONS_ALL 里的暂估科目，月末 accrual 并发务必按时运行。
Fusion 端
- 所有集成优先 REST/FBDI，拒绝尝试穿透底层库；
- 客户化逻辑优先配置 + Groovy，尽量零代码；
- OTBI 实时视图有轻微延迟，高实时性需求走 API 拉取；
- 云版本持续自动升级，自定义 Groovy、API 集成兼容性官方持续维护。