企业官网建设流程全解析

Oracle EBS R12 AP：业务对象 (BO) ↔ 逻辑实体 (LE) 完整关系详解

重要前置概念界定（EBS 特有语境，请勿直接套用 Fusion BO 模型）

1. 业务对象 Business Object（BO）面向业务流程、用户界面、业务生命周期的业务概念模型，对应操作员看到的单据 / 档案； BO 本身没有数据库表，由一个或多个逻辑实体通过【组合 / 聚合 / 关联】组装而成。
2. 逻辑实体 Logical Entity（LE）ETRM/Oracle ERD 数据模型中的数据单元，具备唯一主键、业务约束、外键关系； R12 AP 典型特征：绝大多数逻辑实体一对一映射一张XXX_ALL物理表，是系统底层数据载体。
3. 三种核心关联语义（遵循 Oracle ETRM 建模规范）

• 组合 Composition（强包含）子逻辑实体生命周期依附父 BO；父 BO 删除，子实体级联删除，不能独立存在。

示例：应付发票 BO「包含」发票头、发票分配行。

• 聚合 Aggregation（弱包含）容器 BO 仅仅是逻辑分组，内部成员实体拥有独立生命周期；删除容器，成员实体保留。

示例：付款批 BO 聚合多条付款 BO。

• 关联 Association（平等引用）两个独立 BO 互相引用，彼此生命周期互不绑定，依靠外键建立联系。

示例：供应商 BO ↔ 应付发票 BO。

1. 层级传导链路业务对象BO →[组合/聚合]→ 逻辑实体LE → 物理表XXX_ALL

一、逐个核心业务对象拆解：BO 内部 LE 构成 + 实体间关系

1. BO：应付发票 Invoice（核心 BO）

关系类型：组合关系（强包含） 所有子逻辑实体脱离发票头则无独立业务意义

组成逻辑实体清单

BO 内部 LE 之间拓扑关系

1 发票头 → 一对多 → 发票行 1 发票行 → 一对多 → 发票分配（一行可分摊多个科目） 1 发票头 → 一对多 → 付款计划（支持分期支付） 1 发票头 → 一对多 → 发票暂挂

特殊子类：预付款发票（Invoice_Type=PREPAYMENT）

在基础组合之上，聚合扩展逻辑实体：

• 预付款扩展属性 Prepayment（AP_PREPAYMENTS_ALL） 新增跨单据关联逻辑实体：
• 预付款历史 Prepayment History（AP_PREPAY_HISTORY_ALL）

作用：记录预付款发票 ↔ 标准发票之间的核销关系，属于跨 BO 关联桥梁

关键结论：预付款不是独立 BO，是应付发票 BO 的类型化子类。

2. BO：付款 Payment（Check）

关系类型：组合关系

组成逻辑实体清单

内部拓扑

1 付款头 → 一对多 → 发票付款核销 ✅发票付款核销是关键桥接实体外键同时关联：CHECK_ID(付款) + PAYMENT_SCHEDULE_ID(发票付款计划)实现【付款 BO】与【应付发票 BO】两大顶层业务对象之间的关联。

3. BO：付款批 Payment Batch（EBS 独有容器 BO）

关系类型：聚合关系（弱包含）

组成逻辑实体

• 付款批头 Payment Batch（AP_PAYMENT_BATCHES_ALL） 聚合多个【付款 BO】

聚合特征重点区分

付款批只是批量作业临时容器：

1. 删除付款批，付款逻辑实体不会被级联删除；
2. 一张付款可以脱离原付款批，再次被选入新付款批；
3. 付款拥有独立生命周期，不依附付款批。

对比：组合关系会级联删除；聚合不会。

4. BO：供应商 Supplier（主数据 BO）

关系类型：聚合关系

组成逻辑实体

• 供应商头 Supplier（AP_SUPPLIERS）
• 供应商地点 Supplier Site（AP_SUPPLIER_SITES_ALL）

拓扑：1 供应商头 → 一对多 → 供应商地点 业务强规则：应付发票必须绑定供应商地点，不能直接绑定供应商头因此：【供应商地点 LE】成为「供应商 BO」关联「应付发票 BO」的桥梁。

5. BO：预付款应用 Prepayment Application

不属于单据 BO，是跨 BO 业务动作对象不拥有专属根实体，依靠两个逻辑实体承载：

