Search Results edr_esignatures_n1

Overview

The EDR.EDR_ESIGNATURES table is a core Electronic Records and Signatures (EDR) repository within the Oracle E-Business Suite, storing the individual signature records captured against electronic signature events. In Oracle EBS 12.1.1 and 12.2.2, EDR provides the regulatory-compliance framework (for example, 21 CFR Part 11) that governs electronic approvals, evidence capture, and audit trails for transactions such as document approvals, workflow responses, and Oracle iSignatures invocations. Each row in this table represents a single signing action tied to an event, capturing who signed, when, from which timezone, and the disposition of the signature.

The object is owned by the EDR schema and resides in the APPS_TS_INTERFACE tablespace, both characteristics consistent with an interface/staging style of design. Oracle flags the object as Internal Use Only and does not support direct data access except through standard Oracle Applications programs.

Based on the mined foreign-key structure (relationships to FND_USER and CZ_SIGNATURES and a lean, non-hub-looking key shape), the heuristic Data Vault classification is satellite-leaning. This suggests modeling the table as a satellite attached to a signature or signature-event hub, with descriptive attributes (timestamp, timezone, status, comments) rather than as an independent hub or link.

Key Information Stored

The surrogate primary key is SIGNATURE_ID, enforced by the unique index EDR_ESIGNATURES_U1 on the SIGNATURE_ID column. Because this unique index is the only business-key candidate documented, SIGNATURE_ID serves both as the technical key and as the join key into the EDR signature hierarchy. The following columns carry the operational and compliance content:

• EVENT_ID and EVENT_NAME — identify the signature event to which the signature belongs; the non-unique index EDR_ESIGNATURES_N1 supports retrieval by EVENT_ID.
• EVIDENCE_STORE_ID — links the record to the stored evidence artifact retained for the signature.
• USER_NAME — the signer identity, documented as referencing FND_USER.
• SIGNATURE_SEQUENCE and SIGNATURE_TYPE — order and category of the signature within the event workflow.
• SIGNATURE_TIMESTAMP and SIGNATURE_TIMEZONE — the legally significant moment and locale of signing.
• SIGNATURE_STATUS and SIGNATURE_REASON_CODE — outcome and coded justification for the action.
• SIGNER_COMMENTS and SIGNATURE_OVERRIDING_COMMENTS — free-text annotations and override rationale.
• ORIGINAL_RECIPIENT — the intended recipient captured at signing time.
• ADHOC_STATUS — indicates whether the signer is an ad-hoc participant; a value of ADDED identifies added ad-hoc users, while deletion of default users records DELETED.

Common Use Cases and Queries

Typical EDR reporting and audit scenarios include retrieving all signatures for an event, reconstructing a signature audit trail for a user, and validating that required signatures completed successfully.

• Signatures per event: SELECT SIGNATURE_ID, USER_NAME, SIGNATURE_SEQUENCE, SIGNATURE_STATUS FROM EDR.EDR_ESIGNATURES WHERE EVENT_ID = :event_id ORDER BY SIGNATURE_SEQUENCE;
• User signature history: join USER_NAME to FND_USER.USER_NAME and filter by signature timestamp range.
• Compliance exception report: list rows where SIGNATURE_STATUS is not a completed state or where SIGNATURE_OVERRIDING_COMMENTS is populated.
• Ad-hoc participation audit: SELECT * FROM EDR.EDR_ESIGNATURES WHERE ADHOC_STATUS IN ('ADDED','DELETED');

Related Objects

The table's dependency footprint is deliberately narrow, which simplifies lineage analysis. The most significant related objects are:

• CZ_SIGNATURES — the referenced parent for the SIGNATURE_ID foreign key.
• FND_USER — looked up via the USER_NAME foreign key to resolve signer identity.
• APPS.EDR_ESIGNATURES — the APPS synonym that standard Oracle Applications programs use to access this table.
• The EDR event and evidence-store objects implied by EVENT_ID, EVENT_NAME, and EVIDENCE_STORE_ID, which form the wider EDR signature hierarchy.

Because the metadata documents no outbound references from EDR_ESIGNATURES itself, all navigation to related EDR structures is performed through the event and evidence identifiers rather than through additional foreign keys.