Search Results event_exists

Overview

QA_ERES_DEFER is an Oracle E-Business Suite package body owned by the APPS schema and classified under the OTHER API category. Its central business function is to support electronic signature (E-Records and E-Signatures, or ERES) processing within the Oracle Quality module. Specifically, it defers the application of approval-status stamps to Quality results collections until the appropriate signature or approval event has actually occurred. The package mediates between the signing infrastructure (the EDR_PSIG_DOCUMENTS repository) and the Quality results data stored in QA_RESULTS.

The package defines global constants for the two terminal approval statuses, 'APPROVED' and 'REJECTED', and a fixed character identifier (g_esig_status_char_id) that maps to the "Approval Required" collection element used by Quality plans. The update_res_col procedure dynamically builds and executes an UPDATE statement against QA_RESULTS, resolving the target flexfield result column through QA_FLEX_UTIL.qpc_result_column_name and stamping LAST_UPDATE_DATE and QA_LAST_UPDATE_DATE in addition to the status value. This dynamic column resolution is necessary because the E-Signature status column is a descriptive flexfield segment rather than a fixed table column.

Key Procedures and Functions

The documented callable units include a mixture of signature-approval entry points and a helper used for event detection:

• SPEC_STATUS_UPDATE — Core routine for writing an approval status value back to a specification or collection result row.
• NCM_APPROVE and NCM_DETAIL_APPROVE — Handle approval at the nonconformance (NCM) header level and the NCM detail/line level respectively.
• DISP_APPROVE and DISP_DETAIL_APPROVE — Equivalent approval entry points for disposition records.
• CAR_REVIEW_APPROVE — Applies approval for the review phase of a corrective action request.
• CAR_IMPL_APPROVE — Applies approval for the implementation phase of a corrective action request.
• QA_OCCURRENCE_APPROVE — Approves a single occurrence of a collection result.
• QA_COLLECTION_APPROVE — Approves an entire collection of results spanning multiple occurrences.

In addition, a modularized helper function, per_row_event_exists, checks whether a per-row electronic signature event already exists for a given collection by querying EDR_PSIG_DOCUMENTS with a supplied event name and event key. This function embodies the "defer" logic: the status stamp is skipped when no matching signature event has been recorded. The function returns a VARCHAR2 flag ('Y' or 'N').

Tables Accessed

Two tables are documented as referenced through APPS synonyms:

• EDR_PSIG_DOCUMENTS — Read by the event_exists cursor inside per_row_event_exists, filtering on event_name and event_key. This signature document repository confirms whether an electronic signature event has been captured before the package allows the approval status to be written.
• QA_RESULTS — Written by update_res_col and updated by the various approve procedures. The status column is resolved dynamically via QA_FLEX_UTIL, and the row is identified by plan_id, collection_id, and occurrence.

Usage Notes

QA_ERES_DEFER is invoked from the Oracle Quality forms and from component procedures in the NCM, disposition, and corrective action flows whenever an electronic signature is captured. Rather than stamping approval immediately at the point of data entry, the deferral design ensures that APPROVED or REJECTED status is applied only after the corresponding signature event has been persisted in EDR_PSIG_DOCUMENTS.

The package is self-contained: the documented metadata shows zero packages referencing it, so it operates as a leaf-level utility rather than as shared infrastructure. Custom extensions that need to write signature-based approval status to Quality results should call QA_COLLECTION_APPROVE or QA_OCCURRENCE_APPROVE rather than updating QA_RESULTS directly, because those procedures encapsulate both the event-existence check and the dynamic flexfield column resolution. The global g_esig_status_char_id value should be treated as fixed and not overridden, since it corresponds to a seeded descriptive flexfield segment definition.