Search Results wsh_itm_pkg




Overview
Explore in AI Chat

Overview

WSH_ITM_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the In-Transit Inventory Management (ITM) functionality within the Warehouse Management System (WSH) module. In-Transit Inventory allows organizations to track material that has been shipped from a source location but not yet received at its destination, treating the goods as an inventory-owning entity during transit. This is essential for global supply chains where shipments traverse long distances, cross organizational boundaries, or involve multiple legal entities, and where accurate inventory valuation and visibility are required while goods are physically moving.

WSH_ITM_PKG provides the programmatic interface that orchestrates the exchange of ITM request and response data between Oracle EBS and external trading partners or logistics providers. The package sits at the boundary between EBS and external systems, enabling the structured submission of in-transit inventory requests and the processing of the corresponding responses, including header-level, line-level, and rule-level information. The package is classified as VALID in ETRM and carries an API classification of OTHER, indicating it is a supporting utility rather than a public, externally documented API. Its dependency graph shows only a reference to the SYS.STANDARD package, and internally it references itself, which is characteristic of a self-contained procedural library.

Key Procedures and Functions

The ETRM documentation lists a single documented procedure or function named WSH_ITM_WSH. Based on the naming convention and the supporting data model, this entry point serves as the primary driver routine for the in-transit inventory workflow. It is responsible for coordinating the processing of ITM requests and their associated responses, including validation, orchestration of dependent operations, and interaction with the request control, response header, response line, and response rule tables. No parameter list is documented in the provided ETRM metadata, so its exact signature is not asserted here. Additional subprograms may exist within the package body but are not enumerated in the documented metadata.

Tables Accessed

The package interacts with five documented base tables (referenced through APPS synonyms), which together form the in-transit inventory data model:

  • WSH_ITM_REQUEST_CONTROL — governs the control information for ITM requests, including processing status and identifiers that drive the workflow.
  • WSH_ITM_RESPONSE_HEADERS — stores header-level response data returned for each in-transit inventory request.
  • WSH_ITM_RESPONSE_LINES — holds line-level response detail corresponding to individual items or shipment lines.
  • WSH_ITM_RESPONSE_RULES — captures rule definitions that determine how responses are interpreted or applied.
  • WSH_EXCEPTIONS — records exceptions encountered during ITM processing, supporting error handling and resolution.

These tables collectively support the request-response cycle: a request is initiated and controlled, responses are populated at header, line, and rule granularity, and any processing anomalies are logged in the exceptions table.

Usage Notes

WSH_ITM_PKG is typically invoked in the context of in-transit inventory processing initiated through Oracle Warehouse Management. It may be called from EBS forms, concurrent programs, or external integration points that submit ITM requests and receive responses from trading partners or logistics systems. Because ETRM documents no downstream packages referencing WSH_ITM_PKG, it is not a widely reused library; instead it functions as a focused internal component for the ITM feature. Customizations and extensions should call the documented WSH_ITM_WSH routine rather than manipulating the underlying WSH_ITM_* tables directly, ensuring that validation, exception logging, and control updates remain consistent. As with all APPS-owned packages, direct modification is unsupported; any extension should be layered through supported APIs or custom wrapper code.