Search Results okc_subclasses_v




Overview
Explore in AI Chat

Overview

OKC_SUBCLASSES_V is a seeded, read-only database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKC – Contracts Core product. It exposes subclass (sub-class) definitions used throughout the Oracle Contracts module to classify and categorize contract documents, terms, and related artifacts. Functionally, the view presents a language-resolved, user-facing projection of the underlying descriptive-flexfield-style subclass setup, joining the base table to its translation table so that the current session's language determines the meaning and description returned.

Because it is a view rather than a table, OKC_SUBCLASSES_V carries no storage of its own and does not participate in DML. It serves strictly as a reporting, inquiry, and integration surface. Application code, concurrent programs, and third-party integrations query it to resolve a subclass code into a human-readable meaning without having to handle the master/detail translation join or the language filter directly. This makes it the conventional entry point for any external reporting that must present contract subclass information in the end user's own language.

Underlying Base Objects

The view is defined over two documented base objects, both accessed by the APPS schema through synonyms:

  • OKC_SUBCLASSES_B — the base (master) table holding the language-independent attributes of each subclass, including its code, class code association, effective dates, access level, and the flag controlling opportunity creation.
  • OKC_SUBCLASSES_TL — the translation table holding language-specific attributes, principally MEANING and DESCRIPTION, keyed by CODE and LANGUAGE.

The two are joined on CODE, with an additional predicate restricting the translation row to the language of the current session via USERENV('LANG'). This design follows the standard EBS MLS (Multi-Language Support) pattern, where the _B table provides the canonical definition and the _TL table provides translated text. Selects against the view therefore always return exactly one row per subclass code, resolved into the caller's language.

Key Columns

  • ROW_ID — the ROWID of the base table row, exposed for identification purposes.
  • CODE — the unique subclass code; the primary business key and the join column between the base and translation tables.
  • CLS_CODE — the parent class code to which the subclass belongs, establishing the class/subclass hierarchy.
  • MEANING — the translated display name of the subclass in the session language.
  • DESCRIPTION — the translated longer description of the subclass.
  • SFWT_FLAG — the SFWT (Standard Function Without Translation) flag from the translation table, indicating whether the term is a standard seeded value maintained outside the normal translation process.
  • START_DATE / END_DATE — the effective date range during which the subclass definition is active.
  • ACCESS_LEVEL — the access level assigned to the subclass.
  • CREATE_OPP_YN — flag indicating whether an opportunity may be created for this subclass.
  • OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit and concurrency columns carried through from the base table.

Common Use Cases and Queries

The most frequent use is LOV-style lookup and reporting, resolving subclass codes into readable values and filtering the class hierarchy. A typical query listing active subclasses for a given class is:

  • SELECT code, meaning, description, cls_code, access_level, create_opp_yn FROM okc_subclasses_v WHERE cls_code = :p_class AND SYSDATE BETWEEN start_date AND NVL(end_date, SYSDATE);
  • SELECT meaning, description FROM okc_subclasses_v WHERE code = :p_code; — a single-record lookup, commonly embedded in PL/SQL validation.
  • SELECT cv.code, cv.meaning FROM okc_subclasses_v cv, okc_subclasses_v parent WHERE cv.cls_code = parent.code; — a self-join to present the subclass together with its parent class.

Because translations are resolved dynamically, the same query issued under different session languages returns localized text without any change to the SQL. Integrations extracting contract configuration commonly select CODE, CLS_CODE, MEANING, START_DATE, and END_DATE to build external reference data sets.