Oracle ERP Testing Tool > Test Library > SCM > Inventory Management > Transfers

Syntra Standard Oracle Test Library

Oracle Fusion Ship Transfer Order Test Cases

Validate that a previously created transfer order can be shipped correctly out of the source organization in Oracle Fusion SCM, using a valid ship quantity, ship method and ship date, and confirming that source on-hand and order status update correctly.

Test ID	ORCL.SCM.INV.XFER.SHIP
Application	Oracle Fusion Cloud
Product	SCM / Inventory Management
Module	Inventory Management
Process	Transfers
Business Flow	Plan-to-Produce
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 validate that a previously created, approved transfer order can be shipped out of the source organization in Oracle Fusion SCM, confirming that the correct transfer order, ship quantity, ship method and ship date are captured and that source on-hand and the transfer order status are updated correctly once the shipment is submitted.

The scenario should confirm that:

the correct, eligible transfer order is located and selected for shipment
ship quantity is captured correctly against the transfer order line, including full and partial shipments
the ship method and ship date are captured and reflected on the shipment
lot and serial detail, where the item is lot- or serial-controlled, is captured correctly at shipment
source organization on-hand quantity decreases by exactly the shipped quantity and the transfer order status updates to reflect the shipment
Oracle correctly enforces validation when data errors, configuration errors or security restrictions are introduced (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION)

This scenario assumes a transfer order already exists — created via the separate Create Transfer Order scenario — and covers shipment of that transfer order out of the source organization in Oracle Fusion SCM Inventory Management TEST/UAT environments, including partial shipment, ship method and lot/serial variations. It does not cover creation of the transfer order or receipt at the destination organization, which are covered by the Create Transfer Order and Receive Transfer Order scenarios in the same Transfers cluster.

When to Use This Test

Functional testing of transfer order shipment processing for a new Oracle Fusion SCM Inventory Management implementation
Regression testing of transfer order shipment behavior after an Oracle quarterly update
UAT sign-off for shipping and warehouse personnel who routinely ship transfer orders out of a source organization
Baseline case referenced by the Create Transfer Order, Interorganization Transfer and Receive Transfer Order scenarios within the same Transfers cluster
Diagnosing DATA_ERROR, CONFIGURATION_ERROR and INTEGRATION_ERROR conditions surfaced during shipment before escalating as a possible APPLICATION_ERROR

Where This Test Fits in the Plan-to-Produce Transfers Process

Navigate to Inventory

→

Locate Transfer Order

→

Initiate Shipment

→

Confirm Ship Quantity

→

Select Ship Method/Date

→

Review & Submit

Ship Transfer Order is the second stage of the Transfers cluster within Plan-to-Produce, following Create Transfer Order once a transfer order has been approved and is eligible for shipment, and preceding Receive Transfer Order at the destination organization. It represents the source-organization side of the movement — the shipment reduces source on-hand and updates the transfer order so the destination organization can subsequently receive it. Exact fields available, tolerances and validation depend on organization configuration, item setup and customer-specific Oracle Fusion configuration.

← Previous Stage

Create Transfer Order

Next Stage →

Receive Transfer Order

Preconditions

An approved, open transfer order exists in the target Oracle Fusion SCM environment for the source and destination organizations being tested.
The source organization holds sufficient on-hand quantity of the item to fulfill the ship quantity being tested.
The shipping method used for the test is configured and active for the source organization.
The item, quantity and unit of measure on the transfer order line are valid.
Where the item is lot- or serial-controlled, valid lot and/or serial numbers exist for the on-hand quantity in the source organization.
The test user has shipping privileges for the source organization.

Exact field availability, tolerances, mandatory fields and validation messages may vary by Oracle Fusion implementation, source organization configuration, item setup and customer-specific configuration. State and readiness requirements vary by implementation.

Sample Test Data

