Logic Configuration - Network Routing

ALLOCATE SERVICE PROVIDERS BY OM GROUP

General

6.3.6

If set to true, service provider assignment logic is used to allocate shipments for each order movement group, after shipments have been built for that group (and thus before shipments are built for subsequent order movements groups). Order movement groups are typically based on the Leg Consolidation Groups defined on the legs (itinerary or network legs).

The default is false so service provider assignment is not called until after all shipments have been built.

This logic is useful when commitment allocations, commitment counts, or capacity limits are set up specifically for legs or groups of legs that belong to the same leg consolidation group.

It is not as useful if commitment allocations, commitment counts, or capacity limits are set up on a more global level, where legs that belong to different leg consolidation groups will contribute towards the same commitment allocations, commitment counts, or capacity limits.

If the service provider assignment logic is to be used, the existing PLAN SHIPMENTS WITH CARRIER COMMITMENT parameter still needs to be turned on (true).

ALLOW MIXED EQUIPMENT GROUP ROUTING OPTIONS

General

6.3.4

When this is true, the order release action "Show Network Routing Options - Ocean", and the order movement actions "Show Network Routing Options" and "Show Network Routing Options - Ocean" as well as the "Network Rate and Route" rate inquiry option will search for solutions that mix different equipment groups on the same leg when multiple pieces of equipment are required, and will search for single equipment solutions when, for certain equipment groups, multiple pieces of equipment are required. 

When this is false, these actions will find only solutions that use the same equipment group on the same leg when multiple pieces of equipment are required.

When set to true, more time is taken for the extra logic, so this should only be used when input quantities are large enough that multiple pieces of equipment might be required for certain equipment groups.

BULK PLAN PRIMARY LEG ONLY

General

23C

Set this parameter to true to configure an order release bulk plan to create shipments only for the primary leg, and order movements for the other non-primary legs. This parameter will take effect only when Network Routing is used.

Default: false

Note: This parameter will not be used for order movement bulk plan.

CARRIER COMMITMENT PENALTY FOR ROUTE SELECTION

General

6.3.2

This parameter sets the penalty used in the MIP solver to discourage missing the percentages. This works with the USE CARRIER COMMITMENT IN ROUTE SELECTION below.

This parameter is used to enable the new logic that considers location calendars in network routing. When this is set to true, feasible routes are found for an order by taking into account the calendars defined at all locations along the route.

By default the parameter is set to false. 

DESIRED EQUIPMENT UTILIZATION PERCENTAGE

General

21C

This parameter specifies the desired minimum equipment utilization for full containers in order remnant routing. This parameter works only when PERFORM ORDER REMNANT ROUTING is set to true.  By default, the parameter DESIRED EQUIPMENT UTILIZATION PERCENTAGE is set to 80%. If the equipment utilization is equal or more than this value in at least one metric (for example, weight, volume, or ERU), the order remnant routing logic will determine the packed equipment as fully utilized.

See Order Remnant Routing.

EXPECTED COST LEG OPTIONS

General

6.3

Network routing logic, when routing orders, is not able to use certain rates that are conditional upon order quantities or dimensions. This parameter allows orders to route through legs even if network routing logic cannot use any rates for those legs. This parameter affects only how orders are routed, not how shipments are built. (Shipments can still be built using such rates).

The options are:

• Do not include expected cost leg options - This is the default. If chosen, the network routing logic will consider routing options only for the rates that it finds for each leg. The logic may miss rates that have quantity-related or dimension-related qualifications.
• Include expected cost leg options - If chosen, the network routing logic will consider routing options based upon each leg's expected cost (if non-zero) and expected transit time values (if any), as well as the rates that it finds for each leg. These expected cost options may be used by the network routing logic in place of rates that were missed.
• Include expected cost or expensive default leg options - If chosen, the network routing logic will consider routing options based upon each leg's expected cost and expected transit time values (if any), as well as the rates that it finds for each leg. If a leg has no expected cost defined (or a zero expected cost), the network routing logic will consider routing options based upon a very expensive default. These options may be used by the network routing logic in place of rates that were missed.

EXTEND LEG BY LEG OPTION

General

