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

Syntra Standard Oracle Test Library

Oracle Fusion Change Ship-To Test Cases

Validate that the ship-to address on an existing sales order line can be changed correctly in Oracle Fusion SCM Order Management, and that tax jurisdiction and fulfillment sourcing are correctly re-evaluated for the new ship-to address.

Test ID	ORCL.O2C.OM.CHG.SHIPTO
Application	Oracle Fusion Cloud
Product	SCM / Order Management
Module	Order Management
Process	Order Changes
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 22 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to validate that the ship-to address on an existing, submitted sales order line can be changed in Oracle Fusion SCM Order Management, and that tax jurisdiction and fulfillment/warehouse sourcing downstream of the ship-to address are correctly re-evaluated as a result.

The scenario should confirm that:

the ship-to address on the order line is updated to the newly selected address or customer site
tax is correctly re-determined for the new ship-to address, based on the tax configuration in the target environment
fulfillment/warehouse sourcing is re-evaluated where the ship-to change affects the applicable sourcing rule
a change history / audit trail entry is recorded for the ship-to change
Oracle correctly enforces validation when an invalid, unregistered or unsupported ship-to address is used, or when a change is attempted on a shipped line, under a security restriction or against an active hold

This scenario covers changing the ship-to address on a single existing sales order line in Oracle Fusion SCM Order Management TEST/UAT environments, both before and after the line has been scheduled. It does not cover the separate Change Order Quantity and Change Requested Date scenarios in the same Order Changes cluster, and it does not assert coverage of every possible tax jurisdiction — line-level tax calculation itself is covered in more depth by the related Create Order With Tax scenario.

When to Use This Test

Functional testing of ship-to address changes on existing sales order lines for a new Oracle Fusion SCM Order Management implementation
Regression testing of ship-to change behavior, including tax re-determination and fulfillment re-sourcing, after a configuration change or Oracle quarterly update
UAT sign-off for order entry specialists who routinely correct or update customer ship-to addresses on submitted orders
Baseline case referenced alongside Change Order Quantity, Change Requested Date and Create Order With Tax within the same Order-to-Cash flow
Diagnosing CONFIGURATION_ERROR and DATA_ERROR conditions when tax or fulfillment sourcing fails to re-evaluate as expected after a ship-to change, before escalating as a possible APPLICATION_ERROR

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

Navigate to Order Management

→

Locate Order

→

Select Line

→

Select New Ship-To

→

Re-determine Tax

→

Re-evaluate Fulfillment

→

Submit Change

Change Ship-To is one of several Order Changes scenarios that modify an existing, already-submitted sales order line, alongside Change Order Quantity and Change Requested Date. Because the ship-to address can drive both tax jurisdiction determination and fulfillment warehouse sourcing, this scenario also touches the tax re-determination logic covered in more depth by the Create Order With Tax scenario in the Sales Orders cluster. Exact re-evaluation behavior depends on tax configuration, sourcing rules and customer-specific Oracle Fusion configuration.

← Previous Stage

Change Requested Date

Preconditions

An existing, submitted sales order line is present in the target Oracle Fusion SCM Order Management environment.
An alternate valid ship-to address or customer site is available and associated with the customer account.
For post-scheduling scenarios, the order line has already been scheduled against the original ship-to address.
The order entry test user has appropriate access to change the ship-to address on the order line.
Tax and fulfillment sourcing configuration relevant to both the original and new ship-to address is present in the target environment.

Exact field availability, re-scheduling behavior and validation messages may vary by Oracle Fusion implementation, tax configuration, fulfillment sourcing rules and customer-specific configuration. Not every ship-to change re-triggers scheduling or sourcing — behavior depends on how far the line has progressed.

Sample Test Data

Order Number	${ORDER_NUMBER}
Customer	${CUSTOMER}
Item	${ITEM}
Original Ship-To	${ORIGINAL_SHIP_TO}
New Ship-To	${NEW_SHIP_TO}
Line Status	${LINE_STATUS}
Tax Jurisdiction	${TAX_JURISDICTION}
Fulfillment Warehouse	${FULFILLMENT_WAREHOUSE}

Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion SCM TEST/UAT environment. Not every field applies to every scenario — for example, a pre-scheduling ship-to change may not exercise fulfillment re-sourcing in the same way as a post-scheduling change.

