Shipment legs can be added to a load from the Load Build, Load Processing modules and Transportation Smartbench.
Using Load Build, both the load and shipment leg must be attached to the user's current plan, which means that the load will be in Open status.
Using Load Processing, users can manually assign shipment legs to a load in Planned, Tendered, Tender Accepted, Tender Rejected, Confirming, Picked up,or In Transit status, provided the shipment leg is not attached to a load plan, or the shipment leg is attached to a load plan to which the current user is authorized.
Using Smartbench, users can manually assign shipment legs to a load in Open, Planned, Tendered, Tender Accepted, Tender Rejected, Confirming, Picked up,or In Transit status, provided the shipment leg is not attached to a load plan, or the shipment leg is attached to a load plan to which the current user is authorized.
As with all operations that can be triggered from the Transportation Manager web UI and Smartbench, the administrator can determine which users, if any, should be authorized to add shipments to loads.
Some of the constraints applied during the load planning process and/or optimization process will not be enforced when shipment legs are added later in the load's life cycle. For example:
In Load Build, shipment legs cannot be added to loads where Planning Status is Locked; also, shipment legs cannot be added if Planning Status is Packed if the change would introduce an additional stop (or stops) to the load's itinerary. When an attempt is made to add a shipment leg to a planned load via the Load Processing module or Smartbench, edits for Planning Status will not be enforced.
The optimizer will not add a shipment leg to a load in Tendered or Tender Accepted status if the carrier is not configured to allow addition of shipments after a tender is issued. Using the Load Processing module or Smartbench, an authorized user could add a shipment leg to a load that has already been tendered to a carrier even if the carrier is not configured to accept automated additional of shipment legs.
Depending on system configuration, user may be prompted to provide a reason code when assigning a shipment leg to a planned load via Load Processing or Smartbench. Reason Codes will never be required when a shipment leg is added via the Load Build module since the addition of a shipment leg to a load in Open status would be considered an expected action rather than an exception.
Validation
For a shipment leg to be eligible to be added to a load, it must meet the following requirements:
Shipment leg must not currently be attached to a load.
Operational Status for the shipment leg must be Processed or Optimized. Note: This will exclude unattached legs currently being re-planned (that is, Optimizing or Selected for Optimization).
If the Allow Merging of Consolidation Classes in the Global Settings is not selected, Shipment Consolidation Class and Booking Consolidation Class for the shipment leg must be equal to the corresponding values for the load.
If shipment leg is being added via Load Build, shipment leg must be attached to the current user's current load plan.
If shipment leg is being added to a load that is not in Open status :
Shipment leg must either not be attached to a plan, or it must be attached to a plan that to which the current user is authorized. The plan does not have to be the user's current plan
If the shipment leg is being controlled by a Load Merge-in-Transit Consolidation Class (MITCC), it can only be added to a load that contains shipment legs that refer to the same Load MITCC.
Note: The Remove Load MITCC operation can be used to eliminate Load MITCC requirements, if applicable.
If the shipment leg is being controlled by a Booking Merge-in-Transit Consolidation Class (MITCC), it can only be added to a load on a booking that contains shipment legs that refer to the same Booking MITCC.
Note: The Remove Booking MITCC operation can be used to eliminate Booking MITCC requirements, if applicable.
For a load to be eligible, it must meet the following requirements:
Load must not currently be engaged in the re-planning (optimization) process.
Load must not currently be engaged in the carrier sequential tendering process.
If shipment leg is being added via Load Build, the load must be attached to the current user's current plan.
If shipment leg is being added via Load Processing or Smartbench and it is attached to a plan, the user must be authorized to use this plan.
If shipment leg is being added via Load Processing, the Operational Status for the load must be one of: Planned, Tendered, Tender Accepted, Tender Rejected, Confirming, Picked up, or In Transit.
If shipment leg is being added via Optimizer or Smartbench, the Operational Status for the load must be one of: Open, Planned, Tendered, Tender Accepted, Tender Rejected, Confirming, Picked up, or In Transit.
To ensure that the shipment leg is compatible with the load, the additional edits will be performed:
Division for the load must be equal to the division for the selected shipment leg.
There must be an existing unconfirmed pickup for the load stop where Shipping Location ID, Shipping Location Type, and Address ID are equal to the Origin Shipping Location ID, Origin Shipping Location Type, and Origin Address ID for the shipment leg.
Shipment legs where freight terms are "Prepaid" cannot be combined onto a load with shipment legs where freight terms are "Collect", and vice versa.
For loads where the freight terms are "Collect", the Bill To Customer ID for all shipment legs must be equal.
For each of carrier, service, tractor equipment type or trailer equipment type, if a value is specified for both the shipment leg and the load, the values must be equal.
Shipment leg that has a pick location where "Must be First Stop" is true cannot be added to a load that already has a different pick location where "Must be First Stop" pick stop location is True. Likewise, a shipment leg that has a drop location where "Must be First Stop" is true cannot be added to a load that already has a different drop location where "Must be First Stop" drop stop location is True.
Appointments for shipment legs and load stops must not be in conflict.
If the "Mixed in Loads" flag for the customer for the shipment leg is True, the customer for the load must be equal. Similarly, if the "Mixed in Loads" flag for the customer for the load is True, only shipment legs for that customer can be assigned to the load.
Updates
When both load and shipment leg meet validation requirements listed above:
Shipment leg will be attached to the load.
If stops currently exist for the load, new stops will be created, if necessary. Pick Stop Sequence and Delivery Stop Sequence for the new shipment leg will be established as follows:
When a new shipment leg's pick and drop locations both match existing stops, the sequence numbers for the shipment legs for the matching stops will be repeated for the shipment leg that is being attached to the load.
When a new shipment leg's pick location matches an existing stop but the drop location does not, the sequence number for the shipment legs for the matching stop will be repeated as the Pick Stop Sequence for the new shipment leg while the Delivery Stop Sequence will be assigned so that it immediately follows the Pick Stop Sequence. Sequence numbers for all existing stops will be adjusted, as required, to accommodate the insertion of the new stop.
When a new shipment leg's drop location matches existing stop but the pick location does not, the sequence number for the shipment legs for the matching stop will be repeated as the Delivery Stop Sequence for the new shipment leg while the Pick Stop Sequence will be assigned so that it immediately precedes the Delivery Stop Sequence. Sequence numbers for all existing stops will be adjusted, as required, to accommodate the insertion of the new stop.
When neither the pick or drop location for a new shipment leg matches an existing stop for the load, assign the new shipment's Pick Stop Sequence as the last pick stop for the load and assign the new shipment leg's Drop Stop Sequence as the next stop following the last pickup. Sequence numbers for all existing stops will be adjusted, as required, to accommodate the insertion of the new stops.
Existing routing/rating/scheduling (RR&S) results for the load will be destroyed.
Load will be suspended if any of the load suspension tolerances are violated.
If shipment leg attached to a load plan was assigned to a load that is not in Open status, the shipment will be removed from the plan.
If the shipment leg was assigned to the load that is not in Open status, the following events will be captured:
Monitoring Situations: Shipment Leg Added To Planned Load, Load Impacted by Shipment Changed, Load Suspended.
Event Notification: Shipment Leg Added to Planned Load.
Logging status transition for shipment leg. Note that status transitions for the load will not be generated because the load status will not be impacted.
Auditing Scenarios: Load Suspended or Load Impacted by Shipment Change. Note: Shipment Leg Added to Planned Load will be a shipment leg level operation that may trigger these load level audit scenarios as background events. The Reason Code supplied by the user (if enabled) will be carried only to shipment leg level event data and messages. Secondary load level events generated by the operation will be assigned system-defined Reason Codes.
Special considerations
If a shipment leg is assigned to a load after the load has been set to Planned status, there is a possibility that a subsequent routing/rating/scheduling (RR&S) request might fail for any of the following reasons even though previous RR&S requests for the load were successful:
Commodity Exclusions violation
Commodity / Equipment Type Exclusions violation
Commodity Order Grouping violation
Consolidation Class violation (if the Allow Merging of Consolidation Classes flag in Global Settings is not active)
Note: Validation for this constraint will also be performed when adding shipment legs to loads.
Equipment Type / Shipping Location Exclusions violation