Validate End-to-End Planning Relationships

Welcome back. In the previous lesson, you configured the Oracle Fusion planning source system and ran targeted collections. You proved that organizations, items, inventory, orders, and other planning inputs had reached the Planning Data Repository.

That is necessary, but it is not sufficient. A plan can contain all the right records and still make implausible recommendations if the relationships between them are incomplete or if the wrong sourcing assignment wins. This lesson gives you a repeatable validation method for the item, organization, customer, supplier, and sourcing relationships that turn collected data into an executable end-to-end planning network.

By the end, you should be able to demonstrate, in your practice environment, why Planning will choose a particular make, buy, or transfer source for an item at a particular location and date.

---

Treat planning relationships as a connected network

An end-to-end planning flow is not a list of master-data objects. It is a network in which each object plays a distinct role:

Object	Question it answers	Evidence to validate
Organization	Where does demand occur, inventory reside, supply originate, or manufacturing happen?	Organization is collected, enabled, correctly modeled, and available in the network.
Item-organization	Which item can be planned at this particular node?	Item exists at every organization where it is stocked, made, transferred, bought, or demanded.
Customer and customer site	Who creates independent demand, and which customer-specific sourcing rule might apply?	Customer/site is collected and correctly associated with the demand context.
Supplier and supplier site	Which external source can provide an item?	Supplier/site is collected and usable in a Buy From sourcing rule.
Sourcing rule or bill of distribution	How can the item be supplied?	Source type, source node or supplier, rank, allocation, and effective applicability are correct.
Assignment set	Which sourcing definition applies to this item, category, organization, or demand segment?	Intended assignment is present and resolves as the active rule for the plan context.

The practical unit of validation is therefore not simply “item F100 exists.” It is a statement such as:

“Item F100 is planned at DC1. Demand at DC1 is replenished by a transfer from Plant M1 under assignment set AS_GLOBAL, and the sourcing resolution for the planning date identifies that transfer rule as active.”

That statement is testable. “The item and rule were collected successfully” is not.

---

Start with the collected network: organizations, customers, and suppliers

The Maintain Supply Network Model page is the first place to validate whether the actors in the network exist in Planning. It is especially useful because it brings organizations, customers, suppliers, carriers, and interlocation shipping networks into one review area.

1. Validate each organization as a planning node

Navigate to Tasks and open Maintain Supply Network Model. On the Organizations tab, search for each organization in your controlled scenario: for example, Plant M1 and Distribution Center DC1.

For each organization, confirm:

• it is associated with the expected planning source system;
• its organization code and description identify the intended business role;
• the organization time zone is sensible for its physical operating location;
• the organization is included in the intended planning scope;
• it is not being used ambiguously to represent unrelated operations.

Oracle permits one physical facility to be represented by multiple organizations when it performs different functions, such as manufacturing and distribution. That distinction can be crucial. A manufacturing plant and a DC in the same building may still need separate planning organizations if inventory, supply, demand, or execution responsibility differs.

2. Validate items at every relevant organization

Planning does not source an item merely because its master-item definition was collected. The item must be usable at the relevant planning organization.

For a simple plant-to-DC scenario, validate that finished good F100 exists at:

• Plant M1, where it is manufactured or supplied;
• DC1, where it is stocked and where customer demand is planned;
• any intermediate DC or destination organization included in the actual supply path.

Use the relevant Plan Inputs item table and search by item and organization. At this point, focus on relationship evidence rather than doing a detailed planning-attribute review, which will be covered in the Supply Planning module:

Check	Why it matters
Item exists at the destination organization	Demand, inventory, and planned replenishment cannot be interpreted correctly without the destination item-organization record.
Item exists at the source organization	A transfer or make source must refer to a source node where the item can be supplied.
Unit of measure is consistent	Quantity relationships fail operationally when the planning and execution quantities cannot be interpreted consistently.
Category assignment is correct, if category sourcing is used	A category-level sourcing assignment cannot apply if the item is absent from the expected category in the assignment set’s catalog.
Planning status supports the intended use	An item that is inactive or not usable for the process should not be relied on as a valid plan input.

A frequent implementation error is validating only F100 at DC1 because that is where the sales order exists. The plan may then see demand but lack a valid upstream node from which to create supply.

3. Validate customer and supplier sites, not only names

A customer or supplier header record alone may be too general for planning. Where demand or supply is site-specific, validate the applicable customer site or supplier site too.

This matters for two reasons:

1. Sourcing can be more specific for a particular customer or customer site.
2. Time zones at customer and supplier sites affect the interpretation of demand and supply dates if no separate time zone is assigned.

For an external procurement flow, validate that the supplier and supplier site shown in Planning match the supplier and site that will be selected by the Buy From source rule. Do not configure a generic supplier relationship and assume the correct site will be inferred.

Internal transfer versus internal buy-sell transfer

