Results for “cz_subtypeoption_lkv”

16 results




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

Overview

CZ_SUBTYPEOPTION_LKV is an Oracle E-Business Suite (EBS) view owned by the APPS schema within the CZ (Configurator) product module. Its status is listed as VALID in ETRM metadata for both 12.1.1 and 12.2.2. The view functions as a lookup value key view (denoted by the "_LKV" suffix) that exposes a filtered, read-only subset of the general-purpose lookup values view CZ_LOOKUP_VALUES_VL. Specifically, it restricts the result set to a single lookup type: LIST_NAME = 'SUBTYPE_OPTION'.

From the perspective of reporting and integration, the view presents the set of enumerated subtype option values used by Oracle Configurator when interpreting or validating configurable option data. Rather than querying the broader CZ_LOOKUP_VALUES_VL and applying a filter at each call site, the application and its interfaces can reference CZ_SUBTYPEOPTION_LKV directly to obtain the subtype option lookup domain. This encapsulation is characteristic of key lookup views across EBS: it standardizes the lookup type filter and simplifies developer and report-writer access to a defined value domain.

Underlying Base Objects

The view is defined over a single documented base object: CZ_LOOKUP_VALUES_VL, itself a view. The definition is a straight projection with a WHERE clause applied:

  • Base object: CZ_LOOKUP_VALUES_VL (VIEW).
  • Selection logic: All rows where LIST_NAME = 'SUBTYPE_OPTION'.
  • Join/aggregation: None. The view is a one-to-one filtered projection; it introduces no joins, group functions, or DISTINCT operations.

Because CZ_LOOKUP_VALUES_VL is a translated (_VL) view, it is expected to expose both a base-language row and, where translations exist, additional language-specific rows keyed by LANGUAGE and SOURCE_LANG. The "_LKV" view inherits that multilingual behavior unchanged — only the LIST_NAME filter is added. No other Configurator base tables are documented as referenced by this object.

Key Columns

The columns exposed mirror those of the underlying lookup values view:

  • LIST_NAME — The lookup type; always 'SUBTYPE_OPTION' in this view.
  • DATA_VALUE — The stored lookup value (the code) for a subtype option.
  • NUMERIC_ID_VALUE — Numeric identifier associated with the value, when applicable.
  • VALUE_SEQ — Display/ordering sequence for the value in UI pick lists.
  • DATA_TYPE_ID — Identifier indicating the data type of the value.
  • NULL_VALUE_FLAG — Indicates whether the value is a null/blank value entry.
  • VALUE_LABEL — The translatable user-facing label for the option value.
  • VALUE_DESCRIPTION — Longer description text.
  • VALUE_NOTES — Additional notes attached to the value.
  • LANGUAGE — Language of the current row.
  • SOURCE_LANG — Source language of the row from which translations derive.

Common Use Cases and Queries

Typical uses include report parameter lists that present subtype options, validation of option codes during inbound Configuration/interface loads, and reference queries in diagnostic or data-seeding scripts. The following statements illustrate standard access patterns.

  • Retrieve all subtype options in the session language and display order:

SELECT DATA_VALUE, VALUE_LABEL, VALUE_SEQ, VALUE_DESCRIPTION FROM APPS.CZ_SUBTYPEOPTION_LKV ORDER BY VALUE_SEQ, DATA_VALUE;

  • Validate a specific code exists within the domain:

SELECT COUNT(*) FROM APPS.CZ_SUBTYPEOPTION_LKV WHERE DATA_VALUE = :p_value;

  • Restrict output to one language where translations exist:

SELECT DATA_VALUE, VALUE_LABEL FROM APPS.CZ_SUBTYPEOPTION_LKV WHERE LANGUAGE = USERENV('LANG') ORDER BY VALUE_SEQ;

Because the view always filters to the SUBTYPE_OPTION lookup type, no LIST_NAME predicate is required at the query level. Care should be taken with multilingual rows: joins to configuration data on DATA_VALUE alone can return multiple language rows and should be restricted by LANGUAGE or by aggregating to the base row. Since the view is documented as read-only, INSERT/UPDATE/DELETE operations must be directed to the underlying lookup maintenance forms or base tables rather than this object.