Search Results post_import

Overview

The APPS.XLA_AAD_IMPORT_PVT package is a private PL/SQL API within the Oracle E-Business Suite Subledger Accounting (SLA) module. Its function is to import Analytical Attribute Definitions (AADs) and their associated components from an external data file into the staging area of an Accounting Methods Builder (AMB) context. AADs form part of the SLA rules infrastructure, allowing descriptive attributes and accounting conditions to be defined against transaction data so that subledger journals can be generated with the correct accounting treatment.

The package is declared with AUTHID CURRENT_USER, meaning its SQL statements execute under the privileges of the invoking user rather than the package owner, which is consistent with its classification as a private (PVT) API intended solely for internal consumption by other SLA utilities, not for direct customer invocation. The import workflow is orchestrated through three entry points that separate validation, execution, and post-processing stages, mirroring a common EBS pattern in which setup metadata is migrated between environments or loaded from flat files.

Key Procedures and Functions

The package exposes three documented program units:

• PRE_IMPORT (function) — Performs preparatory validation and setup before the import proper. It accepts the application identifier, the target AMB context code, and a staging context code. It returns a VARCHAR2 result used to signal success or a specific validation outcome to the caller. The separation of this step allows the import routine to be invoked only when the staging environment is confirmed to be in a suitable state.
• IMPORT (procedure) — The core routine that reads AADs and their components from the data file located at the supplied source pathname and loads them into the staging area of the specified AMB context. It is parameterised by API version, an IN OUT return status, the application identifier, the source file pathname, the AMB context code, and an IN OUT import status, allowing the caller to track both the technical return status and the logical import outcome.
• POST_IMPORT (procedure) — Runs the finalisation logic after the raw load has completed, taking the application identifier and the AMB and staging context codes. This is the routine most relevant to the "post_import" search and is where the staged data is reconciled, logged, and made available for downstream SLA processing; it is typically the point at which import results are committed and administrative logging is finalised.

Tables Accessed

The package reads and writes through APPS synonyms against the SLA repository:

• XLA_ANALYTICAL_HDRS_B / _TL and XLA_ANALYTICAL_DTLS_B / _TL — the analytical attribute definition headers and detail lines that constitute the AAD payload being imported, along with their translated descriptions.
• XLA_ANALYTICAL_SOURCES — the source assignments that link AADs to the transaction data against which they are evaluated.
• XLA_APPLI_AMB_CONTEXTS — the target and staging AMB context definitions that scope the import.
• XLA_CONDITIONS, XLA_PRODUCT_RULES_B, XLA_SEG_RULES_B / _TL, XLA_MAPPING_SETS_B / _TL, XLA_MAPPING_SET_VALUES — the SLA rule components associated with the imported definitions.
• XLA_AAD_LOADER_LOGS and XLA_AAD_LOADER_LOGS_S — the import logging tables that record the outcome of each load and support the POST_IMPORT reconciliation step.

Usage Notes

Because this is a private API, it is not surfaced directly through an EBS form. It is invoked internally by the SLA administrative utilities that support AAD migration and setup loading, and it is referenced by one other package (documented under the ETRM metadata). Typical callers are concurrent-program wrappers or other SLA private APIs that orchestrate a full import cycle: PRE_IMPORT to validate, IMPORT to load the file, then POST_IMPORT to finalise. Customisation or direct invocation is not supported; customers requiring AAD migration should use the standard SLA setup migration and loader flows that ultimately call this package. In both 12.1.1 and 12.2.2 the package header and signature are unchanged, and the $Header indicates a stable release line, so behaviour should be consistent across the two releases.