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

Syntra Standard Oracle Test Library

Oracle Fusion Fulfillment Exceptions Test Cases

Validate correct Oracle Fusion system behavior when exception conditions occur at any stage of the fulfillment lifecycle — scheduling, reservation, pick release or ship confirm — confirming each exception is correctly raised, leaves no partial or inconsistent order/inventory state, and can be corrected and retried successfully.

Test ID	ORCL.O2C.OM.FUL.EXCEPTIONS
Application	Oracle Fusion Cloud
Product	SCM / Order Management
Module	Order Management
Process	Fulfillment
Business Flow	Order-to-Cash
Scenario Type	Negative / Exception Handling
Test Usage	Functional Testing / Regression Testing / Exception Classification
Priority	High
Automation	SyntraFlow Ready
Library	Syntra Standard

Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions automatically while presenting the scenario as business-readable test steps for documentation, review and reporting. This scenario is presented as 9 business-readable test steps; SyntraFlow's automation executes approximately 32 underlying Oracle Fusion UI actions to complete it.

Test Objective

Validate correct system behavior when exception conditions occur at any stage of the fulfillment lifecycle — scheduling, reservation, pick release or ship confirm — using deliberately constructed conditions designed to trigger each exception type.

The scenario should confirm that:

the deliberately constructed exception condition at scheduling, reservation, pick release or ship confirm is correctly rejected or flagged rather than silently accepted
the resulting validation message matches the expected message for the exception condition and stage triggered
no partial or inconsistent inventory or order state results from a blocked transaction
order or line status accurately reflects the blocked state until the triggering condition is resolved
retrying the transaction after the triggering condition is corrected completes successfully
order and audit history reflects both the original attempted transaction and the corrected transaction
unrelated, exception-free fulfillment transactions are not blocked by an unrelated exception condition

A negative fulfillment scenario passes when Oracle correctly raises the expected validation — a correctly enforced business rule is a passing test, not a failure, even though it is described as an "exception" in business terms. This scenario does not attempt to certify a specific Oracle application defect; SyntraFlow does not label a failure as an Oracle application defect without supporting evidence, and where an exception appears unexpected or its cause is unclear, it is flagged for further investigation rather than attributed with certainty.

When to Use This Test

Functional testing of fulfillment exception handling for a new Oracle Fusion Order Management implementation
Regression testing of scheduling, reservation, pick release and ship confirm validations after an Oracle quarterly update
UAT sign-off for fulfillment controls that must correctly reject or flag invalid conditions at any stage
Baseline exception case referenced by Schedule Order, Reservation, Pick Release and Ship Confirm within the same Fulfillment cluster
Final coverage point confirming the Fulfillment cluster provides exception coverage across the full order-to-ship flow

Where This Test Fits in the Fulfillment Process

Schedule Order

→

Reservation

→

Pick Release

→

Ship Confirm

→

Exceptions

Fulfillment Exceptions is the fifth and final scenario family in the Fulfillment cluster, following Schedule Order, Reservation, Pick Release and Ship Confirm. It covers exception conditions that can arise at any of those four stages rather than performing a normal fulfillment transaction itself. Exact exception triggers and messages depend on order management configuration, inventory and warehouse setup, and customer-specific Oracle Fusion configuration.

← Previous Stage

Ship Confirm

Preconditions

Oracle Fusion Order Management and related fulfillment access is available to the test user.
A representative sales order and order line exist that can be placed into a scheduling exception condition — no available supply or an invalid warehouse.
Test data required to trigger reservation exception conditions — insufficient on-hand quantity or an unavailable lot/serial — is available or can be constructed.
Test data required to trigger pick release exception conditions — an active order hold or an unscheduled line included in the pick release — is available or can be constructed.
Test data required to trigger ship confirm exception conditions — a ship quantity exceeding the picked quantity or an invalid carrier — is available or can be constructed.
The test user, or Syntra DataVault, can reproduce or observe exception conditions across all four fulfillment stages, including security-restricted and mid-fulfillment cancellation scenarios.

Exact exception triggers, messages and classifications may vary by Oracle Fusion implementation, order management configuration and inventory/warehouse setup.

Sample Test Data

