Search Results import_view_name

Overview

QA_PLANS is the master definition table for collection plans in the Oracle E-Business Suite Quality (QA) module. A collection plan specifies what data Oracle Quality collects, when that data is captured, how it is validated against specification limits, and what actions are triggered on failure. The table resides in the QA schema and stores both the header-level metadata of each plan (name, description, type, effective dating) and the view bindings that determine which transactions and columns the plan is associated with. It is central to quality data collection across manufacturing, receiving, inventory, order management, and service workflows, and is one of the highest-volume reference points in the QA data model.

Because QA_PLANS is referenced by a large number of dependent tables through the PLAN_ID column and holds no foreign key to another hub in the provided metadata, it is best modeled as a Data Vault hub. PLAN_ID serves as the business key surrogate around which links (plan-to-characteristic, plan-to-transaction, plan-to-specification associations) and satellites (descriptive attributes, effective dating, audit columns) can be organized. Older releases of the QA schema used a ZD_EDITION_NAME column for editioning, and this is preserved in the 12.2.2 physical schema.

Key Information Stored

The primary key is QA_PLANS_PK, defined on PLAN_ID, a system-generated surrogate identifier. Two unique indexes act as business-key candidates: QA_PLANS_U1 (PLAN_ID, ZD_EDITION_NAME) and QA_PLANS_U2 (NAME, ZD_EDITION_NAME), confirming that NAME is unique per edition within the schema. The table contains 39 documented columns, of which the most operationally significant are:

• PLAN_ID — surrogate primary key and the join key used by all dependent QA tables.
• NAME and DESCRIPTION — user-facing identifier and free-text purpose of the collection plan.
• PLAN_TYPE_CODE — classifies the plan (for example, collection versus action plan), driving downstream behavior.
• ORGANIZATION_ID — the inventory organization in which the plan is visible; null values typically denote global plans.
• EFFECTIVE_FROM and EFFECTIVE_TO — date range during which the plan is active for data collection.
• SPEC_ASSIGNMENT_TYPE — controls how specification limits are assigned to plan characteristics.
• VIEW_NAME and DEREF_VIEW_NAME — the database views that expose the transaction data collected by the plan.
• IMPORT_VIEW_NAME — the view used when importing results into the plan.
• INSTRUCTIONS — operator-facing guidance shown during data collection.
• TEMPLATE_PLAN_ID — self-referencing pointer when the row was copied from a template plan.
• ESIG_MODE and JRAD_DOC_VER / JRAD_UPGRADE_VER — electronic signature mode and Oracle Application Object Library document version columns used to enforce e-signature compliance.
• MULTIROW_FLAG — indicates whether the plan permits multiple results rows per transaction.
• ZD_EDITION_NAME — editioning column supporting online patching in 12.2.x.
• Standard audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and the fifteen ATTRIBUTE1–ATTRIBUTE15 DFF slots.

Common Use Cases and Queries

Typical reporting scenarios include listing all active collection plans for an organization, auditing which plans have no characteristics attached, and reconciling plan definitions between environments.

• Retrieve active plans for an inventory org:

  SELECT plan_id, name, plan_type_code, effective_from, effective_to
  FROM   qa.qa_plans
  WHERE  organization_id = :org_id
  AND    SYSDATE BETWEEN NVL(effective_from, SYSDATE)
                     AND NVL(effective_to, SYSDATE);

• Find plans whose NAME matches a user search across editions:

  SELECT plan_id, name, description
  FROM   qa.qa_plans
  WHERE  UPPER(name) LIKE UPPER('%'||:keyword||'%');

• Identify plans without associated characteristics (data quality check):

  SELECT p.plan_id, p.name
  FROM   qa.qa_plans p
  WHERE  NOT EXISTS (SELECT 1 FROM qa.qa_plan_chars c WHERE c.plan_id = p.plan_id);

• Results volume by plan for trend analysis:

  SELECT p.name, COUNT(*) results_count
  FROM   qa.qa_plans p, qa.qa_results r
  WHERE  p.plan_id = r.plan_id
  GROUP  BY p.name
  ORDER  BY results_count DESC;

These patterns are frequently used in custom QA extracts, data-migration validation, and audit reports delivered outside the standard Oracle Quality windows.

Related Objects

QA_PLANS is heavily referenced. The most significant dependent objects, with their documented join columns, are:

• QA_PLAN_CHARS (PLAN_ID) — defines each characteristic collected by the plan; the primary child table for data-collection structure.
• QA_RESULTS (PLAN_ID) — stores collected result values for the plan.
• QA_CRITERIA_HEADERS (PLAN_ID) — specification limits and validation criteria tied to plan characteristics.
• QA_PLAN_TRANSACTIONS (PLAN_ID) — associates the plan with source transactions (which rows/columns the plan collects).
• QA_PC_PLAN_RELATIONSHIP (PARENT_PLAN_ID, CHILD_PLAN_ID) — parent-child hierarchy of plans and sub-plans.
• QA_PC_RESULTS_RELATIONSHIP (PARENT_PLAN_ID, CHILD_PLAN_ID) — results linkage across parent and child plans.
• QA_PLAN_CHAR_ACTION_TRIGGERS (PLAN_ID) — actions executed when characteristic values meet trigger conditions.
• QA_ACTION_LOG (PLAN_ID) — audit trail of actions fired by the plan.
• QA_GRANTED_PRIVILEGES (PLAN_ID) — security grants controlling which users can collect against the plan.
• QA_SAMPLING_ASSOCIATION (COLLECTION_PLAN_ID) — links sampling plans to the collection plan.
• QA_SKIPLOT_PROCESS_PLANS (PLAN_ID, ALTERNATE_PLAN_ID) — used in skip-lot supplier quality processing.
• AHL_OPERATIONS_B, AHL_ROUTES_B, AHL_WORKORDERS, AHL_MR_ACTIONS_B — Oracle Complex Maintenance, Repair, and Overhaul (eAM/CMRO) references that bind maintenance operations and routes to their QA plan.
• CS_INCIDENTS_ALL_B (QA_COLLECTION_ID) — Service module incidents that reference the collection plan.

Because every dependent row carries PLAN_ID, deleting or renumbering a plan is generally restricted by these foreign keys; implementation scripts should rely on the collection-plan DDF/API rather than direct DML against QA_PLANS.