Search Results fa_lookup_types_tl_u1

Overview

FA.FA_LOOKUP_TYPES_TL is the translation ("_TL") table belonging to the Oracle Assets (FA) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the language-dependent descriptive attributes — meaning and description — for the lookup types defined in the Oracle Assets module. The corresponding base table, FA_LOOKUP_TYPES_B, holds the language-independent columns that conform to multilingual (MLS) standards, while this table supplies translated text for each installed language so that seeded QuickPick lookup categories can be presented in the user's session language. The FND design data reference is OFA.FA_LOOKUP_TYPES_TL, confirming that the object is delivered as Oracle seeded (FND) data and is installed into the APPS_TS_SEED tablespace.

From a dimensional modeling perspective, the metadata's heuristic Data Vault classification places this object as a standalone structure rather than a classic hub, link, or satellite. Because it holds descriptive, language-specific attributes keyed to the lookup type, it behaves most naturally as a satellite-style descriptive store around the lookup-type business key (LOOKUP_TYPE), with LANGUAGE further qualifying each row.

Key Information Stored

The table's logical row is a single lookup type in a single language. The most significant columns are:

• LOOKUP_TYPE — VARCHAR2(30); the unique identification name of a list of related QuickPick values, and the leading business-key column.
• LANGUAGE — the language of the row's translated columns; the second business-key column.
• SOURCE_LANG — the original (source) language from which the row's translated values derive.
• MEANING — VARCHAR2(80); the meaning of the lookup type.
• DESCRIPTION — VARCHAR2(80); the descriptive text for the lookup type.
• ZD_EDITION_NAME — VARCHAR2(30); the edition name used by the Edition-Based Redefinition (EBR/Online Patching) framework in 12.2.x, and part of the unique index.
• Standard Who columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE, and LAST_UPDATE_LOGIN capture audit and user context.

The documented unique index FA_LOOKUP_TYPES_TL_U1 covers (LOOKUP_TYPE, LANGUAGE, ZD_EDITION_NAME), making it the primary business-key candidate. The table's declared primary key is FA_LOOKUP_TYPES_TL_PK on (LOOKUP_TYPE, LANGUAGE).

Common Use Cases and Queries

This table is queried primarily by Forms and concurrent programs that render lookup values and their descriptions in the user's language, and by reporting that extracts localized lookup text. A representative query joins the translated text with the base lookup definition:

• SELECT b.lookup_type, t.meaning, t.description FROM fa.fa_lookup_types_b b, fa.fa_lookup_types_tl t WHERE b.lookup_type = t.lookup_type AND t.language = USERENV('LANG');
• Confirming the installed translations for a lookup: SELECT language, source_lang, meaning FROM fa.fa_lookup_types_tl WHERE lookup_type = :p_lookup_type;
• Reporting on seed data delivery in a specific edition: SELECT lookup_type, language, zd_edition_name FROM fa.fa_lookup_types_tl;

Queries filtered by LANGUAGE are essential in multilingual deployments to avoid returning duplicate rows for the same lookup type across languages.

Related Objects

The primary relationship is the join to its base table via the shared business key:

• FA.FA_LOOKUP_TYPES_B — the base table; joined on LOOKUP_TYPE (and LANGUAGE context).
• FA.FA_LOOKUP_TYPES_TL# — the referenced helper object/edition access structure, per the dependency listing.
• FA.FA_LOOKUP_VALUES_TL / FA.FA_LOOKUP_VALUES_B — the lookup value definitions that reference the lookup type described here.
• FA_LOOKUP_TYPES_TL_PK (PK on LOOKUP_TYPE, LANGUAGE) and FA_LOOKUP_TYPES_TL_U1 (unique on LOOKUP_TYPE, LANGUAGE, ZD_EDITION_NAME) — the key indexes that govern access.
• FND_LOOKUPS / FND_LOOKUP_TYPES and the FND seed data loaders — functionally associated lookup metadata objects commonly referenced alongside Oracle Assets lookup types.

Because the table is declared standalone (it does not reference other database objects), it acts as a dependent detail store anchored by its lookup-type key rather than as an independent entity.