Oracle ERP Testing Tool > Test Library > SCM > End-to-End SCM

Syntra Standard Journey Oracle Test Library

Oracle Fusion Procure-to-Pay Test Scenarios

Validate the complete Oracle Fusion Procure-to-Pay journey — requisition, approval, purchase order, PO approval, receipt, AP invoice, three-way match validation, supplier payment and accounting — with emphasis on cross-stage data continuity and matching integrity. This flagship end-to-end test orchestrates and links to the individually tested SCM Procurement and Financials AP family pages rather than duplicating their atomic, field-level coverage.

Test ID	ORCL.E2E.P2P
Application	Oracle Fusion Cloud
Product	SCM
Module	End-to-End SCM
Process	Procure-to-Pay
Business Flow	Procure-to-Pay
Scenario Type	End-to-End / Cross-Module
Test Usage	Functional Testing / Regression Testing / UAT
Priority	High
Automation	SyntraFlow Ready
Library	Syntra Standard Journey

Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions across every linked stage automatically while presenting the journey as business-readable test steps for documentation, review and reporting. This scenario is presented as 9 business-readable test steps; SyntraFlow's automation executes approximately 210 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to validate the complete Oracle Fusion Procure-to-Pay journey — requisition, approval, purchase order, PO approval, receipt, AP invoice, three-way match validation, supplier payment and accounting — with emphasis on cross-stage data continuity and matching integrity across all nine stages, not on re-testing each stage's own atomic, field-level validation. This page is an orchestration and journey test: it does not duplicate the scenario coverage already tested individually on the linked Create Purchase Requisition, Approve Requisition, Create Purchase Order, Approve Purchase Order, Receive Purchase Order, Create PO-Matched Invoice, Invoice Validation, Invoice Holds, Invoice Approval, Create Payment, Payment Accounting, Void Payment, Supplier Bank Account and Supplier Inactivation pages. Instead, it links to those live pages and adds scenarios that specifically test the hand-offs, quantity and amount continuity, and matching integrity between them.

The scenario should confirm that:

requisition, purchase order, receipt, invoice, payment and accounting data correctly carry forward from one stage to the next
the three-way match correctly compares purchase order, receipt and invoice quantity and price
variance within configured tolerance correctly allows the invoice to proceed, and variance beyond tolerance correctly places the invoice on hold
payment amount correctly equals the eligible invoice balance, and accounting entries correctly reflect the full transaction chain
document linkage — requisition, purchase order, receipt, invoice and payment — is correctly preserved end to end
Oracle correctly enforces validation when data errors, configuration errors, security restrictions or closed periods are introduced at any stage of the journey (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION)

This scenario orchestrates and links to the individually tested Procurement and Financials AP family pages listed on this page; it does not re-test each stage's own field-level validation, which remains covered on those pages. It covers the standard Procure-to-Pay journey in Oracle Fusion Cloud SCM and Financials TEST/UAT environments and does not cover non-PO invoices, which are covered by separate Accounts Payable scenarios outside this journey.

When to Use This Test

Flagship cross-module regression test validating cross-module continuity across the complete SCM Procurement to Financials AP journey for a new Oracle Fusion implementation — it does not duplicate the atomic scenario coverage already tested on the 14 linked family pages
Regression testing of hand-offs between Create Purchase Requisition, Approve Requisition, Create Purchase Order, Approve Purchase Order, Receive Purchase Order, Create PO-Matched Invoice, Invoice Validation, Invoice Holds, Invoice Approval, Create Payment, Payment Accounting and Void Payment after an Oracle quarterly update
UAT sign-off across procurement buyers, approvers and AP specialists who each own a different stage of the same purchase-to-pay transaction
Validating three-way match integrity and quantity/amount continuity across requisition, purchase order, receipt, invoice and payment
Diagnosing DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR and INTEGRATION_ERROR conditions surfaced at a stage hand-off before escalating as a possible APPLICATION_ERROR

The Procure-to-Pay Journey

Create Requisition

→

Submit / Approve

→

Create Purchase Order

→

Approve PO

→

Receive

→

Create AP Invoice

→

Validate / Match

→

Pay Supplier

→

Create Accounting

Procure-to-Pay is SyntraFlow's flagship end-to-end SCM–Financials journey, spanning nine stages from requisition through accounting. It does not duplicate the atomic scenario coverage already tested individually on the 14 linked family pages below. Instead, it focuses on the hand-offs and cross-stage data continuity between them — quantity and amount continuity, document linkage, three-way match integrity and accounting continuity. Exact configuration — two-way vs three-way match, approval routing, match tolerances and payment methods — depends on customer-specific Oracle Fusion setup.

Preconditions

A supplier ${SUPPLIER} and supplier site ${SUPPLIER_SITE} are active and enabled for procurement and payment in the target Oracle Fusion environment.
Procurement and Financials AP are configured for either two-way or three-way match, with match tolerances defined according to customer policy.
The test user or users hold appropriate access to progress a transaction through requisitioning, purchasing, receiving, invoicing, payment and accounting stages.
Budgetary controls, tax setup, payment methods and an open ${ACCOUNTING_PERIOD} relevant to the journey are configured in the target environment.
This scenario assumes each linked family page's own preconditions are separately satisfied — it does not re-verify field-level setup already covered on those pages.

Exact configuration — including whether match is two-way or three-way, approval hierarchies, match tolerances, payment methods and period status — depends on customer-specific Oracle Fusion setup and is never assumed to be universal across implementations.

Sample Test Data