Order Number	${ORDER_NUMBER}
Item	${ITEM}
Quantity	${QUANTITY}
Warehouse	${WAREHOUSE}
Lot	${LOT} — applicable for lot-controlled items
Serial	${SERIAL} — applicable for serial-controlled items
Ship Method	${SHIP_METHOD}
Carrier	${CARRIER}
Exception Stage	${EXCEPTION_STAGE} — Scheduling / Reservation / Pick Release / Ship Confirm
Expected Validation Message	${EXPECTED_VALIDATION_MESSAGE}

Sample values are illustrative. Actual exception triggers, messages and thresholds depend on the target Oracle Fusion environment and its order management and inventory configuration.

Test Steps

9 business-readable steps. SyntraFlow's automation executes ~32 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.

#	User Action	Expected Result
1	Sign In Sign in to Oracle Fusion as a user authorized to perform fulfillment transactions.	The user signs in successfully and lands on the home page.
2	Navigate to Order Management Navigate to the Order Management work area.	The Order Management work area opens successfully.
3	Construct the Exception Scenario Construct a fulfillment scenario for the order and item under test that is deliberately expected to trigger an exception at the relevant stage — scheduling, reservation, pick release or ship confirm. ${ORDER_NUMBER} / ${ITEM} / ${EXCEPTION_STAGE} This single business step replaces multiple technical actions such as opening the relevant screen, entering the deliberately invalid value and preparing the record for submission.	The order and line are placed into the deliberately constructed exception condition for the stage under test.
4	Attempt the Fulfillment Action at the Relevant Stage Attempt the fulfillment action for the exception condition under test — schedule the order, reserve supply, release the pick, or confirm the shipment. ${QUANTITY} / ${WAREHOUSE} / ${LOT} / ${SERIAL} / ${SHIP_METHOD} / ${CARRIER}	Oracle Fusion processes the attempted action against the exception condition rather than silently accepting it.
5	Capture the Resulting System Message Capture the exception, error or validation message returned by Oracle Fusion at the point the condition is triggered.	A system message is displayed or logged for the attempted transaction.
6	Verify the Message Matches Expected ValidationBusiness assertion Compare the captured message against the expected validation message for the exception condition and stage under test. ${EXPECTED_VALIDATION_MESSAGE} This is the primary business assertion confirming the exception was correctly and specifically raised — a correctly raised validation is a passing test, not a failure.	The observed message matches the expected validation for the triggered condition.
7	Correct the Triggering Condition Correct the underlying condition that triggered the exception — for example, make supply available, release the hold, adjust the picked or confirmed quantity, or select a valid carrier.	The triggering condition no longer applies to the order or line.
8	Retry the Transaction Retry the same fulfillment action at the same stage now that the triggering condition has been corrected.	Oracle Fusion accepts the retried transaction without the previous exception recurring.
9	Verify Successful Completion After CorrectionBusiness assertion Confirm that the order or line completes the stage successfully and that order/audit history reflects both the original attempt and the corrected transaction. This is the closing business assertion for the scenario — the test does not stop merely because the retried action was accepted; the corrected outcome and its history must be confirmed.	The order or line successfully completes the stage, and history reflects both the attempted and the corrected transaction.

Expected Results

Each exception condition — at scheduling, reservation, pick release or ship confirm — produces the expected Oracle Fusion validation message.
No partial or inconsistent inventory or order state results from any blocked transaction.
Order or line status accurately reflects the blocked state until the triggering condition is resolved.
Retrying the transaction after correction completes successfully.
Order and audit history reflects both the attempted and the corrected transaction.
Eligible fulfillment transactions unrelated to the exception condition under test are not blocked.

Key Validation Checkpoints

Each exception condition raises the correct, specific validation message for its stage.
No partial or inconsistent inventory or order state results from a blocked transaction.
Order/line status accurately reflects the blocked state.
Retry after correction succeeds.
Audit/history reflects the attempted and corrected transaction.

Core Business Scenario

Fulfillment Exceptions

Business Steps

Fulfillment Stages Covered

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 fulfillment exception scenario. Jarvis AI can extend this scenario by systematically generating additional exception variations across all four fulfillment stages — Scheduling Exceptions, Reservation Exceptions, Picking Exceptions and Shipping Exceptions — using customer-specific test data and configuration available through Syntra DataVault.

