Search Results edr_process_erecords_t




Overview
Explore in AI Chat

Overview

EDR_PROCESS_ERECORDS_T is a table owned by the EDR schema within Oracle E-Business Suite, where EDR denotes the E-Records product. According to the ETRM metadata, its documented purpose is to serve as a temporary table holding run-time e-record object data during processing. In practice, rows are transient: they represent the working set of e-record instances being assembled, validated, or transitioned through an Electronic Records and Transaction Manager (ETRM) workflow, and are typically consumed and cleared by concurrent processing rather than retained as long-term history.

The object is marked VALID in the 12.1.1 and 12.2.2 releases and is documented with 26 physical columns. The heuristic Data Vault classification supplied with the metadata is satellite-leaning, which is consistent with a table that holds descriptive attributes for a specific business process instance rather than acting as a central hub or many-to-many link. Under that modeling suggestion, ERECORD_SEQUENCE_ID behaves as the surrogate key of the satellite, with the owning process referenced through ERES_PROCESS_ID.

Key Information Stored

The primary key is defined by the unique index EDR_PROCESS_ERECORDS_T_P on ERECORD_SEQUENCE_ID. No separate business-key unique index is documented; the metadata lists only a system LOB index (SYS_IL0000396569C00005$$) alongside the primary key, indicating that PAYLOAD is stored as a LOB. The most significant columns fall into four functional groups:

Common Use Cases and Queries

Because the table is transient, the dominant use cases are diagnostics and process monitoring. A support engineer investigating a stalled e-record run would join the table to FND_USER and filter by process identifier:

  • SELECT p.ERECORD_SEQUENCE_ID, p.TRANSACTION_NAME, p.STATUS, u.USER_NAME FROM EDR_PROCESS_ERECORDS_T p, FND_USER u WHERE p.REQUESTER = u.USER_ID AND p.ERES_PROCESS_ID = :process_id;
  • Correlating rows to an active workflow by querying WF_ITEM_TYPE, WF_ITEM_KEY, and WF_PROCESS for a given TRANSACTION_KEY.
  • Inspecting e-record hierarchies through PARENT_ERECORD_ID and CHILD_ERECORD_IDS to confirm parent-child assembly before posting.
  • Checking STATUS and DEFERRED_MODE to distinguish records awaiting post-processing from those already dispatched to POST_OP_API.
  • Age-based housekeeping, using CREATION_DATE to detect orphaned rows left behind by failed concurrent requests.

Reporting against this table for historical trend analysis is not advisable, since row retention is bounded by run-time processing; the audit and archive tables populated at process completion should be used instead.

Related Objects

The documented foreign key relationships define the two anchors of this table. REQUESTER references FND_USER, enabling the user-name joins shown above. ERES_PROCESS_ID references EDR_ERESMANAGER_T, the process manager table that owns the run-time context in which these temporary e-record rows are created. Beyond those two documented references, the workflow columns imply dependencies on the standard Oracle Workflow tables WF_ITEMS and WF_PROCESS_ACTIVITIES, and the ETRM post-processing columns imply interaction with the e-record transaction and audit structures maintained elsewhere in the EDR schema. The primary key constraint EDR_PROCESS_ERECORDS_T_P is the object most likely to be referenced if the table is extended, though its temporary nature makes inbound foreign keys from other tables unlikely.