6.3

This is a network routing tuning parameter. The network routing logic considers different possible paths that an order may take through itineraries and routing networks.

When this is true, a greater number of possible paths are examined, because the logic will consider all possible rate offering combinations along a route.

If false, network routing will save time by considering only the best rate offering for each leg along a route. It will not consider many different combinations of rate offerings. Excessive run-time within the network routing route selection logic can be addressed by setting this parameter to false. 

HANDLE PARTLY PLANNED ORDERS

General

23C

Use this parameter to prevent bulk plan with Network Routing from resulting in partly planned order releases by disbanding (removing) each shipment graph that includes a partly planned order.

The parameter can take up the following values:

• Allow Partly Planned Orders: This will allow the application to create partly planned order releases.
• Disband All Related Shipments: This will remove any shipment graph that includes a partly planned order.

If the value "Disband All Related Shipments" is set for this parameter, the result will be the following:

• Any order that would have been partly planned will fail to plan
• Any other order that was to have been planned with the partly planned order will also fail planning (even if it would have been fully planned).
• For the orders that fail planning:
  • They will take the status PLANNING - FAILED.
  • No order movements will be created (including network routable order movements).

Default: Allow Partly Planned Orders

Note: This logic is applicable only for order release bulk plan with Network Routing.

Note: If the Network Routing parameter BULK PLAN PRIMARY LEG ONLY is set to true, the parameter HANDLE PARTLY PLANNED ORDERS will be ignored.

When finding routes in a multi-leg scenario, if the order window is large and the route involves legs with consol shipments at different times, using "Shortest Path" as PATH FINDER ALGORITHM should be allowed to consider multiple consol shipments.

This parameter allows all the consol shipments within a certain threshold of time to be considered as valid options. This ensures consol shipments that start later but still arrive within the order window time are not eliminated. This threshold number of days is controlled by this parameter.
Default is 1.

When finding routes in a multi-leg scenario, if the order window is large and the route involves legs with ground schedule shipments at different times, using "Shortest Path" as PATH FINDER ALGORITHM should be allowed to consider multiple ground schedule shipments.

This parameter allows all the ground schedule shipments within a certain threshold time from the earliest ground schedule shipment time to be considered as valid options while finding a route. This ensures that cheaper options with ground schedule shipments, that start later but still reach within the order window time are not eliminated, thus, not generating costlier options. This threshold number of days is controlled by this parameter.
Default is 1.

MAX NUM SHORTEST PATHS

General

6.3

This parameter is used when Iterative Shortest Path value is used for the Path Finder Algorithm in the Show Network Routing Options action or when the PATH FINDER ALGORITHM parameter is set to Iterative Shortest Path.

This parameter indicates the number of different paths that network routing will try to generate with the Show Network Routing Options action. The actual number of paths returned may be different from the value of this parameter. The actual number may be higher if in its last iteration the logic finds more paths than needed when running, but will not use additional run-time to find more paths.

The default is a large number in order to be able to find different combinations of equipment and service provider along similar geographic paths.

MAX PATH LENGTH

General

6.3

This is a constraint on how many legs network routing can send an order on between its source and destination. For example, a Max Path Length of 2 would allow an order to go through one cross dock in a network (with one shipment into the cross dock and another out of the cross dock), but would not allow an order to go through two cross docks in succession (because this would require more than two shipments: one into the first cross dock, one from the first to the second cross dock, and one from the second cross dock). This parameter can be used to limit the types of routes that the network routing logic will consider, even if the routing network itself has longer paths within it.

PATH FINDER ALGORITHM

General

6.3

This controls the algorithm for finding a route through the network. The choice of algorithm trades off run-time and solution quality.

The options are:

• Enumeration: This will consider all possible paths between an order's source and destination. Typically, this will be a reasonable setting only if EXTEND BY LEG OPTION is false.
• Shortest Path: This can be used for small and medium sized networks.
• iterative Shortest Path: This can be used for small, medium and large networks. It works in combination with the MAX NUM SHORTEST PATHS parameter.

Note: The Show Network Routing Option action will always use the Iterative Shortest Path logic regardless of this parameter.

