When a shipment leg is in Load Purged status, this indicates that the load to which the shipment leg was formerly attached has been deleted by the purge utility. This situation could occur for a multi-leg shipment when the loads for some but not all of the attached shipment legs were eligible to be purged. A shipment leg cannot be manually promoted to this status.
Shipment legs in Load Purged status are not eligible for any operational processing. The properties and related data (for example, appointments, reference numbers, and events) for these shipment legs can be viewed but no updates are allowed. These shipment legs have no associated load, load stops, or stop POD data.
Auditing, status transitions, alerts and event notification messages will not be generated when a shipment leg is moved to Load Purged status. The purge utility uses a separate reporting mechanism to audit purge activity.
Most of the lists in the web UI will exclude shipment legs in Load Purged status.
These legs will appear on the Shipment Itinerary list but these legs will be ineligible for any updates. This includes operations that act directly on the requested shipment leg (Properties or Split) as well as the Delete operation which acts on the requested shipment leg and the preceding leg on the shipment's itinerary.
Shipments will always include at least one shipment leg that is not in Load Purged status (once all legs qualify for Load Purged status, the shipment itself is purged).
While most shipment level operations (for example, Reference Numbers or Generate Event) for shipments with a shipment leg in Load Purged status will behave as if the shipment leg was attached to a load in the highest operational status, there are several critical differences in behavior that must be considered:
Scheduling will not be active for any of the legs for the shipment.
The Shipment Gross Margin page will display an alert to inform users that since at least one shipment leg has had its load purged, amounts are distorted.
Some events are logged twice: once by referring to the load ID and once by referring to the shipment leg ID. Prior to a load being purged, users will see two similar entries on the Shipment History list: one for load, the other for shipment leg. After the load is purged, users will see only one entry, the one for shipment leg.
Information on Shipment Events page related to the "First Picked Composition Confirmed" and "Latest Current Location" events may be inappropriately attributed to one of the shipment's legs where the load has not been purged.
When Revenue by Cost Center functionality is enabled, the G/L Transaction generation batch process will use each shipment leg's load header to retrieve the applicable cost center. If a shipment leg is in Load Purged status, this step will fail. The log generated by the batch financial process will identify this exception case.
The generate voucher process (both interactive and batch) will have an additional check for shipments with at least one shipment leg in Load Purged status.
When the customer for an affected shipment is a carrier surcharge based, no voucher will be generated. For the interactive Generate A/R Voucher operation, an error message will inform users that the operation is invalid because at least one load associated to the shipment has been purged. For batch A/R voucher generation requests, a row will be created in the Voucher Run Exception table. If vouchers already exist, Reverse Voucher and Cancel Voucher operations will be blocked. Blocking the Reverse Voucher and Cancel Voucher operations will prevent users from having the false impression that they could re-generate the voucher to fix the "missing load".
When an affected shipment's tariff based customer selectively uses carrier surcharging for at least one Tariff Charge on one of the customer's tariffs, a voucher will be generated. For the interactive Generate A/R Voucher operation, a warning message will inform users that the voucher may be compromised because at least one load associated to the shipment has been purged. For batch Generate A/R Voucher requests, a row will be created with the warning message in the Voucher Run Exception table.
Note: Administrators must evaluate the relative importance of gaining the performance and throughput advantages that result from triggering the purge process in a mode that leaves shipment legs without corresponding loads. If any of the factors listed above would be untenable, then the purge process must be invoked in a mode where purge is deferred until all related loads can be removed simultaneously.