Search Results ic_prch_cls_vw




Overview
Explore in AI Chat

Overview

IC_PRCH_CLS_VW is a backward-compatibility view owned by the APPS schema in Oracle E-Business Suite. It belongs to the GMI (Process Manufacturing Inventory) product family and exists to expose purchasing class data in the legacy OPM Application Programming Interface format. In earlier releases of Oracle Process Manufacturing, purchasing classes were maintained within OPM-specific tables. When Oracle migrated this functionality onto the Oracle Inventory category model, the underlying storage moved to standard category tables such as MTL_CATEGORIES_V and MTL_CATEGORY_SETS. The view IC_PRCH_CLS_VW preserves the original column shape and naming so that pre-existing forms, reports, concurrent programs, and custom integrations that reference the old purchasing class interface continue to function without modification.

The view is defined as a UNION of two branches, both filtered through GMI_CATEGORY_SETS where OPM_CLASS equals 'PURCH_CLASS'. This ensures that only category sets flagged as purchasing classes in the OPM configuration are returned. The two branches differ in whether they join to MTL_CATEGORY_SET_VALID_CATS, which governs category set validity. Consequently, the view presents a unified, backward-compatible representation of purchasing classes regardless of category set validation status.

Underlying Base Objects

IC_PRCH_CLS_VW is defined over four documented base objects. MTL_CATEGORIES_V is the primary source of category data, supplying concatenated segment values, category identifiers, descriptions, audit columns, and the fifteen descriptive flexfield attributes. MTL_CATEGORY_SETS supplies the structure identifier used to match categories to the underlying category structure. GMI_CATEGORY_SETS is the OPM-side configuration table that identifies which category sets are designated as purchasing classes via the OPM_CLASS flag. MTL_CATEGORY_SET_VALID_CATS is referenced by the second UNION branch to include categories that may not satisfy the validation restriction applied in the first branch.

The join chain is therefore: GMI_CATEGORY_SETS (OPM_CLASS = 'PURCH_CLASS') provides the category set identifier, which links to MTL_CATEGORY_SETS on CATEGORY_SET_ID; the resulting STRUCTURE_ID links to MTL_CATEGORIES_V. This chain replaces the direct OPM table access used in prior releases and routes all reads through the certified Oracle Inventory category model.

Key Columns

The first column returns the first eight bytes of CATEGORY_CONCAT_SEGS and serves as the legacy purchasing class code, preserving fixed-width semantics through SUBSTRB. CATEGORY_ID carries the numeric category primary key. The description column is truncated to seventy bytes to match the original column width. Audit columns CREATION_DATE, LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN are passed through directly.

Two positional columns convey status information. The eighth column is a literal zero, retained for interface compatibility. The ninth column applies DECODE to DISABLE_DATE, returning 0 when the category is active and 1 when disabled. The tenth column returns a NULL NUMBER placeholder. ATTRIBUTE1 through ATTRIBUTE15 and ATTRIBUTE_CATEGORY expose descriptive flexfield data, and fifteen TO_CHAR(NULL) placeholders preserve additional legacy output positions.

Common Use Cases and Queries

Typical uses include validating purchasing class assignments during data migration, populating legacy reports that expect the historic column layout, and reconciliation of OPM purchasing classes against the underlying Inventory categories. A basic query retrieves active purchasing classes:

  • SELECT category_id, description FROM apps.ic_prch_cls_vw WHERE disabled_flag = 0;
  • SELECT category_id, description, attribute1 FROM apps.ic_prch_cls_vw ORDER BY description;
  • SELECT COUNT(*) FROM apps.ic_prch_cls_vw;

Because the view performs a UNION and applies string functions to MTL_CATEGORIES_V, queries benefit from restricting results by category_id or description rather than scanning the entire result set. Custom code should treat the view as read-only, since it exposes no INSTEAD OF triggers and holds no data of its own.