企业官网建设流程全解析

Oracle EBS 与 Fusion 应付模块（Payables / AP）
主要业务对象 · 后台表 · ER 关系分析

面向实施、报表、迁移与集成的视角：先厘清业务对象与关系链，再讨论物理表；区分 EBS 可直接访问的_ALL基表与 Fusion 中"文档化数据对象 ≠ 稳定 API"的 SaaS 访问边界。

版本口径：EBS 12.2 / Fusion 25C–26C信息截至 2026-10-04单文件离线可读

1结论摘要

• 业务对象连续，物理模型不连续。EBS 与 Fusion 共用"供应商 → 供应商站点 → 发票头 → 发票行 → 发票分配 → 分期付款 → 付款"主干，Fusion 并非把 EBS 表原样搬到云上，而是将其封装为业务对象、REST 服务、PVO/BICC 抽取层与 OTBI 分析层。
• 分配（Distribution）是会计入口，行（Line）是业务明细。对账与迁移应以分配口径汇总，不能用发票行金额替代。
• 三单匹配发生在分配层级。发票头的PO_HEADER_ID只是快速入口，真正把金额与数量带入 PO-收货-发票匹配的，是AP_INVOICE_DISTRIBUTIONS_ALL.PO_DISTRIBUTION_ID。
• 付款是多对多桥接。一笔 payment 可覆盖一张发票的多个 installment，也可在合并付款中覆盖多张发票，故付款金额不能下沉为发票行的简单属性。
• 访问契约不同。EBS 可直连 APPS 视图与_ALL表；Fusion 的AP_INVOICES_ALL等虽被数据字典列为 TABLE，但生产集成应优先 REST、受支持 PVO/BICC 与 OTBI，禁止对未公开基表 DML。

口径提醒：本文所称_ALL表指应用 schema 中以_ALL结尾、通常保留跨组织数据的基表。EBS 中常通过去掉_ALL的 APPS 视图按职责/Multi-Org 策略过滤ORG_ID；Fusion 虽有同名对象，却不能据此推断客户可直接连接底层库或某列在未来版本不变。

2应付模块主要业务对象全景

无论 EBS 还是 Fusion，Payables 都围绕同一组业务对象运转。下表按"主数据 → 交易 → 结算 → 会计"四层排列。

3EBS Payables：业务对象与主要后台表

EBS R12 的供应商主数据已迁移到 TCA（Trading Community Architecture）：AP_SUPPLIERS记录应付/采购特有属性，AP_SUPPLIER_SITES_ALL记录站点级业务规则，PARTY_ID将其挂到HZ_PARTIES这一通用当事人实体。老式PO_VENDORS/PO_VENDOR_SITES_ALL在 11i 以前是表，R12 起已被 AP 新表及兼容视图取代。

银行信息跨产品域：内部银行账户在 Cash Management 的CE_BANK_ACCOUNTS域，外部供应商银行通过 Oracle Payments 的付款人（IBY_EXTERNAL_PAYEES_ALL）与付款工具使用（IBY_PMT_INSTR_USES_ALL）链接到供应商 party/party site。只连AP_SUPPLIER_SITES_ALL会遗漏未挂站点、分配给 supplier party 或仅在特定组织生效的账户使用记录。同一账户可被多个站点共享且存在生效日期，应按"账户使用关系"去重。

4EBS 四条核心 ER 关系链

4.1 供应商 — 站点 — 银行账户

逻辑关联：一个当事人（Party）可服务于多个业务上下文（Site），一个 Site 可关联多个付款工具使用

HZ_PARTIES

• PARTY_ID (PK)
• party_name
• party_type

├─ PARTY_ID ─┤

AP_SUPPLIERS

• VENDOR_ID (PK)
• PARTY_ID (FK)
• vendor_type

├─ VENDOR_ID ─┤

AP_SUPPLIER_SITES_ALL

• VENDOR_SITE_ID
• VENDOR_ID
• PARTY_SITE_ID
• TERMS_ID

HZ_PARTY_SITES

• PARTY_SITE_ID
• PARTY_ID
• LOCATION_ID

