Results for “customization_level”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_COMMON_LOOKUP_TYPES is a backward-compatibility view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes QuickCode types — the historical name for what are now known as lookup types — through a name that predates the current FND_LOOKUP_TYPES data model. The view exists purely so that legacy customizations, reports, and third-party integrations written against the older QuickCode naming convention continue to function after Oracle restructured the lookup architecture. It is an interface view, not a table, and therefore holds no data of its own; all content is derived at runtime from the lookup tables in the Application Object Library (FND) product.

In reporting and integration contexts, the view behaves as a convenience layer. A query against FND_COMMON_LOOKUP_TYPES returns only lookup types belonging to the Common Lookups application (VIEW_APPLICATION_ID = 3), filtered through the language of the current session and the security group of the executing user. This makes it suitable for ad-hoc queries and legacy code paths, but unsuitable as a general-purpose replacement for the full lookup model, since it deliberately restricts the result set.

Underlying Base Objects

The view text joins two documented base objects plus a PL/SQL package:

• FND_LOOKUP_TYPES (synonym to the FND_LOOKUP_TYPES base table) — supplies the application identifier, lookup type name, audit columns, customization level, and security group identifier.
• FND_LOOKUP_TYPES_TL (synonym to the translation table) — supplies the translated meaning, joined on LOOKUP_TYPE, SECURITY_GROUP_ID, and VIEW_APPLICATION_ID with the session language restriction T.LANGUAGE = USERENV('LANG').
• FND_GLOBAL (package) — invoked as FND_GLOBAL.LOOKUP_SECURITY_GROUP to resolve the security group applicable to each lookup type.

Because translations are sourced from the _TL table, the view returns meaning text in the language of the connected user's session rather than always in US English. The join is a strict equijoin on three key columns, so any lookup type lacking a matching translation row for the session language is excluded from the output.

Key Columns

• APPLICATION_ID — identifier of the owning application. For rows returned by this view the associated view context is the Common Lookups application.
• LOOKUP_TYPE — the internal name of the QuickCode/lookup type, used as the join key throughout the lookup model and referenced by lookup codes.
• LOOKUP_TYPE_MEANING — the user-facing, translated description of the lookup type, sourced from FND_LOOKUP_TYPES_TL. Note that the view definition aliases T.MEANING, which is projected under the LOOKUP_TYPE_MEANING name in the documented column list.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns reflecting who created and last modified the lookup type and from which login session.
• CUSTOMIZATION_LEVEL — indicates whether the lookup type is system-owned, extensible by administrators, or user-defined, which determines whether customers may add or modify associated lookup codes.

Common Use Cases and Queries

The principal use case is reading the list of available QuickCode types with their localized meanings, typically as the header set for a dependent lookup query. A minimal query is:

SELECT lookup_type, lookup_type_meaning
FROM apps.fnd_common_lookup_types
ORDER BY lookup_type;

To enumerate the codes that belong to a given type, the view is joined to FND_LOOKUP_VALUES on LOOKUP_TYPE:

SELECT t.lookup_type, t.lookup_type_meaning,
       v.lookup_code, v.meaning
FROM apps.fnd_common_lookup_types t,
       apps.fnd_lookup_values v
WHERE v.lookup_type = t.lookup_type
  AND t.lookup_type = :p_lookup_type
  AND SYSDATE BETWEEN NVL(v.start_date_active, SYSDATE)
                  AND NVL(v.end_date_active, SYSDATE)
  AND v.enabled_flag = 'Y';

Because results are constrained to VIEW_APPLICATION_ID = 3 and pass through security-group filtering, the view is appropriate for legacy QuickCode-driven reports and for validating that custom code still resolves after an upgrade from 12.1.1 to 12.2.2. New development should query FND_LOOKUP_TYPES and FND_LOOKUP_VALUES directly to gain the full, unrestricted lookup inventory; the compatibility view is retained for existing code and should be treated as read-only reference data.