Results for “gl_auto_alloc_batches”

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

Overview

GL_AUTO_ALLOC_BATCHES is a General Ledger (GL) schema table in Oracle E-Business Suite 12.1.1 and 12.2.2 that defines the assignment of allocation-capable batch definitions to an allocation set. Its documented purpose is to record the assignments of MassAllocation, Mass Budgets, Mass Encumbrances, Recurring Journals, or Projects batches to an allocation set. In operational terms, it is the intersection or mapping table that binds a specific allocation set (defined in GL_AUTO_ALLOC_SETS) to one or more batch or rule definitions, thereby determining which batches are executed when the allocation set is run.

The ETRM relationship metadata classifies this object heuristically as a link table within a Data Vault modeling convention. This classification is appropriate because the table's documented unique key (GL_AUTO_ALLOC_BATCHES_U1) is composed entirely of foreign key columns — ALLOCATION_SET_ID, BATCH_ID, and BATCH_TYPE_CODE — with no independently generated surrogate identifier and minimal descriptive payload. The table therefore functions as a resolved many-to-many association between allocation sets and allocatable batch definitions.

Key Information Stored

The documented physical schema comprises 27 columns. The most significant are the key and control columns:

• ALLOCATION_SET_ID — Identifies the parent allocation set defined in GL_AUTO_ALLOC_SETS. This is a mandatory component of the primary key and unique index.
• BATCH_ID — Identifies the assigned batch. This column participates in documented foreign key relationships to both GL_ALLOC_BATCHES and PA_ALLOC_RULES_ALL, reflecting the dual nature of GL allocations versus Projects allocation rules.
• BATCH_TYPE_CODE — Differentiates the type of batch being assigned (for example, MassAllocation, Mass Budget, Mass Encumbrance, Recurring Journal, or Projects). This value completes the composite unique key.
• STEP_NUMBER — Defines the execution sequence of the batch within the allocation set, which governs the order in which allocations are processed when the set is run.
• ALLOCATION_METHOD_CODE — Specifies the allocation method associated with the assignment, controlling how amounts are distributed.
• OWNER — Records the owner of the allocated batch assignment.
• CONTEXT — The descriptive flexfield context column for the table's DFF structure.
• ATTRIBUTE1 through ATTRIBUTE15 — The standard descriptive flexfield segment columns, available for client-specific extensions.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — The standard Oracle EBS audit columns that track who created and last modified each row.

The surrogate primary key is documented as GL_AUTO_ALLOC_BATCHES_PK1, whose columns are ALLOCATION_SET_ID, BATCH_ID, and BATCH_TYPE_CODE. The unique index GL_AUTO_ALLOC_BATCHES_U1 carries the identical column set, meaning the documented business key and physical unique constraint coincide; no separate generated sequence key is documented.

Common Use Cases and Queries

The primary reporting scenario is determining which batches belong to a given allocation set and in what sequence they execute. A representative query joins the parent set to this mapping table and onward to the batch definition:

• Retrieve all assignments for an allocation set, ordered by STEP_NUMBER, to validate execution order before running a recurring allocation.
• Audit which Projects allocation rules (via BATCH_ID → PA_ALLOC_RULES_ALL) are attached to a GL allocation set, useful when reconciling GL versus Projects-derived allocations.
• List all allocation sets that reference a particular batch, to assess the impact of deactivating or modifying that batch.
• Extract batch assignments by BATCH_TYPE_CODE to produce a register of MassAllocation versus Recurring Journal versus Mass Budget usage across the ledger.
• Report on rows filtered by OWNER or ALLOCATION_METHOD_CODE to review method and ownership distribution.

A typical join pattern is: select from GL_AUTO_ALLOC_SETS A, GL_AUTO_ALLOC_BATCHES B, and GL_ALLOC_BATCHES C where A.ALLOCATION_SET_ID = B.ALLOCATION_SET_ID and B.BATCH_ID = C.BATCH_ID, constrained on B.BATCH_TYPE_CODE as required.

Related Objects

The following documented relationships are the most significant dependencies on GL_AUTO_ALLOC_BATCHES:

• GL_AUTO_ALLOC_SETS — Parent allocation set definition; joined on GL_AUTO_ALLOC_BATCHES.ALLOCATION_SET_ID = GL_AUTO_ALLOC_SETS.ALLOCATION_SET_ID. This is the principal parent entity.
• GL_ALLOC_BATCHES — The GL batch definition referenced through BATCH_ID.
• PA_ALLOC_RULES_ALL — The Projects allocation rules referenced through the same BATCH_ID, supporting Projects-originated allocation assignments.

Because the composite key columns are foreign keys to both GL_ALLOC_BATCHES and PA_ALLOC_RULES_ALL, care must be taken when joining on BATCH_ID alone to avoid unintended row multiplication; constrain the join by BATCH_TYPE_CODE to isolate GL batch definitions from Projects rules. No additional child tables or PL/SQL APIs are documented in the ETRM metadata for this object, so integration is generally performed through the standard GL allocations forms and concurrent programs that maintain allocation sets and their assignments.