├─ PARTY_SITE_ID ─┤

IBY_EXTERNAL_PAYEES_ALL

• EXT_PMT_PARTY_ID
• PAYEE_PARTY_ID
• SUPPLIER_SITE_ID

├─ EXT_PMT_PARTY_ID ─┤

IBY_PMT_INSTR_USES_ALL

• INSTRUMENT_USE_ID
• EXT_PMT_PARTY_ID
• INSTRUMENT_ID

├─ INSTRUMENT_ID ─┤

IBY_EXT_BANK_ACCOUNTS

• EXT_BANK_ACCOUNT_ID
• bank_account_num
• currency_code

通用主数据 (TCA)AP / CE 域Oracle Payments (IBY)│ 为逻辑关联，非穷尽数据库外键

4.2 发票 — 行 — 分配 — GL（分配是会计入口）

AP_INVOICES_ALL

• INVOICE_ID (PK)
• INVOICE_NUM
• VENDOR_ID
• ACCTS_PAY_CODE_COMBINATION_ID

├─ INVOICE_ID ─┤

AP_INVOICE_LINES_ALL

• INVOICE_ID + LINE_NUMBER
• LINE_TYPE
• QUANTITY / UNIT_PRICE

├─ INVOICE_ID, LINE_NUMBER ─┤

AP_INVOICE_DISTRIBUTIONS_ALL

• INVOICE_DISTRIBUTION_ID
• INVOICE_ID
• DIST_CODE_COMBINATION_ID
• PO_DISTRIBUTION_ID

├─ DIST_CODE_COMBINATION_ID ─┤

GL_CODE_COMBINATIONS

• CODE_COMBINATION_ID
• SEGMENT1..n
• CONCATENATED_SEGMENTS

一行可有多条分配，一条分配原则上服务于一个会计组合。发票金额可从行、分配、税、付款状态多个角度聚合；分期付款、折扣、部分支付、预付款应用、贷项通知单与作废支付都会改变口径，不能把"发票头金额 ≠ 分配总额"直接判为错误。

4.3 发票 — 付款计划 — 付款（多对多桥接）

AP_INVOICES_ALL

• INVOICE_ID

├─ INVOICE_ID ─┤

AP_PAYMENT_SCHEDULES_ALL

• INVOICE_ID + PAYMENT_NUM
• DUE_DATE
• GROSS_AMOUNT
• AMOUNT_REMAINING

├─ INVOICE_ID, PAYMENT_NUM ─┤

AP_INVOICE_PAYMENTS_ALL

• INVOICE_PAYMENT_ID
• INVOICE_ID
• PAYMENT_NUM
• CHECK_ID
• AMOUNT

├─ CHECK_ID ─┤

AP_CHECKS_ALL

• CHECK_ID
• CHECK_NUMBER
• CHECK_DATE
• STATUS_LOOKUP_CODE

桥表AP_INVOICE_PAYMENTS_ALL是"发票分期付款"与"付款头"的核销事实。Fusion 的 PVOPaidDisbursementScheduleExtractPVO以ApInvoicePaymentsAllInvoicePaymentId为数据存储键，并公开ApInvoicePaymentsAllInvoiceId、ApInvoicePaymentsAllCheckId，说明"付款发票关联"仍是可抽取、可分析的稳定对象。

4.4 发票 — PO — 收货（三单匹配下钻到分配）

PO_HEADERS_ALL

• PO_HEADER_ID
• SEGMENT1 (PO_NUM)

├─ PO_HEADER_ID ─┤

PO_LINES_ALL

• PO_LINE_ID
• PO_HEADER_ID

├─ PO_LINE_ID ─┤

PO_LINE_LOCATIONS_ALL

• LINE_LOCATION_ID
• SHIPMENT_NUM

├─ LINE_LOCATION_ID ─┤

PO_DISTRIBUTIONS_ALL

• PO_DISTRIBUTION_ID
• CODE_COMBINATION_ID

AP_INVOICE_DISTRIBUTIONS_ALL

• INVOICE_DISTRIBUTION_ID
• PO_DISTRIBUTION_ID

