How to Resolve Item Substitution Failures in Oracle Fusion Order Promising

 

Item substitution can fail even when the substitute is visibly on hand. One useful lesson from an  Oracle Fusion SCM Online Training  is that stock visibility alone does not authorize a replacement. Order Management must permit substitution on the order, Product Information Management must hold a usable substitute relationship, and Global Order Promising must find eligible supply under its promising and sourcing logic. A break at any layer can leave the requested item unchanged or return a later date instead of the expected alternative.

Troubleshooting is fastest when the exact behavior is named. Did Check Availability omit the substitute, did scheduling retain the original item, or did submission fail later? Capture the customer, requested date, warehouse, quantity, unit, and order-line settings, then test the same pair under controlled conditions. A broad failure report hides whether the problem concerns eligibility, data freshness, supply, or fulfillment processing.

Verify that the order permits substitution

Global Order Promising substitutes only when the order line allows it. Inspect the Allow Item Substitution or Allow Substitutions value rather than relying on an order-type convention. Defaulting logic and order management extensions can set the value, and an extension may deliberately turn it off for particular customers, order types, or channels. Check the final value on the affected line after transformations, because that is what the scheduling request presents to promising.

The invocation point matters too. The scheduling fulfillment task in the orchestration process calls Global Order Promising, while a user can invoke availability checking during entry. Confirm that the line reached the expected scheduling path and review its messages. Imported source orders have specific substitution constraints, so reproduce the issue through the supported flow used by that order.

Inspect the substitute item relationship

Open the requested item in Product Information Management and inspect its Relationships information. The related item must be defined with the Substitute relationship type in the intended direction. A reciprocal business expectation is not enough if the configured relationship is one-way. Check effective and end dates against the order's timing, and verify that neither item nor relationship is inactive. Similar descriptions and shared categories do not create a promising relationship automatically.

Confirm that both items are usable in the relevant organizations and that the replacement is suitable for order fulfillment. Oracle advises aligning the primary unit of measure because Order Management does not convert the order-line unit merely because a different item is substituted. A requested item in Each and a substitute maintained in Dozen can produce an operationally invalid result. Also account for product-type limitations and test with a standard item before generalizing results from kits or configured products.

Refresh planning data after setup changes

A relationship visible in Product Information Management may not yet be visible to promising. After creating or changing the relationship, run the applicable plan-input refresh or data collection with Items included, following the deployment's promising setup. Then confirm that the refresh completed successfully. Testing immediately after a relationship edit can produce a false failure because the transaction system and the promising data store are not necessarily reading the same refresh point.

Refresh scope matters. Collecting supply and demand while omitting item-related data will not introduce the new relationship. Conversely, a relationship refresh does not make an unavailable substitute promiseable. Record the refresh completion time and compare it with the relationship update and the test request. Oracle Supply Chain documentation describes item substitution setup and explicitly calls for refreshing Order Promising data with the Items parameter, providing a sound checkpoint before deeper analysis.

Test supply, sourcing, and promising rules

Once eligibility data is current, evaluate supply through the same promising context as the order. On-hand in one organization does not guarantee availability from the warehouse or source selected for the demand. Existing reservations, other demand, calendars, lead times, and sourcing rules can move the available date. Use Check Availability to inspect the options returned for the exact quantity and requested date, and compare the substitute's result with the original item's result rather than looking only at gross on-hand.

Review ATP rules and their assignment to understand which supply and demand types are included. Then inspect sourcing rules, assignment sets, and organization applicability for the substitute. If the requested item has a valid path to the customer but its substitute does not, the engine cannot assume the missing path. A future supply might make the original item preferable on the evaluated date, while substitute supply outside the eligible network remains irrelevant despite being physically present elsewhere.

Account for quantity splits and fulfillment constraints

Substitution results can interact with line splitting. Promising may split fulfillment across items, warehouses, or dates only when line and fulfillment constraints permit the outcome. Check Allow Partial Shipments of Lines, shipment-set membership, and any constraint that requires lines to ship together. A substitute with enough quantity for part of the demand may not produce the result expected when the line must remain whole or when a shipment set imposes a common fulfillment condition.

Read the Available Item on resulting fulfillment lines after Check Availability. A split can preserve the customer's ordered item while showing which item will actually fulfill each portion. If no split appears, test a quantity fully covered by the substitute; that isolates relationship eligibility from partial-quantity behavior. Avoid changing several controls at once. One test for permission, one for full substitute supply, and one for splitting creates clearer evidence than repeated edits to the production order.

Use a controlled correction sequence

Build a minimal test after setup is verified: one active requested standard item, one active substitute with the same primary unit, a current relationship, eligible supply in a valid source organization, and an order line that allows substitution. Refresh the relevant promising data, create the test order, invoke Check Availability, and submit through an orchestration process whose scheduling task is known to run. Save the returned dates, warehouse, available item, and processing messages.

If the test succeeds, reintroduce the affected order's customer, quantity, dates, shipment set, and defaulting rules one at a time. The first change that removes substitution identifies the controlling condition. If the minimal test fails, revisit relationship direction, refresh completion, ATP assignment, and sourcing before altering orchestration. This avoids manually replacing items while future orders retain the same stale data or eligibility rule.

Conclusion

Resolving substitution is an exercise in aligning permission, relationship, current promising data, and eligible supply. Start with the order-line flag, validate the substitute relationship and unit, refresh the relevant inputs, and then examine ATP and sourcing results in the order's actual context. That layered method belongs in Fusion SCM Online Training because it shows why a substitute can be technically related and physically stocked yet still be an invalid promise for a particular demand.

Finish by repeating Check Availability and submitting a controlled order through the normal scheduling task. Verify the available item, promised dates, warehouse, and fulfillment-line structure rather than treating order submission alone as success. Keep the evidence from the failed and successful tests. It reveals whether the durable fix belongs in item data, collection practice, sourcing, promising assignments, or order defaulting—and keeps a local exception from becoming an unexplained manual process.