Results for “qa_actions”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

QA_ACTIONS is a foundational reference table in the Oracle Quality (QA) module of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. It defines the set of Oracle Quality actions available within the application. Each row in this table represents a discrete action that Quality can execute in response to a collection plan, specification, or results condition — for example, launching a concurrent program, invoking a workflow, sending a notification, or triggering a custom action handler. Because actions are configured independently and then attached to specific quality characteristics and plan characteristics, QA_ACTIONS functions as the shared definition layer for the entire Quality action framework.

From a dimensional modeling perspective, the ETRM metadata classifies this object heuristically as hub-leaning within a Data Vault construct. This classification is a modeling suggestion, not a mandated physical design: QA_ACTIONS behaves as a stable, independent list of business entities, and the two dependent tables observed in the relationship metadata reference it by foreign key rather than the reverse. The table is owned by the QA schema and is validated as of the documented metadata release.

Key Information Stored

The table contains ten documented columns. The surrogate primary key is ACTION_ID, enforced by the unique index QA_ACTIONS_PK. A second unique index, QA_ACTIONS_U1, spans (ACTION_ID, ZD_EDITION_NAME), which represents the business-key candidate for edition-aware retrieval. Because ACTION_ID already serves as the primary key, the composite index exists to support Oracle's Edition-Based Redefinition (EBR) model introduced in 12.2.

• ACTION_ID — Surrogate primary key uniquely identifying each Quality action definition.
• DESCRIPTION — The user-facing name or textual description of the action, presented in the Quality setup and characteristic attachment forms.
• ONLINE_FLAG — Indicates whether the action is applied or executed online, typically during data collection, rather than in a deferred manner.
• ENABLED_FLAG — Indicates whether the action is currently active and selectable for attachment to characteristics and plans.
• ZD_EDITION_NAME — The edition identifier used by Edition-Based Redefinition to isolate online patching changes in 12.2.

Standard EBS WHO columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN — provide the audit trail for each row, allowing administrators and reporting layers to determine when an action definition was created or last modified and by which user or login session.

Common Use Cases and Queries

QA_ACTIONS is most frequently queried during setup validation and when troubleshooting why an expected action did not fire during collection or specification processing. A typical query enumerates all enabled actions for configuration review:

• SELECT action_id, description, online_flag, enabled_flag FROM qa.qa_actions WHERE enabled_flag = 'Y' ORDER BY description;
• Identifying which characteristics reference a given action: SELECT c.characteristic_id, c.action_id FROM qa.qa_char_actions c WHERE c.action_id = :action_id;
• Determining which collection plan characteristics use an action: SELECT p.plan_id, p.char_id, p.action_id FROM qa.qa_plan_char_actions p WHERE p.action_id = :action_id;
• In 12.2 EBR environments, edition-aware reporting filters on ZD_EDITION_NAME to isolate the current edition's definitions.

Reporting use cases include audit reports on configured versus enabled actions and impact analysis before disabling an action that is still attached to active characteristics.

Related Objects

The two documented foreign key relationships reveal the primary consumers of this hub table. QA_CHAR_ACTIONS associates a Quality action with a specific characteristic via ACTION_ID, and QA_PLAN_CHAR_ACTIONS associates the action with a collection plan characteristic via the same column. Together, these tables form the link layer that binds QA_ACTIONS to collection plans and specifications. The unique indexes QA_ACTIONS_PK and QA_ACTIONS_U1 support joins on ACTION_ID and, in EBR environments, joins additionally constrained by ZD_EDITION_NAME. Administrators should treat QA_ACTIONS as the master definition set and manage changes to it with awareness that any disabled or removed action ripples directly into both dependent tables. Oracle Quality's public APIs and the concurrent programs referenced by action definitions complement this table but do not store their definitions within it.