Search Results gl_alloc_targets

Overview

GL_ALLOC_TARGETS is a temporary (transient) table within the Oracle E-Business Suite General Ledger module. Its documented purpose is to serve as a staging area for MassAllocations and MassBudgets processing. MassAllocations is the GL feature that allows users to define allocation formulas — typically expressed as a percentage or a basis-point distribution of a source cost pool — and automatically distribute balances across a range of target accounts during a journal posting or batch allocation run. MassBudgets applies the same allocation engine against budget balances rather than actual balances.

Because the allocation engine must expand a set of allocation rules into concrete journal lines, it needs a working set in which each row pairs a resolved target accounting flexfield combination with the allocation formula that produced it and the concurrent request that executed the run. GL_ALLOC_TARGETS holds exactly that intermediate result. In a normal production environment this table is generally empty outside of an active allocation run; rows are inserted at the start of processing and purged or consumed when the run completes. The ETRM metadata records it as "Not implemented in this database," confirming it is a runtime workspace rather than a persistent configuration or transaction table.

From a Data Vault modeling perspective, the ETRM metadata classifies this object heuristically as a link. This classification is consistent with its three foreign keys, each of which references an independent entity — an allocation formula, a code combination, and a concurrent request. The table therefore behaves as an associative structure tying those entities together for the duration of a single allocation run, rather than as a hub of its own business key or a satellite of descriptive attributes.

Key Information Stored

The documented metadata exposes three foreign key columns, which are the substantive content of the table:

• ALLOCATION_FORMULA_ID — Foreign key to GL_ALLOC_FORMULAS. Identifies the allocation formula (MassAllocation or MassBudget definition) whose target set is being expanded. This is the driver that determines which source pool, basis, and offset rules govern the row.
• CODE_COMBINATION_ID — Foreign key to GL_CODE_COMBINATIONS. Identifies the resolved target accounting flexfield combination that the allocation will post to. This is the principal business-key candidate, since a target combination is the meaningful business identifier of a target line.
• REQUEST_ID — Foreign key to FND_CONCURRENT_REQUESTS. Identifies the concurrent program run that generated the row, providing the execution context and allowing rows from different runs to coexist and be isolated.

No surrogate primary key column is documented in the ETRM excerpt, and no unique index columns are listed. In practice the operative uniqueness constraint for this table is the combination of the allocation formula, the target combination, and the owning concurrent request — that triplet defines one target line within one execution. Because the table is a temporary workspace, Oracle does not rely on it as a durable keyed entity; consumers should treat (ALLOCATION_FORMULA_ID, CODE_COMBINATION_ID, REQUEST_ID) as the logical identifier when querying.

Common Use Cases and Queries

Diagnostic and support scenarios dominate the use of this table. Typical questions include: which target accounts did a given allocation run attempt to populate, and did the run pick up the expected number of targets? A representative query joins back to the concurrent request to scope to a single run:

• Enumerate targets for a run: SELECT t.allocation_formula_id, t.code_combination_id, t.request_id FROM gl_alloc_targets t WHERE t.request_id = :request_id;
• Resolve target accounts to flexfield segments by joining CODE_COMBINATION_ID to GL_CODE_COMBINATIONS and GL_CODE_COMBINATIONS_KFV (or the GL_CODE_COMBINATIONS_V view) for the concatenated account string.
• Confirm the formula tied to each target by joining ALLOCATION_FORMULA_ID to GL_ALLOC_FORMULAS, which reveals the formula name, the allocation method, and the associated source pool.
• Troubleshoot a run that produced fewer lines than expected by comparing the count of rows per ALLOCATION_FORMULA_ID against the configured target ranges on the formula definition.
• Audit which concurrent requests generated allocation targets during a period, by aggregating REQUEST_ID against FND_CONCURRENT_REQUESTS completion dates.

Because rows are transient, queries should be executed while a run is in progress or immediately afterward, and should always be filtered by REQUEST_ID to avoid mixing results from separate executions.

Related Objects

The table is closely bound to the following objects, all of which are grounded in the documented foreign key relationships:

• GL_ALLOC_FORMULAS — joined on GL_ALLOC_TARGETS.ALLOCATION_FORMULA_ID = GL_ALLOC_FORMULAS.ALLOCATION_FORMULA_ID; stores the MassAllocation and MassBudget definitions that generate targets.
• GL_CODE_COMBINATIONS — joined on GL_ALLOC_TARGETS.CODE_COMBINATION_ID = GL_CODE_COMBINATIONS.CODE_COMBINATION_ID; supplies the valid, enabled target account combinations.
• FND_CONCURRENT_REQUESTS — joined on GL_ALLOC_TARGETS.REQUEST_ID = FND_CONCURRENT_REQUESTS.REQUEST_ID; provides the execution context of the allocation or budget run.
• GL_ALLOC_FORMULA_LINES and the allocation target-range setup, which define the source pool, basis, offset, and target account ranges consumed when populating this table.
• GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES — the journal tables into which the resolved allocation output is ultimately posted once the target set is finalized.

Together these objects form the MassAllocation processing chain: formula definitions feed the allocation engine, which stages resolved target combinations in GL_ALLOC_TARGETS under a specific concurrent request, and then posts the resulting journal entries to the GL journal tables.