企业官网建设流程全解析

Oracle EBS R12 AP：业务对象与逻辑实体完整关系解析

前置核心定义（区分两层概念，避免和 Fusion BO 混淆）

业务对象 Business Object（业务层视角）面向用户业务流程、UI 单据、业务生命周期，是业务人员认知的 “单据 / 档案”；一个业务对象由多个逻辑实体「组合 / 聚合」构成，业务对象本身不直接映射数据库表。 关系类型遵循 UML：组合（Composition）、聚合（Aggregation）、关联（Association）

• 组合：子实体不能脱离父业务对象独立存在，父销毁子随之失效（发票头→发票行）
• 聚合：子实体可以独立存在，仅临时归属（付款批包含多张付款）
• 关联：双向松散引用（供应商 ↔ 发票）

逻辑实体 Logical Entity（数据模型 ETRM/ERD 视角）独立具备唯一主键、业务语义的数据单元；R12 EBS AP 特征：绝大多数逻辑实体一对一映射一张XXX_ALL物理表，承载数据存储、业务约束、外键关联。

层级链路：业务对象（单据） → [组合 / 聚合] → 多个逻辑实体 → 物理表（All 表）

⚠️关键区别： Fusion：BO 是一等公民（服务层），BO 内部封装 VO 逻辑视图； EBS：没有服务层 BO，业务对象 = 业务单据概念；逻辑实体 = ER 实体，紧贴数据库。

一、三大关系类型在 AP 中的落地释义

1. 组合关系（强包含，生命周期绑定）例：应付发票【业务对象】组合包含：发票头逻辑实体、发票行逻辑实体、发票分配逻辑实体； 没有发票头，发票行、分配行没有业务意义。
2. 聚合关系（弱包含，容器与成员）例：付款批【业务对象】聚合多张付款逻辑实体； 删除付款批，付款单据本身仍然保留，可被其他付款批重新选取。
3. 关联关系（双向引用，平等主体）例：供应商【业务对象】 ↔ 应付发票【业务对象】； 双方可独立创建、独立存在，依靠外键建立关联。

二、核心业务对象 → 构成逻辑实体映射 + 关系说明

1）业务对象：应付发票 Invoice（AP 最核心）

关系类型：组合关系业务对象由以下逻辑实体强组合而成，缺一不可：

1. 发票头（Invoice Header）【主逻辑实体，根】
2. 发票行（Invoice Line）
3. 发票会计分配（Invoice Distribution）
4. 付款计划（Payment Schedule）
5. 发票暂挂（Invoice Hold）【可选组合】

内部实体间关系

• 1 发票头一对多发票行（组合）
• 1 发票行一对多发票分配（组合）
• 1 发票头一对多付款计划（组合，验证后系统自动生成）
• 1 发票头一对多发票暂挂（组合，可选）

业务规则体现：发票保存，先创建发票头→发票行→分配行； 运行【发票验证 APPRV】，自动生成付款计划； 匹配异常自动新增暂挂逻辑实体。

特殊子类：预付款发票（Prepayment） 依然属于【应付发票业务对象】，在原有组合基础上聚合扩展逻辑实体：预付款扩展属性（AP_PREPAYMENTS_ALL）新增关联逻辑实体：预付款应用历史（Prepayment History），用于记录预付款冲抵标准发票。

2）业务对象：付款 Payment（Check）

关系类型：组合关系构成逻辑实体：

1. 付款头（Payment / Check）【主实体】
2. 发票付款核销（Invoice Payment）【组合子实体】

内部关系： 1 付款一对多发票付款核销记录 一条付款可以同时核销多张发票；核销记录不能脱离付款、发票单独存在。

3）业务对象：付款批 Payment Batch（EBS 独有容器对象）

关系类型：聚合关系构成逻辑实体：

1. 付款批头（Payment Batch）【容器实体】
2. 多条付款 Payment 逻辑实体

聚合特征： 付款批只是 “临时选取容器”；付款本身是独立业务对象。 删除付款批，付款单据依然保留；付款可以脱离付款批独立存在。

4）业务对象：供应商 Supplier（主数据业务对象）

关系类型：聚合 + 关联构成逻辑实体：

1. 供应商头 Supplier
2. 供应商地点 Supplier Site（聚合子实体）

