Oracle ERP Testing Tool > Test Library > SCM > Order Management > Returns

Syntra Standard Oracle Test Library

Oracle Fusion Create Return Order Test Cases

Validate that a customer return order can be created in Oracle Fusion SCM Order Management by referencing a previously shipped sales order, with correct return reason, quantity and disposition captured on the new return order.

Test ID	ORCL.O2C.OM.RET.CREATE
Application	Oracle Fusion Cloud
Product	SCM / Order Management
Module	Order Management
Process	Returns
Business Flow	Order-to-Cash
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 8 business-readable test steps; SyntraFlow's automation executes approximately 20 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to verify that an authorised Order Management user can create a return order that references a previously shipped sales order, with correct return reason, quantity and disposition recorded on the new return order.

The scenario should confirm that:

the return order correctly references a valid, previously shipped original sales order and item
the return reason is accepted
the return quantity does not exceed the quantity originally shipped on the referenced order
the disposition, such as return-to-stock or scrap/inspect, is correctly recorded
the return order receives a system-generated order number and correct status
the return order is available for downstream receipt processing
Oracle correctly enforces validation when data errors, configuration errors or security restrictions are introduced (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION)

This scenario covers creation of a customer return order that references a previously shipped sales order in Oracle Fusion SCM Order Management TEST/UAT environments. It does not cover physical receipt of the returned goods against the return order, which is covered by the separate Receive Return scenario in the same Returns cluster.

When to Use This Test

Functional testing of return order creation for a new Oracle Fusion SCM Order Management implementation
Regression testing of return order creation behavior after an Oracle quarterly update
UAT sign-off for customer service representatives who process customer returns
Baseline case referenced by the Receive Return and Return Order Exceptions scenarios within the same Returns cluster
Diagnosing DATA_ERROR, CONFIGURATION_ERROR and SECURITY_ERROR conditions surfaced during return order creation before escalating as a possible APPLICATION_ERROR

Where This Test Fits in the Order-to-Cash Returns Process

Original Order Shipped

→

Customer Requests Return

→

Locate Original Order

→

Create Return Order

→

Enter Return Details

→

Review and Submit

→

Return Order Available for Receipt

Create Return Order is the entry point of the Returns scenario family within Order-to-Cash. Once a return order is created, the returned goods are typically received against it — covered by the Receive Return scenario in this same cluster. Exact fields available, return eligibility rules and disposition options depend on order management setup, return policy configuration and customer-specific Oracle Fusion configuration.

Next Stage →

Receive Return

Preconditions

The original sales order exists and has been shipped in Oracle Fusion SCM Order Management.
The item being returned is eligible for return per the customer's configured return policy.
Return reason codes required for the return are configured.
The test user has appropriate access to create return orders in Oracle Fusion Order Management.

Exact return eligibility rules, return reasons, disposition options and field availability may vary by Oracle Fusion implementation, return policy configuration, and customer-specific configuration.

Sample Test Data

Business Unit	${BUSINESS_UNIT}
Original Order Number	${ORIGINAL_ORDER_NUMBER}
Customer	${CUSTOMER}
Item	${ITEM}
Originally Shipped Quantity	${SHIPPED_QUANTITY}
Return Quantity	${RETURN_QUANTITY}
Return Reason	${RETURN_REASON}
Disposition	${DISPOSITION}
Return Date	${RETURN_DATE}

Sample values are illustrative placeholder tokens. Replace them with valid data from the target Oracle Fusion SCM TEST/UAT environment. Not every field applies to every return — for example, business unit may be inherited from the original order rather than requiring re-entry.

Test Steps