Requisition	${REQUISITION}
Purchase Order	${PURCHASE_ORDER}
Supplier	${SUPPLIER}
Supplier Site	${SUPPLIER_SITE}
Item	${ITEM}
Quantity	${QUANTITY}
Receipt	${RECEIPT}
Invoice	${INVOICE}
Payment	${PAYMENT}
Accounting Period	${ACCOUNTING_PERIOD}

Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion SCM and Financials TEST/UAT environment. Not every field applies to every journey variation — for example, ${RECEIPT} does not apply where a purchase order is configured for two-way match.

Test Steps

9 business-readable steps. SyntraFlow's automation executes ~210 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.

#	User Action	Expected Result
1	Create and Approve the Requisition Create a purchase requisition ${REQUISITION} for ${ITEM} and route it through requisition approval, using the linked Create Purchase Requisition and Approve Requisition scenarios. ${REQUISITION} / ${ITEM} This step orchestrates the Create Purchase Requisition and Approve Requisition family pages rather than repeating their individual field-level test coverage.	The requisition is created and correctly approved, carrying supplier, line and quantity ${QUANTITY} detail forward.
2	Create and Approve the Purchase Order Convert the approved requisition ${REQUISITION} into purchase order ${PURCHASE_ORDER} against ${SUPPLIER} / ${SUPPLIER_SITE}, and route it through PO approval, using the linked Create Purchase Order and Approve Purchase Order scenarios. ${PURCHASE_ORDER} / ${SUPPLIER}	The purchase order is created and correctly approved, carrying requisition, supplier, line and price detail forward without discrepancy.
3	Receive Against the Purchase Order Record receipt ${RECEIPT} of goods or services against the approved purchase order ${PURCHASE_ORDER}, using the linked Receive Purchase Order scenario, where the purchase order is configured for three-way match. ${RECEIPT}	The receipt correctly references the purchase order and carries forward matching quantity and unit-of-measure detail.
4	Create the AP Invoice Referencing the Receipt Create a supplier invoice ${INVOICE} matched to purchase order ${PURCHASE_ORDER} and, where applicable, receipt ${RECEIPT}, using the linked Create PO-Matched Invoice scenario. ${INVOICE}	The invoice is created referencing the correct purchase order and receipt, with quantities and prices carried forward for matching.
5	Validate and Match the Invoice (Three-Way Match) Submit the invoice for validation, allowing Oracle to perform the two-way or three-way match between purchase order, receipt and invoice, using the linked Invoice Validation scenario.	Invoices within tolerance pass validation and move toward approval; invoices outside tolerance are correctly placed on hold.
6	Resolve Any Match Holds Where a match hold is applied, review the hold reason using the linked Invoice Holds scenario and resolve it before resubmitting the invoice for validation and approval via the linked Invoice Approval scenario.	The hold is correctly resolved where the underlying variance is corrected, and the invoice correctly proceeds to approval.
7	Submit and Process Supplier Payment Select the approved, matched invoice ${INVOICE} and submit payment ${PAYMENT} to ${SUPPLIER}, using the linked Create Payment scenario, validating the supplier bank account is active and the supplier site is open. ${PAYMENT}	Payment is created for the correct invoice amount and correctly reduces the open invoice balance.
8	Create Payment Accounting Create accounting for the invoice and payment ${PAYMENT} in the current ${ACCOUNTING_PERIOD}, using the linked Payment Accounting scenario. ${ACCOUNTING_PERIOD}	Accounting entries are correctly created, reflecting the invoice liability and its relief through payment.
9	Verify the Full Audit Trail Links Every Document TogetherBusiness assertion Trace the completed transaction from requisition through purchase order, receipt, invoice, payment and accounting to confirm the audit trail links every document together. This is the primary business assertion for the scenario — a fully linked, correctly matched and correctly accounted audit trail across every stage is the expected pass condition, not merely a successful payment.	The audit trail correctly links requisition ${REQUISITION}, purchase order ${PURCHASE_ORDER}, receipt ${RECEIPT}, invoice ${INVOICE} and payment ${PAYMENT} end-to-end, with accounting correctly reflecting the full chain.

Expected Results

The requisition, purchase order, receipt, invoice, payment and accounting are correctly linked end-to-end.
The three-way match correctly compares purchase order, receipt and invoice quantity and price.
Invoices within configured tolerance proceed to approval without a hold.
Invoices outside configured tolerance are correctly placed on hold pending resolution.
Payment amount correctly equals the eligible invoice balance.
Accounting entries correctly reflect the full transaction chain, and unauthorized actions at any stage of the journey are correctly blocked.

Key Validation Checkpoints

Requisition data correctly carries forward into the PO.
PO data correctly carries forward into receipt.
Receipt data correctly carries forward into the matched invoice.
Three-way match correctly compares PO/receipt/invoice quantity and price.
Variance within tolerance correctly proceeds, variance beyond tolerance correctly holds.
Payment amount correctly equals the eligible invoice balance.
Accounting entries correctly reflect the full transaction chain.
Document linkage (requisition/PO/receipt/invoice/payment) correctly preserved end to end.

Core Business Scenario

Procure-to-Pay

Journey Stages

9 Stages

Test Variations

45 Journey Scenarios

Linked Family Pages

14 Linked Pages

Test Data

DataVault-Driven

Execution

On-Demand / Scheduled / Batch

Jarvis AI

Go Beyond the Standard Test with Jarvis AI

