Oracle ERP Testing Tool > Test Library > SCM > Procurement > Purchase Orders

Syntra Standard Oracle Test Library

Oracle Fusion Change Purchase Order Test Cases

Validate that an eligible Oracle Fusion purchase order can be changed within allowed limits — quantity, price, need-by date, ship-to, terms or lines — while the resulting change order retains prior values in version history and re-triggers approval where configured.

Test ID	ORCL.P2P.PROC.PO.CHANGE
Application	Oracle Fusion Cloud
Product	SCM / Procurement
Module	Procurement
Process	Purchase Orders
Business Flow	Procure-to-Pay
Scenario Type	Positive / 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 automatically while presenting the scenario 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 23 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to validate change-order processing on eligible Oracle Fusion purchase orders — confirming that allowed changes such as quantity, price, need-by date, ship-to, terms and lines are accepted, correctly applied, and preserved alongside the purchase order's prior values and version history.

The scenario should confirm that:

an eligible purchase order can be opened for change by an authorized user
the target field or fields accept a valid new value without unexpected errors
the change order is created and the revised values are reflected accurately once saved
the purchase order's version and change history retain a record of the change rather than silently overwriting it
reapproval is re-triggered where the customer's workflow configuration requires it
the purchase order status remains correct and consistent with the change performed

This scenario covers changing an existing purchase order within Oracle Fusion Procurement TEST/UAT environments. It does not cover initial PO creation, which is covered by the separate Create Purchase Order scenario, or PO cancellation, which is covered by the separate Cancel Purchase Order scenario. Individual field-level changes such as quantity, price or terms are represented as data-driven variations of this same test rather than as separate published test pages.

When to Use This Test

Functional testing of allowed change-order field changes for a new Oracle Fusion Procurement implementation
Regression testing of change-order and reapproval behavior after an Oracle quarterly update
UAT sign-off for buyers who routinely amend purchase orders before or after partial receipt
Baseline case referenced by the create, approve and cancel scenarios within the same purchase order lifecycle

Where This Test Fits in the Purchase Order Lifecycle

Create

→

Change

→

Approve

→

Receive

→

Match

→

Change Purchase Order applies to a purchase order that already exists, adjusting one or more field values via a change order while keeping the PO itself intact. It does not cover initial creation or cancellation, which are covered by other stages of the same purchase order lifecycle. Exact allowed changes, timing restrictions and reapproval behavior depend on PO status, receipt/match progress, customer workflow configuration and security setup.

← Previous Stage

Create Purchase Order

Next Stage →

Approve Purchase Order

Preconditions

A purchase order exists and is in a status that is eligible for change.
The buyer or authorized user performing the change has the appropriate change privileges.
The target values for the change — quantity, price, date, ship-to, terms or line — are valid and configured for the test tenant.
The test user has permission to open and edit purchase orders in Oracle Fusion Procurement.

Exact eligible statuses, field-level restrictions and validation messages may vary by Oracle Fusion implementation, purchase order workflow configuration and security setup.

Sample Test Data

Business Unit	${BUSINESS_UNIT}
PO Number	${PO_NUMBER}
Current PO Status	${PO_STATUS}
New Quantity	${NEW_QUANTITY}
New Price	${NEW_PRICE}
New Need-By Date	${NEW_NEED_BY_DATE}
New Ship-To	${NEW_SHIP_TO}
New Terms	${NEW_TERMS}
Line Number	${LINE_NUMBER}

Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion TEST/UAT environment. Only the field or fields relevant to a given variation are typically changed in a single execution.

Test Steps

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

