Multiple Sourcing Options

Oracle provides sourcing rules and bills of distribution to model multiple sources, including splitting production or purchases across plants or suppliers. These sourcing rules and bills of distribution are assigned to items, organizations, or categories using Assignment Sets.
Both sourcing rules and bills of distribution use effectivity dates to let you project changes to your supply chain over time. The effectivity date initially defaults to the system date; like effectivity dates in routings or bills of material, a “null” ending date means that the effectivity of the rule has no projected end.

1. For each effectivity range, you define the sourcing options associated with the rule. There are three possibilities:

Make At This option specifies that you will make any items associated with the rule at the receiving organization.

Buy From This option indicates that you will buy any items associated with the rule from a specified supplier. With the Buy From option, you must enter the appropriate supplier, and optionally, the supplier site.

Transfer From This option specifies a different organization within your enterprise as the source of items associated with this rule. With the Transfer From option, you identify the source organization; you must have already defined the shipping network between the source and receiving organization. You can also select a ship method from the shipping methods you defined in your shipping network; this will determine the in-transit time and shipping cost, which planning will use in its calculations.

2. Though the mechanics of defining sourcing rules and bills of distribution are much the same whether you’re running ASCP or SCP, they operate very differently based on your planning method and options.

For ASCP, you assign each option a priority code/Rank. A priority code serves as a method for defining multiple sourcing scenarios—all the options within a single priority code will be considered as a unit. Within a priority code, you assign a percentage to each sourcing option. For example, if you have a group of items that you plan to buy from two different suppliers, you might define a sourcing rule with two “buy from” options within the same priority, specifying 50 percent for each supplier. If an alternate scenario for the same set of items is to buy from a single supplier, you would define a second scenario (priority) within the same sourcing rule, assigning the single supplier 100 percent of the purchases. Within a single priority code, the percentages must total 100 percent, or the group of options will not be considered by planning.

For SCP, the entire rule is treated as a single scenario; each option typically has a different priority code, which is used to “break a tie” if two options have identical planning percentages

You can define sourcing rules, bills of distribution, and assignment sets in your ERP instances; they will be collected with other planning data in the data collection process. This approach makes sense if you have only one source instance, or if you want to use the same sourcing rules for other functions within your purchasing system. For example, you may want to use the same sourcing rules in your supplier item catalog that you use for planning.
You can also define sourcing rules, bills of distribution, and assignment sets on the planning server itself; this approach is useful if you will be planning for data collected from multiple ERP instances.

3. Sourcing and Assignment APIs
Oracle provides two APIs to create sourcing information—the Sourcing Rules/Bill of Distribution API and the Sourcing Rules/Bill of Distribution Assignment API. Their use is described in the Oracle ASCP and Global Order Promising Technical Reference Manual, available as part of the Oracle documentation library.