Oracle ERP Testing Tool > Test Library > SCM > Procurement > Requisitions

Syntra Standard Oracle Test Library

Oracle Fusion Change Requisition Test Cases

Validate that an existing Oracle Fusion requisition can be changed within allowed limits — quantity, price, need-by date, deliver-to location, supplier or charge account — while the prior values remain visible in requisition history.

Test ID	ORCL.P2P.PROC.REQ.CHANGE
Application	Oracle Fusion Cloud
Product	SCM / Procurement
Module	Procurement
Process	Requisitions
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 21 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to validate that allowed changes to an existing requisition — such as quantity, price, need-by date, deliver-to location, supplier or charge account — are accepted, correctly applied, and preserved alongside the requisition's original values and audit history in Oracle Fusion Procurement.

The scenario should confirm that:

an eligible requisition can be opened for change by an authorized user
the target field or fields accept a valid new value without unexpected errors
the changed value is reflected accurately once the requisition is saved
the requisition's audit history retains a record of the change rather than silently overwriting it
approval is re-triggered where the customer's workflow configuration requires it
the requisition status remains correct and consistent with the change performed

This scenario covers changing an existing requisition within Oracle Fusion Procurement TEST/UAT environments. It does not cover initial requisition creation, which is covered by the separate Create Purchase Requisition scenario, or requisition cancellation, which is covered by the separate Cancel Requisition scenario. Individual field-level changes such as quantity, price or supplier 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 field-level changes for a new Oracle Fusion Procurement implementation
Regression testing of change and re-approval behavior after an Oracle quarterly update
UAT sign-off for requesters and buyers who routinely amend requisitions before or after approval
Baseline case referenced by the create, approve and cancel scenarios within the same requisition lifecycle

Where This Test Fits in the Requisition Lifecycle

Create

→

Change

→

Approve

→

Convert to Purchase Order

→

Cancel

Change Requisition applies to a requisition that already exists, adjusting one or more field values while keeping the requisition itself intact. It does not cover initial creation or cancellation, which are covered by earlier and later stages of the same requisition lifecycle. Exact allowed changes, timing restrictions and re-approval behavior depend on requisition status, customer workflow configuration and security setup.

← Previous Stage

Create Purchase Requisition

Next Stage →

Approve Requisition

Preconditions

A requisition exists and is in a status that is eligible for change.
The requester or authorized user performing the change has the appropriate change privileges.
The target values for the change — item, account, supplier or location — are valid and configured for the test tenant.
The test user has permission to open and edit requisitions in Oracle Fusion Procurement.

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

Sample Test Data

Business Unit	${BUSINESS_UNIT}
Requisition Number	${REQUISITION_NUMBER}
Current Requisition Status	${REQUISITION_STATUS}
New Quantity	${NEW_QUANTITY}
New Price	${NEW_PRICE}
New Need-By Date	${NEW_NEED_BY_DATE}
New Deliver-To Location	${NEW_DELIVER_TO_LOCATION}
New Supplier	${NEW_SUPPLIER}
New Charge Account	${NEW_CHARGE_ACCOUNT}

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 ~21 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.

#	User Action	Expected Result
1	Sign In and Navigate to Requisitions Sign in to Oracle Fusion using an authorized Procurement test user and navigate to the Requisitions work area.	The Requisitions work area opens successfully.
2	Locate the Existing Requisition Search for and open the requisition that is eligible for change. ${REQUISITION_NUMBER} This single business step replaces multiple technical actions such as opening requisition search, entering the requisition number, and selecting the result.	The correct requisition is located and its current status and values are displayed.
3	Open the Requisition for Editing Select the option to edit the located requisition.	The requisition 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, deliver-to location, supplier or charge account. ${NEW_QUANTITY} / ${NEW_PRICE} / ${NEW_NEED_BY_DATE} / ${NEW_DELIVER_TO_LOCATION} / ${NEW_SUPPLIER} / ${NEW_CHARGE_ACCOUNT}	The new value is accepted without unexpected validation errors.
5	Review Changed Values Before Saving Review the updated field values against the original values before saving the requisition. Reviewing the change before saving lets the tester catch an incorrect value entry before it is committed.	The changed values shown match the intended change for this variation.
6	Save the Changed Requisition Submit and save the change to the requisition in the test environment.	Oracle Fusion successfully saves the change without unexpected errors.
7	Verify Changes Are RetainedBusiness assertion Reopen or refresh the requisition and confirm the new field values are present. This is a primary business assertion for the scenario — a correctly retained change is the expected pass condition, not merely a successful save.	The requisition reflects the changed values accurately.
8	Verify Change History Is PreservedBusiness assertion Review the requisition's audit or history record for the change performed.	The prior value and the change are visible in the requisition's history rather than being silently overwritten.
9	Verify Re-Approval Triggered Where ConfiguredBusiness assertion Review the requisition's approval status after the change is saved.	Where the customer's workflow configuration requires it, re-approval is triggered and the requisition status reflects this correctly.

