Search Results gl_alloc_interim_3

Overview

GL_ALLOC_INTERIM_3 is a temporary (interim) working table used by the Oracle E-Business Suite General Ledger module to support MassAllocations and MassBudgets processing. MassAllocation and MassBudget definitions allow a single allocation formula to be applied across many accounts, cost centers, or accounting flexfield combinations at journal entry or budget entry time. Because this computation can generate a very large volume of intermediate allocation results, Oracle GL stages those results in interim tables — of which GL_ALLOC_INTERIM_1, GL_ALLOC_INTERIM_2, and GL_ALLOC_INTERIM_3 are the numbered variants — before the final allocation journals or budget lines are written to the permanent GL tables.

The object is therefore transient in nature. Rows are populated during the execution of an allocation or budget batch, consumed by subsequent processing steps, and typically deleted or truncated once the run completes. It is not intended as a reporting or archival table, and its contents should not be treated as durable business data. Access is normally restricted to the concurrent programs and internal logic that drive MassAllocation and MassBudget processing.

From a data modeling perspective, the mined foreign key structure suggests a satellite-leaning classification under Data Vault heuristics. The table hangs off GL_ALLOC_FORMULA_LINES through its formula identifier, implying that it records per-formula execution or result detail rather than participating as an independent hub or a many-to-many link entity. This should be regarded as a modeling suggestion rather than a documented architectural statement.

Key Information Stored

The documented metadata for GL_ALLOC_INTERIM_3 identifies the following columns as structurally significant:

• FORMULA_ID — Identifies the allocation or budget formula to which the interim row belongs. This is the foreign key column that joins to GL_ALLOC_FORMULA_LINES, and it functions as a principal business-key candidate for the table.
• FORMULA_LINE_NUMBER — Identifies the specific line within the referenced formula that produced the interim allocation or budget result. Together with FORMULA_ID, this forms the composite business key inherited from GL_ALLOC_FORMULA_LINES.

The metadata does not document a separate surrogate primary key column, nor does it enumerate the full column list, monetary/amount columns, account segment columns, or audit columns that would normally be present in an allocation interim table. Based on the table's stated purpose, the remaining columns may be assumed to hold the account combination and amount detail required to carry the allocation result forward, but these are not confirmed by the supplied documentation and should be verified against the actual data dictionary in a given instance.

The ETRM record explicitly notes "Not implemented in this database," indicating that the object may be absent, unused, or version-dependent in some environments. Verification of its physical presence and column set in a specific 12.1.1 or 12.2.2 instance is therefore advisable before relying on it.

Common Use Cases and Queries

Because GL_ALLOC_INTERIM_3 is a transient staging table, direct end-user querying is uncommon. Its practical uses fall into three categories: troubleshooting allocation or budget runs, validating intermediate results during development or support, and monitoring cleanup of interim data after batch completion.

A typical diagnostic query joins the interim table to its parent formula lines to confirm which formula and line produced a given set of interim rows:

• SELECT i.FORMULA_ID, i.FORMULA_LINE_NUMBER FROM GL_ALLOC_INTERIM_3 i JOIN GL_ALLOC_FORMULA_LINES l ON i.FORMULA_ID = l.FORMULA_ID AND i.FORMULA_LINE_NUMBER = l.LINE_NUMBER WHERE i.FORMULA_ID = :p_formula_id;

Support scenarios include investigating why a MassAllocation produced unexpected journals, confirming that a MassBudget batch reached the interim stage, and checking for orphaned or leftover rows that indicate an incomplete or aborted run. Because interim tables can grow quickly during large allocation batches and are not meant to persist, DBAs may also monitor row counts to ensure that cleanup logic ran correctly.

For reporting purposes, the permanent allocation and budget results — not this interim table — should be used. Any query against GL_ALLOC_INTERIM_3 should be treated as a point-in-time diagnostic rather than a source for reconciliation or financial reporting.

Related Objects

The relationship data identifies one documented foreign key dependency, and several additional objects participate operationally in the same processing chain:

• GL_ALLOC_FORMULA_LINES — The parent table referenced by GL_ALLOC_INTERIM_3.FORMULA_ID (and logically joined on FORMULA_LINE_NUMBER). This is the primary and only FK relationship documented for the interim table.
• GL_ALLOC_FORMULAS — Header table for allocation and budget formulas; joins to GL_ALLOC_FORMULA_LINES and indirectly to the interim table.
• GL_ALLOC_INTERIM_1 and GL_ALLOC_INTERIM_2 — Sibling interim tables used in the same MassAllocation/MassBudget processing flow.
• GL_ALLOC_BATCHES — Batch control table governing allocation runs.
• GL_JE_BATCHES and GL_JE_HEADERS — Destination tables for journal results generated from the allocation process.
• GL_BUDGET_BATCHES and GL_BUDGET_ASSIGNMENTS — Budget-side counterparts consumed when the interim table is used for MassBudgets.
• GL_BALANCES — Source balance data referenced by allocation formulas in computing allocated amounts.

Concurrent programs such as MassAllocation and MassBudget, along with their associated GL APIs, are the primary consumers of this object. Because documented metadata is limited to the single FK relationship, the remaining associations above are operational rather than schema-enforced and should be validated in the target instance.