Search Results qa_skiplot_processes_pk1

Overview

QA_SKIPLOT_PROCESSES is the header table for Oracle EBS Quality Management's skip lot inspection functionality. It defines the rules by which a receiving or in-process inspection can be periodically skipped for a supplier, item, or combination thereof, once quality performance has been demonstrated to be stable. The table's PROCESS_ID acts as the surrogate primary key (QA_SKIPLOT_PROCESSES_PK1), and each row describes a named skip lot process, the inventory organization in which it is valid, and the disqualification thresholds that return an item to full inspection if a defect occurs.

The ETRM metadata classifies this object heuristically as hub-leaning within a Data Vault model. In practice, QA_SKIPLOT_PROCESSES behaves as a hub: it holds the durable business identity of a skip lot process (PROCESS_ID, PROCESS_CODE), while its children — QA_SKIPLOT_ASSOCIATION and QA_SKIPLOT_PROCESS_PLANS — act as link and satellite structures that attach the process to suppliers, items, and inspection plans. Treat this as a modeling suggestion rather than a mandated design.

Key Information Stored

Only the following columns are documented in the ETRM 12.2.2 physical schema (11 total). The most significant are:

• PROCESS_ID — surrogate primary key; system-generated identifier for the skip lot process. Also exposed as unique index QA_SKIPLOT_PROCESSES_U1.
• PROCESS_CODE — user-visible business key; a unique, meaningful code that identifies the process (unique index QA_SKIPLOT_PROCESSES_U2).
• DESCRIPTION — free-text description of the process, typically used in list-of-values and reports.
• ORGANIZATION_ID — the inventory organization in which the skip lot process applies; essential for multi-org filtering.
• DISQUALIFICATION_LOTS — number of consecutive defective lots (or occurrences) that disqualify the process and force reversion to normal inspection.
• DISQUALIFICATION_DAYS — the time window (in days) over which disqualification criteria are evaluated.
• Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, which support concurrency control and audit trail reporting.

The two unique indexes establish PROCESS_ID as the technical key and PROCESS_CODE as the candidate business key. In a Data Vault view, PROCESS_CODE is the natural business key that would anchor the hub, while the remaining descriptive and threshold attributes would be carried as satellite context.

Common Use Cases and Queries

Typical reporting scenarios include auditing which organizations have skip lot processes defined, verifying thresholds, and tracing which suppliers or items are associated with each process. A standard lookup by business key is:

• SELECT PROCESS_ID, PROCESS_CODE, DESCRIPTION, ORGANIZATION_ID, DISQUALIFICATION_LOTS, DISQUALIFICATION_DAYS FROM QA.QA_SKIPLOT_PROCESSES WHERE ORGANIZATION_ID = :org_id;
• Threshold review: SELECT PROCESS_CODE, DISQUALIFICATION_LOTS, DISQUALIFICATION_DAYS FROM QA.QA_SKIPLOT_PROCESSES WHERE ORGANIZATION_ID = :org_id ORDER BY PROCESS_CODE;
• Association join: SELECT p.PROCESS_CODE, a.* FROM QA.QA_SKIPLOT_PROCESSES p, QA.QA_SKIPLOT_ASSOCIATION a WHERE p.PROCESS_ID = a.PROCESS_ID;
• Plan join: SELECT p.PROCESS_CODE, pl.* FROM QA.QA_SKIPLOT_PROCESSES p, QA.QA_SKIPLOT_PROCESS_PLANS pl WHERE p.PROCESS_ID = pl.PROCESS_ID;

These queries support QA administration dashboards, supplier scorecards, and audit readiness checks confirming that skip lot rules are configured consistently across inventory organizations.

Related Objects

The documented foreign key relationships identify the child tables that depend on QA_SKIPLOT_PROCESSES. The most significant related objects are:

• QA_SKIPLOT_ASSOCIATION — joins via PROCESS_ID; links the skip lot process to specific suppliers, items, or supplier-item combinations.
• QA_SKIPLOT_PROCESS_PLANS — joins via PROCESS_ID; attaches inspection plans and sampling details to the process.
• The originating EBS application tables (suppliers, items, and inspection plans in the PO, INV, and QA modules) that the association and plan tables in turn reference indirectly through the PROCESS_ID linkage.

With only two direct child tables documented, QA_SKIPLOT_PROCESSES is a relatively compact hub. Consumers should treat PROCESS_ID as the join key across all dependent tables and use PROCESS_CODE for user-facing lookups and cross-references.