The Syntra Standard Test Library defines the core Procure-to-Pay business journey as an orchestration across SCM and Financials AP. Jarvis AI extends this journey 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, Boundary, Approval, Integration 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 build a separate test for every requisition, purchase order, receipt, invoice, payment and accounting combination, or for every match-tolerance edge case. Jarvis uses the standard journey as the foundation and generates relevant Positive, Negative, Boundary, Approval, Integration and Security variations for the customer's environment — including two-way vs three-way match paths, partial receipts and invoices, and matching-exception holds. These Jarvis-generated variations do not create additional public SEO pages, and this page itself does not duplicate the individual family pages it links to — it remains the canonical reference for the end-to-end journey.

From Standard Test to Executed Regression Pack

SCM

Oracle Fusion SCM product area, orchestrated end-to-end with Financials.

Functional Area — End-to-End SCM

Cross-module End-to-End SCM functional area spanning Procurement and Financials AP.

Process / Scenario Family — Procure-to-Pay

The Procure-to-Pay end-to-end business flow orchestrating the linked family pages.

Standard Test Scenario — Procure-to-Pay Journey

Reusable nine-stage Procure-to-Pay business process and cross-stage hand-off logic.

Customer DataVault

Provides approved customer-specific test data — Requisitions, Purchase Orders, Receipts, Invoices, Payments, Suppliers and Accounting Periods.

Jarvis Variations

Analyses the standard journey together with available test data and generates Positive, Negative, Boundary, Approval, Integration and Security variations. These variations do not create additional public test-library pages.

Regression Pack

Selected journey variations can be grouped into an executable suite.

Scheduled Execution

Execute immediately or schedule the regression pack for unattended batch execution.

Failure Intelligence

Capture execution results, business assertions, screenshots/evidence and exceptions, classified into likely failure categories.

Rather than maintaining a separate test page for every requisition, purchase order, receipt, invoice, payment, accounting or match-tolerance combination, SyntraFlow maintains one core Procure-to-Pay journey scenario — with 45 example scenarios documented below — and allows Jarvis AI to generate matching, timing, approval and security-specific 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-Pay 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.

Positive Scenarios

Complete the standard requisition-to-payment happy path with a clean three-way match
Complete catalog and non-catalog procurement journeys where each is supported
Complete single-line, multi-line and multi-supplier requisition-to-payment journeys
Complete journeys through single-level and multi-level requisition and purchase order approval routing
Complete journeys through purchase order creation and pre-receipt change management
Complete journeys with full receipt, partial receipt and multiple partial receipts
Complete journeys validating three-way match on quantity and price within tolerance
Complete journeys through full, partial and electronic supplier payment

Negative Scenarios

Quantity variance beyond tolerance correctly places the invoice on a mismatch hold
Price variance beyond tolerance correctly places the invoice on a mismatch hold
Payment against an invalid or unverified supplier bank account is correctly blocked
New activity against an inactive supplier or closed supplier site after PO creation is correctly blocked
Accounting creation in a closed accounting period is correctly blocked
Payment attempted against a held or unapproved invoice is correctly blocked

These are representative examples only. Negative-scenario behavior and available match 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 requisition, purchase order, receipt, invoice, payment, supplier and accounting-period combination in a real Oracle Fusion Procure-to-Pay environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Procure-to-Pay journey scenarios relevant to the customer's actual implementation.

Standard Library Definition

Requisition        ${REQUISITION}
Purchase Order      ${PURCHASE_ORDER}
Supplier            ${SUPPLIER}
Supplier Site       ${SUPPLIER_SITE}
Item                ${ITEM}
Quantity            ${QUANTITY}
Receipt             ${RECEIPT}
Invoice             ${INVOICE}
Payment             ${PAYMENT}
Accounting Period   ${ACCOUNTING_PERIOD}

DataVault

Requisitions
  Active requisitions available for conversion to purchase orders
Purchase Orders
  Approved purchase orders by match type (two-way / three-way)
Receipts
  Full and partial receipts by purchase order
Invoices
  PO-matched invoices, prepayments and credit memos
Payments
  Payment methods and disbursement bank accounts by supplier
Suppliers
  Active suppliers and sites enabled for procurement and payment
Accounting Periods
  Open and closed periods by ledger
Security
  Roles authorised at each stage of the journey

Jarvis AI Generates

Scenario 001 — Standard Requisition-to-Payment Happy Path, ${SUPPLIER}
Scenario 016 — Full Receipt Against ${PURCHASE_ORDER}
Scenario 026 — Quantity Mismatch Hold, ${INVOICE} vs ${RECEIPT}
Scenario 038 — Invalid Supplier Bank Account, ${SUPPLIER_SITE}
Scenario 042 — AP Accounting Validation, ${ACCOUNTING_PERIOD}
...

