Mapping Prerequisites for Connected Planning Flows

Good to see you again. In the previous lesson, you traced planning data from the operational source through collection and the planning data repository, then into plan results and, where applicable, execution. The next implementation question is more demanding: what must exist, be valid, and be run in the right order before that flow can work?

For a senior functional consultant, the answer is not a flat checklist. It is a prerequisite map: a dependency model connecting enterprise structures, reference and transactional data, planning configuration, and operational run sequence. This lesson builds that map for a connected flow in which a demand forecast informs replenishment decisions and upstream supply planning determines whether those replenishment needs can be met.

---

Start with one connected business flow

Use this scenario throughout the lesson:

• A manufacturer makes a finished item at Plant A.
• Plant A transfers the item to DC East.
• DC East replenishes several retail stores.
• Demand Management produces an approved forecast using shipment history and, where appropriate, sales orders.
• Replenishment Planning proposes stock replenishment for the stores and DC based on demand, inventory, lead times, and replenishment policy.
• Supply Planning evaluates whether Plant A has the component supply and capacity to meet the proposed upstream requirements.
• Eligible transfer, purchase, or work recommendations are released to execution and then collected back for the next planning cycle.

The planning data repository is the shared planning foundation, but each plan needs a different slice of that foundation and a different set of setup decisions.

A useful way to frame the map is through five layers:

Layer	Core question	Example for the scenario
Enterprise structures	Where does planning occur?	Plant A, DC East, stores, suppliers, customer locations, calendars
Master data and relationships	What is being planned, and how can it flow?	Item attributes, BOM, work definition, lead times, sourcing, assignment set
Transactional data	What demand, inventory, and open supply exist now?	Shipment history, sales orders, on hand, work orders, purchase orders, transfer orders
Planning configuration	How should Oracle interpret the data?	Plan scope, measures, policies, constraints, planning calendars, demand inputs
Run sequence and controls	In what order should data and plans be refreshed?	Collection, validation, plan runs, approval, release, feedback collection

The most important implementation principle is:

A downstream planning result is only as trustworthy as the earliest prerequisite on which it depends.

For example, a replenishment recommendation may look wrong because of a policy parameter. But it might instead originate with a missing item-organization relationship, an outdated lead time, an uncollected on-hand balance, or a sourcing rule that is not assigned to the plan’s assignment set.

---

Layer 1: Enterprise structures establish the planning context

Enterprise structures determine the organizational and temporal meaning of planning data. An item quantity of 500 is not useful to a plan unless Oracle can identify which organization owns it, when it is available, and, for network planning, where it can move next.

For the connected Plant A, DC East, and store flow, establish and validate the following before treating planning as a forecast or optimization problem:

Structure	Why it is a prerequisite	Failure symptom if missing or inconsistent
Source system	Identifies the origin of planning data	Data cannot be collected or is attributed to the wrong source
Inventory organizations	Defines nodes where demand, inventory, and supply are planned	Item, on hand, or supply is absent from plan scope
Manufacturing organization	Identifies where make supply and resource capacity exist	No feasible planned work order or capacity analysis
Customer and customer sites	Provides demand-location context when forecasts or sales orders use customer dimensions	Forecast or demand cannot be analyzed or sourced at the intended level
Suppliers and supplier sites	Supports externally purchased supply	Buy recommendations lack a valid supplier context
Locations and shipping network	Supports transfer relationships and transit assumptions	Transfer recommendations are missing or have implausible dates
Units of measure	Allows consistent planning and conversion	Quantities are missing, distorted, or cannot aggregate correctly
Calendars	Defines valid working and planning dates	Orders are proposed on nonworking dates or dates shift unexpectedly
Catalogs and categories	Support item segmentation, aggregation, and category-level sourcing	Category assignments or category-level sourcing do not resolve

The organization code alone is not enough. In an implementation workshop, confirm the role of each organization. DC East may be an inventory organization for planning, but it is also a transfer destination from Plant A and a replenishment source for stores. Those relationships drive different planning behavior.