Test Steps

8 business-readable steps. SyntraFlow's automation executes ~22 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 authorised order entry test user.	The test user is signed in successfully.
2	Navigate to Order Management Navigate to the Order Management work area.	The Order Management work area opens successfully.
3	Locate the Sales Order Search for and open the existing sales order to be changed. ${ORDER_NUMBER}	The correct sales order opens, showing its current lines and status.
4	Select the Order Line to Change Select the order line whose ship-to address is to be changed. ${ITEM} / ${LINE_STATUS}	The correct order line is selected, showing its current ship-to address.
5	Select the New Ship-To Address Select the alternate valid ship-to address or customer site for the order line. ${ORIGINAL_SHIP_TO} / ${NEW_SHIP_TO}	The new ship-to address is accepted and reflected on the line as a pending change.
6	Review Tax and Fulfillment Impact Review the tax jurisdiction and fulfillment warehouse Oracle Fusion recalculates for the new ship-to address before submitting the change. ${TAX_JURISDICTION} / ${FULFILLMENT_WAREHOUSE} Reviewing the recalculated impact before submitting lets the tester catch an unintended tax or sourcing consequence before the change is committed.	The previewed tax jurisdiction and fulfillment warehouse reflect the newly selected ship-to address.
7	Submit the Ship-To Change Submit the ship-to change for the order line.	Oracle Fusion successfully processes the ship-to change without unexpected errors.
8	Verify Updated Ship-To and Recalculated TaxBusiness assertion Reopen or refresh the order line and confirm the ship-to address, recalculated tax and fulfillment warehouse, and that a change history entry was recorded. This is the primary business assertion for the scenario — a correctly updated ship-to with accurate downstream tax and fulfillment re-evaluation is the expected pass condition, not merely a successful save.	The order line reflects the updated ship-to address, correctly re-determined tax, re-evaluated fulfillment sourcing where applicable, and a recorded change history entry.

Expected Results

The ship-to address on the order line is updated to the selected new address or customer site.
Tax is correctly re-determined for the new ship-to address, based on the tax configuration in the target environment.
Fulfillment/warehouse sourcing is re-evaluated where the ship-to change affects the applicable sourcing rule.
The change is recorded in the order line's change history / audit trail.
Lines already scheduled against the original ship-to reflect the change consistently after resubmission.
Oracle correctly rejects or blocks the change where the new ship-to is invalid, unregistered, unsupported or conflicts with an active hold.

Key Validation Checkpoints

Ship-to updated correctly on the line.
Tax correctly re-determined for the new ship-to, based on configuration.
Fulfillment sourcing re-evaluated where applicable.
Change history / audit trail recorded.

Core Business Scenario

Change Ship-To

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 Ship-To business scenario. Jarvis AI can extend this scenario by generating additional customer site, tax jurisdiction, fulfillment sourcing, 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 ship-to address, jurisdiction or scheduling-state combination. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative, Tax Impact and Timing variations for the customer's environment — including changes made before versus after scheduling and changes that land in a jurisdiction with no configured tax rule, since correctly enforced re-evaluation is an important part of what this scenario proves.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable Change Ship-To business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Orders, Customers, Ship-to Addresses, Tax Jurisdictions and Fulfillment Warehouses.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant ship-to, tax jurisdiction, fulfillment sourcing and timing variations.

Positive + Negative Test Variations

Valid ship-to change scenarios and edge cases such as invalid addresses, shipped lines or unsupported jurisdictions.

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 ship-to address, tax jurisdiction, fulfillment warehouse or scheduling-state combination, SyntraFlow maintains one core Change Ship-To scenario and allows Jarvis AI to generate ship-to, tax impact and timing-specific variations using the customer's available test data.

AI-Generated Test Variations

The same Change Ship-To 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 Order Changes.

Positive Scenarios

Change to another valid customer site before scheduling
Change to another valid customer site after scheduling
Change triggering tax re-determination
Change triggering fulfillment warehouse re-sourcing
Change on one line among several

Negative Scenarios

Attempt to change to an invalid or unregistered ship-to address
Attempt to change the ship-to on a line that has already shipped
Attempt to select a ship-to address not associated with the customer account
Attempt the change as an unauthorized user
Attempt a change that conflicts with an active hold
Attempt a ship-to change into an unsupported jurisdiction

