Search Results cz_data_types_v




Overview
Explore in AI Chat

Overview

CZ_DATA_TYPES_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, belonging to the CZ (Configurator) product family. In both EBS 12.1.1 and 12.2.2 the object carries a VALID status and is registered in the EBS Technical Reference Manual (ETRM) as a documented view. Its purpose is to expose the set of configurator data type signatures that are currently active, presenting them in a denormalized, filter-friendly form suitable for reporting, concurrent programs, and integration extracts. The view is a thin projection over the CZ_SIGNATURES table with a single built-in predicate that restricts the result set to rows whose DELETED_FLAG is '0'. A placeholder column, LOOKUP_LIST_NAME, is emitted as a literal NULL, indicating that the view is designed to present a stable column list for downstream consumers while the lookup-list attribute is sourced elsewhere in the data model. Because the object is a view rather than a table, it is read-only; all maintenance of configuration data types occurs against CZ_SIGNATURES, and CZ_DATA_TYPES_V should be treated strictly as a query surface for configuration metadata.

Underlying Base Objects

The view text is defined as follows:

  • CZ_SIGNATURES — documented as a SYNONYM within the APPS schema in the 12.2.2 ETRM metadata; the underlying physical table stores the configurator signature definitions, including data types used by Configurator models, option classes, and features.

The relationship is direct and unfiltered except for the deleted-row predicate: every qualifying row in CZ_SIGNATURES produces exactly one row in CZ_DATA_TYPES_V. No joins, aggregations, or set operations are applied, so cardinality is preserved. In 12.1.1 the synonym resolves through the same APPS plumbing used by the 12.2.x editions; the Online Patching (adop) editioning architecture introduced in 12.2 does not alter the view definition, only the underlying table's editioning views and the way DDL is applied.

Key Columns

  • SIGNATURE_ID — primary identifier of the data type signature; the join key to other Configurator metadata (for example, references held by CZ_SIGNATURE_RULES or runtime configuration structures).
  • SIGNATURE_TYPE — classifies the signature, distinguishing the kind of data type or signature category used within Configurator.
  • NAME — the user-facing name of the data type signature.
  • DESCRIPTION — free-text description of the signature, typically populated by the seed data or by the administrator maintaining the configuration.
  • LOOKUP_LIST_NAME — always NULL in this view; retained so that report definitions can reference the column consistently with related objects that populate it.
  • DELETED_FLAG — deletion marker; because the view filters on DELETED_FLAG = '0', this column always returns the value '0' for rows visible through the view.
  • SEEDED_FLAG — indicates whether the underlying row was delivered as Oracle seed data ('1' or equivalent seeded value) or created by the customer, which is the standard filter for identifying user-defined versus factory-supplied metadata.

Common Use Cases and Queries

Typical usage includes validating which data type signatures are available before building Configurator models, reconciling seeded versus custom signatures after an upgrade, and feeding configuration metadata into downstream reporting or integration layers. The following examples illustrate standard access patterns:

  • List all active data types:

    SELECT signature_id, signature_type, name, description, seeded_flag FROM cz_data_types_v ORDER BY signature_type, name;

  • Isolate customer-defined (non-seeded) signatures:

    SELECT signature_id, name, description FROM cz_data_types_v WHERE seeded_flag = '0';

  • Join to related Configurator metadata for a model-level report:

    SELECT v.name, v.signature_type, s.* FROM cz_data_types_v v, cz_signatures s WHERE v.signature_id = s.signature_id;

  • Confirm that a specific signature still exists before referencing it in a configuration rule:

    SELECT COUNT(*) FROM cz_data_types_v WHERE signature_id = :p_signature_id;

Because the view already excludes soft-deleted rows, report authors need not add a DELETED_FLAG predicate themselves; adding one is harmless but redundant. All queries shown are read-only and safe for use in concurrent programs, BI Publisher data sets, and ad hoc SQL*Plus or SQL Developer sessions against the APPS schema.