8 business-readable steps. SyntraFlow's automation executes ~20 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 Order Management as an authorised customer service test user.	Oracle Fusion opens successfully for the test user.
2	Navigate to Order Management Navigate to the Order Management work area to begin processing a customer return. ${BUSINESS_UNIT}	The Order Management work area opens successfully for the correct business unit.
3	Locate the Original Shipped Order Search for and open the previously shipped sales order the customer is returning against. ${ORIGINAL_ORDER_NUMBER} / ${CUSTOMER} This single business step replaces multiple technical actions such as opening order search, entering search criteria, and opening the located result.	The correct original order is located and its shipped item and quantity detail are displayed.
4	Initiate Create Return Order Initiate a return order from the located original order.	A new return order is opened and pre-populated with the original order and item reference.
5	Enter Return Quantity and Reason Enter the quantity being returned for the item and select the return reason. ${ITEM} / ${RETURN_QUANTITY} / ${RETURN_REASON}	The return quantity and reason are accepted without unexpected validation errors.
6	Select Disposition Select the disposition for the returned item, such as return-to-stock or scrap/inspect. ${DISPOSITION}	The disposition is accepted and reflected on the return order line.
7	Review and Submit the Return Order Review the complete return order, including original order reference, item, quantity, reason and disposition, then submit it. Reviewing the return order before submission lets the tester catch an incorrect quantity, reason or disposition before the return order is created.	Oracle Fusion processes the return order request without unexpected errors.
8	Verify Return Order Created and Correctly Referencing the Original OrderBusiness assertion Confirm that the return order is created with a system-generated number, correctly references the original order and item, and is available for downstream receipt processing. This is the primary business assertion for the scenario — a correctly created return order that traces back to the original shipped order is the expected pass condition, not merely a successful save. Physical receipt of the returned goods is covered separately by the Receive Return scenario.	A return order number is generated, the return order correctly references the original order and item, return quantity and disposition match the entered data, and the return order is available for receipt.

Expected Results

A return order is created successfully for the correct business unit and customer.
A system-generated return order number is assigned.
The return order correctly references the original shipped sales order and item.
Return quantity does not exceed the quantity originally shipped.
The return reason and disposition are correctly retained on the return order.
The return order status correctly reflects a newly created return order.
No unexpected save errors occur.
The return order is available for downstream receipt processing.

Key Validation Checkpoints

Return order correctly references the original order and item.
Return quantity does not exceed the shipped quantity.
Disposition is correctly recorded.
Return order is available for downstream receipt processing.

Core Business Scenario

Create Return 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 Create Return Order business scenario. Jarvis AI can extend this scenario by generating additional quantity, reason, disposition 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 combination of original order, quantity, reason and disposition. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative, Quantity and Disposition variations for the customer's environment — including return quantities that exceed what was originally shipped, since correctly enforced validation at the edges of expected values is an important part of what this scenario proves.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable Create Return Order business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — shipped orders, customers, items and return reasons.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant quantity, reason, disposition and security variations.

Positive + Negative Test Variations

Valid return order scenarios and edge cases such as over-quantity returns, ineligible items or missing reasons.

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 possible original order, quantity, reason or disposition combination, SyntraFlow maintains one core Create Return Order scenario and allows Jarvis AI to generate quantity, reason, disposition and security-specific variations using the customer's available test data.

AI-Generated Test Variations

The same Create Return 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 Order Management Returns.

Positive Scenarios

Create a standard full-quantity return referencing the original shipped order
Create a partial-quantity return against the original order
Create a return with a documented, valid reason code
Create a return with disposition set to return-to-stock
Create a return with disposition set to scrap/inspect

Negative Scenarios

Attempt to return a quantity greater than the originally shipped quantity
Attempt to create a return referencing an invalid or nonexistent original order
Attempt to return an item that is not eligible for return per policy
Attempt to submit a return with a missing required return reason
Unauthorized user attempts to create a return order
Attempt to create a return outside the configured return window

These are representative examples only. Negative-scenario behavior and available field combinations can depend on the customer's Oracle Fusion configuration, return policy, controls and security — not every Oracle configuration behaves identically.

Generated Using Your DataVault Test Data

Generic test data rarely represents every shipped order, item, quantity, reason and disposition combination in a real Oracle Fusion SCM environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Create Return Order scenarios relevant to the customer's actual implementation.

