Bulk Plan Tuning Direct Shipment Building

Direct shipment building involves building direct shipments for an order release bundle through a multi-leg network or building a single stop shipment (one pickup and one drop off) for an order release or order movement bundle.

Direct Shipment Building of Order Releases to Multi-leg Shipments

The direct shipment building of order releases to multi-leg shipments through a multi-leg network is done only for the cost based routing method.

In this form of direct shipment building, different routing paths through an itinerary are explored. In each routing path, various leg options of packing and transporting the order are explored for each leg. An example of a leg option can be one 40 ft equipment using carrier A. The bulk plan logic takes into account all of the leg options along with the associated costs and comes up with an optimal routing path for the order bundle. Identifying and evaluating the transportation options on the leg involves effectively packing the ship units of the order release into one or more pieces of equipment. The choice of right equipment and the placement of ship units into the correct pieces of equipment are critical in reducing the number of containers needed. The container optimization algorithm determines the number and size of the pieces of equipment used. Due to the extensive tuning capabilities available inside container optimization, tuning container optimization is covered in a separate topic, Bulk Plan Tuning Container Optimization Logic.

Depending on how the itineraries and its associated legs are defined, an itinerary might offer several paths for the order releases to take. Even for a small number of legs in the itinerary, the number of such paths could become very large. To limit the number of paths evaluated, you can set the parameter MAX NUM OF ITINERARY LOCATION COMBINATIONS. While setting this parameter to a smaller number reduces the run time, it negatively impacts the solution quality as it arbitrarily eliminates several paths from consideration, some of which could be good routing paths. Instead, it is recommended you model the itineraries so that the itineraries do not have too many paths. There can be excessive itinerary option creation in bulk plan for non-network routing logic. For order release bulk plans with Cost-Based Routing, multi-leg itineraries, and many rate options for each order (or especially when using itineraries with Multi-model Equipment Group Profile Sets), OTM can run out of memory due to the many combinations of rates, equipment, and legs. Each of these combinations is an "itinerary option". The property glog.business.shipment.legOptionOptimizer.maxNumItineraryOptions can guard against this. The default is 100000.  For any order  bundle, the bulk plan will not create more than this number of itinerary options. If this number of itinerary options is reached, the bulk plan will proceed normally, but it is possible that it will not find a least-cost solution. Note that even with this property, we do not recommend using Multi-modal Equipment Group Profile Sets on itinerary legs.

When an order bundle gets created, the bundle will contain overlapping time windows of all the associated order releases. This is true with order movement bundles as well. For example, if an order release has a delivery time window of 9:00 AM Monday, April 8, 2013 to 5:00 PM Friday, April 12, 2013, and gets bundled with another order release that has a delivery time window of 9:00 AM Friday, April 12, 2013 to 5:00 PM Friday, April 19, 2013, the bundle will have a time window of 9:00 AM Friday, April 12, 2013 to 5:00 PM Friday, April 12, 2013.

Time Window	Order Release 1	Order Release 2	Order Release 3
Time Window Start	Mon, April 8, 2013 09:00	Fri, April 12, 2013 09:00	Fri, April 12, 2013 09:00
Time Window End	Fri, April 12, 2013 17:00	Fri, April 19, 2013 17:00	Fri, April 12, 2013 17:00

 

If this order bundle gets split into two during container optimization, each split containing one order release, the splits will still have the overlapping time windows and not the time windows reflected by the order releases in the split. This is important to understand as the shipments built for the first split with the first order release will start on Friday even though the order is available on Monday. More importantly, both orders might get planned on very expensive transportation modes as they have very restricted time windows. This is one reason why you might consider turning off bundling.

When the order bundle gets split during container optimization, you can choose to use the same rate record for all the splits or explore different rate records for each split. This choice is controlled by the parameter, ALLOW DIFFERENT RATE RECORDS FOR SPLIT ORDERS. Use caution when using this parameter as it has the potential to increase run time as each of the order splits will be rated against all the matching rate records. The parameter, MAX NUMBER OF RATE RECORDS FOR SPLIT ORDER, limits the number of rate records that are used in evaluating the split orders. Similarly, the parameter ALLOW DIFFERENT RATE SERVICES FOR SPLIT ORDERS allows different rate services for different splits. One split of an order release can use TL-SIM (Simulation rate service type) rate service while another split can use Day Duration.

If it is known up front that all the splits will have the same cost, you can use the parameter SAME COST PER CARRIER FOR SPLIT ORDER to reduce the computational effort in rating each and every split.

MULTILEG SERVICE TIME CALC STEP

During the shipment building process involving multi-legs, each leg option is driven several times with different start times in order to find the correct start time. The parameter MULTILEG SERVICE TIME CALC STEP specifies the interval between drive runs. For example, if the value of the parameter is 1 hour, then the shipment will be driven with start times that are separated by 1 hour. Each leg of the multi-leg itinerary will have several shipment options with different start times and they get linked optimally through a shortest path algorithm that optimizes the cost and the time between the shipments. Small values such as 15 minutes or 1 hour tend to increase the number of calls to the drive engine, potentially increasing the overall run time. Larger values on the other hand might miss opportunities to combine shipments.

MULTILEG START TIME SEARCH SPACE

The parameter MULTILEG START TIME SEARCH SPACE specifies the total time for the search. This, in conjunction with the previous parameter, determines the total number of calls to the drive engine. For example, if the MULTILEG SERVICE TIME CALC STEP is 1 hour and the MULTILEG START TIME SEARCH SPACE is 7 days, then the total number of drive call with each leg option is 7 * 24 hours in a day, or 168 calls.

Note: Use the properties glog.business.consolidation.bulkplan.orderMaxTotalWeight and glog.business.consolidation.bulkplan.orderMaxTotalVolume to preemptively fail very large orders.

Direct Shipment Building of Order Movements

The direct shipment building of order movements during bulk plan happens in one of the following ways:

1. When you select a group of order movements and run bulk plan.  
2. When a group of order releases are planned using the parameter ORDER ROUTING METHOD set to Network Routing.