#	User Action	Expected Result
1	Sign In to Oracle Fusion Sign in to Oracle Fusion using an authorized Procurement test user.	Oracle Fusion signs the user in successfully and the home page loads.
2	Navigate to the Purchase Order Navigate to the Purchase Orders work area and search for the purchase order eligible for change. ${PO_NUMBER} This single business step replaces multiple technical actions such as opening PO search, entering the PO number, and selecting the result.	The correct purchase order is located and its current status and values are displayed.
3	Open the Purchase Order for Change Select the option to open the located purchase order for change.	The purchase order opens in an editable state showing its current field values.
4	Modify the Target Field or Fields Update the field or fields relevant to this variation — quantity, price, need-by date, ship-to, line or terms. ${NEW_QUANTITY} / ${NEW_PRICE} / ${NEW_NEED_BY_DATE} / ${NEW_SHIP_TO} / ${NEW_TERMS} / ${LINE_NUMBER}	The new value is accepted without unexpected validation errors.
5	Review Revised Values and Version Review the revised field values and the resulting change-order version before saving. Reviewing the change before saving lets the tester catch an incorrect value entry before it is committed.	The revised values and version shown match the intended change for this variation.
6	Save the Changed Purchase Order Submit and save the change order in the test environment.	Oracle Fusion successfully saves the change order without unexpected errors.
7	Verify Version and History UpdatedBusiness assertion Review the purchase order's version and change history after saving. This is a primary business assertion for the scenario — a correctly recorded version and history is the expected pass condition, not merely a successful save.	The purchase order version increments and the change history reflects the change performed.
8	Verify Revised Values RetainedBusiness assertion Reopen or refresh the purchase order and confirm the revised field values are present.	The purchase order reflects the revised values accurately.
9	Verify Reapproval Triggered Where ConfiguredBusiness assertion Review the purchase order's approval status after the change is saved.	Where the customer's workflow configuration requires it, reapproval is triggered and the purchase order status reflects this correctly.

Expected Results

The target field or fields accept the new value without unexpected errors.
A change order is created and the revised values are reflected accurately once saved.
The purchase order's version and change history retain a record of both the prior and new values.
Reapproval is triggered where the customer's workflow configuration requires it.
The purchase order status remains correct and consistent with the change performed.
Unauthorized change attempts are correctly prevented.

Key Validation Checkpoints

Change order is created.
Revised values are retained on the purchase order.
Version and history are updated.
Reapproval is triggered where configured.

Core Business Scenario

Change Purchase Order

Business Steps

Test Variations

AI-Generated

Test Data

DataVault-Driven

Execution

On-Demand / Scheduled / Batch

Automation

SyntraFlow Ready

Jarvis AI

Go Beyond the Standard Test with Jarvis AI

The Syntra Standard Test Library defines the core change-purchase-order business scenario. Jarvis AI can extend this scenario by generating additional field, status and security variations using customer-specific test data and configuration available through Syntra DataVault.

Teams do not need to manually build a separate test for every field a purchase order can change, or for every status and permission combination. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative, Boundary and Security variations for the customer's environment.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable change-purchase-order business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Purchase Orders, Items, Suppliers, Ship-To Locations, Payment Terms and Approval Workflows.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant field, status and security variations.

Positive + Negative + Boundary + Security Test Variations

Valid field-change scenarios alongside edge cases such as closed or cancelled POs, invalid values and unauthorized users.

Regression Pack

Selected variations can be grouped into an executable suite.

On-Demand / Scheduled / Batch Execution

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

Results + Evidence + Exceptions

Capture execution results, business assertions, screenshots/evidence and exceptions.

Rather than maintaining a separate test page for every field a purchase order can change, SyntraFlow maintains one core change-purchase-order scenario and allows Jarvis AI to generate field-driven, status and security-specific variations using the customer's available test data.

AI-Generated Test Variations

The same Change Purchase Order 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 Procurement Purchase Orders.

Positive Scenarios

Change purchase order quantity
Change purchase order price
Change purchase order need-by date
Change purchase order ship-to
Add a purchase order line
Cancel a purchase order line
Change purchase order terms
Change purchase order after partial receipt where allowed

Negative Scenarios

Purchase order closed
Purchase order cancelled
Invalid account entered for the change
Invalid supplier data entered for the change
Unauthorized user attempts a change
Purchase order in an invalid status for change
Invalid effective date entered for the change

These are representative examples only. Negative-scenario behavior and available change types 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 purchase order, field, supplier and account combination in a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct change-purchase-order scenarios relevant to the customer's actual implementation.

Standard Library Definition

