Search Results xla_aad_loader_defns_t




Overview

XLA_AAD_LOADER_DEFNS_T is a Subledger Accounting (XLA) interface table in Oracle E-Business Suite, owned by the XLA schema. As documented in ETRM, it "is the interface table that facilitates the data transfer from data files and the database." In practical terms, it stores the loader definitions that govern how Accounting Attribute Definition (AAD) metadata—the rules that describe which source values map to which accounting attributes for each subledger transaction—is staged and populated into the database during setup migration, patching, and bulk definition load processes. Because Subledger Accounting drives journal creation from subledger transactions, the integrity of these loader definitions directly affects how accounting attribute assignments are imported and validated before being consumed by the Accounting Methods Builder (AMB) engine.

From a modeling perspective, the mined Data Vault classification is standalone. No foreign-key dependencies were detected, so this table is best treated as an independent load/staging entity rather than as a hub, link, or satellite with resolved parent relationships. The object is documented with 161 columns in the 12.2.2 physical schema and is marked VALID in the XLA schema, appearing in both 12.1.1 and 12.2.2 environments.

Key Information Stored

The surrogate primary key is AAD_LOADER_DEFINITION_ID, enforced through the unique index XLA_AAD_LOADER_DEFNS_T_U1, which also serves as the primary business-key candidate. XLA_AAD_LOADER_DEFNS_T_PK is the named primary-key constraint on the same column. The most significant descriptive and functional columns include:

Audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_APPLICATION_ID, PROGRAM_ID, REQUEST_ID) record which concurrent program and user loaded each row, enabling traceability of loader runs.

Common Use Cases and Queries

DBAs and technical consultants query this table when diagnosing accounting attribute load failures, verifying that a patch or migration populated loader definitions correctly, and auditing which rows remain active and validated. A typical query lists active, successfully validated definitions for a given application:

  • SELECT aad_loader_definition_id, name, accounting_attribute_code, accounting_class_code, validation_status_code FROM xla.xla_aad_loader_defns_t WHERE active_flag = 'Y' AND validation_status_code = 'S' ORDER BY name;

To trace a loader run, filter on concurrent program identifiers and request ID:

  • SELECT request_id, program_id, COUNT(*) FROM xla.xla_aad_loader_defns_t GROUP BY request_id, program_id ORDER BY request_id DESC;

Reporting use cases include producing a catalog of effective-dated loader definitions, identifying rows whose effective range has expired, and comparing staging definitions against the production AMB configuration to detect drift after upgrades. Because the table is standalone, such reports rely exclusively on AAD_LOADER_DEFINITION_ID and the status, date, and code columns rather than on foreign-key joins.

Related Objects

The mined relationship data classifies XLA_AAD_LOADER_DEFNS_T as standalone, with no detected FK dependencies in the ETRM schema. Nonetheless, it functions within the broader Subledger Accounting setup framework and is most significantly related to the following objects:

Because no foreign keys are enforced, joins to the above objects are conventional (application short name, request ID, and accounting attribute code) rather than referential, which should be considered when building integrity checks or reconciliation reports.