---

Layer 2: Master data describes the product and supply network

Master data gives planning its decision logic. Transactions say that demand or supply exists; master data tells the plan whether the item can be made, bought, transferred, substituted, or replenished.

The item-organization record is the planning anchor

At implementation level, avoid speaking only about “the item.” Planning generally depends on the item in a specific organization.

For the finished item in the scenario, validate item-organization planning attributes at every relevant node:

• Plant A: Is the item make-enabled? Does it have a valid work definition, BOM or item structure, lead times, and resource requirements?
• DC East: Is the item transfer-replenished, purchased, or otherwise supplied according to the operating model? Are its lead times and inventory-planning attributes appropriate?
• Stores: Is the item eligible for replenishment, and does it have the policy-related attributes required by the intended replenishment design?
• All locations: Are units of measure, status, lifecycle dates, planning method, and organization assignment valid for the intended plan horizon?

A finished item may be valid at Plant A and absent at DC East. In that case, a Plant A work order can still exist, but DC East cannot be modeled correctly as a destination for its supply.

Product structure and manufacturing prerequisites

Supply Planning cannot produce a credible manufacturing recommendation merely because the item is flagged as “make.”

For a make item, the dependency chain normally includes:

1. A valid item at the manufacturing organization.
2. A collected item structure or bill of material for component explosion.
3. A valid work definition for component and resource requirements.
4. Required resources and resource availability for capacity evaluation.
5. Lead-time and calendar data to determine when supply can start and finish.
6. Component items that are themselves valid and sourced at the required organizations.

If the BOM is missing, Supply Planning cannot translate demand for the finished item into component requirements. If the work definition or resource availability is missing, the plan may not represent manufacturing feasibility as intended.

Network sourcing prerequisites

Sourcing is the bridge between independent demand and an actual supply node. It tells planning whether an item should be made, bought, or transferred and identifies the relevant source.

For the example network, the intended sourcing model might be:

Destination and item	Expected source	Required relationship
Finished item at Plant A	Make at Plant A	Make sourcing plus valid manufacturing master data
Finished item at DC East	Transfer from Plant A	Transfer sourcing rule or bill of distribution
Finished item at a store	Transfer from DC East	Transfer sourcing rule or bill of distribution
Purchased component at Plant A	Buy from approved supplier site	Buy sourcing plus supplier and supplier-site data

The assignment set is crucial. Creating a sourcing rule does not automatically make it effective for every item and plan. The assignment set associates sourcing rules or bills of distribution with the intended items, categories, and organizations. The plan must use the intended assignment set.

Two constraints matter particularly for interview answers involving Replenishment Planning:

• Replenishment Planning does not support Make At sourcing rules.
• Replenishment Planning considers rank-one sources and does not support sourcing splits.

Therefore, do not model a store replenishment policy as directly “making” a product. Model the upstream manufacturing decision in Supply Planning, then provide the replenishment network with a valid transfer or buy source.

---

Layer 3: Transactional data supplies the current planning picture

Once the structural model is usable, transactions establish the time-phased planning position: what customers need, what inventory exists, and what supply is already expected.

A connected flow generally needs the following transaction families.

Transaction family	Typical records	Planning purpose
Historical demand	Shipment history, bookings history	Statistical forecast generation and forecast diagnostics
Current demand	Sales orders, transfer demand, forecasts	Requirement signal for supply or replenishment
Inventory position	On hand, reservations, receipts, in-transit supply	Determines net available inventory
Existing supply	Purchase requisitions, purchase orders, work orders, transfer orders	Prevents duplicate recommendations and establishes expected supply dates
Capacity-related transactions	Resource availability and manufacturing status	Determines whether proposed make supply is feasible

A good prerequisite map distinguishes history from current demand. Shipment history might provide the basis for a demand forecast, but it does not replace an open sales order that must be fulfilled. Similarly, an approved forecast becomes a planning input only when it is available at the appropriate item, organization, customer, and time level for the consuming plan.

