Results for “leaf_node”

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

Overview

OKC_LOOKUPS_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, registered under the OKC (Contracts Core) product family. It is documented as valid in both release 12.1.1 and 12.2.2 and serves as a Contracts-specific projection over the Oracle Application Object Library lookup repository. In EBS, seeded and user-defined lookup codes are physically stored in FND_LOOKUP_VALUES and exposed through the FND_LOOKUP_VALUES synonym. The OKC_LOOKUPS_V view narrows that repository to the lookup rows owned by the Contracts application and filters them to the language of the current session, providing a stable, Contracts-scoped list of code values for contract authoring, validation, and reporting.

The view is read-only by nature. It does not store data of its own and is intended for query, not DML. Its principal value is abstraction: rather than requiring every consumer to know the Contracts application identifier and the language-resolution rule, the view encapsulates both, so that reports, concurrent programs, interfaces, and extensions can resolve contract lookup values with a single, consistent predicate set.

Underlying Base Objects

The documented base object is FND_LOOKUP_VALUES, referenced in the view's defining SQL as a synonym. FND_LOOKUP_VALUES is the core Applications lookup table, holding every lookup type, its lookup codes, translated meanings and descriptions, date-range validity, and enabled status.

The defining text applies three filters to that source:

• LANGUAGE = USERENV('LANG') — restricts rows to the language of the current database session, so that MEANING and DESCRIPTION are returned in the runtime language rather than in every installed translation.
• VIEW_APPLICATION_ID = 0 — restricts rows to the shared or common lookup set rather than to application-owned lookup rows, ensuring that only the standard set of codes is visible.
• SECURITY_GROUP_ID = 0 — restricts rows to the standard, non-secured lookup group.

Because the view reads from a synonym over a single table, it introduces no joins and therefore no fan-out or performance penalty beyond the base table's own access path. Indexes on FND_LOOKUP_VALUES (typically on lookup type and language) apply normally to queries against the view.

Key Columns

The view exposes the following documented columns:

• LOOKUP_TYPE — the lookup category, identifying the group of related codes (the primary discriminator in almost every query).
• LOOKUP_CODE — the stored, language-independent code value used for validation and persistence.
• MEANING — the translated, user-facing label displayed in forms and reports.
• DESCRIPTION — the longer, translated explanatory text associated with the code.
• ENABLED_FLAG — indicates whether the code is currently active and selectable.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective date range that bounds the code's validity.
• LEAF_NODE — the leaf-node indicator carried over from FND_LOOKUP_VALUES, which distinguishes terminal lookup entries from non-terminal or parent nodes when a lookup structure is maintained hierarchically.

The inclusion of LEAF_NODE, together with ENABLED_FLAG and the active date range, gives consumers the three dimensions normally required to build a valid selection list: hierarchy position, enabled status, and effective dating.

Common Use Cases and Queries

The view is commonly used to drive value lists in contract entry forms, to validate inbound interface data before insert into OKC tables, and to render descriptive labels in reports where only the stored code would otherwise appear. A typical query retrieves the current, enabled codes for one lookup type:

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

Where hierarchical lookups are used, LEAF_NODE can be added to the predicate to return only terminal entries, preventing parent nodes from appearing as selectable values. For diagnostic work, a simple SELECT DISTINCT lookup_type FROM okc_lookups_v; enumerates the lookup categories visible to the Contracts application, which is useful when tracing why a particular code is or is not offered to the user.