Delivery Reversal can be performed using the Return to Delivered operation.
POD Reversal can be performed using either the Return to In Transit or the Return to Delivered operation.
Transportation Manager will allow a shipment leg (or all shipment legs for a stop) to be advanced to POD status from either from In Transit, Partially Delivered, Delivered or Partially POD status. Similarly, a shipment leg detail can be advanced to POD from In Transit or Delivered. When POD is performed for a shipment leg detail or shipment leg (or for all shipment legs dropped at a stop) where current status In Transit, the Delivery Confirmation event will be performed in the background. The same approach is used for Reversal: if a shipment leg (or all legs for a stop) is moved from POD status all the way back to In Transit status using the Return to In Transit operation, a "silent" status reversal from POD to Delivered will be performed as part of the transaction.
The Return to In Transit and Return to Delivered operations can be enabled from any of the lists where the POD and Delivery operations can be triggered.
When these return operations are performed, the shipment's customer profile will be consulted to determine whether any existing A/R Vouchers should be placed on hold pending POD or Delivery Notification; the trip/load/manifest's carrier profile will be referenced to determine if any existing A/P vouchers should be held. When the Delivery or POD operation is subsequently performed again for the same shipment leg detail, shipment leg, load or stop, any voucher holds for Outstanding Delivery or POD Notification will be eliminated.
Since the Return to In Transit and Return to Delivered operations are accessed using distinct operations from the various lists, the administrator can control which users can access these operations.
While load confirmation enforces the confirmation sequence for pick stops, (a pick stop cannot be confirmed if the previous pick stop has not yet been confirmed), delivery stop sequence is not considered when a stop's eligibility for the Delivery and POD operations. This means that Delivery or POD can be performed for a drop stop before Delivery or POD has been reported for the previous drop stop.
Similarly, while the relationship between load statuses and their sequences on a trip is enforced up to the point where the loads reach In Transit status, there is no verification beyond this status. For example, a drop stop for the second load on a trip can be updated to Delivered status before Delivery or POD is reported for any drop stops for the first load.
Event handling
By default, user will not be prompted for a Reason Code when using the Return to In Transit or Return to Delivered operations. Event Associations can be configured so that a Reason Code is required when performing these reversal operations. The Reason Code supplied by the user or defaulted by the system will be carried to all event notifications, monitoring situations, status transition events and audit data.
Event Notification events for Delivery and POD will not be automatically un-distributed when Delivery or POD reversal occurs. Likewise, Notification Alerts for POD or Delivery Confirmation will survive any subsequent reversal operations.
When the Delivery Reversal or POD Reversal is performed, Proactive Monitoring will reinstate applicable system-defined overdue alerts and quash applicable system-defined violation alerts.