1. 预付款历史 Prepayment History（关联预付发票 & 标准发票）
2. 标准发票新增反向发票分配行（抵减负债）

链路：预付款发票 BO ←【预付款历史 LE】→ 标准应付发票 BO

6. BO：发票暂挂 Invoice Hold

两种定位：

1. 作为【应付发票 BO】内部可选组合子实体；
2. 独立管控视角下可作为查询业务对象； 底层唯一载体：发票暂挂 LE（AP_HOLDS_ALL）

7. BO：发票批 Invoice Batch

批量导入管控 BO 逻辑实体：发票批头，作为发票导入接口层分组标识； 接口导入时，一批接口数据生成多张应付发票 BO。

8. BO：预扣税 Withholding Tax

由应付发票 BO 衍生业务对象： 发票验证 / 付款时系统自动生成一张预扣税贷项发票（仍复用应付发票 BO 模型）； 预扣税相关金额、税率信息存放于发票分配 LE。

二、全局全景关系拓扑（文字 ER 图，可直接写入设计文档）

第一层：主数据 BO 之间【关联】

供应商BO └─【聚合】供应商地点LE ↓【关联】 应付发票BO

第二层：应付发票 BO 内部【组合链】

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

第三层：付款容器 BO + 付款 BO

付款批BO【聚合容器】 └─【聚合】多个付款BO 付款BO └─【组合】付款头LE 1→N 发票付款核销LE ↓【关联桥接】 付款计划LE（归属应付发票BO）

完整业务流转链路（BO 与 LE 协同工作流程）

1. 创建应付发票 BO → 持久化：发票头 LE、发票行 LE、发票分配 LE
2. 运行发票验证 APPRV 程序 → 自动生成【付款计划 LE】
3. 创建付款批 BO，系统读取所有满足条件的【付款计划 LE】
4. 生成付款 BO，同时创建【发票付款核销 LE】建立付款与负债关联
5. 创建会计程序读取【发票分配 LE、付款 LE】推送 SLA 产生会计事件

核心本质：业务对象之间不直接建立关系，依靠底层逻辑实体充当桥梁。

三、开发 / 实施高频易错关系辨析

辨析 1：付款计划 LE 到底属于谁？

❌误区：付款计划属于付款 BO ✅正确：付款计划是应付发票 BO 内部组合实体

• 由发票验证产生，代表负债；
• 付款程序仅仅读取付款计划，付款本身不产生负债； 负债归属发票，付款只是清偿动作。

辨析 2：AP_INVOICE_PAYMENTS_ALL（发票付款核销 LE）归属

归属【付款 BO】的组合子实体； 它是两大顶级 BO（应付发票 ↔ 付款）唯一的桥接逻辑实体，实现多对多核销： 一张付款可以核销多张发票；一张发票可以多次部分付款。

辨析 3：发票行 vs 发票分配行两层组合意义

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

• 发票行 LE：商务维度（商品、数量、行税费）
• 发票分配 LE：财务维度（科目、成本中心、资产、项目 CCID） 业务明细与会计分摊解耦；一条发票行可以分摊至多个科目。

辨析 4：组合 VS 聚合实操判定标准

1. 组合：删除父 BO，子实体级联删除 例：删除发票，发票分配、付款计划一并删除
2. 聚合：删除容器，成员实体保留 例：删除付款批，付款记录完全保留

辨析 5：为什么 EBS 没有 Fusion 那种 BO 服务层？

Fusion：BO 是服务层一等公民，VO 隔离物理表； EBS 模型： 业务对象 = 业务概念； 逻辑实体 = 数据模型层，紧贴数据库； 程序 API 最终操作逻辑实体对应的表，没有中间 VO 隔离层。

四、总结：BO 与 LE 关系的四大设计思想（Oracle AP 建模核心）

1. 单据模型复用标准发票、贷项、预付、费用报销全部复用「应付发票 BO」，依靠类型区分，共享同一套 LE 组合结构，降低模型复杂度。
2. 负债与支付分离设计负债载体：应付发票 BO（付款计划 LE 承载待付余额） 清偿载体：付款 BO（核销 LE 记录结清轨迹） 天然支持部分支付、多发票合并支付。
3. 分层解耦商务明细（发票行 LE）与财务分摊（发票分配 LE）分离，业务变更不强制改动会计层。
4. 容器聚合模式付款批作为聚合容器，适配传统企业批量付款作业场景，是 EBS 面向资金业务的标志性设计。