Introduction / Issue
In Oracle Shipping Execution (WSH), it’s common to run into a situation where a delivery has been closed, but the associated trip remains open because the trip stop interface (SRS – Interface Trip Stop) was never triggered. This leaves the trip stuck in an inconsistent state: from a business perspective the delivery is done and goods have shipped, but system-wise the trip status doesn’t reflect that, which blocks downstream processes like billing, trip closure reporting, and inventory reconciliation.
Why We Need to Do This / Cause of the Issue
This typically happens due to a timing or trigger gap between the delivery-close action and the trip-stop interface program. A few common causes:
- The Interface Trip Stop (SRS) concurrent program either didn’t fire automatically after the delivery was closed, or it errored out silently.
- Manual interventions (e.g., closing a delivery directly through a form or a custom process) sometimes bypass the standard workflow that normally triggers the stop-closing interface.
- Concurrent program dependency issues or scheduling conflicts can cause the interface request to be skipped or stuck in a pending state.
Impact: Trips stay open indefinitely even though deliveries are closed, which causes reporting mismatches, blocks trip-level closure, and can hold up downstream financial or logistics processes that depend on a fully closed trip.
How We Solve It
Since the standard interface didn’t trigger the stop closure, we can close the trip stop directly using the WSH_TRIP_STOPS_PUB.STOP_ACTION API. This API programmatically performs the same “Close Stop” action that would normally happen through the standard interface, without needing to touch the delivery again.
Key parameters used:
- p_action_code => ‘CLOSE’ — tells the API to close the stop.
- p_stop_id — the specific trip stop ID that needs to be closed (identified from the affected trip record).
- p_actual_date => SYSDATE — marks the actual closure timestamp.
- p_defer_interface_flag => ‘N’ — ensures the interface fires immediately rather than deferring it again.
- fnd_global.apps_initialize — sets the session context (user, responsibility, application) so the API runs with the correct application security context.
/* Formatted on 2026/07/28 21:13 (Formatter Plus v4.8.8) */
DECLARE
l_operation VARCHAR2 (30) := ‘Closing Stop’;
x_return_status VARCHAR2 (1);
x_msg_data VARCHAR2 (2000);
x_msg_count VARCHAR2 (2000);
–Standard Parameters.
p_api_version_number NUMBER;
init_msg_list VARCHAR2 (30);
x_msg_details VARCHAR2 (3000);
x_msg_summary VARCHAR2 (3000);
p_validation_level NUMBER;
p_commit VARCHAR2 (30);
–Parameters for WSH_TRIP_STOPS_PUB.STOP_ACTION
p_action_code VARCHAR2 (200);
p_stop_id NUMBER;
p_trip_id NUMBER;
p_trip_name VARCHAR2 (200);
p_stop_location_id NUMBER;
p_stop_location_code VARCHAR2 (200);
p_planned_dep_date DATE;
p_actual_date DATE;
p_defer_interface_flag VARCHAR2 (200);
—
BEGIN
—
fnd_global.apps_initialize (user_id => 31927,
resp_id => 21623,
resp_appl_id => 660
);
x_return_status := wsh_util_core.g_ret_sts_success;
p_api_version_number := 1.0;
p_action_code := ‘CLOSE’;
p_stop_id := p_trip_stop_id;
–P_TRIP_ID := 7292207;–recopen.tripid;
p_trip_name := NULL;
p_stop_location_id := NULL;
p_stop_location_code := NULL;
p_planned_dep_date := NULL;
p_actual_date := SYSDATE;
p_defer_interface_flag := ‘N’;
–========================================================================
— Delivery Action API (Reopening a Delivery)
–========================================================================
wsh_trip_stops_pub.stop_action
(p_api_version_number => 1.0,
p_init_msg_list => init_msg_list,
x_return_status => x_return_status,
x_msg_count => x_msg_count,
x_msg_data => x_msg_data,
p_action_code => p_action_code,
p_stop_id => p_stop_id,
p_trip_id => p_trip_id,
p_trip_name => p_trip_name,
p_stop_location_id => p_stop_location_id,
p_stop_location_code => p_stop_location_code,
p_planned_dep_date => p_planned_dep_date,
p_actual_date => p_actual_date,
p_defer_interface_flag => p_defer_interface_flag
);
–========================================================================
— COMMIT/ROLLBACK
–========================================================================
IF x_return_status = wsh_util_core.g_ret_sts_success
THEN
DBMS_OUTPUT.put_line (l_operation || ‘ done successfully.’);
COMMIT;
ELSE
DBMS_OUTPUT.put_line (‘Failure.’);
DBMS_OUTPUT.put_line (‘Return Status = ‘ || x_return_status);
wsh_util_core.get_messages (‘Y’, x_msg_data, x_msg_details,
x_msg_count);
DBMS_OUTPUT.put_line (l_operation || ‘: ‘);
DBMS_OUTPUT.put_line (‘Summary: ‘ || SUBSTRB (x_msg_data, 1, 200));
DBMS_OUTPUT.put_line (‘Detail: ‘ || SUBSTRB (x_msg_details, 1, 200));
ROLLBACK;
END IF;
END;
Real-Time Scenario
During a routine trip-closure audit, several trips were found stuck open despite their deliveries showing as closed. Investigation traced it to the Interface Trip Stop SRS not firing for those specific stops. Rather than reopening and re-closing the delivery (which risks re-triggering shipping/inventory transactions unnecessarily), the STOP_ACTION API was run directly against the affected stop_id values, closing the stops cleanly. The x_return_status and message-stack output (wsh_util_core.get_messages) were checked after each run to confirm success or capture the exact validation error for any stop that still failed.
Tip: Always check x_return_status after the API call. If it isn’t S (success), pull the detailed error via wsh_util_core.get_messages before retrying — running this blind on a batch of stop IDs without checking each result can mask stops that genuinely have data issues (e.g., missing location or invalid trip association) rather than a simple interface miss.
Conclusion
By using the WSH_TRIP_STOPS_PUB.STOP_ACTION API directly, we were able to close orphaned trip stops without disturbing already-closed deliveries or re-running the full shipping workflow. This gave a targeted, low-risk fix for trips stuck open due to a missed Interface Trip Stop SRS trigger, and it’s now used as the standard remediation ste