Transfer Order Number	${TRANSFER_ORDER_NUMBER}
Source Organization	${SOURCE_ORGANIZATION}
Destination Organization	${DESTINATION_ORGANIZATION}
Item	${ITEM}
Ship Quantity	${SHIP_QUANTITY}
UOM	${UOM}
Ship Method	${SHIP_METHOD}
Ship Date	${SHIP_DATE}
Lot / Serial	${LOT_SERIAL}

Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion SCM TEST/UAT environment. Lot/Serial fields apply only when the item being shipped is lot- or serial-controlled; not every field applies to every transfer order line.

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 using an authorised shipping or inventory test user.	Oracle Fusion opens successfully for the test user.
2	Navigate to Inventory Open the Inventory Management work area to begin shipping a transfer order. ${SOURCE_ORGANIZATION}	The Inventory Management work area opens for the correct source organization.
3	Locate the Transfer Order Search for and select the previously created, approved transfer order eligible for shipment. ${TRANSFER_ORDER_NUMBER}	The eligible transfer order is returned and available for selection, showing its open quantity.
4	Initiate Ship Transfer Order Open the transfer order and initiate the shipment transaction. ${TRANSFER_ORDER_NUMBER} / ${ITEM} This single business step replaces multiple technical actions such as opening the transfer order, navigating to the shipment transaction and confirming the eligible line.	A new, unsaved shipment is opened against the correct transfer order and line.
5	Confirm or Adjust Ship Quantity Confirm the default ship quantity or adjust it for a partial shipment, and enter lot or serial detail where the item requires it. ${SHIP_QUANTITY} / ${UOM} / ${LOT_SERIAL} This is the step highlighted in the transfers process flow, since correctly capturing the ship quantity against the transfer order's open quantity is central to this scenario.	The ship quantity and any lot/serial detail are accepted without unexpected validation errors.
6	Select Ship Method and Ship Date Select the shipping method and confirm the ship date for the shipment. ${SHIP_METHOD} / ${SHIP_DATE}	The ship method and ship date are accepted and reflected on the shipment.
7	Review and Submit the Shipment Review the shipment header and line detail, including transfer order reference, item, quantity, ship method and ship date, then submit for processing. Reviewing the shipment before submission lets the tester catch an incorrect field entry before the transaction posts.	Oracle Fusion successfully processes the shipment without unexpected errors.
8	Verify Source On-Hand Decreased and Order Status UpdatedBusiness assertion Reopen or query on-hand balances for the source organization and the transfer order and confirm the quantity change and updated order status. This is the primary business assertion for the scenario — a correctly recorded shipment with reduced source on-hand and an updated order status is the expected pass condition, not merely a successful submission.	Source organization on-hand has decreased by exactly the shipped quantity, the shipment is recorded against the transfer order, and the transfer order status updates to reflect the shipment.

Expected Results

The shipment is created against the correct, eligible transfer order.
Ship quantity, ship method and ship date match the entered data.
Lot and/or serial detail, where applicable, is correctly captured at shipment.
Source organization on-hand quantity decreases by exactly the shipped quantity.
The transfer order status updates to reflect the shipment.
In-transit quantity reflects the shipped amount pending receipt at the destination organization.
The shipment is visible and traceable in transaction history for the test user.

Key Validation Checkpoints

Source on-hand decreases by the shipped quantity.
Shipment recorded against the transfer order.
Transfer order status updates to reflect shipment.
In-transit quantity reflects the shipment.

Core Business Scenario

Ship Transfer 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 Ship Transfer Order business scenario. Jarvis AI can extend this scenario by generating additional quantity, ship method, 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 quantity, ship method or order status combination. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative and Boundary variations for the customer's environment — including partial quantity shipments and shipment attempted against an already-shipped or closed transfer order, 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 Ship Transfer Order business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Transfer Orders, Items, Organizations, Ship Methods and Quantities.

Jarvis AI

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

Positive + Negative Test Variations

Valid shipment scenarios and edge cases such as insufficient on-hand, invalid ship methods or restricted access.

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 quantity, ship method or transfer order status combination, SyntraFlow maintains one core Ship Transfer Order scenario and allows Jarvis AI to generate quantity-, method- and status-specific variations using the customer's available test data.

AI-Generated Test Variations

The same Ship Transfer 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 Inventory Management Transfers.

Positive Scenarios

