Search Results erecord_id_tbl_type

Overview

QA_EDR_STANDARD is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that underpins the Electronic Data Records (EDR) and electronic signature infrastructure used by Oracle Quality, Oracle Process Manufacturing, and related modules. Its central role is to determine when a signed electronic record is legally or procedurally required, to capture and persist signature evidence, and to raise the workflow events that drive electronic record (eRecord) and electronic signature (eSig) processing. The package is declared with AUTHID CURRENT_USER, meaning that name resolution for referenced objects is performed under the privileges of the calling user rather than the definer, a deliberate choice consistent with the EBS security model for signature-related code. The source header ($Header: qaedrs.pls 115.4 2004/02/18) dates the base implementation to early 2004, though the object is shipped and supported in both Oracle EBS 12.1.1 and 12.2.2. The package also acts as a bridge between EDR and generic Oracle Workflow events: it raises both ERES (electronic signature) events and inter-event notifications, allowing downstream workflow subscriptions and business event system agents to react when a record or signature is created, acknowledged, or completed. Because it is referenced by nine other packages, QA_EDR_STANDARD is effectively a shared utility layer for the family of electronic-records-enabled applications.

Key Procedures and Functions

The 21 documented routines divide into four functional groups:

• Eligibility and status determination: IS_ESIG_REQUIRED, IS_EREC_REQUIRED, IS_INSTALLED, GET_PSIGSTATUS, and IS_AUDITVALUE_OLD answer questions about whether a given transaction or record demands a signature or an electronic record, whether the EDR schema objects are present in the database, what the current signature status is for a workflow, and whether a value being compared predates the current audit scope.
• Event and query construction: GET_QUERYID_ONEVENTS, PSIG_QUERY, RAISE_ERES_EVENT, and RAISE_INTER_EVENT build and emit events. The record and table types declared in the package specification (eventDetails, eventQuery, ERECORD_ID_TBL_TYPE, ERES_EVENT_REC_TYPE) support these routines. Notably, the ERES_EVENT_REC_TYPE definition was denormalized in Bug 3136403, replacing a nested payload parameter table with nine fixed PARAM_NAME_n/PARAM_VALUE_n pairs (eight in the excerpt, continuing to nine), which simplifies event construction and serialization.
• Signature capture and workflow: CAPTURE_SIGNATURE, REQUEST_SIGNATURE, POST_SIGNATURE, SEND_ACKN, and GET_ERECORD_ID handle the transactional capture of signature data, the request to the signer, post-signature processing, acknowledgment dispatch, and retrieval of the electronic record identifier once created.
• Document lifecycle and formatting: OPEN_DOCUMENT, POST_DOCUMENTPARAMETERS, CLOSE_DOCUMENT, DISPLAY_DATE, DISPLAY_DATE_PUB, and GET_LOOKUP_MEANING manage the document context presented to a signer, parameter posting, document closure, date formatting for display, and lookup-meaning translation.

Tables Accessed

The only documented table reference via an APPS synonym is PLITBLM, the standard EBS lookup-meanings table used by GET_LOOKUP_MEANING to resolve seeded or user-defined lookup codes into displayable descriptions. Because the package is defined AUTHID CURRENT_USER, further objects it touches (such as the ERES event and electronic record repository tables) are resolved dynamically at run time and are not captured in the documented table list. The package's global variable G_SIGNATURE_STATUS carries the workflow outcome value ('APPROVED' or 'REJECTED') between routines within a database session.

Usage Notes

QA_EDR_STANDARD is not intended for direct end-user invocation. It is called from Oracle Forms event handlers when a user attempts to approve, close, or sign an electronic record, from concurrent programs that drive eRecord and signature processing, and from Oracle Workflow function activities and business event subscriptions. Customizations and third-party integrations that implement e-signature compliance should call the public routines rather than re-implementing signature logic, ensuring that the raise-event and acknowledgment paths remain consistent. The package's dependence on Workflow and the Business Event System means that any patch affecting FND_WF_EVENT or the signature repository tables should be regression-tested against the nine dependent packages that reference it.