Search Results igi_lookups




Overview
Explore in AI Chat

Overview

IGI_LOOKUPS is an APPS-owned database view shipped with Oracle E-Business Suite, belonging to the IGI product group — Public Sector Financials International. Its documented purpose is to expose Oracle Application Object Library QuickCodes (lookup values) relevant to the IGI application, presenting the same structural shape as the standard FND_LOOKUPS view but filtered to the IGI application context. In Oracle EBS 12.1.1 and 12.2.2 the object is reported by ETRM as VALID with an APPS owner, indicating it is a supported, catalogued dictionary object rather than a customer-created artifact.

Rather than storing data itself, the view is a security- and language-aware projection over the lookup repository. It gives developers, concurrent programs, and reporting tools a stable, application-scoped access point to IGI lookup codes without requiring direct knowledge of the underlying Application Object Library tables or the security grouping logic. This makes it useful both for EBS-side queries and for integration extracts that need to resolve lookup meanings to human-readable text.

Underlying Base Objects

The view is defined over a single documented base object: FND_LOOKUP_VALUES, referenced through a synonym in the APPS schema. FND_LOOKUP_VALUES is the Application Object Library table that stores the individual values belonging to each lookup type, including their codes, translated meanings, descriptions, enablement flags, and effective date ranges.

The view's defining filter is significant. It restricts rows to VIEW_APPLICATION_ID = 8400, the application identifier associated with the IGI product, so only lookups registered against that application are returned. It further restricts rows by LANGUAGE = USERENV('LANG'), returning the translation matching the session language, and by SECURITY_GROUP_ID = FND_GLOBAL.LOOKUP_SECURITY_GROUP(LOOKUP_TYPE, VIEW_APPLICATION_ID), applying the standard lookup security model. Because these predicates depend on session context, the same query can return different result sets for different users, languages, or security configurations.

Key Columns

  • LOOKUP_TYPE — The lookup type (lookup category) to which the value belongs; the primary grouping key for lookups and an input to the security group function.
  • LOOKUP_CODE — The stored code value, typically the value persisted in transactional tables and the key used in programmatic comparisons.
  • MEANING — The translated, user-facing display text for the code, suitable for reports and user interfaces.
  • DESCRIPTION — Additional descriptive text associated with the lookup value.
  • ENABLED_FLAG — Indicates whether the value is currently active (Y) or disabled (N).
  • START_DATE_ACTIVE — The date from which the lookup value becomes effective; null indicates no start restriction.
  • END_DATE_ACTIVE — The date after which the lookup value is no longer effective; null indicates no end restriction.

Common Use Cases and Queries

Typical uses include resolving stored codes to display meanings in custom reports, driving validation lists in concurrent programs or forms, and extracting lookup configuration for interface or data-migration routines. Combining the columns above supports the standard join pattern in which a transactional table's code column is matched to LOOKUP_CODE within a specific LOOKUP_TYPE.

A representative query returning all enabled IGI lookup values for a given type is:

SELECT lookup_type,
       lookup_code,
       meaning,
       description,
       enabled_flag,
       start_date_active,
       end_date_active
  FROM apps.igi_lookups
 WHERE lookup_type = :p_lookup_type
   AND enabled_flag = 'Y'
 ORDER BY lookup_code;

A second pattern retrieves the distinct lookup types available for the IGI application, useful for building selection lists in custom extensions:

SELECT DISTINCT lookup_type
  FROM apps.igi_lookups
 ORDER BY lookup_type;

Because the view already applies the language and security predicates, callers should not normally re-apply them; doing so risks masking the intended session behaviour. Queries should also account for START_DATE_ACTIVE and END_DATE_ACTIVE where date-effective lookups are in use, though the standard lookup security and enablement logic already governs most visibility outcomes.