Search Results jtf_sr_note

Overview

CS_SR_NOTES_V is a predefined, VALID view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2, delivered within the Service (CS) product family. As its description states, it is the base view behind the notes section of the Service Request workbench tab, providing a denormalized, reporting-friendly representation of the notes attached to service requests. The view joins the generic JTF notes infrastructure (note body, translated text, and lookup metadata) to the CS incident table and to FND user and lookup data, so that each row yields a complete service-request note record without the consumer needing to reconstruct the underlying joins.

This object is the point of origin for the column NOTE_STATUS_MEANING, which is the attribute most commonly sought by users searching on "note_status_meaning." For each note, the view resolves the internal NOTE_STATUS code against the JTF_NOTE_STATUS lookup type and exposes its human-readable MEANING.

Underlying Base Objects

The view is defined over the following documented objects:

• JTF_NOTES_B (synonym) — the base notes table holding the note header, note type, status, source object reference, and audit columns.
• JTF_NOTES_TL (synonym) — the translated notes table, joined on JTF_NOTE_ID and restricted to the session language via USERENV('LANG'), supplying the NOTES text.
• CS_INCIDENTS_ALL_B (synonym) — the service request header, joined on INCIDENT_ID = NOTE.SOURCE_OBJECT_ID where the note's SOURCE_OBJECT_CODE is 'SR'.
• FND_USER (synonym) — supplies USER_NAME for the note creator via CREATED_BY.
• FND_LOOKUPS (view) — referenced twice, once for JTF_NOTE_TYPE and once for JTF_NOTE_STATUS, using outer joins so notes with unpopulated type or status codes are still returned.
• CS_LOOKUPS (view) — supplies the CS_SR_SOURCE_TYPE meaning used to build the SOURCE concatenation.
• DBMS_LOB (synonym) — used via GETLENGTH to determine whether detailed note text exists.

FND_GLOBAL (package) is also referenced indirectly through the language context used in the translation join.

Key Columns

• INCIDENT_ID — service request identifier linking the note to its parent SR.
• ID — the JTF_NOTE_ID, the note's primary key.
• NOTE_TYPE_CODE / NOTE_TYPE_MEANING — the note classification code and its JTF_NOTE_TYPE lookup meaning.
• NOTE_STATUS / NOTE_STATUS_MEANING — the raw status code and its translated JTF_NOTE_STATUS meaning, the principal lookup target.
• NOTE — the localized note text from JTF_NOTES_TL.
• IS_DETAIL — 'Y' or 'N' indicating whether an extended note detail LOB exists.
• OBJ_ID, OBJ_NUMBER, SOURCE — the service request ID, number, and a formatted source label.
• USER_NAME — the user who created the note.
• TRUE_STMT, RECORD_SOURCE_TYPE — static literals ('T', 'JTF_SR_NOTE') used by the workbench UI.
• Standard audit columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The view is typically queried for workbench-style reports, note auditing, and status analysis. A representative query retrieving all notes for a service request, with the status meaning resolved, is:

• SELECT id, note_type_meaning, note_status_meaning, note, user_name, creation_date FROM cs_sr_notes_v WHERE incident_id = :p_incident_id ORDER BY creation_date DESC;
• SELECT incident_id, COUNT(*) FROM cs_sr_notes_v WHERE note_status = :p_status GROUP BY incident_id;

Because all joins other than the translation join are outer or inner to already-validated parent rows, the view returns one row per note per service request, making it suitable for direct use in BI Publisher reports, OAF workbench extensions, and integration extracts where note status and type meanings are required in readable form.