Requisition, purchase order, receipt, invoice, payment and accounting data used in Procure-to-Pay testing is 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 journey 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 45 end-to-end Procure-to-Pay journey scenarios spanning requisition-to-payment continuity, three-way match integrity, approval routing, and negative/boundary 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-P2P-001	Standard Requisition-to-Payment Happy Path	Positive	Complete the full nine-stage journey from requisition ${REQUISITION} through purchase order ${PURCHASE_ORDER}, receipt ${RECEIPT}, invoice ${INVOICE}, payment ${PAYMENT} and accounting for ${SUPPLIER}, with every stage passing cleanly.	SyntraFlow Ready
E2E-P2P-002	Catalog Item Procurement	Positive	Create requisition ${REQUISITION} for catalog item ${ITEM} and carry the catalog price and description through to purchase order ${PURCHASE_ORDER} and invoice ${INVOICE} without manual re-entry.	SyntraFlow Ready
E2E-P2P-003	Non-Catalog Procurement Where Supported	Positive	Create a non-catalog requisition ${REQUISITION} for item ${ITEM} where the environment supports non-catalog procurement, confirming the manually entered description and price correctly carry into purchase order ${PURCHASE_ORDER}.	SyntraFlow Ready
E2E-P2P-004	Single-Line Requisition to Payment	Positive	Progress a single-line requisition ${REQUISITION} for ${ITEM} through purchase order ${PURCHASE_ORDER}, receipt ${RECEIPT} and invoice ${INVOICE} to payment ${PAYMENT}, confirming the single line's quantity and amount remain consistent end-to-end.	SyntraFlow Ready
E2E-P2P-005	Multi-Line Requisition to Payment	Positive	Progress a multi-line requisition ${REQUISITION} through purchase order ${PURCHASE_ORDER}, receipt ${RECEIPT} and invoice ${INVOICE}, confirming each line's quantity ${QUANTITY} and amount independently carries forward and matches correctly.	SyntraFlow Ready
E2E-P2P-006	Multi-Supplier Procurement	Positive	Split a multi-line requisition ${REQUISITION} into separate purchase orders for different suppliers, confirming each resulting purchase order, receipt and invoice correctly references its own supplier and site.	SyntraFlow Ready
E2E-P2P-007	Different Requisitioning and Procurement BU Where Supported	Positive	Create requisition ${REQUISITION} in one requisitioning business unit and convert it to purchase order ${PURCHASE_ORDER} in a different procurement business unit where cross-BU procurement is configured, confirming the business-unit hand-off carries the correct accounting context forward.	SyntraFlow Ready
E2E-P2P-008	Requisition Approval Required	Positive/Approval	Submit requisition ${REQUISITION} for approval and confirm it correctly routes to and through the configured approval hierarchy before purchase order ${PURCHASE_ORDER} can be created.	SyntraFlow Ready
E2E-P2P-009	Multi-Level Requisition Approval	Positive/Approval	Submit requisition ${REQUISITION} through a multi-level approval hierarchy and confirm each approval level's action is correctly recorded before the requisition becomes eligible for purchase order ${PURCHASE_ORDER} creation.	SyntraFlow Ready
E2E-P2P-010	Requisition Rejected and Resubmitted	Positive/Approval	Reject requisition ${REQUISITION} at approval, correct it, and resubmit it, confirming the corrected requisition — not the rejected version — is the one that carries forward to purchase order ${PURCHASE_ORDER}.	SyntraFlow Ready
E2E-P2P-011	PO Created from Approved Requisition	Positive	Convert approved requisition ${REQUISITION} into purchase order ${PURCHASE_ORDER}, confirming supplier, line, quantity ${QUANTITY} and price detail carry forward without discrepancy.	SyntraFlow Ready
E2E-P2P-012	Manual PO to Payment	Positive	Create purchase order ${PURCHASE_ORDER} directly without a source requisition and progress it through receipt ${RECEIPT}, invoice ${INVOICE} and payment ${PAYMENT}, confirming the journey completes correctly without an upstream requisition document.	SyntraFlow Ready
E2E-P2P-013	PO Approval Required	Positive/Approval	Submit purchase order ${PURCHASE_ORDER} for approval and confirm it correctly routes to and through the configured approval hierarchy before it becomes eligible for receipt ${RECEIPT}.	SyntraFlow Ready
E2E-P2P-014	PO Rejected and Revised	Positive/Approval	Reject purchase order ${PURCHASE_ORDER} at approval, revise it, and resubmit it, confirming the revised version — not the rejected version — is the one that carries forward to receipt ${RECEIPT} and invoice ${INVOICE}.	SyntraFlow Ready
E2E-P2P-015	PO Change Before Receipt	Positive	Change the quantity or price on approved purchase order ${PURCHASE_ORDER} before receipt ${RECEIPT} is recorded, confirming the revised purchase order values — not the original — are matched at receipt and invoice.	SyntraFlow Ready
E2E-P2P-016	Full Receipt	Positive	Record a full receipt ${RECEIPT} against purchase order ${PURCHASE_ORDER} matching the full ordered quantity ${QUANTITY}, confirming the received quantity correctly carries forward for invoice ${INVOICE} matching.	SyntraFlow Ready
E2E-P2P-017	Partial Receipt	Positive	Record a partial receipt ${RECEIPT} against purchase order ${PURCHASE_ORDER} for less than the full ordered quantity ${QUANTITY}, confirming only the received quantity — not the full ordered quantity — is available for invoice ${INVOICE} matching.	SyntraFlow Ready
E2E-P2P-018	Multiple Partial Receipts	Positive	Record multiple partial receipts against purchase order ${PURCHASE_ORDER} over time, confirming the cumulative received quantity correctly reconciles against ${QUANTITY} before invoice ${INVOICE} matching.	SyntraFlow Ready
E2E-P2P-019	Receipt Correction	Positive	Correct a previously recorded receipt ${RECEIPT} against purchase order ${PURCHASE_ORDER}, confirming the corrected quantity — not the original erroneous quantity — is the one available for invoice ${INVOICE} matching.	SyntraFlow Ready
E2E-P2P-020	Return to Supplier Before Invoicing	Positive	Return part of receipt ${RECEIPT} to ${SUPPLIER} before invoice ${INVOICE} is created, confirming the reduced net-received quantity correctly carries forward for invoice matching.	SyntraFlow Ready
E2E-P2P-021	Over-Receipt Validation	Positive/Boundary	Attempt to receive a quantity exceeding purchase order ${PURCHASE_ORDER}'s ordered quantity ${QUANTITY} at the boundary of the configured over-receipt tolerance, confirming Oracle correctly enforces the tolerance boundary at receipt ${RECEIPT}.	SyntraFlow Ready
E2E-P2P-022	PO-Matched Invoice	Positive	Create invoice ${INVOICE} matched to purchase order ${PURCHASE_ORDER}, confirming purchase order price and quantity correctly carry forward into the invoice match.	SyntraFlow Ready
E2E-P2P-023	Receipt-Matched Invoice Where Applicable	Positive	Create invoice ${INVOICE} matched to receipt ${RECEIPT} where the purchase order is configured for receipt-based matching, confirming received quantity — not ordered quantity — is the basis for the match.	SyntraFlow Ready
E2E-P2P-024	Invoice Quantity Match	Positive	Create invoice ${INVOICE} with quantity equal to receipt ${RECEIPT} quantity, confirming the three-way match correctly compares and passes on the quantity dimension.	SyntraFlow Ready
E2E-P2P-025	Invoice Price Match	Positive	Create invoice ${INVOICE} with unit price equal to purchase order ${PURCHASE_ORDER} price, confirming the three-way match correctly compares and passes on the price dimension.	SyntraFlow Ready
E2E-P2P-026	Quantity Mismatch Hold	Negative/Boundary	Create invoice ${INVOICE} with a quantity that does not match receipt ${RECEIPT} quantity, confirming Oracle correctly places the invoice on a quantity-mismatch hold rather than allowing it to validate.	SyntraFlow Ready
E2E-P2P-027	Price Mismatch Hold	Negative/Boundary	Create invoice ${INVOICE} with a unit price that does not match purchase order ${PURCHASE_ORDER} price beyond tolerance, confirming Oracle correctly places the invoice on a price-mismatch hold rather than allowing it to validate.	SyntraFlow Ready
E2E-P2P-028	Resolve Invoice Hold	Positive	Correct the quantity or price on a held invoice ${INVOICE} to align with purchase order ${PURCHASE_ORDER} and receipt ${RECEIPT}, confirming the hold correctly releases and the invoice proceeds to validation.	SyntraFlow Ready
E2E-P2P-029	Partial Invoice	Positive	Create invoice ${INVOICE} for only part of purchase order ${PURCHASE_ORDER}'s matched quantity, confirming the remaining unbilled quantity correctly remains available for a subsequent invoice.	SyntraFlow Ready
E2E-P2P-030	Multiple Invoices Against PO	Positive	Create multiple invoices against the same purchase order ${PURCHASE_ORDER} across separate receipts, confirming the cumulative invoiced quantity and amount correctly reconcile against the purchase order without over-billing.	SyntraFlow Ready
E2E-P2P-031	Full Supplier Payment	Positive	Submit payment ${PAYMENT} for the full balance of approved invoice ${INVOICE}, confirming the payment amount correctly equals the invoice's open balance and the invoice status updates to paid.	SyntraFlow Ready
E2E-P2P-032	Partial Supplier Payment	Positive	Submit a partial payment ${PAYMENT} against approved invoice ${INVOICE}, confirming the remaining open balance correctly reflects the partial amount paid.	SyntraFlow Ready
E2E-P2P-033	Payment Process Request	Positive	Select approved invoice ${INVOICE} for ${SUPPLIER} within a payment process request, confirming the invoice is correctly grouped and selected for batch payment ${PAYMENT}.	SyntraFlow Ready
E2E-P2P-034	Electronic Payment	Positive	Submit payment ${PAYMENT} to ${SUPPLIER} using an electronic payment method against the disbursement bank account on file, confirming the electronic payment correctly transmits and the invoice balance updates.	SyntraFlow Ready
E2E-P2P-035	Payment Hold	Negative	Attempt to submit payment ${PAYMENT} for an invoice ${INVOICE} that is not yet approved or is on hold, confirming Oracle correctly prevents payment until the hold is resolved.	SyntraFlow Ready
E2E-P2P-036	Release Payment Hold	Positive	Resolve the condition that placed a payment hold on invoice ${INVOICE}, confirming the hold correctly releases and payment ${PAYMENT} can then be submitted.	SyntraFlow Ready
E2E-P2P-037	Void Payment and Repay	Positive	Void a previously issued payment ${PAYMENT} against invoice ${INVOICE}, confirming the invoice balance correctly reopens and a replacement payment can then be correctly issued.	SyntraFlow Ready
E2E-P2P-038	Invalid Supplier Bank Account	Negative	Attempt to submit an electronic payment ${PAYMENT} against an invalid or unverified bank account for ${SUPPLIER} / ${SUPPLIER_SITE}, confirming Oracle correctly blocks the payment rather than transmitting it.	SyntraFlow Ready
E2E-P2P-039	Inactive Supplier After PO Creation	Negative	Inactivate ${SUPPLIER} after purchase order ${PURCHASE_ORDER} is created, confirming Oracle correctly blocks or restricts new receipt ${RECEIPT} or invoice ${INVOICE} activity against the inactive supplier.	SyntraFlow Ready
E2E-P2P-040	Closed Supplier Site	Negative	Attempt to invoice or pay against a closed ${SUPPLIER_SITE} for an otherwise open purchase order ${PURCHASE_ORDER}, confirming Oracle correctly blocks activity at the closed site.	SyntraFlow Ready
E2E-P2P-041	Closed Accounting Period	Negative	Attempt to create accounting for invoice ${INVOICE} or payment ${PAYMENT} in a closed ${ACCOUNTING_PERIOD}, confirming Oracle correctly blocks accounting creation in the closed period.	SyntraFlow Ready
E2E-P2P-042	AP Accounting Validation	Positive/Integration	Create accounting for approved, matched invoice ${INVOICE} in ${ACCOUNTING_PERIOD}, confirming the resulting journal entries correctly reflect the invoice amount and the correct accounts.	SyntraFlow Ready
E2E-P2P-043	Payment Accounting Validation	Positive/Integration	Create accounting for payment ${PAYMENT} in ${ACCOUNTING_PERIOD}, confirming the resulting journal entries correctly reflect the payment amount and correctly relieve the accounts payable liability recorded at invoice.	SyntraFlow Ready
E2E-P2P-044	End-to-End Document Traceability	Positive/Integration	Trace the completed journey from requisition ${REQUISITION} through purchase order ${PURCHASE_ORDER}, receipt ${RECEIPT}, invoice ${INVOICE} and payment ${PAYMENT}, confirming every document correctly cross-references its upstream and downstream neighbors.	SyntraFlow Ready
E2E-P2P-045	End-to-End Amount Reconciliation	Positive/Integration	Reconcile the amount recorded at requisition ${REQUISITION}, purchase order ${PURCHASE_ORDER}, invoice ${INVOICE}, payment ${PAYMENT} and accounting in ${ACCOUNTING_PERIOD}, confirming the amount correctly ties out across every stage of the journey.	SyntraFlow Ready

