Oracle Fusion Procure-to-Receive Test Cases
Validate the end-to-end Procure-to-Receive journey in Oracle Fusion SCM — requisition creation and approval, purchase order creation and approval, and goods receipt including partial and exception receipts — with emphasis on data correctly carrying forward across each stage, orchestrating rather than duplicating the individual Procurement family pages this journey links to.
| Test ID | ORCL.SCM.E2E.P2R |
| Application | Oracle Fusion Cloud |
| Product | SCM |
| Module | End-to-End SCM |
| Process | Procure-to-Receive |
| Business Flow | Procure-to-Pay |
| Scenario Type | End-to-End / Functional |
| Test Usage | Functional Testing / Regression Testing / UAT |
| Priority | High |
| Automation | SyntraFlow Ready |
| Library | Syntra Standard |
Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions across each Procurement family page automatically while presenting the journey as business-readable test steps for documentation, review and reporting. This scenario is presented as 6 business-readable test steps; SyntraFlow's automation executes approximately 74 underlying Oracle Fusion UI actions to complete it.
Test Objective
The objective of this test is to validate the end-to-end Procure-to-Receive journey in Oracle Fusion SCM — requisition creation and approval, purchase order creation and approval, and goods receipt including partial and exception receipts — with emphasis on data correctly carrying forward across each stage (quantity, price, supplier, item), rather than re-testing each stage's individual field-level validation, which is already covered on the linked Procurement family pages this scenario orchestrates.
The scenario should confirm that:
- the approved requisition's item, quantity and pricing data correctly carry forward into the purchase order
- the approved purchase order's item, quantity, supplier and pricing data correctly carry forward into the goods receipt
- partial receipts correctly track remaining open quantity across the journey
- inspection-required items correctly route to acceptance or to receiving exceptions
- a purchase order change made after requisition approval is correctly reflected in subsequent receiving
- unauthorized users are correctly blocked from receiving at any stage of the journey
This scenario validates the hand-offs and cross-stage data integrity of the Procure-to-Receive journey in Oracle Fusion SCM TEST/UAT environments. It does not duplicate the individual field-level scenario coverage already tested on the Create Purchase Requisition, Approve Requisition, Create Purchase Order, Approve Purchase Order, Receive Purchase Order, Partial Receipt, Inspect Receipt and Receiving Exceptions family pages — this page links to and orchestrates those live pages into an end-to-end journey.
When to Use This Test
- Regression testing that quantity, price, supplier and item data correctly carry forward from an approved requisition into a purchase order and then into a goods receipt
- Validating hand-offs across the linked Procurement family pages — Create Purchase Requisition, Approve Requisition, Create Purchase Order, Approve Purchase Order, Receive Purchase Order, Partial Receipt, Inspect Receipt and Receiving Exceptions — rather than re-testing each page's individual field-level scenarios
- UAT sign-off for procurement and receiving teams who need confidence the full requisition-to-receipt journey works end-to-end, not just each transaction in isolation
- Diagnosing cross-stage data mismatches, blocked hand-offs or misrouted inspection/exception outcomes before escalating as a possible APPLICATION_ERROR
- Baseline orchestration scenario referenced by the broader Procure-to-Pay end-to-end journey, which continues from receipt into invoice matching and payment
Where This Test Fits in the Procure-to-Pay Process
This Procure-to-Receive scenario spans the full requisition-to-receipt journey within the broader Procure-to-Pay business flow, orchestrating the Create Purchase Requisition, Approve Requisition, Create Purchase Order, Approve Purchase Order, Receive Purchase Order, Partial Receipt, Inspect Receipt and Receiving Exceptions family pages rather than duplicating their individual scenario coverage. From receipt, the journey typically continues into invoice matching and payment, covered by the broader Procure-to-Pay end-to-end scenario.
Preconditions
- The requisitioning, approval, purchase order and receiving Procurement family pages referenced by this journey are individually functional in the target Oracle Fusion SCM environment.
- A valid supplier, item and organization are available and enabled for procurement and receiving.
- Approval workflows for requisitions and purchase orders are configured for the test user's business unit.
- The test user holds the roles required to execute each stage of the journey, or alternate unauthorized-user personas are available for security testing.
- Receiving tolerances, inspection requirements and receiving exception routing are configured according to the target environment — this scenario does not assume a universal tolerance or inspection configuration.
Exact tolerance percentages, inspection requirements, approval hierarchies and receiving exception routing vary by Oracle Fusion implementation and customer-specific configuration. This scenario validates that Oracle correctly enforces whatever configuration is in place at each hand-off, not a single universal rule.
Sample Test Data
| Requisition | ${REQUISITION} |
| Purchase Order | ${PURCHASE_ORDER} |
| Supplier | ${SUPPLIER} |
| Item | ${ITEM} |
| Quantity | ${QUANTITY} |
| Receipt | ${RECEIPT} |
| Organization | ${ORGANIZATION} |
| User Role | ${USER_ROLE} |
Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion SCM TEST/UAT environment. Not every field applies to every journey variation — for example, receipt tolerance and inspection fields apply only where those features are configured.
Test Steps
6 business-readable steps. SyntraFlow's automation executes ~74 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.
| # | User Action | Expected Result |
|---|---|---|
| 1 | Create and Approve Purchase Requisition Create a purchase requisition for the required item and quantity, then route it through approval, referencing the standard Create Purchase Requisition and Approve Requisition test scenarios. ${REQUISITION} / ${ITEM} / ${QUANTITY} | The requisition is created and approved, with its status correctly reflecting approval before purchase order creation begins. |
| 2 | Create and Approve Purchase Order Referencing the Requisition Create a purchase order sourced from the approved requisition and route it through approval, referencing the standard Create Purchase Order and Approve Purchase Order test scenarios. ${PURCHASE_ORDER} / ${SUPPLIER} / ${REQUISITION} | The purchase order is created referencing the approved requisition and is approved before receiving begins. |
| 3 | Receive Against the Purchase Order Receive against the approved purchase order — in full, as a partial receipt, or capturing an inspection or receiving exception where the scenario calls for it — referencing the standard Receive Purchase Order, Partial Receipt, Inspect Receipt and Receiving Exceptions test scenarios. ${RECEIPT} / ${PURCHASE_ORDER} / ${ORGANIZATION} | The receipt is recorded against the purchase order with the correct quantity, and any inspection or exception is routed as expected. |
| 4 | Verify Quantity and Pricing Consistency Across StagesBusiness assertion Compare the item, quantity and price captured at the requisition, purchase order and receipt stages of the journey. ${ITEM} / ${QUANTITY} This is a primary business assertion for the journey — matching data across all three stages is the expected pass condition, not merely three individually successful transactions. | Quantity and pricing data correctly carry forward from the requisition to the purchase order to the receipt, with any deviations correctly flagged. |
| 5 | Verify Inspection-Required Items Route Appropriately Where the received item requires inspection, confirm the inspection result correctly routes the receipt to acceptance or to receiving exceptions. ${ITEM} / ${RECEIPT} | Inspection-required items are correctly routed to acceptance on pass or to receiving exceptions on reject. |
| 6 | Verify Audit Trail Links Requisition, Purchase Order and ReceiptBusiness assertion Review the audit trail or document reference chain connecting the requisition, purchase order and receipt for the journey. ${REQUISITION} / ${PURCHASE_ORDER} / ${RECEIPT} This is the final business assertion for the scenario — a traceable, correctly linked document chain is the expected pass condition for the full journey. | The requisition, purchase order and receipt are correctly linked in the audit trail, confirming the end-to-end journey is traceable. |
Expected Results
- The requisition is created and approved before purchase order creation begins.
- The purchase order correctly reflects the approved requisition's item, quantity and pricing data.
- The goods receipt correctly reflects the purchase order's item, quantity and supplier data, including partial and exception receipts.
- Inspection-required items are correctly routed to acceptance or to receiving exceptions.
- Purchase order changes made after requisition approval are correctly reflected in subsequent receiving.
- Unauthorized receiving attempts are correctly blocked at any stage of the journey.
Key Validation Checkpoints
- requisition data correctly carries forward into the purchase order
- purchase order data correctly carries forward into the receipt
- partial receipts correctly track remaining open quantity across the journey
- inspection results correctly route to acceptance or exception handling
- PO changes correctly reflect in subsequent receiving
- unauthorized receipt actions correctly blocked at any stage
Go Beyond the Standard Test with Jarvis AI
The Syntra Standard Test Library defines the core Procure-to-Receive journey as an orchestration across the Procurement family pages within SCM. Jarvis AI extends this scenario by following the pipeline from SCM to Functional Area, Process/Scenario Family and Standard Test Scenarios, then combining it with DataVault test data to generate Jarvis Variations — organized as Positive, Negative and Security categories — before they can be assembled into a Regression Pack and Scheduled Execution, with results surfaced through Failure Intelligence.
Teams do not need to manually stitch together requisition, purchase order and receiving tests for every supplier, item, organization or exception path. Jarvis uses the standard journey as the foundation and generates relevant Positive, Negative and Security variations for the customer's environment — including partial receipts, tolerance breaches and inspection routing — since correctly enforced hand-offs between stages, not just individually correct transactions, is what this journey scenario proves. These Jarvis-generated variations do not create additional public SEO pages, and this page itself does not duplicate the individual scenario coverage already tested on the family pages it links to; this page remains the canonical reference for the end-to-end journey.
From Standard Test to Executed Regression Pack
Rather than re-testing every requisition, purchase order and receipt field individually — already covered on their respective family pages — SyntraFlow maintains one core Procure-to-Receive journey scenario, with 12 example end-to-end scenarios documented below, and allows Jarvis AI to generate supplier, item, organization and security-specific journey variations using the customer's available test data. These variations do not create additional public SEO pages.
AI-Generated Test Variations
The same Procure-to-Receive business scenario can produce many test variations without creating separate public library pages. Below is a real slice of SyntraFlow's Build Scripts library, filtered to SCM End-to-End.
- Standard end-to-end journey from requisition through approval, purchase order through approval, to full receipt
- Journey validating quantity and price carry-forward from the requisition into the purchase order
- Multi-line requisition to multi-line purchase order journey
- Journey ending in a partial receipt against the purchase order
- Journey with an inspection-required item that passes inspection
- Journey with a purchase order change after requisition approval and a downstream receipt against the revised purchase order
- Cross-organization journey with different requesting and receiving organizations
- Journey where a receipt quantity exceeds purchase order tolerance
- Journey where an inspection-required item fails inspection and routes to receiving exceptions
- Journey where purchase order creation is blocked pending budget or supplier setup after requisition approval
- Journey where an unauthorized user attempts to receive against a purchase order without the receiving role
These are representative examples only. Journey behavior, tolerance configuration and available hand-off paths can depend on the customer's Oracle Fusion configuration, controls and security — not every Oracle configuration behaves identically.
Generated Using Your DataVault Test Data
Generic test data rarely represents every supplier, item, organization and exception path in a real Oracle Fusion Procure-to-Receive journey. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct journey scenarios relevant to the customer's actual implementation.
Standard Library Definition
Requisition ${REQUISITION}
Purchase Order ${PURCHASE_ORDER}
Supplier ${SUPPLIER}
Item ${ITEM}
Quantity ${QUANTITY}
Receipt ${RECEIPT}
Organization ${ORGANIZATION}
User Role ${USER_ROLE}
DataVault
Suppliers Active suppliers enabled for procurement Items Active items with tolerance and inspection flags by organization Organizations Requesting and receiving organizations Approvals Requisition and purchase order approval hierarchies Security Roles authorised at each stage of the journey
Jarvis AI Generates
Scenario 01 — Standard Journey, ${ITEM}
Scenario 02 — Partial Receipt Against ${PURCHASE_ORDER}
Scenario 03 — Inspection Reject Routes to Exceptions
Scenario 04 — Cross-Organization Journey
Scenario 05 — Over-Tolerance Receipt Blocked
Scenario 06 — Unauthorized User Attempts Receipt
...
Requisition, purchase order and receipt data used in Procure-to-Receive testing are masked or synthetic through Syntra DataVault — never real production data. The public Syntra Standard Test Library uses illustrative placeholder data only, and where DataVault is connected, customer-specific supplier, item and organization dimensions remain within the customer's controlled SyntraFlow environment and access model, protected according to DataVault's data masking policies. See /datavault/data-masking/ for details.
Example Test Variations
This catalog spans 12 end-to-end Procure-to-Receive journey scenarios validating requisition-to-PO-to-receipt data integrity and hand-offs across Procurement family pages, plus negative/security journey testing. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.
| ID | Variation | Type | Key Difference | Execution |
|---|---|---|---|---|
| E2E-P2R-001 | Standard Requisition-to-Receipt Journey | Positive | Create and approve requisition ${REQUISITION}, create and approve purchase order ${PURCHASE_ORDER}, then receive in full; item, quantity and pricing data match at every stage. | SyntraFlow Ready |
| E2E-P2R-002 | Requisition-to-PO Quantity and Price Carry-Forward | Positive | Verify that quantity and price entered on requisition ${REQUISITION} for ${ITEM} correctly carry forward unchanged onto purchase order ${PURCHASE_ORDER}. | SyntraFlow Ready |
| E2E-P2R-003 | Multi-Line Requisition to Multi-Line Purchase Order Journey | Positive | Create a multi-line requisition ${REQUISITION} with multiple items and quantities, and verify each line correctly carries forward onto multi-line purchase order ${PURCHASE_ORDER}. | SyntraFlow Ready |
| E2E-P2R-004 | Journey Ending in Partial Receipt | Positive | Receive a quantity less than the full ${QUANTITY} ordered on purchase order ${PURCHASE_ORDER}, and verify the remaining open quantity is correctly tracked. | SyntraFlow Ready |
| E2E-P2R-005 | Receipt Quantity Exceeding PO Tolerance | Negative | Attempt to receive a quantity for ${ITEM} that exceeds the tolerance configured on purchase order ${PURCHASE_ORDER}; Oracle correctly flags or blocks the over-tolerance receipt. | SyntraFlow Ready |
| E2E-P2R-006 | Inspection-Required Item — Pass Result | Positive | Receive an inspection-required item ${ITEM} against ${PURCHASE_ORDER} and pass inspection; the receipt correctly routes to acceptance. | SyntraFlow Ready |
| E2E-P2R-007 | Inspection-Required Item — Reject Routes to Receiving Exceptions | Negative | Receive an inspection-required item ${ITEM} against ${PURCHASE_ORDER} and fail inspection; the receipt correctly routes to receiving exceptions. | SyntraFlow Ready |
| E2E-P2R-008 | Requisition Approved but PO Creation Blocked Pending Setup | Negative | Approve requisition ${REQUISITION} for supplier ${SUPPLIER} that lacks required budget or supplier setup; purchase order creation is correctly blocked pending resolution. | SyntraFlow Ready |
| E2E-P2R-009 | PO Change After Requisition Approval with Downstream Receipt | Positive | Change purchase order ${PURCHASE_ORDER} quantity or price after requisition ${REQUISITION} approval, then receive against the revised purchase order; the receipt correctly reflects the revised PO data. | SyntraFlow Ready |
| E2E-P2R-010 | Receiving Exception — Wrong Item or Over-Receipt Blocked | Negative | Attempt to receive an item that does not match ${PURCHASE_ORDER} or a quantity that exceeds the ordered ${QUANTITY}; Oracle correctly blocks the receipt as a receiving exception. | SyntraFlow Ready |
| E2E-P2R-011 | Multi-Organization Requisition-to-Receipt Journey | Positive | Create requisition ${REQUISITION} in requesting organization ${ORGANIZATION} and receive purchase order ${PURCHASE_ORDER} in a different receiving organization; data correctly carries forward across organizations. | SyntraFlow Ready |
| E2E-P2R-012 | Unauthorized Attempt to Receive Without Receiving Role | Negative/Security | Attempt to receive against approved purchase order ${PURCHASE_ORDER} as a user without the ${USER_ROLE} receiving role; Oracle correctly prevents the receipt. | SyntraFlow Ready |
No variations match this filter.
Automatically Expand Positive and Negative Procure-to-Receive Coverage
Positive Testing
Jarvis generates journey scenarios using requisition, purchase order, supplier, item and organization combinations expected to successfully complete the Procure-to-Receive journey in Oracle Fusion.
Approved Requisition + Approved Purchase Order + Valid Receipt Within Tolerance → Journey Completed
Negative Testing
Jarvis can also generate journey scenarios designed to exercise Oracle's validations around tolerance, inspection, budget/supplier setup and receiving security at any stage of the hand-off.
- Receipt Quantity Exceeds PO Tolerance → Expected Tolerance Validation
- Inspection Reject → Expected Routing to Receiving Exceptions
- Requisition Approved but PO Blocked on Budget/Supplier Setup → Expected Validation
- Unauthorized User Attempts Receipt → Expected Access Restriction
A negative end-to-end scenario passes when Oracle correctly enforces the expected data, configuration or security rule at any stage of the journey.
| Scenario | Oracle Outcome | Test Result |
|---|---|---|
| Valid journey data at every stage | Journey completes end-to-end | PASS |
| Data mismatch between stages | Validation or warning occurs | PASS |
| Missing required upstream document | Validation occurs | PASS |
| Unauthorized user at any stage | Access prevented | PASS |
| Unexpected application exception | Unexpected failure | FAIL |
Turn AI-Generated Variations into a Regression Pack
Users can select generated Procure-to-Receive journey scenarios and group them into reusable execution packs.
SCM End-to-End Procure-to-Receive Regression Pack
- Standard Requisition-to-Receipt Journey
- Requisition-to-PO Quantity and Price Carry-Forward
- Multi-Line Requisition to Multi-Line Purchase Order Journey
- Journey Ending in Partial Receipt
- Receipt Quantity Exceeding PO Tolerance
- Inspection-Required Item — Pass Result
- Inspection-Required Item — Reject Routes to Receiving Exceptions
- PO Change After Requisition Approval with Downstream Receipt
- Receiving Exception — Wrong Item or Over-Receipt Blocked
- Unauthorized Attempt to Receive Without Receiving Role
Run On-Demand or Schedule Automated Batch Execution
SyntraFlow can execute selected Procure-to-Receive journey scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.
Once scheduled, SyntraFlow executes the selected Procure-to-Receive journey scenarios unattended and records the outcome of each stage hand-off and business assertion.
| Pack | SCM End-to-End Procure-to-Receive Regression Pack |
| Schedule | Quarterly Update Regression |
| Tests | 12 scenarios |
| Execution | Batch Mode |
| Start | 10:00 PM |
| Environment | Oracle Fusion TEST |
| Status | Scheduled |
Illustrative example — not a live schedule.
Review Results Across the Entire Test Pack
Users can drill from the regression pack into a journey scenario, its business steps, the underlying automation actions across each Procurement family page, and the evidence captured for each.
Illustrative example data — not actual production metrics.
Regression Pack → Scenario → Business Step → Automation Action → Evidence
Security & Approval Variations
Access to each stage of the Procure-to-Receive journey — creating a requisition, approving a purchase order, or receiving goods — is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that access behaves as expected at each stage — not to assert a single universal Oracle security model.
| Persona | Action | Expected | Syntra Result |
|---|---|---|---|
| Procurement Buyer | Execute Full Procure-to-Receive Journey | Allowed | PASS |
| Receiving Clerk | Receive Against Approved Purchase Order | Allowed | PASS |
| Unauthorized User | Attempts to Receive Without Role | Access prevented | PASS |
Understand Why a Test Failed
SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.
From Business Scenario to Execution Evidence
Business teams get readable test documentation; automation teams retain detailed execution traceability.
Meet Jarvis — SyntraFlow's AI Testing Engine
Jarvis extends the Syntra Standard Test Library by analysing the Procure-to-Receive journey, available DataVault test data and expected business outcomes to generate additional Positive, Negative and Security coverage for the customer's environment, following the SCM → Functional Area → Process/Scenario Family → Standard Test Scenarios → DataVault Test Data → Jarvis Variations → Regression Pack → Scheduled Execution → Failure Intelligence pipeline. These variations do not create additional public SEO pages, and this page itself does not duplicate the individual scenario coverage already tested on the Procurement family pages it links to and orchestrates.
How SyntraFlow Automates This Test
The Standard Test defines the scenario; DataVault, Jarvis AI and SyntraFlow's execution engine take it from a single reusable business definition to executed, evidenced regression coverage.
Business Step → Underlying UI Actions
What SyntraFlow Captures Per Run
Action Status vs. Business Validation
A successful UI interaction at any single stage does not automatically prove the end-to-end journey is correct — this is illustrative of how SyntraFlow separates action success from cross-stage business validation; it does not reflect a specific live execution. When a hand-off fails, SyntraFlow's evidence trail is designed to help a tester classify the likely cause — for example DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: Receipt Failed to Match Purchase Order — Likely category: DATA_ERROR — Evidence: Receipt quantity for ${ITEM} exceeds purchase order ${PURCHASE_ORDER} tolerance — Recommendation: Verify receipt quantity against PO before submitting. A failure should never be labeled as an Oracle defect without first eliminating data, configuration, security, automation and integration causes.
| Step | Action Status | Business Validation |
|---|---|---|
| Receive Against the Purchase Order | Pass | — |
| Verify Quantity and Pricing Consistency Across Stages | Pass | Pass |
| Verify Audit Trail Links Requisition, Purchase Order and Receipt | Pass | Pass |
Related End-to-End Tests
Procure-to-Receive is one stage of the broader Procure-to-Pay journey, and links directly to the individual Procurement family pages it orchestrates.
Turn This Standard Journey into Your Oracle SCM Procure-to-Receive Regression Suite
Start with the Syntra Standard Procure-to-Receive journey, use DataVault to provide environment-specific test data, let Jarvis generate additional supplier, organization and security variations, and execute the resulting regression pack automatically with SyntraFlow.
Use This Oracle Fusion Test Case
Download Test Case
Excel, CSV or JSON export.
Coming soonAutomate with SyntraFlow
Run this script against your own tenant today.