Results for “trigger_sequence”

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

Overview

The QA_PLAN_CHAR_ACTION_TRIGGERS table is a Quality Management (QA) module object in Oracle E-Business Suite 12.1.1 and 12.2.2. It defines the action triggers configured against a collection plan, specifying the conditions under which an action is fired when a quality characteristic is sampled. Each row represents a single trigger rule — a combination of a plan, a characteristic, a relational operator, and threshold values — that governs whether an associated action should be executed.

The table sits at the intersection of collection plan definition and quality action automation. It is stored in the QA schema and is owned by the Quality product, which is tightly integrated with Oracle Quality collection plans, specifications, and results processing. From a Data Vault modeling perspective, the FK structure suggests a satellite-leaning classification: the table depends heavily on parent entities (QA_PLANS, QA_CHARS) and carries a descriptive set of trigger attributes rather than acting as a pure hub or link. This is a heuristic suggestion; the business-key uniqueness is enforced by the unique index described below.

Key Information Stored

The table contains 17 documented columns in 12.2.2. The most important include:

• PLAN_CHAR_ACTION_TRIGGER_ID — the surrogate primary key and the single-column lead of the primary key constraint QA_PC_ACTION_TRIGGERS_PK.
• PLAN_ID — foreign key to QA_PLANS, identifying the collection plan the trigger belongs to.
• CHAR_ID — foreign key to QA_CHARS, identifying the characteristic evaluated by the trigger.
• TRIGGER_SEQUENCE — ordering of the trigger within the plan/characteristic combination.
• OPERATOR — the relational operator (for example, equals, greater than, between) applied to the sampled value.
• LOW_VALUE_LOOKUP / LOW_VALUE_OTHER / LOW_VALUE_OTHER_ID — the lower-bound threshold, expressed either as a lookup value or a free-form/other value.
• HIGH_VALUE_LOOKUP / HIGH_VALUE_OTHER / HIGH_VALUE_OTHER_ID — the upper-bound threshold, structured the same way as the low-value columns.
• ZD_EDITION_NAME — the editioning column that supports Online Patching (adopted in 12.2), included in the unique index QA_PC_ACTION_TRIGGERS_U1 alongside PLAN_CHAR_ACTION_TRIGGER_ID.
• Standard audit columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.

The unique index QA_PC_ACTION_TRIGGERS_U1 is the documented business-key candidate. Note that both the surrogate PK and the audit columns are present, so queries should be aware of the editioning constraint in 12.2.

Common Use Cases and Queries

Typical usage centers on interrogating which triggers are configured for a given plan or characteristic, and how thresholds are set. A common query joins the plan and characteristic names:

• Listing all triggers for a collection plan: SELECT trigger_sequence, char_id, operator, low_value_lookup, high_value_lookup FROM qa_plan_char_action_triggers WHERE plan_id = :plan_id ORDER BY trigger_sequence;
• Auditing the actions that will fire: join to QA_PLAN_CHAR_ACTIONS on PLAN_CHAR_ACTION_TRIGGER_ID to retrieve the actions linked to each trigger.
• Comparing threshold configuration across characteristics by joining to QA_CHARS on CHAR_ID.
• Reporting on triggers modified within a date range using LAST_UPDATE_DATE for change-tracking.

Because triggers drive automated quality actions, reporting from this table is useful when validating that sampling rules are enforced correctly after a plan revision or migration.

Related Objects

The most significant related objects are:

• QA_PLANS — joined on PLAN_ID; parent collection plan.
• QA_CHARS — joined on CHAR_ID; the characteristic evaluated.
• QA_PLAN_CHAR_ACTIONS — references this table via PLAN_CHAR_ACTION_TRIGGER_ID; holds the actions triggered.
• QA_PC_ACTION_TRIGGERS_PK and QA_PC_ACTION_TRIGGERS_U1 — the primary key constraint and unique index (including ZD_EDITION_NAME).
• Standard QA results and specification tables that consume trigger definitions during results processing.

Together these objects form the QA collection plan action-trigger chain, with this table acting as the rule-bearing satellite between plans, characteristics, and actions.