Positive and Negative Journey Testing

Positive Testing

Jarvis generates journey scenarios using requisition, purchase order, receipt, invoice, payment and accounting combinations expected to successfully complete the Procure-to-Pay journey end-to-end in Oracle Fusion.

Approved ${PURCHASE_ORDER} + Matching ${RECEIPT} + ${INVOICE} Within Tolerance → Journey Completes to Payment and Accounting

Negative Testing

Jarvis can also generate journey scenarios designed to exercise Oracle's validations around matching, supplier status, site status, banking and period controls across the journey.

Quantity Mismatch Beyond Tolerance → Invoice Held
Price Mismatch Beyond Tolerance → Invoice Held
Invalid Supplier Bank Account → Payment Blocked
Inactive Supplier After PO Creation → New Activity Blocked
Closed Supplier Site → Activity Blocked
Closed Accounting Period → Accounting Creation Blocked

A negative end-to-end scenario passes when Oracle correctly enforces the expected data, configuration, matching 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 hold 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-Pay journey scenarios and group them into reusable execution packs.

SCM End-to-End Procure-to-Pay Regression Pack

Standard Requisition-to-Payment Happy Path
Catalog Item Procurement
Requisition Approval Required
PO Approval Required
Full Receipt
Partial Receipt
PO-Matched Invoice
Quantity Mismatch Hold
Resolve Invoice Hold
Full Supplier Payment
Invalid Supplier Bank Account
AP Accounting Validation
End-to-End Document Traceability

