Oracle Fusion Procure-to-Pay Regression Pack
The P2P Regression Pack composes 20 flow-shaped Procure-to-Pay scenarios — Supplier, Requisition, Approval, PO, Receipt, AP Invoice, Validation, Payment and Accounting — into a compact, reusable regression suite, referencing rather than duplicating the individual Procurement and Accounts Payable family pages each scenario ID is drawn from, and remaining deliberately smaller and faster-running than the deeper 45-scenario Procure-to-Pay End-to-End journey it cross-links to.
| Test ID | ORCL.REGRESSION.P2P |
| Application | Oracle Fusion Cloud |
| Product | Regression |
| Module | Regression Packs |
| Process | P2P Regression |
| Business Flow | Procure-to-Pay Regression |
| Scenario Type | Regression Pack / Composition |
| Test Usage | Regression Testing / Release Validation / UAT |
| Priority | High |
| Automation | SyntraFlow Ready |
| Library | Syntra Regression Pack |
Note on test design: These business steps describe running the composed P2P Regression Pack itself — confirming supplier readiness, selecting scenario IDs, binding test data, executing the batch and classifying results — not the detailed field-level steps of each of the 20 referenced scenarios, which are documented individually on their family pages and, for full step-by-step continuity, on the Procure-to-Pay End-to-End journey. This scenario is presented as 9 business-readable test steps; SyntraFlow's automation executes approximately 142 underlying Oracle Fusion UI actions to complete it.
Test Objective
The objective of the P2P Regression Pack is to give release and QA teams a defined, repeatable set of 20 flow-shaped Oracle Fusion Procure-to-Pay scenarios — spanning Supplier, Requisition, Approval, PO, Receipt, AP Invoice, Validation, Payment and Accounting — that can be run together ahead of a quarterly update, patch or configuration change, without needing to execute the full 45-scenario Procure-to-Pay End-to-End journey every cycle.
The scenario should confirm that:
- the 20 referenced REG-P2P scenario IDs are correctly composed from their underlying Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages
- quantity and amount correctly carry across the flow — from requisition into PO, PO into receipt, receipt into invoice match, and validated invoice into payment and accounting
- three-way match integrity is correctly enforced, with quantity and price mismatches correctly placed on hold rather than silently validated
- negative and security validations are correctly enforced across the composed pack rather than only within a single family page
- a batch execution of the pack correctly records pass/fail status per scenario, with failures classified into a likely root-cause category
- the pack can be scheduled and re-run on a defined cadence, such as ahead of a quarterly Oracle update
- unauthorized users are correctly blocked from creating or approving a transaction at any stage of the flow
This pack does not duplicate the individual field-level scenario coverage already tested on the Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages. It also does not duplicate the detailed, step-by-step 45-scenario coverage documented on the Procure-to-Pay End-to-End journey page — this compact 20-scenario pack references those same scenario IDs and family pages, but is scoped for faster, more frequent regression runs. For full step-by-step detail on any stage of the flow, see the Procure-to-Pay End-to-End journey.
When to Use This Test
- Regression testing ahead of an Oracle quarterly update, patch or configuration change across the Supplier-to-Accounting Procure-to-Pay flow
- A faster-running alternative to the full 45-scenario Procure-to-Pay End-to-End journey when release timelines only require the 20 highest-risk flow scenarios
- Release sign-off requiring evidence that P2P-critical scenarios still pass without re-running the full journey or module-level test library
- Validating flow continuity — quantity from PO into receipt, receipt into invoice match, validated invoice into payment and accounting — rather than re-testing each family page's individual field-level scenarios
- Scheduled nightly or pre-release batch execution with Failure Intelligence classification when a scenario fails
P2P Regression Pack Composition
The P2P Regression Pack composes 20 scenarios across these nine flow stages of Oracle Fusion Procure-to-Pay, referencing the Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages rather than duplicating their individual scenario coverage. This compact pack is deliberately smaller than the 45-scenario Procure-to-Pay End-to-End journey — it exists for faster, more frequent regression runs, and links to the End-to-End journey for full step-by-step detail on any stage.
Preconditions
- The Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages referenced by this pack's 20 scenario IDs are individually functional in the target Oracle Fusion environment.
- A valid supplier, item, purchase order and accounting period are available and enabled across Procurement and Accounts Payable.
- The test user holds the roles required to execute each referenced scenario, or alternate unauthorized-user personas are available for security testing.
- DataVault test data bindings for the referenced scenario IDs are current for the environment under test.
- Approval hierarchies, match tolerances, payment methods and security roles are configured according to the target environment — this pack does not assume a single universal configuration applies to every scenario.
Exact approval hierarchies, match tolerances, payment methods and security roles vary by Oracle Fusion implementation and customer-specific setup. This pack validates that Oracle correctly enforces whatever configuration is in place for each referenced scenario, not a single universal rule.
Sample Test Data
| Supplier | ${SUPPLIER} |
| Requisition | ${REQUISITION} |
| PO Number | ${PO_NUMBER} |
| Item | ${ITEM} |
| Quantity | ${QUANTITY} |
| Receipt | ${RECEIPT} |
| Invoice | ${INVOICE} |
| Amount | ${AMOUNT} |
| Payment | ${PAYMENT} |
| Accounting Period | ${ACCOUNTING_PERIOD} |
Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion TEST/UAT environment. Not every field applies to every referenced scenario — for example, Payment fields apply only to Payment-stage scenarios and are not used for Requisition or PO-stage scenarios.
Test Steps
9 business-readable steps. SyntraFlow's automation executes ~142 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.
| # | User Action | Expected Result |
|---|---|---|
| 1 | Confirm Supplier Readiness Confirm supplier ${SUPPLIER} is active, enabled for procurement and holds valid banking setup, referencing the standard Suppliers family page. ${SUPPLIER} | Supplier ${SUPPLIER} is correctly active and available for requisitioning and payment. |
| 2 | Create the Requisition Create requisition ${REQUISITION} for item ${ITEM} and quantity ${QUANTITY}, referencing the standard Requisitions family page and scenario REG-P2P-001. ${REQUISITION} / ${ITEM} / ${QUANTITY} | The requisition is correctly created with supplier, line and quantity detail carried forward. |
| 3 | Route the Requisition Approval Route requisition ${REQUISITION} through requisition approval per the configured hierarchy, referencing the standard Requisitions family page and scenario REG-P2P-002. ${REQUISITION} | Requisition approval is correctly enforced per the configured hierarchy before PO conversion. |
| 4 | Create and Approve the PO Convert the approved requisition into purchase order ${PO_NUMBER} and route it through PO approval, referencing the standard Purchase Orders family page and scenario REG-P2P-003. ${PO_NUMBER} / ${SUPPLIER} | The purchase order is correctly created and approved, carrying requisition, supplier and price detail forward without discrepancy. |
| 5 | Receive Against the PO Record a receipt ${RECEIPT} against purchase order ${PO_NUMBER}, including full, partial and corrected receipt paths, referencing the standard Receiving family page and scenarios REG-P2P-004 through REG-P2P-006. ${RECEIPT} / ${PO_NUMBER} / ${QUANTITY} | Received quantity is correctly recorded against the PO, with partial receipts and corrections correctly reflected in open PO quantity. |
| 6 | Create the AP Invoice Create invoice ${INVOICE} matched to purchase order ${PO_NUMBER} or, where supported, to receipt ${RECEIPT}, referencing the standard AP Invoice Processing family page and scenarios REG-P2P-007 and REG-P2P-008. ${INVOICE} / ${PO_NUMBER} / ${AMOUNT} | The invoice is correctly created and carries forward matched quantity and amount from the referenced PO or receipt. |
| 7 | Validate the MatchBusiness assertion Validate invoice ${INVOICE} against its matched PO and receipt, confirming quantity and price mismatches are correctly placed on hold and resolved holds correctly clear for payment, referencing the standard AP Invoice Processing family page and scenarios REG-P2P-009 through REG-P2P-012. ${INVOICE} / ${AMOUNT} This is a primary business assertion for the pack — correctly enforced match integrity, not merely a successful invoice creation, is the expected pass condition. | Three-way match integrity is correctly enforced — mismatches are correctly flagged rather than silently validated, and resolved holds correctly clear. |
| 8 | Process the Payment Process payment ${PAYMENT} for validated invoice ${INVOICE} — full, partial, via Payment Process Request, electronic, held or voided and repaid — referencing the standard AP Payments family page and scenarios REG-P2P-013 through REG-P2P-019. ${PAYMENT} / ${AMOUNT} / ${SUPPLIER} | Payment is correctly created against the validated invoice amount, with holds, voids and reissues correctly reflected in supplier balance. |
| 9 | Verify Accounting ContinuityBusiness assertion Confirm the accounting entries generated across requisition, PO, receipt, invoice and payment remain correctly consistent end-to-end, referencing scenario REG-P2P-020 and, for full step-by-step detail, the Procure-to-Pay End-to-End journey. ${AMOUNT} / ${ACCOUNTING_PERIOD} This is the final business assertion for the pack — correctly reconciled accounting continuity across all nine flow stages is the expected pass condition. | Accounting entries correctly reconcile from requisition through payment, with no orphaned or mismatched accounting lines. |
Expected Results
- All 20 referenced REG-P2P scenario IDs are correctly included and resolvable against the target environment.
- Test data binds correctly to each scenario via DataVault before execution.
- Each scenario in the batch run records a pass, fail or exception status.
- Quantity and amount continuity remain correctly consistent from requisition through PO, receipt, invoice and payment.
- Three-way match mismatches are correctly flagged on hold rather than silently validated, and resolved holds correctly clear.
- Any failure is correctly classified into a likely root-cause category rather than assumed to be an Oracle defect.
- The pack's aggregate result is available as evidence for a release go/no-go decision.
Key Validation Checkpoints
- all 20 scenario IDs correctly resolved from their referenced family pages
- DataVault test data correctly bound to each scenario before execution
- batch execution correctly records pass/fail/exception per scenario
- quantity and amount continuity correctly maintained across the flow
- quantity and price mismatches correctly placed on hold rather than silently validated
- negative and security scenarios correctly enforce the expected restriction
- failed scenarios correctly classified using the 8-category taxonomy
- aggregate pack result correctly available for release sign-off
Go Beyond the Standard Pack with Jarvis AI
The Syntra Standard Test Library defines the P2P Regression Pack as a composition of 20 regression-critical scenario IDs across the Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages within SCM and Financials. Jarvis AI extends this pack by following the pipeline from SCM/Financials 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, Integration and Security categories — before they can be assembled into this Regression Pack and Scheduled Execution, with results surfaced through Failure Intelligence.
Teams do not need to manually assemble which requisition, PO, receipt, invoice and payment scenarios matter most for a release. Jarvis uses this standard 20-scenario pack composition as the foundation and generates relevant Positive, Negative, Boundary, Integration and Security variations for the customer's environment — including quantity and price mismatches, blocked approvals and payment exceptions — since correctly enforced continuity across the Procure-to-Pay flow, not just individually correct transactions, is what this pack 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 references, or the detailed step-by-step coverage on the Procure-to-Pay End-to-End journey; this page remains the canonical reference for the compact regression pack.
From Standard Test to Executed Regression Pack
Rather than re-testing every requisition, PO, receipt, invoice and payment field individually — already covered on their respective family pages and on the deeper Procure-to-Pay End-to-End journey — SyntraFlow maintains one compact P2P Regression Pack composed of 20 regression-critical scenario IDs, documented in the browser below, and allows Jarvis AI to generate item, supplier and security-specific pack variations using the customer's available test data. These variations do not create additional public SEO pages.
AI-Generated Test Variations
The same P2P Regression Pack 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 P2P Journey Regression.
- Pack validating requisition-to-PO-to-receipt continuity correctly carries quantity and price forward without discrepancy
- Pack validating PO-matched and receipt-matched invoices correctly carry matched quantity and amount into validation
- Pack validating a resolved invoice hold correctly clears the invoice for payment
- Pack validating full, partial, Payment Process Request and electronic payment correctly relieve the validated invoice balance
- Pack validating accounting entries correctly reconcile end-to-end from requisition through payment
- Pack scenario where a quantity mismatch between receipt and invoice is correctly placed on hold rather than silently validated
- Pack scenario where a price mismatch beyond configured tolerance is correctly placed on hold rather than silently validated
- Pack scenario where an inactive or invalid supplier bank account is correctly rejected rather than allowing payment to proceed
These are representative examples only. Pack behavior, approval routing, match tolerances and available transaction paths can depend on the customer's Oracle Fusion configuration and security — not every Oracle configuration behaves identically.
Generated Using Your DataVault Test Data
Generic test data rarely represents every supplier, item, PO and payment method referenced across a real Oracle Fusion P2P Regression Pack run. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct pack scenarios relevant to the customer's actual implementation.
Standard Library Definition
Supplier ${SUPPLIER}
Requisition ${REQUISITION}
PO Number ${PO_NUMBER}
Item ${ITEM}
Quantity ${QUANTITY}
Receipt ${RECEIPT}
Invoice ${INVOICE}
Amount ${AMOUNT}
Payment ${PAYMENT}
Accounting Period ${ACCOUNTING_PERIOD}
DataVault
Suppliers Approved suppliers, sites and bank accounts Items Active items with sourcing and pricing by supplier Match Tolerances Configured quantity and price tolerance rules Payment Methods Configured payment methods and formats by supplier Security Roles authorised at each referenced scenario stage
Jarvis AI Generates
Scenario 01 — Standard Happy Path, ${SUPPLIER}
Scenario 02 — PO-Matched Invoice, ${PO_NUMBER}
Scenario 03 — Price Mismatch Hold, ${INVOICE}
Scenario 04 — Payment Process Request, ${PAYMENT}
Scenario 05 — Unauthorized User Attempts Payment
...
Supplier, requisition, PO, receipt, invoice and payment data used in P2P Regression Pack 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 and payment 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 the 20 scenario IDs composed into the P2P Regression Pack across Supplier, Requisition, PO, Receipt, Invoice and Payment stages, plus cross-stage negative coverage. Each row references the real family page the underlying scenario is defined on, or the Procure-to-Pay End-to-End journey for continuity scenarios — this pack does not duplicate that field-level definition.
| ID | Variation | Type | Key Difference | Execution |
|---|---|---|---|---|
| REG-P2P-001 | Standard Happy Path | Requisition/PO/Receipt/Invoice/Payment | Regression-critical instance validating the full Supplier-to-Accounting flow completes cleanly for requisition ${REQUISITION}, PO ${PO_NUMBER}, receipt ${RECEIPT}, invoice ${INVOICE} and payment ${PAYMENT}. Source: Procure-to-Pay End-to-End Journey (/oracle-erp-testing-tool/test-library/scm/end-to-end/procure-to-pay/) | Illustrative |
| REG-P2P-002 | Requisition Approval | Requisition | Regression-critical instance validating that requisition ${REQUISITION} is correctly routed and approved per the configured approval hierarchy before PO conversion. Source: Requisitions (/oracle-erp-testing-tool/test-library/scm/procurement/requisitions/) | Illustrative |
| REG-P2P-003 | PO Approval | PO | Regression-critical instance validating that purchase order ${PO_NUMBER} is correctly approved according to the configured approval hierarchy before it becomes available for receiving. Source: Purchase Orders (/oracle-erp-testing-tool/test-library/scm/procurement/purchase-orders/) | Illustrative |
| REG-P2P-004 | Partial Receipt | Receipt | Regression-critical instance validating that a partial receipt ${RECEIPT} against purchase order ${PO_NUMBER} correctly records received quantity ${QUANTITY} while leaving the remaining PO quantity open. Source: Receiving (/oracle-erp-testing-tool/test-library/scm/procurement/receiving/) | Illustrative |
| REG-P2P-005 | Multiple Partial Receipts | Receipt | Regression-critical instance validating that successive partial receipts against purchase order ${PO_NUMBER} correctly accumulate received quantity toward the full ${QUANTITY} ordered. Source: Receiving (/oracle-erp-testing-tool/test-library/scm/procurement/receiving/) | Illustrative |
| REG-P2P-006 | Receipt Correction | Receipt | Regression-critical instance validating that correcting receipt ${RECEIPT} correctly adjusts received quantity and downstream on-hand for purchase order ${PO_NUMBER}. Source: Receiving (/oracle-erp-testing-tool/test-library/scm/procurement/receiving/) | Illustrative |
| REG-P2P-007 | PO-Matched Invoice | Invoice | Regression-critical instance validating that invoice ${INVOICE} matched to purchase order ${PO_NUMBER} correctly carries forward matched quantity and amount ${AMOUNT}. Source: AP Invoice Processing (/oracle-erp-testing-tool/test-library/financials/accounts-payable/invoice-processing/) | Illustrative |
| REG-P2P-008 | Receipt-Matched Invoice Where Supported | Invoice | Regression-critical instance validating that, where the environment supports it, invoice ${INVOICE} matched to receipt ${RECEIPT} rather than the PO correctly carries forward received quantity and amount ${AMOUNT}. Source: AP Invoice Processing (/oracle-erp-testing-tool/test-library/financials/accounts-payable/invoice-processing/) | Illustrative |
| REG-P2P-009 | Quantity Mismatch | Invoice/Negative | Cross-stage negative instance confirming Oracle correctly places invoice ${INVOICE} on hold when invoiced quantity does not match received quantity for ${PO_NUMBER}, rather than silently validating it. Source: AP Invoice Processing (/oracle-erp-testing-tool/test-library/financials/accounts-payable/invoice-processing/) | Illustrative |
| REG-P2P-010 | Price Mismatch | Invoice/Negative | Cross-stage negative instance confirming Oracle correctly places invoice ${INVOICE} on hold when invoiced price for ${ITEM} exceeds the configured match tolerance against purchase order ${PO_NUMBER}. Source: AP Invoice Processing (/oracle-erp-testing-tool/test-library/financials/accounts-payable/invoice-processing/) | Illustrative |
| REG-P2P-011 | Invoice Hold | Invoice/Negative | Regression-critical instance validating that invoice ${INVOICE} correctly remains on hold and ineligible for payment until the underlying exception is resolved. Source: AP Invoice Processing (/oracle-erp-testing-tool/test-library/financials/accounts-payable/invoice-processing/) | Illustrative |
| REG-P2P-012 | Hold Resolution | Invoice | Regression-critical instance validating that resolving the underlying exception on invoice ${INVOICE} correctly clears the hold and makes it eligible for payment. Source: AP Invoice Processing (/oracle-erp-testing-tool/test-library/financials/accounts-payable/invoice-processing/) | Illustrative |
| REG-P2P-013 | Full Payment | Payment | Regression-critical instance validating that payment ${PAYMENT} for the full validated amount ${AMOUNT} of invoice ${INVOICE} correctly clears the outstanding balance. Source: AP Payments (/oracle-erp-testing-tool/test-library/financials/accounts-payable/payments/) | Illustrative |
| REG-P2P-014 | Partial Payment | Payment | Regression-critical instance validating that a partial payment ${PAYMENT} against invoice ${INVOICE} correctly reduces the outstanding balance while leaving the remainder open. Source: AP Payments (/oracle-erp-testing-tool/test-library/financials/accounts-payable/payments/) | Illustrative |
| REG-P2P-015 | Payment Process Request | Payment | Regression-critical instance validating that a Payment Process Request correctly selects and batches eligible validated invoices for supplier ${SUPPLIER} into payment ${PAYMENT}. Source: AP Payments (/oracle-erp-testing-tool/test-library/financials/accounts-payable/payments/) | Illustrative |
| REG-P2P-016 | Electronic Payment | Payment | Regression-critical instance validating that an electronic payment ${PAYMENT} for supplier ${SUPPLIER} correctly generates the expected payment file format and status. Source: AP Payments (/oracle-erp-testing-tool/test-library/financials/accounts-payable/payments/) | Illustrative |
| REG-P2P-017 | Payment Hold | Payment/Negative | Cross-stage negative instance confirming a payment hold on invoice ${INVOICE} correctly prevents payment ${PAYMENT} from being issued rather than silently proceeding. Source: AP Payments (/oracle-erp-testing-tool/test-library/financials/accounts-payable/payments/) | Illustrative |
| REG-P2P-018 | Void and Repay | Payment | Regression-critical instance validating that voiding payment ${PAYMENT} correctly reopens invoice ${INVOICE} for payment, and a subsequent reissued payment correctly clears the balance. Source: AP Payments (/oracle-erp-testing-tool/test-library/financials/accounts-payable/payments/) | Illustrative |
| REG-P2P-019 | Supplier Bank Negative Test | Negative | Cross-stage negative instance confirming Oracle correctly rejects or blocks payment ${PAYMENT} to supplier ${SUPPLIER} when the supplier bank account is inactive or invalid, rather than allowing payment to proceed. Source: Suppliers (/oracle-erp-testing-tool/test-library/scm/procurement/suppliers/) | Illustrative |
| REG-P2P-020 | P2P Accounting Continuity | Requisition/PO/Receipt/Invoice/Payment | Cross-stage continuity instance confirming accounting entries generated for requisition ${REQUISITION}, PO ${PO_NUMBER}, receipt ${RECEIPT}, invoice ${INVOICE} and payment ${PAYMENT} correctly reconcile end-to-end for accounting period ${ACCOUNTING_PERIOD}. Source: Procure-to-Pay End-to-End Journey (/oracle-erp-testing-tool/test-library/scm/end-to-end/procure-to-pay/) | Illustrative |
No variations match this filter.
Positive and Negative Pack Testing
Positive Testing
Jarvis generates pack scenarios using supplier, item, PO and payment combinations expected to successfully complete each referenced scenario and its cross-stage continuity check in Oracle Fusion.
Correctly Approved Requisition → Approved PO → Receipt → Matched Invoice → Payment → Accounting Reconciled
Negative Testing
Jarvis can also generate pack scenarios designed to exercise Oracle's validations around match mismatches, holds and unauthorized access at any referenced stage.
- Quantity Mismatch Between Receipt and Invoice → Expected Flag Rather Than Silent Validation
- Price Mismatch Beyond Configured Tolerance → Expected Hold Rather Than Silent Validation
- Inactive Supplier Bank Account → Expected Rejection Rather Than Payment Proceeding
- Unauthorized User Attempts Approval or Payment → 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 data at every referenced stage | Pack scenario completes end-to-end | PASS |
| Quantity or price mismatch between stages | Hold or validation occurs | PASS |
| Missing required upstream document | Validation occurs | PASS |
| Unauthorized user at any referenced stage | Access prevented | PASS |
| Unexpected application exception | Unexpected failure | FAIL |
Turn AI-Generated Variations into a Regression Pack
This P2P Regression Pack is a compact, 20-scenario execution pack — distinct from and cross-linked to the deeper 45-scenario Procure-to-Pay End-to-End journey at /oracle-erp-testing-tool/test-library/scm/end-to-end/procure-to-pay/, which documents the full step-by-step flow. Users can select generated P2P Regression scenarios and group them into this reusable execution pack for faster, more frequent regression runs.
P2P Regression Pack
- Standard Happy Path
- Requisition Approval
- PO Approval
- Partial Receipt
- PO-Matched Invoice
- Price Mismatch
- Payment Process Request
- P2P Accounting Continuity
Run On-Demand or Schedule Automated Batch Execution
SyntraFlow can execute the P2P Regression Pack's 20 scenarios individually or as a batch. Users can schedule the pack according to their release or testing cycle.
Once scheduled, SyntraFlow executes the P2P Regression Pack's scenarios unattended and records the outcome of each scenario and cross-stage business assertion.
| Pack | P2P Regression Pack |
| Schedule | Quarterly Update Regression |
| Tests | 20 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 pack into a scenario, its business steps, the underlying automation actions across each referenced Procurement and AP family page, and the evidence captured for each.
Illustrative example data — not actual production metrics.
Regression Pack → Scenario → Business Step → Automation Action → Evidence
DataVault Journey Persona
This persona groups the linked-entity dimensions that must stay consistent across the P2P Regression Pack as DataVault-supplied test data flows from supplier and requisition creation through PO, receipt, invoice, payment and accounting.
| Supplier | ${SUPPLIER} |
| Requisition | ${REQUISITION} |
| PO Number | ${PO_NUMBER} |
| Item | ${ITEM} |
| Quantity | ${QUANTITY} |
| Receipt | ${RECEIPT} |
| Invoice | ${INVOICE} |
| Amount | ${AMOUNT} |
| Payment | ${PAYMENT} |
| Accounting Period | ${ACCOUNTING_PERIOD} |
Keeping these dimensions linked across DataVault-supplied test data lets Jarvis generate pack variations that remain internally consistent from supplier and requisition creation through to whichever referenced scenario — PO, receipt, invoice, payment or accounting — the regression pack composes.
Security & Approval Variations
Access to each stage referenced by this pack — creating or approving a requisition, purchase order, invoice or payment — 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 — not to assert a single universal Oracle security model.
| Persona | Action | Expected | Syntra Result |
|---|---|---|---|
| Procurement Buyer | Create Requisition and Purchase Order | Allowed | PASS |
| Procurement Approver | Approve Requisition and Purchase Order | Allowed | PASS |
| Finance AP Specialist | Create and Validate AP Invoice | Allowed | PASS |
| Finance AP Manager | Approve Payment Process Request | Allowed | PASS |
| Unauthorized User | Attempts to Create Payment Without Role | Access prevented | PASS |
Cross-Stage Business Assertions
These assertions validate that quantity, amount and document linkage remain consistent as the flow crosses from Requisition through PO, Receipt, AP Invoice, Validation, Payment and Accounting.
| Stage Transition | Assertion | Example | Status |
|---|---|---|---|
| Requisition -> PO | Requisitioned Qty = PO Qty | Requisition ${REQUISITION} quantity ${QUANTITY} for ${ITEM} = PO ${PO_NUMBER} quantity | PASS |
| PO -> Receipt | Received Qty <= PO Qty, correctly accumulated across partial receipts | Receipt ${RECEIPT} against ${PO_NUMBER} correctly reduces open PO quantity | PASS |
| Receipt -> AP Invoice | Matched Invoice Qty/Price correctly reconciles to Receipt/PO, mismatches correctly held | Invoice ${INVOICE} amount ${AMOUNT} matches receipt ${RECEIPT} for ${PO_NUMBER} | PASS |
| Validation -> Payment | Validated Invoice Amount = Payment Amount | Payment ${PAYMENT} for invoice ${INVOICE} equals validated amount ${AMOUNT} | PASS |
| Payment -> Accounting | Payment Amount correctly reconciles to accounting entries | Payment ${PAYMENT} amount ${AMOUNT} reconciles in accounting period ${ACCOUNTING_PERIOD} | PASS |
Illustrative example using DataVault variables — not hard-coded production values.
Stage-by-Stage Execution Evidence
This example shows illustrative execution status recorded at each of the nine P2P Regression Pack flow stages in one representative pack run, including how a failure at one stage blocks downstream stages.
Illustrative example run — not a live execution.
Journey Failure Model
This example shows how a failure at the Validation stage is classified and reported without blocking visibility into which upstream stages already passed.
| Supplier | PASS |
| Requisition | PASS |
| Approval | PASS |
| PO | PASS |
| Receipt | PASS |
| AP Invoice | PASS |
Price Mismatch (REG-P2P-010)
Invoice ${INVOICE} price variance beyond the configured match tolerance is correctly placed on hold pending resolution.
Invoice ${INVOICE} validated and became eligible for payment despite a price variance exceeding the configured match tolerance for ${PO_NUMBER}.
Payment ${PAYMENT} for invoice ${INVOICE} is at risk of paying an incorrect amount; downstream accounting continuity cannot be verified until resolved.
Verify match tolerance and hold reason configuration for the invoice validation rule set, and escalate only after eliminating data, security, automation and environment causes.
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 Smoke Only
- Standard Happy Path
- Requisition Approval
- PO Approval
- Full Payment
- P2P Accounting Continuity
P2P Negative Only
- Quantity Mismatch
- Price Mismatch
- Invoice Hold
- Payment Hold
- Supplier Bank Negative Test
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 P2P Regression Pack's 20 referenced scenarios, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary, Integration and Security coverage for the customer's environment, following the SCM/Financials → Functional Area → 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 family pages it references, or the detailed coverage on the Procure-to-Pay End-to-End journey.
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 transaction at any single stage does not automatically prove the full flow 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 scenario in the pack fails, SyntraFlow's evidence trail is designed to help a tester classify the likely cause across an 8-category taxonomy — 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 Validated Despite Price Variance — Likely category: CONFIGURATION_ERROR — Evidence: Invoice ${INVOICE} price variance exceeds the configured match tolerance but was not placed on hold — Recommendation: Verify match tolerance and hold reason configuration. 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 |
|---|---|---|
| Process the Payment | Pass | — |
| Validate the Match | Pass | Pass |
| Verify Accounting Continuity | Pass | Pass |
Related Regression Packs & the Procure-to-Pay Journey
The P2P Regression Pack composes 20 scenario IDs from the Requisitions, Purchase Orders, Receiving, Suppliers, AP Invoice Processing and AP Payments family pages, and links directly to both those pages and the deeper Procure-to-Pay End-to-End journey for full step-by-step detail.
Turn This Standard Pack into Your Oracle P2P Regression Suite
Start with the Syntra Standard P2P Regression Pack, use DataVault to provide environment-specific test data, let Jarvis generate additional supplier, item and security variations, and execute the resulting 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.