Take a tour through Oracle Fusion Procurement and Supply Chain modules following the purchase of a box of gloves.
Select any tile to jump to that part of the guide, then open the detours when your business does something different.
Approved supplier, site, and spend authorization.
What ItemItem identity, UOMs, manufacturer, attributes, and other master data.
On what terms Price & AgreementCommercial source, price, dates, and purchasing terms.
Catalog, requisition, accounting, approval.
Commit PurchaseBuyer processing and purchase order.
Arrive ReceiveDirect, standard, inspection, or expense receipt.
Control InventoryOn-hand, locators, movements, counts.
Repeat ReplenishMin/Max, PAR, transfers, purchasing demand.
Settle Pay & CostAccrual, invoice match, valuation, liability.
The three prerequisites
Imagine that Central Stores needs to buy boxes of nitrile gloves. Before an employee ever searches a catalog, Oracle needs answers to three different questions.
Which supplier and supplier site are approved to support the purchasing relationship?
What is the glove item, how is it measured, and how should downstream applications interpret it?
What price, effective dates, commercial terms, and purchasing agreement should Oracle and the requester use?
These may be established by completely different teams and at different times. The important architectural idea is that Procurement eventually brings them together.
Foundation 1 — Who
The supplier must exist in Oracle, have the appropriate supplier site, and be usable for the purchasing relationship we are about to create.
Supplier Registration can begin that relationship by collecting company information, addresses, contacts, questionnaires, classifications, certifications, and other onboarding data directly from the supplier. They can get support from built in AI chatbots along the way.
But registration approval does not necessarily mean the supplier is immediately ready for ordinary purchasing.
Introductory takeaway: before we issue purchase orders, the supplier must exist, have the right supplier site, and be authorized for the purchasing relationship.
Supplier Qualification Management helps move the conversation beyond “does this supplier exist?” toward “should we do business with this supplier?”
Oracle organizes qualification content into reusable questions, qualification areas, initiatives, and models. Instead of every sourcing event or registration request inventing its own supplier questionnaire, the organization can reuse a governed library of the questions. You can send questionnaires on a regular basis, though this does require Supplier Portal.
Collect foundational information, contacts, classifications, certifications, and questionnaire responses during onboarding.
Group related criteria such as financial stability, cybersecurity, sustainability, diversity, insurance, clinical requirements, or quality. Oracle supports bank account verification through JP Morgan Chase.
Bring multiple areas together into an overall assessment of whether the supplier meets the organization's expectations.
Qualification questions can support later negotiations so sourcing teams do not have to repeatedly recreate the same due-diligence questions.
A prospective supplier may therefore be perfectly legitimate for registration, qualification, and competitive sourcing while still not being ready for spend. They would need to be approved before they could receive any negotiation awards.
Do not confuse onboarding with approval to spend. The registration process proves that Oracle knows who the supplier is. Qualification helps determine whether the relationship is acceptable. Spend authorization controls whether ordinary purchasing should proceed. And if you aren't ready to leveragel Qualification, you can approve a supplier for spend without this step.
AI and agentic experiences can make parts of supplier review, sourcing preparation, and buyer work easier, but they do not eliminate the need for a clear qualification model. The organization still needs to decide which evidence matters and who owns the decision.
Foundation 2 — What
The glove is not merely an item number and description. It is a shared product record interpreted by several applications.
Item number, purchasing category, manufacturer, manufacturer part number, purchasing eligibility, and organization assignments.
Primary UOM, purchasing UOM, packaging, and the conversions needed when suppliers sell one way but operations consume another.
Stocking behavior, lot or serial requirements, expiration controls, subinventories, locators, and replenishment attributes.
Healthcare or business-specific information such as size, sterile status, latex status, manufacturer identity, or other extended attributes.
Procurement asks whether the glove can be purchased. Inventory asks where and how it can be stocked. Receiving asks whether additional controls apply. Costing asks how transactions should be valued.
A purchasing category is more than a reporting label. Category design can influence catalog content, approvals, account derivation, sourcing, purchasing controls, supplier strategy, buyer ownership, and downstream analytics.
That means the category hierarchy should describe how the business actually wants to manage spend rather than simply mirror an implementation team's preferred technical structure.
For example, the organization may want all surgical implants treated differently from commodity medical supplies even if both eventually hit similar expense accounts. Category is one of the places Oracle can preserve that procurement distinction.
A poorly designed category hierarchy eventually becomes everyone else's problem. Once categories drive content, approval, buyer assignment, supplier strategy, reporting, or accounting, changing the hierarchy is no longer merely a taxonomy cleanup.
Healthcare exposes a question that every item-master design eventually has to answer: does this record need to behave like a real supply-chain item, or do we simply need to know that the manufacturer part exists?
A true Oracle item brings an entire operating model with it: categories, units of measure, lifecycle status, organization assignments, purchasing controls, inventory behavior, duplicate management, costing, and downstream integrations. That is appropriate when the product needs Inventory, PAR, replenishment, receiving, costing, or full item-master synchronization to an EHR.
It may be unnecessary for thousands of reference-only manufacturer part numbers that appear in supplier or GPO price files but are never stocked or governed as supply-chain items.
Oracle may send item identity, description, manufacturer and MPN, UOM, cost or price information, and lifecycle changes to Epic, Oracle Health, or another clinical platform.
Clinical systems may return usage, patient or procedure context, lot or serial information, waste, or charging information.
The integration lesson: Oracle and the EHR do not have to maintain identical item masters, but they do need durable cross-references and clear ownership of each attribute.
Healthcare also makes substitution more consequential. A commercially equivalent product may not be clinically equivalent. Size, material, compatibility, physician preference, regulatory status, or intended use may require value-analysis or clinical approval before an alternate item is truly acceptable.
Read the full healthcare supply-chain guideFoundation 3 — On what terms
For an introductory path, the easiest answer is a Blanket Purchase Agreement.
The BPA provides an operational purchasing framework that can make approved content and pricing available to requisitions and purchase orders.
The interesting question is where that agreement came from.
Competitive sourcing lets the organization compare more than unit price. A negotiation can include commercial questions, qualification criteria, attachments, requirements, and additional cost factors.
This matters because the cheapest quoted unit price is not always the lowest total cost. Freight, implementation costs, payment terms, warranties, conversion effort, rebates, service requirements, and other commercial factors can change the award decision.
Supplier Qualification questions can also provide reusable due-diligence content. That allows the sourcing event to focus on the decision rather than repeatedly rebuilding the same supplier questionnaire.
Once the organization evaluates supplier responses, the award can become an operational document such as a purchase order, BPA, or Contract Purchase Agreement depending on the business scenario.
Think of Sourcing as a decision process, not just an RFQ screen. It helps the organization decide which supplier and commercial response should become actionable purchasing content.
Oracle's newer AI and agentic experiences can increasingly help buyers summarize information, prepare work, and navigate sourcing activity. Those tools may change the user experience, but the underlying flow is still demand → response → evaluation → award → purchasing execution.
External Purchase Prices becomes especially interesting when the commercial source of truth originates outside Oracle.
Healthcare is a good example because the purchasing relationship is often more complicated than “supplier + item = price.” Manufacturer and manufacturer part number may be the durable product identity, while the same product can be purchased through several distributors. The eligible price may depend on a national GPO contract, a regional agreement, a local or direct manufacturer contract, and the organization's eligibility tier.
Negotiates contracts for participating healthcare organizations. The GPO relationship can influence which manufacturer pricing the organization is eligible to receive.
Commonly supports trading-partner connectivity, transaction exchange, synchronization, and item or pricing content. It is not simply another name for a GPO.
Provides the Oracle-side framework to load external price records, map them, determine eligible sources, and make selected pricing actionable for Procurement.
EPP can store external price information without requiring every incoming manufacturer part to become a fully governed Oracle item first. With the right design, selected records can support controlled procurement access.
When the relevant manufacturer part is linked to a true Oracle item, the process becomes much more powerful because external pricing can support purchasing-agreement maintenance.
Why this matters operationally: a pricing team or external trading partner naturally knows the supplier, manufacturer, MPN, UOM, and price. They usually should not need to know which internal Oracle BPA number and BPA line happens to hold that product before they can submit a price update.
The tradeoff is design discipline. Manufacturer normalization, UOM mapping, category mapping, supplier relationships, security, and integration behavior all have to be governed. EPP is valuable because it makes the external pricing actionable—not because it gives you another place to dump a price file.
Oracle External Purchase Prices overviewEnterprise Contracts should not be treated as simply another price list.
Establishes the legal relationship, contractual language, obligations, negotiated terms, redlines, clauses, and legal governance.
Operationalizes the purchasing relationship—what can be bought and, where applicable, at what price.
A master or enterprise contract can therefore govern the legal relationship while one or more purchasing documents execute that relationship.
Legal truth and operational purchasing truth are related, but they are not the same thing. Do not force the BPA to become a contract-authoring system or force an Enterprise Contract to become a product catalog.
Sometimes the simplest answer is the right one. A buyer can create and maintain the BPA directly when the organization already knows the supplier, item, pricing, and agreement structure.
The BPA can be associated with agreed terms and conditions, but that should not be confused with full contract-authoring and redlining functionality.
Direct electronic BPA maintenance normally requires the process to know the specific agreement and line being changed. That is reasonable for an internal buyer who works in Oracle every day.
It is less natural for an external price source. The supplier, manufacturer, GPO, or pricing feed usually knows product and commercial identity—supplier, manufacturer, MPN, UOM, effective date, and price—not your internal BPA number and line.
The design question is not “which method is most sophisticated?” It is which process should own the commercial source of truth and which identifiers that source can reliably provide.
Demand
Now the foundations converge. The supplier is available, the glove exists, and commercial terms are in place.
Not everything belongs in a searchable catalog. A noncatalog request lets the requester describe something that has not been modeled as normal catalog content.
That flexibility is useful, but a blank noncatalog form can also become an invitation to inconsistent descriptions, missing information, incorrect categories, and buyer follow-up.
A Smart Form guides the requester through a specific purchasing scenario, default information, limit choices, and collect the details downstream teams will need.
Instead of telling users “submit a noncatalog requisition,” the organization can create a recognizably business-specific entry point such as:
The goal is not to eliminate exceptions. It is to make the common exceptions structured enough that Procurement does not have to rediscover the same missing information on every request. A second goal is to guide spend towards approved agreements and suppliers for compliance and value.
Descriptive Flexfields are one of the main reasons Oracle can support very different organizations without every customer needing a custom transaction.
A requisition DFF can capture additional information at the header or line, and that information can be carried into downstream purchasing processes.
Everyone sees the field. This works well when the information applies broadly and should be consistently captured.
Different fields can appear for different business situations. This keeps the page cleaner, but the context-selection experience matters: if users have to choose the right context, they may not get it right.
Information Templates use the flexfield architecture but package the questions into a reusable structure. They can be associated with Smart Forms, items, or purchasing categories.
That makes them useful when several products or request types need the same structured supplemental information. One caveat is Punchout: Information Templates cannot simply be attached inside the external supplier site, so category-based design becomes more important.
A Smart Form can predefine much of a noncatalog request, default values, narrow the questions the requester sees, and associate an Information Template.
Instead of giving users a blank noncatalog form, you can create something that feels purpose-built for legal services, capital purchases, guest speakers, research animals, lab chemicals, or another specialized request.
Design warning: collecting a field and making it useful are different jobs. Decide whether the information must appear in approvals, reporting, supplier communication, integrations, or the eventual PO before choosing the capture mechanism. Keep it simple, users faced with too many fields tend to skip them.
Locations look simple until one location field starts influencing shipping, requester defaults, inventory organizations, catalog security, receiving, and internal delivery. Even worse, Facilities, HR and Supply Chain teams all fight over ownership and management.
Think about where the supplier or carrier physically brings the shipment: a dock, receiving area, building, or other supplier-facing destination.
Think about the final internal destination: the department, office, lab, clinic, person, or supply location that actually needs the material. This is the only value a requester sees, the Ship-To is in the background.
Requisition preferences can establish a requester's normal Deliver-To location. That selection participates in the organizational context Oracle uses to determine which locations are eligible.
This creates an important troubleshooting lesson. A user may know that the correct location exists and still be unable to find it because the requester's derived inventory-organization context does not make that location eligible. Searching harder will not repair an organizational mismatch.
The Common Set is visible to everyone in the entire environment, which makes it attractive during implementation but dangerous as a default dumping ground. Operational locations are often easier to govern when they live in intentional BU-specific reference-data sets rather than making every location available everywhere.
If the same final destination can be served through materially different Ship-To routes, the design may need separate Deliver-To records so that each record carries the correct shipping relationship instead of asking a requester to understand logistics routing. Remember, requesters cannot see Ship To relationships directly.
Content zones can use Deliver-To location to influence which catalog content a requester sees. That does not mean the location list itself is secured by the same rule.
Keep these controls separate: whether a location exists, whether it is eligible for the organizational context, whether the requester may change it, and what catalog content appears for it are related questions—but they are not one setting.
A requisition and purchae order distribution tells Oracle where the financial impact should ultimately be accounted.
Depending on the organization's chart of accounts, segments may represent values such as:
The requester generally should not have to understand the accounting architecture well enough to construct the account manually. Even if they did this in their legacy ERP, values usually change during implementation. It's a great chance to make day to day operations and onboarding easier by reducing the need to memorize numbers.
Transaction Account Builder rules can use business context to derive the appropriate account combination. A rule might look at requisitioning BU, deliver-to organization, category, requester organization, project information, or other transaction attributes.
Good account derivation feels invisible. The requester expresses the business need. Oracle uses the rules to translate that need into accounting.
Some organizations use budgetary control to check whether funds are available and to reserve funds as purchasing demand moves through the process.
Other organizations do not use budgetary control for routine supply purchases at all.
When enabled, requisition and purchasing events can participate in the progression from planned funds to commitments, obligations, actual expenditures, or other budgetary states depending on the accounting model.
Requisition approval do not mean “send every request to the requester's manager.”
Approval can reflect different types of business accountability:
Approvers can act in sequence or in parallel. Parallel routing is useful when two different owners can independently review different risks and neither review truly depends on the other finishing first.
A better approval-design question: which risks require approval, and who is actually accountable for each of those risks?
Guest speakers, student workers, research participants, honoraria recipients, visiting faculty, awards, stipends, and similar payments sit awkwardly inside a traditional Procure-to-Pay model.
They are not employee expenses, they do not send conventional supplier invoices, and the recipient may not think of themselves as a supplier at all. But the organization still needs approvals, tax information, auditability, duplicate controls, appropriate accounting, and a usable front-end experience.
There is not one universally correct Oracle pattern. Four realistic choices are:
Prepare payment data outside Oracle and load it to Payables. This is the most seeded and can work well for centrally managed or high-volume batches, but the external intake process must handle validation, version control, attachments, duplicate prevention, and auditability.
A Visual Builder experience can use language and fields that make sense to the requester, then create the Payables transaction. The tradeoff is build/maintenance effort and heavier dependence on AP and invoice approval.
Treat the payee as a supplier and use a purpose-built requisition type. This preserves requisition approval, Procurement visibility, and accounting controls. Pay-on-receipt and automatic receipt can make the downstream process largely touchless when the scenario fits.
A conversational experience can ask only the questions relevant to the payment type, help with supplier onboarding, and guide the user through policy. It can be more adaptive than a static form, but it requires guardrails, security, testing, and clear ownership.
The design question is volume + initiator + approval path. A centrally managed batch of research-participant payments may deserve a different pattern than an occasional department-entered honorarium. Many organizations will reasonably use more than one method.
Supplier onboarding is still important when the recipient ultimately needs to be paid. A self-registration process can let the payee provide sensitive tax and banking information directly rather than passing those details through the requester.
Read the Payment Request deep diveBill Only is designed for healthcare demand that does not always begin with a requisition.
An implant or procedural product may already have been selected and used during patient care. Procurement still needs a controlled document to establish price, accounting, approval, receipt, invoice matching, and audit history—but sending a normal purchase order telling the supplier to ship the product would make no sense.
Header and line DFF contexts can collect information such as physician, date of service, procedure context, lot or serial reference, patient-safe identifiers, or other information needed by the healthcare workflow.
The Special Handling type can control behavior such as buyer review, whether the request is treated as negotiated, supplier requirements, and automatic receipt.
The supplier site can also be configured so a documentation-only purchase order is not unnecessarily communicated as a new order.
Primarily documents and pays for material that was already used or selected.
Adds a replenishment dimension when consumed vendor or procedural stock must also be restored.
Commitment
An approved requisition is demand. Purchasing is the operational bridge that converts that demand into a supplier commitment.
Buyers manage staged demand requiring intervention, create and maintain purchase orders, follow up on existing orders, process changes, and manage the purchasing relationship after approval.
Buyer Assignment is more hierarchical than it first appears. Testing only the Buyer Assignment Rules page can be confusing because several conditions may assign a buyer before those rules are ever evaluated.
Rule criteria can include business context such as Requisitioning BU, Procurement BU, purchasing category or category hierarchy, supplier, deliver-to organization, project, cost center, amount, currency, and whether the line is noncatalog.
Rule sequencing matters as much as rule logic. A broad fallback rule placed too high can match first and prevent a more specific category or supplier rule from ever being evaluated.
An option to assign lines to the same buyer can consolidate a requisition under one buyer. That may be convenient operationally, but it can also override the carefully determined line-level ownership you expected from BPA or category logic.
That is why buyer assignment is really an operating-model decision, not just a configuration task.
A durable model is often category-oriented ownership, supplemented by intentional ownership for strategic supplier agreements and sensible fallback rules.
Read the Ultimate Guide to Buyer Assignment RulesApproved requisition and valid sourcing can support automatic purchase-order creation with little or no buyer intervention.
The buyer reviews staged demand and creates, combines, or adjusts the order before communicating it to the supplier.
Requisition demand can become the starting point for a negotiation; the award then produces the resulting agreement or PO.
This is why Sourcing appears in more than one place on a real supply chain map.
Sometimes sourcing establishes an agreement before demand exists. Other times new demand starts the sourcing event.
Sourcing is not always “upstream.” Demand can discover that the organization does not yet have an acceptable source, causing the approved requisition to become the reason a negotiation starts.
The business requirement behind a blanket order is usually reasonable: approve an ongoing commercial relationship once, then release against it over time without recreating the entire approval process for every purchase.
The mistake is trying to reproduce that by creating one enormous requisition or one never-ending PO.
Owns the commercial truth: supplier, items or services, pricing, effective dates, controls, and release limits.
Owns the demand truth: what the business actually needs, when it needs it, where it needs it, and which accounting applies.
Owns the execution truth: the individual commitment and instruction sent to the supplier.
Imagine Item A costs $10 today and will cost $15 next quarter. The business expects 10,000 units over six months.
If the requester creates one 10,000-unit requisition line with one need date and one price, Oracle has been given inaccurate demand. Budgetary control will reserve the full amount, the resulting PO inherits the original sourcing and pricing, and future price changes become change orders, reapprovals, or invoice-tolerance problems.
Oracle can only automate the truth you give it. The requester owns the truth of demand. The buyer owns the truth of supply and price. Bad need dates and bad effective dates create a perfectly automated wrong transaction.
If prices are known by period, structure the BPA with the appropriate effective dates or price breaks. Future requisitions can then represent real demand and source to the price valid for that period rather than repairing an old transaction months later.
Approval rules can recognize that a release is sourced from an approved BPA, is within the agreement or release limit, uses the expected item, category, supplier, site, and price, and does not violate budget controls.
Clean releases can be auto-approved or lightly approved while exceptions still route for review.
Often what the supplier actually needs is a persistent agreement reference. Use the BPA number or supplier agreement number as the standing commercial reference and allow each PO to remain the individual shipment, release, receipt, and invoice reference.
Leading Practice in Fusion: the BPA owns commercial truth, the requisition owns demand truth, and the PO owns execution truth.
Physical arrival
Our gloves are now on a truck and arrive at the hospital. Before we explain receipt routing, we need to understand the destination options.
The material becomes stocked inventory. Central Stores is a good example. Oracle will track on-hand balances and the product can later participate in movements, transfers, counting, and replenishment. We can track lot and serial, even item revisions, or just simple on-hand.
The purchase is delivered for consumption rather than added to normal perpetual inventory. Many self-service purchases and point-of-use or PAR supply processes use this model.
For this guide: assume the gloves are purchased into a Central Stores inventory organization so we can follow them into inventory and replenishment.
Arrival and delivery/putaway are effectively recorded together. Oracle can default a subinventory or locator while the receiver records where the material was actually placed.
Receiving and delivery are separated. The dock can acknowledge high-volume arrivals before another process performs putaway. This may be called 2-step Receiving.
Material is received, inspected according to required criteria, and accepted material proceeds to delivery or putaway.
The physical receipt may occur before the supplier invoice. Oracle therefore needs a way to recognize that the organization has received economic value even though AP has not yet recorded the supplier liability.
Depending on the organization's accounting design, purchasing accruals may be recognized at receipt or through period-end accrual processing.
The accounting consequence is associated closely with the receiving event.
The organization recognizes qualifying uninvoiced purchasing activity through the period-end process.
This is one of the clearest examples of a physical supply chain event immediately becoming part of the financial supply chain.
Expense purchasing creates a classic Procure-to-Pay problem: the person who knows whether the product arrived may not work in Receiving, while AP cannot safely pay an invoice that requires receipt evidence until someone records the receipt.
Oracle gives the organization several ways to close that gap.
Receiving staff can record the arrival when the organization operates a central dock or wants physical receipt control centralized.
Requesters can record and correct their own receipts in the self-service experience, including from mobile-friendly Redwood pages.
Receipt-confirmation notifications can take the action to the requester instead of expecting the requester to remember to visit Oracle.
The requester can be given actions such as Receive in Full, Receive up to the Invoiced Amount, or Did Not Receive.
A “Did Not Receive” response can become a useful escalation to the buyer rather than silently leaving AP to chase the problem.
Design the exception path too. Reminders are useful only if the organization also knows what should happen when the requester says the item never arrived, the quantity is wrong, or the supplier invoiced before delivery.
These requester-oriented flows are primarily useful for expense purchases. Inventory-controlled receipts, especially items requiring lot or serial capture, belong in the appropriate receiving and inventory process rather than being reduced to a simple requester confirmation.
Self-service receiving and receipt notificationsA PO receipt only proves that a shipment reached the organization. What about proving that the package reached the requester, department, lab, clinic, or final drop zone?
Receipt Deliveries in Oracle Mobile Inventory fills that last-mile gap. Think of it as internal package logistics after receiving, not as a replacement for UPS or FedEx tracking.
The package becomes an Oracle delivery object that can be labeled and followed through the internal process.
Deliveries are grouped into operational carts. A “cart” can represent the physical reality that makes sense locally: a cart, pallet, vehicle, route, or another reusable delivery grouping.
The process can capture delivery confirmation, and organizations can use proof such as signatures or photographs where the business risk justifies the extra step.
The feature is not restricted to traditional item-master purchases. The operating model can support packages with or without Oracle item numbers and can also support manually created deliveries when there is no normal PO-driven receipt to start from.
The native model is primarily Create → Cart → Deliver. It is not a rich carrier-style chain of many intermediate package scans.
Dock Logging can record that a tracking number arrived at a particular time. That is useful evidence of arrival, but it does not by itself prove that the package reached the final destination. You shouldn't use both - if possible, use Package Tracking to track receipt and delivery of each tracking number.
Receipt Delivery is the process to use when internal delivery completion matters.
Design takeaway: use Receipt Delivery for packages you need to prove you delivered.
Material control
Once the gloves are in Central Stores, Oracle Inventory becomes the system of record for on-hand material.
The inventory team needs to preserve accurate quantities and locations as material is moved, transferred, issued, counted, and replenished.
Both processes compare what Oracle thinks exists with what people physically count. The more important distinction is how each process treats operations while the count is underway.
Counts a selected population on a recurring basis. Expected quantity continues to account for properly recorded transactions after the count sequence is generated, so normal operations can continue when the physical movement and Oracle transaction stay in sync.
Takes a broader snapshot of one or more subinventories. Because expected quantity is tied to that snapshot, movements after the snapshot can create bad adjustments if operations are not tightly controlled or frozen until the count is posted.
Cycle Count also lets discrepancies be reviewed and approved at a more granular level. Physical Inventory tends to behave more like one formal count event.
One operating pattern worth considering is whether a broadly configured Cycle Count can replace the traditional annual Physical Inventory.
A count can be structured to include the required population and manually generated sequences while preserving the operational benefits of cycle-count processing.
That lets the organization resolve material discrepancies, resume clean items sooner, and avoid freezing an entire operation longer than necessary.
Do not choose Physical Inventory merely because “we have always done an annual physical.” Start with the control objective, audit expectation, operational risk, and how the organization actually wants to investigate discrepancies.
If a cycle counter finds 100 units where Oracle says 90, correcting Oracle to 100 fixes today's number. It does not fix the process that created the ten-unit difference.
The real value of counting is finding the process leak.
Do not investigate every tiny variance with the same intensity. Focus attention on material discrepancies, recurring patterns, sensitive items, or locations that repeatedly fail.
Use a root-cause approach such as the 5 Whys. The point is not to literally ask “why” five times; it is to keep going until the team reaches a fixable process, data, training, or environmental cause.
A good corrective action changes the process so the same error is less likely to recur. Otherwise the warehouse simply pays people to discover the same mistake again next month.
Common root causes may be surprisingly mundane: case-versus- each UOM mistakes, full and partial boxes stored together, confusing locator labels, movements performed physically but not transacted, or a culture where counts are copied from paper instead of independently observed.
Avoid “human error” as the final answer. If people repeatedly make the same mistake, ask what about the training, labels, system design, UOM setup, workflow, or physical environment makes that mistake easy to make.
These products overlap at the edges, but they solve different levels of operating complexity.
The system of record for material transactions, receiving, on-hand balances, subinventories, locators, lots, serials, Min/Max, PAR sourcing, transfer orders, movement requests, internal requisitions, cycle counts, physical inventory, and related accounting. You need Inventory to have Advanced Inventory or WMS!
Strengthens lower- to moderate-complexity warehouse execution where mobile operators need assigned work, directed activity, LPN-enabled transactions, putaway suggestions, or stronger workload control without adopting a full WMS platform.
A warehouse execution platform for operations where optimization, scale, task orchestration, packing, shipping, automation, capacity, labor, slotting, and complex warehouse flows are strategic requirements.
The replenishment calculation belongs in Inventory. Advanced Inventory or WMS may help execute warehouse work, but they do not replace the underlying replenishment model.
Inventory owns the source configuration and resulting demand. WMS can execute an inventory-sourced request after the source has been selected; it does not dynamically decide supplier versus internal stock during the pick.
Replace invisible demand with internal requisitions or controlled movement requests. A better warehouse execution engine cannot repair an informal demand-intake process by itself.
Label locators, define overflow locations, enforce system movements, and improve location accuracy before buying optimization technology.
Last-mile delivery of expense packages is different from warehouse fulfillment and outbound carrier shipping. Receipt Deliveries belongs with the Fusion Inventory/mobile operating model.
“We need kitting” can describe three completely different problems:
A useful diagnostic question: are we trying to decide what supply should exist, record what happened, assign work to an operator, or optimize how a complex warehouse executes work? Those are different problems.
WMS cannot automatically repair weak item setup, unclear locator design, informal demand, poor receiving discipline, inaccurate on-hand balances, or missing replenishment parameters. Solve the operating problem first, then select the execution capability that fits it.
Pick the capabilities that matter most. The score is a teaching aid to show which product deserves the strongest look—not a licensing recommendation.
Strongest when the primary needs are control, replenishment, receiving, traceability, package delivery, internal demand, locator discipline, and proportional implementation effort.
Strongest when Inventory remains the foundation but mobile operators need assigned work, directed execution, LPN-enabled transactions, or more structured putaway.
Strongest when warehouse execution and optimization are strategic capabilities involving waves, slotting, labor, automation, packing, shipping, complex LPNs, or value-added services.
This simplified selector intentionally does not represent every capability, integration, release enhancement, or licensing consideration. Validate detailed functionality in the Oracle release and subscriptions used by your organization.
Demand repeats
Central Stores begins issuing gloves to clinical locations. Eventually supply runs low, and a new demand signal has to be created.
Two useful introductory patterns are Min/Max and PAR.
Oracle uses system-maintained supply and on-hand information. When the planning position falls below the minimum, the process calculates replenishment toward the configured maximum.
A user counts or records demand at a PAR location. Oracle applies the configured PAR logic and creates the corresponding replenishment request.
Depending on sourcing and setup, Min/Max demand can result in:
Conceptually, Supply Chain Orchestration acts as a traffic controller: demand has been identified and Oracle needs to determine which supply path should execute it.
PAR works well where supplies are consumed freely and Oracle may not maintain a reliable perpetual shelf-level on-hand balance between counts.
That is common in nursing units, procedure areas, laboratories, and other point-of-use locations.
The Central Stores item can still be fully inventoried. The difference is that material is often expensed when it is issued to the point of use, and the next replenishment signal comes from what someone observes or requests at the PAR location.
The counter records what is physically present. Oracle compares the observation with the configured PAR target and determines the replenishment quantity.
The user does not need to perform a full shelf count. Triggering the PAR requests the predefined replenishment quantity—conceptually similar to a Kanban or two-bin signal.
The user directly enters the quantity needed. It behaves more like a very lightweight replenishment request while staying in the PAR workflow.
A subinventory can provide the normal count-type behavior, while item-specific configuration can support exceptions where the business process requires them.
Oracle uses its maintained supply picture—on-hand, relevant supply or demand, planning parameters, and source setup—to determine whether replenishment is needed.
Someone counts, presses a replenishment trigger, or enters a desired order quantity because the point-of-use location is intentionally not behaving like perpetual warehouse inventory.
PAR is not “lazy inventory control.” It is a different control model for locations where speed and availability matter more than recording an Oracle transaction every time a clinician removes a box of gloves from a shelf.
When the normal path breaks
Now imagine the glove manufacturer announces a backorder—or the product is recalled.
Unfortunately, no ERP can eliminate exceptions. Oracle Fusion provides a controlled way to deal with the common ones.
Item relationships and replacement processes can help propagate a controlled product change. Internal inventory may satisfy demand through movement or transfer orders. Purchasing may need to find a new source.
Healthcare adds another dimension: a technically available substitute is not necessarily clinically interchangeable. Value analysis, clinical approval, packaging, usage, and EHR implications may still have to be considered.
A discontinued or recalled product can appear in many places: purchasing agreements, open purchase orders, replenishment parameters, sourcing rules, PAR locations, catalogs, clinical systems, preference cards, warehouse shelves, and reporting.
Changing one PO therefore fixes only one transaction.
A better response asks where the old item is still actionable and where the approved replacement needs to become visible.
Which requisitions, replenishment requests, PAR locations, or open PO lines still point to the disrupted product?
Is the replacement sourced from the same supplier, a new supplier, internal stock, or another organization?
Is the alternate truly interchangeable, or does it require value-analysis, clinical, quality, or regulatory approval?
Mass Item Replacement can be useful when the organization needs a governed way to propagate a replacement through eligible supply-chain structures instead of manually finding every occurrence.
The real exception process is not “find another item.” It is identify the affected demand, approve the substitute, redirect supply, update the places that generate future demand, and preserve enough history to understand what changed.
The connected financial story
The financial supply chain has been following the physical item almost the entire time.
| Business event | Typical financial meaning |
|---|---|
| Requisition approved | Funds are reserved when budgetary control is used. |
| PO approved | Purchasing commitment or obligation is established or transferred according to the accounting design. |
| Goods received | Receipt accrual or another receiving accounting event may occur. |
| Delivered to inventory | Inventory valuation is established through the applicable costing process: Standard, Actual or Average by org or subinventory. |
| Material issued | Inventory value moves toward expense, work order, project, or another destination. |
| Invoice validated | The supplier liability is recognized according to the payable and accounting process. |
| Invoice matched | Price, quantity, purchase order, and receipt evidence are compared according to matching controls. |
| Payment | The supplier liability is settled. |
Matching is one of the controls that connects Procurement, Receiving, and Payables.
Before an invoice can proceed normally, Oracle compares the supplier's invoice with the purchasing and receiving evidence required by the organization's matching setup.
Compares the invoice to the purchase order. This may be appropriate where receipt evidence is not part of the control, such as some service purchases.
Adds receipt quantity to the comparison. Oracle now expects the invoice, PO, and receipt to agree within the configured tolerances.
Adds inspection or acceptance evidence so payment can depend on the product not only arriving, but also being accepted.
A single invoice can violate more than one tolerance. Price, ordered quantity, received quantity, and other matching checks can generate independent holds.
Removing one problem does not mean the invoice is automatically ready to pay.
Tolerances can be established as organizational defaults and, where appropriate, refined for supplier-specific behavior.
System holds are useful because they identify that Oracle's version of the transaction and the supplier's version do not agree.
Manually releasing the hold may be appropriate in a legitimate exception, but recurring manual releases usually hide a broken upstream process.
Example: if the same supplier repeatedly creates a price hold because the invoice says $15 while the BPA says $10, the long-term answer is probably not “AP should release the hold faster.” Determine whether the supplier is invoicing incorrectly or whether the buyer failed to update the commercial source of truth.
AP may see an invoice on hold because Oracle has no receipt. The requester may know the product arrived. The buyer may know the supplier shipped late. Receiving may know it went to the wrong dock.
None of those teams alone has the complete story.
Receipt-confirmation notifications can send the question back to the requester so they can receive the material—or explicitly say it did not arrive.
That is much better than an AP analyst repeatedly sending emails asking for a receipt.
The cultural takeaway: match exceptions are not an AP cleanup queue. They are a cross functional problem to solve together.
The bigger lesson
A giant Oracle Fusion architecture diagram makes the suite look like a collection of applications.
Leverage the flowchart to see how Oracle Supply Chain modules are a connected set of business objects and decisions that continually cross application boundaries.
A supplier, item, and agreement make a product purchasable. A requisition expresses demand. A purchase order creates a commitment. A receipt acknowledges arrival. Inventory records where material is. Replenishment creates the next demand signal. Payables settles the obligation. Costing records the financial impact.
Instead of asking “Which module does this belong to?”, ask: “What business event just happened, what does Oracle need to know about it, and which application owns that part of the story?”
Once you understand the simple path, the larger Oracle Fusion Supply Chain architecture becomes much less intimidating. The modules stop looking like separate products and begin looking like different owners of one connected business story.
The simplified journey above is deliberately linear enough to teach. The real architecture is not. Supplier Management, Strategic Procurement, Self Service Procurement, Purchasing, Inventory, Receiving, Costing, Payables, Manufacturing, and replenishment processes intersect in several places.
Select one answer for each question, then choose Check My Answers. Explanations appear after grading.
Working through a complex Oracle Fusion Supply Chain design, planning an implementation, or looking for someone to speak about Oracle or AI? Send me a note.
Your message has been sent. I'll get back to you as soon as I can.
Join the mailing list for future walkthroughs, design patterns, and Oracle Fusion updates.