Analytics Catalog/Oracle EPM/Planning/Data Model
Explore the catalogPlanningLevel-0 exportForecast accuracyFCCS
Oracle EPM Cloud · Planning · Data Model

The plan star, conformed and gated

The application answers about the current plan; the star answers about every plan it has ever seen. Three facts, five dimensions that conform across catalogs, and four asserts that run before anyone reads a number.

Note: Planning, Oracle's module where budgets and forecasts are built, answers questions about the current version of the plan. Keeping every version, every approval state, every month takes a small database of your own beside it. This page is that design.

The whole module is mapped on the Planning index.

RuleConform the dimensions, land the three facts nightly, snapshot forecasts immutably, and gate before anyone reads.
Neverlet a past snapshot be corrected. The moment April can change, forecast accuracy stops being a measurement and becomes an opinion.
The star, drawn and drillable, three facts, five dimensions, every node opening its page.

Three facts, five dimensions, one rule: every dimension conforms. dim_entity and dim_period_years are the same spine the close and reconciliation stars use, so the plan for 1010-CL, the Chilean subsidiary, its consolidation, and its reconciliations all join on equal keys. fact_plan_level0 keeps every lane and version as loaded each night. fact_approval_daily is the history the application never holds. fact_workforce keeps the employee-job rows with their components.

THE PLAN STAR · GCP · AWS · AZURE TIES ACROSS CATALOGS dim_entity dim_period_years dim_scenario dim_version dim_account fact_plan_level0level-0 rows · lane named fact_approval_dailyone row per unit per day fact_workforcecomponents as columns the close and reconciliation starssame entity and period keys nightly gatesfour asserts, listed below the consolehow is forecast tracking against budget?run it live → every dimension joins every fact · underlined boxes open their pages · dim_entity and dim_period_years are the spine the close and reconciliation stars use star: the warehouse model on GCP, AWS, or Azure · console: the read-only Irvine Analytics assistant · conformed: one definition shared everywhere
The four gates, and the ties, the asserts that run nightly, and the join across catalogs.
Nightly gateThe assert
Plan totalsLevel-0 rows sum to the reported lane totals: the forecast lane foots to 851.4M revenue, or the load stops.
Approvals footUnit states sum to the population: 41 + 12 + 6 + 1 = 60, every day.
Workforce footActive plus requisitions equals headcount, 4,806 + 74 = 4,880, and components sum to total compensation.
Snapshot immutabilityPast forecast snapshots never change: April's rows in July are April's rows in December. The accuracy report depends on this one.

The driver decomposition rides the same star: 6.1 + 2.4 + 0.9 explaining the 9.4M lives as computed columns, not a spreadsheet. Cross-catalog, the plan sits beside the close and reconciliation stories: one world, three catalogs, one console over all of it.

THE USE CASE, SIMPLIFIED

The problem: Every question about last quarter's plan requires an administrator, and half the answers no longer exist.

What we build: The plan star: level-0 facts, approval history, and workforce rows on the same entity and period keys as your close and reconciliation data, gated nightly.

What you get: Any version, any month, any entity, one query, forever. The application plans; the warehouse remembers.

Ready to own the plan's history?
A 10-day engagement lands this star on your cloud: the exports wired, the four gates running, and the console answering plan questions from your own data.
Talk to us
Terms on this page
conformed dimension
One definition, every fact, every catalog. The moat.
fact_approval_daily
The history the application never keeps.
immutability
Past snapshots never change. Accuracy depends on it.
one world
Plan, close, and reconciliation joined on equal keys.