Search Results xla_gl_transfer_batches_all




Overview

XLA_GL_TRANSFER_BATCHES_ALL is the transferred batches history table owned by the XLA (Subledger Accounting) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It maintains the log of Subledger Accounting to General Ledger transfer submissions, recording each request that moves subledger journal entries from the accounting layer into the GL interface. Each row corresponds to one submitted transfer run, capturing the run identifier, the concurrent request that produced it, the ledger and batch context, the transfer date range, and the ultimate status of the transfer. The table is therefore a control and audit object rather than a transactional journal store.

The mined foreign-key structure classifies this object heuristically as a standalone table, with no other table in the vault depending on it as a parent hub or link. It does, however, hold outbound references to FV_LEGAL_ENTITIES, CST_COST_TYPES, and CST_COST_GROUPS, which behave as dimension lookups for legal entity and cost context rather than as true Data Vault parents. In practice, the object is best modeled as a satellite of the transfer run, tracking the state and audit attributes of each transfer event over time. The companion table XLA_GL_TRANSFER_BATCHES_ALL is complemented by the non-multi-org view XLA_GL_TRANSFER_BATCHES commonly exposed to reporting.

Key Information Stored

The surrogate primary key and sole documented unique business key is GL_TRANSFER_RUN_ID, indexed by XLA_GL_TRANSFER_BATCHES_U1. All other columns are descriptive attributes of the run.

Common Use Cases and Queries

Typical uses include monitoring transfer status, reconciling subledger to GL postings, and diagnosing failed or incomplete transfers. A common pattern lists the most recent transfer runs for a ledger:

  • Status tracking: SELECT gl_transfer_run_id, request_id, transfer_status, gl_transfer_date FROM xla_gl_transfer_batches_all WHERE set_of_books_id = :ledger_id ORDER BY gl_transfer_date DESC;
  • Reconciliation: join GL_TRANSFER_RUN_ID to the GL interface and journal import request identifiers to confirm that each transferred batch reached GL.
  • Audit: filter by USER_ID, TRANSFER_FROM_DATE, and TRANSFER_TO_DATE to reproduce the population of entries submitted during a period close.
  • Cost context reporting: join to CST_COST_TYPES and CST_COST_GROUPS on COST_TYPE_ID and COST_GROUP_ID for costing-enabled subledgers.

Related Objects

The following objects are the most significant join targets and dependents:

  • FV_LEGAL_ENTITIES — joined on LEGAL_ENTITY_ID for legal entity attribution.
  • CST_COST_TYPES — joined on COST_TYPE_ID for costing context.
  • CST_COST_GROUPS — joined on COST_GROUP_ID for cost group classification.
  • XLA_GL_TRANSFER_BATCHES — non-multi-org view over the same data, commonly used for reporting.
  • GL_JE_BATCHES / GL_JE_HEADERS — GL-side batches and journals that receive the transferred entries via BATCH_NAME and run identifiers.
  • GL_INTERFACE — staging table populated by the transfer, keyed by INTERFACE_RUN_ID and GLLEZL_REQUEST_ID.

These relationships make XLA_GL_TRANSFER_BATCHES_ALL the central audit anchor for Subledger Accounting to General Ledger transfer activity.