The Planning Quest โ€บ Troubleshooting Guide
๐Ÿ“– Iโ€“III ๐Ÿ“˜ Groovy โš™ Kernel ๐ŸŽฏ Prep ๐Ÿ”
Troubleshooting
By category All Issues (47) ๐Ÿ“‹ Forms & Dashboards (9) ๐Ÿ”— Data Loads & DI (9) โšก Groovy Rules (9) ๐Ÿงฎ Calculations (6) โšก Performance (5) โœ… Approvals (4) ๐Ÿ”’ Security (3) ๐Ÿ’ฑ Currency (2)
Related
โš™ Essbase Kernel ๐Ÿ“˜ Groovy Chapter I โšก Groovy Chapter II ๐Ÿ’€ Failing Answers ๐ŸŽฏ Interview Prep ๐Ÿ  Quest Map
๐Ÿ”ง Production Reference ยท EPM 25.06+ ยท 47 Issues

EPBCS Troubleshooting Guide

Symptom โ†’ Root Cause โ†’ Fix. Every common production issue, organised by what you see first. Search by symptom or browse by category. Built from real implementation war stories.

47
Issues
8
Categories
12
Critical
EPM 25.11
Verified
How to use this guide: Search for what you're seeing โ€” e.g. "form empty", "data not loading", "Groovy silent fail", "approval stuck". Each card shows the diagnostic steps, the root cause, and the fix. Critical issues (red dot) are those that cause data loss or block the close cycle. Start there.
๐Ÿ“‹ Forms & Dashboards 9 issues
Form shows empty cells after a seeding/copy rule ran successfully.
FormsCalcโ–ผ
Root Cause
Target blocks don't exist. Groovy setDataCellValues() calls targeting non-existent blocks silently fail โ€” no error thrown. New fiscal year, new scenario, or new version has never had data written to it, so no blocks exist at those sparse intersections.
Fix
Run a block creation step before the Groovy rule: either DATACOPY FY2025 -> FY2026 (calc script, copies blocks + data) or a @CREATEBLOCK FIX for zero-based seeding. Check block count in Application โ†’ Statistics before and after.
1
Check Application Statistics โ€” Application โ†’ Overview โ†’ Statistics. Find block count for the target Scenario/Year. If count is 0, blocks were never created.
2
Manual test โ€” type a value of 0 into one target cell and Save. Re-run the seeding rule. If it now works for that entity, it's a block creation issue, not logic.
3
Add DATACOPY or @CREATEBLOCK as Step 1 in your rule chain. Block creation must precede any Groovy write to new sparse intersections.
In a composite form, Grid B shows the wrong year/period even after the user changes the selector.
Forms 2.0โ–ผ
Root Cause
In Forms 2.0, Apply Context must be explicitly configured. The stateless architecture means nothing propagates between grids automatically โ€” unlike classic forms. Grid B's RTP binding is missing or mapped to a different variable than Grid A's selector.
Fix
In Form Designer โ†’ Grid B โ†’ Member Selection โ†’ Apply Context. Explicitly map each grid's period/year to the same RTP variable as the composite form's selector. Test every grid independently after configuring.
1
Open each grid's RTP mapping โ€” in Form Designer, click Grid B โ†’ the RTP bindings panel. Verify the Year/Period RTP is mapped and points to the same variable used by the selector grid.
2
Check the 12-component limit โ€” if the dashboard has 12+ components, Forms 2.0 silently drops the overflow ones. Count all grids, charts, text boxes, and selectors.
โš  Common Trap
This is the #1 Forms 2.0 support ticket in production. A form that worked perfectly in classic Forms may show this behaviour after migration to Forms 2.0, even if the RTP logic appeared identical. Always test every grid's RTP binding explicitly after migration.
Dashboard or form takes 45+ seconds to load or times out.
FormsPerformanceโ–ผ
Root Cause (Top 3)
1. BSO cube queried for a consolidated view (all entities) โ€” 600 accounts ร— 12 entities = large block scan. 2. Dynamic Calc accounts re-evaluating on every cell access. 3. Valid Intersections rule set too large, evaluated on every cell render.
Fix
For total-entity reporting: use Smart Push to ASO reporting cube โ€” consolidation queries hit ASO (fast) not BSO. For Dynamic Calc: check if the account can be stored instead. For VI: reduce rule count to essential guardrails only.
1
Check what the form queries โ€” open the form in Administration. Are Total members (dynamic aggregations) on the rows? If yes, every open triggers a full aggregation scan.
2
Check block count โ€” Application Statistics. High block count + large block size = slow opens. Target 50โ€“200KB block size.
3
Enable database suppression (Oracle Reports) โ€” suppresses zero rows at the Essbase level. Vision Corp P&L report dropped from 45 seconds to 8 seconds with this setting.
Planner cannot save data โ€” form save button does nothing or shows a generic error.
FormsGroovyโ–ผ
Root Cause
Most likely: a beforeSave Groovy rule threw an unhandled exception, or a throwVetoException() was triggered by a validation guard. Less likely: valid intersection violation blocking the write. Rare: planning unit is Locked or Approved.
Fix
Check Jobs โ†’ Job Console for the failed rule โ€” the error message is there even though it's invisible on the form. For veto exceptions, the message should appear in the form. For VI violations, the cell won't render at all.
1
Jobs โ†’ Job Console โ€” filter to the time of the save attempt. Groovy exceptions appear here even when no message shows on the form.
2
Check approval status โ€” if the planning unit is Approved or Locked, data entry is blocked. Admin can check via Application โ†’ Manage Approvals.
3
Test without the business rule โ€” temporarily detach the beforeSave rule and retry. If save works, the rule is throwing. Isolate with a minimal test.
Supporting Detail or cell annotations are not visible after migrating to Forms 2.0.
Forms 2.0โ–ผ
Root Cause
Forms 2.0 supporting detail has limited formatting options vs classic. Cell-level annotations are supported from EPM 25.09+. If the environment is pre-25.09, annotations don't render in Forms 2.0.
Fix
Verify EPM release is 25.09+. Enable Supporting Detail in the form properties. For critical forms relying on complex Supporting Detail formatting, keep on classic until 25.12+ or use cell annotations as the alternative.
Drill-through from a form cell to ERP transaction detail is not available or returns no results.
FormsDataโ–ผ
Root Cause (Top 3)
1. Drill Through not enabled in the Data Integration application options. 2. The data was loaded using Quick Mode โ€” Quick Mode bypasses TDATASEG, so no drill anchor exists. 3. User not logged into ERP before drilling โ€” ERP requires separate authentication.
Fix
1. Enable in DI โ†’ Application โ†’ Options โ†’ Drill Through = Yes. 2. For Quick Mode loads: switch to Full workflow mode for actuals that need drill-back. 3. Instruct users to log into ERP first. 4. If Drill URL is wrong: delete and recreate the ERP Source System โ€” the new DI UI auto-sets it correctly.
Dashboard KPI shows a different number than the FRS/Reports P&L for the same cell.
FormsCalcโ–ผ
Root Cause (Top 3)
1. Different POV โ€” dashboard may show Working version, report may show Approved. 2. Data loaded but CALC ALL not re-run โ€” derived members are stale. 3. Dashboard form queries BSO, report queries an ASO cube that hasn't had Smart Push run since the latest data change.
Fix
1. Open both in Admin view and compare the exact POV (Scenario, Version, Year, Entity). 2. Run CALC ALL and refresh both. 3. If using ASO reporting cube, run Smart Push and check the timestamp. 4. Check if a Groovy rule wrote to a different Version than expected.
1
Compare exact intersection โ€” identify the precise Scenario/Version/Year/Entity/Period/Account combination in both surfaces. Differences are almost always in Version (Working vs Approved) or Entity (Total vs leaf).
2
Check calc timestamp โ€” Application โ†’ Statistics shows last calculation time. If data was loaded after the last calc run, all derived accounts are stale.
Dependent dropdown (cascading member selector) doesn't filter correctly after the parent selection changes.
Forms 2.0โ–ผ
Root Cause
Forms 2.0 supports some dependent dropdown chains but not all dependency configurations from classic forms. Complex multi-level cascades (e.g. Region โ†’ Country โ†’ Entity โ†’ Cost Centre) may have partial support depending on the EPM release.
Fix
Test on latest EPM release (25.11+). For complex chains not supported in Forms 2.0: keep the specific form on classic (via Application Settings temporarily) and log an SR with Oracle. Oracle is actively closing Forms 2.0 feature gaps.
Smart View ad hoc analysis from a Dashboard 2.0 form isn't available or the "Open in Smart View" menu item is missing.
Forms 2.0โ–ผ
Root Cause
Dashboard 2.0 forms require the Smart View Forms 2.0 plugin (introduced EPM 25.10). Without it, right-click context menu options "Open in Smart View" and "Analyze" don't appear. The plugin is separate from the standard Smart View install.
Fix
Install the Smart View Forms 2.0 plugin from EPM Cloud โ†’ Smart View โ†’ Downloads. Requires Smart View 23.200+ on the client. After install, the "Analyze", "Open in Smart View", and "Spreadsheet Export" context menu options appear on Dashboard 2.0 form grids.
๐Ÿ”— Data Loads & Data Integration 9 issues
Nightly actuals load appears to succeed but EPBCS shows different March numbers than SAP at 9am.
DataCalcโ–ผ
Root Cause (Top 3)
1. CALC ALL not run after load โ€” parent aggregations and derived accounts are stale. 2. Unmapped GL accounts landing in Unclassified_Actuals instead of correct EPBCS accounts. 3. POV mismatch โ€” report shows different Scenario/Version than what the DI rule targeted.
Fix
1. Ensure CALC ALL runs after every DI load in the nightly EPM Automate script. 2. Check DI Process Details for unmapped record count โ€” any balance in Unclassified_Actuals needs investigation. 3. Verify the exact Scenario/Version/Period the DI rule targeted matches what the report POV shows.
1
Check job sequence in EPM Automate log โ€” did runDataRule complete before runBusinessRule "CALC ALL" was called? Verify timestamps โ€” calc must run after load, not in parallel.
2
Open DI Workbench โ€” Data Integration โ†’ Process Details โ†’ click the run โ†’ Workbench shows source-to-target mapping for every record. Filter for unmapped records.
3
Compare total loaded records vs SAP โ€” DI Process Details shows row count per step. If Import count โ‰  Export count, some rows were rejected at Validate step (usually mapping failures).
Actuals data has doubled โ€” every value is exactly 2ร— what it should be.
Dataโ–ผ
Root Cause
Data Integration was run with ACCUMULATE (Merge) export mode instead of REPLACE. The load added new values on top of existing values. Second most common: the DI rule was run twice โ€” once manually and once by the nightly automation.
Fix
1. Change export mode to REPLACE for all actuals loads. 2. Re-run the DI rule with REPLACE โ€” it will clear the intersection and reload correctly. 3. Check job history to confirm the rule wasn't run twice. For prevention: REPLACE is mandatory for actuals; ACCUMULATE is only for additive scenarios (budget adjustments).
โš  Prevention
Make REPLACE the default export mode for all actuals DI rules. Document this as a standard and include it in your DI runbook. Use NOCOMMIT export mode first to validate โ€” if the row counts look correct, then re-run with COMMIT.
Data Integration ERP connection fails โ€” HTTP 401 or HTTP 403 error.
Dataโ–ผ
401 vs 403 โ€” Different Problems
401: Authentication failure โ€” wrong password, SSO/federated account (must use non-SSO service account), or expired credentials. 403: IP firewall blocking EPM Cloud IPs โ€” credentials are valid but ERP denies the connection from EPM's IP range.
Fix
401: Verify account is non-SSO (test login directly via ERP REST API with Postman). Re-enter credentials in DI Connection. Confirm GL job role assigned. 403: Contact ERP admin to add EPM Cloud IP ranges to ERP Network Access allowlist. Check Oracle's published EPM Cloud IP ranges for your data centre.
// Postman diagnostic โ€” POST to ERP REST URL: https://<erp-pod>/fscmRestApi/resources/latest/erpintegrations // Body: { "OperationName": "submitESSJobRequest", "JobPackageName": "oracle/apps/ess/financials/generalLedger/ledgers/ledgerDefinitions", "JobDefName": "ExtractCubeInformation", "ESSParameters": "null" } // HTTP 201 โ†’ credentials + roles OK // HTTP 401 โ†’ wrong password or SSO account // HTTP 403 โ†’ IP Firewall blocking EPM IPs
DI load reports success but specific accounts show zero / are missing in EPBCS.
Dataโ–ผ
Root Cause
New GL account codes added to SAP/ERP mid-year with no corresponding member mapping rule in Data Integration. Unmapped records are either rejected or land in the Unclassified_Actuals catch-all account (if one exists). Without a catch-all, records are silently dropped at Validate step.
Fix
1. Check DI Workbench for unmapped records โ€” filter by "Unmapped" status. 2. Add the missing account mappings in the dimension map. 3. If using an Unclassified_Actuals account: check its balance. 4. Re-run with REPLACE mode to reload the period correctly. For prevention: add a catch-all Like rule as the last mapping rule so no record is ever silently dropped.
Custom BIP extract in Data Integration times out โ€” only partial data loads (typically first 20%).
Dataโ–ผ
Root Cause
Direct BIP Report execution mode has a 5-minute synchronous timeout. Large ERP extracts that take 8โ€“12 minutes partially load before the timeout aborts the remaining data. The first batches write to Essbase; the rest are dropped.
Fix
Switch Execution Method from BIP Report to ESS Job in DI Application Options. Create an Oracle Enterprise Scheduler Job in Fusion wrapping the same BIP report. ESS runs asynchronously โ€” DI polls for up to 6.5 minutes. For extracts exceeding even that: partition by ledger or period range into multiple integrations.
Data loads to the wrong period โ€” March data appears in April, or values are doubled for certain months.
Dataโ–ผ
Root Cause
Overlapping period keys in the Source Period Mapping โ€” adjustment periods (e.g. Period 13) included in the regular period mapping, causing both the regular and adjustment period to match the same source key. Or: integration uses Explicit period type but some months are still mapped as Default.
Fix
Go to DI โ†’ Actions โ†’ Period Mapping. Verify no duplicate Source Period keys โ€” every source period label must map to exactly one EPM period. Remove adjustment periods from the regular mapping (they need their own dedicated integration). After fixing mappings, run Application Update to refresh the period cache.
EPM Automate runDataRule command works but Quick Mode (Direct Load) is not being used โ€” load is slow.
Dataโ–ผ
Root Cause
runDataRule does NOT support Quick Mode. Quick Mode requires the EPM REST API's runIntegration endpoint with importMode: "DIRECT". Calling runDataRule always uses the full workflow regardless of what's configured in the UI.
Fix
Switch to the REST API for Quick Mode loads: POST /rest/v3/applications/{app}/jobs with jobType: "IMPORT_DATA" and importMode: "DIRECT". Note: Quick Mode disables Workbench audit data and drill-through. Only use for high-volume loads where audit is not required.
EPBCS budget writeback to ERP fails โ€” "Error in Validating the Budget Load" or rows rejected.
Dataโ–ผ
Root Cause
ERP pre-validation rejected rows before they reached the GL. Common causes: invalid currency code, budget name doesn't match exactly what's configured in ERP (case-sensitive), or the ERP Essbase budget cube doesn't have the target scenario configured.
Fix
Go to ERP โ†’ General Accounting Dashboard โ†’ Correct Budget Import Errors. This shows row-level rejection reasons. The fix must happen in ERP dimension configuration or the EPBCS-to-ERP mapping, not in EPM logs. Budget name must match ERP configuration exactly โ€” case-sensitive.
EPM Automate fails on Linux/Mac automation server after EPM upgrade โ€” Java-related error in startup.
Dataโ–ผ
Root Cause
EPM Automate on Linux/Unix/macOS requires Java 17 from EPM 25.06. Java 8 is discontinued. The server was running Java 8. Windows users are unaffected โ€” EPM Automate Windows ships its own bundled JRE.
Fix
Install Java 17 on the automation server. Set JAVA_HOME to the Java 17 installation. Test epmautomate login in a non-production environment first. Verify no other applications on the server require Java 8 specifically before upgrading.
โšก Groovy Rules 9 issues
Groovy rule runs successfully (green in Job Console) but no data is written โ€” cells are still empty or unchanged.
GroovyBlocksโ–ผ
Root Cause (Top 2)
1. Target Essbase blocks don't exist โ€” setDataCellValues() silently fails on non-existent blocks. No exception thrown. 2. getCell() returned null (block missing or #MISSING) and null propagated into the write list โ€” null values written are treated as no-ops.
Fix
1. Run a block creation step first: DATACOPY or @CREATEBLOCK calc script before the Groovy rule. 2. Add null-guards: def val = getCell(...) ?: 0 to every getCell() call. 3. Add println("Writing ${writes.size()} cells") before the write call โ€” if it logs 0, the loop built an empty list.
// Diagnostic: add logging before write def writes = [] entities.each { e -> def val = getCell(e.getName(), "Revenue", ...) ?: 0 writes << [e.getName(), "Revenue_Target", ..., val * 1.05] } println("Staging ${writes.size()} writes โ€” if 0, check block existence") if (writes) operation.grid.setDataCellValues(writes)
Groovy rule throws NullPointerException at runtime โ€” rule aborts, nothing is calculated.
Groovyโ–ผ
Root Cause
getCell() returns null when the intersection is #MISSING or when the block doesn't exist. If the result is used directly in arithmetic without a null-guard, Java/Groovy throws NPE when unboxing null to a primitive.
Fix
Add Elvis operator to every getCell() call: def val = getCell(...) ?: 0. For allocation denominators: guard against zero division separately โ€” if (totalRev == 0) { println("No revenue"); return }.
// Safe pattern โ€” always use ?: 0 def rev = getCell(entity, "Revenue", ...) ?: 0 def total = getCell("Total", "Revenue", ...) ?: 0 if (total == 0) { println("Guard: zero denominator โ€” abort"); return } def share = rev / total // safe โ€” total โ‰  0
Groovy allocation or calculation rule runs correctly but takes 30+ minutes at scale.
GroovyPerformanceโ–ผ
Root Cause
Rule uses individual getCell() / setCell() calls inside a loop โ€” each is a network round-trip to Essbase. 200 cost centres ร— 2 calls = 400 round-trips. At 150ms each = 60 seconds minimum, plus overhead.
Fix
Replace loop with: 1 DataGridBuilder batch read โ†’ stage all writes in a list โ†’ 1 setDataCellValues() call. Total: 2 round-trips regardless of entity count. See Groovy Chapter II โ€” Performance Levers.
Groovy validation rule should stop a save with a message, but no message appears โ€” or the rule throws an unhandled exception.
Groovyโ–ผ
Root Cause
Rule uses throw new RuleStoppedException("msg") โ€” this class does not exist in the EPM Groovy API. It throws a MissingClassException, which surfaces as an internal error rather than a user-visible message.
Fix
Replace with throwVetoException("Your message") โ€” no import, no new, just the helper method. This is the only supported mechanism for user-visible form validation messages in EPM Groovy.
// โŒ Wrong โ€” class doesn't exist throw new RuleStoppedException("Invalid entry") // โœ“ Correct โ€” helper method, no import needed throwVetoException("Revenue cannot exceed $5B โ€” contact Finance Admin")
Groovy rule throws MissingMethodException on the first cube or dimension access call.
Groovyโ–ผ
Root Cause
Calling application.getEssbaseCube("Plan1") โ€” this method doesn't exist. Or calling cube.getDimension("Account") โ€” the Cube object doesn't expose dimensions directly. These are the #1 and #2 Groovy API mistakes.
Fix
Use: operation.application.getCube("Plan1") for the cube. Use: cube.getOutline().getDimension("Account") for dimensions. Use: dim.findMember("Total_Revenue") for members (not getMember()).
Groovy rule has println() debug statements but the output can't be found.
Groovyโ–ผ
Root Cause
println() in EPM Groovy routes to the EPM Job Console log โ€” not the browser console, not a log file on disk, not visible on the form to the user. If the developer is looking anywhere other than Jobs โ†’ Job Details, they won't find it.
Fix
Navigate to Application โ†’ Jobs โ†’ (find your rule execution) โ†’ Job Details. The full println() output is there. Filter by job name and time. For form rules (beforeSave/afterSave), the job appears under "Business Rule" in the Jobs list immediately after the save event.
Groovy rule using getRestApiClient() works in a form rule but fails in a standalone business rule.
Groovyโ–ผ
Root Cause
getRestApiClient() is only available in form rules (beforeSave, afterSave, onLoad) โ€” it is scoped to the form context and uses the current user's session. It does not exist in standalone business rules (EPM 25.11 limitation).
Fix
For standalone business rules that need REST calls: use HttpURLConnection with a service account credential. Create a Named Connection in EPM Workspace pointing to your EPM URL and use it in the rule for authentication. This is the documented pattern for business rule REST calls.
Groovy rule calling getSubstitutionVariable("CurPeriod") returns null or throws MethodMissingException.
Groovyโ–ผ
Root Cause
Wrong method name. The correct method is getSubstitutionVariableValue() with the full Value suffix. The short form getSubstitutionVariable() doesn't exist โ€” returns null silently or throws MissingMethod depending on context.
Fix
Use full method name: application.getSubstitutionVariableValue("CurPeriod") or cube.getSubstitutionVariableValue("CurPeriod"). To set: application.setSubstitutionVariableValue("CurPeriod", "Apr"). Note: getSubstitutionVariables() (plural, no "Value") returns a collection of all variables โ€” separate method.
Groovy rule to generate and distribute an Excel report isn't working โ€” file not appearing in Inbox/Outbox.
Groovyโ–ผ
Root Cause
Excel workbook creation via Groovy was introduced in EPM 25.07. If the environment is pre-25.07, the API is unavailable. Also: file upload to Inbox/Outbox uses the REST Jobs API (UPLOAD_FILE jobType) โ€” there is no direct uploadFileToServer() method on the connection object.
Fix
Verify EPM release is 25.07+. For file upload: use the REST API's UPLOAD_FILE job type via a Named Connection, not a direct method call. Check the EPM 25.07 What's New for the exact Groovy Excel API syntax โ€” it changed from the originally documented beta API.
๐Ÿงฎ Calculations & Essbase 6 issues
Calculation rule runs in 45+ minutes โ€” it used to run in 5 minutes.
CalcPerformanceโ–ผ
Root Cause (Top 3)
1. Block count has exploded โ€” a prior rule with loose SET CREATENONMISSINGBLK ON created millions of empty blocks. 2. FIX statement is missing the Year dimension โ€” calculates across all years instead of one. 3. Dynamic Calc account referenced inside a FIX โ€” re-evaluated per block instead of on-demand.
Fix
1. Check block count in Statistics. If exploded: find and fix the SET CREATENONMISSINGBLK rule, then clear and reload data. 2. Add Year to every FIX statement. 3. Materialize the Dynamic Calc account if it's referenced frequently in stored calcs.
1
Check Application Statistics โ€” normal Vision Corp block count ~240,000. If you see 2M+, block explosion has occurred.
2
Review all FIX statements โ€” every FIX must include Scenario, Version, Year, and Entity scope. A FIX with only Scenario = calculates all years ร— all entities.
3
Check for SET CREATENONMISSINGBLK ON โ€” search all rule scripts. Every occurrence must be paired with SET CREATENONMISSINGBLK OFF immediately after the ENDFIX.
A member formula returns the wrong value for some entities but correct for others.
Calcโ–ผ
Root Cause
Member formula references a cross-dimensional expression without proper scoping. For entities where the referenced member doesn't exist (or is #MISSING), the formula silently returns #MISSING or 0 depending on the formula logic. Also common: formula uses a hard-coded parent member that not all entities are children of.
Fix
Add @ISMBR checks in the formula for edge cases. Use @RELATIVE scoping to ensure the formula targets the correct level-0 members for all entities. Test the formula in an ad hoc grid against the failing entity specifically.
DATACOPY calc script runs successfully but the target year remains empty.
Calcโ–ผ
Root Cause
Source year has zero blocks โ€” nothing to copy. This happens when DATACOPY is attempted before any actuals or budget data has been loaded for the source year, or when the source scenario/version combination is different from what you think.
Fix
Check source block count in Statistics before running DATACOPY. Verify the exact source Scenario, Version, Year in the script matches where data actually lives. If source is empty: load seed data first, or use @CREATEBLOCK approach instead of DATACOPY for zero-based seeding.
Application Statistics shows millions of blocks โ€” significantly more than expected. Everything is slow.
CalcPerformanceโ–ผ
Root Cause
Block explosion โ€” a calc script or Groovy rule used SET CREATENONMISSINGBLK ON without a tight FIX scope, creating blocks at every sparse intersection regardless of whether data exists. Or: a poorly scoped @CREATEBLOCK ran across all years ร— all scenarios.
Fix
1. Identify the offending rule (check recent job history). 2. Fix it: add tight FIX scope, add SET CREATENONMISSINGBLK OFF after ENDFIX. 3. Clear all data and reload from backup โ€” the only way to remove phantom blocks is to clear the data. 4. Verify normal block count after reload matches pre-explosion baseline.
โš  Vision Corp Impact
A loose SET CREATENONMISSINGBLK on a 5-dimension FIX grew Vision Corp's cube from 48,000 to 1.2M blocks overnight. The application became unresponsive. Recovery required a full data reload from the previous night's backup โ€” 4-hour outage.
YTD values are wrong โ€” not accumulating correctly from January or showing the same value as the monthly figure.
Calcโ–ผ
Root Cause (Top 2)
1. Period dimension hierarchy not structured for YTD rollup โ€” YTD parent member with "+" consolidation isn't in the right position. 2. The &CurPeriod substitution variable is set to a future month, so YTD accumulates beyond the current period.
Fix
1. Review Period dimension: confirm Jan โ†’ Dec members under a YTD parent with "+" consolidation. Check if H1/H2 parents are interfering. 2. Verify &CurPeriod value: Application โ†’ Substitution Variables. For current-month YTD, it should be the current closed month, not a future one.
Budget data is showing Actual values โ€” or calc rule appears to have written to the wrong Scenario.
Calcโ–ผ
Root Cause
FIX statement is missing Scenario or Version dimension scope. Without an explicit FIX on Scenario, a rule calculates all scenarios โ€” meaning a Budget calculation also writes to Actual. This is rare in Calculation Manager rules but can happen in Groovy rules that hardcode member names incorrectly.
Fix
1. Review FIX statement: always include explicit Scenario and Version. 2. Check Valid Intersections to add a guardrail preventing writes to Actual via planning rules. 3. Restore Actual data from last backup snapshot (EPM Automate importData from the pre-calc snapshot).
โœ… Approval Workflow 4 issues
Planning unit stuck "Under Review" โ€” reviewer is on leave and budget cycle closes in 48 hours.
Approvalโ–ผ
Root Cause
Assigned reviewer is unavailable and no backup reviewer was configured in the Planning Unit Hierarchy. The unit cannot auto-advance.
Fix
Application โ†’ Manage Approvals โ†’ find the stuck unit โ†’ admin can: (1) Change the assigned reviewer to a backup, or (2) Force-advance the status to Approved as an admin action. Both actions are logged in the audit trail with admin username and timestamp โ€” the approval history is not lost.
โš  Prevention
Always configure at least one backup reviewer in the Planning Unit Hierarchy for each approval level before the budget cycle opens. Test the backup path during UAT โ€” not during a live budget close.
Planner (or admin) cannot edit a cell that was previously writable โ€” data entry is blocked without explanation.
Approvalโ–ผ
Root Cause
The Planning Unit for this Entity/Scenario/Version/Year is in Approved or Locked status. Approved blocks planner edits. Locked blocks even administrator edits (must explicitly unlock).
Fix
Check Application โ†’ Manage Approvals for the planning unit status. To reopen: admin pushes it back to the previous state (Approved โ†’ Under Review โ†’ First Pass). Document the reason in the approval comments โ€” this creates an audit trail for SOX compliance purposes.
Planner clicks "Promote" but planning unit status doesn't change from First Pass.
Approvalโ–ผ
Root Cause
The planner doesn't have the Entity dimension security access required to promote (needs Write access to the entity, not just Read). Or: the Planning Unit Hierarchy has a reviewer assigned at a higher level who hasn't acknowledged the promotion โ€” state appears stuck from the planner's view.
Fix
1. Check dimension security: planner must have Write access to the entity they're promoting. 2. Check Manage Approvals โ€” is the unit waiting for a reviewer action at a higher level? Admin view shows the full approval chain status. 3. Verify the Planning Unit Hierarchy is configured correctly โ€” the review levels must match the approval policy.
CFO approved the budget last week but EPBCS now shows different numbers than the Board Pack PDF.
ApprovalSOXโ–ผ
Causes to Investigate
1. Board Pack used Working version; EPBCS report now shows Approved version (or vice versa). 2. CALC ALL ran after the PDF was generated โ€” derived accounts updated. 3. An admin unlocked and edited an Approved planning unit post-sign-off (SOX finding). 4. Data was loaded to the wrong Scenario/Version after the PDF was created.
Fix
1. Compare exact POV of the PDF and the current report. 2. Check Application Audit Log for any data changes after the PDF generation timestamp. 3. Check Manage Approvals for any unlock events post-approval. 4. Going forward: use Narrative Reporting with live data references โ€” the "stale PDF" problem disappears permanently.
โš  SOX Note
Any data change to an Approved planning unit without documented sign-off is a SOX audit finding. If the audit trail shows an admin unlock + edit after CFO approval, this must be escalated to Finance Controllership immediately.
๐Ÿ”’ Security & Access 3 issues
A planner can see or edit data for entities they shouldn't have access to.
Securityโ–ผ
Root Cause
Entity dimension security not configured for this user's group. Or: the user is in a group that has parent-level Entity access (e.g. Total_Operating) โ€” which grants access to all descendants by default. Or: a newly added Entity member hasn't been added to the group's security profile.
Fix
Access Control โ†’ Dimension Security โ†’ Entity dimension โ†’ review the group's member access list. Remove parent member access if only leaf-level access is required. When adding new Entity members to the outline, immediately update all affected security groups. Test by logging in as a test user in the affected group.
New user cannot log into EPBCS โ€” authentication error or "you don't have access to this application."
Securityโ–ผ
Root Cause
User was provisioned in IDCS but not assigned an Application Role in EPBCS (Planner, Power User, Viewer). Or: the user's email domain federation is not configured in IDCS. Or: user was added to the wrong IDCS group (group exists but doesn't have EPBCS access).
Fix
1. In EPBCS: Application โ†’ Access Control โ†’ Users โ†’ verify the user appears and has an Application Role assigned. 2. In IDCS: verify user is in the correct group mapped to the EPBCS application. 3. If automating via EPM Automate: use assignRole command after addUser. Role assignment is a separate step from user creation.
Data Integration load succeeds but specific data doesn't appear โ€” rows are silently rejected.
SecurityDataโ–ผ
Root Cause
Valid Intersections rules are rejecting records during the DI Export step. This is not a security permission issue โ€” it's a VI rule blocking the specific Entity + Scenario + Account combination the DI rule is trying to write to. Common: a VI rule blocks Actual scenario writes for all entities, but an override for certain entities isn't configured.
Fix
Check DI Process Details โ€” rejected rows appear in the Export step with a VI violation message. Review the VI rule set for the failing Entity/Scenario combination. Either update the VI rule to allow the specific intersection, or ensure the DI target matches the VI-allowed scope.
๐Ÿ’ฑ Currency Translation 2 issues
Translated (reporting currency) values are wrong โ€” appear to use the wrong exchange rate or no translation at all.
Currencyโ–ผ
Root Cause (Top 3)
1. Exchange rates not loaded into the HSP_Rates cube for the specific period. 2. Wrong exchange rate type (Average vs Ending vs Historical) mapped to the account type โ€” Income Statement accounts should use Average, Balance Sheet should use Ending. 3. Currency translation hasn't been run after loading new FX rates.
Fix
1. Check HSP_Rates cube: open an ad-hoc grid on the Exchange Rate plan type and verify rates are populated for the period. 2. Check Account dimension properties โ€” currency translation type is configured per account. 3. Run currency translation: Rules โ†’ Translate (or CALC ALL includes translation). 4. For systematic issues: trace one cell โ€” open it in ad hoc, check Local value, apply rate manually, compare to translated value.
FX variance in the reporting currency P&L is unexpectedly large โ€” management wants a rate vs volume analysis.
Currencyโ–ผ
Root Cause
FX rate changed significantly between periods and there's no rate vs volume analysis configured in EPBCS. The full P&L movement is visible but the split between "we sold more" (volume) vs "the rate moved" (FX) is not automated โ€” Finance is calculating this manually in Excel.
Fix / Build
Build FX variance members in the Account dimension: FX_Rate_Var = (CurrPeriodRate - PriorRate) ร— LocalVolume; FX_Volume_Var = (CurrVolume - PriorVolume) ร— PriorRate. Store prior period rates in a separate Version or use @PRIOR in a member formula. This eliminates the manual Excel FX bridge that every global Finance team currently runs every month.
โšก Performance 5 issues
EPBCS is slow for all users every morning, then speeds up after the first few people use it.
Performanceโ–ผ
Root Cause
Essbase block cache is cold after the nightly maintenance window. The first queries of the day must load blocks from disk into memory โ€” subsequent queries hit the warm cache. This is normal behaviour but can be mitigated.
Fix
Add a "cache warm-up" step to the nightly EPM Automate script: run a background data export or CALC ALL covering the most-accessed intersection immediately after maintenance completes. This pre-populates the block cache before Finance arrives. Alternatively, increase the EPM data cache size in Application Settings if the environment licence allows it.
CFO consolidated P&L report (all entities) takes 45+ seconds to load in BSO.
PerformanceCalcโ–ผ
Root Cause
BSO is optimised for write-back and calculation, not for large read-only aggregation queries across all entities. Querying Total Entity in BSO triggers aggregation of 600 accounts ร— 12 entity blocks in real-time.
Fix
Implement an ASO reporting cube. Configure Smart Push to push BSO data to ASO after each CALC ALL. CFO report queries ASO โ€” aggregation is pre-computed, query returns in <2 seconds. Vision Corp saw 45 seconds โ†’ 8 seconds (BSO with database suppression) โ†’ 2 seconds (ASO).
Groovy allocation rule runs in 45 minutes for 200 cost centres. Needs to run in under 5 minutes.
PerformanceGroovyโ–ผ
Root Cause
Rule uses individual getCell() / setCell() per cost centre in a loop. 200 entities ร— 2 calls = 400 network round-trips. At ~150ms each = 60 seconds minimum, plus overhead from EPM job orchestration per call.
Fix โ€” Apply 9 Hourglass Levers in Order
1. Replace loop reads with one DataGridBuilder call. 2. Stage all writes in a list, commit with one setDataCellValues(). 3. Verify FIX scope on upstream calc scripts โ€” are they touching all years? 4. Check if the allocation basis account is Dynamic Calc (re-evaluated every getCell). 5. Check block count โ€” has a prior run created phantom blocks?
Data Integration loads for multiple entity files take too long โ€” running sequentially takes 32 minutes for 4 entities.
PerformanceDataโ–ผ
Root Cause
Multi-file DI imports are running sequentially โ€” 4 files ร— 8 minutes = 32 minutes. Parallel processing is available from EPM 25.08 but not enabled.
Fix
Enable parallel processing: DI โ†’ Application Settings โ†’ Parallel Processing = On. All 4 entity files now load simultaneously โ€” total time drops to ~10 minutes. Alternatively, use a Pipeline to orchestrate multiple integrations in the same Stage (Stage jobs run in parallel by design).
CALC ALL takes much longer this month than it did last month โ€” no changes were made to rules.
PerformanceCalcโ–ผ
Root Cause
Block count increased since last month โ€” either due to new entities, new scenarios being loaded, or a block creation rule that created more blocks than expected. More blocks = more work for CALC ALL even if the rules are unchanged.
Fix
Compare Application Statistics block counts month-over-month. If block count grew significantly without a planned dimensional expansion: investigate recent calc scripts and data loads for unintended block creation. For expected growth: consider whether a Custom CALC (scoped FIX) can replace CALC ALL for the specific accounts that changed.

ABOUT THIS GUIDE

All issues verified against Oracle EPM Cloud EPM 25.11. Block storage behaviour, API method names, and release-specific features are cross-referenced against Oracle's official Groovy Scripting Reference and EPM Cloud What's New documentation. When in doubt: check the Job Console first, Application Statistics second, Oracle Support third.