Keep these two patterns distinct in an interview and in design documentation.

Pattern	Planning relationship	Execution representation
Interorganization transfer	A Transfer From sourcing rule identifies the source organization.	Interorganization shipping transfers material between internal organizations.
Internal buy-sell transfer	The source organization is modeled as a supplier, and the destination organization is modeled as a customer.	A sales order at the shipping organization supports shipment; a purchase order at the receiving organization supports receipt.

Do not add customer-supplier organization associations merely because there is an ordinary transfer path. Add them when the business executes the movement as a buy-sell relationship using internal sales and purchase documents.

---

Validate the rule, then validate its assignment

A sourcing rule describes a possible replenishment method. It does not name the item or scope by itself. An assignment set makes the rule operational by linking it to an item, category, organization, or—in the case of independent demand—a more detailed customer-related context.

The three sourcing objects have different jobs

Use this mental model:

Object	Job in the model	Example
Sourcing rule	Defines a replenishment option.	“F100 can transfer from M1 to DC1.”
Bill of distribution	Efficiently represents linked distribution relationships across a larger network.	“Regional DCs pull F100 through a central-DC network.”
Assignment set	Associates the sourcing definition with a real planning context.	“Apply the M1-to-DC1 rule to F100 at DC1.”

Validate the source type

Oracle supports three basic source types:

Source type	Meaning	Required relationship evidence
Transfer From	Supply is moved from an internal organization.	Item exists at source and destination; source organization is correct.
Make At	The item is manufactured at an internal organization.	Item is valid at the manufacturing organization and manufacturing data is available where the plan requires it.
Buy From	Supply is purchased from an external supplier.	Supplier and supplier site are collected and selected in the rule.

For your validation, make the intended route explicit. For example:

• F100 at DC1 uses Transfer From Plant M1.
• F100 at M1 uses Make At M1.
• Component R100 at M1 uses Buy From Supplier SUP-A, Site MAIN.

This is clearer and safer than creating one vague “global supply rule” that covers every item and organization.

Do not confuse two different kinds of rank

Oracle uses rank in two distinct ways. Senior-level answers should distinguish them.

1. Sourcing assignment hierarchy rank determines which assignment scope applies. A more granular assignment overrides a more general one. For regular supply sourcing, Oracle evaluates scopes in this order:

1. Item and organization
2. Category and organization
3. Item
4. Category
5. Organization
6. Global

For example, an item-organization rule for F100 at DC1 takes precedence over a global rule for F100.

2. Source rank inside a sourcing rule determines which source option is considered first. A lower numeric rank has higher priority. Sources within the same rank must have allocation percentages totaling $100\%$.

This distinction matters when diagnosing a surprising recommendation. If the wrong rule was selected, inspect the assignment hierarchy. If the intended rule was selected but Planning chose an unexpected source inside it, inspect the source rank and allocation.

Replenishment Planning design constraint

For a connected Demand, Supply, and Replenishment Planning implementation, apply the lowest-common-denominator check early:

• Replenishment Planning does not support Make At sourcing rules.
• It considers only rank-one sources.
• It does not support sourcing splits.
• It supports only rank-one bills of distribution.

Therefore, a sourcing model with a 70/30 split across suppliers or a rank-two fallback may work differently than expected when reused for replenishment. Do not assume that a sourcing design validated for Supply Planning is automatically suitable for Replenishment Planning.

---

Customer-specific sourcing: validate independent-demand context

For supply created in response to sales orders or forecasts, Oracle can use a more detailed demand sourcing hierarchy. Customer, customer site, demand class, and region can make a sourcing assignment more specific than a generic item rule.

Consider this situation:

• F100 normally transfers from Plant M1 to DC1.
• Customer Retailer A must be supplied from a dedicated distribution path.
• Retailer A’s sales order is received at a particular customer site.

A customer-site-specific assignment can override the general item sourcing assignment. If Retailer A’s demand is unexpectedly supplied from M1 rather than its designated source, do not begin by changing the generic transfer rule. First validate:

1. The customer and customer site were collected correctly.
2. The demand line carries the expected customer and site.
3. The customer-specific assignment is in the assignment set used by the plan.
4. The item, organization, and date entered during sourcing validation match the demand context.
5. No more specific assignment is taking precedence.

This is one of the most common cross-module dependencies: Demand Management can produce a forecast at a customer or customer-site granularity, while Supply Planning must interpret that demand through the corresponding sourcing hierarchy.

---

Hands-on lab: prove two sourcing paths in your practice environment

Reserve about 15 minutes. Use real identifiers from your environment, but keep the scenario deliberately small.

Part A: Define your validation case

Record the following before opening setup pages:

Relationship	Example value	Your value
Finished item	F100
Manufacturing organization	M1
Distribution organization	DC1
Customer and site creating finished-goods demand	Retailer A / Main Site
Raw material or purchased item	R100
External supplier and site	SUP-A / MAIN
Assignment set expected in the plan	AS_DEMO
Validation date	A date within the plan horizon