The relationship test: can Oracle connect the records?

In practice, data can be technically collected yet functionally unusable. Before blaming plan logic, verify these relationships:

Relationship to validate	Example evidence
Item to organization	Finished item exists at Plant A, DC East, and relevant stores
Item to source system	Collected record shows the expected source system
Demand to item and location	Sales order or forecast references a valid item and demand organization
Supply to item and location	Purchase order, work order, or transfer order references a valid item and supply organization
Customer to demand	Customer or customer site is valid where demand-level forecasting or sourcing uses it
Supplier to buy source	Supplier site used in sourcing is valid and collected
Source to destination	Transfer relationship resolves through the plan’s assignment set
Make item to components and resources	BOM, work definition, resources, and availability are valid in the manufacturing organization
Date to calendar	Demand, supply, transit, and work dates fall within valid calendar and plan horizon context

This is the difference between a data inventory and a dependency map. An item, customer, supplier, order, and sourcing rule can all exist independently. Planning works only when the applicable links resolve for the item, organization, date, and assignment set used by the plan.

---

Layer 4: Configuration tells each plan how to interpret shared data

The planning data repository contains available inputs. Configuration determines which inputs a plan uses and what decision it makes from them.

For the connected scenario, separate shared configuration from plan-specific configuration.

Shared and cross-plan configuration

These decisions affect more than one planning process:

• Planning source system and collection setup
• Organization, item, customer, supplier, and catalog scope
• Calendars, units of measure, and time zone consistency
• Sourcing rules, bills of distribution, and assignment sets
• Data access and planner responsibilities
• Forecast publication or approval process
• Collection templates, filters, and cadence

Demand Management configuration

Demand Management needs, at minimum:

• Plan scope and forecast horizon
• Time levels and output granularity
• Historical demand measure and its data source
• Forecast method and relevant forecasting parameters
• Product, customer, and geography hierarchies where used
• A defined forecast measure that can later be approved or consumed downstream

The practical handoff is not simply “run the demand plan.” It is: produce an approved forecast at a level that the downstream plan can consume without unintended aggregation, disaggregation, or duplication.

Replenishment Planning configuration

Replenishment Planning needs:

• Replenishment plan scope and relevant item-location combinations
• Planning horizon and time buckets
• Inventory, demand, and supply inputs
• Replenishment policies and policy parameters
• A valid rank-one replenishment source
• Lead times, calendars, sourcing, and order constraints
• Where used, a connected supply input that reflects upstream availability or constraints

Supply Planning configuration

Supply Planning needs:

• Plan scope across manufacturing, distribution, and supplier organizations
• Demand sources, including sales orders, forecasts, and connected-plan demand
• Planning horizon and calendar
• Planning mode and applicable constraint settings
• Assignment set for network sourcing
• BOMs, work definitions, resources, capacities, lead times, and order modifiers
• Existing supply and inventory netting behavior

A senior consultant calls out a critical distinction:

Master data describes what is possible; plan configuration determines what the current plan is allowed to consider.

For example, a transfer sourcing rule may be correct, but DC East still will not receive transfer recommendations if the source organization is excluded from the plan scope, if the plan uses a different assignment set, or if the related item is excluded.

---

A consolidated prerequisite map

The following map can be used in a design workshop, configuration workbook, test script, or interview explanation.

