Oracle EBS R12 AP业务对象与逻辑实体完整关系解析前置核心定义区分两层概念避免和 Fusion BO 混淆业务对象 Business Object业务层视角面向用户业务流程、UI 单据、业务生命周期是业务人员认知的 “单据 / 档案”一个业务对象由多个逻辑实体「组合 / 聚合」构成业务对象本身不直接映射数据库表。 关系类型遵循 UML组合Composition、聚合Aggregation、关联Association组合子实体不能脱离父业务对象独立存在父销毁子随之失效发票头→发票行聚合子实体可以独立存在仅临时归属付款批包含多张付款关联双向松散引用供应商 ↔ 发票逻辑实体 Logical Entity数据模型 ETRM/ERD 视角独立具备唯一主键、业务语义的数据单元R12 EBS AP 特征绝大多数逻辑实体一对一映射一张XXX_ALL物理表承载数据存储、业务约束、外键关联。层级链路业务对象单据 → [组合 / 聚合] → 多个逻辑实体 → 物理表All 表⚠️关键区别 FusionBO 是一等公民服务层BO 内部封装 VO 逻辑视图 EBS没有服务层 BO业务对象 业务单据概念逻辑实体 ER 实体紧贴数据库。一、三大关系类型在 AP 中的落地释义组合关系强包含生命周期绑定例应付发票【业务对象】组合包含发票头逻辑实体、发票行逻辑实体、发票分配逻辑实体 没有发票头发票行、分配行没有业务意义。聚合关系弱包含容器与成员例付款批【业务对象】聚合多张付款逻辑实体 删除付款批付款单据本身仍然保留可被其他付款批重新选取。关联关系双向引用平等主体例供应商【业务对象】 ↔ 应付发票【业务对象】 双方可独立创建、独立存在依靠外键建立关联。二、核心业务对象 → 构成逻辑实体映射 关系说明1业务对象应付发票 InvoiceAP 最核心关系类型组合关系业务对象由以下逻辑实体强组合而成缺一不可发票头Invoice Header【主逻辑实体根】发票行Invoice Line发票会计分配Invoice Distribution付款计划Payment Schedule发票暂挂Invoice Hold【可选组合】内部实体间关系1 发票头一对多发票行组合1 发票行一对多发票分配组合1 发票头一对多付款计划组合验证后系统自动生成1 发票头一对多发票暂挂组合可选业务规则体现发票保存先创建发票头→发票行→分配行 运行【发票验证 APPRV】自动生成付款计划 匹配异常自动新增暂挂逻辑实体。特殊子类预付款发票Prepayment 依然属于【应付发票业务对象】在原有组合基础上聚合扩展逻辑实体预付款扩展属性AP_PREPAYMENTS_ALL新增关联逻辑实体预付款应用历史Prepayment History用于记录预付款冲抵标准发票。2业务对象付款 PaymentCheck关系类型组合关系构成逻辑实体付款头Payment / Check【主实体】发票付款核销Invoice Payment【组合子实体】内部关系 1 付款一对多发票付款核销记录 一条付款可以同时核销多张发票核销记录不能脱离付款、发票单独存在。3业务对象付款批 Payment BatchEBS 独有容器对象关系类型聚合关系构成逻辑实体付款批头Payment Batch【容器实体】多条付款 Payment 逻辑实体聚合特征 付款批只是 “临时选取容器”付款本身是独立业务对象。 删除付款批付款单据依然保留付款可以脱离付款批独立存在。4业务对象供应商 Supplier主数据业务对象关系类型聚合 关联构成逻辑实体供应商头 Supplier供应商地点 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 引入强制分层发票行Invoice Line承载商务明细、商品、税费信息业务明细层发票分配Distribution承载会计科目、CCID、成本分摊财务核算层 一条发票行可以分摊到多个科目因此1 行 → N 分配 二者都属于发票业务对象内部组合实体。11i 遗留习惯很多实施跳过发票行直接录入分配行R12 税务场景必须启用两层结构。辨析 4组合 vs 聚合实务区分✅组合发票头→发票行删除发票头系统级联删除行、分配、付款计划、暂挂子实体没有独立生命周期。✅聚合付款批→付款删除付款批付款记录保留付款可以被重新挑选进入新付款批。五、业务对象跨对象交互关系端到端 P2P 流程视角创建【应付发票 BO】→生成内部全套逻辑实体验证发票 → 自动生成付款计划 LE创建【付款批 BO】选取满足条件的付款计划生成【付款 BO】自动创建【发票付款核销 LE】建立负债结清关系运行创建会计程序读取发票分配 LE、付款 LE推送 SLA 生成分录数据流本质业务对象之间不直接关联依靠底层逻辑实体作为桥梁业务对象只是面向使用者的概念系统底层数据联动全部依靠逻辑实体之间的外键约束。六、对比 Fusion 关键差异方便你前后知识串联EBS 业务对象 ←【组合 / 聚合】→ 逻辑实体 ≈ 物理表逻辑实体是数据交互核心没有独立服务层程序直接操作逻辑实体对应的表。Fusion BO顶层服务对象 ← VO 逻辑视图 ← 物理表 不存在 “业务对象组合多个逻辑实体” 这种 EBS 经典分层 核销统一封装为 Settlement BO不再拆分分散的核销实体。