Search Results wsh_exceptions_s




Overview
Explore in AI Chat

Overview

WSH_XC_UTIL is a utility package body in the APPS schema that supports the Oracle Shipping Execution exception framework. Its principal business function is to centralize the creation, classification, status management, and lifecycle handling of shipping exceptions recorded against deliveries, delivery details, delivery legs, trips, and trip stops. In Oracle EBS 12.1.1 and 12.2.2, exceptions drive operational visibility: they flag holds, delays, quantity discrepancies, carrier issues, and integration failures so that warehouse and transportation users can act on them from the Shipping Execution and Transportation forms and concurrent programs.

The package is classified as a UTIL API. It is not a public transactional interface; rather, it is the shared internal engine used by other WSH packages, forms, and workflows. The ETRM dependency listing notes that it is referenced by 44 other packages, while it references no external database object outside its own dependency set, underscoring its role as a leaf-level utility rather than a top-level entry point.

Key Procedures and Functions

  • LOG_EXCEPTION — Core routine for recording a shipping exception against a delivery or related entity. Validates the exception definition and writes to the WSH_EXCEPTIONS table.
  • LOG_OTM_EXCEPTION — Specialized variant that logs exceptions originating from Oracle Transportation Management (OTM) integration events.
  • GET_OTM_DELIVERY_EXCEPTION — Retrieves OTM-related exception information for a delivery, supporting inbound integration processing.
  • CHECK_EXCEPTIONS — Evaluates existing exceptions, typically to determine whether any open exceptions block a business action.
  • CLOSE_EXCEPTIONS — Closes or resolves open exceptions, updating status and resolution information.
  • CHANGE_STATUS — Generic status transition routine used across exception records.
  • INSERT_XC_DEF_FORM — Form-level insert of an exception definition (XC_DEF), used by the exception definition maintenance UI.
  • UPDATE_XC_DEF_FORM — Form-level update of an existing exception definition.
  • DELETE_XC_DEF_FORM — Form-level deletion of an exception definition.
  • LOAD_ROW — Loads a definition row, supporting data seeding or concurrent loader processes.
  • TRANSLATE_ROW — Populates translated (TL) columns for exception definitions.
  • ADD_LANGUAGE — Adds a language row to the exception definition translation table.
  • GET_LOOKUP_MEANING — Returns lookup meaning text, used to resolve coded values to display text.
  • PURGE — Removes obsolete or historical exception and definition records.

Tables Accessed

  • WSH_EXCEPTIONS / WSH_EXCEPTIONS_S — Primary exception transaction tables; the _S sequence-backed table provides the unique key source used to identify exception rows.
  • WSH_EXCEPTION_DEFINITIONS_B / _S / _TL / _VL — Exception definition base, sequence, translation, and view-layer tables, accessed by the definition management routines (INSERT/UPDATE/DELETE/LOAD/TRANSLATE/ADD_LANGUAGE).
  • WSH_NEW_DELIVERIES — Reads delivery header context when logging or evaluating exceptions.
  • WSH_DELIVERY_ASSIGNMENTS, WSH_DELIVERY_DETAILS, WSH_DELIVERY_LEGS — Provide the delivery line and leg context against which exceptions are recorded.
  • WSH_TRIP_STOPS — Supplies trip stop context for transportation-related exceptions.
  • FND_LANGUAGES — Used by ADD_LANGUAGE and TRANSLATE_ROW for multilingual definition maintenance.
  • WF_PARAMETER_LIST_T and PLITBLM — Workflow/PL/SQL parameter and array utility types used for internal passing of arguments.

Usage Notes

WSH_XC_UTIL is invoked indirectly rather than directly by end users. The form-level exception definition routines are called by the Shipping Execution exception definition maintenance form, while LOG_EXCEPTION, CHECK_EXCEPTIONS, and CLOSE_EXCEPTIONS are invoked by other WSH packages—including WSH_NEW_DELIVERIES_PVT, WSH_PICK_LIST, WSH_UTIL_CORE, and WSH_UTIL_VALIDATE—and by consolidation and transportation workflows. The OTM routines support integration with Oracle Transportation Management. Because it depends on FND_API, FND_MSG_PUB, FND_MESSAGE, and WSH_DEBUG_INTERFACE, callers rely on standard EBS API error handling and debugging conventions. It is not referenced by any database object outside APPS, so customizations should call it cautiously and expect signature stability to be governed by Oracle's internal API policy.