Analytics Catalog/Oracle EPM/FCCS/Consolidation Status
Explore the catalogFCCSEntity dimensionConsolidation dimensionKnown issues
Oracle EPM Cloud · FCCS · Close report

The Consolidation Status report, the close's heartbeat

Before any number in the application is worth reading, one question comes first: has everything that changed been consolidated? Status answers it per entity, per period, and close managers live on this screen for a week every month.

This page opens the reports shelf of the FCCS reference. The eight dimensions behind these reports each carry one question of the cube, mapped on the FCCS index, and this report reads two of them together, the entity tree and the close's own clock.

RuleRead status before trusting any number. An Impacted entity means something changed beneath it and its parents are stale until the consolidation runs again.
Neverchase a variance on an entity whose status is not OK. Consolidate first, investigate second; the other order wastes an afternoon explaining a number that was about to change.
One Tuesday in close week— the report in use, a worked example any close manager will recognize.

A group of sixty entities, day three of the close. At 18:40 the Chilean subsidiary posts a late journal, a reclass their auditor requested. The status view, readable in the application and in a Smart View grid, now shows this on the affected branch:

EntityStatusWhat it means right now
GroupImpactedSomething below changed. The top line on every report is stale until the run.
· EuropeOKUntouched by the change. Its numbers are still good.
·· GermanyOKNothing to do here.
· AmericasImpactedThe change is somewhere in this branch.
·· United StatesOKIts own data is unchanged; only the parents above are stale.
·· ChileImpactedThe late journal landed here. This is where the trail starts.

The moves, in order. Consolidate the Americas branch, and the belt runs Chile, then each parent pair on the way up, statuses flipping to OK from the bottom. Only then reopen the variance report that was on screen at 18:39, because until the run, it was explaining a number that was about to change. Once the journal is approved, lock Chile, prior periods first. And if tomorrow morning a sibling of Chile opens Impacted for no visible reason, that is not a mystery, it is the second row of the table below, arriving on schedule.

Reading the statuses— what each value means, and the 24.10 split every upgraded application now shows.
StatusWhat it tells you
OKConsolidated since the last change. The only status a period should close on, for every entity, parents included.
ImpactedData, ownership, or metadata changed beneath this point since the last run. The number on screen still shows, and it is stale. Consolidation clears it, bottom up.
No DataNothing loaded here for this period. Expected on new entities and empty scenarios, and a flag when it appears where a trial balance should have landed.
System ChangeA release touched stored results, historically the signal to re-run after an upgrade, the Compute Rates then re-consolidate routine. Pairs with the update governance habit.
Calc Status and Node Status, since 24.10One status became two. Calc Status follows the entity's own input and consolidated data, while Node Status follows the parent-side members of the consolidation belt, Proportion, Elimination, Contribution. Shared instances of an entity can now show different node statuses in different positions, which is the point: the same books, several places in the tree, each with its own freshness.
When status misleads— the documented cases where the heartbeat reads wrong, and what each one looks like.
CaseThe pattern, from Oracle's own issue notes
Copy Data sets the wrong statusCopying data or override rates between entities has mis-set statuses in documented cases, targets left unimpacted when they should flip, sources flipped when they should not, empty copies marked Impacted. After any copy, treat status as a claim to verify, not a fact.
Ownership changes leave stale statusChanging ownership data under a consolidation rule has left the entity and its partner showing the wrong status. The habit after ownership work: re-consolidate the affected branch regardless of what the screen claims.
Next month opens Impacted, for no visible reasonDocumented and subtle: when partner eliminations write to a sibling entity, the sibling's status stays clean in the current period and flips Impacted in future periods. The mystery Impacted on a fresh month is often last month's intercompany, arriving on schedule.
Smart View edits that never impactAn ad hoc grid with a root Period member left on it can change data without setting entity impact status at all. The one silent case on this list, and the reason grids should carry real periods, not the dimension root.
Locking, and the order it demands— the Invalid Data error decoded, and the question asked on the forums this January.
SituationWhat to know
The Invalid Data error on lockLocking runs in order: an entity locks only after its prior periods, and its descendants' prior periods, are locked. The error message decodes to exactly that, somewhere below or behind this entity, an earlier period is still open.
A new entity joins a locked hierarchyAsked live on Customer Connect this January: entities locked for all history, one new member added, and the new entity needs locking up to the current period before the branch behaves again. The order rule above is why, history first, then now.
Lock status and approvals, since 24.10A configurable task updates lock status from the approval process, runs as a job, and can run long on large applications. Check it completed before reading the locks as truth.

In the owned warehouse, the star schema we recommend building beside FCCS on your own cloud, mapped here, status lands beside the data and the publish gate is a query, every entity OK for the period, or the load waits. That gate is exactly what our read-only console's close-readiness light reads. Statuses, documented cases, and locking behavior verified against Oracle's documentation and release notes, July 2026.

A close that ends when the emails stop?
We wire status into the warehouse and turn done into a query result, every entity OK, every lock in place, checked nightly.
Talk to us
Terms on this page
Impacted
Something changed beneath. The number shows, and it is stale.
System Change
A release touched stored results. Re-run before trusting.
Node Status
Freshness of the parent-side belt members, per position, since 24.10.
the lock order
History first, descendants included, then the current period.