Results for “consolidation_run_id”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

GL_CONS_BATCHES is a General Ledger consolidation table that records the association between consolidation definitions, consolidation runs, and the journal entry batches produced or consumed during a consolidation. Within Oracle EBS 12.1.1 and 12.2.2, it functions as an intersection table that binds a given consolidation run (identified by CONSOLIDATION_ID and CONSOLIDATION_RUN_ID) to the specific JE batches that participate in that run. Its documented description, "Transaction method consolidation batches," confirms this role: each row represents one consolidation batch linkage, not a standalone balance or definition record.

From a dimensional modeling perspective, the heuristic Data Vault classification suggested by the mined foreign key structure is link. The table primarily serves as a many-to-many resolution between GL_CONSOLIDATION and GL_JE_BATCHES, carrying only descriptive/audit attributes rather than extensive business descriptors. This classification is a modeling suggestion based on FK topology, not a declared property of the ETRM metadata.

Key Information Stored

The table is documented with 8 columns in the ETRM 12.2.2 physical schema. The most significant columns are:

• CONSOLIDATION_ID — Identifies the consolidation definition to which the batch belongs. It is part of the primary key and a foreign key to GL_CONSOLIDATION.
• CONSOLIDATION_RUN_ID — Identifies the specific execution (run) of a consolidation. Together with CONSOLIDATION_ID it distinguishes repeated consolidation executions.
• JE_BATCH_ID — The journal entry batch linked to the consolidation run; a foreign key to GL_JE_BATCHES and part of the primary key.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit columns recording who created and last modified each linkage row, and when.

The primary key is defined by GL_CONS_BATCHES_PK on the composite (CONSOLIDATION_ID, CONSOLIDATION_RUN_ID, JE_BATCH_ID). There is no separate surrogate single-column key documented; the composite primary key itself is the natural/business key candidate, since the combination of consolidation, run, and JE batch uniquely identifies each row.

Common Use Cases and Queries

Typical usage focuses on traceability: identifying which JE batches were generated or linked for a given consolidation run, and reconciling consolidation output back to the originating journals. A representative query joins to GL_JE_BATCHES to obtain batch names:

• List batches for a run: SELECT cb.CONSOLIDATION_ID, cb.CONSOLIDATION_RUN_ID, jb.NAME, jb.STATUS FROM GL_CONS_BATCHES cb, GL_JE_BATCHES jb WHERE cb.JE_BATCH_ID = jb.JE_BATCH_ID AND cb.CONSOLIDATION_ID = :consolidation_id AND cb.CONSOLIDATION_RUN_ID = :run_id;
• Audit who touched a linkage via LAST_UPDATED_BY / LAST_UPDATE_DATE.
• Count batches per consolidation run to validate completeness of a consolidation execution.

These patterns support reconciliation, audit, and consolidation-run reporting.

Related Objects

• GL_CONSOLIDATION — joined on GL_CONS_BATCHES.CONSOLIDATION_ID; supplies the consolidation definition.
• GL_JE_BATCHES — joined on GL_CONS_BATCHES.JE_BATCH_ID; supplies the batch details.
• GL_JE_HEADERS and GL_JE_LINES — reached transitively through JE_BATCH_ID for journal-level detail.
• GL_CONSOLIDATION_HISTORY and the consolidation concurrent programs — derive run-level context for these linkages.

Together these objects provide the consolidation-to-journal traceability chain in Oracle General Ledger.