GKS.

Supplier Sites vs Addresses: The Mistake That Breaks POs

A supplier is set up. The address is right there on the screen, correct to the letter. Then someone tries to raise a purchase order against it, and the site will not appear in the list. Or worse, the PO saves fine and gets stamped with the wrong business unit, and the problem only surfaces weeks later when payables cannot process the invoice. This is one of the most common supplier setup failures in Fusion, and almost every time it traces back to one confusion. Address and site are not the same thing.

Get the difference straight and a whole category of purchase order headaches simply stops happening.

Two different objects doing two different jobs

Start with the supplier itself. In Fusion, a supplier is a global entity. Define it once and every business unit in the organization can see it. It sits above the org structure entirely, not tied to any BU, ledger, or legal entity. Simple enough.

An address is just a physical location on that supplier. A street, a city, a country. It records where the supplier physically is, and it carries address purposes that reflect what the supplier says it does at that spot, things like ordering or RFQ. Nothing about an address, on its own, lets a purchase order happen.

A site is the piece people miss. A site is a business relationship between one procurement BU and the supplier at a given address. That is the whole idea in one sentence. The address answers where. The site answers who the buying organization deals with there, and under what terms. A site is owned by a procurement BU, and it holds the controls, the policies, the receipt and invoice tolerances, everything that governs how procure to pay actually runs with that supplier at that location.

So an address is geography. A site is a contract to do business at that geography. One supplier address can even underpin sites for several different business units, each with its own terms. The address stays put while the relationships stack on top.

Why a correct address still breaks the PO

Here is the mechanic that catches people, and it is worth reading twice.

A purchase order does not run on an address. It runs on a site, and more precisely on the site assignment. When a site gets created, it needs assignments that connect it to the client business units it serves. That assignment record is where the real work lives. It names the client BU, the business unit doing the requisitioning, and it names the bill to BU, the one responsible for processing invoices.

Now the part that actually derives on the PO. Fusion figures out the business unit for the order from the requisitioning BU matched against the supplier site assignment. No assignment linking that supplier site to that requisitioning BU means the site is invisible when someone tries to order. The address looks perfect and the PO still cannot be built, because the missing piece was never the address. It was the relationship the address was supposed to support.

This is also why a PO sometimes lands with a business unit nobody expected. The BU stamped on the order comes straight from the site assignment, and payment follows that same BU. Set the assignment up loosely and the document carries the wrong owner from birth, which turns into an invoice processing mess downstream.

The setup order that prevents all of it

The failures above almost always come from doing these steps out of order or skipping the last one. The sequence that works:

Create the supplier first, at the global level. Add the address next, the physical location with its purposes set correctly. Then create the site under the correct procurement BU, since the site cannot exist without knowing which procurement organization owns the relationship. Give the site its purpose, Purchasing being the common one, and note that Fusion defaults the site purpose from the address purposes, though the site purpose can be a narrower subset of what the supplier claims to do.

Then comes the step people forget, the one that causes most of the tickets. Go to Site Assignments and actually assign the site to every client BU that needs to buy from it. On each assignment, set the client BU and the bill to BU. Only client BU and bill to BU are truly required here, but they are the difference between a site that works and one that only looks finished.

Miss that assignment step and everything upstream looks complete while the purchase order stubbornly refuses to cooperate. The supplier is there. The address is there. The site is there. And it still does not work, because the relationship to the requisitioning BU was never drawn.

What to check when a site will not show up

When a buyer says the supplier site is not available on a PO, skip the address entirely and go straight to the assignment. Nine times out of ten the site was never assigned to that requisitioning BU, or it was assigned to a different BU than the one raising the requisition. Confirm the procurement BU owns the site. Confirm the site assignment lists the correct client BU. Confirm the bill to BU is set so invoicing has somewhere to go. The answer is almost never in the address, which is exactly why people waste an afternoon staring at it.

Two objects. Two jobs. The address says where the supplier lives. The site says the buying organization has a working relationship there, on set terms, tied to specific business units. Keep those two ideas apart and supplier setup stops being a guessing game.

More practical Oracle Fusion walkthroughs land here every day. Video versions live on the SCM Simplified YouTube channel.

← Back to the blog