You can review the parameters related to the sourcing of products only. There are other parameters defined as part of scheduling rules that are used for date determination purposes.
Scheduling rules are set up at an Enterprise level. Sterling Selling and Fulfillment Foundation uses the rule defined by the Enterprise of the order transaction. When using an on-the-fly inquiry, Sterling Selling and Fulfillment Foundation uses the rule defined by the primary Enterprise of the organization code making the request.
This parameter can be used to turn node prioritization on or off based on the distance between the node and the ship-to location. If "Use geography" is set to "Yes" and you are optimizing node selection based on "Priority", Sterling Selling and Fulfillment Foundation calculates the node priority as:
Weight factor for distance * distance in miles as calculated based on longitude
and latitude + Weight factor for priority * priority setup in the distribution
node group.
This combined priority is used to select the node that has the lowest priority number. The weight factors are also set up as part of the scheduling rules.
If you want to give first preference to the node priority setup, you would want to set up the weight factor of "Priority" as 100,000 irrespective of the distance that is given the first preference. When the priorities of two nodes are the same, the distance is the tiebreaker. If you want to give distance more importance, you set up the weight factor for priority as 0 or another low number. You can work out the weight factors and priority numbers you want to use based on the fact that the distance (in miles) calculation is done internally.
When multiple nodes and dates are available for sourcing, this parameter can be used to make sourcing selections based on:
The optimization type that is required can be set as part of the scheduling rules. The following optimization types can be set:
Distribution Group Passed on Line DG1: N1 – Priority 1, N2 - Priority 10.
Final leg shipping cost from N1 is $10, from N2 it is $2 (assuming no other costs are being used).
The optimum solution is N2.
After the node priority cost factor is enabled,
Priority Cost Factor - $1
Option1 - N1 - 1*$1+$10=$11
Option2 - N2 - 10*$1+$2=$12
The optimum solution is N1 as it has the lesser cost and a low priority of node.
The previous figure illustrates how the windows refer to the optimization date range, which is configured as 5 days. The items are available on various dates. Item1 is available on 2/3/06 and continues to be available until 2/15/06. Similarly, the Item2 is available on 2/6/06 and Item3 on 2/8/06 until 2/15/06. Item 4 is available only on 2/15/06. If the customer places an order for all the items, and has agreed to wait for the shipment, the items are consolidated in one shipment and is shipped on 2/15/06 which reduces the cost of multiple shipments. This applies the rule of Date Range Optimization Logic. But if the customer wants the items to be shipped when they are available, the shipment optimization is considered and the customer is shipped items1 and 2 at the earliest date 2/6/06 which falls within a single window.
A Delay window can be specified at the item level to account for high ticket items. This window can be set to 0 days which means that the product is never delayed. You can also choose not to delay shipments to be consolidated with future inventory since information (dates) about future inventory is often not accurate. This ensures that onhand and procured inventory is shipped immediately.
When scheduling, the landed cost options are evaluated to determine the least landed cost, which is used as the cost-based option. Landed cost is prorated to reflect landed cost per unit. The priority is configured in the scheduling rules. In addition to the various costs listed previously, the priority can be converted into cost using the cost factor. For example, if a node within a distribution group has a lower priority (higher priority number), the node will contribute more to the cost, compared to a higher priority node.
To determine the best cost-based optimization type, a higher number of solutions should be evaluated. To evaluate a higher number of solutions, you can increase the MaximumRecords in the promising and scheduling APIs. If date optimization is used, cost-based scheduling will not be used because the fastest option will be considered first.
Cost-based scheduling: An example
In the following example, landed cost is computed for a given option. Let us assume that a customer orders a DVD player and three DVDs. The DVD player is available at DC1, and the DVDs are available at DC2. In this case, the schedule has two options:
Because option 2 is less expensive, it is selected by the schedule as the cost-based schedule option. The options are described in the following sections.
Option 1
Assuming that all the costs are configured, the landed cost for option 1 is computed as follows:
(Total Item Cost + Outbound Handling Cost + Final Leg Cost) / Total Units
If this equation is used, the landed cost for shipment 1 is $120.50, as shown in the following calculation:
(1 unit * $100 (average cost) + $3 (per shipment) + $17.50 (ground shipping to customer)) / 1 unit = $120.50
(Item Cost + Outbound Handling Cost + Final Leg Cost) / Total Units
If this equation is used, the landed cost for shipment 2 is $14.33, as shown in the following calculation:
(3 units * $10 (average cost) + $3 (per shipment) + $10 (ground shipping to customer)) / 3 units = $14.33
The calculations for shipment 1 and shipment 2 are added together in order to determine the landed cost to fulfill option 1, which is $124.83.
Option 2
Assuming that all the costs are configured, the landed cost for option 2 is computed as follows:
(Total Item Cost + Outbound Handling Cost) / Total Units
If this equation is used, the landed cost for shipment 2 is $106, as shown in the following calculation:
(1 Unit * $100 (average cost) + $3 (per shipment) + $2 (fixed transfer cost between DC1 and DC3) + $1 (per shipment at DC3)) / 1 Unit = $106
(Total Item Cost + Outbound Handling Cost + Transfer Cost + Inbound Handling Cost) / Total Units
If this equation is used, the landed cost for shipment 2 is $11.67, as shown in the following calculation:
(3 Units * $10 (average cost) + $3 (per shipment) + $1 (fixed transfer cost between DC2 and DC3) + $1 (per shipment at DC3)) / 3 Units = $11.67
(No Inventory Cost (items/are procured) + Outbound Handling Cost + Final Leg Cost) / 4 Units
If this equation is used, the landed cost for shipment 3 is $3.33, as shown in the following calculation:
($3 (per shipment) + $7 (ground shipping to customer from DC3)) / 3 Units = $3.33
The calculations for shipment 1, shipment 2, and shipment 3 are added together in order to determine the landed cost to fulfill option 2, which is $121.
This parameter ensures that all product lines in the promising inquiry request are either completely scheduled or not scheduled at all. Lines could, however, be sourced from different shipping locations.
This parameter ensures that all product lines in the promising inquiry request are either completely scheduled or not scheduled at all. It also ensures that the complete request is sourced from a single node on a single date. This is a super set of "ship complete order" and when this parameter is set, a "ship complete" is assumed.
This parameter ensures that every product line on an individual line basis is either completely sourced or not sourced at all. However, lines could be sourced from different shipping locations. The difference between this rule and the "ship complete order" rule is that this rule does not enforce that all lines of the request are completely sourced. One particular line can be sourced while another line of the same request could be backordered.
This parameter ensures that every product line in the inquiry request is either completely scheduled or not scheduled at all. It also ensures that each individual line is sourced from a single node on a single date. This is a super set of "ship complete line" and when this parameter is set, a "ship complete line" is assumed. However, this rule does not enforce that all lines are shipped from the same node. A particular line may be completely shipped from node 1 while another line could be completely shipped from node 2.