These are representative examples only. Ship-to change behavior, tax re-determination and fulfillment re-sourcing 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 ship-to address, tax jurisdiction and fulfillment sourcing combination in a real Oracle Fusion SCM environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Change Ship-To scenarios relevant to the customer's actual implementation.

Standard Library Definition

Order Number            ${ORDER_NUMBER}
Customer                ${CUSTOMER}
Item                    ${ITEM}
Original Ship-To        ${ORIGINAL_SHIP_TO}
New Ship-To             ${NEW_SHIP_TO}
Line Status             ${LINE_STATUS}
Tax Jurisdiction        ${TAX_JURISDICTION}
Fulfillment Warehouse   ${FULFILLMENT_WAREHOUSE}

DataVault

Customers / Ship-to Addresses
  Active customer sites and registered ship-to addresses
Orders
  Existing submitted orders at varying line statuses
Tax Rules
  Configured tax regimes, rules and rates per jurisdiction
Sourcing Rules
  Configured warehouse/fulfillment sourcing by ship-to region
Holds
  Active order and customer holds

Jarvis AI Generates

Scenario 01 — Change to Alternate Site Before Scheduling
Scenario 02 — Change to Alternate Site After Scheduling
Scenario 03 — Change Triggers Tax Re-Determination
Scenario 04 — Change Triggers Fulfillment Re-Sourcing
Scenario 05 — Invalid Ship-To Address
Scenario 06 — Unauthorized User Attempts Change
...

Change Ship-To test data can include sensitive commercial categories such as customer, address and order information. The public Syntra Standard Test Library uses illustrative placeholder data only. Where DataVault is connected, customer-specific ship-to and order 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 Change Ship-To scenarios Jarvis can generate from this business scenario, spanning ship-to, tax impact and timing 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 to Another Valid Site Before Scheduling	Positive/Timing	Ship-to changed on a line before it has been scheduled	Syntra Ready
VAR-002	Change to Another Valid Site After Scheduling	Positive/Timing	Ship-to changed on a line already scheduled against the original address	Syntra Ready
VAR-003	Change Triggering Tax Re-Determination	Positive/Tax Impact	New ship-to maps to a different configured tax jurisdiction	Syntra Ready
VAR-004	Change Triggering Fulfillment Re-Sourcing	Positive	New ship-to changes the applicable fulfillment warehouse sourcing rule	Syntra Ready
VAR-005	Change on One Line Among Several	Positive	Ship-to changed on a single line while other order lines are unaffected	Syntra Ready
VAR-006	Invalid or Unregistered Ship-To Address	Negative	Selected ship-to address is invalid or not registered	Syntra Ready
VAR-007	Change Attempted on a Shipped Line	Negative/Timing	Ship-to change attempted on a line that has already shipped	Syntra Ready
VAR-008	Ship-To Not Associated with Customer Account	Negative	Selected ship-to is not associated with the order's customer account	Syntra Ready
VAR-009	Unauthorized User Attempts Change	Negative	Requesting user lacks access to change the ship-to on the order line	Syntra Ready
VAR-010	Change Conflicts with Active Hold	Negative	Order or customer has an active hold preventing the change	Syntra Ready
VAR-011	Change to Unsupported Jurisdiction	Negative/Tax Impact	New ship-to maps to a jurisdiction with no configured tax rule	Syntra Ready

Automatically Expand Positive and Negative Ship-To Change Coverage

Positive Testing

Jarvis generates scenarios using valid customer sites, scheduling states and tax/fulfillment configurations expected to successfully change the ship-to address on an order line in Oracle Fusion.

Valid Order Line + Alternate Registered Customer Site → Ship-To Updated, Tax and Fulfillment Re-Evaluated

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's validations around address registration, line status, account association, holds and security.

Invalid/Unregistered Ship-To → Expected Address Validation
Shipped Line → Expected Line-Status Validation
Ship-To Not on Customer Account → Expected Association Validation
Active Hold → Expected Hold Enforcement
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 order change	Change applied	PASS
Invalid quantity	Validation occurs	PASS
Change conflicts with hold	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 Ship-To scenarios and group them into reusable execution packs.

SCM Order Management Change Ship-To Regression Pack

