Entity, the dimension approvals ride

Every entity is a planner, and every approval unit is an entity in a scenario and version. Below: the tree itself in tabular form, then the cascade and exclusion rules that surprise people.

Note: In Planning, Oracle's budgeting and forecasting module, the Entity dimension is who plans: the organizational units that each build a budget and submit it for approval. This page is that dimension, and the approval machinery bolted to it.

The whole module is mapped on the Planning index.

RuleOne entity spine across plan, close, and reconciliation; approval units at the level you review; template chosen by where the first edit happens.

Neverexclude an approval unit casually. The annotations and history go with it, and the doc says so.

◆ The dimension, and the machinery on it, the states, the cascade, the exclusion caution, the three design decisions.

Before the machinery, the dimension itself. An excerpt of the sixty-entity tree in the sample world, the way it reads in the dimension editor:

Member	Description	Parent	Currency	Approvals
Total Company	All sixty entities rolled up	(top of tree)	USD	parent unit
AMER	Americas region	Total Company	USD	parent unit
1000-US	United States operating company	AMER	USD	approval unit
1010-CL	Chilean subsidiary	AMER	CLP	approval unit
EMEA	Europe, Middle East, Africa	Total Company	USD	parent unit
2000-DE	German subsidiary	EMEA	EUR	approval unit
2010-UK	United Kingdom subsidiary	EMEA	GBP	approval unit
APAC	Asia Pacific region	Total Company	USD	parent unit
3000-JP	Japanese subsidiary	APAC	JPY	approval unit
…	fifty-three more leaf entities	by region	local	approval units

The naming convention carries information: a four-digit code plus a country suffix, first digit assigned by region, so 1010-CL reads as an Americas entity, Chile, at a glance. Every leaf is an approval unit. Regions and Total Company are parent units, which lets a reviewer act on a whole region at once. When any page in this catalog says 1010-CL, this is who it means: the Chilean subsidiary whose late journal runs through the close, reconciliation, and planning stories.

Entity is the dimension approvals are built on: the approval-unit hierarchy is entities, each unit a scenario-version-entity combination that moves through the documented states, per the states reference. Two structural facts matter at design time. Parent status changes cascade to children unless a child was excluded or already approved. And excluding a unit discards all of its annotations and history, with data values retained, per the approvals tutorial: exclusion is not a pause button.

Design decision	The rule
Entity spine	Same sixty entities as the close and reconciliation catalogs. One dim_entity across all three is the point of owning the model; the plan for the Chilean subsidiary 1010-CL and the late journal against it join on one key.
Approval granularity	Units at the entity level you actually review at. Sixty units for sixty entities in the sample world. Going deeper adds approval steps without adding information.
Template choice	Bottom-up starts ownership at the bottom of the hierarchy, distribute at the top, per the actions doc. Pick by where the first real edit happens.

THE USE CASE, SIMPLIFIED

The problem: Plan, close, and reconciliation each carry their own entity list, and nothing joins.

What we build: One conformed entity table in your warehouse, with plan, close, and reconciliation data all keyed to it.

What you get: 1010-CL is one row everywhere. A question that crosses systems becomes a join, not a project.

Three catalogs, three entity lists, nothing joining?

We conform the entity dimension across plan, close, and reconciliation in your warehouse, and 1010-CL means the same thing everywhere.

Talk to us

Terms on this page

approval unit: Entity plus scenario plus version, moving through the states.
cascade: Parent status changes children, unless excluded or approved.
exclusion: Removes the unit and discards its annotations and history.
conformity: One entity key across catalogs. The moat.