Oracle EBS R12 AP业务对象 (BO) ↔ 逻辑实体 (LE) 完整关系详解重要前置概念界定EBS 特有语境请勿直接套用 Fusion BO 模型业务对象 Business ObjectBO面向业务流程、用户界面、业务生命周期的业务概念模型对应操作员看到的单据 / 档案 BO 本身没有数据库表由一个或多个逻辑实体通过【组合 / 聚合 / 关联】组装而成。逻辑实体 Logical EntityLEETRM/Oracle ERD 数据模型中的数据单元具备唯一主键、业务约束、外键关系 R12 AP 典型特征绝大多数逻辑实体一对一映射一张XXX_ALL物理表是系统底层数据载体。三种核心关联语义遵循 Oracle ETRM 建模规范组合 Composition强包含子逻辑实体生命周期依附父 BO父 BO 删除子实体级联删除不能独立存在。示例应付发票 BO「包含」发票头、发票分配行。聚合 Aggregation弱包含容器 BO 仅仅是逻辑分组内部成员实体拥有独立生命周期删除容器成员实体保留。示例付款批 BO 聚合多条付款 BO。关联 Association平等引用两个独立 BO 互相引用彼此生命周期互不绑定依靠外键建立联系。示例供应商 BO ↔ 应付发票 BO。层级传导链路业务对象BO →[组合/聚合]→ 逻辑实体LE → 物理表XXX_ALL一、逐个核心业务对象拆解BO 内部 LE 构成 实体间关系1. BO应付发票 Invoice核心 BO关系类型组合关系强包含 所有子逻辑实体脱离发票头则无独立业务意义组成逻辑实体清单逻辑实体 LE关系角色说明发票头 Invoice Header根主实体BO 的根所有子实体外键指向 INVOICE_ID发票行 Invoice Line组合子实体承载商务明细、物料、行级税务信息R12 EBTax 强制分层发票分配 Invoice Distribution组合子实体会计分摊层CCID 科目存放地SLA 分录数据源付款计划 Payment Schedule组合子实体发票验证后自动生成付款选取唯一数据源发票暂挂 Invoice Hold可选组合子实体匹配异常 / 人工冻结控制存在暂挂则无法支付BO 内部 LE 之间拓扑关系1 发票头 → 一对多 → 发票行 1 发票行 → 一对多 → 发票分配一行可分摊多个科目 1 发票头 → 一对多 → 付款计划支持分期支付 1 发票头 → 一对多 → 发票暂挂特殊子类预付款发票Invoice_TypePREPAYMENT在基础组合之上聚合扩展逻辑实体预付款扩展属性 PrepaymentAP_PREPAYMENTS_ALL 新增跨单据关联逻辑实体预付款历史 Prepayment HistoryAP_PREPAY_HISTORY_ALL作用记录预付款发票 ↔ 标准发票之间的核销关系属于跨 BO 关联桥梁关键结论预付款不是独立 BO是应付发票 BO 的类型化子类。2. BO付款 PaymentCheck关系类型组合关系组成逻辑实体清单逻辑实体 LE角色付款头 Payment/Check根主实体AP_CHECKS_ALL发票付款核销 Invoice Payment组合子实体AP_INVOICE_PAYMENTS_ALL内部拓扑1 付款头 → 一对多 → 发票付款核销 ✅发票付款核销是关键桥接实体外键同时关联CHECK_ID(付款) PAYMENT_SCHEDULE_ID(发票付款计划)实现【付款 BO】与【应付发票 BO】两大顶层业务对象之间的关联。3. BO付款批 Payment BatchEBS 独有容器 BO关系类型聚合关系弱包含组成逻辑实体付款批头 Payment BatchAP_PAYMENT_BATCHES_ALL 聚合多个【付款 BO】聚合特征重点区分付款批只是批量作业临时容器删除付款批付款逻辑实体不会被级联删除一张付款可以脱离原付款批再次被选入新付款批付款拥有独立生命周期不依附付款批。对比组合关系会级联删除聚合不会。4. BO供应商 Supplier主数据 BO关系类型聚合关系组成逻辑实体供应商头 SupplierAP_SUPPLIERS供应商地点 Supplier SiteAP_SUPPLIER_SITES_ALL拓扑1 供应商头 → 一对多 → 供应商地点 业务强规则应付发票必须绑定供应商地点不能直接绑定供应商头因此【供应商地点 LE】成为「供应商 BO」关联「应付发票 BO」的桥梁。5. BO预付款应用 Prepayment Application不属于单据 BO是跨 BO 业务动作对象不拥有专属根实体依靠两个逻辑实体承载预付款历史 Prepayment History关联预付发票 标准发票标准发票新增反向发票分配行抵减负债链路预付款发票 BO ←【预付款历史 LE】→ 标准应付发票 BO6. BO发票暂挂 Invoice Hold两种定位作为【应付发票 BO】内部可选组合子实体独立管控视角下可作为查询业务对象 底层唯一载体发票暂挂 LEAP_HOLDS_ALL7. 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 协同工作流程创建应付发票 BO → 持久化发票头 LE、发票行 LE、发票分配 LE运行发票验证 APPRV 程序 → 自动生成【付款计划 LE】创建付款批 BO系统读取所有满足条件的【付款计划 LE】生成付款 BO同时创建【发票付款核销 LE】建立付款与负债关联创建会计程序读取【发票分配 LE、付款 LE】推送 SLA 产生会计事件核心本质业务对象之间不直接建立关系依靠底层逻辑实体充当桥梁。三、开发 / 实施高频易错关系辨析辨析 1付款计划 LE 到底属于谁❌误区付款计划属于付款 BO ✅正确付款计划是应付发票 BO 内部组合实体由发票验证产生代表负债付款程序仅仅读取付款计划付款本身不产生负债 负债归属发票付款只是清偿动作。辨析 2AP_INVOICE_PAYMENTS_ALL发票付款核销 LE归属归属【付款 BO】的组合子实体 它是两大顶级 BO应付发票 ↔ 付款唯一的桥接逻辑实体实现多对多核销 一张付款可以核销多张发票一张发票可以多次部分付款。辨析 3发票行 vs 发票分配行两层组合意义R12 引入 E-Business Tax 后强制分层发票行 LE商务维度商品、数量、行税费发票分配 LE财务维度科目、成本中心、资产、项目 CCID 业务明细与会计分摊解耦一条发票行可以分摊至多个科目。辨析 4组合 VS 聚合实操判定标准组合删除父 BO子实体级联删除 例删除发票发票分配、付款计划一并删除聚合删除容器成员实体保留 例删除付款批付款记录完全保留辨析 5为什么 EBS 没有 Fusion 那种 BO 服务层FusionBO 是服务层一等公民VO 隔离物理表 EBS 模型 业务对象 业务概念 逻辑实体 数据模型层紧贴数据库 程序 API 最终操作逻辑实体对应的表没有中间 VO 隔离层。四、总结BO 与 LE 关系的四大设计思想Oracle AP 建模核心单据模型复用标准发票、贷项、预付、费用报销全部复用「应付发票 BO」依靠类型区分共享同一套 LE 组合结构降低模型复杂度。负债与支付分离设计负债载体应付发票 BO付款计划 LE 承载待付余额 清偿载体付款 BO核销 LE 记录结清轨迹 天然支持部分支付、多发票合并支付。分层解耦商务明细发票行 LE与财务分摊发票分配 LE分离业务变更不强制改动会计层。容器聚合模式付款批作为聚合容器适配传统企业批量付款作业场景是 EBS 面向资金业务的标志性设计。