Search Results qa_plan_transactions_s

Overview

QA_PLANS_PUB is the public PL/SQL API package for Oracle Quality plan definitions in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes the collection plan maintenance operations that Oracle Quality forms, concurrent programs, and external integration code use to create, copy, modify, and remove collection plans and their constituent plan elements. The package acts as the supported public entry point (API classification PUB) over the underlying QA_PLANS_API and QA_PLAN_ELEMENT_API layers, applying validation, security, and message handling before delegating to the private implementation packages. It is owned by the APPS schema and carries a VALID status in both releases; the object inventory is functionally identical between 12.1.1 and 12.2.2, so the summary below applies to either version.

Key Procedures and Functions

• CREATE_COLLECTION_PLAN — Creates a new collection plan header together with its associated plan definition attributes, returning the identifiers required for subsequent plan element and characteristic setup.
• ADD_PLAN_ELEMENT — Adds a plan element (a specification, characteristic, or action line) to an existing collection plan.
• DELETE_PLAN_ELEMENT — Removes a previously defined plan element from a collection plan.
• DELETE_COLLECTION_PLAN — Deletes a collection plan and its dependent definition rows, subject to the standard Oracle Quality deletion rules.
• COPY_COLLECTION_PLAN — Duplicates an existing collection plan, including its elements, to accelerate creation of similar plans.
• COMPLETE_PLAN_PROCESSING — Finalizes plan definition processing, performing the post-maintenance steps that make a plan complete and usable for data collection.
• GET_PLAN_TYPE — Returns the plan type classification for a given collection plan.
• GET_PLAN_VIEW_NAME — Returns the name of the database view that exposes a collection plan's collected results.
• GET_IMPORT_VIEW_NAME — Returns the name of the view used when importing or loading data into the plan structure.

No parameter signatures are documented in the ETRM metadata; callers should consult the package specification for exact argument lists.

Tables Accessed

The package reads and writes the core Oracle Quality tables through APPS synonyms. QA_PLANS and QA_PLANS_S hold the plan header and its translation rows; QA_PLAN_CHARS stores the plan-level characteristics; QA_PLAN_CHAR_ACTIONS, QA_PLAN_CHAR_ACTION_OUTPUTS, and QA_PLAN_CHAR_ACTION_TRIGGERS define the actions, outputs, and triggering conditions attached to those characteristics; QA_PLAN_CHAR_VALUE_LOOKUPS and QA_PLAN_CHAR_ACTION_TRIGGERS_S supply lookup and translation support. QA_PLAN_TRANSACTIONS and QA_PLAN_TRANSACTIONS_S capture plan transactions, while QA_PLAN_COLLECTION_TRIGGERS and QA_TXN_TRIGGER_IDS_S record collection trigger definitions. QA_CHAR_INDEXES and QA_CHAR_INDEXES_PKG relate to characteristic indexing, QA_DEVICE_INFO supports device integration, and QA_RESULTS holds collected quality results. Oracle Alert integration is served by ALR_ACTIONS, ALR_ACTIONS_S, ALR_ACTION_SETS, ALR_ACTION_SETS_S, and ALR_ACTION_SET_MEMBERS(_S), with QA_ALR_ACTION_NAME_S and QA_ALR_ACTION_SET_NAME_S providing Quality-specific alert name translations. FND_LOOKUP_VALUES and FND_USER supply lookup and user validation, and PO_LOOKUP_CODES is referenced for shared lookup values.

Usage Notes

QA_PLANS_PUB is the standard integration surface for collection plan maintenance. Oracle Quality setup forms invoke it when a user defines or copies a collection plan, and concurrent programs and import routines rely on the GET_IMPORT_VIEW_NAME accessor to resolve target views. Custom code should call the public procedures rather than writing directly to the underlying tables, because the API applies FND_API error handling, FND_MSG_PUB message stacking, and FND_GLOBAL session context. The package has no dependent database objects (nothing references it) but is itself referenced by one other package. Error conditions are surfaced through the standard FND message stack, and multi-lingual data is handled via the _S translation tables and FND_LOOKUP_VALUES.