Add Selected to Regression Pack(coming soon)Run Now(coming soon)Schedule(coming soon)

Run On-Demand or Schedule Automated Batch Execution

SyntraFlow can execute selected Procure-to-Pay 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-Pay journey scenarios unattended across SCM and Financials AP, and records the outcome of each stage hand-off and business assertion.

Run immediatelyNightly regressionWeekly regressionBefore releaseAfter configuration changesAfter environment refreshQuarterly Oracle update testingPre-UAT validation

Pack	SCM End-to-End Procure-to-Pay Regression Pack
Schedule	Weekly End-to-End Regression
Tests	45 scenarios
Execution	Batch Mode
Start	11: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, and the evidence captured at each stage hand-off.

Illustrative example data — not actual production metrics.

Total Scenarios

Passed

Failed

Exceptions

Positive Tests

Negative Tests

Business Assertions

Regression Pack → Scenario → Business Step → Automation Action → Evidence

DataVault Journey Persona

Rather than generating an independent random value for each stage, Jarvis preserves one linked set of persona values — supplier, item, quantities, documents and payment detail — across every stage of the journey, so the requisition, purchase order, receipt, invoice and payment in a given test run all describe the same underlying transaction.

Persona: Standard Domestic Supplier Journey

Supplier	${SUPPLIER}
Supplier Site	${SUPPLIER_SITE}
Item	${ITEM}
Category	${CATEGORY}
Requisition BU	${REQUISITIONING_BU}
Procurement BU	${PROCUREMENT_BU}
Receiving Organization	${RECEIVING_ORG}
Quantity	${QUANTITY}
UOM	${UOM}
Unit Price	${UNIT_PRICE}
Currency	${CURRENCY}
PO	${PURCHASE_ORDER}
Receipt	${RECEIPT}
Invoice	${INVOICE}
Payment Method	${PAYMENT_METHOD}
Disbursement Bank Account	${DISBURSEMENT_BANK_ACCOUNT}
Accounting Period	${ACCOUNTING_PERIOD}

Linked persona data matters because a realistic Procure-to-Pay test must prove that the same supplier, item and quantity carry correctly across every stage — a set of unrelated random values per stage would never expose a genuine cross-stage continuity or matching defect.

Security & Approval Variations

Access to each stage of the Procure-to-Pay journey — requisitioning, purchasing, receiving, invoicing, payment and accounting — 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 Requisition Through Receipt Stages	Allowed	PASS
AP Specialist	Process Invoice Through Payment Stages	Allowed	PASS
Unauthorized User	Attempts to Approve Payment Without Role	Access prevented	PASS