Standard Library Definition

Business Unit              ${BUSINESS_UNIT}
Original Order Number       ${ORIGINAL_ORDER_NUMBER}
Customer                    ${CUSTOMER}
Item                        ${ITEM}
Return Quantity              ${RETURN_QUANTITY}
Return Reason                ${RETURN_REASON}
Disposition                  ${DISPOSITION}

DataVault

Shipped Orders
  Order A — Fully Shipped, No Prior Return
  Order B — Partially Returned
  Order C — Return Window Expired
  Order D — Item Not Return-Eligible
Items
  Item X, Item Y, Item Z
Return Reasons
  Damaged in Transit, Wrong Item Shipped, Customer Changed Mind, Quality Issue

Jarvis AI Generates

Scenario 01 — Order A + Full Return + Damaged in Transit
Scenario 02 — Order A + Partial Return + Wrong Item Shipped
Scenario 03 — Order B + Additional Partial Return + Quality Issue
Scenario 04 — Return Quantity Exceeds Shipped Quantity (Negative)
Scenario 05 — Return Against Invalid Order (Negative)
Scenario 06 — Return Against Order D, Item Not Eligible (Negative)
Scenario 07 — Return Against Order C, Outside Return Window (Negative)
...

Create Return Order test data can include sensitive customer and order information. The public Syntra Standard Test Library uses illustrative placeholder data only. Where DataVault is connected, customer-specific order management dimensions remain within the customer's controlled SyntraFlow environment and access model, protected according to DataVault's data masking policies. See /datavault/ for details.

Example Test Variations

Representative examples of Create Return Order scenarios Jarvis can generate from this business scenario, spanning quantity, reason and disposition 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	Standard Full-Quantity Return	Positive/Quantity	Return quantity equals full originally shipped quantity	Syntra Ready
VAR-002	Partial-Quantity Return	Positive/Quantity	Return quantity is less than originally shipped quantity	Syntra Ready
VAR-003	Return With Documented Reason Code	Positive	Return submitted with a valid, documented return reason	Syntra Ready
VAR-004	Disposition: Return-to-Stock	Positive/Disposition	Disposition set to return-to-stock	Syntra Ready
VAR-005	Disposition: Scrap/Inspect	Positive/Disposition	Disposition set to scrap/inspect	Syntra Ready
VAR-006	Additional Partial Return on Same Order	Positive/Quantity	Second partial return submitted against remaining shipped quantity	Syntra Ready
VAR-007	Return Quantity Exceeds Shipped Quantity	Negative/Quantity	Return quantity entered greater than originally shipped quantity	Syntra Ready
VAR-008	Return Against Invalid Original Order	Negative	Original order number does not correspond to a valid, shipped order	Syntra Ready
VAR-009	Item Not Return-Eligible	Negative	Selected item is excluded from return per configured policy	Syntra Ready
VAR-010	Missing Required Return Reason	Negative	Required return reason left blank	Syntra Ready
VAR-011	Unauthorized User Attempts Return Creation	Negative	User lacks return-creation privilege/security	Syntra Ready
VAR-012	Return Attempted Outside Return Window	Negative	Return initiated after the configured return window has elapsed	Syntra Ready

Automatically Expand Positive and Negative Return Order Coverage

Positive Testing

Jarvis generates scenarios using original order, quantity, reason and disposition combinations expected to successfully create a return order in Oracle Fusion.

Valid Shipped Order + Eligible Item + Valid Return Quantity + Valid Return Reason → Return Order Created

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's return eligibility rules, quantity validations, return window enforcement and security around return order creation.

Return Quantity Exceeds Shipped Quantity → Expected Quantity Validation
Invalid Original Order → Expected Reference Validation
Item Not Return-Eligible → Expected Eligibility Validation
Missing Return Reason → Expected Required Field Validation
Unauthorized User → Expected Access Restriction

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

