Search Results check_exceptions

Overview

WSH_XC_UTIL is the central utility package within the Oracle E-Business Suite Shipping Execution module (WSH) responsible for creating, maintaining, validating, and closing shipping exception records. Shipping exceptions represent deviations, holds, delivery failures, or informational events that occur during outbound logistics processing — for example, a delivery that cannot be confirmed, a trip that breaches a scheduled stop, or an integration failure affecting a delivery leg. The package encapsulates the business logic required to persist these conditions in the exceptions data model and to reconcile that data against delivery and trip state.

In both Oracle EBS 12.1.1 and 12.2.2, the package is owned by APPS and classified as a utility (UTIL) API. Its header carries a long maintenance history, notably for extensions to LOG_EXCEPTION covering request identifiers, OPM parameters (sublot, secondary unit of measure and quantity), and batch identifiers used by the Process Release Online flow. Because exception handling is cross-cutting across shipping, the package is referenced by a large number of other shipping and logistics packages — the ETRM metadata records 44 dependent packages — which establishes it as a foundational internal API rather than an end-user facing component.

Key Procedures and Functions

• LOG_EXCEPTION — Creates a new exception record or updates an existing one. Update semantics are deliberately narrow: only fields that are currently NULL may be populated, which supports adding a name or completing missing attributes on an already-open exception without overwriting captured data. It is the primary write entry point for the package.
• CHANGE_STATUS — Transitions an existing exception between lifecycle states, supporting the opening, resolution, and closure flows that downstream consumers rely upon.
• INSERT_XC_DEF_FORM, UPDATE_XC_DEF_FORM, DELETE_XC_DEF_FORM — Form-facing APIs that maintain exception definition setup data (the code-and-name catalogue that classifies exceptions).
• LOAD_ROW, TRANSLATE_ROW, ADD_LANGUAGE — Standard Oracle seed-data and translation utilities, used to load definition rows and to propagate translatable definition text across installed languages.
• GET_LOOKUP_MEANING — Resolves a lookup code to its displayed meaning, typically for exception severity or handling values.
• CHECK_EXCEPTIONS — Validates exception state for a delivery or related entity, returning whether exceptions exist or remain open. This is the procedure most often called by surrounding shipping logic before confirming a delivery or closing a trip.
• CLOSE_EXCEPTIONS — Performs bulk closure of exception records, used at the conclusion of delivery, trip, or release processing.
• PURGE — Deletes historical exception records according to retention criteria.
• LOG_OTM_EXCEPTION and GET_OTM_DELIVERY_EXCEPTION — Support exception exchange with Oracle Transportation Management, logging inbound or outbound OTM exception conditions and retrieving delivery-level exception information.

Tables Accessed

The package reads and writes WSH_EXCEPTIONS and its intersection/sequence companion WSH_EXCEPTIONS_S as the transactional store of logged exceptions. Definition metadata resides in WSH_EXCEPTION_DEFINITIONS_B (base codes), WSH_EXCEPTION_DEFINITIONS_TL (translated names and descriptions), and WSH_EXCEPTION_DEFINITIONS_S. Delivery and trip context is drawn from WSH_NEW_DELIVERIES, WSH_DELIVERY_ASSIGNMENTS, WSH_DELIVERY_DETAILS, WSH_DELIVERY_LEGS, and WSH_TRIP_STOPS, allowing exceptions to be anchored to the correct delivery detail, leg, or trip stop. Language utilities touch FND_LANGUAGES, workflow parameters are read from WF_PARAMETER_LIST_T, and PLITBLM is used for string/table manipulation during purge or bulk processing.

Usage Notes

WSH_XC_UTIL is not a public, customer-facing API. It is invoked internally by Shipping Execution forms, concurrent programs, and workflow activities, and by the 44 dependent packages documented in the ETRM repository. Typical invocations include logging an exception when a delivery confirmation fails, calling CHECK_EXCEPTIONS before allowing a delivery to proceed, and calling CLOSE_EXCEPTIONS or PURGE during end-of-cycle housekeeping. Custom code should call these procedures only through the documented signature, observing the standard API conventions of the header (p_api_version, p_init_msg_list, p_commit, and x_return_status/x_msg_count/x_msg_data). For LOG_EXCEPTION, callers must set location parameters to FND_API.G_MISS_NUM to insert a new exception and to NULL to update an existing one, and must account for the fact that update only fills NULL columns. Because the package is shared internally, release-specific signature changes — as seen in the historical bug fixes — should be verified against the target release before use in custom extensions.