Teams do not need to manually construct dozens of near-identical exception scenarios to cover every insufficient-supply condition, held order, quantity mismatch or invalid carrier. Jarvis uses the standard exception scenario as the foundation and generates stage-by-stage coverage relevant to the customer's environment.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable fulfillment exception scenario and automation logic.

Customer DataVault

Provides approved customer-specific test data required for exception scenario generation — Order Number, Item, Quantity, Warehouse, Lot, Serial, Ship Method and Carrier.

Jarvis AI

Analyses the standard exception scenario together with available test data and generates relevant stage-specific variations.

Positive + Negative Test Variations

Correctly enforced validations, and deliberately invalid scheduling, reservation, pick release and ship confirm conditions.

Regression Pack

Selected exception 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 exception classification.

Rather than maintaining a separate test for every possible fulfillment exception condition, SyntraFlow maintains one core exception scenario and allows Jarvis AI to generate stage-specific variations across Scheduling Exceptions, Reservation Exceptions, Picking Exceptions and Shipping Exceptions using the customer's available test data.

AI-Generated Test Variations

The same Fulfillment Exceptions 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 Fulfillment.

Positive Scenarios

Expected validation raised for insufficient supply at scheduling
Expected validation raised for held order at pick release
Expected validation raised for ship quantity exceeding picked quantity
Expected validation raised for unauthorized fulfillment action

Negative Scenarios

Order scheduled with no available supply for the requested item
Order scheduled against an invalid or unconfigured warehouse
Reservation attempted with insufficient on-hand quantity
Reservation attempted where the required lot or serial is unavailable
Pick release attempted against an order carrying an active hold
Pick release run inadvertently includes an unscheduled order line
Ship confirm entered with a quantity exceeding the picked quantity
Ship confirm attempted with an invalid or unconfigured carrier
Fulfillment action attempted by a user restricted by security/role configuration
Fulfillment action attempted on an order cancelled mid-fulfillment

These are representative examples only. Exception triggers, messages and classifications can depend on the customer's Oracle Fusion configuration, inventory setup and security model — not every Oracle configuration behaves identically.

Generated Using Your DataVault Test Data

Generic test data rarely represents every order, item, warehouse, lot, serial, ship method and carrier combination in a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to deliberately construct each exception condition relevant to the customer's actual implementation.

Standard Library Definition

Exception Stage       ${EXCEPTION_STAGE}
Order Number           ${ORDER_NUMBER}
Item                    ${ITEM}
Quantity                ${QUANTITY}
Warehouse               ${WAREHOUSE}
Lot                     ${LOT}
Serial                  ${SERIAL}
Ship Method             ${SHIP_METHOD}
Carrier                 ${CARRIER}
Expected Validation     ${EXPECTED_VALIDATION_MESSAGE}

DataVault

Orders and Lines
  Eligible and deliberately exception-prone combinations
Items
  Lot-controlled, serial-controlled and standard items
Warehouses
  Configured and unconfigured organizations
Carriers and Ship Methods
  Valid and deliberately invalid references
Holds
  Active hold types by order/line

Jarvis AI Generates

Scenario 01 — No Available Supply at Scheduling
Scenario 02 — Invalid Warehouse at Scheduling
Scenario 03 — Insufficient On-Hand at Reservation
Scenario 04 — Held Order Blocks Pick Release
Scenario 05 — Ship Quantity Exceeds Picked Quantity
Scenario 06 — Invalid Carrier at Ship Confirm
...