Cross-Stage Business Assertions

These assertions validate that data continuity is preserved as a transaction moves from one journey stage to the next — they do not re-test each stage's own field-level validation, which remains covered on the linked family pages.

QUANTITY_CONTINUITYAMOUNT_CONTINUITYDOCUMENT_LINKAGESTATUS_CONTINUITYACCOUNTING_CONTINUITY

Stage Transition	Assertion	Example	Status
Requisition -> PO	Requisition Qty = PO Qty (where not consolidated)	Requisition qty ${REQ_QTY} = PO qty ${PO_QTY}	PASS
PO -> Receipt	Received Qty <= PO Qty / configured tolerance	Receipt qty ${RECEIPT_QTY} within tolerance of PO qty ${PO_QTY}	PASS
Receipt -> Invoice	Invoice Qty / Amount matches PO / Receipt expectation	Invoice qty ${INVOICE_QTY} matches receipt qty ${RECEIPT_QTY}	PASS
Invoice -> Payment	Payment Amount = Eligible Invoice Balance	Payment amount ${PAYMENT_AMOUNT} = invoice balance ${INVOICE_AMOUNT}	PASS
Requisition -> Payment	Document linkage preserved end to end	Requisition ${REQUISITION}, PO ${PURCHASE_ORDER}, Receipt ${RECEIPT}, Invoice ${INVOICE}, Payment ${PAYMENT} all cross-referenced	PASS

Illustrative example using DataVault variables — not hard-coded production values.

Stage-by-Stage Execution Evidence

This shows a worked example of a Procure-to-Pay journey run in which one stage fails, and how upstream and downstream stages are reported around it.

1Requisition

PASS

2Requisition Approval

PASS

3Purchase Order

PASS

4PO Approval

PASS

5Receipt

PASS

6Invoice

FAIL

7Payment

NOT RUN

8Accounting

NOT RUN

Failed Stage

Invoice

Upstream Passed

Downstream Blocked

Illustrative example run — not a live execution.

Journey Failure Model

SyntraFlow is designed to surface a failure at the journey level — showing what passed upstream and what is blocked downstream — rather than reporting only an isolated stage failure.

Journey: Procure-to-Pay Failed Stage: Invoice Validation

Upstream Status

Requisition	PASS
PO	PASS
Receipt	PASS

Scenario

Quantity Mismatch Hold

Expected Result

Invoice validates cleanly against the matched purchase order and receipt.

Actual Result

Invoice quantity 105 does not match received quantity 100.

Failure Classification

DATA_ERROR

Blocking Impact / Downstream Status

Payment not executed; accounting not created.

Recommended Action

Correct invoice quantity to match the receipt, or process a receipt correction before resubmitting.

Do not label as an Oracle application defect without eliminating data, configuration, security, automation, environment and integration causes first.

Additional Named Regression Packs

This journey can be executed as one pack or split into focused packs covering specific behavior.

P2P Standard Pack

Standard Requisition-to-Payment Happy Path
Catalog Item Procurement
PO Created from Approved Requisition
Full Receipt
PO-Matched Invoice
Full Supplier Payment
AP Accounting Validation

P2P Negative Pack

Quantity Mismatch Hold
Price Mismatch Hold
Invalid Supplier Bank Account
Inactive Supplier After PO Creation
Closed Accounting Period

P2P Approval Pack

Requisition Approval Required
Multi-Level Requisition Approval
Requisition Rejected and Resubmitted
PO Approval Required
PO Rejected and Revised

P2P Matching Pack

Invoice Quantity Match
Invoice Price Match
Quantity Mismatch Hold
Price Mismatch Hold
Resolve Invoice Hold
Receipt-Matched Invoice Where Applicable

Understand Why a Test Failed

SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.

DataConfigurationSecurityAutomationApplicationEnvironmentExpected Validation

Jarvis Failure Intelligence — Coming Soon

From Business Scenario to Execution Evidence

Business teams get readable test documentation; automation teams retain detailed execution traceability.

Standard Business Scenario

AI-Generated Variation

Regression Pack

Business Test Step

Automation Actions

Business Assertion

Screenshot / Evidence

Execution Result

Meet Jarvis — SyntraFlow's AI Testing Engine

Jarvis extends the Syntra Standard Test Library by analysing the Procure-to-Pay journey, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary, Approval, Integration 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 family pages it links to — it orchestrates and cross-references them.

Generate

Positive, Negative, Boundary, Approval, Integration and Security journey variations.

Parameterize

Use relevant test data from DataVault.

Assemble

Build reusable end-to-end regression packs.

Execute

Run journey scenarios autonomously across SCM and Financials.

Schedule

Execute unattended test batches.

Validate

Evaluate expected business outcomes at every hand-off.

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.

Standard Library — Procure-to-Pay Journey, 9 Business Steps

↓

DataVault — Customer-Specific Test Data

↓

Jarvis AI — Generate Positive + Negative + Boundary + Approval + Integration + Security Variations

↓

Regression Pack — Select Relevant Coverage

↓

SyntraFlow Execution — Each Variation

↓

Detailed UI Actions

↓

Business Assertions

↓

Evidence

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Validate and Match the Invoice (Three-Way Match)

May internally include

Submit Invoice for Validation → Compare PO/Receipt/Invoice Quantities → Compare PO/Invoice Prices → Evaluate Against Match Tolerance → Apply or Release Hold → Route for Approval

Business Step

Verify the Full Audit Trail Links Every Document Together

May internally include

Open Requisition → Trace to Purchase Order → Trace to Receipt → Trace to Invoice → Trace to Payment → Trace to Accounting → Confirm Linked References