PERFORM DYNAMIC CLUSTER LOGIC FOR DEST REGIONS

PERFORM DYNAMIC CLUSTER LOGIC FOR SOURCE REGIONS

General

6.3

When either or both of these parameters are set to TRUE, the dynamic clustering algorithm will be performed at the beginning of route selection for the orders. Multistop logic will be used for each set of orders starting (or ending) in the same region, in order to determine good multistop shipment opportunities for pickups (or deliveries) within those regions. The dynamic clustering algorithm simulates single stop and multi-stop consolidations on all applicable first legs (if PERFORM DYNAMIC CLUSTER LOGIC FOR SOURCE REGIONS is TRUE) and last legs (if PERFORM DYNAMIC CLUSTER LOGIC FOR DEST REGIONS is TRUE) of the orders to determine the realistic costs and transit times at the source and destination locations of the orders. This results in a more accurate estimate of the true cost and travel times for the orders from order's source location to first leg's destination and last leg's source location to order's destination location - which translates to better routing decisions. Since consolidations are done at the source and destination legs, the overall run time is expected to be higher.

If these parameters are FALSE, OTM still looks at the order's transit time from the order's source location to the first leg's destination location and the order's transit time from the order last leg's source location to order's destination location. However, unlike in the case when the parameters are TRUE, estimated transit time and costs based on single and multi-stop dynamic clustering logic is not performed.
These default to FALSE.

Network Routing logic makes some assumptions in order to simplify the order routing problem. These include:

• the use of abstracted costs to model in simplified way the actual rated costs on legs,
• the use of regions at routing network source and destinations to represent consolidation opportunities in a simplified way.

These assumptions may be justified in many business scenarios.

Use of dynamic clustering is recommended when:

• The correct routing decisions depend in part on determining the correct multistop shipments on the pickup or delivery legs, because:
  • multistop consolidation opportunities cannot be known without considering the actual multistop shipment costs, and/or
  • time-feasible transit through the network cannot be known without considering the actual multistop shipment transit times.
• Higher bulk plan run-time is acceptable.(when additional run-time is not a problem, dynamic clustering can be used in order to better represent multistop consolidation opportunities and costs. Dynamic clustering uses the OTM multistop logic in order to analyze multistop consolidation opportunities within the routing network source and destination regions. This analysis includes a consideration of true transit times during multiple pickups or deliveries, as well as true rated cost of multistop shipments).

Consider the following cases, in which orders are picked up at different sources and sent into a throughpoint hub to be routed through the network to their destinations:

• If each source location is assigned to one specific hub, then dynamic clustering is not needed, because there is only one pickup leg. No decision is needed about which pickup leg to use.
• If, for a source location, there is a choice of hubs to which to send the orders, then dynamic clustering will be useful, because the pickup shipments will have different timing or cost characteristics depending upon which hub they go to.

Note: This should be enabled if using USE LEG CONSOLIDATION GROUPS IN ROUTE SELECTION.

Note: Dynamic Clustering will only work on an itinerary with a Routing Network.

PERFORM ORDER REMNANT ROUTING

General

21C

This parameter must be set to true to turn on the order remnant routing logic in network routing. By default, this logic is turned off.  Use this logic in certain planning scenarios to split orders along different routes to save cost.

See DESIRED EQUIPMENT UTILIZATION PERCENTAGE.

See Order Remnant Routing.

RESTRICT OM TIME WINDOWS

General

20B

This parameter allows Network Routing logic to compute more accurate time windows for use in order movement bundling.

When this parameter is set to true, the logic uses leg-related data to more accurately determine late pickup and early delivery times for order movements, which are then used to determine how order movements can be bundled.  There is no performance penalty when setting this parameter to true.

The default is false.

ROUTING LOGISTICS GUIDE TEMPLATE GID

General

6.3

This parameter indicates which Logistics Guide Template is to be used by the Network Routing logic when considering quantity-based rates. The Logistics Guide Template defines which quantity-breaks are to be used when considering quantity-based rates (such as weight-based, volume-based rates or ERU-based rates).

The default is “ROUTING LOGISTICS GUIDE TEMPLATE DEFAULT” and has weight breaks for parcel and LTL.

