Results for “oke_std_notes_v”

26 results




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

Overview

OKE_STD_NOTES_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKE – Project Contracts application. Its stated purpose in the ETRM metadata is to expose "standard note type" values for use within the Project Contracts module. In other words, the view presents a filtered, denormalized list of the lookup codes that Oracle Projects and Project Contracts use to classify standard contract notes (for example, terms, clauses, and boilerplate text associated with a contract or deliverable).

Because the view is read-only and defined over a Foundation lookup view rather than a transaction table, it plays a reference-data role rather than a transactional one. It is typically consumed by reports, concurrent programs, extensions, and integration interfaces that need to resolve a stored standard-note-type code into its descriptive meaning, or that need to validate that a code is currently enabled before it is assigned. It carries no project- or contract-specific data itself; it is the controlled vocabulary behind the notes subsystem.

Underlying Base Objects

The documented definition of the view is a single SELECT from one base object:

  • FND_LOOKUP_VALUES_VL — the Foundation lookup values view (a view, not a table). OKE_STD_NOTES_V selects from it and applies the following filters in the WHERE clause: LOOKUP_TYPE = 'STD_NOTE_TYPE' and VIEW_APPLICATION_ID = 777. Application ID 777 corresponds to the OKE/Projects Contracts application, which scopes the lookup set to that product.

Consequently, the view inherits the behavior of the Oracle Application Object Library lookup framework. Only lookup values that belong to the STD_NOTE_TYPE lookup type and the 777 application are returned. The metadata records the view as VALID in the APPS schema for both 12.1.1 and 12.2.2, and the definition is unchanged between those releases. Note that FND_LOOKUP_VALUES_VL is itself a view; the true base table is FND_LOOKUP_VALUES, and the _VL suffix indicates the view applies language (translation) handling, so MEANING and DESCRIPTION may be returned in the session's language.

Key Columns

The documented column list of OKE_STD_NOTES_V is as follows:

  • STD_NOTE_CODE — the lookup code; the primary identifier for a standard note type, equivalent to LOOKUP_CODE in the underlying lookup view.
  • STD_NOTE_NAME — the display name of the note type, equivalent to MEANING.
  • DESCRIPTION — the longer descriptive text for the note type.
  • START_DATE_ACTIVE — the date from which the note type becomes effective.
  • END_DATE_ACTIVE — the date on which the note type ceases to be effective (null means open-ended).
  • ENABLED_FLAG — indicates whether the value is currently enabled ('Y'/'N'), independent of the active date range.

The column naming reflects how the view re-labels the lookup attributes: LOOKUP_CODE is surfaced as STD_NOTE_CODE and MEANING as STD_NOTE_NAME, aligning the reference data to OKE terminology.

Common Use Cases and Queries

Typical uses include populating a list of values on a custom form or OAF page, resolving a stored code to its description in a report, and validating note types during data loading. The following query returns all currently active and enabled standard note types:

  • SELECT std_note_code, std_note_name, description FROM apps.oke_std_notes_v WHERE enabled_flag = 'Y' AND TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE-1) AND NVL(end_date_active, SYSDATE+1) ORDER BY std_note_name;
  • SELECT std_note_code, std_note_name FROM apps.oke_std_notes_v WHERE UPPER(std_note_name) LIKE UPPER(:p_search || '%'); — for a search-based LOV.
  • SELECT description FROM apps.oke_std_notes_v WHERE std_note_code = :p_code; — to resolve a single code to its description.

Because the view reads from FND_LOOKUP_VALUES_VL, results reflect whatever is configured in the STD_NOTE_TYPE lookup for application 777, including any user-defined additions. Applications should filter on ENABLED_FLAG and the active date range unless historical or disabled values are deliberately required.