Oracle EBS R12 AP業務對象 (BO) 與邏輯實體 (LE)【組合關系】深度詳解前置基礎定義嚴格區分術語限定 EBS 語境組合關系 CompositionUML 建模標準整體擁有部分部分不能脫離整體獨立存在整體生命周期決定部分生命周期整體刪除部分級聯刪除。 區別于聚合弱包含聚合只是分組容器成員可獨立存在組合是強所有權綁定。EBS AP 邊界約定業務對象 BO業務視角單據 / 檔案應付發票、付款等面向流程與用戶邏輯實體 LEETRM 數據模型單元一一映射XXX_ALL物理表組合關系 BO整體 ←→ LE組成部分強歸屬重要區分 ?組合LE 是 BO 不可分割組成部分離開 BO 無業務意義 ?關聯兩個獨立 BO 之間互相引用供應商 ? 發票不屬于組合 ?聚合付款批包含付款屬于聚合不屬于組合。本文只聚焦【組合關系】聚合、跨 BO 關聯僅作對比排除。一、核心判定規則EBS AP 內部組合識別標準同時滿足以下全部條件才認定為組合關系邏輯實體存在指向業務對象根實體的外鍵不存在 “脫離父 BO 單獨創建該 LE” 合法業務場景在標準功能刪除父單據時系統級聯刪除子 LE子 LE 的業務語義依附父單據存在。二、逐個核心業務對象拆解內部組合結構BO1應付發票 Invoice最核心 BO大量組合關系整體應付發票 BO整體所有下屬 LE 均為【組合成員】 根邏輯實體發票頭 LEAP_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_TYPEPREPAYMENT預付款依然是應付發票 BO 的子類不產生新 BOAP_PREPAYMENTS_ALL預付款擴展 LE ?? 注意該實體是聚合不是組合理由刪除預付款發票時受歷史核銷數據約束系統不會直接級聯刪除預付款擴展記錄存在保留歷史的業務規則因此不屬于嚴格組合。AP_PREPAY_HISTORY_ALL預付款歷史屬于跨 BO 關聯橋接實體不屬于組合。小結預付款只是在標準發票組合結構之上附加擴展實體基礎組合鏈不變。會計衍生補充AP_ACCOUNTING_EVENTS_ALLAP 會計事件 LE 屬于應付發票 BO、付款 BO 共同衍生的組合子實體交易發生后生成依附原始單據。BO2付款 PaymentCheck整體付款 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 關聯避坑清單表格關系類型歸屬場景典型例子核心特征組合 CompositionBO 內部構成發票頭→發票行付款→發票付款核銷刪除父 BO子 LE 級聯刪除子不能獨立存在聚合 Aggregation容器 - 成員付款批→付款發票批→發票刪除容器成員保留關聯 Association兩個獨立 BO 之間供應商 BO ? 應付發票 BO預付發票 ? 標準發票雙方互相獨立依靠外鍵引用高頻誤區澄清誤區 1付款計劃屬于付款 BO?錯誤。付款計劃是應付發票 BO 內部組合 LE代表負債付款只是使用負債進行清償。誤區 2AP_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