Search Results requested_quantity_uom




Overview
Explore in AI Chat

Overview

WSH_BACKORDER_LINES_V is a pre-built Oracle E-Business Suite view owned by the APPS schema and delivered as part of the Shipping Execution (WSH) product family. It is available in both 12.1.1 and 12.2.2 and is flagged VALID in the ETRM object registry. The view exposes delivery detail lines that have been processed by Oracle Shipping and left in a backordered state, specifically those whose RELEASED_STATUS equals 'B'. It joins delivery detail, delivery assignment, delivery header, delivery leg, and trip stop information into a single flattened row, allowing report writers, OAF pages, and interfaces to retrieve order, item, delivery, trip, and delivery-leg context without navigating the underlying normalized table set.

The view's defining predicate NVL(WDD.LINE_DIRECTION,'O') IN ('O','IO') restricts output to outbound and internal order line directions, excluding inbound flows. The view is implemented as a UNION of two branches that differ in how trip and stop information is resolved, ensuring that lines associated with a trip are returned alongside lines that are not yet trip-assigned. Backorder reporting is the primary purpose, but the view also serves as a convenient source for downstream availability and fulfillment dashboards.

Underlying Base Objects

The documented referenced objects are WSH_DELIVERY_ASSIGNMENTS_V (view), and the synonyms WSH_DELIVERY_DETAILS, WSH_DELIVERY_LEGS, WSH_NEW_DELIVERIES, and WSH_TRIP_STOPS, all resolving to their APPS base tables. WSH_DELIVERY_DETAILS is the driving table, supplying delivery_detail_id, source order and line identifiers, customer, inventory item, requested quantity and UOM, and the RELEASED_STATUS and LINE_DIRECTION attributes that filter the result set.

WSH_DELIVERY_ASSIGNMENTS maps delivery details to deliveries; its join to WSH_NEW_DELIVERIES supplies delivery_id and delivery name. WSH_DELIVERY_LEGS provides the DELIVERY_LEG_ID used to identify the shipment leg, and WSH_TRIP_STOPS supplies trip_id and stop_id. The view text shows the first UNION branch joining delivery header to trip stops through INITIAL_PICKUP_LOCATION_ID = STOP_LOCATION_ID and leg to stop through PICK_UP_STOP_ID = STOP_ID, while the second branch returns NULL for trip and stop identifiers where no trip assignment exists.

Key Columns

  • DELIVERY_DETAIL_ID — Primary key of the delivery detail line; used to drill back to WSH_DELIVERY_DETAILS.
  • ORDER_NUMBER / LINE_NUMBER — Source order and line numbers from the originating order management transaction.
  • HEADER_ID / LINE_ID — Source header and line identifiers for integration joins.
  • ORDER_TYPE_ID / ORDER_TYPE_NAME — Source header type, distinguishing sales order from internal order flows.
  • DELIVERY_ID / DELIVERY_NAME — Delivery header identity.
  • DELIVERY_LEG_ID — Identifier of the shipment leg on which the delivery is scheduled; NULL when trip assignment has not yet occurred.
  • TRIP_ID / STOP_ID — Trip and stop on which the delivery is planned; NULL for unassigned lines.
  • REQUESTED_QUANTITY / REQUESTED_QUANTITY_UOM — Ordered quantity and unit of measure for the backordered line.

Common Use Cases and Queries

Operations teams use this view to list open backorders by delivery and trip, to measure backorder volume by item or customer, and to reconcile delivery legs with trip stops. The inclusion of DELIVERY_LEG_ID makes it useful for freight planning and for identifying lines that have a leg but no trip stop.

Sample query to list backordered lines with trip and leg context:

  • SELECT order_number, line_number, delivery_name, delivery_leg_id, trip_id, stop_id, requested_quantity, requested_quantity_uom FROM apps.wsh_backorder_lines_v WHERE trip_id IS NULL ORDER BY delivery_name, line_number;
  • SELECT inventory_item_id, SUM(requested_quantity) backorder_qty FROM apps.wsh_backorder_lines_v GROUP BY inventory_item_id;
  • SELECT b.order_number, b.line_number, b.delivery_leg_id FROM apps.wsh_backorder_lines_v b WHERE b.delivery_leg_id IS NOT NULL AND b.stop_id IS NULL;

Queries should always qualify the view with the APPS schema and filter on the exposed columns rather than on underlying tables, since the view already enforces the backorder status and line-direction predicates.