Oracle EBS R12 AP業(yè)務(wù)對象 (BO) 與邏輯實體 (LE)【聚合關(guān)系】深度解析前置概念界定UML 標準 EBS 落地口徑區(qū)分組合 / 聚合 / 關(guān)聯(lián)1. 聚合關(guān)系 Aggregation共享聚合弱包含語義整體包含部分但部分具備獨立生命周期整體和部分可獨立創(chuàng)建、獨立存在刪除整體不會級聯(lián)刪除組成部分。通俗區(qū)分?組合Composition強所有權(quán)零件不能脫離主體刪主體→級聯(lián)刪除零件發(fā)票頭→發(fā)票分配、付款→核銷記錄?聚合Aggregation容器與成員容器只是臨時分組、歸類載體成員是獨立完整業(yè)務(wù)對象脫離容器依然有效刪除容器成員保留。?關(guān)聯(lián)Association平等引用兩個獨立 BO 互相引用不存在 “容器包含”供應(yīng)商 ? 應(yīng)付發(fā)票核心判定三條標準全部滿足才是 AP 中的聚合關(guān)系存在一個容器業(yè)務(wù)對象 BO邏輯上收納一批成員成員本身是完整業(yè)務(wù)對象自帶一套獨立組合邏輯實體刪除容器成員數(shù)據(jù)不被級聯(lián)刪除成員可以脫離容器獨立操作也可以加入其他容器。2. 重要前提EBS AP 中聚合發(fā)生在【BO ? BO】層面 組合發(fā)生在【BO ? 下屬 LE】層面 不要混淆層級組合整體 BO → 內(nèi)部從屬邏輯實體 LE聚合容器 BO → 多個獨立成員 BO一、AP 模塊內(nèi)典型聚合關(guān)系全景梳理聚合 1付款批 Payment Batch【容器 BO】 聚合 多個 付款 Payment【成員 BO】這是 EBS AP最典型、最重要的聚合關(guān)系也是和 Oracle Fusion AP 最大的差異點Fusion 徹底取消付款批容器。結(jié)構(gòu)表達付款批 BO容器 └──【聚合】多個 付款 BO成員容器邏輯實體付款批頭 LEAP_PAYMENT_BATCHES_ALL成員付款 BO付款 BO 自身擁有完整組合結(jié)構(gòu) 付款頭 LE 發(fā)票付款核銷 LE聚合關(guān)系核心特征逐條驗證判定標準成員具備獨立生命周期付款本身是完整業(yè)務(wù)對象可以獨立創(chuàng)建、獨立確認、獨立取消不依賴付款批存在。刪除容器成員保留取消 / 刪除付款批底層AP_CHECKS_ALL付款記錄、核銷記錄不會被級聯(lián)清除。成員可跨容器遷移一筆付款可以被撤銷選取未來新一輪付款作業(yè)可以重新選取同一條付款計劃生成新付款歸入新付款批。業(yè)務(wù)語義付款批只是 “批量作業(yè)臨時分組容器”用途統(tǒng)一篩選待支付負債、統(tǒng)一打印、統(tǒng)一導(dǎo)出銀行付款文件、批量會計處理 不擁有底層資金負債數(shù)據(jù)僅做任務(wù)分組。業(yè)務(wù)場景舉例新建付款批 A → 選取發(fā)票生成 10 筆付款 后續(xù)刪除付款批 A 10 筆付款依舊完整存在可以新建付款批 B 再次處理若尚未確認付款。關(guān)鍵誤區(qū)提醒? 錯誤認知付款批和付款是組合關(guān)系 ? 糾正如果是組合刪付款批會連帶刪除付款實際系統(tǒng)無此級聯(lián)因此只能是聚合。聚合 2發(fā)票批 Invoice Batch【容器 BO】聚合 多張應(yīng)付發(fā)票 Invoice【成員 BO】結(jié)構(gòu)表達發(fā)票批 BO導(dǎo)入容器 └──【聚合】多張 應(yīng)付發(fā)票 BO成員容器邏輯實體發(fā)票批頭 LE存儲批名稱、導(dǎo)入時間、來源標識成員應(yīng)付發(fā)票 BO自帶發(fā)票頭、發(fā)票行、分配、付款計劃等整套組合 LE聚合特征發(fā)票批主要用于批量導(dǎo)入發(fā)票接口導(dǎo)入、快速錄入批次發(fā)票導(dǎo)入成功持久化后發(fā)票和發(fā)票批僅保留邏輯關(guān)聯(lián)刪除發(fā)票批不會刪除已經(jīng)生成的正式應(yīng)付發(fā)票發(fā)票一旦創(chuàng)建完成可獨立修改、驗證、付款完全脫離發(fā)票批管控。邊界發(fā)票批僅作為導(dǎo)入階段管控容器日常業(yè)務(wù)很少使用聚合屬性和付款批一致但使用頻次遠低于付款批。聚合 3應(yīng)付發(fā)票 BO類型 預(yù)付款 Prepayment聚合 預(yù)付款擴展 LEAP_PREPAYMENTS_ALL這是「BO 聚合邏輯實體」的特殊場景區(qū)別于 BO 聚合 BO區(qū)分為什么是聚合、不是組合組合要求刪除父 BO子實體必須級聯(lián)刪除。 業(yè)務(wù)規(guī)則 預(yù)付款發(fā)票一旦發(fā)生預(yù)付款應(yīng)用沖抵標準發(fā)票產(chǎn)生AP_PREPAY_HISTORY_ALL歷史記錄系統(tǒng)禁止級聯(lián)刪除 AP_PREPAYMENTS_ALL需要保留預(yù)付核銷軌跡用于審計。 因此 預(yù)付款擴展實體只是附加屬性載體不屬于強綁定的組合部件屬于聚合關(guān)系。結(jié)構(gòu)示意應(yīng)付發(fā)票BO預(yù)付子類 ├─【組合】發(fā)票頭、發(fā)票行、分配、付款計劃基礎(chǔ)骨架 └─【聚合】預(yù)付款擴展 LE AP_PREPAYMENTS_ALL附加屬性補充AP_PREPAY_HISTORY_ALL預(yù)付款歷史不屬于聚合屬于跨 BO 關(guān)聯(lián)橋接實體連接預(yù)付發(fā)票與被沖抵標準發(fā)票。二、聚合關(guān)系 VS 組合關(guān)系 對照匯總AP 落地實例關(guān)系類型層級典型案例核心行為特征組合 CompositionBO → 內(nèi)部從屬 LE應(yīng)付發(fā)票 BO → 發(fā)票分配 LE付款 BO → 發(fā)票付款核銷 LE刪除父 BO子實體級聯(lián)刪除子實體不能脫離父存在聚合 Aggregation容器 BO → 成員 BOBO → 附加 LE付款批 BO 聚合 付款 BO發(fā)票批 BO 聚合 應(yīng)付發(fā)票 BO預(yù)付發(fā)票 BO 聚合預(yù)付款擴展 LE刪除容器成員保留成員可獨立生命周期關(guān)聯(lián) AssociationBO ? BO平等主體供應(yīng)商 BO ? 應(yīng)付發(fā)票 BO預(yù)付發(fā)票 BO ? 標準發(fā)票 BO無容器概念雙向外鍵引用彼此獨立高頻踩坑澄清坑 1把 “付款批→付款” 當成組合根源直覺“付款批里面包含付款” 數(shù)據(jù)層面校驗在 EBS 測試刪除付款批AP_CHECKS_ALL記錄完好無級聯(lián)刪除證明是聚合?？?2混淆 “預(yù)付款擴展實體” 歸屬預(yù)付款發(fā)票基礎(chǔ)骨架發(fā)票頭、行、分配屬于組合 AP_PREPAYMENTS_ALL 屬于附加屬性聚合不要全部歸為組合?？?3認為聚合只存在于 BO 與 BO 之間EBS AP 存在特例BO 也可以聚合一個邏輯實體附加擴展屬性實體前提是不滿足級聯(lián)刪除的組合條件。三、聚合關(guān)系在系統(tǒng)設(shè)計、開發(fā)實施上帶來的影響1. 數(shù)據(jù)模型層面聚合容器實體只保存關(guān)聯(lián)外鍵不擁有業(yè)務(wù)核心數(shù)據(jù) 核心業(yè)務(wù)數(shù)據(jù)全部存儲在成員 BO 對應(yīng)的一套邏輯實體中。例付款批表只存批次信息金額、供應(yīng)商、核銷明細全部在 AP_CHECKS、AP_INVOICE_PAYMENTS。2. API 操作約束刪除付款批 API僅清除批次關(guān)聯(lián)標識不會刪除付款單據(jù)取消付款操作操作對象是【付款 BO】和歸屬哪個付款批無關(guān) 體現(xiàn)成員 BO 擁有獨立完整操作接口。3. 業(yè)務(wù)流程設(shè)計啟示付款批只是操作層面的工具不能作為資金管控的核心依據(jù) 資金審計、付款軌跡溯源必須以【付款 Payment BO】作為核心對象不能依賴付款批。4. 遷移 / 數(shù)據(jù)清理注意事項清理歷史數(shù)據(jù)時 不能直接刪除付款批期待連帶清理付款 必須先單獨清理付款、核銷記錄再清理付款批容器。四、結(jié)構(gòu)化匯總清單可直接粘貼進 ERP 設(shè)計文檔EBS AP 全部聚合關(guān)系清單付款批 BO 聚合 付款 BO最重要業(yè)務(wù)聚合容器 LEAP_PAYMENT_BATCHES_ALL成員付款 BO內(nèi)部組合AP_CHECKS_ALL AP_INVOICE_PAYMENTS_ALL發(fā)票批 BO 聚合 應(yīng)付發(fā)票 BO導(dǎo)入批量管控聚合容器 LE發(fā)票批頭成員應(yīng)付發(fā)票 BO 全套組合實體預(yù)付款類型應(yīng)付發(fā)票 BO 聚合 預(yù)付款擴展 LE主體應(yīng)付發(fā)票基礎(chǔ)組合結(jié)構(gòu)聚合附加 LEAP_PREPAYMENTS_ALL