Use a purchased item only if your environment contains a usable supplier and supplier site. If it does not, validate the finished-good transfer path completely rather than inventing a supplier relationship that is not represented in the source data.

Part B: Validate collected parties and item-organization records

In Maintain Supply Network Model:

1. Search the Organizations tab for M1 and DC1.
2. Confirm the relevant organization data and time zones.
3. Search the Customers tab for Retailer A and its site.
4. Search the Suppliers tab for SUP-A and its site, if testing a Buy From route.
5. If your design uses internal buy-sell transfers, verify that M1 has the supplier and supplier-site association and DC1 has the customer and customer-site association.

In Plan Inputs, verify F100 at both M1 and DC1. Verify R100 at M1 if you are testing external procurement.

Capture the result as evidence, not merely as a screenshot. For example:

“F100 is collected for M1 and DC1. Retailer A Main Site is available as the customer demand context. SUP-A MAIN is available as the procurement source for R100.”

Part C: Validate each sourcing definition

Navigate from a Supply Chain Planning work area to:

• Tasks > Manage Sourcing Rules
• Tasks > Manage Bills of Distribution, where applicable
• Tasks > Manage Assignment Sets

For each sourcing rule, inspect the relationship rather than just its name:

Intended route	What must be true
F100 at DC1 transfers from M1	The rule is Transfer From, M1 is the source organization, and F100 is available at both nodes.
F100 at M1 is made at M1	The rule is Make At, and M1 is the manufacturing organization.
R100 at M1 is bought externally	The rule is Buy From, and SUP-A plus MAIN are selected—not merely present elsewhere in Planning.

If a rule contains multiple sources of the same rank, validate that allocations total $100\%$. If it contains multiple ranks, record why the rank-one source is normally preferred and under which planning process the lower-ranked source is meaningful.

Part D: Use View Sourcing as the decisive test

From within the relevant assignment set, use View Sourcing. Enter the required context:

• assignment set;
• organization;
• item;
• date.

Perform at least these two checks:

1. F100 at DC1 on your validation date
   Expected active result: the intended transfer source from M1.

2. R100 at M1 on your validation date, if available
   Expected active result: the intended Buy From source, including SUP-A and MAIN.

If the result is not what you expected, diagnose in this order:

Symptom	Most likely validation point
No active rule is returned	Assignment is absent, wrong assignment set is being tested, wrong date is used, or the rule is too narrowly scoped.
A global rule wins unexpectedly	The item-organization or category-organization assignment is missing, invalid, or less specific than assumed.
Wrong customer-specific source is selected	Customer/site or demand-class context does not match the assignment, or a more specific assignment takes precedence.
Buy From source cannot be used	Supplier or supplier site is missing from collected data, or the rule points to the wrong supplier/site.
Transfer source is implausible	Source item-organization availability, source organization, or active assignment needs correction.

Finally, confirm that the plan configuration is intended to use the assignment set you validated. A correct assignment set that is not selected for the planning process provides no protection against an incorrect sourcing result.

---

A concise senior-consultant explanation

For an interview question such as, “How do you validate sourcing before running a supply plan?”, structure the answer around evidence:

“I validate sourcing as a connected relationship rather than checking master data in isolation. First, I confirm the organizations, customers, suppliers, and sites are collected in the Supply Network Model. Then I verify that the item exists at every source and destination organization involved in the flow. For each sourcing rule, I confirm whether it is Transfer From, Make At, or Buy From and validate the relevant source organization or supplier site. Next, I review the assignment set because that is what links the rule to the item, category, organization, or customer demand context. I use View Sourcing with the assignment set, item, organization, and planning date to prove which rule is active. Finally, I verify that the intended plan uses that assignment set and consider module limitations, particularly that Replenishment Planning supports only rank-one sourcing and does not support Make At or split sourcing.”

This explanation shows both configuration knowledge and a disciplined diagnostic sequence.

---

Key takeaways

A complete planning flow depends on valid relationships, not merely successful collections:

• Validate every organization as a meaningful planning node.
• Validate items at both the source and destination organizations.
• Validate customer and supplier sites, especially where demand or procurement is site-specific.
• Use Transfer From, Make At, and Buy From rules for distinct supply mechanisms.
• Use assignment sets to connect sourcing definitions to specific item, category, organization, customer, or demand contexts.
• Separate assignment-specificity precedence from the source rank and allocation within a rule.
• Use View Sourcing with the assignment set, organization, item, and date as the most direct proof of the active sourcing relationship.
• Account for Replenishment Planning sourcing restrictions before reusing a Supply Planning design.

Next, you will diagnose collections that fail, complete only partially, or appear successful technically while leaving Planning without the data needed for a valid end-to-end flow.