Search Results qa_enabled

Overview

QA_TXN_GRP is a grouping (GRP-classified) PL/SQL package in the APPS schema that supports the Oracle Quality transaction processing framework in Oracle E-Business Suite 12.1.1 and 12.2.2. It provides the low-level engine responsible for creating, evaluating, and persisting quality results against collections and plans as transactions are processed. In practice, QA_TXN_GRP acts as the bridge between a triggering business event — a manufacturing or receiving transaction, a batch move, or a web-entered quality transaction — and the Quality results tables that record specifications, character readings, and collection occurrence data.

The package is a foundational dependency for several higher-level APIs and processing modules. Within the same module family, QA_MQA_MWA_API, QA_WEB_TXN_API, QA_PARENT_CHILD_PKG, and QA_SS_PARENT_CHILD_PKG all reference QA_TXN_GRP, and external modules such as CSD_PROCESS_PVT, WIP_BATCH_MOVE, and WSMPLBMI also depend on it. This broad dependency footprint confirms that QA_TXN_GRP is not an end-user entry point but a shared service routine invoked by numerous Quality and manufacturing flows.

Key Procedures and Functions

The ETRM metadata documents approximately 47 procedures and functions. The following are named in the documented metadata; their purposes are summarized without asserting specific signatures.

• QA_ENABLED — Determines whether Quality processing is enabled for the current context, typically used as a gate before further transaction processing is attempted.
• COMMIT_ALLOWED — Indicates whether the package may perform an implicit commit at the current point in the business flow, protecting callers that must remain within a single transaction boundary.
• GET_COLLECTION_ID — Retrieves the collection identifier associated with a transaction or plan, using the QA_COLLECTION_ID_S sequence where a new identifier is required.
• RESULT_TO_ARRAY — Converts a quality result record into an array structure for bulk processing or for consumption by calling APIs.
• EVALUATE_TRIGGERS — Evaluates the collection triggers defined for a plan to determine whether a collection should be created or processed for the current transaction.
• INSERT_RESULTS — Inserts quality results into the QA_RESULTS table, forming the core write path of the package.
• POST_BACKGROUND_RESULTS and EAM_POST_BACKGROUND_RESULTS — Post results originating from background or deferred processing, including Enterprise Asset Management contexts.
• GET_PLAN_NAMES — Returns the plan names applicable to a given transaction context.
• RELATE_RESULTS — Establishes relationships between result records, writing to the parent/child relationship structures used by the Quality module.
• CLEAR_CUSTOMS — Resets the descriptive flexfield custom attribute values held by the package's internal state.
• PUT_CUSTOM1 through PUT_CUSTOM9 — Populate the nine descriptive flexfield custom segments used by the Quality results tables.

Tables Accessed

QA_TXN_GRP reads and writes a defined set of Quality tables through APPS synonyms, along with DUAL and the PL/SQL table type PLITBLM. The core results path touches QA_RESULTS, QA_OCCURRENCE_S, QA_COLLECTION_ID_S, and QA_PC_RESULTS_RELATIONSHIP, which together hold result values, occurrence identifiers, collection identifiers, and parent/child result linkages. Plan and trigger configuration is read from QA_PLANS, QA_PLAN_CHARS, QA_PLAN_TRANSACTIONS, and QA_PLAN_COLLECTION_TRIGGERS. Specification and character definitions are read from QA_CHARS, and intermediate or bulk result handling uses QA_PERFORMANCE_TEMP.

Usage Notes

QA_TXN_GRP is normally invoked indirectly. Oracle Quality forms and the Quality web transactions API call into it during transaction entry and processing, and concurrent programs that post background results depend on POST_BACKGROUND_RESULTS and its EAM counterpart. Manufacturing and shipping flows such as WIP_BATCH_MOVE and WSMPLBMI reach the package through their own processing logic. Because the package is a shared dependency of public APIs including QA_WEB_TXN_API and the parent/child packages, custom code should call those higher-level APIs rather than QA_TXN_GRP directly. Where direct invocation is unavoidable, callers must respect the COMMIT_ALLOWED flag and avoid introducing commits that would break the surrounding transaction.