Note: A zero or a negative quantity for weight, volume, or ERU count in the ROUTING LOGISTICS GUIDE TEMPLATE is considered invalid as this can create issues in the routing of orders.

ROUTING REGION GROUP GID

General

6.3

This parameter indicates which Region Group is to be used by Network Routing logic when it considers how to route order releases through itineraries. Order release source or destination locations that match to the same region within the Routing Region Group are considered geographically similar to one another so that the Network Routing logic can reduce the complexity of the network routing problem. Order release source or destination locations that do not fall into any region within the Routing Region Group will not be considered similar to any other location, but the Network Routing logic will still consider these locations.

ROUTING SOLUTION METHOD

General

19B

Some bulk plan planning scenarios (Bulk Plan with Work Assignments or Network Modeling Bulk Plan) use network routing but may not have any routing decisions. This parameter can save run time by disabling the logic associated with the network routing. The following values are available:

• Optimize: Rate the network and go through network routing optimization (including shortest path and route optimization logic). This is the default.

• Simple Solve With Rating: Rate the network, but do not optimize (goes through shortest path, but not the route optimization logic). This option is the same behavior as  when the property glog.optimization.networkrouting.useSimpleSolve is set to true.

• Simple Solve With No Rating: Do not rate the network, and do not optimize (goes through shortest path, but not the route optimization logic). Instead of rating, OTM will create a single network routing leg option for each network routing leg, with a container cost = 1 (or the Leg Estimated Cost, if any).

SAVE ORDER MOVEMENTS

General

6.3.2

Enables you to create the unplanned network leg order movements as well as the unplanned itinerary leg order movements. The following values exist:

• Build Shipments and Save All Order Movements: Network routing will create and save shipments and all order movements. This is the default.
• Save All Order Movements without Building Shipments: Network routing will not create shipments, but will create and save all order movements (including network leg order movements). These order movements will indicate how the order release has been routed through the entire network, including any routing networks.
• Save itinerary Leg-Level Order Movements without Building Shipments: Network routing will not create shipments and will save only the itinerary leg-level order movements. If an order release has been routed through a routing network, only the network routable order movement will be saved (which does not indicate how it may be routed through the routing network).

SET OM WINDOWS FOR SPECIFIC PATH

General

6.3.6

When this parameter is true (default), OTM will create order movements with more restrictive time windows, based on a specific rate service and/or schedule choice on each of the legs.
When this parameter is false, the order movements will be created with less restrictive time windows, based on all feasible rate service and/or schedule choices on each of the legs.  
A setting of true may be useful when the correct choice of schedule on one leg may depend upon the correct choice of rate service on another leg. For example, in a multi-leg land-ocean-land scenario, when, the ocean leg being planned first, the choice of which voyage to use should depend upon the choice of the carrier that brings the order to the port on the leg previous to the voyage leg.

USE CARRIER COMMITMENTS IN ROUTE SELECTION

General

6.3.2

This parameter allows allocation commitments to be considered in route selection. For examples of use cases, see Allocation Commitments in Network Routing.

USE LEG CONSOLIDATION GROUPS IN ROUTE SELECTION

General

19B

This parameter enables consideration of cross-leg consolidation in routing. The default is true. The following parameters should also be enabled for this logic to work.

ALLOW DIFF ORIG LEG GID OMS CONSOLIDATE

PERFORM DYNAMIC CLUSTER LOGIC FOR SOURCE REGIONS / PERFORM DYNAMIC CLUSTER LOGIC FOR DEST REGIONS

See also Leg Consolidation Group.

When this parameter is true, the network routing logic will use a multiple iteration solve process to decide both which legs to use and how that choice interacts with equipment group selection and capacity constraints. Setting this parameter to false disables the multiple iteration solve.

By default, this parameter is set to true.

USE PATH FINDING FOR PRE RATING

General

6.3.7

When this parameter is true, the network routing logic will determine which itinerary or network legs can be used by the orders, and will rate only those legs. This can help improve performance in scenarios with many legs when the orders will not be able to use most legs (due to geography or routing constraints), so that to rate all of the legs would waste processing time.
It should not be used in networks where there are very many possible paths (e.g., thousands) that an order might take.
This runs before the network routing logic rates the network.