关联关系： 1 供应商 → 多个供应商地点；供应商地点 关联 应付发票头（发票必须绑定供应商地点，不是供应商头）。

5）业务对象：发票暂挂 Invoice Hold

既可以作为应付发票业务对象内部组合子实体； 也可以单独作为业务管控对象对外查询。

6）业务对象：预付款应用 Prepayment Application

属于跨发票业务对象的关联关系预付款发票（Invoice） ↔ 标准发票（Invoice） 依靠「预付款历史 Prepayment History」逻辑实体建立双向关联。

三、全景关系分层图谱（文字 ER 语义）

第一层：主数据业务对象之间【关联关系】

供应商（BO） 1→N 供应商地点（逻辑实体） 供应商地点（逻辑实体） 1→N 应付发票（BO）

第二层：应付发票业务对象【内部组合链】

应付发票BO └──【组合】发票头(LE) 1→N 发票行(LE) └──【组合】发票行(LE) 1→N 发票分配(LE) └──【组合】发票头(LE) 1→N 付款计划(LE) └──【组合】发票头(LE) 1→N 发票暂挂(LE) 【预付款发票扩展】 应付发票BO（类型=Prepayment） └──【聚合】预付款扩展属性(LE) └──【关联】预付款历史(LE) ←→ 另一张应付发票BO

第三层：付款业务对象 + 付款批容器

付款批BO（聚合容器） └──【聚合】多条付款BO 付款BO └──【组合】付款头(LE) 1→N 发票付款核销(LE) 发票付款核销(LE) 双向关联 → 付款计划(LE)（归属应付发票BO）

四、极易混淆的重点关系辨析（实施 / 开发高频踩坑点）

辨析 1：为什么「付款计划」属于应付发票内部组合实体，而不是付款实体？

• 付款计划由发票验证程序生成，归属发票生命周期；
• 付款程序读取付款计划选取待支付负债；
• 付款只是 “清偿动作”，不产生负债；负债载体永远在发票内部。

业务语义：负债属于发票，付款只是结清负债的操作。

辨析 2：核销实体（AP_INVOICE_PAYMENTS_ALL）归属？

属于【付款业务对象】的组合子实体一条付款产生多条核销记录； 核销记录外键同时指向：CHECK_ID（付款）+ PAYMENT_SCHEDULE_ID（发票付款计划），实现两个业务对象之间的桥接。

辨析 3：发票行 VS 发票分配行两层组合关系

R12 E-Business Tax 引入强制分层：

1. 发票行（Invoice Line）：承载商务明细、商品、税费信息（业务明细层）
2. 发票分配（Distribution）：承载会计科目、CCID、成本分摊（财务核算层） 一条发票行可以分摊到多个科目，因此1 行 → N 分配； 二者都属于发票业务对象内部组合实体。

11i 遗留习惯：很多实施跳过发票行，直接录入分配行；R12 税务场景必须启用两层结构。

辨析 4：组合 vs 聚合实务区分

✅组合（发票头→发票行）删除发票头，系统级联删除行、分配、付款计划、暂挂；子实体没有独立生命周期。

✅聚合（付款批→付款）删除付款批，付款记录保留；付款可以被重新挑选进入新付款批。

五、业务对象跨对象交互关系（端到端 P2P 流程视角）

1. 创建【应付发票 BO】→生成内部全套逻辑实体
2. 验证发票 → 自动生成付款计划 LE
3. 创建【付款批 BO】，选取满足条件的付款计划
4. 生成【付款 BO】，自动创建【发票付款核销 LE】建立负债结清关系
5. 运行创建会计程序：读取发票分配 LE、付款 LE，推送 SLA 生成分录

数据流本质：业务对象之间不直接关联，依靠底层逻辑实体作为桥梁业务对象只是面向使用者的概念；系统底层数据联动全部依靠逻辑实体之间的外键约束。

六、对比 Fusion 关键差异（方便你前后知识串联）

1. EBS 业务对象 ←【组合 / 聚合】→ 逻辑实体 ≈ 物理表；逻辑实体是数据交互核心；没有独立服务层，程序直接操作逻辑实体对应的表。
2. Fusion BO（顶层服务对象） ← VO 逻辑视图 ← 物理表； 不存在 “业务对象组合多个逻辑实体” 这种 EBS 经典分层； 核销统一封装为 Settlement BO，不再拆分分散的核销实体。