Search Results qa_results_pk

Overview

QA.QA_RESULTS is the central transactional repository for quality results data in Oracle E-Business Suite Quality (QA). Each row records the outcome of an inspection, test, or data-collection event executed against a quality plan, associating the captured readings with the transaction, item, organization, and business entity that produced them. The table is populated when a collection plan is executed in Oracle Quality — from receiving inspections, work-in-process checks, discrete and process manufacturing operations, service and repair events, or ad hoc data collection — and it is the principal source for quality analytics, nonconformance tracking, and disposition processing.

Given the extensive foreign-key footprint spanning manufacturing, purchasing, order management, service, and customer master tables, the object behaves as a broad integration fact. Mined from its FK structure, the heuristic Data Vault classification is satellite-leaning; a modeling exercise would typically treat QA_RESULTS as a satellite (or a link-satellite combination) attached to the collection plan and occurrence business keys, with numerous secondary links to the referenced operational entities. This is a suggestion rather than a documented Oracle construct.

Key Information Stored

QA_RESULTS is a wide table of 236 documented columns in release 12.2.2. The surrogate primary key is QA_RESULTS_PK, defined over (COLLECTION_ID, OCCURRENCE). Two unique indexes act as business-key candidates: QA_RESULTS_U1 (PLAN_ID, COLLECTION_ID, OCCURRENCE) and QA_RESULTS_U2 (PLAN_ID, OCCURRENCE). PLAN_ID therefore anchors a result to the collection plan, while OCCURRENCE distinguishes repeated executions of the same plan.

• COLLECTION_ID / OCCURRENCE — composite surrogate identifier for a single result row.
• PLAN_ID — the collection plan under which the result was captured; the primary business key.
• SPEC_ID — the specification used to evaluate the result.
• ORGANIZATION_ID — the inventory organization in which the inspection occurred.
• ITEM_ID / REVISION / LOT_NUMBER / SERIAL_NUMBER — the item and its controlled attributes under inspection.
• QUANTITY / UOM — quantity inspected and its unit of measure.
• WIP_ENTITY_ID / LINE_ID / FROM_OP_SEQ_NUM / TO_OP_SEQ_NUM — work order, line, and operation context for shop-floor collections.
• VENDOR_ID / RECEIPT_NUM / PO_HEADER_ID / PO_RELEASE_ID — supplier and purchasing context for receiving inspections.
• CUSTOMER_ID / SO_HEADER_ID / RMA_HEADER_ID — customer and order-management context.
• TRANSACTION_ID / TRANSACTION_NUMBER / TRANSACTION_DATE — the originating transaction and timestamp.
• NONCONFORMANCE_SOURCE, NONCONFORMANCE_TYPE, NONCONFORMANCE_CODE, NONCONFORM_SEVERITY, NONCONFORM_PRIORITY — nonconformance classification of the result.
• DISPOSITION / DISPOSITION_ACTION / DISPOSITION_STATUS — disposition outcome applied to the affected material.
• DATE_OPENED / DATE_CLOSED / DAYS_TO_CLOSE — handling lifecycle metrics.
• CHARACTER1 … CHARACTER100, SEQUENCE1 … SEQUENCE15, COMMENT1 … COMMENT5 — the flexible, plan-defined result attributes where actual collection values reside.
• STATUS / REQUEST_STATUS — workflow status of the result and its request record.

Common Use Cases and Queries

The dominant reporting use is quality performance analysis: first-pass yield, defect Pareto, and nonconformance aging. Because flexible values are stored generically, queries join QA_RESULTS to the collection-plan metadata (QA_RESULTS_VIEW definitions via QA_PLANS) to resolve CHARACTERn columns to named collection elements.

• Result counts by plan and organization for a date range.
• Nonconformance extracts filtered on NONCONFORMANCE_SOURCE, NONCONFORM_SEVERITY, and DATE_OPENED.
• Disposition aging: SELECT COLLECTION_ID, OCCURRENCE, DAYS_TO_CLOSE FROM QA.QA_RESULTS WHERE DATE_CLOSED IS NULL AND DATE_OPENED < SYSDATE - 30;
• Receiving inspection traceability joining VENDOR_ID, RECEIPT_NUM, and PO_HEADER_ID.
• WIP defect analysis joining WIP_ENTITY_ID and LINE_ID to WIP_ENTITIES and WIP_LINES.

Queries should be restricted by PLAN_ID and organization to exploit QA_RESULTS_U1/U2 rather than scanning the full table.

Related Objects

• QA_PLANS — QA_RESULTS.PLAN_ID references the defining collection plan.
• QA_SPECS — QA_RESULTS.SPEC_ID references the specification applied to results.
• QA_PC_RESULTS_RELATIONSHIP — parent/child result relationships via PARENT_COLLECTION_ID/PARENT_OCCURRENCE and CHILD_COLLECTION_ID/CHILD_OCCURRENCE.
• MTL_SYSTEM_ITEMS_B — ITEM_ID, ASSET_GROUP_ID, and ASSET_ACTIVITY_ID resolve to inventory items.
• WIP_ENTITIES / WIP_LINES — WORK_ORDER_ID, WIP_ENTITY_ID, and LINE_ID link results to shop-floor work.
• PO_RELEASES_ALL and PO_VENDORS — supplier-side sourcing context.
• RA_CUSTOMERS / HZ_PARTIES — customer and party attribution.
• BOM_DEPARTMENTS / BOM_RESOURCES — DEPARTMENT_ID and RESOURCE_ID reference routing components.
• FND_USER — QA_CREATED_BY identifies the collecting user.