QA Collection Plan Transactions – Oracle EBS SQL Report

Oracle E-Business Suite SQL report from the Enginatics Library powered by Blitz Report™. Oracle EBS module: Quality · all Quality reports

Overview

Every collection transaction an Oracle Quality collection plan is attached to, with the trigger conditions that decide whether collection actually fires, the Mandatory Collection, Background Collection and Enabled flags, and each trigger’s field, database field, datatype, operator and low and high values. Attachments that collect unconditionally are listed too, with a blank Collection Trigger.

Attaching a collection plan to a transaction is what makes Oracle Quality collect anything at all: until a plan is attached to a transaction such as Receiving Transactions or Completion Transactions it is only a definition, and nothing is ever collected against it. Trigger conditions narrow that further, so the attachment on its own does not tell you when collection happens - a plan attached to Completion Transactions with a trigger of Item equals a single assembly collects for that assembly and no other. Mandatory Collection means the transaction cannot be saved without quality results, and Background Collection means results are collected without prompting the operator.

A plan can be attached to the same transaction more than once, each attachment carrying its own trigger conditions. Transaction Attachments counts how many attachments the plan has for that transaction, so one attachment with several triggers can be told apart from several separate attachments. Trigger Field is the form prompt the trigger tests and Trigger Database Field is the column behind it, both taken from the transaction’s own trigger list in qa_txn_collection_triggers, so a condition can be traced from the prompt an implementer sees to the column a data load has to supply.

Leave the parameters blank for the full picture, or narrow with Organization, Collection Plan, Plan Type, Transaction and Collection Trigger. Mandatory Collection Only and Enabled Transactions Only restrict to attachments carrying those flags. Leaving Organization blank returns every collection plan the responsibility has inventory organization access to, plus the seeded template plans, which are not owned by an inventory organization and therefore show a blank Organization Code.

Run this report in Excel in seconds: download Blitz Report™ free (your first 30 reports are free) or try it in the online demo.

Report Parameters

Organization, Collection Plan, Plan Type, Transaction, Collection Trigger, Mandatory Collection Only, Enabled Transactions Only

Oracle EBS Tables Used

qa_plan_transactions, qa_txn_collection_triggers, qa_plans, mtl_parameters, qa_plan_collection_triggers, qa_chars, org_access_view

Report Categories

Enginatics

QA Collection Plans, QA Collection Plan Actions, QA Collection Plan Upload, QA Quality Results, QA Collection Plan Elements, QA Collection Plan Relationships, QA Collection Plan Element Values, FND Attached Documents

Running This SQL Without Blitz Report

The SQL source can be run in any SQL client. Some Oracle EBS SQL reports in this library use functions from the utility package xxen_util – install it first. Blitz Report™ adds parameters, Excel output with pivots, scheduling and security on top.

Download & Import Options

Resource Link
Excel Example Output QA Collection Plan Transactions 14-Aug-2026 112113.xlsx
Blitz Report™ XML Import QA_Collection_Plan_Transactions.xml
SQL Source QA Collection Plan Transactions.sql
Full Report on Enginatics www.enginatics.com/reports/qa-collection-plan-transactions/

Case Study & Technical Analysis: QA Collection Plan Transactions

Executive Summary

The QA Collection Plan Transactions report shows every transaction that an Oracle Quality collection plan is attached to, together with the trigger conditions that decide whether collection fires. It is written for quality engineers and Oracle Quality administrators who need to know when a collection plan actually collects results, for example on receiving or completion transactions. A plan attached to a transaction is only a definition until the attachment exists, and each trigger narrows the collection further, so the report shows both layers. For each attachment it returns the mandatory, background and enabled flags, and for each trigger the field, database column, datatype, operator and values. It sits in the Quality module.

Business Challenge

The Solution

Technical Architecture (High Level)

Primary Tables

Logical Relationships

  1. QA_PLANS joins to MTL_PARAMETERS as an outer join on the organisation identifier.
  2. QA_PLANS joins to QA_PLAN_TRANSACTIONS on the plan identifier.
  3. Each attachment joins to QA_PLAN_COLLECTION_TRIGGERS as an outer join on the plan transaction identifier, so unconditional attachments are kept.
  4. Each trigger joins to QA_CHARS as an outer join on the trigger identifier, to give the element name and datatype.
  5. The trigger’s form description and database field are read from QA_TXN_COLLECTION_TRIGGERS by transaction number and trigger identifier, through scalar subqueries.
  6. Results are ordered by organisation, plan name, transaction name, attachment identifier and element name.

Parameters & Filtering

Performance & Optimization

FAQ

Q: Why does my collection plan not collect results for a transaction? A: The plan must be attached to the transaction, and its trigger conditions must match the transaction. The report shows both the attachment and the trigger conditions.

Q: What does Mandatory Collection mean for an operator? A: The description states that the transaction cannot be saved without quality results when Mandatory Collection is set.

Q: How do I trace a trigger condition to the column a data load must supply? A: Read the Trigger Field, which is the form prompt, and the Trigger Database Field, which is the column behind it, on the same row.

© Enginatics GmbH