Search Results cz_src_devl_projects_v




Overview

The CZ_SRC_DEVL_PROJECTS_V view is a reporting and integration layer within the Oracle E-Business Suite Configurator product (CZ). It is defined in the APPS schema and exposes development project header records for consumption by other application modules, concurrent programs, and external interfaces. In the ETRM reference for release 12.2.2 the object carries a status of VALID and is classified as a view owned by APPS.

The view does not store data itself; it consolidates project header information sourced from the Configurator development project tables and resolves the display text associated with each project. Its principal role is to present a denormalized, filtered projection of development projects so that dependent components — such as configurator model extraction, source import/export utilities, and customized reports — can query a single, consistently structured row set rather than navigating the underlying normalized schema.

Because the view applies deletion and entry-state filters internally, callers receive only active, non-deleted development projects, which reduces the risk of stale or logically removed records flowing into downstream processing.

Underlying Base Objects

The view is defined over three referenced objects as documented in the ETRM metadata:

  • CZ_DEVL_PROJECTS (synonym to the base table) — the primary source of development project header data, supplying identifiers, names, model type, organization, inventory item, and product key references.
  • CZ_LOCALIZED_TEXTS_VL (view) — supplies translated text strings, joined on INTL_TEXT_ID, providing the internationalized description where one exists.
  • CZ_RP_ENTRIES (synonym to the repository entry table) — joined on OBJECT_ID with OBJECT_TYPE = 'PRJ' to confirm the project has a valid repository entry.

The join between CZ_DEVL_PROJECTS and CZ_LOCALIZED_TEXTS_VL is an outer join (TXT.INTL_TEXT_ID(+)), so projects lacking a localized text record are still returned, with the description falling back to the project's own DESC_TEXT through an NVL expression. The join to CZ_RP_ENTRIES is an inner join, ensuring only projects that have a corresponding, non-deleted repository entry (RP.DELETED_FLAG = '0') are surfaced. The base project row must also satisfy PROJ.DELETED_FLAG = '0'.

Key Columns

  • DEVL_PROJECT_ID — primary identifier for the development project; used as the key across dependent configurator objects.
  • NAME — the project name as defined by the developer or implementer.
  • DESC_TEXT — the resolved description. This column returns the localized text string when available, otherwise the project's stored description, via the NVL expression.
  • ORIG_SYS_REF — original system reference, useful for traceability when projects are migrated or copied between environments.
  • CREATION_DATE / LAST_UPDATE_DATE — standard audit timestamps.
  • CREATED_BY / LAST_UPDATED_BY — standard audit user identifiers referencing FND_USER.
  • MODEL_TYPE — indicates the type of configurator model associated with the project.
  • ORGANIZATION_ID — inventory organization context for the project.
  • INVENTORY_ITEM_ID — the inventory item linked to the project, where applicable.
  • PRODUCT_KEY — the product key identifying the configurable product.

Common Use Cases and Queries

Typical uses include listing development projects for a given organization, driving extract or comparison utilities, and joining project information to other configurator or inventory metadata.

To list all active development projects:

  • SELECT devl_project_id, name, desc_text, model_type
  • FROM cz_src_devl_projects_v
  • ORDER BY name;

To restrict to a specific inventory organization and product:

  • SELECT devl_project_id, name, organization_id, inventory_item_id
  • FROM cz_src_devl_projects_v
  • WHERE organization_id = :org_id
  • AND product_key = :product_key;

To audit recent activity:

  • SELECT name, creation_date, last_update_date, last_updated_by
  • FROM cz_src_devl_projects_v
  • WHERE last_update_date >= :from_date;

Because the view already enforces deletion and repository-entry filters, customization authors should generally query the view rather than rebuilding the same join logic against the base tables.