Scenario	Oracle Outcome	Test Result
Valid return order	Return created	PASS
Quantity exceeds shipped	Validation occurs	PASS
Item not return-eligible	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 Create Return Order scenarios and group them into reusable execution packs.

SCM Order Management Create Return Order Regression Pack

Standard Full-Quantity Return
Partial-Quantity Return
Return With Documented Reason Code
Disposition: Return-to-Stock
Disposition: Scrap/Inspect
Additional Partial Return on Same Order
Return Quantity Exceeds Shipped Quantity
Return Against Invalid Original Order
Item Not Return-Eligible
Return Attempted Outside Return Window

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

Once scheduled, SyntraFlow executes the selected Create Return 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	SCM Order Management Create Return Order Regression Pack
Schedule	Quarterly Update Regression
Tests	13 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

Access to create a return order is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that return-order-creation access behaves as expected for each role — not to assert a single universal Oracle security model.

Persona	Action	Expected	Syntra Result
Customer Service Representative	Create Return Order	Allowed	PASS
Unauthorized User	Attempts Return Creation	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 Create Return Order scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Quantity and Disposition coverage — including return quantities that exceed what was shipped — for the customer's environment.

Generate

Positive and negative 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 — Create Return Order, 8 Business Steps

↓

DataVault — Customer-Specific Test Data

↓

Jarvis AI — Generate Positive + Negative 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 Original Shipped Order

May internally include

Open Order Search → Enter Search Criteria → Open Result → Read Shipped Item/Quantity

Business Step

Select Disposition

May internally include

Open Disposition List of Values → Select Disposition → Confirm Selection

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 return order was created correctly — this is illustrative of how SyntraFlow separates action success from business validation; 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, AUTOMATION_ERROR, INTEGRATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: Create Return Order failed — Likely category: EXPECTED_VALIDATION — Evidence: return quantity exceeds the quantity originally shipped on the referenced order — Recommended action: this is expected behavior; correct the return quantity to match the eligible shipped amount. A failure should never be labeled as an Oracle defect without supporting evidence.

Step	Action Status	Business Validation
Enter Return Quantity and Reason	Pass	—
Click Submit	Pass	—
Verify Return Order Created and Correctly Referencing the Original Order	Pass	Pass

Related Returns Tests

Create Return Order is the entry point of the Returns cluster — explore the related receipt, exception and inquiry scenarios below.

Receive Return Return Order Exceptions Order Inquiry

Turn This Standard Test into Your Oracle SCM Create Return Order Regression Suite

Start with the Syntra Standard Create Return Order test, use DataVault to provide environment-specific test data, let Jarvis generate additional quantity, reason and disposition variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Order Management Returns 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

Oracle ERP Testing Tool Test Library SCM Test Library Order Management Test Library Returns Test Library Syntra DataVault

Frequently Asked Questions

What makes previously shipped goods eligible for a return order in Oracle Fusion?

Eligibility depends on the customer's configured return policy — typically the item must have been shipped on a valid original order and not already fully returned or otherwise excluded from return. Exact eligibility rules depend on the customer's Oracle Fusion configuration.

What disposition options are available when creating a return order?

Common dispositions include return-to-stock, where the item is expected back into saleable inventory, and scrap/inspect, where the item requires quality inspection before any inventory action. Available disposition values depend on the customer's configured return reasons and inventory setup.

How is a return window enforced when creating a return order?

Where configured, Oracle Fusion can restrict returns to a defined window measured from the original shipment or order date. This scenario includes a negative variation for a return attempted outside the configured return window; exact enforcement depends on customer-specific return policy configuration.

How is security tested for the create return order scenario?

Security testing verifies that a user with appropriate access, such as a Customer Service Representative, can create a return order, while a user without that access is correctly prevented from doing so. Both outcomes are treated as passing test results when Oracle behaves as expected.

Does this test create real customer returns or process real refunds?

No. This is test automation executed against Oracle Fusion TEST/UAT environments only. It does not create real customer returns, process real refunds, or perform any financial transaction in a production environment.