Approved Supplier List vs. Sourcing Rules vs. Assignment Sets: How Oracle Actually Picks a Supplier

A hospital system I worked with had a backorder problem. Their primary surgical implant supplier went short on inventory, and the buyer expected the system to automatically flip the requisition to the backup supplier on contract. Instead it defaulted to a third supplier nobody remembered approving, with no agreement attached, at list price. Three different people blamed three different screens. None of them were right, because none of them understood that supplier selection isn't one setup, it's three, stacked on top of each other.

If you've ever argued with a teammate about why a requisition defaulted to the "wrong" supplier, you were probably arguing about the wrong layer. Here's how the three actually divide the work.

Layer 1: Approved Supplier List (ASL) — who's allowed

The ASL is the eligibility gate. It answers one question: is this supplier even allowed to supply this item or category, and under what status. Entries live at the item or category level, scoped to a procurement BU or a specific ship-to organization, and carry a status like Approved, Preferred, New, or Debarred. A debarred entry blocks the supplier outright, regardless of what any other setup says.

The ASL entry can also link a source document, typically a blanket or contract purchase agreement, so that once a supplier is selected, the system knows which negotiated agreement to price against. What the ASL does not do is decide which approved supplier wins when there's more than one. That's not its job.

Layer 2: Sourcing Rules — who actually gets picked

This is the layer most Procurement folks forget exists, because it lives in the Supply Chain Planning side of the house, not in Purchase Agreements. A sourcing rule says, for a given supply need: Buy From this supplier, Transfer From this internal org, or Make At this manufacturing org, and it can list more than one source with an allocation percentage and a rank.

This is where the split logic lives. "Send 70% of implant orders to the GPO contract supplier, 30% to the regional backup, and if the percentages ever tie, rank breaks it." When a Buy From source is used, the supplier named in the sourcing rule has to correspond to a valid ASL entry, because that's where the system pulls the agreement and pricing from. The sourcing rule decides who wins; the ASL supplies the paperwork once they've won.

Layer 3: Assignment Sets — where the rule actually applies

A sourcing rule by itself doesn't do anything. It has to be attached to a scope through an assignment set, and that scope can be as narrow as a single item in a single organization, or as broad as global, meaning every item everywhere unless something more specific overrides it. Assignment sets are also where you'll find the precedence hierarchy: item-organization beats item, item beats category-organization, category-organization beats category, and everything loses to a more specific rule if one exists.

This is the layer that gets skipped in a rush. I've seen well-built sourcing rules sit completely inactive because nobody assigned them to anything, or because they were assigned at the wrong level and got silently overridden by a broader, older rule someone forgot was still active.

How they combine when a requisition is created

Put together, the sequence at requisition or planned order time is: the assignment set determines which sourcing rule applies to this item in this organization, at the most specific level available. The sourcing rule then determines the source type, and for a buy scenario, which supplier wins based on allocation and rank. Finally, the ASL entry for that winning supplier is referenced to pull the linked agreement and pricing, and to confirm the supplier's status isn't Debarred or otherwise blocked.

Break any one link and the chain still runs, it just runs wrong. No assignment set scope for that item-org combination, and the requisition falls back to manual sourcing or a stale broader rule. Sourcing rule points to a supplier with no live ASL entry, and you get a supplier assigned with no pricing behind it. ASL entry sitting there with a great agreement attached, but no sourcing rule or assignment set pointing to it, and the buyer has to source it by hand every single time.

Where this actually breaks on healthcare projects

The implant backorder scenario above is the classic version. The GPO contract supplier is correctly on the ASL, correctly linked to a national agreement, and everyone assumes that's enough. It isn't. Without a sourcing rule and an assignment set scoped to that item and receiving organization, there's nothing telling the system to prefer the GPO supplier over anyone else also sitting on the ASL. The fix usually isn't a new ASL entry, it's building the sourcing rule with the right allocation split and making sure the assignment set actually activates it at the item-org level, not just item level, if different hospital locations need different backup suppliers.

Quick diagnostic, next time a requisition defaults wrong

Check in this order: assignment set first, to confirm a sourcing rule is even active for that item and organization. Sourcing rule second, to confirm the allocation and rank point where you expect. ASL third, to confirm the winning supplier's status and linked agreement are actually current. Nine times out of ten the complaint is "the ASL is wrong," and the actual problem is one layer up or down from where everyone's looking.

One flag before you touch any of this in a live environment: field names, checkbox labels, and exactly which work area hosts Manage Sourcing Rules versus Manage Assignment Sets shift a little between quarterly updates. Confirm the current screens against your instance's release before you change anything, rather than trusting a screenshot from a prior version.