Global Order Promising (ATP) in Oracle Fusion: Configuration Steps Consultants Miss

The ATP rule looks correct. The sourcing rule looks correct. And the order still comes back with "No Data was Retrieved" instead of a promised ship date. Anyone who's implemented oracle fusion global order promising configuration more than once has hit this exact wall, and it almost never means the rules themselves are wrong. It usually means one quiet step downstream of rule creation got skipped.

This guide walks through the three ATP promising modes, how sourcing rules and assignment sets actually connect to each other, the specific setup step that causes most "it should be working" tickets, and what changes when you configure GOP for back-to-back or drop ship fulfillment instead of standard stock-and-ship

Every ATP rule in Oracle Fusion runs in one of three promising modes, and picking the right one per item matters more than most implementations treat it. Infinite Availability promises the requested date regardless of actual supply, performs no availability search, and generates no pegging, though it still respects calendars and transit lead times. Lead Time mode fits items that are reliably assembled or built on demand, promising based on a known production or procurement lead time rather than checking real inventory. Supply Chain Availability Search is the deep end: a fully configurable search across your sourcing rules that actually checks real supply and determines the best fulfillment location based on the item and the requested date.

Think of it like three different ways a restaurant handles a reservation request. Infinite Availability just says yes to every table request without checking who's actually seated. Lead Time knows the kitchen needs exactly forty minutes and promises based on that fixed number. Supply Chain Availability Search is the host physically checking which tables are free, which ones are turning over soon, and which section can realistically seat the party in time. Assigning the wrong mode to an item is like using the "just say yes" approach for a fully booked private dining room. It looks fine until it very visibly isn't.

Mismatched modes are a quiet, common mistake. Low-value, always-in-stock items forced through Supply Chain Availability Search waste processing time on a search that Infinite Availability would answer instantly and correctly. Constrained, high-value items assigned Infinite Availability promise dates the supply chain can't actually hit, which shows up as broken customer promises weeks later, not as a visible error today.

Three separate objects have to line up correctly for order promising to function: the sourcing rule defines where supply actually comes from (buy from a supplier, transfer from another organization, or make internally), the ATP rule defines how availability gets checked against that supply, and the assignment set is the connector that links a sourcing rule to a specific item, category, or organization. Miss the connection between any two of these and promising fails, even though each object individually looks perfectly configured.

Building a basic setup follows a defined sequence. First, create the sourcing rule itself, specifying whether it's a Buy rule (with supplier, supplier site, allocation percent, and rank), a Transfer rule between organizations, or a Make rule for internal production. Second, create the ATP rule and set its promising mode based on the item's actual behavior. Third, create an assignment set and add the sourcing rule to it, specifying an assignment basis such as Global, Item, or Category. Fourth, assign the ATP rule itself to the relevant item or organization combination.

Here's the detail that causes real problems and rarely gets enough attention during design: assignment set level isn't a cosmetic choice. Oracle's own troubleshooting guidance is specific about this. For certain global sourcing scenarios, the assignment level needs to be Global, Item, or Category, and explicitly not Organization, Item and Organization, or Category and Organization. Getting this backwards doesn't throw a clear error message. It just means order promising quietly can't find the supply data it needs, and the fix looks nothing like what the symptom suggests.

A documented case from a Fusion 24A quarterly update illustrates exactly how subtle this gets. After the upgrade, sales orders that should have been fulfilled through a category-level sourcing assignment in the GOP assignment set started processing through the global-level assignment instead, even in environments where the category-level rule was still correctly configured. Orders that should have shipped from a specific warehouse were processed as drop ship orders whenever the warehouse wasn't entered at the line level. The fix required re-saving the assignment set with its catalog association, running collections again, and restarting the Order Promising server, not touching the sourcing rule or ATP rule at all. The rules were fine the whole time. The assignment set's relationship to its catalog was what had quietly broken.

For the broader order-to-cash configuration this connects into, Oracle Fusion's order management configuration guide covers pricing, ATP/CTP basics, and AutoInvoice setup alongside this. This guide picks up specifically where that one leaves off on the promising engine itself.

The single most common cause of a correctly built setup that still fails to promise anything comes down to two things happening in the wrong order, or not happening at all: the MSP_DEFAULT_ASSIGNMENT_SET profile option not being set to the new assignment set at the site level, and the Collections and Order Promising Server refresh not being run after the rules were created or changed.

Neither of these lives on the same screen as sourcing rules, ATP rules, or assignment sets, which is exactly why they get missed. A consultant builds a global sourcing rule, creates an assignment set with the correct assignment level, creates an ATP rule with Supply Chain Availability Search mode, and tests an order immediately. It fails with "No Data was Retrieved." The instinct is to go back and re-check the rules that were just built, since they're the most recently touched objects. But if MSP_DEFAULT_ASSIGNMENT_SET still points to an old assignment set, or points to nothing, the new setup is functionally invisible to the order promising engine no matter how correctly it was built.

The second piece compounds the confusion. Even with the profile option set correctly, changes to sourcing rules, assignment sets, or ATP rules don't take effect in real time. Order Orchestration Reference Objects need to be picked up by the Collections program, and the Order Promising Server itself needs to be refreshed and restarted before the engine is actually working from current data. Testing immediately after a rule change, before running Collections, produces the exact same symptom as a genuinely broken configuration: no availability found, no clear reason why.

What happens if a consultant only fixes the profile option and skips the Collections step, assuming that was the whole problem? The setup will still fail, and now it looks like the profile option fix didn't work either, when really it just hasn't been picked up yet. Running both steps together, profile option first, then Collections and server refresh, before testing anything, saves a genuinely frustrating debugging loop.

