Search Results wip_eam_work_req_notes

Overview

WIP_EAM_WORK_REQ_NOTES is a table in the WIP (Work in Process) schema of Oracle E-Business Suite, holding log and note information associated with Enterprise Asset Management (EAM) work requests. The table is documented in ETRM with a VALID status and is owned by the WIP product module. Its stated purpose is to store work request log information. In EAM, a work request captures a maintenance need raised against an asset; the notes table provides the mechanism by which technicians, planners, and requesters attach free-text log entries and notification-related remarks to that request without altering the header record itself. This separation keeps the work request master row stable while allowing an unbounded history of commentary to accumulate.

From a dimensional modeling perspective, the ETRM data vault classification (mined heuristically from the foreign key structure) is satellite-leaning. In Data Vault terms, this suggests modeling WIP_EAM_WORK_REQ_NOTES as a satellite attached to the WIP_EAM_WORK_REQUESTS hub, with WORK_REQUEST_ID acting as the hub reference and the note attributes carrying the descriptive payload. The classification is a modeling suggestion rather than a documented physical constraint.

Key Information Stored

The table is documented with ten columns. The primary key is WIP_EAM_WORK_REQ_NOTES_PK, defined on WORK_REQUEST_NOTE_ID, which is also the single unique-index business-key candidate (WIP_EAM_WORK_REQ_NOTES_U1). WORK_REQUEST_NOTE_ID is therefore the surrogate identifier for each note row, while the true parent linkage is carried by WORK_REQUEST_ID, the foreign key pointing to WIP_EAM_WORK_REQUESTS.

• WORK_REQUEST_NOTE_ID — surrogate primary key uniquely identifying each note record.
• WORK_REQUEST_ID — foreign key to WIP_EAM_WORK_REQUESTS; ties the note to its parent work request.
• NOTES — the free-text body of the log entry.
• WORK_REQUEST_NOTE_TYPE — classifies the note (for example, distinguishing log entries from other note categories).
• NOTIFICATION_ID — associates the note with a notification record, supporting the work request notification workflow.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard Oracle EBS WHO columns providing audit and concurrency information.

Common Use Cases and Queries

Typical reporting needs include retrieving the full note history for a work request, auditing who added commentary and when, and tracing notes surfaced through notification workflows. A representative pattern joins the satellite to its parent hub:

• Selecting all notes for one request: SELECT note.work_request_note_id, note.notes, note.work_request_note_type, note.creation_date, note.created_by FROM wip.wip_eam_work_req_notes note WHERE note.work_request_id = :p_work_request_id ORDER BY note.creation_date;
• Combining with the header for context: SELECT req.work_request_id, note.notes, note.last_update_date FROM wip.wip_eam_work_requests req, wip.wip_eam_work_req_notes note WHERE req.work_request_id = note.work_request_id;
• Audit-style extraction keyed on the surrogate: SELECT * FROM wip.wip_eam_work_req_notes WHERE work_request_note_id = :p_note_id;

Because the table is a satellite, extracts typically filter by WORK_REQUEST_ID or by the audit columns rather than scanning on NOTES content. Note that the NOTES column is free text and should not be used as a join or filtering key in high-volume reports.

Related Objects

The dominant relationship is the foreign key from WIP_EAM_WORK_REQ_NOTES.WORK_REQUEST_ID to WIP_EAM_WORK_REQUESTS, making the work request header the primary parent object for every query and extraction.

• WIP_EAM_WORK_REQUESTS — parent entity; join on WORK_REQUEST_ID.
• WIP_EAM_WORK_REQ_NOTES_PK — primary key constraint on WORK_REQUEST_NOTE_ID.
• WIP_EAM_WORK_REQ_NOTES_U1 — unique index on WORK_REQUEST_NOTE_ID.
• NOTIFICATION_ID — logical linkage to the notification infrastructure referenced by the note.
• EAM work request inquiry and maintenance workbench windows, which surface these notes to users.
• Concurrent programs and reports in the WIP/EAM module that extract work request history.

Collectively these objects define the note satellite as an append-oriented log tied to a single work request hub, with all query paths converging on the WORK_REQUEST_ID relationship.