ARM_BALANCE_TOTALS, and the naming scheme behind it

One row per reconciliation, a column per balance type per currency bucket, and names like BSRC100001 that look like noise until you know the scheme. Then the whole table reads at a glance.

Note: ARCS, Oracle's account reconciliation module, compares balances loaded from your systems. This table holds the summarized balances the screens display, one row per reconciliation, and this page explains its unusual column naming.

All ARCS table references hang off Tables & views; what the balances mean in workflow terms is on Balance loads.

RuleDecode column names as balance type plus bucket, join on PROFILE_ID and PERIOD_ID, and derive the on-screen measures once, in one place.

Neverhunt for Unexplained Difference as a stored column. It is computed, the thread confirms it, and the derivation belongs in your warehouse, not in every report.

◆ The scheme, decoded, balance type plus bucket, the join, and the two companions.

Per Oracle's reference, this table exists for performance: the display values behind the balance summaries, one row per reconciliation, joined to ARM_RECONCILIATIONS on PROFILE_ID and PERIOD_ID. The columns are generated from a scheme, balance type plus bucket ID, and the buckets are 100001, 100002, 100003 for Entered, Functional, Reporting. So BSRC100001 is the Source System Balance in the Entered currency, and SRC100003 is Adjustments to Source System at Reporting. Decode the scheme once and the whole table reads.

Pattern	Meaning
BSRC + bucket	Source System Balance in that currency bucket.
SRC + bucket	Adjustments to Source System in that bucket.
100001 / 100002 / 100003	Entered, Functional, Reporting. The lowest, middle, highest bucket.

Two companions. The balance types match the older ARM_SUMMARY_AMOUNTS table identically, which is why the classic practitioner queries, like the comments report, filter ARM_SUMMARY_AMOUNTS on SUMMARY_TYPE = BSRC and BUCKET_ID = 100003 and still read correctly. And the ARM_BALANCE_DETAIL_SUMMARY view returns what the Detail Balances list shows on screen, the reader-friendly companion to this machine-friendly table.

◆ The derived-column limit, what is not here, and where the derivation should live.

The known limit, from a live thread: Period Activity, Unexplained Difference, and the adjusted balances are not sitting here as columns. They are computed on screen, and your query derives them from these stored pieces. Write each derivation once, in the warehouse, and every report shares it; the full argument is on the tables page.

THE USE CASE, SIMPLIFIED

The problem: Period Activity and Unexplained Difference get rebuilt in every report, differently.

What we build: The derivations are built once in the warehouse from the stored pieces.

What you get: Every downstream report agrees, because there is one derivation.

Deriving these measures per report?

We land this table beside the ledger, derive Period Activity and Unexplained Difference once, and every report downstream agrees by construction.

Talk to us

Terms on this page

BSRC100001: Source System Balance, Entered currency. The scheme in one example.
bucket: 100001 Entered · 100002 Functional · 100003 Reporting.
ARM_SUMMARY_AMOUNTS: The older table with identical balance types. Old queries still read.
detail view: ARM_BALANCE_DETAIL_SUMMARY, what the Detail Balances screen shows.