Oracle EBS AP应付模块 vs Oracle Fusion AP应付账款深度全解析覆盖设计哲学、底层原理、实现逻辑、业务对象、逻辑实体、物理实体、核心后台表、标准程序示例同时对比两代架构差异。前置说明 EBSOracle E-Business Suite R12.x传统 ERPC/SWeb Forms单体应用 Fusion ERPOracle Cloud ERPSaaS 云原生微服务 OSM/BO 框架REST API 驱动 AP Accounts Payable 应付账款模块一、整体设计哲学对比1. Oracle EBS AP 设计哲学核心定位事务驱动、会计分录优先、账套中心化、模块化紧耦合基于会计科目结构GL CCID作为最核心的资金纽带所有应付交易最终落地生成 GL 日记账遵循采购 - 接收 - 发票 - 付款传统供应链闭环模块间硬集成PO→AP→GL→CE事务先行审批后置可配置单据保存即生成事务数据审批控制业务操作权限数据分层业务事务层 → 分配层 → 会计分录层实体高度复用供应商同时被 PO、AP、Payables 共享无独立供应商微服务局限单体数据库表之间大量外键扩展依赖自定义表、触发器、个性化 Form。2. Oracle Fusion AP 设计哲学核心定位云原生 BOBusiness Object领域驱动、标准化服务、审计原生、合规优先、松耦合领域对象 BO 为第一公民不再以数据库表为核心业务通过 BO 服务交互数据库是存储载体强制审批流嵌入事务生命周期大量业务操作必须经过审批才能生效多维度维度拆分供应商管理独立为「供应商管理云Supplier Model」AP 只负责发票、付款结算会计引擎独立Subledger AccountingSLA作为独立总账子分类账引擎EBS 与 Fusion 都有 SLA但 Fusion SLA 重构原生支持多法人、多账套、多币种、全球税务Global Tax税务逻辑从 AP 剥离为独立 Tax 服务外部集成标准化REST API / EventBusiness Event禁止直接操作后台表分层思想UI 层 → BO 服务层 → 业务规则层 → SLA 会计层 → 持久层。二、底层核心原理通用基础原理EBS Fusion 同源应付模块核心业务原理不变采购产生负债AP 发票→ 审核负债真实性 → 付款清偿负债 → 产生现金流出 → 子分类账生成会计分录传入总账 标准会计逻辑标准采购发票 借费用 / 存货 / 资产 贷应付账款供应商负债付款 借应付账款 贷银行存款EBS AP 底层原理特征11i 遗留架构延续AP 事务表AP_INVOICES_ALL保存发票头分配行 AP_INVOICE_DISTRIBUTIONS_ALL 承载会计分配SLA 是 R12 新增R11 无 SLA直接生成 GL 接口付款AP_PAYMENTS_ALL、付款批AP_PAYMENT_BATCHES_ALL付款核销发票依靠 AP_INVOICE_PAYMENTS_ALL发票 - 付款关联表币种转换、汇率存储在事务行转换逻辑内置 AP 标准程序税务EBS TaxEB Tax嵌入 AP 分配行。Fusion AP 底层原理特征业务事件驱动架构发票创建、验证、审批、付款触发业务事件可供外部订阅分离供应商主数据Procurement Supplier BO不在 AP 内部税务Global Tax ServiceAP 只接收计算后的税行不负责计税规则银行 / 付款Cash Management BO 独立发票不再简单头行结构区分Invoice Header BO、Invoice Line BO、Invoice Distribution BO、Tax Line BO、Withholding Tax BO核销关系不再简单一张关联表通过结算 BOSettlement统一管理发票、贷项通知单、付款、预付款核销SLA 完全解耦所有会计条目由 SLA 引擎统一产出AP 不直接生成 GL 分录。三、业务完整实现逻辑端到端流程3.1 EBS AP 标准业务流程实现逻辑PO接收 → 匹配PO发票(3-way匹配) ↓ 录入/导入发票(AP_INVOICES_ALL) → 创建分配行AP_INVOICE_DISTRIBUTIONS_ALL ↓ 【发票验证 Validate Invoice】核心并发请求APPRV 校验金额、税率、PO匹配、预算、重复发票 验证通过设置INVOICES_ALL.APPROVED_FLAG Y ↓ 可创建预付款、贷项通知单抵扣负债 ↓ 选择发票创建付款批 → 付款选择程序 → 生成付款AP_PAYMENTS_ALL ↓ 付款核销AP_INVOICE_PAYMENTS_ALL 记录哪笔付款付哪些发票行 ↓ 提交SLA会计程序 → 生成XLA_AE_HEADERS/XLA_AE_LINES ↓ SLA传送至GL接口表 → GL过账关键控制点未验证发票不能付款分配行是会计维度载体CCID 存储科目组合预付款AP_PREPAYMENTS_ALL预付款应用会生成反向分配行3.2 Fusion AP 标准业务流程实现逻辑采购接收 → 创建供应商发票通过UI/Import REST API/Excel导入 ↓ 发票BO保存自动触发税务服务生成税行 ↓ 发票验证Validation Service→ 触发审批流程 ↓ 审批完成 → 发票状态变为“可支付”(Ready for Payment) ↓ 付款工作区选取应付负债 → 创建付款结算Settlement BO ↓ 付款指令推送现金管理云生成银行付款文件 ↓ 付款生效后自动创建结算核销关系发票-付款 ↓ 触发SLA子分类账引擎生成会计事件 ↓ SLA发布日记账至GL云总账重大差异审批是强制性中间节点EBS 审批更多是控制访问不阻塞付款配置相关核销逻辑抽象为 Settlement支持多层抵销发票、贷项、预付款、扣款、付款统一结算不存在 “付款批” 传统概念改为付款文档 Payment Document四、业务对象、逻辑实体、物理实体分层定义分层标准业务对象 BO对外服务层 逻辑实体业务模型层 物理实体数据库表4.1 Oracle EBS AP1顶层业务对象业务视角供应商 Supplier应付发票 Invoice标准发票、贷项通知单、借项通知单、预付款发票分配 Invoice Distribution付款 Payment预付款 Prepayment发票付款核销 Invoice Payment Application预留 / 预扣税 Withholding Tax付款批 Payment Batch2逻辑实体逻辑模型不直接对应单表发票头逻辑实体发票分配行逻辑实体付款头逻辑实体发票 - 付款核销关联逻辑实体预付款应用逻辑实体3核心物理实体后台表All 表 多组织ORG_ID 区分 OU物理表名用途主键 / 核心外键AP_INVOICES_ALL发票头信息发票号、供应商、发票日期、币种、状态INVOICE_IDPK, VENDOR_ID, VENDOR_SITE_IDAP_INVOICE_DISTRIBUTIONS_ALL发票分配行费用科目、PO 匹配信息、金额、CCIDINVOICE_DISTRIBUTION_ID, INVOICE_IDAP_INVOICE_PAYMENTS_ALL发票与付款核销关联核心核销表INVOICE_PAYMENT_ID, INVOICE_ID, PAYMENT_IDAP_PAYMENTS_ALL付款头记录PAYMENT_ID, PAYMENT_BATCH_IDAP_PAYMENT_BATCHES_ALL付款批EBS 独有PAYMENT_BATCH_IDAP_PREPAYMENTS_ALL预付款属性扩展PREPAYMENT_ID, INVOICE_IDAP_HOLDS_ALL发票冻结 / 暂停付款记录HOLD_ID, INVOICE_IDAP_SUPPLIERS供应商头R12 供应商主表VENDOR_IDAP_SUPPLIER_SITES_ALL供应商地点付款地点VENDOR_SITE_IDXLA_AE_HEADERS/XLA_AE_LINESSLA 子分类账分录R12从 AP 事务 ID 关联EBS 特点逻辑实体几乎和物理表一一对应中间层薄业务程序直接读写表。4.2 Oracle Fusion AP1顶层业务对象 BOBusiness ObjectFusion 一等公民Fusion 基于 Application Development Framework (ADF) Business Components OSML 服务模型Invoice BO应付发票主对象Invoice Header VOView ObjectInvoice Line VOInvoice Distribution VO会计分配行Invoice Tax Line VOSettlement BO结算对象统一处理付款、贷项、预付款核销Payment BO付款文档Withholding Tax BO重要供应商属于Procurement Supplier BO不属于 AP BO跨模块服务调用。2逻辑实体逻辑数据模型 LDMOracle 发布 Fusion LDM 模型中 AP 核心逻辑实体Payable InvoicePayable Invoice LinePayable Invoice DistributionPayable Invoice TaxPayable Settlement结算核销Payable PaymentPayable Prepayment Application逻辑实体不一对一映射数据库表一个 BO 可以关联多张物理表VO 是逻辑视图屏蔽底层物理存储。3物理实体Fusion 后台表注意Oracle 不鼓励客户直接查询修改Fusion 表命名范式AP_XXX/PAY_XXX多组织使用LEDGER_ID、BU_ID业务单元不再单纯 ORG_ID仅列出核心物理表Cloud 版本持续迭代表结构会微调 | 物理表 | 说明 | |---|---| |AP_INVOICES | 发票头物理表 | |AP_INVOICE_LINES | 发票行Fusion 区分 Header 与 LineEBS 无独立发票行| |AP_INVOICE_DISTRIBUTIONS | 会计分配行 | |AP_INVOICE_TAXES | 发票税行 | |AP_SETTLEMENTS | 核心结算表替代 EBS AP_INVOICE_PAYMENTS_ALL发票 / 付款 / 贷项核销全部在此| |PAY_PAYMENTS | 付款主表 | |PAY_PREPAYMENT_APPLICATIONS | 预付款核销记录 | |AP_HOLDS | 发票冻结 | |XLA_AE_HEADERS、XLA_AE_LINES|Fusion SLA 表结构和 EBS 大体兼容但会计事件类型不同|关键区别EBS没有独立 AP_INVOICE_LINES发票头直接挂分配行Fusion 引入三层结构Header → Line → DistributionFusion 使用 AP_SETTLEMENTS 一张表统一承载所有抵销关系EBS 分散在多张表五、核心程序 / 并发请求、代码示例思路5.1 Oracle EBS AP 标准并发程序重要Payables Invoice ValidationAPPRV发票验证核心程序包AP_PAYMENT_SCHEDULES_PKG、AP_INVOICES_PKG作用计算付款计划、校验匹配、创建 AP_PAYMENT_SCHEDULES_ALL付款计划非常关键AP_PAYMENT_SCHEDULES_ALL每张发票到期付款计划是付款选择程序的数据源Payables Payment Selection 付款选择包AP_PAY_SELECT_PKGCreate Payment Batch 创建付款批SLA Create Accounting 创建会计分录XLA_ACCOUNTING_PUB_PKGEBS PL/SQL 简易业务示例仅原理演示正式开发要用标准 API禁止直接 DML-- 重要提醒EBS严禁直接insert ap_invoices_all必须调用标准API: AP_INVOICES_PKG.CREATE_INVOICE DECLARE l_invoice_id NUMBER; BEGIN -- 调用标准API创建发票头 AP_INVOICES_PKG.CREATE_INVOICE( p_invoice_num TEST-20260816, p_vendor_id 100123, p_vendor_site_id 200456, p_invoice_date SYSDATE, p_invoice_amount 5000, p_org_id 82, l_invoice_id l_invoice_id ); -- 新增发票分配行 APIAP_INVOICE_DISTRIBUTIONS_PKG -- 之后调用 AP_PAYMENT_SCHEDULES_PKG 生成付款计划 END; /EBS 标准导入方式AP_INVOICES_INTERFACE 接口表 → 运行【Import Invoices】并发请求5.2 Fusion AP 程序与集成方式Fusion 不存在客户可直接调用的后台并发请求 Package所有业务只能通过三种途径REST API官方推荐ADF 桌面集成器Excel 导入ESS 调度作业内部作业客户不能直接调用 PLSQL 包Fusion AP 关键 REST 资源/fscmRestApi/resources/11.13.18.05/payablesInvoices 应付发票 CRUD/fscmRestApi/resources/11.13.18.05/payableSettlements 结算 / 核销/fscmRestApi/resources/11.13.18.05/payments 付款Fusion API 请求示例创建发票简化 Payload{ InvoiceNumber: FUSION-TEST-001, InvoiceDate: 2026-08-16, SupplierId: 300012, SupplierSiteId: 450098, InvoiceAmount: 3500, LedgerId: 10001, BusinessUnitId: 204, InvoiceLines: [ { LineAmount: 3500, DistributionSetId: 1050 } ] }不能直接操作 AP_INVOICES 物理表任何直接 DML 会破坏 BO 缓存、审批流、审计、SLA 事件Oracle 不支持、不保修。六、EBS AP vs Fusion AP 核心架构差异汇总维度EBS R12 APFusion Cloud AP架构模式单体应用数据库中心云微服务BO 业务对象中心数据分层发票头 → 分配行两层发票头 → 发票行 → 分配行三层核销载体AP_INVOICE_PAYMENTS_ALLAP_SETTLEMENTS统一结算模型供应商管理AP 内置供应商表独立采购云 Supplier BO跨模块调用税务逻辑EB Tax 嵌入 AP 分配行独立 Global Tax 服务付款模型付款批 Payment Batch付款文档 结算 Settlement无付款批概念集成方式接口表、PLSQL API、Form 个性化REST API、业务事件、Excel 导入组织维度OU运营单位ORG_IDBU 业务单元 Ledger 账套双维度会计引擎SLAR12重构 SLA更强多准则、多币种支持扩展方式自定义表、触发器、Form PersonalizationExtensibility 框架、Groovy、自定义属性禁止数据库触发器七、实施 开发关键落地要点EBS 迁移 Fusion AP 最大改造点淘汰接口表导入方案改用 REST API重构预付款、贷项、发票核销逻辑适配 Settlement 结算模型供应商主数据迁移至 Procurement 供应商模型税务逻辑从 AP 剥离改为调用全局税务服务。报表开发注意EBS可基于 AP 多表关联开发自定义报表Fusion优先使用 OTBI 分析模型尽量避免直连后台物理表查询。会计分录迁移重点 SLA 会计事件类别Event Class两代存在差异会计规则需要重新配置不能直接迁移 XLA 设置。