Results for “source_table”

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

Overview

The XLA_GL_TRANSFER_BATCHES view is a Subledger Accounting (XLA) reporting object owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents a consolidated, query-friendly representation of the batch definitions and run parameters that Subledger Accounting uses when transferring subledger journal entries to the General Ledger. Each row corresponds to a General Ledger transfer run, identified by the GL_TRANSFER_RUN_ID, and captures the selection criteria, date ranges, accounting category scope, transfer mode, and processing status associated with that run. Because the view is a thin projection defined over the underlying _ALL table, it serves as the primary reference point for administrators, support analysts, and reporting developers who need to audit or troubleshoot the Create Accounting and Transfer to GL process without querying the multi-org base table directly. In the ETRM 12.2.2 metadata, the view is documented with status VALID and is grouped under the XLA - Subledger Accounting product family.

Underlying Base Objects

The view is defined as a simple SELECT over XLA_GL_TRANSFER_BATCHES_ALL, which is a synonym for the base table of the same name. The column list is passed through directly, without joins, aggregation, or transformation. This projection model means the view returns the same rows as the base table for the current query context; org-level filtering is inherited from the underlying _ALL object through the ORG_ID column. The documented referenced base object is XLA_GL_TRANSFER_BATCHES_ALL (SYNONYM). The list of exposed columns is: GL_TRANSFER_RUN_ID, APPLICATION_ID, USER_ID, SELECTION_TYPE, SET_OF_BOOKS_ID, BATCH_NAME, SOURCE_ID, SOURCE_TABLE, TRANSFER_FROM_DATE, TRANSFER_TO_DATE, AE_CATEGORY, GL_TRANSFER_MODE, SUBMIT_JOURNAL_IMPORT, SUMMARY_JOURNAL_ENTRY, PROCESS_DAYS, GL_TRANSFER_DATE, GLLEZL_REQUEST_ID, INTERFACE_RUN_ID, GROUP_ID, ORG_ID, LEGAL_ENTITY_ID, COST_TYPE_ID, COST_GROUP_ID, TRANSFER_STATUS, and PACKET_ID.

Key Columns

• GL_TRANSFER_RUN_ID — Primary identifier of the transfer run; the natural key for joining related XLA and GL objects.
• AE_CATEGORY — The accounting category (event category) selected for the transfer, filtering which subledger journal entries are eligible. This is the column most frequently searched by users investigating category-specific transfers.
• SET_OF_BOOKS_ID — The ledger or set of books for which the transfer executes.
• SELECTION_TYPE, TRANSFER_FROM_DATE, TRANSFER_TO_DATE — Define the run's selection scope and accounting date window.
• GL_TRANSFER_MODE, SUBMIT_JOURNAL_IMPORT, SUMMARY_JOURNAL_ENTRY — Control how the transfer is performed and whether journals are summarized or the import program is submitted automatically.
• TRANSFER_STATUS — Current state of the batch (for example, pending, processing, completed, or errored).
• GLLEZL_REQUEST_ID, INTERFACE_RUN_ID, GROUP_ID, PACKET_ID — Correlation identifiers linking the batch to the Journal Import run, interface run, and packetized processing units.
• ORG_ID, LEGAL_ENTITY_ID, COST_TYPE_ID, COST_GROUP_ID — Organizational and costing context, particularly relevant for Cost Management and multi-org environments.

Common Use Cases and Queries

Typical scenarios include auditing failed or pending transfers, tracing a batch to its Journal Import request, and reviewing which accounting categories were included in a given run. A representative query filtered by accounting category is:

• SELECT GL_TRANSFER_RUN_ID, BATCH_NAME, SET_OF_BOOKS_ID, AE_CATEGORY, TRANSFER_STATUS FROM XLA_GL_TRANSFER_BATCHES WHERE AE_CATEGORY = :p_category AND TRANSFER_STATUS = 'P';
• SELECT GL_TRANSFER_RUN_ID, TRANSFER_FROM_DATE, TRANSFER_TO_DATE, GLLEZL_REQUEST_ID, INTERFACE_RUN_ID FROM XLA_GL_TRANSFER_BATCHES WHERE GL_TRANSFER_DATE >= TRUNC(SYSDATE) - 7;
• SELECT ORG_ID, LEGAL_ENTITY_ID, COUNT(*) FROM XLA_GL_TRANSFER_BATCHES GROUP BY ORG_ID, LEGAL_ENTITY_ID;

Because the view exposes the same column set as the base table, it is suitable for ad hoc reporting, custom concurrent programs, and troubleshooting scripts without requiring direct access to the underlying _ALL object.