Search Results wsh_itm_response_headers




Overview
Explore in AI Chat

Overview

The WSH_ITM_RESPONSE_HEADERS table is a core data object within the Shipping Execution (WSH) module of Oracle E-Business Suite (EBS) versions 12.1.1 and 12.2.2. It functions as the primary repository for storing the header-level information of responses generated by the In-Transit Inventory (ITM) service. This service is integral to the logistics and supply chain management processes, facilitating communication between the EBS instance and external trading partners or carriers. As documented, for every request processed by the ITM service, a corresponding response header record is created in this table, establishing a formal audit trail and a parent entity for detailed response line data.

Key Information Stored

While the provided metadata does not list specific columns beyond the keys, the structure and relationships define the critical data points stored. The primary identifier, RESPONSE_HEADER_ID, uniquely distinguishes each response. The table links to the originating transaction via the REQUEST_CONTROL_ID foreign key, which references the WSH_ITM_REQUEST_CONTROL table, thereby connecting a response to its initial request. Furthermore, the VENDOR_ID foreign key, referencing the WSH_ITM_VENDORS table, identifies the specific external vendor or carrier that provided the response. This structure implies the table also stores metadata about the response itself, such as status, creation date, and potentially a summary of the response outcome, which governs the subsequent processing of the associated shipment or inventory transaction.

Common Use Cases and Queries

This table is central to troubleshooting and reporting on EBS communication with logistics partners. A common use case involves tracing the lifecycle of a shipment request by joining the response header to its request and associated lines. For instance, to find all responses for a specific vendor that have failed or are pending, a query would filter on VENDOR_ID and a status column. Another critical scenario is auditing: identifying requests that have not received a response within an expected timeframe by performing an outer join from the request control table to this response header table. Sample SQL to retrieve basic response audit information would typically follow this pattern:

  • SELECT rh.RESPONSE_HEADER_ID, rc.REQUEST_NUMBER, v.VENDOR_NAME, rh.CREATION_DATE FROM WSH_ITM_RESPONSE_HEADERS rh, WSH_ITM_REQUEST_CONTROL rc, WSH_ITM_VENDORS v WHERE rh.REQUEST_CONTROL_ID = rc.REQUEST_CONTROL_ID AND rh.VENDOR_ID = v.VENDOR_ID;

Related Objects

The WSH_ITM_RESPONSE_HEADERS table sits within a defined hierarchy of ITM service tables, as evidenced by its foreign key relationships. It is a child table to both WSH_ITM_REQUEST_CONTROL (via REQUEST_CONTROL_ID) and WSH_ITM_VENDORS (via VENDOR_ID). Most importantly, it acts as the parent table for WSH_ITM_RESPONSE_LINES, which holds the granular, line-level details of the carrier's response (e.g., for each shipment line or item). The primary key, RESPONSE_HEADER_ID, is referenced by the foreign key column WSH_ITM_RESPONSE_LINES.RESPONSE_HEADER_ID. This one-to-many relationship is fundamental, as a single response header record consolidates the status and summary for potentially many detailed response lines.