Order Base/Release: Constraints

This page is accessed via:

• Order Management > Purchase Order > Order Base. Click the Constraints tab.
• Order Management > Order Release > Order Release. Click the Constraints tab.

Note: Most of the fields are the same on the order base and the order release. Any fields that are different between the two will be noted as such on a per-field basis.

Oracle Transportation Management provides a variety of constraints that you can place on an order (order-level constraints) or itinerary leg (leg-level) that help you control how orders are bundled and how shipments are created for orders. For example, these constraints let you determine which service provider is used, control the transportation mode, dictate that cost of shipping an order by choosing a specific rate, and determine whether orders should be planned through cross-docks or distribution pools.

If you decide not to use these constraints (itinerary, rate, and service provider), Oracle Transportation Management's optimization engine determines the best choice during the shipment planning process.

Note: Order-level constraints only impact the planning of the primary leg. Leg-level constraints can be used to influence the planning of any other itinerary leg.

Note: If you decide to use the constraints for rate offerings and itineraries, these entries override the "Active" state of those business objects as well as any effective or expiration dates that have been recorded for the business object. For example, if you specify a rate offering that is marked as inactive in the Rate Manager, Oracle Transportation Management will assign the Rate Offering that you specify regardless of the fact that it is marked inactive. The assumption is that these constraints always take precedence.

Adding Constraints

1. Buy Fixed Itinerary field identifies the itinerary that is used to plan the shipment for the order.
2. Sell Fixed Itinerary field identifies the itinerary that is used to create a bill for the order/shipment.
3. The Buy/Sell Itinerary Profile fields can be used to identify groups of itineraries that are used to create a bill for the order/shipment. These fields only appear on the order release.
4. Buy Rate Offering ID identifies the specific rate offering that is used to rate the shipment for the order.
5. Sell Rate Offering ID is used to create a bill for the order/shipment. If you enter a rate offering ID, then any rate record associated with the rate offering can be used.
6. Click the Get Buy Rate or Get Sell Rate to obtain rates for your order release.
7. Effective and Expiration date fields (on an order base only) can be used to constrain when order releases are created from the order base. If you leave these fields blank, Oracle Transportation Management follows the typical rules for order release creation.
8. Buy Rate Record ID identifies the specific rate record (for a particular rate offering) that is used to rate the shipment for the order.
9. Sell Rate Record ID is used to create a bill for the order/shipment using a specific rate record within a rate offering.
10. Equipment Group identifies a specific equipment group that is used when building a shipment for the order.
11. Equipment Group Profile considers the set of equipment groups in the profile when building shipments for the order.
12. Equipment Type ID specifies the equipment type to use when building a shipment for the order.
13. Transport Mode identifies a specific transportation mode (as opposed to a list of transportation modes defined in a profile) when building a shipment for the order.
14. Mode Profile only considers a set of transportation modes included in the profile when building a shipment for the order.
15. Buy Service Provider determines the specific service provider that can be used when building a shipment for the order. When Oracle Transportation Management bundles orders and builds shipments, it checks that there is an intersection between the service provider value identified on the order base.
16. Buy Service Provider Profile field only considers a set of service providers included in the profile when building shipments (as opposed to specifying a single service provider discussed in the previous paragraph).

    Note: If you use either one of these service provider constraints, you must have at least one rate offering for the service provider to successfully build a shipment from the order.

17. Sell Service Provider is used by planning when building a sell side shipment from this order.
18. Sell Service Provider Profile field is used by planning when building a sell side shipment.
19. The Rate Service ID field identifies a specific rate service that is used when building a shipment for the order.
20. The Rate Service Profile sets up a list of rate service types. Only rates that have the service levels identified in that profile are used during the shipment planning process. When Oracle Transportation Management bundles orders and build shipments it checks that there is an intersection between the rate service values identified on the orders.
21. Date Emphasis governs how the order release Early/Late Pickup Dates and Early/Late Delivery Dates are used. It takes into account some parameter settings.
22. The Ignore Location Calendar check box will cause the system to ignore the constraints set by the location's calendar.
23. The Allocation Group ID field allows you to constrain by allocation group.
24. Must Ship Thru Cross Dock is a process where product is received in a facility, occasionally married with other products going to the same destination, then shipped at the earliest opportunity without going into long-term storage.
    
    If checked, any order release that is created from this order base must ship through a cross-dock. You can only use this constraint if you create itineraries that support cross-dock planning.