Business Unit        ${BUSINESS_UNIT}
PO Number             ${PO_NUMBER}
Current PO Status     ${PO_STATUS}
New Quantity          ${NEW_QUANTITY}
New Price             ${NEW_PRICE}
New Need-By Date      ${NEW_NEED_BY_DATE}
New Ship-To           ${NEW_SHIP_TO}
New Terms             ${NEW_TERMS}
Line Number           ${LINE_NUMBER}

DataVault

Purchase Orders
  Open and eligible-for-change purchase orders
Items
  Active items with valid quantity/price ranges
Suppliers
  Active suppliers eligible for assignment
Ship-To Locations
  Configured ship-to locations per Business Unit
Payment Terms
  Valid term codes per supplier agreement
Approval Workflow
  Reapproval rules per change type

Jarvis AI Generates

Scenario 01 — PO-4001 + Change Quantity
Scenario 02 — PO-4001 + Change Price
Scenario 03 — PO-5002 + Change Ship-To + After Partial Receipt
Scenario 04 — PO-5002 + Cancel Line
Scenario 05 — Invalid Account Entered
Scenario 06 — Unauthorized User Attempts Change
...

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. Where DataVault is connected, customer-specific dimensions such as purchase order, supplier, account and location remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Representative examples of change-purchase-order scenarios Jarvis can generate from this business scenario, spanning field, status and security conditions. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.

ID	Variation	Type	Key Difference	Execution
VAR-001	Change Purchase Order Quantity	Positive/Field	Quantity updated to a new valid value	Syntra Ready
VAR-002	Change Purchase Order Price	Positive/Field	Price updated to a new valid value	Syntra Ready
VAR-003	Change Purchase Order Need-By Date	Positive/Field	Need-by date updated to a new valid date	Syntra Ready
VAR-004	Change Purchase Order Ship-To	Positive/Field	Ship-to updated to a new configured location	Syntra Ready
VAR-005	Add Purchase Order Line	Positive/Field	A new line added to the existing purchase order	Syntra Ready
VAR-006	Cancel Purchase Order Line	Positive/Field	An existing line cancelled on the purchase order	Syntra Ready
VAR-007	Change Purchase Order Terms	Positive/Field	Payment terms updated to a new valid term code	Syntra Ready
VAR-008	Change After Partial Receipt Where Allowed	Positive/Status	Change performed against a purchase order with a partial receipt already recorded	Syntra Ready
VAR-009	Purchase Order Closed	Negative/Status	Change attempted on a closed purchase order	Syntra Ready
VAR-010	Purchase Order Cancelled	Negative/Status	Change attempted on a cancelled purchase order	Syntra Ready
VAR-011	Invalid Account Entered	Negative/Field	New charge account entered is not a valid combination	Syntra Ready
VAR-012	Invalid Supplier Data Entered	Negative/Field	New supplier data entered is inactive or not configured	Syntra Ready
VAR-013	Unauthorized Change Attempt	Negative/Security	A user without change privileges attempts to modify the purchase order	Syntra Ready
VAR-014	Invalid Status for Change	Negative/Status	Change attempted while the purchase order is in a status not eligible for change	Syntra Ready
VAR-015	Invalid Effective Date Entered	Negative/Field	New effective or need-by date entered is outside a valid or open range	Syntra Ready

Automatically Expand Positive and Negative Change Purchase Order Coverage

Positive Testing

Jarvis generates scenarios using field values and status expected to successfully create a change order on an eligible purchase order while preserving version history and re-triggering approval where required.

Eligible Purchase Order + Valid New Ship-To + Change Before Full Receipt → Change Order Created and History Preserved

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's validations around purchase order status, field values and user authorization.

Closed Purchase Order → Expected Status Validation
Cancelled Purchase Order → Expected Status Validation
Invalid Account → Expected Account Validation
Invalid Supplier Data → Expected Supplier Validation
Unauthorized User → Expected Security Validation

A negative scenario passes when Oracle correctly enforces the expected business rule or validation.

Scenario	Oracle Outcome	Test Result
Valid PO	Purchase order created	PASS
Inactive supplier	Supplier validation occurs	PASS
Invalid account	Account validation occurs	PASS
Security restriction	Access prevented	PASS
Unexpected application exception	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

Users can select generated change-purchase-order scenarios and group them into reusable execution packs.

