Oracle EBSR12​ 和Oracle Fusion CloudERP Budgetary Control EPM Planning PPM​ 的预算体系按「设计哲学 → 实现逻辑 → 核心差异 → 具体示例」系统讲清楚。重点不是菜单路径而是为什么这么设计、钱是怎么被“锁住/释放/超支”的。一、共同的设计哲学预算不是报表而是交易闸门无论是 EBS 还是 FusionOracle 的预算哲学都可以概括成一句话预算控制 在交易发生前/中用“可用资金”做资金检查Funds Check而不是事后做差异分析。核心公式始终存在Available Funds可用预算 Budget批准预算 调整 - Encumbrance / Commitment / Obligation已承诺但未实际支付 - Actual已入账/已形成债务设计上有 4 个底层假设承诺前置PR/PO 不是“未来可能花钱”而是“现在就占用钱”。会计与管控分离但贯通预算维度 ≠ 会计科目维度但最终都要落到 COAChart of Accounts。控制级别可配置None / Track / Advisory / Absolute。预算是治理对象预算可以编制、审批、基线化、修订、结转、审计。EBS 和 Fusion 的区别不在哲学而在“承诺如何分层、引擎在哪里、控制有多细”。二、Oracle EBSGL 内嵌式预算控制Budgetary Control Encumbrance1. 设计哲学EBS 的时代背景是总账是系统中枢子模块PO / AP / HR / Projects都把“钱”最终送回 GL预算控制是GL 的一项能力不是独立产品所以 EBS 的哲学是预算余额存在于 GL交易经过 GL 的 Funds CheckEncumbrance 是唯一的“未实现支出”载体。2. 核心对象对象含义BudgetGL Budget Journal 载入的年度/期间预算EncumbrancePR / PO / AP Invoice 产生的预留款ActualGL 已过账实际数Funds Check交易保存/审批时检查可用资金Budgetary Control Group决定哪些 Journal Source/Category 受控Budget Organization预算组织/汇总结构3. 占用模型单池 EncumbranceEBS 只有一层Budget - EncumbrancePR PO Invoice 预留混在一起 - Actual Funds AvailablePR 审批 → 占 EncumbrancePO 审批 → 冲 PR Encumbrance占 PO EncumbranceAP Invoice 校验 → 冲 PO Encumbrance占 Invoice EncumbrancePayment → 不影响预算占用因为债务已成立GL 过账 → Encumbrance 减少Actual 增加⚠️ EBS 不天然区分“我想买”Commitment“我已经下订单”Obligation“已经收货/发票”Expenditure它们都是 Encumbrance只是类型不同。4. 控制流程P2P 场景Dept Budget 1,000,000 1) PR 200,000 审批 Encumbrance 200,000 Available 800,000 2) PO 200,000 审批 PR Encumbrance 200,000 释放 PO Encumbrance 200,000 占用 Available 800,000 3) 收货 发票 180,000 PO Encumbrance 降到 180,000 Actual 180,000 Available 820,000 4) 发票最终 200,000 完结 Encumbrance 0 Actual 200,000 Available 800,0005. EBS 的典型问题PR/PO 占用混在一起管理层看不出“软需求”和“硬合同”草稿/未审批不占预算 → 批量审批时集体超预算部分收货/部分开票时预算释放不灵活预算余额常需跑Maintain Budgetary Control Balances项目预算和企业预算“双控”要靠 GL Oracle Projects 两套机制拼6. EBS 项目预算怎么控Oracle Projects 里项目预算 baseline项目成本按 Project / Task / Resource 检查同时如果集成 GL还会生成 GL 预算/Encumbrance所以 EBS 的“项目部门双控”本质是PO / AP 交易 ├─ GL Funds Check → 成本中心/科目维度 └─ PA Funds Check → 项目/任务维度但 PA 和 GL 是两个控制域不是同一个引擎。三、Oracle Fusion独立预算引擎XCC EPM PPM1. 设计哲学Fusion 的哲学是预算编制Planning和预算执行控制Budgetary Control是不同层控制引擎应独立于 GL支持多层承诺、按业务对象精细化管控。架构变成三层EPM Planning / Spreadsheet / FBDI │ 编制、滚动预测、版本、情景 ▼ ERP Budgetary ControlXCC │ 控制预算、资金检查、预留余额 ▼ GL / Subledger / Projects / Expenses / Procurement │ 实际业务 ▼ Reporting BI关键词XCC eXtensible Controls / Budgetary Control 引擎社区里常叫 XCC。2. 三层占用模型核心进步Fusion 把“承诺”拆开Budget - Commitment : PR / 差旅申请 / 软需求 - Obligation : PO / 已批报销 / 合同义务 - Expenditure : 发票/日记账/实际成本 Funds Available公式Available Budget - Commitment - Obligation - Expenditure这带来三个好处能看到“还没下单但想买多少”能看到“已下单但没发票多少”能按阶段设不同控制强度3. 控制对象更细Fusion 可按LedgerBusiness UnitProject / TaskDepartment / Cost CenterAccount / Natural AccountTransaction TypePR / PO / Invoice / Expense / JournalBudget Calendar不等于会计日历设置级别行为None不检查Track只记录不拦Advisory超支警告可继续Absolute硬拦截Tolerance %容差内允许超容差再拦4. 控制预算Control BudgetFusion 里不是“GL 里有一张预算日记账”就完事而是有显式的Control Budget 被预算引擎使用的可执行预算属性包括Ledger / CurrencyBudget CalendarControl Budget StructureCOA 段组合Control LevelToleranceSourceEPM Planning / FBDI / Manual系统通过Control Budget Filter​ 决定交易归哪个预算管Ledger onlyProject onlyLedger or Project例如一笔 POLedger Vision City Project Roadways如果 filter Ledger or Project先匹配项目控制预算再匹配总账控制预算两个都过才允许这就是 Fusion 原生的“双控”。5. P2P 全链路示例Fusion部门预算差旅 办公 200,000项目 Roadways / Task T1 100,000Step 1员工提交 PR 50,000Commitment 50,000 Obligation 0 Expenditure 0 Ledger Available 150,000 Project Available 50,000如果项目预算只剩 30,000 → 项目维度 Advisory/Absolute 触发。Step 2PR 转 PO 50,000 审批Commitment -50,000 Obligation 50,000总占用还是 50,000但性质变了从“需求”变成“采购义务”。Step 3部分收货 发票 30,000Fusion 可按比例释放Obligation 50,000 → 20,000 Expenditure 30,000EBS 很多时候要等完全匹配Fusion 支持按比例。Step 4发票完结 50,000Obligation 0 Expenditure 50,000四、EBS vs Fusion本质差异一张表维度EBS R12Fusion Cloud预算引擎GL 内嵌独立 Budgetary Control / XCC占用模型单池 EncumbranceCommitment / Obligation / Expenditure实时性常需维护 BC 余额近实时控制粒度全局/预算组织级BU / 项目 / 科目 / 单据类型 / 场景级编制端Excel / GL Budget / HyperionEPM Planning 原生集成项目双控GL Projects 拼装Ledger or Project 原生容差基本无Tolerance %审计轨迹较弱预留生命周期强定制PL/SQL 很自由配置 扩展底层不开放部署本地SaaS / OCI五、具体业务示例项目采购“双控”场景成本中心 CC1001设备费预算 200 万项目 P2026Task T01 预算 80 万一张 PR买服务器 90 万既带 CC1001也带 P2026/T01EBS 行为GL Funds Check: CC1001 设备费可用 200万 - 已占用 PR 90万 → 若够过 PA Funds Check: P2026/T01 可用 80万 PR 90万 → 超 10万但 EBS 里GL 和 PA 是两套检查如果 PA 控制级别设 Track不会拦真要硬控要做 PA Budgetary Control GL Budgetary Control 同时 Absolute并发提交时未审批不占预算容易出现“审批时才发现没钱”Fusion 行为Control BudgetCORP_OPEX_2026: CC1001 设备科目 200万, Absolute PROJ_P2026: P2026/T01 80万, AbsolutePR 提交瞬间Ledger pool: Commitment 90万 → 200-90110万 ✅ Project pool: Commitment 90万 → 80-90 -10万 ❌结果PR 直接被拦不用等 PO 审批。如果项目预算调整为 95 万Project pool: 95-90 5万 ✅ PR 可提交 → PO → Invoice → Expenditure六、预算编制端EBS 弱Fusion 强EBSGL Budget WorksheetExcel → GL Budget JournalHyperion Planning外部项目预算在 Oracle Projects 里做 baseline特点编和控耦合在 GL协同能力弱。FusionEPM Planning Financials ├─ 部门填报 ├─ 版本 / 情景 / 滚动预测 ├─ 审批流 └─ Data Management → ERP Control Budget特点编制版本和控执行预算分离编制端改了控制端可以“修订预算”支持预算调剂、追加、转移、重估七、什么时候选 EBS 模式什么时候选 Fusion 模式适合 EBS 预算模型本地部署、数据不能上云组织架构不复杂主要是“费用/采购不超科目预算”有老 Hyperion / Excel 体系二开能力强要改 GL_BC_PACKETS / PO_ENCUMBRANCES适合 Fusion 预算模型多 BU、多币种、多项目型业务要“申请占、订单占、发票占”分开看项目预算 部门预算都要硬控要 EPM 编制 → ERP 执行 → BI 分析闭环审计要求预留全链路可追溯能接受 SaaS 和订阅成本八、一句话总结**EBS 的预算是“GL 里的钱袋子PR/PO 往里塞 Encumbrance”Fusion 的预算是“独立控制引擎里的多维资金容器Commitment / Obligation / Expenditure 分层流动EPM 编、XCC 控、BI 看”。**