├─ PO_DISTRIBUTION_ID ─┤

RCV_TRANSACTIONS

• TRANSACTION_ID
• TRANSACTION_TYPE
• PO_DISTRIBUTION_ID
• QUANTITY

匹配校验必须下钻：两阶段匹配链路为 PO distribution → receipt（RCV_TRANSACTIONS.PO_DISTRIBUTION_ID）→ AP 发票分配。仅比较"发票总额 vs PO 总额"无法定位价格差异、数量差异、未入账收货与回冲。

5Fusion Payables Cloud：业务对象优先，物理表次之

Fusion 的公开契约首先是业务对象与视图对象，而不是裸表。26C 的PayablesInvoiceTransaction业务对象包含supplier、supplierSite、purchaseOrderMatchedFlag、币种/汇率与审批状态；PayablesInvoiceLine表示一行可有多条分配；PayablesInvoiceDistribution直接持有poDistributionId。目标映射应写"发票业务对象 — 发票行对象 — 分配对象 — 采购订单分配"，而非从物理表名反推业务键。

Fusion 25D/26A 的Tables and Views for Financials将AP_INVOICES_ALL列为 FUSION schema 下 AP 拥有的TABLE，主键INVOICE_ID；AP_INVOICE_LINES_ALL主键(INVOICE_ID, LINE_NUMBER)；AP_INVOICE_PAYMENTS_ALL主键INVOICE_PAYMENT_ID。因此在物理数据探索、BICC lineage 核对或迁移源分析时可确认这些名称存在；但"文档化数据对象"不自动等于客户可安全更新的应用 API，不能据列名执行UPDATE/DELETE。

供应商更彻底地是 party + 业务关系：底层仍可见HZ_PARTIES、HZ_PARTY_SITES，但客户映射应以"Party ID + Party Site ID + Supplier/Site 业务键"为组合主键，不能假定 EBS 的VENDOR_ID/VENDOR_SITE_ID与 Fusion 内部数值 ID 可直接复用。Oracle 官方社区亦明确：不存在普适的一对一映射层，PVO 是预连接、抽象化的视图层，而非物理表等价物。

付款由 Payments 服务统一编排：Payables 的 PPR（Payment Process Request）选择应付分期付款形成 document payable；每个 document payable 必须获得 disbursement bank account 与 payment process profile 后才能进入验证。生命周期为 待处理 → 提议 → 确认/打印 → 电子支付文件传输或纸质付款文件打印 → 银行对账。故完整支付链路是：Payables installment → Payments document payable → PPR/profile → payment instruction/file → payment → 银行对账。

6从 EBS 到 Fusion：数据模型的四层演进

7数据核对与迁移：典型查询 SQL 片段

以下为逻辑片段，非完整产品报表。表别名中的AP/PO/RCV/CE/GL/IBY/HZ需按实际 EBS schema / 同义词调整。Fusion 仅在具备底层 SQL 访问权限的环境参考，生产替代方案为 REST / PVO / BICC。金额需考虑币种、汇率、折扣、作废、预付款应用与会计状态。

7.1 发票 — 行 — 分配 — GL 汇总

SELECT ai.invoice_id, ai.invoice_num, ai.vendor_id, SUM(aid.amount) AS distribution_total, aid.dist_code_combination_id, gcc.concatenated_segments AS account FROM ap_invoices_all ai JOIN ap_invoice_distributions_all aid ON aid.invoice_id = ai.invoice_id LEFT JOIN gl_code_combinations gcc ON gcc.code_combination_id = aid.dist_code_combination_id WHERE ai.invoice_id = :invoice_id GROUP BY ai.invoice_id, ai.invoice_num, ai.vendor_id, aid.dist_code_combination_id, gcc.concatenated_segments;

7.2 发票 — 分期付款 — 付款 — 付款头

