The Entity dimension, the tree the close climbs
The legal structure of the group, drawn as a hierarchy the consolidation walks bottom to top, and the single key that ties every consolidated number back to a ledger somebody actually closed.
Every cell in a consolidation cube answers several questions at once, and each dimension carries one of them. This page is the question of whose company a number belongs to. How it then travels up the tree lives on the Consolidation page, and the whole reference is mapped on the FCCS index.
◆ How the tree works— base and parent, the walk, and the percentages that change with time.
| Piece | What it does |
|---|---|
| Base entities | The leaves, the actual companies. Data loads here and only here, each carries its own currency, and behind each stands a ledger in the ERP, which is the fact everything else on this page depends on. |
| Parent entities | Computed, never loaded. A parent holds the sum of its children's contributions in its Entity Consolidation member, and a group is just the topmost parent. |
| The walk | Consolidation runs each parent and child pair from the bottom of the tree to the top, the conveyor belt executing once per pair. The first common parent of two trading entities is where their eliminations meet and matched amounts net to zero, so the tree's shape decides where eliminations land. |
| Ownership by period | The consolidation percentage and method for each parent and child pair are set by scenario, year, and period, because groups buy, sell, and merge mid-year. After an ownership change, the data is recomputed, and the effective dates are the audit trail of who owned what, when. |
◆ Shared entities, and the reconciliation key— alternate views done right, and the mapping that makes the whole cube trustworthy.
| Topic | What to know |
|---|---|
| Shared instances | A management view, regional rollups beside the legal tree, is built by sharing the one entity into an alternate hierarchy, never by copying it. One entity, one set of data, several places to read it from. |
| Their behaviors | Shared instances are the same member wearing two positions, so operations treat them as one: a clear aimed at a shared instance does not clear independently of its base. And when shared instances merge under a parent, the cumulative ownership can shift, which is exactly when the system writes the parent-only adjustment members from the consolidation belt. Rarely seen, and when seen, that is the story. |
| The reconciliation key | Each base entity maps to a ledger and balancing segment in the ERP, and that mapping is what lets the warehouse tie the consolidated result back to the general ledger, entity by entity, period by period. It is the single most valuable row of metadata in the whole application, and it deserves to be documented like one. |
In the owned star, the entity flattens into level columns with currency and the ledger mapping as attributes, and the entity-by-entity tie to the ledger runs as the gate before anything publishes. Structure and behaviors verified against Oracle's documentation, July 2026.
- base entity
- A leaf, an actual company, a ledger behind it. The only place data loads.
- first common parent
- Where two traders' eliminations meet. The tree's shape decides it.
- shared instance
- The same entity in a second hierarchy. One member, two positions, never a copy.
- consolidation percentage
- Ownership applied per parent and child, per period. The belt reads it.
- the ledger mapping
- Base entity to ledger and balancing segment. The reconciliation lives on it.