Search Results ak_customizations_tl_n2

Overview

AK.AK_CUSTOMIZATIONS_TL is the translation (TL) table corresponding to AK.AK_CUSTOMIZATIONS within the Oracle E-Business Suite Application Object Library (AK) schema. It stores language-specific descriptive attributes — name and description — for customization definitions that are registered against Oracle EBS regions and applications. Because it is an owner-seeded, ETRM-documented object with a status of VALID, it is present in both Oracle EBS 12.1.1 and 12.2.2 environments, where the underlying structure and indexes remain consistent. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10.

Under the heuristic Data Vault classification derived from FK structure, AK_CUSTOMIZATIONS_TL is modeled as a standalone object. In Data Vault terms, this suggests treating it as a satellite-like construct that carries descriptive, language-dependent payload attached to a business key, rather than as a hub or link with independent referential relationships. It does not reference any database object directly.

Key Information Stored

The table's primary key, AK_CUSTOMIZATIONS_TL_PK, is a composite made up of CUSTOMIZATION_APPLICATION_ID, REGION_CODE, CUSTOMIZATION_CODE, LANGUAGE, and REGION_APPLICATION_ID. This composite key establishes the row's identity while the unique index AK_CUSTOMIZATIONS_TL_U1 adds ZD_EDITION_NAME to the same column set, making it the business-key candidate that supports edition-based redefinition (EBR) in 12.2.2.

• CUSTOMIZATION_APPLICATION_ID — Application ID where the customization is used.
• CUSTOMIZATION_CODE — Short code identifying a given customization.
• REGION_APPLICATION_ID — Application ID where the region is used.
• REGION_CODE — Region code for the given region.
• NAME — Translated customization name (up to 80 characters).
• DESCRIPTION — Translated customization description (up to 2000 characters).
• LANGUAGE — Language of the translated row.
• SOURCE_LANG — Source language from which the row was derived.
• ZD_EDITION_NAME — Edition name supporting EBR in 12.2.x.
• WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard audit lineage.

Non-key business attributes NAME and DESCRIPTION are the translatable payload; all other columns are identifiers, audit fields, or EBR scaffolding. The secondary nonunique index AK_CUSTOMIZATIONS_TL_N2 supports alternate access paths by REGION_CODE, REGION_APPLICATION_ID, CUSTOMIZATION_CODE, and CUSTOMIZATION_APPLICATION_ID.

Common Use Cases and Queries

Typical usage retrieves localized customization labels for a specific language, audits who created or updated translated text, or joins to base tables via the composite business key. A standard lookup pattern follows:

SELECT CUSTOMIZATION_APPLICATION_ID, REGION_CODE, CUSTOMIZATION_CODE, LANGUAGE, NAME, DESCRIPTION FROM AK.AK_CUSTOMIZATIONS_TL WHERE LANGUAGE = :p_lang AND CUSTOMIZATION_APPLICATION_ID = :p_app_id;

Reporting scenarios include extracting all translations for a customization into a multilingual catalog, comparing SOURCE_LANG against LANGUAGE to identify missing translations, and filtering by ZD_EDITION_NAME to isolate the active edition in 12.2.2. Administrators use these rows to verify that displayed customization names match the intended locale during implementations.

Related Objects

• AK.AK_CUSTOMIZATIONS — Base table whose non-translated rows are joined via CUSTOMIZATION_APPLICATION_ID, REGION_CODE, CUSTOMIZATION_CODE, REGION_APPLICATION_ID, and LANGUAGE.
• AK.AK_CUSTOMIZATIONS_TL# — The editioning view wrapper referenced by the table in 12.2.x EBR environments.
• AK.AK_CUSTOMIZATIONS_TL_U1 — Unique index enforcing the business-key candidate including ZD_EDITION_NAME.
• AK.AK_CUSTOMIZATIONS_TL_N2 — Nonunique index for alternate lookup paths.
• AK.AK_CUSTOMIZATIONS_TL_PK — Primary key constraint underpinning row identity.
• FND Application and Region Reference Tables — Supply CUSTOMIZATION_APPLICATION_ID and REGION_APPLICATION_ID values consumed by this table.

The dense overlap between the primary key, unique index, and secondary index reflects a compact relational design focused on multilingual access with minimal redundancy.