Ship the full transfer order quantity
Ship a partial quantity, leaving the remainder open on the transfer order
Ship using different configured ship methods
Ship a lot- or serial-controlled item with detail carried to the shipment
Ship multiple transfer order line items together in a single shipment

Negative Scenarios

Attempt to ship with insufficient on-hand quantity in the source organization
Attempt to ship against an invalid transfer order reference
Enter a ship quantity that exceeds the transfer order's open quantity
Select an invalid or inactive ship method
Attempt to ship a transfer order that has already been shipped
Attempt to ship a closed or cancelled transfer order

These are representative examples only. Negative-scenario behavior and available field combinations 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 transfer order, item, quantity and ship method combination in a real Oracle Fusion SCM environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Ship Transfer Order scenarios relevant to the customer's actual implementation.

Standard Library Definition

Transfer Order Number    ${TRANSFER_ORDER_NUMBER}
Source Organization      ${SOURCE_ORGANIZATION}
Destination Organization ${DESTINATION_ORGANIZATION}
Item                     ${ITEM}
Ship Quantity            ${SHIP_QUANTITY}
UOM                      ${UOM}
Ship Method              ${SHIP_METHOD}
Ship Date                ${SHIP_DATE}
Lot / Serial             ${LOT_SERIAL}

DataVault

Transfer Orders
  Eligible open transfer orders and lines per source organization
Items
  Active catalog and serial/lot-controlled item values
Organizations
  Configured source and destination organizations
Ship Methods
  Active shipping methods per organization
Quantities
  Open and on-hand quantities per transfer order line

Jarvis AI Generates

Scenario 01 — Full Quantity Ship, Source to Destination
Scenario 02 — Partial Quantity Ship
Scenario 03 — Ship via Alternate Ship Method
Scenario 04 — Lot-Controlled Item Ship
Scenario 05 — Ship Attempted Against Already-Shipped Order
Scenario 06 — Unauthorized User Attempts Ship Transfer Order
...

Ship Transfer Order test data can include sensitive inventory categories such as item, organization and quantity information. The public Syntra Standard Test Library uses illustrative placeholder data only. Where DataVault is connected, customer-specific transfer 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 Ship Transfer Order scenarios Jarvis can generate from this business scenario, spanning quantity, ship method and order status 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	Full Quantity Ship	Positive	Shipment created for the full open quantity on the transfer order line	Syntra Ready
VAR-002	Partial Quantity Ship	Positive/Quantity	Only part of the transfer order quantity is shipped, remainder stays open	Syntra Ready
VAR-003	Different Ship Methods	Positive	Shipment created using an alternate configured ship method	Syntra Ready
VAR-004	Lot/Serial Shipment	Positive	Shipment created for an item configured for lot or serial control	Syntra Ready
VAR-005	Multiple Line Items Shipped Together	Positive	Two or more transfer order lines are shipped together in a single shipment	Syntra Ready
VAR-006	Insufficient On-Hand to Ship	Negative/Quantity	Source organization lacks sufficient on-hand quantity to fulfill the ship quantity	Syntra Ready
VAR-007	Invalid Transfer Order Reference	Negative	Transfer order number entered does not resolve to an eligible order	Syntra Ready
VAR-008	Ship Quantity Exceeds Order Quantity	Negative/Quantity	Ship quantity entered exceeds the transfer order line's open quantity	Syntra Ready
VAR-009	Invalid Ship Method	Negative	Selected ship method is invalid or inactive for the source organization	Syntra Ready
VAR-010	Already-Shipped Order	Negative/Status	Selected transfer order has already been fully shipped	Syntra Ready
VAR-011	Closed or Cancelled Order	Negative/Status	Selected transfer order is closed or cancelled as of the ship date	Syntra Ready

Automatically Expand Positive and Negative Shipment Coverage

Positive Testing

Jarvis generates scenarios using transfer order, item, quantity and ship method combinations expected to successfully ship a transfer order in Oracle Fusion.

Approved Open Transfer Order + Sufficient Source On-Hand + Valid Ship Method → Shipment Recorded, Order Status Updated

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's validations around on-hand quantity, order reference, order status, ship method and security.