Expected Results

The target field or fields accept the new value without unexpected errors.
The changed value is reflected accurately once the requisition is saved.
The requisition's audit history retains a record of both the prior and new values.
Re-approval is triggered where the customer's workflow configuration requires it.
The requisition status remains correct and consistent with the change performed.
Unauthorized change attempts are correctly prevented.

Key Validation Checkpoints

Changed values are retained on the requisition.
Change history is preserved.
Approval is re-triggered where configured.
Requisition status is correct after the change.

Core Business Scenario

Change Requisition

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-requisition business scenario. Jarvis AI can extend this scenario by generating additional field, timing 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 requisition can change, or for every timing 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-requisition business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Requisitions, Items, Suppliers, Accounts, Locations and Approval Workflows.

Jarvis AI

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

Positive + Negative + Boundary + Security Test Variations

Valid field-change scenarios alongside edge cases such as restricted changes, 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 requisition can change, SyntraFlow maintains one core change-requisition scenario and allows Jarvis AI to generate field-driven, timing and security-specific variations using the customer's available test data.

AI-Generated Test Variations

The same Change Requisition 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 Requisitions.

Positive Scenarios

Change requisition quantity
Change requisition price
Change requisition need-by date
Change requisition deliver-to location
Change requisition supplier
Change requisition charge account
Add or remove a requisition line where allowed
Change requisition before approval
Change requisition after rejection

Negative Scenarios

Change an already converted requisition where restricted
Invalid quantity entered for the change
Invalid charge account entered for the change
Invalid supplier entered for the change
Invalid need-by date entered for the change
Unauthorized user attempts a 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 requisition, 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-requisition scenarios relevant to the customer's actual implementation.

Standard Library Definition

Business Unit        ${BUSINESS_UNIT}
Requisition Number    ${REQUISITION_NUMBER}
Current Status        ${REQUISITION_STATUS}
New Quantity          ${NEW_QUANTITY}
New Price             ${NEW_PRICE}
New Need-By Date      ${NEW_NEED_BY_DATE}
New Deliver-To        ${NEW_DELIVER_TO_LOCATION}
New Supplier          ${NEW_SUPPLIER}
New Charge Account    ${NEW_CHARGE_ACCOUNT}

DataVault

Requisitions
  Open and eligible-for-change requisitions
Items
  Active items with valid quantity/price ranges
Suppliers
  Active suppliers eligible for assignment
Charge Accounts
  Valid combinations per Business Unit
Deliver-To Locations
  Configured ship-to/deliver-to locations
Approval Workflow
  Re-approval rules per change type

Jarvis AI Generates

