Oracle EBS 与 Oracle Fusion 在应付（AP）模块的设计上，既体现了企业级财务软件一脉相承的核心逻辑，又因技术架构的代际差异展现出了截然不同的实现方式。以下为您详细拆解两者在设计哲学、底层逻辑、数据模型及后台程序上的深度对比。
一、 设计哲学与核心原理对比
1. Oracle EBS AP：流程驱动与单据驱动会计
EBS 的应付模块秉承“先业务、后财务”的哲学。其核心原理是单据驱动会计，即所有的会计分录都不允许手工直接录入总账，而是必须由发票、付款等底层业务单据自动生成。
- 严格三单匹配：强制采购订单（PO）、收货单（Receipt）与发票（Invoice）的闭环校验，支持部分匹配与跨期间匹配，以控制超收超付。
- 弹性域（Flexfield）架构：通过 COA 弹性域（如公司段、成本中心、自然科目等）自动推导会计科目，实现多维度核算。
- 三权分立：在 R12 版本中，EBS 将业务层（AP模块）、支付层（Oracle Payments）和核算层（SLA 子分类账）进行了清晰的职责分离。
2. Oracle Fusion AP：云原生与事件驱动
Fusion 采用云原生微服务架构，其设计哲学更倾向于事件驱动与配置化。
- 服务化与解耦：业务逻辑下沉至云端服务，例如税务计算不再同步阻塞，而是通过消息队列异步触发 Tax 微服务进行计税，实现非阻塞执行。
- 禁止底层篡改：SaaS 模式下禁止直接操作底层物理表或编写自定义 PL/SQL 修改核心业务逻辑，所有扩展必须通过标准 API、REST 接口或 SLA 规则配置实现。
- AI 与自动化：内置智能单据识别（IDR）与 AI Agent，实现多渠道发票自动解析、三单匹配、欺诈校验及审批路由，大幅减少人工干预。
二、 业务对象 → 逻辑实体 → 物理实体映射
在数据模型理念上，EBS 与 Fusion 一脉相承，但在物理表命名和存储架构上存在差异。
1. 核心应付单据与供应商
| 逻辑实体 | 业务对象说明 | EBS 物理实体 (后台表) | Fusion 物理实体 (后台表/视图) |
|---|---|---|---|
| 发票头 | 记录供应商、金额、币种等 | AP_INVOICES_ALL | AP_INVOICES_ALL |
| 发票行 | 物料、服务、税费明细 | AP_INVOICE_LINES_ALL | AP_INVOICE_LINES_ALL |
| 发票分配 | 会计维度、金额、科目组合 | AP_INVOICE_DISTRIBUTIONS_ALL | AP_INVOICE_DISTRIBUTIONS_ALL |
| 付款计划 | 发票的到期日与付款状态 | AP_PAYMENT_SCHEDULES_ALL | AP_PAYMENT_SCHEDULES_ALL |
| 付款/支票 | 实际资金支付单据 | AP_CHECKS_ALL | AP_CHECKS_ALL |
| 供应商主数据 | 供应商头信息 | AP_SUPPLIERS | POZ_SUPPLIERS |
| 供应商地点 | 供应商结算/开票地址 | AP_SUPPLIER_SITES_ALL | POZ_SUPPLIER_SITES_ALL_M |
2. SLA 子分类账（贯穿所有模块的会计引擎）
SLA 是业务单据转化为总账凭证的桥梁。EBS 与 Fusion 的 XLA 表结构基本一致，但 Fusion 增加了 Supporting Reference 等概念以支持不扩 COA 段情况下的多维余额核算。
| 逻辑实体 | EBS 物理实体 | Fusion 物理实体 |
|---|---|---|
| 事务实体 | XLA_TRANSACTION_ENTITIES | XLA_TRANSACTION_ENTITIES |
| 会计事件 | XLA_EVENTS | XLA_EVENTS |
| 子分类账头 | XLA_AE_HEADERS | XLA_AE_HEADERS |
| 子分类账行 | XLA_AE_LINES | XLA_AE_LINES |
| 分配链接 | XLA_DISTRIBUTION_LINKS | XLA_DISTRIBUTION_LINKS |
三、 核心业务处理逻辑与后台程序示例
1. 发票校验与会计创建 (Invoice Validation & Accounting)
- EBS 实现：采用传统的并发程序（Concurrent Request）。发票验证（Validation）会执行三单匹配、税额计算及暂挂（Hold）检查；随后运行“创建会计科目（Create Accounting）”程序，调用底层 PL/SQL 包将分配行（Distributions）转化为 SLA 分录。
- Fusion 实现：采用 ESS（企业调度服务）替代并发管理器。业务单据保存后，通过消息队列发布异步事件，Tax 和 SLA 微服务消费事件并自动完成计税与记账，前端无需等待后台批处理完成。
2. 付款处理 (Payment Processing)
- EBS 实现：采用“指令化”架构。通过付款挑选请求（PPR）筛选符合条件的发票，生成付款批（Payment Batch），底层写入
AP_CHECKS_ALL表。随后调用 Oracle Payments 模块进行报文格式化（Format）和传输（Transmit）。 - Fusion 实现：提供高级支付管理与自动化付款运行，内置 Payments Agent 协助优化现金流出、评估动态折扣，并直接与银行系统交互实现供应商快速入驻与支付确认。
3. 税务与预扣税处理 (Tax & Withholding)
- EBS 实现：eBTax 引擎在发票保存或验证时同步执行 PL/SQL 逻辑，预扣税（Withholding Tax）通常作为单独的分配行或暂估逻辑处理。
- Fusion 实现：原生一体化实现。预扣税与普通流转税共用 Regime-Tax 架构，通过 Bucket 计税桶自动按周期（月/季/年）累计应付基数，超阈值自动追溯计算，无需二次开发。
四、 总结
Oracle EBS 的应付模块建立在高度开放的本地化数据库之上，其“物理表+PL/SQL并发程序”的模式赋予了企业极高的定制自由度，但同时也带来了系统耦合度高、升级维护成本大的问题。
相比之下，Oracle Fusion 的应付模块则彻底拥抱了云原生架构。它通过“微服务+消息队列+REST API”重构了底层逻辑，将复杂的业务规则（如税务、会计推导）封装在云端标准服务中。虽然在物理表层面保留了与 EBS 相似的命名习惯（如AP_INVOICES_ALL），但其严禁直接 DML 操作，强制企业通过标准化配置和 API 进行集成，从而实现了更高的安全性、可扩展性以及 AI 时代的智能化升级。
