Results for “gl_alloc_history”

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

Overview

GL_ALLOC_HISTORY is a General Ledger table that stores the execution history of MassAllocation and MassBudget runs. In Oracle EBS 12.1.1 and 12.2.2, MassAllocation and MassBudget are concurrent programs that generate journal entries by distributing balances across accounts according to user-defined allocation formulas. Each successful or failed execution produces a record in this table, capturing the batch, the concurrent request, the accounting periods involved, and the run status. It is owned by the GL schema and holds 17 documented columns in the 12.2.2 physical schema.

Under the heuristic Data Vault classification mined from its foreign-key structure, GL_ALLOC_HISTORY is best modeled as a link. It records associations among a MassAllocation batch, a concurrent request, a set of books, and an access set, rather than serving as a standalone hub or as a purely descriptive satellite. The link interpretation fits its role as a cross-reference between allocation batches and the concurrent requests that produced them.

Key Information Stored

The table is identified by the primary key GL_ALLOC_HISTORY_PK, a composite surrogate key on (ALLOCATION_BATCH_ID, REQUEST_ID). Two unique indexes further define business-key candidates: GL_ALLOC_HISTORY_UK1 on (NAME, REQUEST_ID) and GL_ALLOC_HISTORY_UK2 on (REQUEST_ID). These constraints confirm that a single concurrent request maps to one allocation history row, while a name and request combination must also remain unique.

The most significant columns include:

• ALLOCATION_BATCH_ID — identifies the MassAllocation batch; part of the primary key and a foreign key to GL_ALLOC_BATCHES.
• REQUEST_ID — the concurrent request that executed the allocation; part of the primary key and a foreign key to FND_CONCURRENT_REQUESTS.
• NAME — the batch or run name; part of the UK1 unique key.
• SET_OF_BOOKS_ID_11I — the ledger/set of books identifier for the run.
• RUN_STATUS — the outcome of the allocation execution.
• FROM_PERIOD_NAME / TO_PERIOD_NAME — the accounting period range covered by the run.
• TO_PERIOD_NUM / TO_PERIOD_YEAR — numeric period and year of the target period.
• JOURNAL_EFFECTIVE_DATE — the effective date applied to generated journals.
• CALCULATION_EFFECTIVE_DATE — the date used for calculation purposes.
• ACCESS_SET_ID — foreign key to GL_ACCESS_SETS, supporting data access security.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, CREATED_BY, CREATION_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.

Common Use Cases and Queries

Typical usage centers on auditing allocation activity, diagnosing failed runs, and reconciling concurrent request output against batches. A common query joins the history to concurrent requests to retrieve run status and timing:

• Listing all allocation runs for a ledger within a period range, filtering on SET_OF_BOOKS_ID_11I and FROM_PERIOD_NAME/TO_PERIOD_NAME.
• Identifying failed or incomplete runs by selecting rows where RUN_STATUS indicates an abnormal outcome, joined to FND_CONCURRENT_REQUESTS for error detail.
• Auditing which concurrent request produced a given allocation batch by joining ALLOCATION_BATCH_ID to GL_ALLOC_BATCHES.
• Reporting allocation history by name using the UK1 business key (NAME, REQUEST_ID).

A representative pattern selects ALLOCATION_BATCH_ID, NAME, RUN_STATUS, and the period columns from GL_ALLOC_HISTORY, joining to FND_CONCURRENT_REQUESTS on REQUEST_ID and to GL_ALLOC_BATCHES on ALLOCATION_BATCH_ID.

Related Objects

The following objects are directly related through documented foreign keys and key structures:

• GL_ALLOC_BATCHES — referenced via GL_ALLOC_HISTORY.ALLOCATION_BATCH_ID; holds batch definitions for MassAllocation.
• FND_CONCURRENT_REQUESTS — referenced via GL_ALLOC_HISTORY.REQUEST_ID; supplies request status and execution metadata.
• GL_SETS_OF_BOOKS — referenced via GL_ALLOC_HISTORY.SET_OF_BOOKS_ID; identifies the ledger.
• GL_ACCESS_SETS — referenced via GL_ALLOC_HISTORY.ACCESS_SET_ID; governs data access security.

These relationships make GL_ALLOC_HISTORY the central audit link between allocation batches, ledger configuration, security access sets, and the concurrent manager framework.