Change to Another Valid Site Before Scheduling
Change to Another Valid Site After Scheduling
Change Triggering Tax Re-Determination
Change Triggering Fulfillment Re-Sourcing
Change on One Line Among Several
Invalid or Unregistered Ship-To Address
Change Attempted on a Shipped Line
Ship-To Not Associated with Customer Account
Change Conflicts with Active Hold
Change to Unsupported Jurisdiction

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

Once scheduled, SyntraFlow executes the selected Change Ship-To scenarios unattended and records the outcome of each test and business assertion.

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

Pack	SCM Order Management Change Ship-To Regression Pack
Schedule	Quarterly Update Regression
Tests	11 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 & Approval Variations

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

Persona	Action	Expected	Syntra Result
Order Entry Specialist	Change Ship-To	Allowed	PASS
Unauthorized User	Attempts Order 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 Ship-To scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Tax Impact and Timing coverage — including pre- and post-scheduling changes and changes into jurisdictions with no configured tax rule — 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 — Change Ship-To, 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

Review Tax and Fulfillment Impact

May internally include

Open Ship-To Change Preview → Read Recalculated Tax Jurisdiction → Read Recalculated Fulfillment Warehouse → Compare Against Original Values

Business Step

Verify Updated Ship-To and Recalculated Tax

May internally include

Reopen Order Line → Read Ship-To Address → Read Tax Amount → Read Fulfillment Warehouse → Open Change History → Confirm Audit Entry

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 ship-to change, tax re-determination and fulfillment re-sourcing were all applied 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 across categories such as DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, AUTOMATION_ERROR, INTEGRATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: Change Ship-To failed — Likely category: CONFIGURATION_ERROR — Evidence: no tax rule is configured for the new ship-to jurisdiction — Recommended action: verify tax configuration for the new jurisdiction before re-running the test. A failure should never be labeled as an Oracle defect without supporting evidence.

Step	Action Status	Business Validation
Select the New Ship-To Address	Pass	—
Submit the Ship-To Change	Pass	—
Verify Updated Ship-To and Recalculated Tax	Pass	Pass

Related Order Change Tests

Change Ship-To is part of the Order Changes cluster — explore the related quantity, date and tax scenarios below.

Change Order Quantity Change Requested Date Create Order With Tax

Turn This Standard Test into Your Oracle SCM Change Ship-To Regression Suite

Start with the Syntra Standard Change Ship-To test, use DataVault to provide environment-specific customer, address and tax configuration data, let Jarvis generate additional jurisdiction, sourcing and security variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Order Management Order Changes 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 Order Changes Test Library Syntra DataVault

Frequently Asked Questions

What does this test validate on a ship-to change?

This test validates that the ship-to address on an existing sales order line can be changed to another valid customer site, and that the line correctly reflects the new address along with downstream tax and fulfillment sourcing re-evaluation and a recorded change history entry.

How does tax re-determination work when the ship-to address changes?

Changing the ship-to address on an order line can change the tax jurisdiction Oracle Fusion uses to calculate tax, since jurisdiction determination is typically driven by the ship-to address together with customer and item tax classifications. This test confirms tax is re-determined using whatever tax configuration is present in the target environment — see the related Create Order With Tax scenario for line-level tax calculation detail.

Does this test support ship-to changes into every tax jurisdiction?

No. This test validates that tax and fulfillment sourcing are re-evaluated based on whatever jurisdictions, tax rules and sourcing configuration are present in the customer's Oracle Fusion environment. It does not claim universal coverage of every tax jurisdiction, and includes a representative negative scenario for a ship-to change into an unsupported jurisdiction.

What happens if the order line has already been scheduled against the original ship-to address?

This scenario includes a representative post-scheduling variation to confirm how Oracle Fusion handles a ship-to change once a line has already been scheduled — behavior can include re-scheduling or re-sourcing depending on customer configuration, so results should be interpreted against the target environment's setup rather than assumed.

How does security testing work for changing the ship-to address?

Access to change the ship-to address on a sales order line is controlled by Oracle Fusion's security configuration, which varies by customer. SyntraFlow can execute representative persona-based variations — such as an order entry specialist versus an unauthorized user — to confirm that access behaves as expected, without asserting a single universal Oracle security model.