USE ROUTING CONSTRAINT FOR PORT SELECTION

General

6.4.1

This enables the use of routing constraints to specify allowable ports of load and ports of discharge as a constraint for an order release. The routing constraints will limit the selection of ports for both the routing choice of legs (port-to-port move as a separate shipment) as well as via point selection (shipment with arbitraries). The sequence number value on the Routing Constraint manager will indicate whether the specified ports should be treated as ports of load or ports of discharge.

Valid values are:

• False (default): The network logic will consider only shipment start/end locations when enforcing routing constraints.
• True: The network routing logic will consider also shipment via point stops when enforcing routing constraints, as well as shipment start/end port locations. There are restrictions on routing constraint configuration.

This parameter does not apply for Show Network Routing Options; neither order release nor order movement (but does apply for Show Network Routing Options-Ocean).

This parameter also allows rate inquiry for ports of Load and Ports of Discharge.

See the topic Ports of Load/Ports of Discharge Routing Constraints.

USE ROUTING SOLUTION ORDER MOVEMENT CONSTRAINTS

General

20A

This parameter control whether the choices selected by network routing are persisted as constraints on the order movement. The default is FALSE. The constraints impacted are Transport Mode ID, Service Provider ID, Rate Record ID, Rate Offering ID, Equipment Group ID.

USE TIME-DEPENDENT TRANSIT TIME

General

6.4.3

When this is set to true, network routing will consider start time-dependent transit times. The default is false.

In Network Routing, OTM computes transit times for the leg options only once and uses those times throughout the route-finding logic, assuming that they remain the same regardless of different start times on the leg. This can cause incorrect results in case of transport modes (e.g. PARCEL) where transit times can change significantly based on the start time. For example, a ground parcel shipment starting on Monday usually spends 4 days in transit and gets delivered on Friday, whereas the same parcel shipment will take more time (up to 6 days) if started on a Thursday, due to the weekend.

Network routing can consider time-dependent transit time if using TIMEDEFINITESERVICE or DAYDURATION rate service types. To do so, this parameter must be set to true.

Additionally, since it is not practical for OTM to call the external rating engine (for TIMEDEFINITESERVICE) to get the transit time for every start time and every order, OTM will compute these times by taking into account the calendar that mainly influences time-dependent nature. For this rate service type, this calendar is usually set up with the external rating engine. You will need to specify the same calendar on the rate service.

VALIDATE FOR SHARED EQUIPMENT ON PRIMARY LEG

General

6.3.2

When this is on (set to true), OTM requires that the planning of order movements on primary legs happens before the planning of non-primary leg order movements which share equipment. It only pertains to network routing planning.

When enabled, OTM will prevent the planning of a non-primary leg order movement if the leg shares equipment with a primary leg where the corresponding order movement has not yet been planned. It will not affect the scenario when primary and non-primary shared equipment leg order movements are selected for the same bulk plan. This enhancement will affect bulk plan and other planning actions when the primary leg shared equipment order movements are not selected for planning.

It will not affect the planning of order movements on legs that do not share equipment.

For example, a container is: (1) taken to a port on a drayage leg, (2) then shipped across the ocean on the ocean leg, and (3) then taken from the port on a drayage leg. In this case, the ocean leg is usually the most important of the three legs. It generally would not make sense to plan the drayage leg first before the ocean leg since you would not know when the vessel was scheduled to sail.

The default is false.

WRITE ROUTING SOLVER INPUT XML

General

6.3

This parameter indicates whether the Network Routing Solver input should be written as an XML file. The input XML file can be used by OTM Support to analyze how the Network Routing Solver produced its solution. This parameter should be turned on only when you particularly want this file to be created. The setting of this parameter will not affect the solution.

WRITE ROUTING SOLVER OUTPUT XML

General

6.3

This parameter indicates whether the Network Routing Solver output should be written as an XML file. The output XML file can be used by OTM Support to analyze how the Network Routing Solver produced its solution. This parameter should be turned on only when you particularly want this file to be created. The setting of this parameter will not affect the solution.