Insufficient On-Hand → Expected Quantity Validation
Ship Quantity Exceeds Order Quantity → Expected Quantity Validation
Already-Shipped Order → Expected Status 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 transfer order	Order created	PASS
Invalid organization	Organization validation occurs	PASS
Same source/destination	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 Ship Transfer Order scenarios and group them into reusable execution packs.

SCM Inventory Management Ship Transfer Order Regression Pack

Full Quantity Ship
Partial Quantity Ship
Different Ship Methods
Lot/Serial Shipment
Multiple Line Items Shipped Together
Insufficient On-Hand to Ship
Ship Quantity Exceeds Order Quantity
Already-Shipped Order
Closed or Cancelled Order
Security Restriction — Unauthorized Shipment

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

Once scheduled, SyntraFlow executes the selected Ship Transfer 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 Inventory Management Ship Transfer Order 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 & Persona Variations

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

Persona	Action	Expected	Syntra Result
Inventory Planner	Ship Transfer Order	Allowed	PASS
Unauthorized User	Attempts Shipment	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 Ship Transfer Order scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary and Status coverage — including partial quantity shipments and shipment attempted against an already-shipped order — 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 — Ship Transfer 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 Transfer Order

May internally include

Open Transfer Order Search → Enter Transfer Order Number Criteria → Filter Eligible Orders → Select Transfer Order → Confirm Open Quantity

Business Step

Verify Source On-Hand Decreased and Order Status Updated

May internally include

Open On-hand Balances → Query Source Organization → Query Transfer Order Status → Compare Pre/Post Quantities → Confirm Order Status

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 shipment moved the correct quantity — 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: Ship Transfer Order failed — Likely category: DATA_ERROR — Evidence: ship quantity exceeds the remaining open transfer order quantity — Recommended action: adjust the ship quantity to match the open order balance. A failure should never be labeled as an Oracle defect without supporting evidence.

Step	Action Status	Business Validation
Confirm or Adjust Ship Quantity	Pass	—
Review and Submit the Shipment	Pass	—
Verify Source On-Hand Decreased and Order Status Updated	Pass	Pass

Related Transfer Tests

Ship Transfer Order is the source-organization stage of the Transfers cluster — explore the related creation, interorganization and receipt scenarios below.

Create Transfer Order Interorganization Transfer Receive Transfer Order

Turn This Standard Test into Your Oracle SCM Ship Transfer Order Regression Suite

Start with the Syntra Standard Ship Transfer Order test, use DataVault to provide environment-specific test data, let Jarvis generate additional quantity, ship method and status variations, and execute the resulting regression pack automatically with SyntraFlow.

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

Frequently Asked Questions

What does a ship transfer order test validate?

This test validates that a previously created, approved transfer order can be shipped out of the source organization in Oracle Fusion SCM, using a valid ship quantity, ship method and ship date, and that source on-hand and the transfer order status are updated correctly once the shipment is submitted.

How does Ship Transfer Order relate to Create Transfer Order?

Ship Transfer Order assumes a transfer order already exists, created and approved through the separate Create Transfer Order scenario. This scenario covers only the source-organization shipment step — reducing source on-hand and updating the order — while creation of the order itself is covered by Create Transfer Order.

What happens when only part of the transfer order quantity is shipped?

Oracle Fusion allows a transfer order line to be shipped in full or in part. Where a partial quantity is shipped, source on-hand decreases only by the shipped amount, the remaining open quantity stays available on the transfer order for a later shipment, and this scenario includes a partial quantity ship variation to exercise that path.

How is the shipment tracked before it is received?

Once shipped, the transferred quantity moves into an in-transit state against the transfer order pending receipt at the destination organization. This scenario's business assertion confirms that in-transit quantity reflects the shipped amount, and the subsequent Receive Transfer Order scenario in the same cluster covers the destination-organization side of the movement.

How does security testing work for shipping transfer orders?

Access to ship a transfer order for a given source organization is controlled by Oracle Fusion's security configuration, which varies by customer. SyntraFlow can execute representative persona-based variations — such as an authorised inventory planner versus an unauthorized user — to confirm that shipping access behaves as expected, without asserting a single universal Oracle security model.