Search Results hist_req_id




Overview

APPS.JTF_FM_CONTENT_HISTORY_V is a CRM Foundation (JTF) reporting view that consolidates the history of outbound fulfillment and correspondence content generated through Oracle EBS fulfillment management. It exposes a unified, denormalized record set describing each piece of content processed for a party — including the request that generated it, its delivery destination, and its delivery outcome. In Oracle EBS 12.1.1 and 12.2.2, this view is a reporting and integration access point rather than a transactional entity, and application code should treat it as read-only. Its principal value is that it joins processed fulfillment requests with their request contents and request history, presenting both historical rows retained in JTF_FM_CONTENT_HISTORY and live rows derived from the processed request tables in a single result set.

Underlying Base Objects

The view is defined as a UNION ALL of two branches, based on the following documented objects:

  • JTF_FM_CONTENT_HISTORY — supplies the persisted history branch, including content metadata, outcome description, deletion flag, and object version number.
  • JTF_FM_PROCESSED — supplies the live processed-request branch, including batch/job number, party name, outcome code, and the request identifier.
  • JTF_FM_REQUEST_CONTENTS — joins to the processed request via REQUEST_ID and contributes quantity, document type, content number/type/name, and user notes.
  • JTF_FM_REQUEST_HISTORY (itself a view) — provides the submission timestamp and media type used to decode the destination address; it is joined on HIST_REQ_ID.

All are referenced as APPS-owned synonyms. The deduplication key PK_ID is synthesized via TO_NUMBER(CONTENT_NUMBER || HIST_REQ_ID || SUBMIT_DT_TM || BATCH_NUMBER) on the history branch and set to 0 on the processed branch.

Key Columns

  • HIST_REQ_ID — the request identifier, in the live branch mapped from JTF_FM_PROCESSED.REQUEST_ID and joined to JTF_FM_REQUEST_HISTORY.HIST_REQ_ID. This is the primary correlation key and the column most commonly searched.
  • CONTENT_NUMBER, CONTENT_TYPE, CONTENT_NAME — identify the fulfillment content item; MES_DOC_ID maps to CONTENT_ID on the live branch.
  • PARTY_ID, PARTY_NAME — the recipient party associated with the content.
  • BATCH_NUMBER — the processing job/batch, from JTF_FM_PROCESSED.JOB.
  • DESTINATION_ADDR — decoded from the media type (EMAIL, FAX, PRINTER, UNKNOWN) to the appropriate email, fax, or printer address.
  • SUBMIT_DT_TM, OUTPUT_ID, USER_NOTES — submission timing, output reference, and free-text notes.
  • OUTCOME_CODE, OUTCOME_DESC — delivery result; the description is populated only on the history branch and is NULL in the live branch.
  • QUANTITY, DOCUMENT_TYPE — content volume and document classification.
  • F_DELETEDFLAG, OBJECT_VERSION_NUMBER, PK_ID — soft-delete indicator, concurrency version, and synthesized surrogate key.

Common Use Cases and Queries

The view supports delivery auditing, correspondence tracking, and reconciliation of fulfillment output against requests. Because a given HIST_REQ_ID may appear once per content item, queries should be scoped accordingly.

  • Retrieve all content for a specific request: SELECT * FROM apps.jtf_fm_content_history_v WHERE hist_req_id = :req_id;
  • Report delivery outcomes by party and date: SELECT party_name, outcome_code, COUNT(*) FROM apps.jtf_fm_content_history_v WHERE submit_dt_tm >= :from_date GROUP BY party_name, outcome_code;
  • Identify failed correspondences: SELECT hist_req_id, content_name, destination_addr FROM apps.jtf_fm_content_history_v WHERE outcome_code <> 'SUCCESS' AND f_deletedflag IS NULL;
  • Trace a batch: SELECT batch_number, content_number, submit_dt_tm FROM apps.jtf_fm_content_history_v WHERE batch_number = :batch ORDER BY submit_dt_tm;

Filtering on HIST_REQ_ID, PARTY_ID, SUBMIT_DT_TM, or BATCH_NUMBER is standard; note that the UNION ALL and function-based PK_ID may limit index usage, so restrict date ranges in high-volume environments.