Search Results qa_plans




Overview
Explore in AI Chat

Overview

The QA_PLANS table is the central repository for collection plan definitions within the Oracle E-Business Suite (EBS) Quality Management (QA) module, in both versions 12.1.1 and 12.2.2. A collection plan is a core configuration object that defines the structure for quality data collection. It specifies what characteristics to inspect, the acceptable values, sampling rules, and any associated actions. This table stores the master definition of these plans, which are then executed to collect results for items, processes, suppliers, or customers. Its role is foundational, as it acts as the parent entity for all plan-specific configurations and collected quality data, enabling systematic quality control across manufacturing, service, and maintenance operations.

Key Information Stored

While the provided metadata does not list individual columns, the primary key is documented as PLAN_ID. This unique identifier is the critical column, referenced extensively by foreign keys throughout the Quality schema and integrated applications. Based on its role as a definition table, it typically stores descriptive and control attributes for a collection plan. Common columns in such a table include PLAN_NAME, DESCRIPTION, EFFECTIVE_DATE, DISABLE_DATE, PLAN_TYPE (e.g., inspection, test), STATUS, and various creation and last update audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE). The PLAN_ID is the essential link to all detailed plan components and execution data.

Common Use Cases and Queries

This table is primarily accessed for administrative configuration, integration reporting, and data integrity validation. Common scenarios include identifying all active collection plans, tracing quality data back to its source definition, or analyzing plan usage across modules. A frequent query pattern retrieves plan details along with basic audit information. For instance, to list all enabled plans, one might use:

SELECT plan_id, plan_name, description, creation_date
FROM qa.qa_plans
WHERE disable_date IS NULL OR disable_date > SYSDATE
ORDER BY plan_name;

Another critical use case involves joining QA_PLANS with child tables like QA_RESULTS or QA_PLAN_CHARS to generate reports that correlate collected quality results with the original plan specifications and characteristics. Troubleshooting data issues often requires verifying the existence and status of a PLAN_ID referenced in transactional tables.

Related Objects

The QA_PLANS table has extensive relationships, as evidenced by the foreign key metadata. Key dependent objects within the QA schema include:

  • QA_PLAN_CHARS: Stores the inspection characteristics defined for a plan.
  • QA_RESULTS: Holds the actual data values collected during plan execution.
  • QA_CRITERIA_HEADERS: Links specification limits to collection plans.
  • QA_PLAN_TRANSACTIONS: Tracks transactions performed against a plan.
  • QA_PC_PLAN_RELATIONSHIP: Manages hierarchical relationships between parent and child plans.
Furthermore, its integration is broad, with foreign keys from tables in other EBS modules such as: This demonstrates that collection plans defined in QA_PLANS are central to quality processes in manufacturing, service, and asset maintenance workflows.