 与逻辑实体 (LE)【组合关系】深度详解## 前置基础定义（严格区分术语，限定 EBS 语境）＞ ＞ 1. *)
Oracle EBS R12 AP：业务对象 (BO) 与逻辑实体 (LE)【组合关系】深度详解
前置基础定义（严格区分术语，限定 EBS 语境）
- 组合关系 CompositionUML 建模标准：整体拥有部分，部分不能脱离整体独立存在；整体生命周期决定部分生命周期；整体删除，部分级联删除。 区别于聚合（弱包含）：聚合只是分组容器，成员可独立存在；组合是强所有权绑定。
- EBS AP 边界约定
- 业务对象 BO：业务视角单据 / 档案（应付发票、付款等），面向流程与用户；
- 逻辑实体 LE：ETRM 数据模型单元，一一映射
XXX_ALL物理表； - 组合关系 = BO（整体） ←→ LE（组成部分，强归属）
重要区分： ✅组合：LE 是 BO 不可分割组成部分，离开 BO 无业务意义； ❌关联：两个独立 BO 之间互相引用（供应商 ↔ 发票），不属于组合； ❌聚合：付款批包含付款，属于聚合，不属于组合。
本文只聚焦【组合关系】，聚合、跨 BO 关联仅作对比排除。
一、核心判定规则（EBS AP 内部组合识别标准）
同时满足以下全部条件，才认定为组合关系：
- 逻辑实体存在指向业务对象根实体的外键；
- 不存在 “脱离父 BO 单独创建该 LE” 合法业务场景；
- 在标准功能删除父单据时，系统级联删除子 LE；
- 子 LE 的业务语义依附父单据存在。
二、逐个核心业务对象拆解内部组合结构
BO1：应付发票 Invoice（最核心 BO，大量组合关系）
整体：应付发票 BO（整体）所有下属 LE 均为【组合成员】 根逻辑实体：发票头 LE（AP_INVOICES_ALL），是整个 BO 的根节点。
组合成员清单 + 关系说明
- 发票行 LE AP_INVOICE_LINES_ALL
- 组合关系：1 发票头 → 一对多 → 发票行
- 业务语义：发票商务明细，商品、运费、行级税费；
- 组合依据：不能无发票头单独创建发票行；删除发票，发票行级联删除。
- 发票分配 LE AP_INVOICE_DISTRIBUTIONS_ALL
- 组合关系：1 发票行 → 一对多 → 发票分配
- 组合依据：分配行依附发票行 / 发票头；是会计维度载体；无发票则分配行无意义；删除发票级联清除分配行。
R12 分层设计：发票行（业务明细）与分配行（财务分摊）两级组合。
- 付款计划 LE AP_PAYMENT_SCHEDULES_ALL
- 组合关系：1 发票头 → 一对多 → 付款计划
- 关键认知：付款计划属于应付发票 BO 的组成部分，不属于付款 BO
- 组合依据：由发票验证程序基于发票信息自动生成；依附发票生命周期；发票取消 / 删除，付款计划同步清除；代表 “发票产生的负债分期计划”。
- 发票暂挂 LE AP_HOLDS_ALL
- 组合关系：1 发票头 → 一对多 → 发票暂挂
- 可选组合成员：一张发票可以没有暂挂，也可以多条暂挂；
- 组合依据：暂挂是针对这张发票的冻结控制，不能脱离发票独立存在；发票删除，暂挂记录一并删除。
应付发票 BO 内部完整组合链
应付发票BO【整体】 └──【组合】发票头LE（根） ├──【组合】发票行LE │ └──【组合】发票分配LE ├──【组合】付款计划LE └──【组合】发票暂挂LE（可选）特殊扩展：预付款发票（INVOICE_TYPE=PREPAYMENT）
预付款依然是应付发票 BO 的子类，不产生新 BO
AP_PREPAYMENTS_ALL（预付款扩展 LE）： ⚠️ 注意：该实体是聚合，不是组合理由：删除预付款发票时，受历史核销数据约束，系统不会直接级联删除预付款扩展记录，存在保留历史的业务规则，因此不属于严格组合。AP_PREPAY_HISTORY_ALL（预付款历史）属于跨 BO 关联桥接实体，不属于组合。
小结：预付款只是在标准发票组合结构之上附加扩展实体，基础组合链不变。
会计衍生补充
AP_ACCOUNTING_EVENTS_ALL（AP 会计事件 LE） 属于应付发票 BO、付款 BO 共同衍生的组合子实体，交易发生后生成，依附原始单据。
BO2：付款 Payment（Check）
整体：付款 BO【整体】根逻辑实体：付款头 LE AP_CHECKS_ALL
组合成员：发票付款核销 LE AP_INVOICE_PAYMENTS_ALL
- 组合关系：1 付款头 → 一对多 → 发票付款核销
- 组合判定依据：
- 核销记录描述 “这笔付款清偿了多少负债”，不能脱离付款单独存在；
- 删除付款（取消付款），系统级联清除对应的核销记录；
- 核销记录主键依赖 CHECK_ID。
重要边界： 核销 LE 外键同时指向【付款计划 LE（归属应付发票 BO）】 👉 这是两个 BO 之间的关联桥梁，并不改变：核销 LE 是付款 BO 内部组合成员这一事实。
组合结构简图
付款BO【整体】 └──【组合】付款头LE（根） └──【组合】发票付款核销LEBO3：供应商 Supplier（主数据 BO）
整体：供应商 BO【整体】根逻辑实体：供应商头 LE AP_SUPPLIERS 组合成员：供应商地点 LE AP_SUPPLIER_SITES_ALL
- 组合关系：1 供应商头 → 一对多 → 供应商地点
- 判定依据：供应商地点是供应商不可分割组成档案；业务上不存在无供应商头的地点；删除供应商（清理主数据）会级联处理地点。
供应商BO【整体】 └──【组合】供应商头LE（根） └──【组合】供应商地点LE业务强规则：发票绑定【供应商地点 LE】，而非供应商头；供应商地点作为「供应商 BO ↔ 应付发票 BO」的关联桥梁。
BO4：发票批 Invoice Batch（导入管控 BO）
根逻辑实体：发票批头 LE 组合成员：一批接口生成的多张应付发票 BO
注意：发票批与发票之间属于聚合，不是组合。 删除发票批不会删除发票，因此不属于组合关系。
BO5：付款批 Payment Batch（容器 BO）
付款批头 LE 和 付款 BO 之间：聚合关系❌ 不属于组合！ 核心区分点：删除付款批，付款单据完整保留；付款拥有独立生命周期，可以加入其他付款批。
三、关键对比：组合 VS 聚合 VS 跨 BO 关联（避坑清单）
表格
| 关系类型 | 归属场景 | 典型例子 | 核心特征 |
|---|---|---|---|
| 组合 Composition | BO 内部构成 | 发票头→发票行；付款→发票付款核销 | 删除父 BO，子 LE 级联删除；子不能独立存在 |
| 聚合 Aggregation | 容器 - 成员 | 付款批→付款；发票批→发票 | 删除容器，成员保留 |
| 关联 Association | 两个独立 BO 之间 | 供应商 BO ↔ 应付发票 BO；预付发票 ↔ 标准发票 | 双方互相独立，依靠外键引用 |
高频误区澄清
误区 1：付款计划属于付款 BO
❌错误。付款计划是应付发票 BO 内部组合 LE，代表负债；付款只是使用负债进行清偿。
误区 2：AP_INVOICE_PAYMENTS_ALL 属于应付发票 BO
❌错误。核销记录描述 “本次付款的分摊明细”，所有权归属付款 BO，是付款的组合子实体；只是通过外键关联发票的付款计划。
误区 3：预付款历史属于应付发票内部组合
❌错误。预付款历史是两张独立发票 BO 之间的桥接实体，属于跨 BO 关联，不属于任何一方的组合成员。
误区 4：发票暂挂可以独立存在
❌错误。发票暂挂 LE 必须依附某一张发票头，属于应付发票可选组合组件。
四、组合关系带来的系统行为（开发 / 实施价值）
- 级联删除机制根源正是因为定义了组合关系，EBS 标准 API 删除发票时自动删除：发票行、分配行、付款计划、暂挂； 如果绕过 API 直接删发票头，会产生大量孤立子实体，引发数据完整性错误。
- API 设计思想EBS 标准 API 按照 “BO 整体” 设计：创建发票 API 自动创建全套组合 LE，不允许单独插入发票行、分配行。
- SLA 会计溯源逻辑会计分录源头来自应付发票 BO 内部的【发票分配 LE】，分配行作为 BO 固有组成部分，保证每一笔负债都有会计维度。
- 状态联动逻辑发票验证（APPRV）本质是修改发票头 LE 状态，并自动生成组合成员【付款计划 LE】； 体现：整体状态变更驱动内部组成实体生成。
五、完整汇总表（可直接放进设计文档）
| 顶层业务对象 BO | 根逻辑实体 LE | 内部组合逻辑实体 LE |
|---|---|---|
| 应付发票 Invoice | 发票头 AP_INVOICES_ALL | 发票行、发票分配、付款计划、发票暂挂 |
| 付款 Payment | 付款头 AP_CHECKS_ALL | 发票付款核销 AP_INVOICE_PAYMENTS_ALL |
| 供应商 Supplier | 供应商头 AP_SUPPLIERS | 供应商地点 AP_SUPPLIER_SITES_ALL |