Customer-specific test data and AI-generated exception variations are not published to the Syntra Standard Test Library. Where DataVault is connected, customer-specific dimensions such as orders, items, warehouses and carriers remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Representative examples of fulfillment exception scenarios Jarvis can generate from this business scenario, spanning scheduling, reservation, picking and shipping 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	No Available Supply at Scheduling	Scheduling	Order line has no available supply to satisfy the requested schedule date	Syntra Ready
VAR-002	Invalid Warehouse at Scheduling	Scheduling	Order scheduled against a warehouse that is not valid or not configured for the item	Syntra Ready
VAR-003	Schedule Date Outside Valid Window	Scheduling	Requested schedule date falls outside a valid scheduling window	Syntra Ready
VAR-004	Insufficient On-Hand at Reservation	Reservation	Reservation attempted where on-hand quantity is insufficient to cover the order line	Syntra Ready
VAR-005	Lot Unavailable at Reservation	Reservation	Required lot is not available for a lot-controlled item at reservation	Syntra Ready
VAR-006	Serial Unavailable at Reservation	Reservation	Required serial number is not available for a serial-controlled item at reservation	Syntra Ready
VAR-007	Order Cancelled Before Pick Release	Picking	Order is cancelled after scheduling but before pick release begins	Syntra Ready
VAR-008	Held Order Blocks Pick Release	Picking	Pick release attempted against an order carrying an active hold	Syntra Ready
VAR-009	Unscheduled Line Included in Pick Release	Picking	Pick release run inadvertently includes a line that has not yet been scheduled	Syntra Ready
VAR-010	Insufficient Picked Quantity	Picking	Quantity picked is less than the quantity released for picking	Syntra Ready
VAR-011	Unauthorized User Attempts Pick Release	Picking	A user without pick-release privileges attempts to release the pick	Syntra Ready
VAR-012	Ship Quantity Exceeds Picked Quantity	Shipping	Ship confirm quantity entered exceeds the quantity actually picked	Syntra Ready
VAR-013	Invalid Carrier at Ship Confirm	Shipping	Ship confirm attempted with a carrier that is not valid or not configured for the ship method	Syntra Ready
VAR-014	Invalid Ship Method at Ship Confirm	Shipping	Ship confirm attempted with a ship method not enabled for the order or organization	Syntra Ready
VAR-015	Ship Confirm on Order Cancelled Mid-Fulfillment	Shipping	Ship confirm attempted on an order line that was cancelled after pick release	Syntra Ready

Why a Correctly Raised Exception Can Be a Passing Test

Positive Testing

Jarvis generates scenarios designed to confirm that Oracle Fusion correctly raises the expected validation when an exception condition exists at scheduling, reservation, pick release or ship confirm.

Held Order + Pick Release Attempt → Expected Hold Validation Displayed

Negative Testing

Jarvis can also generate edge-case scenarios that stress-test whether an exception is detected, classified and reflected correctly at all — these surface potential gaps in Oracle's exception handling rather than confirm it.

Exception Silently Ignored → Transaction Should Have Been Blocked (potential defect requiring investigation)
Exception Detected but Order/Line Status Does Not Reflect It
Exception Condition Blocks an Unrelated, Eligible Transaction
Retry After Correction Still Blocked by the Original Exception
Exception Detected but Inventory or Order State Left Inconsistent
Exception Message Displayed Does Not Match the Expected Classification

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

Scenario	Oracle Outcome	Test Result
Valid order scheduled	Order scheduled	PASS
Insufficient supply	Validation occurs	PASS
Held order	Scheduling blocked	PASS
Security restriction	Access prevented	PASS
Unexpected application exception	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

Users can select generated exception scenarios and group them into reusable execution packs.

Fulfillment Exceptions Regression Pack

No Available Supply at Scheduling
Invalid Warehouse at Scheduling
Insufficient On-Hand at Reservation
Lot Unavailable at Reservation
Held Order Blocks Pick Release
Unscheduled Line Included in Pick Release
Ship Quantity Exceeds Picked Quantity
Invalid Carrier at Ship Confirm
Unauthorized User Attempts Pick Release
Ship Confirm on Order Cancelled Mid-Fulfillment

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

Once scheduled, SyntraFlow executes the selected exception 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	Fulfillment Exceptions Regression Pack
Schedule	Quarterly Update Regression
Tests	15 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 trigger and act on fulfillment exceptions is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that fulfillment access behaves as expected for each role — not to assert a single universal Oracle security model.

Persona	Action	Expected	Syntra Result
Order Fulfillment Specialist	Attempts Action Outside Authorization	Access prevented	PASS
Unauthorized User	Attempts Any Fulfillment Action	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 fulfillment exception scenario, available DataVault test data and expected business outcomes to systematically generate exception coverage across four categories for the customer's environment — Scheduling Exceptions, Reservation Exceptions, Picking Exceptions and Shipping Exceptions.

Generate

Positive and negative exception variations by stage.

Parameterize

Use relevant order, item and warehouse 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 — Fulfillment Exceptions, 9 Business Steps

