企业官网建设流程全解析

Oracle EBS AP（应付模块） vs Oracle Fusion AP（应付账款）深度全解析

覆盖：设计哲学、底层原理、实现逻辑、业务对象、逻辑实体、物理实体、核心后台表、标准程序示例，同时对比两代架构差异。

前置说明： EBS：Oracle E-Business Suite R12.x（传统 ERP，C/S+Web Forms，单体应用） Fusion ERP：Oracle Cloud ERP（SaaS 云原生，微服务 + OSM/BO 框架，REST API 驱动） AP = Accounts Payable 应付账款模块

一、整体设计哲学对比

1. Oracle EBS AP 设计哲学

核心定位：事务驱动、会计分录优先、账套中心化、模块化紧耦合

1. 基于会计科目结构（GL CCID）作为最核心的资金纽带，所有应付交易最终落地生成 GL 日记账；
2. 遵循采购 - 接收 - 发票 - 付款传统供应链闭环，模块间硬集成（PO→AP→GL→CE）；
3. 事务先行，审批后置（可配置），单据保存即生成事务数据，审批控制业务操作权限；
4. 数据分层：业务事务层 → 分配层 → 会计分录层；
5. 实体高度复用：供应商同时被 PO、AP、Payables 共享，无独立供应商微服务；
6. 局限：单体数据库，表之间大量外键，扩展依赖自定义表、触发器、个性化 Form。

2. Oracle Fusion AP 设计哲学

核心定位：云原生 BO（Business Object）领域驱动、标准化服务、审计原生、合规优先、松耦合

1. 领域对象 BO 为第一公民，不再以数据库表为核心；业务通过 BO 服务交互，数据库是存储载体；
2. 强制审批流嵌入事务生命周期，大量业务操作必须经过审批才能生效；
3. 多维度维度拆分：供应商管理独立为「供应商管理云（Supplier Model）」，AP 只负责发票、付款结算；
4. 会计引擎独立：Subledger Accounting（SLA）作为独立总账子分类账引擎，EBS 与 Fusion 都有 SLA，但 Fusion SLA 重构；
5. 原生支持多法人、多账套、多币种、全球税务（Global Tax），税务逻辑从 AP 剥离为独立 Tax 服务；
6. 外部集成标准化：REST API / Event（Business Event），禁止直接操作后台表；
7. 分层思想：UI 层 → BO 服务层 → 业务规则层 → SLA 会计层 → 持久层。

二、底层核心原理

通用基础原理（EBS & Fusion 同源）

应付模块核心业务原理不变：

采购产生负债（AP 发票）→ 审核负债真实性 → 付款清偿负债 → 产生现金流出 → 子分类账生成会计分录传入总账 标准会计逻辑：

1. 标准采购发票 借：费用 / 存货 / 资产 贷：应付账款（供应商负债）
2. 付款 借：应付账款 贷：银行存款

EBS AP 底层原理特征

1. 11i 遗留架构延续，AP 事务表（AP_INVOICES_ALL）保存发票头，分配行 AP_INVOICE_DISTRIBUTIONS_ALL 承载会计分配；
2. SLA 是 R12 新增，R11 无 SLA，直接生成 GL 接口；
3. 付款（AP_PAYMENTS_ALL）、付款批（AP_PAYMENT_BATCHES_ALL），付款核销发票依靠 AP_INVOICE_PAYMENTS_ALL（发票 - 付款关联表）；
4. 币种转换、汇率存储在事务行，转换逻辑内置 AP 标准程序；
5. 税务：EBS Tax（EB Tax）嵌入 AP 分配行。

Fusion AP 底层原理特征

1. 业务事件驱动架构：发票创建、验证、审批、付款触发业务事件，可供外部订阅；
2. 分离：
   • 供应商主数据：Procurement Supplier BO（不在 AP 内部）
   • 税务：Global Tax Service，AP 只接收计算后的税行，不负责计税规则；
   • 银行 / 付款：Cash Management BO 独立；
3. 发票不再简单头行结构，区分：Invoice Header BO、Invoice Line BO、Invoice Distribution BO、Tax Line BO、Withholding Tax BO；
4. 核销关系不再简单一张关联表，通过结算 BO（Settlement）统一管理发票、贷项通知单、付款、预付款核销；
5. 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云总账

重大差异：

1. 审批是强制性中间节点；EBS 审批更多是控制访问，不阻塞付款（配置相关）
2. 核销逻辑抽象为 Settlement，支持多层抵销：发票、贷项、预付款、扣款、付款统一结算
3. 不存在 “付款批” 传统概念，改为付款文档 Payment Document

