Locations look simple at implementation—until requisition lists become noisy, change orders fail validation, or users cannot find a destination they used yesterday. These problems usually trace back to location naming, Reference Data Set design, migration quality, or the relationship between Deliver-To, Ship-To, and inventory organizations.
1. Start with the procurement experience
For requesters, a location answers one practical question: Where should this order end up? Every user needs a preferred Deliver-To location and can change it during requisition checkout. If the correct destination is hard to find, adoption suffers immediately.
In Redwood Self Service Procurement, location naming is part of the user experience. Users search for what they think a place is called; they rarely know the official postal address, and they rarely scroll through a long result list.
Three-character search constraint
Redwood requires at least three characters for a search. Names such as “IT Building” create predictable frustration because users naturally type “IT.” Design names and prefixes with the first three characters in mind.
Advanced search is available in Preferences but not in the cart. Oracle customers can follow or support the related Customer Connect enhancement discussion for Deliver-To advanced search.
2. Use a human-first naming pattern
A consistent, left-to-right structure lets people search by the fragment they actually remember.
Building / Common Name – Street Address – Floor – Area / Office
Example: Warbler Building – 155 W Van Buren – 2nd Floor – Office 123
Why it works
- The building name is the strongest memory cue.
- The address confirms the correct site.
- Floor and office support last-mile delivery.
- Searching any meaningful fragment can succeed.
Likely searches
- Warbler
- Van Buren
- 2nd Floor
- Office 123
Common anti-patterns
- Address-only names: users rarely remember street numbers.
- Internal codes first: a code such as LOC-FL-0047 is meaningful to administrators, not requesters.
- Inconsistent ordering: building first in one record and floor first in another.
- Inconsistent abbreviations: mixing BLDG, STE, RM, and unexplained local shorthand.
- Excess punctuation: visual noise reduces scanning speed.
Use prefixes intentionally
| Effective | Problematic |
|---|---|
| ZZZ – DO NOT USE – Old Dock | Random numeric prefixes |
| TEMP – Mobile Clinic – Orlando | Business-unit codes users do not understand |
| DC – Main Warehouse – Atlanta | A prefix that means different things in different business units |
If a location should not be selected, make that obvious within the first three characters.
3. Separate Deliver-To from Ship-To
Deliver-To
Where the goods ultimately belong—the office, lab, floor, clinic, or work area. This is the value requesters see and care about.
Ship-To
The destination presented to the supplier on the purchase order—usually a dock or receiving point that a truck can reach.
At the location level, Oracle allows a location to be its own Ship-To. Otherwise, the Deliver-To location references one Ship-To location.
When one destination has multiple delivery routes
A Research Lab may receive different product types through different docks:
| Material or route | Ship-To | Deliver-To | Requester-facing name |
|---|---|---|---|
| Small packages | Front Desk | Research Lab | Front Desk | Research Lab |
| Compressed gas | Hubbard Receiving Dock | Research Lab | Hubbard Dock | Research Lab |
| Pallets | Main Dock | Research Lab | Main Dock | Research Lab |
Requesters cannot easily inspect or change the linked Ship-To during checkout. Until a more flexible derived Ship-To model exists, create a separate Deliver-To record for each valid route and make the route explicit in the requester-facing name. Each Ship-To itself only needs to be created once.
4. Understand Location Sets
A location does not have to exist globally. It belongs to a Reference Data Set, and that set is assigned to a business unit through Manage Business Functions.
- Common Set locations are visible to all business units.
- BU-specific Location Sets are visible only to assigned business units.
- Inventory organization filtering can further restrict the available Deliver-To list.
| Complaint | Likely cause |
|---|---|
| “I can’t find the location I need.” | The location is in another Location Set or excluded by the active inventory organization filter. |
| “I see too many irrelevant locations.” | Operational locations were placed in Common Set and are visible beyond their intended business unit. |
The Common Set trap
Putting every location in Common Set is convenient during a rapid implementation because everything appears everywhere. It becomes a liability when the organization adds business units, inventory organizations, Redwood Self Service Procurement, or stronger data governance.
Common Set removes useful guardrails
Locations influence inventory organization filtering, Deliver-To lists, change-order validation, routing, and accounting. Global visibility can allow users to order across entities or geographies and trigger unintended cross-entity accounting.
5. Move operational locations safely
The durable design is to place operational locations in BU-specific Location Sets. Treat the transition as a phased data migration, not a mass cleanup.
- Create the new BU-specific Location Sets.
- Re-create the required operational locations in those sets.
- Temporarily leave the Common Set records in place.
- Rename legacy records with an unmistakable prefix such as ZZZ – DO NOT USE.
- Confirm which open purchase orders still reference the old records.
- Deactivate old locations only after transaction and change-order testing is complete.
Receiving often continues for an existing purchase order even when its location is no longer selectable. A change order invokes stricter validation, which is why immediate deactivation can create failures later in the document lifecycle.
Open purchase orders define the migration tail
Plan coexistence around open POs, receipts, invoices, and likely change orders. A successful new requisition test does not prove that older documents remain maintainable.
6. What works—and what breaks
| Scenario | Conditions | Observed result |
|---|---|---|
| Receiving | Existing PO references an old Location Set; location is no longer selectable. | Receipt succeeds |
| Change order: not invoiced or received | Deliver-To remains editable; list is restricted by inventory organization. | Works when replacement locations are valid |
| Change order: already invoiced or received | Deliver-To is locked. | Change is not allowed |
| Change-order submission | Deliver-To changed but Ship-To or Bill-To was not; document contains mixed Location Sets. | Submission fails |
7. Keep header and line Ship-To values aligned
Purchase orders contain header-level and line-level Ship-To values. Changing one does not automatically update the other. When all lines share a destination, Fusion may infer what it displays at the header, but that does not prove the stored header value changed. Editing the PO can expose the underlying mismatch.
| Action | Outcome |
|---|---|
| Edit header and all lines | Values match |
| Edit header only | Line values remain wrong |
| Edit lines only | The UI may look correct while the printed PO is wrong |
| Edit neither | No new inconsistency is introduced |
Training rule
Edit everything or edit nothing. If the Ship-To must change, reconcile the header and every affected line before submission and document generation.
8. Account for the Redwood inventory organization filter
In requisitions, Deliver-To is associated with an inventory organization. The user’s Preferences determine filtering, even though the checkout experience does not clearly explain that dependency. The Deliver-To list therefore shows locations for the inventory organization associated with the preferred Deliver-To.
If the correct location belongs to another inventory organization:
- The user will not see it in checkout.
- Typing its name will not make it appear.
- The user must change Preferences first.
This mental model is particularly unintuitive in healthcare, higher education, and financial services, where requesters do not ordinarily think in inventory organizations.
Search cannot override security or context
If a valid location is absent, verify Preferences, inventory organization, Location Set, and BU assignment before changing the location name or creating a duplicate.
9. Use seeded B2B account numbers for healthcare Ship-To
Oracle supports assigning B2B account numbers to Ship-To locations and transmitting them on outbound purchase orders. This is important for healthcare suppliers and integrations such as GHX.
Organizations that previously maintained custom DVMs or reporting workarounds should evaluate the supported capability. For multi-facility health systems, supplier-facing account numbers reduce fulfillment ambiguity, errors, and technical debt.
Implementation checklist
- Use searchable, human-first names with consistent ordering.
- Make nonselectable or temporary status obvious in the first three characters.
- Model each valid Deliver-To and Ship-To route explicitly.
- Avoid Common Set for operational locations unless global visibility is truly intended.
- Assign BU-specific Location Sets through Manage Business Functions.
- Train requesters on Preferences and inventory organization filtering in Redwood.
- Inventory open POs before moving or deactivating locations.
- Test receiving, change orders, submission, and printed documents—not only requisitions.
- Update header and line Ship-To values together.
- Use the supported B2B account-number capability where applicable.
Final takeaway
Location Sets are not merely setup data. They shape the requester experience, search results, transaction routing, accounting boundaries, and document lifecycle rules. A deliberate naming standard and BU-aligned Reference Data Set design prevent many issues that can otherwise look like Redwood defects.