↓

DataVault — Customer-Specific Order, Item and Warehouse Data

↓

Jarvis AI — Generate Scheduling / Reservation / Picking / Shipping Exception 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

Attempt the Fulfillment Action at the Relevant Stage

May internally include

Open Schedule/Reserve/Pick Release/Ship Confirm Screen → Select Order/Line → Submit Deliberately Invalid Condition → Capture Response

Business Step

Verify the Message Matches Expected Validation

May internally include

Open Message Detail → Capture Validation Text → Capture Message Code → Compare to Expected

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 exception was correctly raised and classified — this is illustrative of how SyntraFlow separates action success from business validation; it does not reflect a specific live execution.

Step	Action Status	Business Validation
Attempt the Fulfillment Action at the Relevant Stage	Pass	—
Capture the Resulting System Message	Pass	—
Verify the Message Matches Expected Validation	Pass	Pass

Related Fulfillment Tests

Fulfillment Exceptions is the fifth and final page in the Fulfillment cluster — the most comprehensive page in the cluster, aggregating exception coverage across Schedule Order, Reservation, Pick Release and Ship Confirm rather than testing a single stage in isolation.

Schedule Order Pick Release Ship Confirm

Turn This Standard Test into Your Oracle Fulfillment Exception Regression Suite

Start with the Syntra Standard fulfillment exception test, use DataVault to provide environment-specific order, item and warehouse data, let Jarvis generate additional stage-specific exception variations, and execute the resulting regression pack automatically with SyntraFlow.

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

Frequently Asked Questions

Does a correctly blocked fulfillment transaction mean the test failed?

No. A negative fulfillment scenario passes when Oracle correctly raises the expected validation — for example, blocking scheduling when no supply is available, or blocking pick release against a held order. The test only fails if Oracle does not behave as expected, such as silently accepting the exception condition.

How are the eight failure-intelligence categories used on this page?

Jarvis Failure Intelligence considers eight possible root-cause categories for any fulfillment exception: DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, AUTOMATION_ERROR, INTEGRATION_ERROR, ENVIRONMENT_ERROR and APPLICATION_ERROR. For example, Fulfillment Exceptions failed at pick release — likely category: EXPECTED_VALIDATION — evidence: the order carries an active hold — recommended action: this is expected behavior; release the hold before retrying pick release. Fulfillment Exceptions failed at ship confirm — likely category: DATA_ERROR — evidence: confirmed quantity exceeds the picked quantity — recommended action: correct the ship confirm entry to match the picked quantity. Fulfillment Exceptions failed at reservation — likely category: INTEGRATION_ERROR — evidence: the inventory availability service did not respond within the expected time — recommended action: confirm the integration/service is available before retrying. Because this page aggregates every exception path in the Fulfillment cluster, this principle matters most here: SyntraFlow does not label a failure as an Oracle application defect without supporting evidence — an unexpected or unclassifiable failure is flagged for further investigation rather than attributed with certainty.

Are exceptions tested at every stage of fulfillment?

Yes. This scenario covers exception conditions across all four fulfillment stages — scheduling (for example no available supply or an invalid warehouse), reservation (insufficient on-hand quantity or unavailable lot/serial), pick release (a held order or an unscheduled line) and ship confirm (a ship quantity exceeding the picked quantity or an invalid carrier), as well as cross-stage conditions such as security restrictions and mid-fulfillment cancellation.

How does this page test security around fulfillment exceptions?

SyntraFlow includes variations that confirm a fulfillment action attempted outside a user's authorization, or by a user without any fulfillment access, is correctly prevented rather than silently allowed — see the Security & Persona Variations section below.

What should happen after a triggering condition is corrected?

Once the condition that caused the exception is corrected — for example supply becomes available, the hold is released, or a valid carrier is selected — the transaction should be retried and should complete successfully, with order and audit history reflecting both the original attempt and the corrected transaction.

How does this page relate to the other Fulfillment test pages?

Fulfillment Exceptions is the fifth and final scenario family in the Fulfillment cluster, following Schedule Order, Reservation, Pick Release and Ship Confirm. It does not repeat those normal-path scenarios; instead it aggregates exception coverage across all four stages to complete the Fulfillment scenario library.