Dependency level	Required prerequisites	Validation gate before proceeding
1. Enterprise foundation	Source system, organizations, locations, calendars, units of measure, catalogs, customers, suppliers	Relevant organizations and parties are collected and visible in planning
2. Product foundation	Item master, item-organization attributes, categories, lifecycle and planning status	Each planned item exists and is usable at every required node
3. Supply-network model	Sourcing rules or bills of distribution, assignment set, shipping and transit assumptions	View sourcing resolves the intended active source for item, organization, and date
4. Manufacturing model, where applicable	Item structures, work definitions, components, resources, capacity, lead times	Finished-item demand can explode to valid components and resource requirements
5. Transactional position	Demand history, forecasts, sales orders, on hand, reservations, work orders, purchase orders, transfer orders	Plan Inputs show the expected record, quantity, date, and organization
6. Plan definitions	Plan scope, horizon, calendars, measures, demand sources, policies, planning mode, assignment set	Plan includes the intended records and is configured for the intended decision
7. Plan execution and handoffs	Collection schedule, demand-plan approval, connected-plan schedule, review and release controls	Each plan runs after its required inputs are refreshed and approved
8. Execution feedback	Release process, execution acceptance, subsequent collection	Released documents return as existing supply or demand in the next cycle

This map is intentionally ordered from the least volatile prerequisites to the most volatile. Enterprise structures and network relationships usually change less often than sales orders or inventory balances, but a change in a foundational layer has much broader impact.

---

Run sequence: establish once, operate repeatedly

A prerequisite map needs two sequences:

1. an initial implementation sequence, when the planning foundation is built; and
2. a recurring operating sequence, when the plans are run in business-as-usual cycles.

Initial implementation sequence

For a selective or phased implementation, use this order:

1. Define the planning design and scope.
   Identify source systems, organizations, items, customers, suppliers, plan types, decision ownership, time horizons, and the required connected-plan handoffs.

2. Establish enterprise structures and source-system ownership.
   Confirm that organizations, locations, calendars, units of measure, customers, suppliers, catalogs, and source-system relationships are valid.

3. Create and validate master-data relationships.
   Complete item-organization setup, product structures, work definitions, resources, lead times, sourcing rules or bills of distribution, and assignment sets.

4. Configure plan definitions and operational policies.
   Define Demand Management measures and scope, Replenishment Planning policies and scope, and Supply Planning demand inputs, constraints, and assignment set.

5. Run an initial targeted collection of reference data.
   Validate organizations, items, customers, suppliers, calendars, product structures, work definitions, and sourcing-related inputs in the planning repository.

6. Run a targeted collection of required history, demand, supply, inventory, and capacity data.
   Include enough valid history for forecasting and enough open transactions to represent the current position.

7. Validate collected records before running plans.
   Confirm the critical item-organization combinations, demand records, on-hand balances, open supply, resources, and source-destination relationships in Plan Inputs and the supply network model.

8. Run plans in their configured dependency order.
   Generate and approve the demand forecast first. Run downstream replenishment and supply processes according to the connected design.

9. Validate outputs and handoffs.
   Reconcile forecast, demand, inventory, supply, exceptions, and pegging. Verify that connected-plan schedules are current and at the expected grain.

10. Release only approved eligible recommendations.
    Confirm that the resulting execution transaction is created successfully.

11. Collect execution feedback and rerun as required.
    The released work order, purchase order, or transfer order must return as existing supply in the next cycle.

Recurring connected planning cycle

For the example scenario, a practical cycle is:

1. Refresh changes to reference data when required, and collect current transactional demand, inventory, supply, and capacity.
2. Validate high-impact exceptions in the collected inputs, particularly missing items, invalid sourcing, late supplies, and unexplained inventory changes.
3. Run Demand Management and review the resulting forecast.
4. Approve or publish the forecast measure intended for downstream consumption.
5. Run the downstream operational plan or plans according to the connected design.
6. Where Supply Planning is intended to constrain replenishment availability, run the plans in the configured sequence so the replenishment result reflects the latest upstream supply position.
7. Review projected inventory, shortages, capacity issues, exceptions, and pegging.
8. Release approved eligible recommendations.
9. Run a follow-up collection when released execution documents must be recognized as existing supply.

Do not present the sequence as immutable. A consultant should say: “The exact run order follows the approved connected-plan design, but every schedule must respect the dependency of the consuming plan on refreshed and approved upstream input.”

