Search Results rg_lookups




Overview

RG_LOOKUPS is a view owned by the APPS schema in Oracle E-Business Suite, registered as part of the RG (Application Report Generator) product module. It exposes a filtered subset of Oracle Application Object Library (FND) lookup values that belong specifically to the Application Report Generator application, identified internally by VIEW_APPLICATION_ID = 168. Rather than querying the global FND_LOOKUP_VALUES table directly, the view presents only those lookup codes relevant to the RG module, scoped to the runtime language of the session and the standard security group context.

In Oracle EBS 12.1.1 and 12.2.2, this view serves reporting and integration usage. It provides a stable, module-scoped read interface so that reports, concurrent programs, and custom extensions associated with the Application Report Generator can resolve lookup meanings (such as status codes and report type indicators) without hardcoding values or referencing the full FND lookup set. Because the view filters on LANGUAGE = USERENV('LANG'), the content is automatically translated to the session language, keeping report output consistent with the user's locale.

Underlying Base Objects

The view is defined over a single documented base object, FND_LOOKUP_VALUES, which is exposed through a synonym in the APPS schema. FND_LOOKUP_VALUES is the standard Oracle EBS table that stores all lookup codes and their translated meanings across applications.

The view text applies three restricting predicates to that base table:

  • LANGUAGE = USERENV('LANG') — returns only the rows translated into the language of the current session.
  • VIEW_APPLICATION_ID = 168 — restricts rows to the Application Report Generator application.
  • SECURITY_GROUP_ID = 0 — limits rows to the standard (non-secured) lookup values.

These predicates convert the global lookup table into an application-specific, language-aware projection. All columns exposed by the view are drawn directly from FND_LOOKUP_VALUES without transformation or computation.

Key Columns

The view exposes seven columns, each mapped one-to-one from the base table:

  • LOOKUP_TYPE — the lookup category or group name to which the code belongs. Together with LOOKUP_CODE it forms the logical key for a given value.
  • LOOKUP_CODE — the stored code value used by application logic and stored in transactional or configuration tables.
  • MEANING — the user-facing, language-translated display text associated with the code; this is what reports typically show.
  • DESCRIPTION — an optional longer description providing additional context for the value.
  • ENABLED_FLAG — indicates whether the lookup value is currently active (Y) or disabled (N).
  • START_DATE_ACTIVE — the effective start date from which the value is valid.
  • END_DATE_ACTIVE — the effective end date after which the value is no longer valid; null typically means open-ended.

The date and enabled columns allow consumers to filter for values valid as of a given point in time, supporting accurate historical reporting.

Common Use Cases and Queries

Typical scenarios include translating stored codes into display meanings within RG reports, driving value-set lists in custom concurrent program parameters, and validating that a code was active on a given date. A basic query lists all enabled values for a lookup type:

  • SELECT LOOKUP_CODE, MEANING FROM APPS.RG_LOOKUPS WHERE LOOKUP_TYPE = :p_type AND ENABLED_FLAG = 'Y';

To resolve a single code to its translated meaning for a report column:

  • SELECT MEANING FROM APPS.RG_LOOKUPS WHERE LOOKUP_TYPE = :p_type AND LOOKUP_CODE = :p_code;

To retrieve only values active on a specific date, the date columns are used to bound the result:

  • SELECT LOOKUP_CODE, MEANING FROM APPS.RG_LOOKUPS WHERE LOOKUP_TYPE = :p_type AND (START_DATE_ACTIVE IS NULL OR START_DATE_ACTIVE <= :p_date) AND (END_DATE_ACTIVE IS NULL OR END_DATE_ACTIVE >= :p_date) AND ENABLED_FLAG = 'Y';

Because the view depends on USERENV('LANG'), reports should not be run with an unexpected session language if a fixed-language output is required. Queries should generally filter on LOOKUP_TYPE to avoid scanning the full application lookup set.