Scenario 01 — Requisition REQ-1001 + Change Quantity
Scenario 02 — Requisition REQ-1001 + Change Price
Scenario 03 — Requisition REQ-2004 + Change Supplier + Before Approval
Scenario 04 — Requisition REQ-2004 + Change Account + After Rejection
Scenario 05 — Invalid Charge 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 requisition, supplier, account and location remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Representative examples of change-requisition scenarios Jarvis can generate from this business scenario, spanning field, timing 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 Requisition Quantity	Positive/Field	Quantity updated to a new valid value	Syntra Ready
VAR-002	Change Requisition Price	Positive/Field	Price updated to a new valid value	Syntra Ready
VAR-003	Change Requisition Need-By Date	Positive/Field	Need-by date updated to a new valid date	Syntra Ready
VAR-004	Change Deliver-To Location	Positive/Field	Deliver-to location updated to a new configured location	Syntra Ready
VAR-005	Change Requisition Supplier	Positive/Field	Supplier updated to a new active supplier	Syntra Ready
VAR-006	Change Requisition Charge Account	Positive/Field	Charge account updated to a new valid account combination	Syntra Ready
VAR-007	Add Requisition Line Where Allowed	Positive/Field	A new line added to the existing requisition	Syntra Ready
VAR-008	Remove Requisition Line Where Allowed	Positive/Field	An existing line removed from the requisition	Syntra Ready
VAR-009	Change Requisition Before Approval	Positive/Timing	Change performed while the requisition is still pending approval	Syntra Ready
VAR-010	Change Requisition After Rejection	Positive/Timing	Change performed after the requisition was rejected, ahead of resubmission	Syntra Ready
VAR-011	Change Already Converted Requisition	Negative	Change attempted on a requisition already converted to a purchase order, where restricted	Syntra Ready
VAR-012	Invalid Quantity Entered	Negative/Field	New quantity entered outside a valid range	Syntra Ready
VAR-013	Invalid Charge Account Entered	Negative/Field	New charge account entered is not a valid combination	Syntra Ready
VAR-014	Invalid Supplier Entered	Negative/Field	New supplier entered is inactive or not configured	Syntra Ready
VAR-015	Invalid Need-By Date Entered	Negative/Field	New need-by date entered is outside a valid or open range	Syntra Ready
VAR-016	Unauthorized User Attempts Change	Negative/Security	A user without change privileges attempts to modify the requisition	Syntra Ready

Automatically Expand Positive and Negative Change Requisition Coverage

Positive Testing

Jarvis generates scenarios using field values and timing expected to successfully change an eligible requisition while preserving its audit history and re-triggering approval where required.

Eligible Requisition + Valid New Charge Account + Change Before Approval → Requisition Updated and History Preserved

Negative Testing

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

Already Converted Requisition → Expected Restriction Validation
Invalid Quantity → Expected Field Validation
Invalid Charge Account → Expected Account Validation
Invalid Supplier → 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 requisition	Requisition created	PASS
Inactive item	Item 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-requisition scenarios and group them into reusable execution packs.

Change Requisition Regression Pack

Change Requisition Quantity
Change Requisition Price
Change Requisition Need-By Date
Change Deliver-To Location
Change Requisition Supplier
Change Requisition Charge Account
Change Requisition Before Approval
Change Requisition After Rejection
Change Already Converted Requisition
Unauthorized User Attempts Change

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

Once scheduled, SyntraFlow executes the selected change-requisition 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 Requisition Regression Pack
Schedule	Quarterly Update Regression
Tests	16 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 requisition are typically restricted by role. Jarvis can generate persona-based variations to confirm that only authorized users can change a requisition, and that unauthorized attempts are correctly prevented rather than silently allowed.

Persona	Action	Expected	Syntra Result
Requester	Change Own Requisition	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-requisition 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 Requisition, 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

Locate the Existing Requisition

May internally include

Open Requisition Search → Enter Requisition Number → Search → Select Requisition → Confirm

Business Step

Verify Change History Is Preserved

May internally include

Open Requisition History → Read Prior Value → Read New Value → 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 was retained or 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 Requisition	Pass	—
Verify Change History Is Preserved	Pass	Pass

Related Requisition Tests

Change Requisition applies to a requisition that already exists within the same requisition lifecycle — explore the related create, approve and cancel scenarios below.

Create Purchase Requisition Approve Requisition Cancel Requisition

Turn This Standard Test into Your Oracle Requisition Regression Suite

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

Automate with SyntraFlow Explore Requisitions 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

Requisitions 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 requisition?

Depending on requisition status and customer configuration, allowed changes commonly include quantity, price, need-by date, deliver-to location, supplier and charge account, along with adding or removing a line where permitted. Availability of each change type depends on the customer's Oracle Fusion setup and the requisition's current status.

Is the requisition's change history preserved when a value is updated?

Yes. This test specifically validates that the prior value and the change performed remain visible in the requisition's audit or history record rather than being silently overwritten.

Does changing a requisition always trigger re-approval?

It depends on the customer's approval workflow configuration. Some changes to an already-approved requisition trigger a new approval cycle, while others do not. This test verifies that re-approval behavior matches the configured expectation for the change performed.

How is unauthorized-user testing approached for requisition changes?

Jarvis AI can generate a security variation where a user without change privileges attempts to modify a requisition. 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 supplier 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-requisition variations.