Oracle Fusion Create Sales Order Test Cases
Validate that a standard sales order is created correctly in Oracle Fusion SCM Order Management using a valid customer, item, quantity, unit of measure, warehouse, requested date and price list, and that pricing and credit checks behave as expected.
| Test ID | ORCL.O2C.OM.SO.CREATE |
| Application | Oracle Fusion Cloud |
| Product | SCM / Order Management |
| Module | Order Management |
| Process | Sales Orders |
| 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 a standard sales order can be created in Oracle Fusion SCM Order Management using a valid customer, item, quantity, unit of measure, warehouse, requested date and price list, and that the resulting sales order is created with correct header and line detail, pricing and status.
The scenario should confirm that:
- the sales order is created for the correct business unit and customer
- customer account status and credit checks are enforced correctly
- item, quantity, UOM and warehouse detail is captured accurately on the line
- pricing is calculated correctly from the applicable price list
- the sales order receives a system-generated order number and correct status
- 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 single or multi-line standard sales order in Oracle Fusion SCM Order Management TEST/UAT environments. It does not cover order submission for fulfillment, scheduling or shipment, which are covered by the separate Submit Sales Order and related scenarios in the same Sales Orders cluster.
When to Use This Test
- Functional testing of sales order creation for a new Oracle Fusion SCM Order Management implementation
- Regression testing of sales order creation behavior after an Oracle quarterly update
- UAT sign-off for order entry specialists who routinely create sales orders
- Baseline case referenced by the Create Multi-Line Order, Create Order With Discount and Submit Sales Order scenarios within the same Sales Orders cluster
- Diagnosing DATA_ERROR, CONFIGURATION_ERROR and INTEGRATION_ERROR conditions surfaced during sales order creation before escalating as a possible APPLICATION_ERROR
Where This Test Fits in the Order-to-Cash Sales Orders Process
Create Sales Order is the entry point of the Sales Orders scenario family within Order-to-Cash. Once a sales order is created, it is typically submitted, scheduled and fulfilled — covered by the Submit Sales Order and related scenarios in this same cluster. Exact fields available, pricing behavior and credit check enforcement depend on order management setup, customer and item configuration and customer-specific Oracle Fusion configuration.
Preconditions
- The customer account used on the sales order is active and creditworthy according to configured credit checks.
- The item being ordered is active and orderable in the item catalog.
- A price list applicable to the customer and item combination is configured and active.
- The order entry specialist has appropriate access to create a sales order for the business unit.
- The warehouse and requested date used on the sales order are valid and available.
Exact field availability, mandatory fields, credit check behavior and validation messages may vary by Oracle Fusion implementation, order management configuration, customer setup and customer-specific configuration. State and readiness requirements vary by implementation.
Sample Test Data
| Business Unit | ${BUSINESS_UNIT} |
| Customer | ${CUSTOMER} |
| Item | ${ITEM} |
| Quantity | ${QUANTITY} |
| UOM | ${UOM} |
| Price List | ${PRICE_LIST} |
| Warehouse | ${WAREHOUSE} |
| Requested Date | ${REQUESTED_DATE} |
| Payment Terms | ${PAYMENT_TERMS} |
| Order Type | ${ORDER_TYPE} |
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 line — for example, default warehouse or payment terms may be inherited from the customer account rather than requiring re-entry.
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. | Oracle Fusion opens successfully for the test user. |
| 2 | Navigate to Order Management Navigate to the Order Management work area to begin creating a sales order. ${BUSINESS_UNIT} | The Order Management work area opens successfully for the correct business unit. |
| 3 | Initiate Create Sales Order Start a new sales order from the Order Management work area. ${ORDER_TYPE} This single business step replaces multiple technical actions such as opening the create page and confirming the order type. | A new, unsaved sales order is opened for the correct business unit and order type. |
| 4 | Select Customer Search for and select the customer for the sales order. ${CUSTOMER} | The customer is accepted and reflected on the sales order header. |
| 5 | Add Item Lines Search for and add the item to the sales order, entering quantity and unit of measure. ${ITEM} / ${QUANTITY} / ${UOM} | The item line is accepted and added to the sales order without unexpected validation errors. |
| 6 | Select Warehouse and Requested Date Select the shipping warehouse and enter the requested date for the sales order line. ${WAREHOUSE} / ${REQUESTED_DATE} | The warehouse and requested date are accepted and reflected on the line. |
| 7 | Review Pricing Review the pricing calculated for the line and header based on the applicable price list and payment terms. ${PRICE_LIST} / ${PAYMENT_TERMS} Reviewing pricing before saving lets the tester catch an incorrect price list or line entry before the order is created. | The reviewed sales order reflects pricing consistent with the applicable price list. |
| 8 | Review and Submit the Sales OrderBusiness assertion Review the complete sales order and save it for creation in the test environment. This is the primary business assertion for the scenario — a correctly created sales order with accurate header and line detail is the expected pass condition, not merely a successful save. Formal submission for scheduling and fulfillment is covered separately by the Submit Sales Order scenario. | A sales order number is generated, the order status is correct, and customer, item, quantity, pricing and totals match the entered data. |
Expected Results
- The sales order is created for the correct business unit and customer.
- A system-generated order number is assigned.
- Item, quantity, UOM and warehouse detail on the line are correct.
- Pricing is calculated correctly from the applicable price list.
- The requested date and payment terms are correctly reflected.
- The sales order status correctly reflects a newly created order.
- Credit checks are correctly enforced where the customer requires them.
Key Validation Checkpoints
- Order created with correct status.
- Customer, item and pricing details are accurate.
- Order is available for downstream processing, such as scheduling.
- Credit check is correctly enforced where applicable.
Go Beyond the Standard Test with Jarvis AI
The Syntra Standard Test Library defines the core Create Sales Order business scenario. Jarvis AI can extend this scenario by generating additional customer, item, pricing, warehouse 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 customer, item, quantity or price list combination. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative, Boundary and Customer/Credit variations for the customer's environment — including sales orders for customers on credit hold and boundary quantity or pricing cases, 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
Rather than maintaining a separate test page for every possible customer, item, quantity, price list or warehouse combination, SyntraFlow maintains one core Create Sales Order scenario and allows Jarvis AI to generate customer, item, pricing and security-specific variations using the customer's available test data.
AI-Generated Test Variations
The same Create Sales 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 Sales Orders.
- Create a standard single-line sales order
- Create a sales order with multiple items on one order
- Create sales orders for different customers
- Create sales orders from different warehouses
- Create sales orders with different payment terms
- Create a sales order with a scheduled requested date
- Attempt to create an order for an inactive customer
- Attempt to order an item that is not orderable
- Enter an invalid quantity
- Enter an invalid price list
- Attempt to create an order for a customer on credit hold
- Attempt to save with missing required fields
- Enter an invalid warehouse
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 customer, item, price list, warehouse and payment terms combination in a real Oracle Fusion SCM environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Create Sales Order scenarios relevant to the customer's actual implementation.
Standard Library Definition
Business Unit ${BUSINESS_UNIT}
Customer ${CUSTOMER}
Item ${ITEM}
Quantity ${QUANTITY}
UOM ${UOM}
Price List ${PRICE_LIST}
Warehouse ${WAREHOUSE}
Requested Date ${REQUESTED_DATE}
Payment Terms ${PAYMENT_TERMS}
Order Type ${ORDER_TYPE}
DataVault
Customers Active, creditworthy customer accounts per business unit Items Active, orderable catalog items Price Lists Price lists applicable to customer/item combinations Warehouses Configured, available warehouses Payment Terms Configured payment terms codes Credit Profiles Customer credit hold and credit limit status
Jarvis AI Generates
Scenario 01 — Customer A + Single Item + Standard Pricing Scenario 02 — Customer A + Multiple Items on One Order Scenario 03 — Customer B + Different Warehouse and Terms Scenario 04 — Customer on Credit Hold Scenario 05 — Inactive Customer Scenario 06 — Unauthorized User Attempts Order Creation ...
Create Sales Order test data can include sensitive customer and pricing 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 Sales Order scenarios Jarvis can generate from this business scenario, spanning customer, pricing, warehouse and terms 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 Single-Line Sales Order | Positive | Sales order created with valid customer, item and quantity | Syntra Ready |
| VAR-002 | Multiple Items on One Order | Positive | Order created with multiple item lines on a single order | Syntra Ready |
| VAR-003 | Different Customers | Positive/Customer | Order created for an alternate active, creditworthy customer | Syntra Ready |
| VAR-004 | Different Warehouses | Positive | Order created shipping from an alternate configured warehouse | Syntra Ready |
| VAR-005 | Different Payment Terms | Positive/Pricing | Order created with an alternate configured payment terms code | Syntra Ready |
| VAR-006 | Scheduled Requested Date | Positive | Order created with a future requested date for scheduling | Syntra Ready |
| VAR-007 | Inactive Customer | Negative/Customer | Selected customer is inactive as of the order date | Syntra Ready |
| VAR-008 | Item Not Orderable | Negative | Selected item is not orderable or inactive | Syntra Ready |
| VAR-009 | Invalid Quantity | Negative | Line quantity entered as zero or a negative value | Syntra Ready |
| VAR-010 | Invalid Price List | Negative/Pricing | Price list entered is not applicable to the customer/item combination | Syntra Ready |
| VAR-011 | Customer on Credit Hold | Negative/Customer | Selected customer account is on active credit hold | Syntra Ready |
| VAR-012 | Missing Required Fields | Negative | A mandatory header or line field is left blank | Syntra Ready |
| VAR-013 | Invalid Warehouse | Negative | Warehouse entered is invalid or not configured for the business unit | Syntra Ready |
No variations match this filter.
Automatically Expand Positive and Negative Sales Order Coverage
Positive Testing
Jarvis generates scenarios using customer, item, quantity, pricing and warehouse combinations expected to successfully create a sales order in Oracle Fusion.
Valid Customer + Orderable Item + Valid Price List + Available Warehouse → Sales Order Created
Negative Testing
Jarvis can also generate scenarios designed to exercise Oracle's validations around customer status, item status, credit hold and security.
- Inactive Customer → Expected Customer Validation
- Item Not Orderable → Expected Item Validation
- Invalid Price List → Expected Pricing Validation
- Customer on Credit Hold → Expected Credit Check 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 sales order | Order created | PASS |
| Invalid customer | Customer validation occurs | PASS |
| Credit hold | Credit check enforced | 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 Sales Order scenarios and group them into reusable execution packs.
SCM Order Management Create Sales Order Regression Pack
- Standard Single-Line Sales Order
- Multiple Items on One Order
- Different Customers
- Different Warehouses
- Different Payment Terms
- Scheduled Requested Date
- Inactive Customer
- Invalid Price List
- Customer on Credit Hold
- Invalid Warehouse
Run On-Demand or Schedule Automated Batch Execution
SyntraFlow can execute selected Create Sales Order scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.
Once scheduled, SyntraFlow executes the selected Create Sales Order scenarios unattended and records the outcome of each test and business assertion.
| Pack | SCM Order Management Create Sales 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.
Regression Pack → Scenario → Business Step → Automation Action → Evidence
Security & Persona Variations
Access to create a sales order for a given business unit is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that sales-order-creation access behaves as expected for each role — not to assert a single universal Oracle security model.
| Persona | Action | Expected | Syntra Result |
|---|---|---|---|
| Order Entry Specialist | Create Sales Order | Allowed | PASS |
| Unauthorized User | Attempts Order 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.
From Business Scenario to Execution Evidence
Business teams get readable test documentation; automation teams retain detailed execution traceability.
Meet Jarvis — SyntraFlow's AI Testing Engine
Jarvis extends the Syntra Standard Test Library by analysing the Create Sales Order scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary and Customer/Credit coverage — including sales orders for customers on credit hold and boundary quantity or pricing cases — for the customer's environment.
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.
Business Step → Underlying UI Actions
What SyntraFlow Captures Per Run
Action Status vs. Business Validation
A successful UI interaction does not automatically prove the sales 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 Sales Order failed — Likely category: EXPECTED_VALIDATION — Evidence: the customer account is on credit hold — Recommended action: this is expected behavior; use a customer account without an active credit hold or process the required credit release. A failure should never be labeled as an Oracle defect without supporting evidence.
| Step | Action Status | Business Validation |
|---|---|---|
| Add Item Lines | Pass | — |
| Review Pricing | Pass | — |
| Review and Submit the Sales Order | Pass | Pass |
Related Sales Order Tests
Create Sales Order is the entry point of the Sales Orders cluster — explore the related multi-line, discount and submission scenarios below.
Turn This Standard Test into Your Oracle SCM Create Sales Order Regression Suite
Start with the Syntra Standard Create Sales Order test, use DataVault to provide environment-specific test data, let Jarvis generate additional customer, pricing and security variations, and execute the resulting regression pack automatically with SyntraFlow.
Use This Oracle Fusion Test Case
Download Test Case
Excel, CSV or JSON export.
Coming soonAutomate with SyntraFlow
Run this script against your own tenant today.
Related Oracle Testing Resources
Frequently Asked Questions
What is a standard sales order in Oracle Fusion Order Management?
How does credit check behavior work when creating a sales order?
How is pricing determined on a sales order?
How does security testing work for sales order creation?
Does this test create real sales orders or real transactions in Oracle Fusion?
- Home
- Oracle ERP Testing Tool
- Test Library
- SCM
- Order Management
- Sales Orders
- Create Sales Order