Oracle Cloud Procurement common mistakes
Oracle Cloud Procurement · Understand the traps and how to avoid them.
Treating the requisition-to-purchase-order path as a single approval workflow, and answering questions as if one BPM task approves a requisition, its lines, and the resulting PO together.
Candidates memorize 'requisition approval' as a single step and miss that requisition header and line approvals are separate configurable tasks, that document styles and tolerances change routing, and that PO approval is an independent workflow triggered after the requisition is fully approved and the buyer submits the order.
What to do instead
Map the approval chain explicitly: requisition header approval, requisition line approval, purchase order approval, and change order approval are distinct BPM tasks with their own rules. Practice tracing a requisition with mixed line types and note which task fires at each stage before answering.
Assuming a configured document style or approval rule applies globally, without checking whether it is scoped to a business unit, procurement BU, or specific document type.
Setup pages present document styles, approval rules, and tolerances as if they were single global settings, but many are business-unit-specific or tied to a document type. Candidates who set one value and expect it everywhere pick the wrong answer on scoping questions.
What to do instead
For every configuration object, memorize its scoping dimension: business unit, procurement BU, document type, category, or supplier. Build a one-page table of setup objects and their scope, and check scope before selecting an answer.
Confusing the roles of buyer, requester, and preparer when describing who can edit, submit, or approve a requisition or purchase order.
Self-service procurement separates the person who needs the goods, the person who prepares the document, and the buyer who manages the order. Candidates collapse these into one actor and then misjudge which actions are available at each step.
What to do instead
Learn the action matrix per role: requester creates and submits, preparer edits on behalf, buyer sources and submits the PO, approver acts only on assigned tasks. Walk through a full transaction naming the actor and allowed action at each step.
Treating requisition line types (goods, services, fixed-price services, rate-based services) as interchangeable when predicting downstream behavior, such as receipt requirements or invoicing.
Line type controls whether a receipt is required, how milestones or rate cards apply, and whether the line can be billed against. Candidates who treat all lines as 'goods' mispredict receiving and matching outcomes.
What to do instead
Build a comparison table for each line type covering receipt requirement, invoicing method, and whether milestones or rate cards apply. Use it to reason through a scenario before choosing an answer.
Assuming a supplier is immediately usable after creation, without accounting for the registration, approval, and onboarding states that must complete first.
Supplier creation, registration, approval, and site activation are separate stages. Candidates who stop at 'supplier record created' choose answers that assume the supplier is already transactable, which is wrong when onboarding is incomplete.
What to do instead
Trace the supplier lifecycle end to end: registration, approval, site creation, and activation, noting which state blocks requisitioning and PO creation. Ask 'is the supplier active and does it have a valid site?' before assuming a transaction can proceed.
Ignoring supplier site and business classification when predicting whether a PO can be created, which payment terms apply, or whether the supplier appears in a search.
A supplier can exist without an active purchasing site, and business classifications drive default payment terms and tax behavior. Candidates focus on the supplier header and overlook site-level and classification-level configuration.
What to do instead
Always check three things: supplier status, purchasing site status, and business classification. Memorize that transaction defaults come from the site and classification, not the supplier header alone.
Mixing up when sourcing events and negotiations create awards versus when they create contracts or purchase orders.
Sourcing, negotiation, and award are distinct phases, and the output of an award depends on configuration and the buyer's choice of action. Candidates assume an award automatically becomes a contract or a PO.
What to do instead
Learn the sequence: sourcing event, responses, evaluation, award, then a separate decision to create a PO, a contract, or both. Answer award questions by identifying the explicit follow-on action, not by assuming automatic document creation.
Treating contract terms, contract types, and contract templates as the same configuration object.
Templates control document structure, contract types control behavior such as approval and deviation rules, and terms define clauses. Candidates who blur these pick answers that apply the wrong control to the wrong object.
What to do instead
Separate the three: template equals layout, contract type equals behavior and approval routing, terms equal clause content. When a question mentions deviations or approvals, reason from contract type and terms, not template.
Assuming invoice matching always uses two-way match, and mispredicting whether a receipt or a PO is required for a line to be invoiced.
Match type depends on line type, receipt requirement, and configuration. Candidates who default to two-way match misjudge why an invoice is on hold or cannot be matched.
What to do instead
Determine match type from the requisition line type and receipt requirement first, then reason about holds. Memorize that services lines and goods lines often differ in receipt requirement and therefore in match behavior.
Confusing change order handling, such as when a PO revision requires reapproval, with initial PO approval rules.
Change orders have their own approval triggers based on amount changes, tolerance thresholds, and whether the change is within an approved threshold. Candidates apply initial approval logic to revisions and get the routing wrong.
What to do instead
Study change order approval separately: identify which changes trigger reapproval, how tolerance thresholds apply, and how the revised amount is compared to the original. Practice with a PO whose amount increases beyond and within tolerance.