Search Results gl_alloc_interim_2

Overview

GL_ALLOC_INTERIM_2 is a temporary (interim) working table used by the Oracle General Ledger MassAllocations and MassBudgets processes in Oracle E-Business Suite 12.1.1 and 12.2.2. During allocation and budgeting runs, the allocation engine requires a staging area to hold the generated journal line detail before it is validated, aggregated, and finally posted to the permanent GL_JE_LINES and GL_JE_HEADERS tables. GL_ALLOC_INTERIM_2 serves precisely this role: it captures the intermediate, in-flight results of an allocation or budget formula so that the concurrent program can process large volumes of calculated lines without committing them prematurely to the general ledger.

Because the object is described in the ETRM metadata as "Not implemented in this database," it must be treated as a transient structure whose presence and population are entirely governed by the allocation run lifecycle. Rows are inserted, consumed, and typically purged within the span of a single MassAllocation or MassBudget concurrent request. Under the heuristic Data Vault classification derived from its foreign key structure, the table is characterized as satellite-leaning — that is, it behaves like a descriptive satellite attached to a parent business entity (the allocation formula definition) rather than as an independent hub or a link resolving many-to-many relationships. This classification is a modeling suggestion only and reflects the fact that GL_ALLOC_INTERIM_2 carries formula-derived descriptive and numeric detail keyed back to a definition table.

Key Information Stored

The documented structure of GL_ALLOC_INTERIM_2 is anchored by its relationship to GL_ALLOC_FORMULA_LINES. The most significant columns include:

• FORMULA_ID — Identifies the MassAllocation or MassBudget formula that produced the interim rows. This is the principal foreign key and the strongest business-key candidate, joining to GL_ALLOC_FORMULA_LINES.FORMULA_ID.
• FORMULA_LINE_NUMBER — The sequence number of the individual formula line within the parent formula. Together with FORMULA_ID it forms the composite foreign key back to GL_ALLOC_FORMULA_LINES and provides line-level traceability.
• Allocation and journal detail columns populated by the allocation engine, such as the target account combination, the calculated debit or credit amount, the currency, the period, and the balancing segment values derived from the formula's basis.
• Source and target identifiers that distinguish which journal batch, ledger, and accounting period the interim lines belong to.
• Status or processing-indicator columns used by the concurrent program to track which rows have been validated, offset, or posted.

The surrogate or composite primary key for this table is not documented in the ETRM metadata. In practice, the composite of FORMULA_ID and FORMULA_LINE_NUMBER functions as the practical business key for joining purposes, while any internal sequence or row identifier, if present, acts as the surrogate. Because the object is a temporary work table, no unique index is documented, and duplicate interim rows are possible across concurrent runs.

Common Use Cases and Queries

Diagnostic and reconciliation queries against GL_ALLOC_INTERIM_2 are common when an allocation run fails, produces unexpected results, or leaves residual rows. A typical trace query joins the interim table to its parent formula lines to confirm which formula generated each staged allocation:

• SELECT i.formula_id, i.formula_line_number, f.* FROM gl_alloc_interim_2 i JOIN gl_alloc_formula_lines f ON f.formula_id = i.formula_id AND f.formula_line_number = i.formula_line_number;
• Detecting orphaned interim rows left behind after an abnormal termination of the MassAllocation program, which can be used to decide whether the temporary area needs manual cleanup.
• Auditing allocation output before posting, by comparing staged amounts against the expected basis and offset accounts defined in the formula.
• Performance tuning of large MassAllocation runs, where row counts and distribution patterns in the interim table inform indexing or purge strategies.

Because the table is transient and not implemented as a persistent object, queries should always be scoped by FORMULA_ID and by the relevant concurrent request or period to avoid scanning stale data.

Related Objects

The following objects are the most significant in relation to GL_ALLOC_INTERIM_2:

• GL_ALLOC_FORMULA_LINES — The documented parent of the foreign key relationship; joined on FORMULA_ID and FORMULA_LINE_NUMBER.
• GL_ALLOC_FORMULAS — Header-level definition of the MassAllocation or MassBudget formula referenced by FORMULA_ID.
• GL_JE_LINES — The permanent journal line table that ultimately receives the validated output staged in the interim table.
• GL_JE_HEADERS — The journal batch header that groups the posted allocation results.
• GL_JE_BATCHES — Provides batch-level control totals against which interim allocations are reconciled.
• GL_LEDGERS — Supplies the ledger context for the allocation run.
• GL_BUDGETS and GL_BUDGET_ASSIGNMENTS — Relevant when the interim table is used by the MassBudget variant of the process.

These relationships should be used to construct traceability queries from formula definition through staging to final posted journal detail.