Search Results gl_auto_alloc_rev_batches




Overview
Explore in AI Chat

Overview

GL_AUTO_ALLOC_REV_BATCHES is a General Ledger (GL) schema table in Oracle E-Business Suite that stores the mapping between journal batches and headers produced by an AutoAllocation rollback and the reversal journal entries generated to offset them. AutoAllocation is the GL engine that distributes balances across accounts using allocation formulas; when a completed allocation run must be rolled back, the process creates reversing journal entries so that the original generated journals are neutralized in an auditable fashion. This table records those reversal artifacts and ties each reversal back to the concurrent request that performed the rollback, providing a durable audit trail.

From a modeling perspective, the heuristic Data Vault classification supplied with the metadata is link. The table behaves as an associative (many-to-many style) construct: it joins the original AutoAllocation batch and header to their reversal batch and header, and relates both to the driving concurrent request and its parent. It is not a descriptive hub of a business entity, nor a satellite carrying time-variant attributes of one entity; its principal purpose is relationship capture between journal artifacts and the request that produced them.

Key Information Stored

The documented physical schema contains 12 columns. The most significant are:

The surrogate PK is REVERSAL_JE_HEADER_ID; the unique index on the same column confirms it as the surviving business key.

Common Use Cases and Queries

Typical usage centers on reconciliation and diagnostics for AutoAllocation rollbacks. To trace which reversal batch and request handled a given original batch:

  • Join GL_AUTO_ALLOC_REV_BATCHES to GL_JE_BATCHES on REVERSAL_JE_BATCH_ID to retrieve reversal batch names and statuses.
  • Join to GL_JE_HEADERS on REVERSAL_JE_HEADER_ID or JE_HEADER_ID to compare original and reversal journals.
  • Join to FND_CONCURRENT_REQUESTS on REQUEST_ID (and PARENT_REQUEST_ID) to obtain program name, phase, and completion status.
  • Report orphan reversals (rollbacks whose original batch is no longer posted) by outer-joining GL_JE_BATCHES on JE_BATCH_ID and filtering nulls.
  • Audit query grouping by BATCH_TYPE_CODE and CREATION_DATE to quantify rollback volume by period.

Related Objects

  • GL_JE_BATCHES — joined via REVERSAL_JE_BATCH_ID (the reversal batch) and, semantically, via JE_BATCH_ID (the original batch).
  • GL_JE_HEADERS — joined via REVERSAL_JE_HEADER_ID; also via JE_HEADER_ID for the original header.
  • FND_CONCURRENT_REQUESTS — joined twice: on REQUEST_ID and on PARENT_REQUEST_ID.
  • GL_JE_LINES — accessed through the header to inspect reversal line detail.
  • GL_AUTO_ALLOC_BATCHES / AutoAllocation definition tables — provide the originating allocation context.
  • AutoAllocation and Journal Import concurrent programs — the processes that create and consume these rows.

Collectively these relationships make GL_AUTO_ALLOC_REV_BATCHES the audit bridge between AutoAllocation execution, rollback activity, and the GL journal repository.