The FCCS consolidation engine runs in three stages — Local Currency, Translated, Consolidated. Each stage has a fixed sequence of system processes that cannot be moved, removed, or reordered. Within each stage, Oracle has designated specific configurable seed points where implementer logic can be inserted. These are the only places custom calculation rules run as part of the consolidation cycle.
On-demand rules are architecturally separate. They live outside the consolidation process entirely. They cannot be placed into the engine sequence — the system prevents it. They are invoked explicitly, by a user with the right access, at the right moment relative to the close calendar.
The first question when writing any rule is not "Groovy or Essbase?" It is: "Does this belong in the consolidation engine cycle, or is it on-demand?" Everything else follows from that answer.
The mess is not a rule accidentally entering the engine — the architecture blocks that. The mess is an on-demand rule triggered at the wrong point in the close cycle: before translated data exists, after a period is locked, or twice against the same data state. The close calendar and access controls govern when and by whom on-demand rules are triggered. This is process discipline, not system enforcement.
Across the three stages, there are exactly six configurable seed points: Stage 1 — After Opening Balance Carry Forward, Final Calculations · Stage 2 — Translation Overrides, Before FX Calculations, After Opening Balance Carry Forward · Stage 3 — Configurable Consolidation, After Opening Balance Carry Forward, Final Calculations. Every implementer-written consolidation rule must be deployed to one of these six points.
Run automatically as part of every Consolidate action. Part of the cycle — they run when the engine runs, at the stage and seed point they are deployed to.
Deployed and available but live outside the consolidation process entirely. Cannot be placed into the engine sequence — the architecture prevents it. Invoked explicitly by a user with access.
The architectural separation is fixed — on-demand rules cannot enter the engine. The risk is temporal, not structural. An on-demand rule triggered before translated data exists operates on untranslated local currency data and produces wrong results. Triggered after a period is locked fails or corrupts approved balances. Triggered twice against the same state doubles the adjustment. The close calendar and access controls (Hall 8) govern when and by whom on-demand rules are triggered. This is process discipline, not system enforcement.
DeutschWerk sold €420,000 of components to BritEdge. BritEdge has not sold half of them onward at period end. The £210,000 unrealised profit sits in BritEdge's inventory. Standard Eliminations in Stage 3 handled the basic IC revenue/COGS elimination automatically. The unrealised inventory profit is not handled by any system process — it requires judgement and a decision.
| Situation | Correct Approach | Where It Runs | Who Decides |
|---|---|---|---|
| One-off, variable amount, Finance team knows the inventory status | Enterprise Journal with supporting documentation | Hall 7 — Journals & Approvals | Finance Controller |
| Pattern emerging — same entities, predictable margin, quarterly recurrence but not every period | On-demand Groovy rule — triggered explicitly when the pattern applies | Outside engine, invoked by authorised user | Finance Controller + FCCS admin |
| Fully systematic — same entities, fixed margin rate, every single period, Finance never needs to judge | Configurable Consolidation rule in Stage 3 — runs every cycle automatically | Configurable Consolidation seed point, Stage 3 | Implementation team + Finance sign-off |
In practice, unrealised profit elimination is almost always a journal. Finance teams know their inventory positions. The amount varies. The judgment belongs to the Controller. Rules are only warranted when the pattern is so systematic and the volume so high that manual journals introduce more risk than a rule. That threshold is higher than most implementations assume.
Groovy rules in FCCS are written in the Groovy scripting language and run within the FCCS runtime context. They can read and write data cells, iterate over dimension member combinations, access the current POV (Scenario, Year, Period, Entity), and call FCCS runtime operations.
The key distinction from Essbase calc scripts: Groovy rules are dynamic and context-aware — they can make decisions based on data values, member properties, and runtime conditions. Essbase calc scripts are batch-oriented, syntax-driven, and run against fixed member selections. For FCCS consolidation rules, Groovy is the standard approach for configurable seed point logic.
Current POV (Scenario, Year, Period, Entity) · Data cells via operation.grid.getCellWithMembers() · Member properties · FCCS runtime operations · Iteration over dimension member lists · Conditional logic based on data values at runtime.
This rule reads USD currency data — it must run in Stage 3 (Consolidated stage) where translated Parent Currency data exists. If this rule were placed in Stage 1 (Local Currency), the USD intersection would be empty and the rule would read zero. The seed point is not just a scheduling choice — it determines what the rule can see.
Stage 1 rules see Entity Currency. Stage 2 rules see Parent Currency. Stage 3 rules see consolidated elimination data.
| What Your Rule Needs | Correct Stage | Correct Seed Point |
|---|---|---|
| Entity-level local currency data before translation | Stage 1 — Local Currency | After Opening Balance Carry Forward or Final Calculations |
| Override a specific account translation rate | Stage 2 — Translated | Translation Overrides |
| Adjust translated data before CTA is calculated | Stage 2 — Translated | Before Foreign Exchange (FX) Calculations |
| Adjust translated data after CTA is calculated | Stage 2 — Translated | After Opening Balance Carry Forward |
| Post a custom elimination entry (IC or other) | Stage 3 — Consolidated | Configurable Consolidation |
| Calculations using fully consolidated group data | Stage 3 — Consolidated | Final Calculations |
Q1 consolidation has run. All entities are at OK status. The Group Finance Director raises three issues that require calculation rule decisions. For each one: identify whether a consolidation rule, on-demand rule, or journal is the right approach, name the correct seed point if a rule is warranted, and explain your reasoning.
FCCS sandbox with GlobalMerge Corp fully configured · Calculation Studio open · All four entities (BritEdge GBP 100%, DeutschWerk EUR 80%, AsiaLink SGD 50% JV, NovaTech USD 30%) at Consolidated status for Q1 Actual.
DeutschWerk holds €2,000,000 of hedged receivables. Under IAS 39, these must translate at the hedge rate (1.05), not the Q1 average rate (1.09). The default translation engine applies 1.09 to all EUR accounts. This will happen every single quarter for as long as the hedge is in place.
- 01 Open Calculation Studio → New Rule. Set type: Consolidation Rule. Stage: 2 — Translated. Seed point: Translation Overrides.
- 02 Write a Groovy rule that reads the HedgedReceivables account for DeutschWerk, re-translates at rate 1.05, and posts the difference to the Translation Adjustment account.
- 03 Deploy the rule. Run consolidation. Verify the translated USD balance for HedgedReceivables reflects rate 1.05, not 1.09.
- 04 Confirm the rule fires automatically on every subsequent Consolidate action — no user trigger required.
BritEdge holds €210,000 of DeutschWerk components in inventory at period end. The Finance Controller confirms this is a Q1-specific situation — BritEdge typically sells through inventory within the quarter and this is unusual. She wants the adjustment made this quarter but does not expect it to recur.
- 01 Navigate to Hall 7 — Journals & Approvals. Create a new Enterprise Journal for entity BritEdge, Actual Q1.
- 02 Post the elimination: Dr FCCS_Inventory £210,000 / Cr FCCS_RetainedEarnings £210,000 in the Elimination member.
- 03 Attach supporting documentation: the BritEdge inventory schedule showing unsold DeutschWerk components as at Q1 end.
- 04 Submit for Finance Controller approval. Once approved, the journal posts and feeds into consolidated results.
The CFO wants a consolidated EBITDA margin ratio calculated and stored in FCCS after every consolidation — so it appears in dashboards automatically. The ratio uses consolidated Revenue and EBITDA figures that only exist after Stage 3 completes.
- 01 Open Calculation Studio → New Rule. Type: Consolidation Rule. Stage: 3 — Consolidated. Seed point: Final Calculations.
- 02
Write Groovy to read the consolidated EBITDA account and consolidated Revenue account at GlobalMerge level. Calculate EBITDA / Revenue. Store the result in a dedicated ratio account (e.g.,
KPI_EBITDA_Margin). - 03 Deploy the rule. Run consolidation. Confirm the KPI account is populated in the GlobalMerge entity after consolidation completes.
- 04 Verify the rule cannot access the ratio if run at a Stage 1 or Stage 2 seed point — the consolidated inputs do not exist there. The Final Calculations position in Stage 3 is the only correct placement.
- → Equity Pick-up runs in Stage 1 — Local Currency — before translation. AsiaLink's equity method investment value is therefore calculated in SGD first, then translated in Stage 2. What does this mean for the CTA calculation on AsiaLink's investment? Does the investment carrying value produce a CTA, and where in Stage 2 does that CTA appear?
- → A junior implementer writes a Groovy rule that reads USD consolidated data and places it in Stage 1 — After Opening Balance Carry Forward — because "that's the first configurable seed point." What will the rule read and why? What is the fix?
- → Standard Eliminations in Stage 3 is system-locked. The basic BritEdge/DeutschWerk IC elimination runs there automatically. If GlobalMerge needs a custom elimination for a specific intercompany arrangement — for example, a management fee elimination between GlobalMerge Corp and DeutschWerk — which seed point does that custom rule sit in, and why can it not sit in Standard Eliminations?
- → An on-demand Groovy rule for unrealised profit elimination is written and deployed. The close calendar says it should be triggered after Consolidate completes for Q1. A junior analyst triggers it before Consolidate runs — against Impacted data. What does the rule actually operate on, and what result does it produce?
- → The CFO asks: "Why can't FCCS just automatically calculate unrealised profit and eliminate it like it does intercompany revenue?" What is the precise technical and accounting reason, and how do you explain it to a non-technical Finance Controller?
Calculation Studio, seed points, and rule type architecture are consistently tested in the Oracle FCCS Implementation Specialist exam. Expect scenario-based questions that require you to correctly identify the stage, seed point, and rule type for a given business requirement.