Search Results qa_result_grp




Overview
Explore in AI Chat

Overview

QA_RESULT_GRP is a group-type PL/SQL package in the APPS schema that provides a consolidated API layer for managing the lifecycle of quality results records in Oracle E-Business Suite. The package body encapsulates the enabling, propagation, and purging logic associated with QA_RESULTS and its dependent entities, including electronic records (e-records) and electronic signatures governed by the EDR (Electronic Data Records) schema. It serves as the functional bridge between the base QA_RESULTS data model, the QA Results API (QA_RESULTS_API), and the workflow/action logging subsystem that records quality-driven transactions.

Functionally, QA_RESULT_GRP supports the Oracle Quality module's requirement that result records be activated for downstream use, that associated e-records be created and signed in regulated environments, and that obsolete or invalid result data be removed in a controlled manner. Because QA results can trigger material transactions, action log entries, and result-to-specification relationships, the package centralizes these multi-table operations into a single reusable interface.

Key Procedures and Functions

The ETRM metadata documents eight procedures and functions exposed by the package:

  • PURGE — Removes quality result data according to the package's internal purge criteria, coordinating the deletion of dependent records.
  • ENABLE — Activates quality results records so that they become eligible for downstream processing and validation.
  • ENABLE_QA_RESULTS — The core enabling routine that drives the activation of records in the QA_RESULTS table, likely delegating to QA_RESULTS_API for row-level changes.
  • ENABLE_AND_FIRE_ACTION — Combines the enablement of results with the invocation of a subsequent action, allowing the caller to enable a result and immediately trigger the associated workflow or action logic.
  • GET_QA_RESULTS_ERECORDS — Retrieves the electronic records associated with quality results, returning e-record identifiers for subsequent processing.
  • ENABLE_RESULTS_ERECORDS — Enables the electronic records corresponding to quality results, ensuring the e-record is active and available for signature or acknowledgment.
  • PURGE_RESULTS_ERECORDS — Purges electronic records linked to quality results, supporting retention and cleanup policies.
  • PURGE_INVALID_RESULTS — Removes invalid or failed quality results records, emptying the QA_RESULTS table of entries that did not pass validation.

The procedures are organized around three functional clusters: enablement (ENABLE, ENABLE_QA_RESULTS, ENABLE_AND_FIRE_ACTION, ENABLE_RESULTS_ERECORDS), retrieval (GET_QA_RESULTS_ERECORDS), and purge (PURGE, PURGE_RESULTS_ERECORDS, PURGE_INVALID_RESULTS).

Tables Accessed

The package reads and writes several core tables through APPS synonyms:

  • QA_RESULTS — The primary table of quality results; enablement and purge operations act directly on its rows.
  • QA_PC_RESULTS_RELATIONSHIP — Stores relationships between results and parent/child result sets; accessed when propagating enablement or purge across related result rows.
  • QA_ACTION_LOG — Records actions taken against quality results, including the firing of workflow actions from ENABLE_AND_FIRE_ACTION.
  • MTL_MATERIAL_TRANSACTIONS_TEMP — Holds temporary material transactions generated as a consequence of enabled quality results, supporting integration with inventory movement.
  • EDR_PSIG_DOCUMENTS — Stores electronic signature documents; accessed when retrieving, enabling, or purging e-records attached to results.

Additionally, the package depends on EDR_TRANS_ACKN_PUB, FND_API, FND_LOG, FND_MSG_PUB, FND_PROFILE, FND_REQUEST, QA_RESULTS_API, QA_SEQUENCE_API, DBMS_SQL, and PLITBLM, reflecting use of the standard API error-handling, logging, and dynamic SQL infrastructure.

Usage Notes

QA_RESULT_GRP is not referenced by any database object, meaning it is not directly invoked by database triggers or constraints, nor is it a dependency of other stored PL/SQL. It is, however, referenced by eleven other packages, indicating it functions primarily as a callable utility and API layer consumed by higher-level Quality and e-records components.

Typical invocation scenarios include Oracle Forms-based Quality result entry and maintenance, concurrent programs that batch-enable or purge results, and custom extensions requiring programmatic control of result lifecycle. The presence of FND_REQUEST and FND_PROFILE dependencies suggests that some operations may be submitted as concurrent requests or gated by profile options. Developers extending Oracle Quality should call ENABLE_QA_RESULTS and the associated e-record routines rather than modifying QA_RESULTS directly, preserving validation, logging, and electronic signature integrity.