Search Results xla_aads_h

Overview

XLA_AADS_H is a Subledger Accounting (XLA) history table in the Oracle E-Business Suite database, owned by the XLA schema. It stores historical versions of application accounting definitions (AADs) — the rule sets that determine how subledger transactions are transformed into accounting entries and transferred to the General Ledger. Per the documented description, the history is updated when application accounting definitions are exported, meaning each export operation preserves a snapshot of the definition state at that point in time. This makes XLA_AADS_H a versioning and audit trail object rather than a transactional one, and it complements the operational XLA_AAD tables by retaining prior versions that would otherwise be overwritten.

Based on its primary key structure — APPLICATION_ID, PRODUCT_RULE_TYPE_CODE, PRODUCT_RULE_CODE, and VERSION_NUM — the heuristic Data Vault classification is satellite. The composite of application, rule type, and rule code behaves as a parent business key, while VERSION_NUM and the descriptive columns capture changing state over time. This modeling view is particularly apt because the table records the evolution of a definition across releases and exports, with each row representing one versioned state of the same underlying business entity.

The object is VALID in both 12.1.1 and 12.2.2, and the documented physical schema lists 18 columns. It is a standalone object from a foreign key perspective; no outbound FK relationships are documented within the ETRM metadata.

Key Information Stored

The most significant columns fall into three groups: identity, versioning, and audit.

• APPLICATION_ID — Identifies the owning application (for example, Payables, Receivables, or Assets) whose accounting definition is being versioned.
• PRODUCT_RULE_TYPE_CODE — Classifies the type of application accounting definition, distinguishing among definition categories within the product.
• PRODUCT_RULE_CODE — The specific application accounting definition being versioned.
• VERSION_NUM — The version sequence number. Together with the three columns above, this forms the primary key XLA_AADS_H_PK and the unique index XLA_AADS_H_U1, making these four columns the business-key candidate for the history record.
• BASE_VERSION_NUM — The version from which the current version was derived, establishing lineage between definition versions.
• USER_VERSION — A user-assigned version label, typically set when the definition is exported or published.
• VERSION_COMMENT — Free-text description of the changes or rationale for the version.
• LEAPFROG_FLAG — Indicates whether the version was produced through a leapfrog (non-sequential) versioning operation.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the Oracle Framework for concurrent update control.
• CREATION_DATE, CREATED_BY — Standard audit columns recording when and by whom the history row was inserted.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns capturing the most recent modification.
• PROGRAM_UPDATE_DATE, PROGRAM_APPLICATION_ID, PROGRAM_ID, REQUEST_ID — Concurrent program and request context, enabling traceability to the export or concurrent process that created the row.

Common Use Cases and Queries

Typical scenarios include auditing which version of an application accounting definition was active at a point in time, reconciling definition changes against concurrent request history, and reporting on version drift across environments or releases. Because the history is written on export, DBAs and functional consultants commonly use this table to determine when a definition was last exported and by which concurrent program.

A representative query listing the version history for a given definition:

• SELECT application_id, product_rule_type_code, product_rule_code, version_num, base_version_num, user_version, creation_date, created_by FROM xla.xla_aads_h WHERE application_id = :app_id AND product_rule_type_code = :type_code AND product_rule_code = :rule_code ORDER BY version_num DESC;
• Correlating versions to the export job: join REQUEST_ID to FND_CONCURRENT_REQUESTS to obtain the request name, phase, and completion time.
• Identifying divergent definitions across instances by comparing the latest version_num returned from each environment for the same business key.

Related Objects

The documented FK metadata classifies XLA_AADS_H as standalone, so joins are primarily driven by the composite business key rather than enforced foreign keys. Significant related objects include:

• XLA_AADS — The current (non-historical) application accounting definitions table, sharing APPLICATION_ID, PRODUCT_RULE_TYPE_CODE, and PRODUCT_RULE_CODE; the history table preserves the versions that this table holds only in latest form.
• FND_APPLICATION — Resolves APPLICATION_ID to the owning product short name.
• FND_CONCURRENT_REQUESTS — Joined on REQUEST_ID to identify the export concurrent request that produced each history row.
• XLA_AAD_PRODUCT_RULES / XLA_AAD_LINE_DEFS — The detail-level definition tables whose effective content is versioned through the parent AAD.
• XLA_LOOKUPS — Resolves PRODUCT_RULE_TYPE_CODE and related coded values to their display meanings.
• FND_USER — Resolves CREATED_BY and LAST_UPDATED_BY to user names for audit reporting.

No public PL/SQL APIs are documented against XLA_AADS_H in the ETRM metadata; the table is populated internally by the Subledger Accounting export process.