SELECT ai.invoice_id, ai.invoice_num, aps.payment_num, aps.gross_amount, aps.amount_remaining, aip.invoice_payment_id, aip.amount AS payment_amount, ac.check_id, ac.check_number, ac.status_lookup_code FROM ap_invoices_all ai JOIN ap_payment_schedules_all aps ON aps.invoice_id = ai.invoice_id JOIN ap_invoice_payments_all aip ON aip.invoice_id = ai.invoice_id AND aip.payment_num = aps.payment_num JOIN ap_checks_all ac ON ac.check_id = aip.check_id WHERE ai.invoice_id = :invoice_id;

7.3 PO / 收货匹配下钻

SELECT ai.invoice_id, aid.invoice_distribution_id, aid.amount, aid.po_distribution_id, pd.po_header_id, pd.po_line_id, pd.line_location_id, rt.transaction_id, rt.transaction_type, rt.quantity FROM ap_invoice_distributions_all aid JOIN po_distributions_all pd ON pd.po_distribution_id = aid.po_distribution_id LEFT JOIN rcv_transactions rt ON rt.po_distribution_id = pd.po_distribution_id JOIN ap_invoices_all ai ON ai.invoice_id = aid.invoice_id WHERE ai.invoice_id = :invoice_id;

7.4 供应商 — 站点 — 银行账户使用关系（EBS）

SELECT s.vendor_id, s.vendor_name, ss.vendor_site_id, ss.vendor_site_code, iue.ext_pmt_party_id, eba.ext_bank_account_id, eba.bank_account_num, eba.currency_code, iue.payment_function FROM ap_suppliers s JOIN ap_supplier_sites_all ss ON ss.vendor_id = s.vendor_id JOIN iby_external_payees_all ep ON ep.payee_party_id = s.party_id AND ep.supplier_site_id = ss.vendor_site_id JOIN iby_pmt_instr_uses_all iue ON iue.ext_pmt_party_id = ep.ext_pmt_party_id JOIN iby_ext_bank_accounts eba ON eba.ext_bank_account_id = iue.instrument_id WHERE s.vendor_id = :vendor_id;

7.5 Fusion：可公开表达的关联逻辑（BICC / PVO，非直接表 SQL）

PayablesInvoiceHeaderPVO.INVOICE_ID = PayablesInvoiceLinePVO.INVOICE_ID = PayablesInvoiceDistributionPVO.INVOICE_ID PayablesInvoiceDistributionPVO.PO_DISTRIBUTION_ID = PurchaseOrderDistributionExtractPVO.PO_DISTRIBUTION_ID PaidDisbursementScheduleExtractPVO.ApInvoicePaymentsAllInvoicePaymentId -> PayablesPaymentPVO.CHECK_ID

上述 Fusion 片段表示 BICC/PVO 之间可观察的业务键关系，不是 Oracle 保证的 SQL 列名。生产实现应在目标环境的 BICC lineage 中核对 PVO、属性、增量抽取键及可用版本；不可因 EBS 与 Fusion 的_ALL表名相同而拼接同名 JOIN。

8对账、数据质量与迁移建议

• 建立"业务键 + 系统键 + 会计键"三套映射。EBS→Fusion 或反向集成不应只映射INVOICE_ID：业务上保留供应商编号、站点代码、PO 号、发票号、报销单号、付款参考；技术上保存各系统内部 ID；会计上保存 ledger、会计日期、期间、CCID、SLA 事件与 GL 日记账。这样才能解释"同一单据两系统 ID 不同但金额与状态一致"。
• 四条关系链分别设对账断点：
  • 供应商链：party/site 是否停用、银行账户是否覆盖、币种与主账户是否唯一；
  • 发票链：发票总额、行总额、分配总额及税/折扣差异；
  • 付款链：分期付款总额、选中付款金额、付款文件金额、支付状态、银行对账金额；
  • PO 链：PO 承诺、收货、发票匹配、价格/数量差异与回冲。
  只跑一个总应付余额无法定位差异来自匹配、预付款、汇率还是会计日期。
