Search Results qc_source

Overview

GMD_QC_E_ALL_SPEC_VRS_DISP_V is an APPS-owned reporting view within the Oracle E-Business Suite Process Manufacturing Product Development (GMD) module. It exposes quality specification version data in a presentation-ready format, augmenting the underlying specification version records with decoded, human-readable lookup descriptions. The view is a "display" (DISP) layer, meaning that for each Yes/No indicator and each coded lookup value held on the specification version, the view provides both the stored code and an accompanying description column suitable for direct presentation in forms, reports, and integrations.

The view is of particular interest to users searching on the column CONTROL_BATCH_STEP_IND_DISP, which is one of several decoded indicator columns the view materialises. In Oracle EBS 12.1.1 and 12.2.2, the view is defined in the APPS schema and is marked VALID, so it can be referenced safely from custom concurrent programs, BI Publisher data templates, OAF pages, and SQL*Plus or Discoverer reports without re-implementing the lookup decode logic.

Underlying Base Objects

The documented base objects underlying the view are:

• GMD_ALL_SPEC_VRS (referenced via a SYNONYM) — the primary source of specification version rows, supplying SPEC_VR_ID, SPEC_ID, item, lot, routing, recipe, formula, step, and operation attributes along with the stored Yes/No indicator codes.
• FND_LOOKUP_VALUES_VL (VIEW) — the Oracle Application Object Library lookup view, joined multiple times to translate the stored indicator values ('Y' and 'N') and coded values (such as SPEC_TYPE and COA_TYPE) into their display meanings. Aliases such as FLY, FLN, QC_SOURCE, and COA_IND in the view text reflect these repeated lookup joins.

Because the decoding is embedded in the view definition, consumption of the decoded columns is consistent across all callers and does not require a separate lookup join in each report.

Key Columns

• SPEC_VR_ID / SPEC_ID — Primary key of the specification version and its parent specification.
• ORGANIZATION_CODE, SPEC_TYPE, SPEC_TYPE_DISP — The owning organization and the specification type code with its lookup meaning.
• SPEC_NAME, SPEC_VERS, SPEC_STATUS, SPEC_STATUS_DESC, SPEC_VR_STATUS, SPEC_VR_STATUS_DESC — Identification and lifecycle status of the specification and its version.
• INVENTORY_ITEM_ID, REVISION, LOT_NUMBER, PARENT_LOT_NUMBER, SUBINVENTORY, LOCATOR — The item and inventory context to which the version applies.
• CONTROL_BATCH_STEP_IND / CONTROL_BATCH_STEP_IND_DISP — Indicates whether batch step control applies; the DISP column returns the lookup meaning for the stored 'Y'/'N' code. Parallel decoded columns exist for SAMPLE_INV_TRANS_IND, CONTROL_LOT_ATTRIB_IND, COA_AT_SHIP_IND, COA_AT_INVOICE_IND, COA_REQ_FROM_SUPL_IND, and AUTO_SAMPLE_IND.
• OUT_OF_SPEC_LOT_STATUS_CODE, IN_SPEC_LOT_STATUS_CODE, COA_TYPE, COA_TYPE_DISP — Lot disposition and Certificate of Analysis configuration.
• SAMPLING_PLAN_ID, START_DATE, END_DATE — Sampling plan assignment and effective dating.
• BATCH_ID, RECIPE_ID/NO/VERSION, FORMULA_ID/NO/VERS, ROUTING_ID/NO/VERS, STEP_ID/NO, OPRN_ID/NO/VERS, CHARGE, CUST_ID — Manufacturing context linking the specification version to recipes, formulas, routings, operations, and the customer where applicable.

Common Use Cases and Queries

Typical uses include specification version listings for quality and compliance reporting, batch step control analysis, and integration extracts feeding LIMS or MES systems.

• List all active specification versions for an item, showing decoded control indicators.
• Identify versions where batch step control is enabled for a given recipe or routing.
• Extract COA configuration (COA_TYPE_DISP, COA_AT_SHIP_IND_DISP, COA_AT_INVOICE_IND_DISP) for shipping documentation.

Sample query:

SELECT spec_name, spec_vers, organization_code,
      control_batch_step_ind_disp,
      auto_sample_ind_disp, coa_type_disp
FROM  apps.gmd_qc_e_all_spec_vrs_disp_v
WHERE  inventory_item_id = :item_id
  AND  spec_vr_status = 'ACTIVE';

Because the view already resolves lookup meanings, no additional join to FND_LOOKUP_VALUES is required in the calling query.