Analytics Catalog/Oracle EPM/Account Reconciliation/Data Model
Explore the catalogAccount ReconciliationStatus exportTM exportFCCS
Oracle EPM Cloud · Account Reconciliation · Data Model

The ARCS star, conformed and gated

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

Note: ARCS, Oracle's account reconciliation module, answers questions about the open period. Keeping the history, every status, every match, every month, takes a small database of your own beside it. This page is that design.

One question this page answers: what do we actually build beside ARCS so status, aging, and match history survive the period lock? The whole module is mapped on the Account Reconciliation index.

RuleConform the dimensions, snapshot status daily, land both exports nightly, and gate before anyone reads. History is the product.
Nevermodel per source or per match type. Conformity is the point; a star per table spends it.
The star, drawn and drillable, three facts, five dimensions, every node opening its page.

Three facts, five dimensions, one rule: every dimension conforms. dim_period and dim_entity are the same spine the FCCS star uses, so the reconciliation count for a close day and the consolidation story for that day join on equal keys. fact_status_daily is the history the application never keeps: one row per reconciliation per day, which is what makes "when did it reopen" a query.

THE CONFORMED STAR · GCP · AWS · AZURE TIES ACROSS CATALOGS dim_period dim_profile dim_entity dim_user dim_match_type fact_status_dailyone row per rec per day fact_balancesource · subsystem · bucket fact_tm_transactionmatched · suggested · unmatched FCCS close pagesthe cross-catalog tie nightly gatesfour asserts, listed below the consolehow are we doing on the close?run it live → every dimension joins every fact · underlined boxes open their pages · dim_period and dim_entity are the same spine the FCCS pages use ARCS: Account Reconciliation Cloud Service · conformed: one definition shared by every fact, and across catalogs
The four gates, and the cross-catalog tie, the asserts that run nightly, and the join to the FCCS pages.
Nightly gateThe assert
PopulationStatus rows today equal the period population. June: 412, every day, or the load stops.
Status footClosed plus open plus pending equals the population. Tuesday: 268 + 96 + 45 + 3 = 412.
TM footMatched plus suggested plus unmatched equals loaded. June: 23,911 + 293 + 414 = 24,618.
Aging recomputeBuckets sum to unmatched: 198 + 121 + 58 + 37 = 414, recomputed from row ages, not carried.

Cross-catalog, the close-day reconciliation story sits beside the FCCS close task page and the consolidation status: the Wednesday reopen of 1010-CL on these pages is the same late Chilean journal on those. One sample world, three ways in, and the console answers from all of it.

THE USE CASE, SIMPLIFIED

The problem: Reconciliation history disappears when the period locks.

What we build: The conformed star lands both exports nightly with daily status history, gated.

What you get: Any period, any reconciliation, forever, joined to the close data on equal keys.

Ready to own the reconciliation history?
A 10-day engagement lands this star on your cloud: both exports wired, the four gates running, and the console answering close questions from your own data.
Talk to us
Terms on this page
conformed dimension
One definition, every fact, every catalog. The moat.
fact_status_daily
The history ARCS never keeps. One row per rec per day.
gate
An assert before anyone reads. Four of them, nightly.
the tie
Same period and entity keys as the FCCS star. One world.