Oracle EBS PO 模块 vs Oracle Fusion Procurement采购模块深度对比分析全文结构设计哲学 → 核心原理 → 业务实现逻辑 → 业务对象 / 逻辑实体 → 物理实体后台表→ 关键程序示例 → 架构本质差异说明EBS R12 E-Business SuiteFusion Oracle Cloud ERP Fusion ProcurementSaaS 新一代 ERP 采购范围覆盖申请 Requisition → 采购订单 PO → 接收 Receiving → 发票匹配 AP Invoice不含 Sourcing 招标部分一、两套产品采购模块【设计哲学】1. Oracle EBS PO 设计哲学本地 ERP单体架构事务驱动、面向表单、紧耦合单体模型以纸质单据电子化作为核心出发点复刻传统企业采购流程单据优先流程次之。模块边界清晰但数据库层强耦合PO、AP、INV、GL 各自独立应用模块但底层共用一套数据库大量跨模块直接表关联没有统一服务层。“状态机驱动单据生命周期”所有单据PR/PO/Receipt依靠状态字段控制业务行为PO_STATUS、AUTHORIZATION_STATUS 等权限、审批、可编辑性全部绑定状态。多组织架构基于MOACMulti-Org Access Control** 账套→法人LE→业务实体 OU数据隔离靠 ORG_ID 列物理区分单表存储多 OU 数据。扩展模式弹性域Key Flexfield/Descriptive Flexfield预留 ATTR1~ATTR20 字段做扩展无原生自定义对象模型。技术定位On-Prem 传统 ERP面向事务处理报表直接访问基表2. Oracle Fusion Procurement 设计哲学云原生 SaaS服务化、面向业务对象BO、松耦合微服务架构抛弃单体表单思路业务对象为一等公民单据只是 BO 的视图所有操作通过标准服务 API禁止直连数据库。统一业务平台Fusion Application PlatformFAP共享企业结构、安全模型、审批框架、审计框架、ESS 调度、消息事件总线。“对象生命周期 事件驱动” 替代单纯状态机单据变更触发业务事件Event外部扩展、集成、工作流订阅事件而非直接修改表。多组织全新模型企业结构Enterprise StructureBU 业务单元、Legal Entity 法人、Inventory Org 库存组织、Procurement BU 采购业务单元采购独立 BU 维度区分于 EBS OU。原生自定义模型Flexfield 扩展 自定义对象Custom Object不再只是 ATTR 字段支持扩展属性分组、父子扩展对象。分层隔离逻辑层BO→视图对象 VO→物理表客户无法直接访问物理表内置采购协同供应商门户、自助采购、谈判寻源一体化原生支持外部参与者核心哲学一句话总结EBS数据库优先表单单据驱动Fusion业务对象优先服务事件驱动。二、核心原理与实现逻辑对比一EBS PO 实现原理1. 分层模型三层Form界面OAF/Forms ↓ PL/SQL APIPO_PUBLIC_API、PO_DOCUMENT_ACTION_PUB ↓ 后台基表物理表所有业务逻辑重度依赖PL/SQL 包Form、并发程序、外部集成统一调用同一套公共 API 保证一致性。无中间对象层API 直接读写物理表。并发请求Concurrent Request处理批量操作自动创建 PO、汇总审批、接收事务处理。2. 单据流转核心逻辑PR申请→ 审批 → 自动 / 手动生成 PO → PO 审批 → 接收 → 匹配 AP 发票三向匹配 (3-way match) 关键控制逻辑审批基于 AME 审批引擎R12审批结果写入单据头授权状态匹配控制匹配选项存储在 PO_LINE_LOCATIONS_ALL发运层数量控制已订购、已接收、已开票数量实时更新在 PO 行 / 发运表实时汇总计算取消 / 关闭修改单据状态标识不删除数据软状态而非软删除3. EBS 核心约束所有数量汇总字段QUANTITY_ORDERED、QUANTITY_RECEIVED物理存储在表中频繁更新并发锁风险高。跨模块校验PO 调用 INV API 接收、调用 AP 校验发票匹配直接数据库会话交互。二Fusion Procurement 实现原理1. 标准四层架构Fusion ADF BC 模型UIFusion Pages / OTBI ↓ VO 视图对象View Object逻辑查询封装 ↓ EO 实体对象Entity Object映射物理表、内置业务校验 ↓ 物理数据库表客户不可直接访问上层对外暴露Business Object ServiceREST API / SOAP2. 流转核心逻辑采购申请 BO → 审批服务 → 采购订单 BO → 接收 BO → 发票 BO 重大差异数量不再实时写物理字段大量度量字段采用动态计算 / 物化视图减少行锁工作流统一使用 Fusion SOA Workflow全平台统一不再是 PO 独立审批引擎所有变更产生业务事件Business Event可用于集成三向匹配逻辑下沉到 AP Common 服务采购模块只负责记录接收与订单信息采购 BU 作为独立安全维度实现采购业务与财务法人适度解耦EBS OU 强绑定财务。3. 集成方式强制规范禁止直表读写必须使用REST API采购标准 BO APIFBDI 批量导入工具事件通知 EBS 大量项目普遍存在直表更新Fusion SaaS 严格禁止。三、业务对象Business Object逻辑实体物理实体划分术语定义先厘清业务对象 BO面向业务人员的完整业务载体采购申请、采购订单逻辑实体BO 内部拆分逻辑单元订单头、订单行、发运、分配与界面区块对应物理实体数据库真实 Table物理表3.1 Oracle EBS PO 业务对象、逻辑实体、物理表映射BO1采购申请 Purchase Requisition逻辑实体核心物理表说明申请头PO_REQUISITION_HEADERS_ALLPR 头信息申请人、单据日期、OU申请行PO_REQUISITION_LINES_ALL物料、数量、需求日期、科目申请分配PO_REQ_DISTRIBUTIONS_ALL费用分配、CCID 会计科目、预算信息BO2采购订单 Purchase Order标准 PO / 合同 / 一揽子 / 计划逻辑实体核心物理表关键说明PO 头PO_HEADERS_ALL供应商、付款条件、币种、单据类型 PO_TYPEPO 行PO_LINES_ALL物料、单价、类别、税码PO 发运ShipmentPO_LINE_LOCATIONS_ALL交付地点、匹配控制、接收允差、税率分配层3-way 匹配控制点PO 分配DistributionPO_DISTRIBUTIONS_ALL会计科目、项目 WBS、预算、已开票金额EBS 经典四层结构Header → Line → Line Location → DistributionBO3接收事务 Receiving逻辑实体物理表接收头RCV_SHIPMENT_HEADERS供应商送货单接收行RCV_SHIPMENT_LINES对应 PO 发运接收事务RCV_TRANSACTIONS_ALL接收、检验、入库、退货所有动作流水核心事务表BO4供应商采购共享PO_VENDORS_ALL、PO_VENDOR_SITES_ALLEBS 特点逻辑实体几乎一对一映射物理表中间层很薄。3.2 Oracle Fusion Procurement 业务对象、逻辑实体、底层物理映射重要Fusion 不对外公开完整物理表名官方只开放 BO 名称物理表仅供 Oracle 内部运维使用。下面是公开 BO 分层模型BO1Requisition采购申请逻辑分层Requisition Header申请头Requisition Line申请行Requisition Distribution费用分配对外服务名称requisitionsREST APIBO2Purchase Order采购订单 BO逻辑实体分层和 EBS 名称相似但含义差异Order Header 订单头Order Line 订单行Order Schedule替代 EBS Line Location 发运Order Distribution费用分配Fusion 术语变化Line Location → Schedule 对外标准 REST 资源purchaseOrdersBO3Receipt接收 BOReceipt HeaderReceipt LineReceipt Transaction事务流水BO4Agreements一揽子协议 / 合同 BOFusion 将 Blanket Purchase Agreement、Contract 作为独立 BOEBS 只是 PO_TYPE 区分。关键架构差异EBS一张表 一个逻辑实体Fusion一个 EO实体对象可以组合多个物理表VO 多层聚合BO 是上层聚合视图业务对象 ≠ EO ≠ 物理表存在多层封装。四、EBS PO 核心后台表清单完整常用表PO 模块主表PO_HEADERS_ALL PO订单头 PO_LINES_ALL PO行 PO_LINE_LOCATIONS_ALL PO发运Shipment PO_DISTRIBUTIONS_ALL PO分配 PO_REQUISITION_HEADERS_ALL PR头 PO_REQUISITION_LINES_ALL PR行 PO_REQ_DISTRIBUTIONS_ALL PR分配 PO_VENDORS_ALL 供应商 PO_VENDOR_SITES_ALL 供应商地点 PO_AGREEMENTS_ALL 协议头 PO_AGREEMENT_LINES_ALL 协议行接收模块 RCVRCV_SHIPMENT_HEADERS RCV_SHIPMENT_LINES RCV_TRANSACTIONS_ALL 接收事务核心流水 RCV_ACCEPTANCES采购审批 / 状态表PO_ACTION_HISTORY 单据操作历史审批、取消、修改 PO_APPROVAL_LIST_HEADERS PO_APPROVAL_LIST_LINES价格 / 目录PO_PRICE_DIFFERENTIALS PO_CATALOG_SOURCESEBS 重要字段示例PO_HEADERS_ALL ORG_ID多组织、PO_HEADER_ID 主键、PO_TYPE、AUTHORIZATION_STATUS审批状态、PO_STATUS单据状态、VENDOR_ID、VENDOR_SITE_ID五、程序代码示例示例 1EBS PL/SQL 标准 API 创建采购订单PO_DOCUMENT_ACTION_PUBEBS 所有自定义开发必须调用公共 API禁止直插表DECLARE g_po_header_rec PO_DOCUMENT_ACTION_PUB.g_po_header_rec_type; g_po_lines_tbl PO_DOCUMENT_ACTION_PUB.g_po_lines_tbl_type; g_po_line_loc_tbl PO_DOCUMENT_ACTION_PUB.g_po_line_loc_tbl_type; g_po_dist_tbl PO_DOCUMENT_ACTION_PUB.g_po_dist_tbl_type; x_po_header_id NUMBER; x_po_number VARCHAR2(20); x_return_status VARCHAR2(1); x_msg_count NUMBER; x_msg_data VARCHAR2(4000); BEGIN --填充头 g_po_header_rec.vendor_id : 1001; g_po_header_rec.vendor_site_id : 10001; g_po_header_rec.org_id : 82; g_po_header_rec.po_type : STANDARD; --调用API创建PO PO_DOCUMENT_ACTION_PUB.create_po( p_api_version 1.0, p_init_msg_list FND_API.G_TRUE, p_po_header_rec g_po_header_rec, p_po_lines_tbl g_po_lines_tbl, p_po_line_loc_tbl g_po_line_loc_tbl, p_po_dist_tbl g_po_dist_tbl, x_po_header_id x_po_header_id, x_po_number x_po_number, x_return_status x_return_status, x_msg_count x_msg_count, x_msg_data x_msg_data ); IF x_return_status FND_API.G_RET_STS_SUCCESS THEN DBMS_OUTPUT.PUT_LINE(创建PO成功PO号||x_po_number); ELSE DBMS_OUTPUT.PUT_LINE(失败||x_msg_data); END IF; END; /示例 2EBS 查询 PO 四层表关联 SQL最常用报表模板SELECT ph.po_header_id, ph.segment1 po_number, pl.po_line_id, pl.line_num, pll.po_line_location_id, pll.shipment_num, pd.po_distribution_id, pd.distribution_num, pl.item_id, pl.unit_price, pll.quantity_ordered, pll.quantity_received, pll.quantity_billed 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_distributions_all pd ON pll.po_line_location_id pd.po_line_location_id WHERE ph.org_id 82 AND ph.authorization_status APPROVED;示例 3Fusion Procurement REST API 调用示例查询采购订单 BOFusion 无 PL/SQL 本地 API标准集成方式 RESTGET https://fusion-host/fscmRestApi/resources/11.13.18.05/purchaseOrders ?qpoNumberPO12345 expandlines,schedules,distributionsPayload 简化返回结构BO 层级{ poHeaderId: 300000123456, poNumber: PO12345, lines: [ { poLineId: 300000123457, lineNum: 1, schedules: [ { scheduleId: 300000123458, quantityOrdered: 100, distributions: [ {distributionId:300000123459} ] } ] } ] }批量导入采用FBDI Excel 模板替代 EBS 接口表PO_INTERFACE_HEADERS_ALL示例 4EBS 采购开放接口表导入传统数据上载接口表PO_INTERFACE_HEADERS_ALL PO_INTERFACE_LINES_ALL PO_INTERFACE_LINE_LOCATIONS_ALL PO_INTERFACE_DISTRIBUTIONS_ALL运行并发程序Import Standard Purchase OrdersFusion 没有这类数据库接口表改用 FBDI/REST。六、EBS PO vs Fusion Procurement 核心关键差异汇总维度Oracle EBS POR12Fusion Procurement架构单体 On-PremPL/SQL 驱动云原生微服务、ADF BC、服务 BO多组织MOACORG_IDOU 核心维度采购 BU 独立维度Enterprise Structure单据分层Header-Line-Line Location-DistributionHeader-Line-Schedule-Distribution业务逻辑载体PL/SQL 包 APIEO 实体对象 Java 业务逻辑数据访问允许 API大量项目直表读写严格禁止直表只能 API/FBDI扩展方式弹性域 DFF/KFF (ATTR 字段)弹性域 自定义业务对象审批引擎AME统一 Fusion Workflow数量字段物理存储实时更新锁竞争高动态计算为主集成方式PLSQL API、接口表、直表REST、SOAP、FBDI、事件总线供应商协同附加模块原生内置供应商门户事务模型状态机为主事件驱动 状态结合七、实施与迁移关键总结ERP 架构师视角EBS 模型本质关系数据库表驱动业务规则封装在 PLSQL单据四层表完全贴合关系范式适合本地重度二次开发但并发、扩展、云集成短板明显。Fusion 模型本质业务对象服务驱动数据库作为底层存储被封装对外屏蔽物理模型一切以 BO 服务为标准降低数据库耦合适合 SaaS 持续升级但底层自定义能力大幅受限。迁移最大改造点放弃所有 EBS 直表 SQL、直表更新逻辑将 PLSQL 接口改造为 Fusion REST/FBDI 集成组织模型从 OU 切换为采购 BU 法人 LE 双层结构弹性域迁移、审批从 AME 迁移至 Fusion 工作流。