• Fusion 公开访问形成三层策略：操作型集成用 REST/Web 服务；分析报表用 OTBI 或正式主题区；批量历史抽取用 BICC/PVO，并通过 Oracle 发布的 VO-to-database lineage 识别真实底层表。未公开基表、内部审计表、中间处理表及 FND 元数据表只能在隔离环境观察。
• 保留版本与 lineage 快照。Fusion 表与视图文档按版本发布（本文核对 25C/25D/26A/26C 部分对象），PVO 支持可能随发布增减。实施档案应保存文档版本、提取日期、BICC lineage 文件、对象/属性哈希、查询责任人与允许用途。
• 代扣税、预付款、费用报销是独立生命周期，不是发票的普通行。代扣税应在验证或付款时计算，生成 withholding 类型行并更新分期未付金额；报表须区分供应商应付毛额、withholding 金额、实际净付款与 tax authority 应付，避免重复计入"供应商负债"。预付款是独立发票类型（Temporary 可应用、Permanent 不冲销），两张发票之间由 application/prepay history 连接，查询净应付须考虑已应用/未应用余额、应用日期与冲销记录。费用报销要把员工变为受供应商流程约束的收款人，须保存 费用报表 ID → 生成发票 ID → 员工/当事人 ID → 预付款应用 的闭环追溯。
• 期间不是单一 AP 状态字段。Fusion 建议仅在期间交易已创建分录并转入总账后关闭应付期间；关闭前须完成交易与付款文件、核对银行活动、处理未入账交易，并可运行Unaccounted Transactions and Sweep将允许滚动的未入账交易改到下一开放期间。应把AP_INVOICE_DISTRIBUTIONS_ALL.GL_DATE / PERIOD_NAME、付款会计期间、SLA 创建会计/过账状态与 GL 期间分开看待；只检查AP_INVOICES_ALL.PAYMENT_STATUS_FLAG无法证明总账已闭环。

8bEBS 关键表字段速查（字段级 ER）

下表给出四条关系链中"必须知道"的字段及其角色。PK为主键，FK为外键/关联键，AK为业务 alternate key。注意：Oracle 并非总以数据库外键约束实现这些关联（尤其跨产品域的 IBY/CE/HZ），应用层保证引用完整性。

8b.1 供应商与站点

8b.2 发票、行、分配、付款计划

8b.3 付款与核销

8b.4 采购与收货（三单匹配上游）

8b.5 会计、税与预付款

8b.6 Fusion 侧对象对照（业务对象 / PVO ↔ 物理表名）

不要把同名当成同义：EBS 与 Fusion 的AP_INVOICES_ALL名称相同、主键语义相近，但列集合、隐藏分区、审计列、策略谓词与可访问性完全不同。跨代 JOIN 必须用业务键（供应商编号 + 站点代码 + 发票号 + 业务单元 + 账册 + 会计日期）配对，绝不能拼接INVOICE_ID数值。

9信息截至日期、来源与局限

信息截至2026 年 10 月 4 日。EBS 以 12.2 系列公开参考材料为主；Fusion 以 25C、25D、26A、26C 的公开文档与数据字典为主。两产品均随版本更新，Fusion 变化尤其频繁。

• 未获得一个统一、同时覆盖两代系统全部字段与数据库约束的官方"single source of truth"；EBS 12.2 Payables Reference Guide 的公开章节主要说明接口、PO matching 与 SLA 设置，并不自动等于逐列技术手册。
• Fusion 的AP_INVOICES_ALL等对象虽被官方数据字典列为TABLE，Oracle 未在所用材料中发布可视为客户稳定升级契约的"全部基表及全部外键清单"。FND、SLA/XLA、IBY、CE、Tax、Party 的内部表可能随版本、部署架构或 patch 变化。
• 社区材料中的 EBS→Fusion PVO 映射表不是 Oracle 官方稳定承诺，未被当作一对一迁移事实。
• 未对客户实际数据库执行查询，也未访问任何 Oracle SaaS 租户；SQL 属逻辑片段。EBS 银行表链与 SLA 内部表因 patch/架构可能变化，落地前须在目标环境用 eTRM / BICC lineage 复核表与列；用于生产开发应以 Oracle 官方 REST / PVO / BICC 文档及 Oracle Support 答复替代对未公开基表的直接依赖。