Search Results logging_entity

Overview

WSH_EXCEPTIONS_DLVY_V is a reporting view owned by the APPS schema within the Oracle E-Business Suite Shipping Execution (WSH) module. It presents delivery-related exception records in a denormalized, translation-aware form, joining the core exception table to its definition, lookup, location, and organization context. The view exists to give operational users and downstream integrations a single, query-ready source of shipping exception data that already resolves lookup codes into their display meanings and normalizes status and severity values.

The logging_entity column identifies the object type (for example, delivery, trip, trip stop, or container) against which an exception was logged, and its meaning is resolved at runtime through the WSH_XC_UTIL.GET_LOOKUP_MEANING function against the LOGGING_ENTITY lookup type. This makes the view particularly relevant for exception-monitoring inquiries, alerting, and integration interfaces that must interpret why a delivery is blocked or flagged.

Underlying Base Objects

The view is defined over the following documented base objects:

• WSH_EXCEPTIONS (synonym) — the driving table, aliased XC, holding each logged exception record.
• WSH_EXCEPTION_DEFINITIONS_TL and WSH_EXCEPTION_DEFINITIONS_B (synonyms) — provide the exception name and translated description.
• FND_LOOKUP_VALUES — resolves exception behavior/severity lookup codes into meanings via FLV.MEANING.
• WSH_LOCATIONS aliased WLO and WLAL (synonyms) — supply UI location codes for the exception location and the logging location.
• HR_LOCATIONS_ALL — associated with location resolution.
• MTL_PARAMETERS — supplies the organization ID and organization code context.
• WSH_DELIVERY_ASSIGNMENTS_V (view) — contributes delivery assignment context.
• WSH_XC_UTIL (package) — provides GET_LOOKUP_MEANING to translate logging entity and behavior codes.

The view text joins these through exception, definition, lookup, location, and organization keys, and includes decode logic that maps raw severity and status codes into consolidated values.

Key Columns

• EXCEPTION_ID / EXCEPTION_NAME — primary identifier and descriptive name of the exception.
• LOGGING_ENTITY / LOGGING_ENTITY_ID — the entity type and its identifier against which the exception was logged; the entity meaning is resolved dynamically.
• LOGGED_AT_LOCATION_ID / UI_LOCATION_CODE — location where the exception originated, with its user-facing code.
• SEVERITY — decoded to ERROR, WARNING, INFO, or the original value; behavior meaning resolved via lookup.
• STATUS — normalized to OPEN or NO_ACTION_REQUIRED from underlying statuses such as MANUAL, LOGGED, IN_PROCESS, ERROR, or NOT_HANDLED.
• DELIVERY_ID / ASSIGNED_DELIVERY_ID, DELIVERY_NAME, DELIVERY_DETAIL_ID, DELIVERY_ASSIGNMENT_ID — delivery and line context.
• TRIP_ID / TRIP_NAME / TRIP_STOP_ID, CONTAINER_NAME — transportation and packing context.
• INVENTORY_ITEM_ID, LOT_NUMBER, REVISION, SERIAL_NUMBER, UNIT_OF_MEASURE, QUANTITY, SUBINVENTORY, LOCATOR_ID — item and inventory detail.
• ARRIVAL_DATE, DEPARTURE_DATE, MESSAGE, ERROR_MESSAGE — timing and diagnostic text.
• ATTRIBUTE1–15, CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, REQUEST_ID, PROGRAM_ID — descriptive flexfields and audit/concurrent program columns.

Common Use Cases and Queries

Typical usage includes exception dashboards, delivery-blocking analysis, and data feeds into alerting systems. The following sample retrieves open, high-severity exceptions with their logging entity meaning:

SELECT exception_id,
       delivery_name,
       logging_entity,
       ui_location_code,
       severity,
       status,
       message
FROM   apps.wsh_exceptions_dlvy_v
WHERE  status = 'OPEN'
AND    severity = 'ERROR';

A second pattern aggregates exceptions by logging entity to identify recurring problem areas:

SELECT logging_entity,
       COUNT(*) exception_count
FROM   apps.wsh_exceptions_dlvy_v
GROUP  BY logging_entity
ORDER  BY exception_count DESC;

Because the view applies decode and lookup functions, consumers should filter on the derived STATUS and SEVERITY values rather than raw codes, and should expect dynamic lookup translation to reflect current FND_LOOKUP_VALUES configuration.