Search Results ja_lookups




Overview

The JA_LOOKUPS view is a localization-specific reporting object owned by the APPS schema in Oracle E-Business Suite. It belongs to the JA – Asia/Pacific Localizations product family and is classified in ETRM as a VIEW with VALID status in both release 12.1.1 and 12.2.2. Its documented purpose is to expose "Standard lookup codes for Quickcodes" — that is, the predefined and user-extensible code values that populate Asia/Pacific localization QuickCode sets used throughout JA functionality.

Functionally, JA_LOOKUPS is a filtered, language-aware projection of the core Oracle Application Object Library lookup table. Rather than storing data of its own, it presents a restricted subset of lookup values that belong specifically to the JA localization application, scoped to the session language and a security group of zero. This makes it a convenient, read-only façade for developers, report authors, and integration components that need to resolve JA QuickCode meanings without writing repetitive join and filter predicates against the underlying dictionary table.

Underlying Base Objects

The view is defined over a single referenced base object, documented in the ETRM metadata as FND_LOOKUP_VALUES (accessed through a synonym). The documented view text is essentially:

Three predicates shape the result set. First, LANGUAGE = USERENV('LANG') restricts rows to the language of the current database session, ensuring that MEANING and DESCRIPTION are returned in the caller's locale. Second, VIEW_APPLICATION_ID = 7000 confines the view to the JA localization application, since application ID 7000 identifies Asia/Pacific Localizations. Third, SECURITY_GROUP_ID = 0 limits output to the standard, non-secured lookup rows. Because JA_LOOKUPS is a view and not a table, it inherits no independent storage, indexes, or constraints; all maintenance — insertion, update, and translation of lookup values — must be performed against FND_LOOKUP_VALUES through the standard Oracle lookup maintenance forms or APIs, with the appropriate application and security group settings.

Key Columns

The view projects a near-complete column set from FND_LOOKUP_VALUES, providing both business-meaningful values and full audit and descriptive-flexfield context. Significant columns include:

  • LOOKUP_TYPE — the QuickCode set or lookup type name that groups related values.
  • LOOKUP_CODE — the stored code value used by application logic and interfaces.
  • MEANING — the displayable, user-facing label for the code, translated to the session language.
  • DESCRIPTION — supplementary free-text explanation of the code.
  • ENABLED_FLAG — indicates whether the lookup value is active and available for selection.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — the effective date window governing when the code is valid, supporting time-bound localization rules.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns recording who created or last modified the row and when.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield context and segment columns enabling localized data to be stored alongside each QuickCode.

Common Use Cases and Queries

Typical consumers of JA_LOOKUPS include custom JA localization reports, concurrent programs, and integrations that must translate stored lookup codes into human-readable meanings or validate incoming codes against the active, date-valid QuickCode set. A representative query retrieving all active values for a given JA lookup type is:

  • SELECT lookup_code, meaning, description FROM apps.ja_lookups WHERE lookup_type = :p_type AND enabled_flag = 'Y' AND SYSDATE BETWEEN NVL(start_date_active, SYSDATE) AND NVL(end_date_active, SYSDATE) ORDER BY lookup_code;

Another frequent pattern joins lookup values to transactional or interface data to resolve descriptions:

  • SELECT t.code, l.meaning FROM apps.ja_interface_tbl t, apps.ja_lookups l WHERE t.code = l.lookup_code AND l.lookup_type = 'JA_SOME_TYPE';

Because JA_LOOKUPS automatically filters on session language, callers need not add their own LANGUAGE predicate, though they should always filter by LOOKUP_TYPE, ENABLED_FLAG, and effective dates to obtain a deterministic, currently valid result set.