Search Results wsh_departures_pk

Overview

The WSH_DEPARTURES table is a core data object within the Oracle E-Business Suite (EBS) Order Entry (OE) module, specifically integral to the shipping execution lifecycle. It serves as the master repository for recording and managing departure entities. In the context of shipping and fulfillment, a departure represents a scheduled or actual movement of goods, such as a truckload, shipment leg, or freight consolidation event. This table enables the system to plan, track, and associate deliveries with specific transportation segments, forming a critical link between order fulfillment activities and physical logistics. Its role is to provide a structured framework for managing the timing and sequencing of outbound logistics operations.

Key Information Stored

While the provided metadata does not list individual columns, the primary and foreign key relationships define its critical structure. The central identifier is the DEPARTURE_ID, which is the primary key (WSH_DEPARTURES_PK). A significant recursive relationship is established via the ARRIVE_AFTER_DEPARTURE_ID foreign key, which points back to the same table. This allows for modeling sequential departure dependencies, where one departure cannot commence until a prior one arrives. The table also links to operational entities through foreign keys, notably REPORT_SET_ID for associating output documents. The presence of both PLANNED_DEPARTURE_ID and ACTUAL_DEPARTURE_ID in the related WSH_DELIVERIES table indicates that WSH_DEPARTURES stores records for both scheduled and executed departure events.

Common Use Cases and Queries

Common use cases revolve around shipment planning, status tracking, and reporting. Planners use this table to schedule freight movements and consolidate deliveries. Dispatchers query it to view actual departure times and sequences. A typical query would join WSH_DEPARTURES with WSH_DELIVERIES to analyze the status of deliveries planned for a specific departure. For instance, identifying all deliveries associated with a delayed departure would assist in customer notification. Another common pattern involves the recursive relationship to build a sequence of departures for a complex multi-leg shipment. Reporting often focuses on departure timeliness, comparing planned versus actual departure dates, and analyzing resource utilization based on departure schedules.

Related Objects

The WSH_DEPARTURES table is central to the shipping schema, with extensive relationships documented in the metadata. Key related objects include:

• WSH_DELIVERIES: The primary child table, linked via PLANNED_DEPARTURE_ID and ACTUAL_DEPARTURE_ID. This is the most critical relationship, tying departure schedules to specific delivery lines.
• SO_PICKING_BATCHES_ALL and SO_PICKING_LINE_DETAILS: These tables reference the DEPARTURE_ID, linking the departure to the picking and batch release processes that precede shipping.
• SO_LINE_DETAILS: Links order line fulfillment details to a specific departure.
• SO_REPORT_SETS: Associates a set of shipping documents (like bills of lading) with a departure via REPORT_SET_ID.
• Self-Reference: The recursive foreign key on ARRIVE_AFTER_DEPARTURE_ID allows for modeling departure sequences within the same table.

These relationships underscore the table's role as a nexus between order management, warehouse operations, and transportation execution.