Results for “spec_element_value”

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

Overview

QA_SPECS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered with the Quality (QA) product family. Its documented description is simply "Shows all specifications," and it presents specification header data from the QA_SPECS base table enriched with decoded meanings, item, vendor, customer, and category set attributes. The view is exposed in the ETRM reference for 12.1.1 and 12.2.2 with status VALID.

Because it consolidates columns from quality, inventory, purchasing, and receivables master data into a single flat structure, the view serves as a convenient read-only source for specification inquiry screens, custom reports, and interface extracts that need specification context without duplicating multi-table joins. It is the specification analogue of the sampling and collection views in the QA schema and is not intended for direct DML.

Underlying Base Objects

The view text selects from QA_SPECS (aliased QS) joined against lookups, category sets, item and party entities. The documented base objects are:

• QA_SPECS (synonym) — the driving specification table, containing spec name, status, assignment type, and the HIDE_PLAN_CHARS_FLAG column referenced in the user's search.
• QA_CHARS (synonym) — joined to provide spec element name, data type, values-exists flag, decimal precision, and SQL validation string.
• MTL_CATEGORY_SETS_B / MTL_CATEGORY_SETS_TL (synonyms) — supply category set structure, validation flag, name, and description.
• MTL_SYSTEM_ITEMS_B / MTL_SYSTEM_ITEMS_TL (synonyms) — provide item description and the REVISION_QTY_CONTROL_CODE used as REV_CONTROL_FLAG.
• AP_SUPPLIERS (synonym) — provides the vendor number via SEGMENT1.
• HZ_PARTIES and HZ_CUST_ACCOUNTS (synonyms) — supply vendor party name, customer account number, and customer name.
• MFG_LOOKUPS (view) — decoded multiple times (ML2, ML3, ML4) to translate assignment type, HIDE_PLAN_CHARS_FLAG, and specification status into user-facing meanings.

Note that the view text also references a self-join against QA_SPECS (aliased QS2) to resolve the common specification name. Because the underlying objects are APPS synonyms, the view resolves against the standard QA, INV, PO, and AR base tables in a properly configured environment.

Key Columns

• SPEC_ID, SPEC_NAME, SPEC_STATUS — identity, display name, and workflow/approval status of the specification.
• ORGANIZATION_ID, EFFECTIVE_FROM, EFFECTIVE_TO — inventory organization and effective date range of the specification.
• COMMON_SPEC_ID, COMMON_SPEC_NAME — self-referenced common specification for inherited specs.
• ASSIGNMENT_TYPE, ASSIGNMENT_TYPE_MEANING — the assignment scope (item, category, vendor, customer, or blank) with its decoded meaning.
• CATEGORY_SET_ID, CATEGORY_ID, ITEM_ID, ITEM_REVISION, VENDOR_ID, CUSTOMER_ID, CHAR_ID — the assignment targets; sentinel values of -1 are decoded to NULL to indicate "not applicable."
• SPEC_ELEMENT, DATATYPE, SPEC_ELEMENT_VALUE, VALUES_EXIST_FLAG, SQL_STRING_FLAG, DECIMAL_PRECISION — characteristics of the specification element.
• HIDE_PLAN_CHARS_FLAG and HIDE_PLAN_CHARS_MEANING — the flag (and its lookup meaning) that governs whether planning characteristics are suppressed when the specification is applied, the column that prompted the user's search.
• VENDOR_NUMBER, VENDOR_NAME, CUSTOMER_NUMBER, CUSTOMER_NAME — party attributes for vendor- and customer-assigned specifications.
• CAT_SET_VALIDATE_FLAG, CATEGORY_SET_NAME, CATEGORY_SET_DESCRIPTION — category set metadata for category-assigned specifications.
• ROW_ID — the ROWID of the underlying QA_SPECS row, useful for row-level identification in forms and DML.

Common Use Cases and Queries

Typical uses include specification inquiry lists, planning-characteristic configuration audits, and extracts feeding quality reporting. The following query lists specifications whose planning characteristics are hidden:

• SELECT spec_id, spec_name, organization_id, hide_plan_chars_flag, hide_plan_chars_meaning FROM qa_specs_v WHERE hide_plan_chars_flag = 'Y' ORDER BY spec_name;
• SELECT spec_name, assignment_type_meaning, item_description, vendor_name, customer_name, effective_from, effective_to FROM qa_specs_v WHERE assignment_type_meaning IS NOT NULL;
• SELECT spec_name, spec_element, datatype, spec_element_value, values_exist_flag FROM qa_specs_v WHERE organization_id = :org_id AND spec_status = :status;
• SELECT s.spec_name, s.category_set_name, s.validate_flag FROM qa_specs_v s WHERE s.category_id IS NOT NULL;

Queries should always filter by ORGANIZATION_ID or SPEC_ID to avoid full scans, and consumers should rely on the decoded _MEANING columns rather than lookup codes for reporting. Because the view joins several base tables, it is read-only and should not be used as a DML target.