That distinction is important. If a Replenishment Plan consumes an upstream constrained supply schedule, running replenishment before that schedule is refreshed may yield a technically successful but operationally stale result.

---

Diagnose failures by locating the broken prerequisite

When a planning result is implausible, classify the issue before changing setup.

Symptom	Most likely layer to inspect first	Example
Item is missing from the plan	Collection, scope, or item-organization master data	Item exists in Product Management but was not collected for DC East
Transfer is proposed from the wrong DC	Sourcing or assignment-set configuration	A global sourcing rule is active instead of the item-organization rule
Supply Plan does not create component demand	BOM, work definition, component setup, or plan options	Finished item is make-enabled, but the item structure was not collected
Replenishment quantity ignores recent inventory change	Transactional collection timing or inventory input selection	On-hand was changed after the last successful collection
Forecast does not influence Supply Planning	Approved forecast handoff, demand source, measure, or aggregation	Demand Plan produced a forecast, but the consuming plan references another measure
Same supply is repeatedly proposed	Existing supply transaction, release feedback, or netting issue	Released purchase order has not yet been collected back into planning
Recommendation date is unrealistic	Lead time, calendar, transit, order modifier, or capacity data	Transfer lead time is missing or source organization calendar is incorrect

Use the lifecycle timestamps from the previous lesson with this prerequisite map:

• When did the source record or setup change?
• Was the applicable entity collected successfully?
• Is the dependency visible and valid in the planning repository?
• Did the plan run after that collection?
• Did the correct plan, assignment set, scope, and configuration interpret it?
• If released, did the execution record come back through collection?

This prevents a common implementation mistake: altering plan parameters to compensate for missing or stale data.

---

Practice in your environment: create a one-page prerequisite map

Use one item that exists in your practice environment at two or more organizations. If possible, choose a make item supplied from a plant to a distribution organization.

Create a short worksheet with these five sections:

1. Network and scope
   Record source system, Plant A equivalent, DC equivalent, item, suppliers if applicable, customers or stores if applicable, and planning calendars.

2. Master-data relationships
   Record the item-organization status at each node, make or buy behavior, lead times, sourcing rule or bill of distribution, assignment set, and manufacturing structure where applicable.

3. Transactional inputs
   Record at least one demand input, on-hand balance, and existing supply record. Note their quantity, date, organization, and collection status.

4. Plan configuration
   Record the Demand Plan forecast measure, the Replenishment Plan policy or policy assignment, and the Supply Plan assignment set and demand input. Do not attempt to configure every parameter yet; establish the dependency and ownership of each setting.

5. Run sequence and evidence
   Write the intended collection and plan-run order, then capture the latest collection timestamp, latest plan-run timestamp, and one output record that demonstrates the item is flowing through the model.

For validation, use the planning work area’s seeded tables and supply network model to inspect the collected item, organizations, suppliers, and relationships. For sourcing, use the assignment set’s View Sourcing capability with the specific assignment set, organization, item, and effective date. This is more reliable than assuming the rule you created is the rule Oracle is currently applying.

---

Key takeaways

A connected Oracle Cloud SCM Planning flow depends on five linked layers: enterprise structures, master-data relationships, transactional inputs, planning configuration, and a controlled run sequence.

• Enterprise structures establish where and when planning occurs.
• Item-organization attributes, manufacturing data, and sourcing relationships determine what supply paths are possible.
• Transactions establish the current demand, inventory, supply, and capacity position.
• Plan definitions determine how each planning module interprets those shared inputs.
• Collection, validation, plan execution, approval, release, and feedback collection must occur in a dependency-aware sequence.

For an interview, avoid reciting a generic list of data objects. Explain the relationships: an item must exist at the relevant organization; its sourcing must resolve through the active assignment set; its demand and supply must be collected; and the plan that consumes them must run after its upstream inputs are available.

Next, you will configure a planning source system and run targeted data collections in the practice environment, turning this prerequisite map into a working implementation baseline.