Search Results gl_lookups




Overview
Explore in AI Chat

Overview

GL_LOOKUPS is a read-only dictionary view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It is classified under the GL — General Ledger product/module and carries a VALID status in the ETRM repository. The view exposes a filtered subset of Oracle Application Object Library lookup values that pertain specifically to the General Ledger application. Rather than storing data in its own right, GL_LOOKUPS projects a restricted slice of the shared FND_LOOKUP_VALUES table, which is the central repository for all extensible lookup codes across the E-Business Suite.

The defining characteristic of this view is its application scoping. The view text filters on VIEW_APPLICATION_ID = 101, which is the registered application identifier for Oracle General Ledger, and on SECURITY_GROUP_ID = 0, the default security group. It also restricts rows to the language of the current session via the USERENV('LANG') call. The result is that callers querying GL_LOOKUPS see only General Ledger lookup types, translated into their own session language, without needing to know the internal application identifier or to join back to FND_APPLICATION themselves. This makes the view a convenient, stable integration point for reports, interfaces, and conversions that must resolve GL lookup meanings.

Underlying Base Objects

According to the documented ETRM metadata, GL_LOOKUPS is defined over a single referenced base object: FND_LOOKUP_VALUES, accessed through a synonym. FND_LOOKUP_VALUES is the AOL table that holds every lookup code defined in the system, keyed by lookup type, lookup code, language, application, and security group. Because General Ledger lookups are stored in that shared table rather than in a dedicated GL table, GL_LOOKUPS is best understood as a security- and application-scoped projection of FND_LOOKUP_VALUES.

The view text is:

Because it is a view and not a table, GL_LOOKUPS stores no data. All inserts, updates, and deletions must be performed against FND_LOOKUP_VALUES; the view simply reflects those changes in real time. No materialization or aggregation occurs.

Key Columns

  • LOOKUP_TYPE — The lookup type, i.e., the category or group under which related lookup codes are organized (for example, a GL-specific type such as journal source or currency conversion type).
  • LOOKUP_CODE — The internal code value stored on transactional rows; this is the value typically validated against the lookup.
  • MEANING — The user-facing, translatable display value corresponding to the lookup code, resolved for the session language.
  • DESCRIPTION — An optional longer explanation of the lookup code, also language-dependent.
  • ENABLED_FLAG — Indicates whether the lookup code is currently active (Y) or disabled (N). Disabled codes remain in the table for historical data but should not be presented for new selections.
  • START_DATE_ACTIVE — The date from which the lookup code becomes effective. A null value indicates no start restriction.
  • END_DATE_ACTIVE — The date after which the lookup code is no longer effective. A null value indicates the code is open-ended.

Common Use Cases and Queries

GL_LOOKUPS is most often used in custom reports, concurrent programs, and interface/API routines that must resolve or validate General Ledger lookup values. A typical pattern is to join the view to a transactional table on LOOKUP_CODE within a fixed LOOKUP_TYPE to obtain the printable MEANING. The following query lists all enabled GL lookup values for a given type:

  • SELECT lookup_code, meaning, description, start_date_active, end_date_active
  • FROM gl_lookups
  • WHERE lookup_type = :p_lookup_type
  • AND enabled_flag = 'Y'
  • AND TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE) AND NVL(end_date_active, SYSDATE);

A second common usage is to join the view into a reporting query over GL journals or balances so that codes are rendered as their meanings in the report output. Because the view already filters by session language and application, no additional language join is required. Note that the view omits TAG and other attribute columns present in FND_LOOKUP_VALUES; when those are needed, query the base table directly with the same VIEW_APPLICATION_ID = 101 predicate. Care should also be taken to respect ENABLED_FLAG and the active date range whenever the view is used to drive a list of values.