Change Purchase Order Regression Pack

Change Purchase Order Quantity
Change Purchase Order Price
Change Purchase Order Need-By Date
Change Purchase Order Ship-To
Add Purchase Order Line
Cancel Purchase Order Line
Change Purchase Order Terms
Change After Partial Receipt Where Allowed
Purchase Order Closed
Unauthorized Change Attempt

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 change-purchase-order scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.

Once scheduled, SyntraFlow executes the selected change-purchase-order scenarios unattended and records the outcome of each test and business assertion.

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

Pack	Change Purchase Order Regression Pack
Schedule	Quarterly Update Regression
Tests	15 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 scenario, its business steps, the underlying automation actions, and the evidence captured for each.

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

Security & Persona Variations

Change privileges for an existing purchase order are typically restricted by role. Jarvis can generate persona-based variations to confirm that only authorized users can change a purchase order, and that unauthorized attempts are correctly prevented rather than silently allowed.

Persona	Action	Expected	Syntra Result
Buyer	Change Own PO	Allowed	PASS
Unauthorized User	Attempts Change	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.

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 change-purchase-order scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary and Security coverage for the customer's environment.

Generate

Positive, Negative, Boundary and Security variations.

Parameterize

Use relevant test data from DataVault.

Assemble

Build reusable regression packs.

Execute

Run scenarios autonomously.

Schedule

Execute unattended test batches.

Validate

Evaluate expected business outcomes.

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 — Change Purchase Order, 9 Business Steps

↓

DataVault — Customer-Specific Test Data

↓

Jarvis AI — Generate Positive + Negative + Boundary + 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

Navigate to the Purchase Order

May internally include

Open PO Search → Enter PO Number → Search → Select Purchase Order → Confirm

Business Step

Verify Version and History Updated

May internally include

Open PO Change History → Read Prior Version → Read New Version → Compare Against Expected Change

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 does not automatically prove the change order was created or version history preserved — this is illustrative of how SyntraFlow separates action success from business validation; it does not reflect a specific live execution.

Step	Action Status	Business Validation
Modify the Target Field or Fields	Pass	—
Save the Changed Purchase Order	Pass	—
Verify Version and History Updated	Pass	Pass

Related Purchase Order Tests

Change Purchase Order applies to a PO that already exists within the same purchase order lifecycle — explore the related create, approve and cancel scenarios below.

Create Purchase Order Approve Purchase Order Cancel Purchase Order

Turn This Standard Test into Your Oracle Purchase Order Regression Suite

Start with the Syntra Standard change-purchase-order test, use DataVault to provide environment-specific test data, let Jarvis generate additional field, status and security variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Purchase Orders 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.

Related Oracle Testing Resources

Purchase Orders Test Library Procurement Test Library SCM Test Library Oracle ERP Testing Tool Test Library Syntra DataVault

Frequently Asked Questions

What changes are typically allowed to an existing Oracle Fusion purchase order?

Depending on PO status and customer configuration, allowed changes commonly include quantity, price, need-by date, ship-to, terms, and adding or cancelling a line. Availability of each change type depends on the customer's Oracle Fusion setup and the purchase order's current status.

What happens when a purchase order is changed after partial receipt?

Where the customer's configuration allows it, a change order can still be created against a partially received PO, but certain fields — such as reducing quantity below what has already been received — may be restricted. This test includes a variation for change after partial receipt where allowed.

Is reapproval always required after a purchase order change?

No, it depends on the customer's approval workflow configuration and which field was changed. Some changes to an already-approved purchase order trigger a new approval cycle, while others do not. This test verifies that reapproval behavior matches the configured expectation for the change performed.

How is unauthorized-user testing approached for purchase order changes?

Jarvis AI can generate a security variation where a user without change privileges attempts to modify a purchase order. The expected outcome is that Oracle Fusion correctly prevents the change, which counts as a passed negative test — see the Security & Persona Variations table on this page.

How are individual field-level changes such as quantity or price handled?

They are represented as data-driven rows in the Example Test Variations table on this same page rather than as separate published test pages, keeping a single canonical URL for all change-purchase-order variations.