What SyntraFlow Captures Per Run

Parameterised input valuesReusable navigationAutomation action traceScreenshots / evidence captureExecution timingPass / fail statusBusiness assertionsEnvironment-independent test data

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 business validation across a multi-stage journey; it does not reflect a specific live execution. When a step 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: Invoice Held at Three-Way Match — Likely category: EXPECTED_VALIDATION — Evidence: Invoice ${INVOICE} quantity does not match receipt ${RECEIPT} against purchase order ${PURCHASE_ORDER} — Recommendation: Correct the invoice quantity or process a receipt correction before resubmitting. A failure should never be labeled as an Oracle defect without first eliminating data, configuration, security, automation, environment and integration causes.

Step	Action Status	Business Validation
Create PO-Matched Invoice	Pass	—
Submit Payment	Pass	—
Verify the Full Audit Trail Links Every Document Together	Pass	Pass

Related End-to-End Journeys & Family Tests

Procure-to-Pay is SyntraFlow's flagship SCM–Financials orchestration journey. Explore the related end-to-end journeys and the family scenario pages it links to below.

Procure-to-Receive Supplier-to-Payment Create PO-Matched Invoice

Turn This Standard Test into Your Oracle Procure-to-Pay Regression Suite

Start with the Syntra Standard Procure-to-Pay journey test, use DataVault to provide environment-specific test data, let Jarvis generate additional matching, timing, approval and security variations, and execute the resulting regression pack automatically with SyntraFlow across SCM and Financials AP.

Automate with SyntraFlow Explore SCM End-to-End Test Library

Use This Oracle Fusion Test Case

Download Test Case

Excel, CSV or JSON export.

Coming soon

Automate with SyntraFlow

Run this script against your own tenant today.

Frequently Asked Questions

Is two-way or three-way match used in this Procure-to-Pay journey?

Whether a purchase order is matched two-way (purchase order and invoice) or three-way (purchase order, receipt and invoice) depends on that purchase order's own configuration, not on a fixed rule in this scenario. This journey exercises both paths where configured, without assuming three-way match is universal across every Oracle Fusion implementation.

How does this page differ from the individual Create Purchase Order, Receive Purchase Order and Create PO-Matched Invoice pages?

Those pages test each stage's own field-level scenario coverage in isolation — for example, purchase order header validation or invoice line matching. This page does not repeat that coverage. It links to those pages and instead tests the hand-offs between stages and the integrity of quantity, amount and document-reference data as it carries forward from requisition through payment and accounting.

What does the Journey Failure Model on this page show?

The Journey Failure Model is a worked example showing how a single failed stage — for example, an invoice held at three-way match — is surfaced at the journey level rather than only as an isolated stage failure. It shows which upstream stages passed, what the expected versus actual result was, how the failure is classified, and what downstream impact it has, such as payment not being executed and accounting not being created.

What do the cross-stage assertions validate that the individual family pages do not?

Cross-stage assertions validate data continuity as a transaction moves between stages — for example, that requisition quantity correctly carries to the purchase order, that received quantity stays within purchase order tolerance, and that payment amount correctly equals the eligible invoice balance. The individual family pages validate each stage's own fields in isolation; they do not, by themselves, confirm that data remained consistent across the hand-off.

What do the failure-intelligence categories mean for a failed Procure-to-Pay journey?

When a step fails, SyntraFlow's evidence trail helps a tester classify the likely cause as DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR. A failure should never be labeled as an Oracle defect without first eliminating data, configuration, security, automation, environment and integration causes.

How is security tested across a multi-stage journey like this?

Access to each stage — requisitioning, purchasing, receiving, invoicing, payment and accounting — is controlled by Oracle Fusion's security configuration, which varies by customer and by role. SyntraFlow can execute representative persona-based variations, such as a procurement buyer or AP specialist versus an unauthorized user, to confirm that access behaves as expected at each stage, without asserting a single universal Oracle security model.

Oracle Fusion Procure-to-Pay Test Scenarios

Test Objective

When to Use This Test

The Procure-to-Pay Journey

Preconditions

Sample Test Data

Test Steps

Expected Results

Key Validation Checkpoints

Go Beyond the Standard Test with Jarvis AI

From Standard Test to Executed Regression Pack

AI-Generated Test Variations

Generated Using Your DataVault Test Data

Standard Library Definition

DataVault

Jarvis AI Generates

Example Test Variations

Positive and Negative Journey Testing

Positive Testing

Negative Testing

Turn AI-Generated Variations into a Regression Pack

SCM End-to-End Procure-to-Pay Regression Pack

Run On-Demand or Schedule Automated Batch Execution

Review Results Across the Entire Test Pack

DataVault Journey Persona

Security & Approval Variations

Cross-Stage Business Assertions

Stage-by-Stage Execution Evidence

Journey Failure Model

Additional Named Regression Packs

P2P Standard Pack

P2P Negative Pack

P2P Approval Pack

P2P Matching Pack

Understand Why a Test Failed

From Business Scenario to Execution Evidence

Meet Jarvis — SyntraFlow's AI Testing Engine

How SyntraFlow Automates This Test

Business Step → Underlying UI Actions

What SyntraFlow Captures Per Run

Action Status vs. Business Validation

Related End-to-End Journeys & Family Tests

Turn This Standard Test into Your Oracle Procure-to-Pay Regression Suite

Use This Oracle Fusion Test Case

Download Test Case

Automate with SyntraFlow

Related Oracle Testing Resources

Frequently Asked Questions