Search Results commit_results

Overview

The PL/SQL package body APPS.QA_MQA_RESULTS belongs to the Oracle Quality (QA) module of Oracle E-Business Suite and is classified as an OTHER API under ETRM for releases 12.1.1 and 12.2.2. Its principal business function is to accept, validate, and persist quality results collected against a quality plan, specification, or collection element. In this sense the package sits between the data-entry layer (Quality Workbench and custom collection screens) and the core Quality results API, qa_results_api.insert_row, which performs the actual insert into the results tables.

The package body was reshaped during the R12 MOAC project (bug 4637896). Validation-related utility routines — parse_id, parse_value, the two result_to_array variants, and the two set_validation_flag variants — were relocated to qa_validation_api so that they could be shared by sibling packages such as qa_ss_results. The header comment still records the older bug 2701777 change, which introduced the helper that marks every element in an ElementsArray as both valid and action-fired, supporting the insert of results for History plans without running validations.

Key Procedures and Functions

ETRM documents six callable units in this package. Their purposes, as recorded, are as follows:

• POST_RESULT — Posts a single result to the database. It is a thin wrapper over the QA API qa_results_api.insert_row and returns 0 on success and -1 on error. A transaction header identifier parameter is accepted but is never used; the routine simply delegates to qa_ss_results.nontxn_post_result, confirming there is no functional difference between the two methods.
• POST_RESULT_WITH_NO_VALIDATION — Inserts a result while bypassing the standard validation path. This variant relies on the helper that sets the validation flag and action-fired flag on every element, which is the mechanism originally added for History plans.
• DELETE_RESULT — Removes a single previously posted quality result identified by the caller.
• DELETE_RESULTS — Removes a set of quality results in a single call, used when a group of collected values must be purged together.
• COMMIT_RESULTS — Performs the commit of results that have been posted during the current session or transaction. This is the unit most relevant to the search term commit_results: callers invoke it once all post operations for a batch have completed, so that the set of results is made durable as a single logical unit rather than committed row by row.
• set_validation_flag_valid — An internal helper (recorded in the package source) that iterates over an ElementsArray, assigning valid_element and action_fired to each element so that records can be inserted into qa_results without any validation.

Tables Accessed

The only table documented against this package through APPS synonyms is PLITBLM. This is the PL/SQL index-by table used internally by the EBS toolkit layer for passing tabular data between forms and stored program units; the package does not therefore maintain its own dedicated base table. Actual result rows are written to the Quality results tables indirectly, through qa_results_api.insert_row, rather than by direct DML from QA_MQA_RESULTS. Deletions are likewise routed through the supporting results API.

Usage Notes

The package is referenced by at least one other package in the EBS schema, indicating it acts as a shared service rather than a standalone entry point. Typical invocation paths include the Quality results data-entry forms, where the results of a collection are posted and subsequently committed in a single user action, and custom or extension code that posts batches of quality results programmatically. Because POST_RESULT defers to qa_ss_results.nontxn_post_result, non-transactional callers should treat the two as interchangeable. When integrating custom code, the expected sequence is to call the post routine for each result and to finalize the batch with COMMIT_RESULTS, allowing the surrounding transaction to be controlled explicitly and rolled back if any post in the batch returns -1. The no-validation variant should be reserved for History plans or equivalent scenarios where validation would otherwise block legitimate archival data. On R12.2.2, all operations must be executed within the correct MOAC operating unit context, since result rows are organization-scoped.