Search Results qa_skiplot_process_plans_pk1




Overview
Explore in AI Chat

Overview

QA_SKIPLOT_PROCESS_PLANS is a Quality Management (QA) module table in Oracle E-Business Suite that stores skip lot process plans. A skip lot process plan defines the sampling strategy used during inspection: it determines how frequently an item or lot is inspected versus skipped, based on a referenced inspection plan and an optional alternate plan. Each row links a specific skip lot process to the plan that governs acceptance and sampling behavior, and it serves as the central definition record around which skip lot state, plan rules, and state history are organized.

In Data Vault terms, the mined foreign key structure suggests a satellite-leaning classification. The table is anchored by the surrogate primary key PROCESS_PLAN_ID, and its foreign keys point outward to parent entities (QA_SKIPLOT_PROCESSES and QA_PLANS), while several child tables reference back to it. This pattern is characteristic of an entity that carries descriptive context and business state transitions rather than serving purely as a join or hub record. Practitioners modeling this object generically should treat it as a satellite with business attributes and relationships.

Key Information Stored

The table is documented with nine columns in the 12.2.2 physical schema. The most significant are:

  • PROCESS_PLAN_ID — the surrogate primary key (QA_SKIPLOT_PROCESS_PLANS_PK1), uniquely identifying each skip lot process plan and serving as the join key for dependent tables. It also appears as a unique index candidate (QA_SKIPLOT_PROCESS_PLANS_U1), a business-key candidate.
  • PROCESS_ID — foreign key to QA_SKIPLOT_PROCESSES, associating the plan with its governing skip lot process.
  • PLAN_ID — foreign key to QA_PLANS, identifying the primary sampling or inspection plan applied.
  • ALTERNATE_PLAN_ID — foreign key to QA_PLANS, identifying an optional secondary plan, typically used when reduced inspection or a fallback strategy applies.
  • LAST_UPDATE_DATE — standard audit column recording the most recent modification timestamp.
  • LAST_UPDATED_BY — user or application that last modified the row.
  • CREATION_DATE — timestamp of row creation.
  • CREATED_BY — user or process that created the row.
  • LAST_UPDATE_LOGIN — login identifier associated with the last update.

The four audit columns are the standard WHO columns common to EBS transactional tables. No other business attributes are documented in the nine-column schema, meaning most descriptive sampling logic resides in the child tables QA_SKIPLOT_PROCESS_PLAN_RULES and QA_SKIPLOT_PLAN_STATES.

Common Use Cases and Queries

Typical use cases include validating that every active skip lot process has both a primary and alternate plan defined, reporting which inspection plans are attached to which skip lot processes, and reconciling plan definitions against their current skip lot states.

  • Joining to the process parent to retrieve process context: SELECT p.PROCESS_PLAN_ID, p.PROCESS_ID, p.PLAN_ID, p.ALTERNATE_PLAN_ID FROM QA.QA_SKIPLOT_PROCESS_PLANS p WHERE p.PROCESS_ID = :process_id;
  • Resolving plan names through QA_PLANS: SELECT pp.PROCESS_PLAN_ID, pl.PLAN_NAME FROM QA.QA_SKIPLOT_PROCESS_PLANS pp JOIN QA.QA_PLANS pl ON pl.PLAN_ID = pp.PLAN_ID;
  • Checking plans configured with an alternate: SELECT PROCESS_PLAN_ID FROM QA.QA_SKIPLOT_PROCESS_PLANS WHERE ALTERNATE_PLAN_ID IS NOT NULL;
  • Auditing recent maintenance: filter on LAST_UPDATE_DATE and LAST_UPDATED_BY to trace who changed plan assignments.

Because the table is a definition-level object, reporting queries frequently aggregate child counts from QA_SKIPLOT_PROCESS_PLAN_RULES and QA_SKIPLOT_PLAN_STATES to summarize rule coverage per plan.

Related Objects

  • QA_SKIPLOT_PROCESSES — parent process definition; joined on QA_SKIPLOT_PROCESS_PLANS.PROCESS_ID.
  • QA_PLANS — sampled on both PLAN_ID and ALTERNATE_PLAN_ID to resolve the primary and alternate inspection plans.
  • QA_SKIPLOT_PLAN_STATES — child table holding current state per plan; referenced via QA_SKIPLOT_PLAN_STATES.PROCESS_PLAN_ID.
  • QA_SKIPLOT_PROCESS_PLAN_RULES — child table defining rule conditions; referenced via QA_SKIPLOT_PROCESS_PLAN_RULES.PROCESS_PLAN_ID.
  • QA_SKIPLOT_STATE_HISTORY — historical audit of state transitions; referenced via QA_SKIPLOT_STATE_HISTORY.PROCESS_PLAN_ID.

Together these objects form the skip lot definition and state model, with QA_SKIPLOT_PROCESS_PLANS acting as the anchor record that ties process, plans, rules, and state history into a coherent inspection strategy.