25. Must Ship Thru Pool is a process of freight consolidation when customers have multiple orders going to the same consignee, each with a different purchase order. It can also involve the shipment of multiple orders on a single truckload to a distribution center and then subsequent deliveries within those geographic territories. This allows customers to gain freight savings by having only one truckload rate and the local drayage versus multiple LTL shipments.
    
    If checked, any order release that is created from this order base must ship through a distribution pool. You can only use this constraint if you create an itinerary that supports distribution pool planning.

    Note: Orders must be planned using the Bulk Plan action to be considered for this type of consolidation.

26. Must Ship Direct is the traditional transportation method when no cross-dock or distribution pool is needed. If checked, order releases created from this order base must ship direct or multi-stop from the source location to the destination location. If you have not configured an itinerary to support cross-dock or distribution pool planning, Oracle Transportation Management automatically assumes this planning constraint.
27. Select a Bundling Type from the drop-down list. If you select "Do Not Bundle", it will prevent orders that would naturally bundle together from being built on to the same shipment. Use the Do Not Bundle option only if you need to explicitly prevent orders that would naturally bundle together from being on the same shipment. This will impact multi-stop shipments.

    Note: If you are working with an order release for a multi-stop shipment, the Bundling Type field will be read only and will be set to Do Not Bundle.

28. The Routing Constraint ID identifies routing constraints that apply to this order release.
29. The Allow Equipment Consolidation check box determines how order release equipment is handled during bundling and allows order releases which have equipment specified to be bundled together.
30. Ship With Group: For non-multistop functionality, this acts as an order planning constraint to prevent orders in a given bulk plan with non-identical Ship with Group values from bundling into shipments. A value of "null" (default) will bundle with all other orders with a value of "null" but will not be considered a bundling candidate for an order with the Ship with Group field populated with any value. Similarly, multiple orders in the same bulk plan with identical Ship with Group values will be considered candidates for consolidation, while other orders in that same bulk plan with different Ship with Group values will not.
    
    For multi-stop scenarios, the Ship with Group functionality can be influenced by the MULTISTOP CONSOLIDATION logic parameter MULTISTOP FAVOR SAME SHIP WITH GROUP. In addition, the MULTISTOP SAME SHIP WITH GROUP EMPHASIS logic configuration parameter is used to further incent the multi-stop logic to consolidate orders with the same Ship with Group value. Also see the property “glog.business.consolidation.bulkplan.favorSameSWGConsolidation”.
31. Pickup Rail Carrier and Delivery Rail Carrier: (located on the Order Release Manager Constraints tab only). In some cases, the least cost rate is not desirable for service related issues. This provides the ability to assign delivery and pickup rail carrier on an order to apply constraint.
32. If you wish to constrain the order based on a rail route, use the Rail Route Code field to record the code to be used.
33. Pickup Routing Sequence and Drop off Routing Sequence control the routing sequence; how Oracle Transportation Management plans the sequence of shipment stops that are built from an order base.
34. Once a release order is planned and a shipment is successfully created, Oracle Transportation Management completes the Buy/Sell Assigned Itinerary fields with the ID of the itinerary that was used. You can view the details of the itinerary using the Itinerary Manager.
35. Leg Consolidation Group ID constrains by leg consolidation group.
36. Early Sail Date: The early sailing date and time is used as a constraint when planning the order release onto a buy shipment on the primary leg. This constraint only applies when the primary leg contains a voyage. This date is applied against the departure time from the source port of the voyage.
37. Late Sail Date: The late sailing date and time is used as a constraint when planning the order release onto a buy shipment on the primary leg. This constraint only applies when the primary leg contains a voyage. This date is applied against the departure time from the source port of the voyage.

Note: These dates do not override order release time window.  The order release pickup and delivery time windows together with the parameter Order Window Time Span must be compatible with the early and late sail dates for the shipment to be scheduled successfully.  

Note: If early or late sail dates or voyage ID is defined on order; when this order is on a consol shipment with the voyage ID, the consol shipment must leave between the sail dates i.e., first stop departure must be between early or late sail date.  Voyage ID on the consol shipment must be same as the voyage ID on order.  If the order is planned on a consol shipment without voyage ID, the system will ignore the sail dates and voyage ID on order.

38. The Voyage ID is used as a constraint when planning the order release onto a buy shipment on the primary leg. This constraint only applies when the primary leg contains a voyage.
39. External Voyage Code indicates the voyage number.

Constraints

Click New Order Release Constraint or New Order Base Constraint to create leg classifications that can be associated with a set of leg-level constraints that are then assigned to a specific leg of an itinerary.