四、业务对象、逻辑实体、物理实体分层定义

分层标准：业务对象 BO（对外服务层） > 逻辑实体（业务模型层） > 物理实体（数据库表）

4.1 Oracle EBS AP

1）顶层业务对象（业务视角）

1. 供应商 Supplier
2. 应付发票 Invoice（标准发票、贷项通知单、借项通知单、预付款）
3. 发票分配 Invoice Distribution
4. 付款 Payment
5. 预付款 Prepayment
6. 发票付款核销 Invoice Payment Application
7. 预留 / 预扣税 Withholding Tax
8. 付款批 Payment Batch

2）逻辑实体（逻辑模型，不直接对应单表）

• 发票头逻辑实体
• 发票分配行逻辑实体
• 付款头逻辑实体
• 发票 - 付款核销关联逻辑实体
• 预付款应用逻辑实体

3）核心物理实体（后台表，All 表 = 多组织，ORG_ID 区分 OU）

EBS 特点：逻辑实体几乎和物理表一一对应，中间层薄，业务程序直接读写表。

4.2 Oracle Fusion AP

1）顶层业务对象 BO（Business Object，Fusion 一等公民）

Fusion 基于 Application Development Framework (ADF) Business Components + OSML 服务模型

1. Invoice BO（应付发票主对象）
2. Invoice Header VO（View Object）
3. Invoice Line VO
4. Invoice Distribution VO（会计分配行）
5. Invoice Tax Line VO
6. Settlement BO（结算对象：统一处理付款、贷项、预付款核销）
7. Payment BO（付款文档）
8. Withholding Tax BO

重要：供应商属于Procurement Supplier BO，不属于 AP BO，跨模块服务调用。

2）逻辑实体（逻辑数据模型 LDM）

Oracle 发布 Fusion LDM 模型中 AP 核心逻辑实体：

1. Payable Invoice
2. Payable Invoice Line
3. Payable Invoice Distribution
4. Payable Invoice Tax
5. Payable Settlement（结算核销）
6. Payable Payment
7. Payable 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 与 Line，EBS 无独立发票行）| |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 大体兼容，但会计事件类型不同）|

关键区别：

1. EBS没有独立 AP_INVOICE_LINES，发票头直接挂分配行；Fusion 引入三层结构：Header → Line → Distribution
2. Fusion 使用 AP_SETTLEMENTS 一张表统一承载所有抵销关系，EBS 分散在多张表

五、核心程序 / 并发请求、代码示例思路

5.1 Oracle EBS AP 标准并发程序（重要）

1. Payables Invoice Validation（APPRV）发票验证核心程序包：AP_PAYMENT_SCHEDULES_PKG、AP_INVOICES_PKG作用：计算付款计划、校验匹配、创建 AP_PAYMENT_SCHEDULES_ALL（付款计划！非常关键）

   AP_PAYMENT_SCHEDULES_ALL：每张发票到期付款计划，是付款选择程序的数据源

2. Payables Payment Selection 付款选择包：AP_PAY_SELECT_PKG
3. Create Payment Batch 创建付款批
4. SLA Create Accounting 创建会计分录XLA_ACCOUNTING_PUB_PKG

EBS 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 ); -- 新增发票分配行 API：AP_INVOICE_DISTRIBUTIONS_PKG -- 之后调用 AP_PAYMENT_SCHEDULES_PKG 生成付款计划 END; /

EBS 标准导入方式：AP_INVOICES_INTERFACE 接口表 → 运行【Import Invoices】并发请求

5.2 Fusion AP 程序与集成方式

Fusion 不存在客户可直接调用的后台并发请求 Package！所有业务只能通过三种途径：

1. REST API（官方推荐）
2. ADF 桌面集成器（Excel 导入）
3. 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 核心架构差异汇总

七、实施 & 开发关键落地要点

1. EBS 迁移 Fusion AP 最大改造点
   • 淘汰接口表导入方案，改用 REST API；
   • 重构预付款、贷项、发票核销逻辑，适配 Settlement 结算模型；
   • 供应商主数据迁移至 Procurement 供应商模型；
   • 税务逻辑从 AP 剥离，改为调用全局税务服务。
2. 报表开发注意
   • EBS：可基于 AP 多表关联开发自定义报表；
   • Fusion：优先使用 OTBI 分析模型，尽量避免直连后台物理表查询。
3. 会计分录迁移重点 SLA 会计事件类别（Event Class）两代存在差异，会计规则需要重新配置，不能直接迁移 XLA 设置。