If setup steps like these are where your team keeps losing implementation time, book a free SCM demo class with TechLeads IT's Oracle Fusion SCM training program and see how order promising configuration gets covered hands-on, including the profile option and Collections sequence that trips up most first-time implementers.

Standard stock-and-ship promising, back-to-back fulfillment, and drop ship fulfillment all use the same three building blocks, sourcing rules, ATP rules, and assignment sets, but the specific configuration inside each one changes based on how the item actually gets fulfilled.

Back-to-back fulfillment requires one setup step that has nothing to do with GOP directly: the Back-to-Back Enabled flag on the item must be set to Yes in Product Information Management before any promising configuration around it will function as intended. From there, sourcing rules need to reflect the actual buy, make, or transfer path the item follows, and the ATP rule needs a promising mode that matches how reliably that path can be scheduled.

Drop ship follows a similar pattern with a different sourcing rule shape. The sourcing rule becomes a Buy rule pointed directly at the designated supplier, the ATP rule typically accounts for the supplier's lead time rather than internal production timing, and the assignment rule is what actually attaches that sourcing rule to the specific item, most cleanly done by setting the assignment level to Item so the drop ship path applies consistently every time that item gets ordered.

For organizations moving from an on-premise EBS environment, one structural difference catches teams off guard: EBS let you dedicate a specific ASCP plan directly to GOP through a plan option. Fusion doesn't have an equivalent plan option. GOP in Fusion pulls planned order data differently, through the Planning Central plan configuration and collections setup rather than a dedicated GOP-specific plan assignment, which means the migration isn't a direct like-for-like mapping of settings.

Misconception: once ATP and sourcing rules are created, order promising just works.

Reality: new or changed rules don't take effect until Collections picks up Order Orchestration Reference Objects and the Order Promising Server is refreshed and restarted. Testing immediately after rule creation commonly produces "No Data was Retrieved" even on a correctly built setup. Why it matters: teams that assume the rules themselves are broken waste hours re-checking correct configuration instead of running the two steps that actually activate it.

Misconception: assignment set level is a minor detail that doesn't affect functionality.

Reality: Oracle's own troubleshooting guidance specifies that certain scenarios require the assignment level to be Global, Item, or Category, and explicitly not Organization, Item and Organization, or Category and Organization. Why it matters: getting this backwards produces no clear error message, just a promising engine that silently can't find the supply data it needs.

Misconception: Fusion Global Order Promising works the same way EBS's ASCP-based GOP did.

Reality: EBS allowed a dedicated ASCP plan option specifically for GOP. Fusion has no direct equivalent, and planned order data flows through Planning Central and collections setup instead. Why it matters: teams migrating from EBS who assume a direct settings mapping run into confusion that has nothing to do with a configuration error and everything to do with a genuinely different underlying architecture.

Q: What are the three ATP promising modes in Oracle Fusion Global Order Promising?

A: Infinite Availability promises the requested date without checking supply, suited to low-value or non-constrained items. Lead Time promising uses a known, reliable production or procurement lead time, suited to assemble-to-order or make-to-order items. Supply Chain Availability Search performs a full, configurable check against actual supply across defined sourcing rules, suited to constrained or high-value items.

Q: Why does Oracle Fusion Order Management show "No Data was Retrieved" during order promising?

A: This typically means a sourcing rule, assignment set, or ATP rule isn't correctly connected, most often because the assignment set level is set incorrectly, the MSP_DEFAULT_ASSIGNMENT_SET profile option doesn't point to the correct assignment set, or the setup hasn't been picked up by Collections and an Order Promising Server refresh yet.

Q: What is the MSP_DEFAULT_ASSIGNMENT_SET profile option and why does it matter?

A: It's the site-level profile option that tells the order promising engine which assignment set to use by default. If it points to an outdated or incorrect assignment set, newly created sourcing and ATP rule connections are effectively invisible to promising, even when the rules themselves are configured correctly.

Q: Do I need to run Collections after creating or changing ATP and sourcing rules?

A: Yes. Changes to sourcing rules, assignment sets, and ATP rules don't take effect immediately. The Collections program needs to pick up Order Orchestration Reference Objects, and the Order Promising Server needs to be refreshed and restarted before the new configuration is actually active.

Q: What's required to configure Global Order Promising for back-to-back fulfillment?

A: The item's Back-to-Back Enabled flag must be set to Yes in Product Information Management first. From there, sourcing rules need to reflect the item's actual buy, make, or transfer path, and the ATP rule's promising mode needs to match how reliably that fulfillment path can be scheduled.

Q: What's the difference between ATP and CTP in Oracle Fusion?

A: ATP, Available to Promise, checks existing inventory and planned supply to confirm a requested ship date. CTP, Capable to Promise, goes further and checks manufacturing capacity, confirming whether production can actually happen in time to meet the date. ATP suits standard stock-and-ship items; CTP suits make-to-order or configure-to-order items where production scheduling determines the real ship date.

  None of the mistakes covered here come from a badly built rule. They come from configuration objects that depend on each other in ways that aren't obvious from any single setup screen: an assignment set whose level quietly excludes the scenario it needs to support, a profile option living outside the rule-creation flow entirely, a Collections step that has to run before anything built actually activates. Getting order promising right the first time means treating these dependencies as part of the configuration, not an afterthought to test around later.  

  Book a free SCM demo class with Tech Leads IT's  Oracle Fusion SCM training program to see how Global Order Promising, sourcing rules, and the setup sequence covered here get taught hands-on, including the exact profile option and Collections steps most implementations discover the hard way.