Search Results fnd_lookups_values

Overview

APPS.OKC_ASSENTS_LOOKUPS_V is a reporting and integration view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments. It resides in the APPS schema and is registered in FND Design Data under the internal name OKC.OKC_ASSENTS_LOOKUPS_V. The view exposes lookup-driven attributes associated with the OKC_ASSENTS_V entity (the Oracle Contracts "Assents" or agreement-related entity), combining contract line status and operation codes with descriptive flexfield context and standard "Who" audit columns. Its primary role is to present code values in a denormalized, human-readable form suitable for concurrent programs, BI Publisher reports, Oracle Discoverer workbooks, and integration extracts, rather than for direct transactional data manipulation. The view is documented as VALID and carries the standard Oracle Internal Use Only warning, meaning Oracle supports access only through standard Applications programs and not from third-party extensions or ad hoc queries in a supported manner.

Underlying Base Objects

The view is defined over three documented referenced objects:

• OKC_ASSENTS_V — the primary contract/assent view supplying the core entity rows and the descriptive flexfield (DFF) structure. The lookup view decorates this base view with status and operation semantics.
• FND_LOOKUPS — the EBS standard lookup view, which is itself a synonym or view over FND_LOOKUP_TYPES and FND_LOOKUP_VALUES. This supplies the translatable, enabled meaning/description for the STS_CODE (line status) and OPN_CODE (operation) columns.
• FND_GLOBAL — the standard EBS package used to resolve session-level context such as USER_ID, RESP_ID, LOGIN_ID, and language. It is referenced to drive the multilingual lookup resolution (particularly the OPN_NAM column, the operation name) and the CREATED_BY / LAST_UPDATED_BY audit attribution in the context of the running session.

Because the view joins a contract entity to FND_LOOKUPS, its row count and the values returned for STS_CODE, OPN_CODE, and OPN_NAM depend on the enabled lookup types and the current language setting. Disabled or end-dated lookup codes will not be resolved to a meaning, which is a common source of apparently missing values.

Key Columns

• ROW_ID (ROWID) — the physical row address of the underlying contract row, useful for row identification and for joining back to base tables.
• STS_CODE (VARCHAR2 30) — line status code stored in FND_LOOKUP_VALUES. This is the raw code rather than the meaning; it must be joined or resolved against FND_LOOKUPS to obtain the user-facing description.
• OPN_CODE (VARCHAR2 30) — operation code, likewise defined in FND_LOOKUP_VALUES, identifying the operation or action associated with the assent row.
• OPN_NAM — the resolved operation name, obtained by translating OPN_CODE through the lookup framework (using FND_GLOBAL language context). This is the principal reason for referencing FND_GLOBAL.
• OBJECT_VERSION_NUMBER (NUMBER) — the standard EBS optimistic-locking column, set to 1 on insert and incremented on each update. It is used by the public APIs to detect concurrent modification.
• ALLOWED_YN (VARCHAR2) — a Yes/No lookup type flag indicating whether a given operation or status transition is permitted.
• ATTRIBUTE_CATEGORY (VARCHAR2 90) and ATTRIBUTE1..ATTRIBUTE15 (VARCHAR2 450) — the descriptive flexfield (DFF) context and segment columns inherited from the base entity, allowing user-defined attributes to be carried alongside the lookup codes.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard "Who" columns populated from FND_GLOBAL session context.

Common Use Cases and Queries

The view is typically used to list assents with readable status and operation labels, to validate which operations are allowed, and to export contract lookup data for integration. When the user searches for "fnd_lookups_values", the intent is usually to retrieve the meaning behind STS_CODE or OPN_CODE that this view stores only as a code. A representative query joining the view back to the lookup values is:

• Resolve the meaning of STS_CODE: SELECT lv.lookup_code, lv.meaning FROM apps.fnd_lookup_values lv WHERE lv.lookup_type = '<STS_LOOKUP_TYPE>' AND lv.language = USERENV('LANG') AND SYSDATE BETWEEN lv.start_date_active AND NVL(lv.end_date_active, SYSDATE + 1) AND lv.enabled_flag = 'Y';
• List assents with resolved operation name: SELECT v.row_id, v.sts_code, v.opn_code, v.opn_nam, v.allowed_yn FROM apps.okc_assents_lookups_v v WHERE v.sts_code = 'ACTIVE';
• Audit recently changed rows: SELECT v.row_id, v.last_updated_by, v.last_update_date, v.object_version_number FROM apps.okc_assents_lookups_v v WHERE v.last_update_date >= TRUNC(SYSDATE) - 7 ORDER BY v.last_update_date DESC;
• Extract DFF segments for integration: SELECT v.row_id, v.attribute_category, v.attribute1, v.attribute2 FROM apps.okc_assents_lookups_v v WHERE v.attribute_category IS NOT NULL;

Because the view contains no lookup meaning for STS_CODE and OPN_CODE beyond OPN_NAM, reporting logic that requires the descriptive text of the status code must join FND_LOOKUP_VALUES explicitly on lookup_code, lookup_type, and the active date range. All access should be restricted to standard Oracle Applications programs, consistent with the internal-use restriction documented for this object.