Oracle Back-to-Back Order Testing

What Is a Back-to-Back Order in Oracle Order Management?

A back-to-back order is a sales order line for an item that is sourced on demand rather than from existing on-hand stock. When the order is booked, Oracle evaluates the item's sourcing rule and, if it is flagged for back-to-back fulfillment, automatically creates a supply order — a purchase requisition if the item is bought, or a work order if the item is manufactured. That supply order is immediately tied back to the originating sales order line, and Inventory creates an order-specific reservation so the supply, once it exists, is held for that order and cannot be allocated to any other demand.

Everything downstream depends on that reservation surviving the journey intact: the requisition converting to a purchase order, the purchase order being received (or the work order being completed), the receipt or completion consuming the reservation, and the order line finally becoming eligible to pick and ship. A break at any point — a requisition created without the order link, a receipt that doesn't consume the right reservation, a date change on the PO that never reflows to the customer promise date — produces an order that looks fine in Order Management but is quietly stuck.

Dimension	Standard order (from stock)	Back-to-back order	Drop-ship order
Supply source	Existing on-hand inventory	New purchase or work order, triggered by the sales order	Supplier's own stock
Where supply is received	Already in company inventory	Company's own warehouse or site	Directly to the customer
Reservation	Against existing on-hand quantity	Order-specific, created against future supply	None in company inventory — no receipt into stock
Fulfillment step after supply	Pick, pack, ship	Receive/complete, consume reservation, pick, pack, ship	Supplier ship confirms the order directly
Typical trigger	Available-to-promise from stock	No on-hand supply; item sourcing rule set to back-to-back	Item sourced directly from a supplier per sourcing rule
Primary testing owner page	Sales Order Testing	This page	Drop Ship Testing

Scope note — what this page owns. This page tests the back-to-back linkage: sourcing determination, supply-order creation, order-specific reservation, and reservation consumption through to fulfillment. It does not repeat general inventory reservation mechanics — see Inventory Testing — or the depth of standard purchase order testing, covered on the Procurement Testing Tool. This page tests where those two processes connect to the sales order.

Back-to-back vs. drop-ship. The two are frequently confused because both create supply on demand rather than shipping from stock. The distinction is where the supply lands: back-to-back supply is received into the company's own inventory or site first, then picked and shipped to the customer through normal fulfillment; drop-ship supply never enters the company's inventory at all — the supplier ships directly to the customer. A line incorrectly flagged one way instead of the other changes who owns the shipment, what gets received, and what the reservation actually reserves. See Oracle Drop Ship Testing for the supplier-direct flow.

Why Testing Back-to-Back Orders Matters

Because a back-to-back order line depends on a chain of records across three modules, the failure modes are different from a standard stock order — and less visible until a shipment is late. The risks specific to back-to-back:

Risk	Example	Potential impact	Testing response
Reservation not created	Supply order created but no order-specific reservation follows	Supply consumable by any competing order	Assert a reservation exists on every supply order
Wrong supply type determined	Buy item routes to a work order, or vice versa	Wrong demand signal; delayed or failed fulfillment	Test buy/make determination against item setup
Supply-order link broken	Requisition or work order created without the order reference	Orphaned supply; no automatic fulfillment trigger	Verify the order-line link field on every supply order
Reservation not consumed on receipt	Receipt or completion posts but order line stays unfulfilled	Manual intervention; missed ship date	Test reservation consumption immediately after receipt
Cancellation doesn't release reservation	Order cancelled but reservation remains held	Unusable, un-reservable inventory; orphaned supply order	Negative test on cancellation plus reservation state
Date changes don't re-flow	Supplier push-out not reflected on the sales order	Customer promise-date accuracy erodes	Test date propagation from supply order to order line
Back-to-back / drop-ship misclassification	Item flagged for the wrong fulfillment path	Wrong receiving location; cost and timing exposure	Test sourcing-rule determination explicitly per item
Cross-order reservation leakage	Reserved supply consumed by an unrelated order	Broken order-specific promise; customer disputes	Test reservation isolation under concurrent demand
Partial-receipt mishandling	Partial receipt consumes the full reservation	Under-shipment to the customer	Test partial receipt against reservation math
Open-order visibility gap	Open back-to-back orders not visible to service or planning	Missed exception management on late orders	Test open-order and supply-status reporting
Silent release change	Quarterly update alters requisition or reservation logic	Undetected process break across three modules	Release-aware regression on the full back-to-back flow

The Oracle Back-to-Back Order Process Flow

The flow crosses Order Management, Procurement or Manufacturing, and Inventory in sequence. Each arrow below is a handoff a test suite must verify independently — a passing order line does not confirm the handoff behind it worked.

Back-to-back sequence

Order line flagged back-to-back → Supply order created (PO or work order) → Order-specific reservation applied → Supply received / completed → Reservation consumed → Order line fulfilled & shipped

Trigger: booking a sales order line for an item whose sourcing rule is set to back-to-back with no eligible on-hand supply.
Key validations: item eligibility, correct buy/make determination, requisition or work order reference back to the order line, reservation created against the new supply order.
Decision point: receipt or work order completion event determines whether the reservation is fully, partially, or not yet consumed.
Exceptions: supply order cancellation, sales order cancellation, date change, supplier delay, over- or under-receipt each branch the flow and must release or adjust the reservation correctly.
Expected output: the order line reaches a fulfillable state only once its own reservation is fully consumed — never before, and never using another order's supply.
Downstream impact: pick release, shipping, and revenue recognition all assume the reservation-to-fulfillment link held correctly.

Suggested visual: a swimlane diagram spanning Order Management, Procurement/Manufacturing, and Inventory lanes with the reservation and exception branches, for the web team to produce.

Testing Scope & Coverage Matrix

The dimensions a complete back-to-back test suite must cover, with automation suitability and priority.

Test area	What must be validated	Example scenario	Automation	Priority
Functional (happy path)	Order line flags, supply creates, ships on time	Buy item, clean requisition to receipt	High	High
Sourcing determination	Buy vs. make routed correctly by item setup	Make item generates a work order, not a PO	High	High
Reservation integrity	Order-specific reservation created, isolated, consumed	Competing order cannot allocate reserved supply	High	High
Boundary / receipt variance	Partial, full, over-, and under-receipt behaviour	Partial receipt leaves order correctly open	High	High
Exception / cancellation	Reservation release on supply or order cancellation	Sales order cancelled with open PO	Medium	High
Date propagation	Supply-side date changes reflect on order schedule date	Supplier delay pushes promise date	High	High
Cross-module linkage	OM, Inventory, and Procurement/Manufacturing stay in sync	Supply order visible from the sales order line	High	High
Mixed sourcing on one order	Back-to-back and drop-ship lines coexist correctly	Each line fulfils independently	Medium	Medium
Role-based	Supply status visibility matches role	Customer service sees status, not procurement detail	Medium	Medium
Integration / API	Integration-created demand behaves like UI-entered demand	EDI order triggers identical supply linkage	High	Medium
Reporting	Open back-to-back orders and supply status queryable	Open-order inquiry matches underlying records	High	Medium
Regression / release	Flow behaviour unchanged after an update	Re-run pack after a quarterly update	High	High

Oracle Back-to-Back Order Test Scenarios

A representative set of 33 Oracle Fusion back-to-back scenarios — sourcing determination, reservation integrity, receipt variance, cancellation and date-change exceptions, cross-BU and mixed-sourcing cases, and regression. Test IDs use the OM-BB prefix.

ID	Scenario	Preconditions	Expected result	Pri	Auto
OM-BB-001	Flag sales order line as back-to-back at entry	Item back-to-back enabled; no on-hand supply	Line shows back-to-back sourcing indicator	H	Y
OM-BB-002	Attempt back-to-back flag on non-eligible item	Item not enabled for back-to-back sourcing	Flag rejected; standard sourcing applied	H	Y
OM-BB-003	Supply-type determination — buy item	Item sourced from an approved supplier	Purchase requisition created as supply	H	Y
OM-BB-004	Supply-type determination — make item	Item has manufacturing routing/BOM	Work order created as supply	H	Y
OM-BB-005	Purchase requisition auto-created from order line	Buy item, no on-hand supply	Requisition generated referencing the order line	H	Y
OM-BB-006	Work order auto-created from order line	Make item, no on-hand supply	Work order generated referencing the order line	H	Y
OM-BB-007	Requisition approval workflow before PO conversion	Requisition value above approval threshold	Requisition routes for approval before PO creation	M	Y
OM-BB-008	Supply order linked to originating sales order	Supply order (PO or work order) confirmed	Order-line reference visible on both records	H	Y
OM-BB-009	Order-specific reservation created	Supply order created	Reservation created tying supply to the order line	H	Y
OM-BB-010	Reservation prevents allocation to other orders	Reserved supply; second competing order for the item	Second order cannot consume reserved supply	H	Y
OM-BB-011	Partial supply receipt against back-to-back PO	PO partially received	Partial reservation consumed; balance remains open	H	Y
OM-BB-012	Full supply receipt against back-to-back PO	PO fully received	Full reservation consumed; line ready to ship	H	Y
OM-BB-013	Work order completion consumes reservation	Work order reports full completion	Completed quantity consumes the reservation	H	Y
OM-BB-014	Reservation consumption triggers fulfillment eligibility	Reservation fully consumed	Order line becomes eligible for pick/ship	H	Y
OM-BB-015	Supply order cancellation before receipt	PO/work order cancelled, nothing received	Reservation released; line returns for re-sourcing	H	Y
OM-BB-016	Supply order cancellation after partial receipt	PO/work order cancelled, partial quantity received	Received quantity retained; remaining reservation released	M	Y
OM-BB-017	Sales order cancellation with open supply order	Order cancelled while PO/work order still open	Supply order flagged/cancelled per policy; reservation released	H	P
OM-BB-018	Supply order date change re-flows to schedule date	Buyer changes the PO promise date	Sales order schedule date updates accordingly	H	Y
OM-BB-019	Supplier delay impact on order promise date	Supplier-acknowledged date slips	Order schedule date and exception flag reflect the delay	H	Y
OM-BB-020	Multiple back-to-back lines on one order	Order has two or more back-to-back eligible lines	Each line generates its own linked supply and reservation	M	Y
OM-BB-021	Back-to-back combined with drop-ship on same order	One line back-to-back, another line drop-ship	Each line follows its own fulfillment path independently	H	P
OM-BB-022	Back-to-back item substitution	Approved substitute item configured	Supply and reservation created for the substitute item	M	P
OM-BB-023	Over-receipt of supply against the PO	Receipt quantity exceeds PO quantity	Over-receipt handled per tolerance; excess not mis-reserved	M	Y
OM-BB-024	Under-receipt of supply against the PO	Receipt quantity less than ordered	Order line remains partially unfulfilled; shortage visible	H	Y
OM-BB-025	Supply order price variance vs. order price	PO price differs from sales order cost assumption	Variance visible on the order without blocking fulfillment	M	Y
OM-BB-026	Cross-business-unit back-to-back sourcing	Supplying BU differs from the selling BU	Reservation and supply link correctly across BUs	M	P
OM-BB-027	Reservation transfer between orders	Authorized user reassigns reserved supply	Reservation moves; original order line un-reserved	M	P
OM-BB-028	Back-to-back return / RMA flow	Customer returns a fulfilled back-to-back line	Return processed; supply/reservation history retained	M	Y
OM-BB-029	Integration-created back-to-back demand	Order created via integration/EDI with a back-to-back item	Same supply, reservation, and linkage as UI-entered order	H	Y
OM-BB-030	API-triggered supply order creation	Order created via REST API	Supply order created and linked identically to the UI path	M	Y
OM-BB-031	Role-based visibility into supply order status	Customer service role views the order	Role sees supply/reservation status without excess access	M	P
OM-BB-032	Reporting on open back-to-back orders	Open back-to-back orders exist across statuses	Inquiry returns accurate open-order and supply status	M	Y
OM-BB-033	Quarterly-release regression on back-to-back flow	Post-update tenant	End-to-end back-to-back scenarios reproduce prior results	H	Y

Pri = priority (H/M/L). Auto = automation candidate (Y suitable · P partly, needs role/data setup). Steps summarised; full step detail ships in the downloadable test pack.

Common Back-to-Back Defects

Defect	Likely cause	Business impact	Recommended test
No reservation created	Supply order created outside the expected path	Supply consumed by wrong order	OM-BB-009, OM-BB-010
Wrong buy/make routing	Item sourcing rule misconfigured	Delayed or failed supply creation	OM-BB-003, OM-BB-004
Supply order missing order reference	Link field not populated on creation	Orphaned supply; no fulfillment trigger	OM-BB-005, OM-BB-006, OM-BB-008
Reservation not consumed at receipt	Receipt/completion event doesn't trigger consumption	Order stuck though supply has arrived	OM-BB-011 to 014
Reservation survives cancellation	Cancellation logic doesn't release the reservation	Inventory unusable; orphaned supply order	OM-BB-015 to 017
Schedule date not updated	Date change on supply order doesn't propagate	Customer promise date wrong	OM-BB-018, OM-BB-019
Mixed-sourcing order breaks a line	Back-to-back and drop-ship logic collide	One line blocks or duplicates fulfillment	OM-BB-021
Over-receipt mis-reserved	Tolerance not applied to reservation math	Excess supply incorrectly tied to the order	OM-BB-023
Cross-BU link failure	BU-to-BU sourcing setup incomplete	Reservation fails to tie back to the order	OM-BB-026
API demand behaves differently than UI	Integration path skips a validation the UI enforces	Inconsistent fulfillment for integrated orders	OM-BB-029, OM-BB-030
Open-order reporting inaccurate	Report doesn't reflect real-time supply status	Service teams give customers wrong answers	OM-BB-032

How SyntraFlow Automates Back-to-Back Order Testing

SyntraFlow drives the full chain — order entry, supply-order creation, reservation, and receipt — and asserts the linkage held at every step, not just that each screen completed.

AI-assisted test generation

Generates back-to-back variants — buy/make combinations, partial receipts, cancellation timing — from your item and sourcing setup.

Self-healing execution

Playwright-based runs that re-anchor when Oracle changes order, requisition, or work order pages, so end-to-end runs keep working.

Cross-pillar orchestration

Runs a single test that spans Order Management, Procurement or Manufacturing, and Inventory as one continuous scenario.

Dynamic test data

The Oracle Data Vault provisions items, sourcing rules, suppliers, and BOMs that produce the specific supply and reservation each test needs.

Reservation-level assertions

Verifies the reservation record itself — created, isolated, and consumed — the difference between a real test and a hollow one.

UI + API execution

Runs order entry and supply creation through both the UI and REST and confirms the two produce the same linkage.

Evidence capture

Timestamped screenshots, reservation logs, and execution traces retained as audit-grade evidence across every module touched.

Release-impact selection

Runs the back-to-back subset a given release actually affects, instead of the full pack every quarter.

Configuration-aware testing

Ties each test to the sourcing rules and options that drive it, so a configuration change re-points the right tests.

A note on capability. AI-assisted generation, self-healing execution, cross-pillar orchestration, UI/API testing, and evidence capture are current platform capabilities. Coverage scoped to your specific sourcing rules, business units, and approval thresholds is configurable during onboarding. Any tenant-specific extension is confirmed at assessment rather than assumed here.

When to Re-Test Back-to-Back Orders

Because back-to-back depends on configuration in three modules at once, any change to one of them is a regression trigger. Retest when these events occur:

Change event	Risk to back-to-back flow	Recommended regression scope
Oracle quarterly update	Requisition, work order, or reservation logic changes	Full back-to-back pack, release-scoped
Item sourcing rule change	Buy/make/drop-ship determination shifts	Sourcing-determination cases
Approval workflow change	Requisition-to-PO conversion timing shifts	Requisition approval cases
Inventory reservation setup change	Reservation creation or consumption behaviour changes	Reservation integrity cases
Manufacturing routing/BOM change	Work order completion behaviour changes	Make-item completion cases
New BU / site / legal entity	Cross-BU linkage gaps	Cross-business-unit cases
Security-role change	Supply-status visibility changes	Role-based visibility cases
Integration / API change	Integration-created demand diverges from UI	API + integration cases
Production defect fix	Fix may regress adjacent linkage or reservation logic	Targeted + smoke back-to-back pack

Back-to-Back Orders & Oracle Quarterly Releases

Oracle's quarterly updates can change any leg of the back-to-back chain independently — requisition creation rules in Procurement, work order behaviour in Manufacturing, or reservation logic in Inventory — without an equivalent change appearing in Order Management. Because the flow only works when all three stay in sync, a change on one side is easy to miss until an order stalls.

Rather than re-testing the entire back-to-back pack on every release, SyntraFlow Release Intelligence narrows the work to what actually changed in your tenant:

1.Analyses Oracle release notes for changes touching Order Management, Procurement, Manufacturing, or Inventory reservations.
2.Maps those changes to your sourcing rules, requisition setup, and reservation configuration.
3.Identifies which back-to-back item categories and order types are affected.
4.Recommends the specific end-to-end test cases to run.
5.Prioritises regression execution by risk to promise-date accuracy.
6.Tracks evidence across all three modules for audit and sign-off.

See how the impact map is built on the Release Impact Analysis page.

Configurations That Drive Back-to-Back Behaviour

A back-to-back test is only trustworthy if the configuration behind sourcing, requisitioning, and reservation is known and stable. These setups determine whether an order line flows correctly end to end — and when they drift between environments, a passing test proves nothing about production.

Configuration area	Testing impact	Example failure	Recommended validation
Item sourcing rules	Determine back-to-back vs. drop-ship vs. standard	Item flagged for the wrong fulfillment path	Sourcing-determination cases
Supply-order type mapping	Governs buy vs. make routing	Buy item mapped to a work order	Buy/make determination cases
Requisition approval rules	Set approval thresholds before PO conversion	Threshold differs from production	Approval workflow cases
Reservation rules	Define how and when reservations are created/consumed	Reservation not created on requisition	Reservation integrity cases
Business unit / sourcing assignments	Control which BU supplies which selling BU	Cross-BU assignment missing	Cross-business-unit cases
Receiving tolerances	Set acceptable over/under-receipt limits	Tolerance differs from prod	Over-/under-receipt cases
Manufacturing routing/BOM	Drives make-item work order behaviour	Routing change alters completion timing	Work order completion cases
Role and duty setup	Governs who sees supply-order status	Visibility drift between roles	Role-based visibility cases

SyntraFlow's Configuration Intelligence compares these setups across environments and flags drift before it corrupts a back-to-back test result — so a passing test means the configuration was correct, not just present.

Back-to-Back Integration Points

Back-to-back sits at the junction of three modules. These are the connections a back-to-back test must respect:

Integration	Data exchanged	Key test	Failure risk
Procurement	Requisition, PO status, receipt quantities and dates	Requisition creation and receipt trigger order updates	Requisition/PO not linked to order line
Manufacturing	Work order status and completion quantities	Completion consumes the correct reservation	Completion doesn't flow back to order line
Inventory	Order-specific reservations, on-hand supply	Reservation isolation and consumption	Reservation leaks to another order
Shipping	Pick release eligibility	Line becomes shippable only after full reservation consumption	Premature pick release
Costing	Standard/actual cost vs. supply order price	Price variance surfaces without blocking fulfillment	Variance silently absorbed or blocks shipment
OIC / REST APIs	Order and supply-order create/update calls	API-created demand parity with UI	API/UI linkage divergence

For the broader order-to-cash chain this flow feeds into, see Oracle Order Management Testing Tool.

Back-to-Back Testing Best Practices

01

Assert the reservation record itself, not just that the order line eventually ships.

02

Test the full chain end to end — order, supply order, reservation, receipt — not each module in isolation.

03

Cover both buy and make paths; they exercise different downstream systems.

04

Test cancellation at every stage — before receipt, after partial receipt, and from the sales order side.

05

Verify date changes propagate in both directions between supply order and sales order.

06

Run concurrent-demand tests to confirm reservation isolation actually holds.

07

Test mixed-sourcing orders — back-to-back and drop-ship lines together — not just single-line orders.

08

Validate through UI and API/integration paths — bulk and integrated orders rely on the latter.

09

Re-run the pack on every quarterly update, scoped by release impact across all three modules.

10

Capture evidence at each hop — order, requisition/work order, reservation, receipt — for audit trace-through.

11

Include cross-business-unit cases when supply and selling BUs differ.

12

Re-validate coverage after any sourcing-rule, approval, or reservation-configuration change.

Manual vs Generic Automation vs SyntraFlow

For back-to-back order testing specifically.

Capability	Manual	Generic automation	SyntraFlow
Cross-pillar orchestration (OM + Inventory + Procurement/Mfg)	Manual, high effort	No	Yes
Reservation-level assertions	Manual	No	Yes
Pre-built back-to-back cases	No	No	Yes
Maintenance effort	Very high	High	Low
Self-healing on Redwood	N/A	No	Yes
Release-impact analysis	No	No	Yes
Configuration awareness	Manual	No	Yes
UI + API testing	Partial	Partial	Yes
Audit-grade evidence across modules	Weak	Partial	Yes

Oracle Back-to-Back Order Test Pack

A structured pack covering supply-creation scenarios across buy and make paths, order-specific reservation conditions, cancellation and date-change exceptions, and cross-module expected results — with evidence and sign-off fields ready for a quarterly regression cycle.

It's built to extend directly from the scenario table above, mapped to your item sourcing rules and business unit setup rather than a generic template.

Request the Test Pack

Related Oracle Order Management Pages

Back-to-back connects directly to sales order entry, drop-ship, inventory, and procurement testing. Go deeper on adjacent topics:

Oracle Order Management Testing Tool ⭐

The Order Management testing hub.

Sales Order Testing →

Order entry, pricing, and scheduling.

Drop Ship Testing →

Supplier-direct fulfillment testing.

Inventory Testing Tool →

Reservation and on-hand mechanics.

Procurement Testing Tool →

Requisition-to-PO testing depth.

Oracle Data Vault →

Test data behind every scenario.

Frequently Asked Questions

What is a back-to-back order in Oracle Order Management?

▼

A back-to-back order is a sales order line for an item with no available on-hand supply, where booking the line automatically triggers a purchase requisition or work order, ties that supply order to the sales order, and creates a reservation so the supply is held for that order once it exists.

How is back-to-back different from drop-ship?

▼

Both create supply on demand, but the destination differs. Back-to-back supply is received into the company's own inventory or site and then picked, packed, and shipped through normal fulfillment. Drop-ship supply never enters company inventory — the supplier ships directly to the customer. See Drop Ship Testing for the supplier-direct flow.

What triggers supply creation in a back-to-back order?

▼

Booking a sales order line for an item whose sourcing rule is set to back-to-back, where no eligible on-hand supply exists, automatically generates the supply order — a purchase requisition for a buy item or a work order for a make item.

How does Oracle decide whether to buy or make the item?

▼

The determination follows the item's configured sourcing setup — items sourced from an approved supplier generate a purchase requisition, while items with a manufacturing routing and bill of materials generate a work order. Testing must confirm this routing is correct for every item category, not assumed.

What is an order-specific reservation and why does it matter?

▼

It is a reservation tied to one sales order line rather than to general on-hand stock, created against the supply order as soon as it exists. Without it, the supply that arrives could be allocated to any competing order, breaking the promise made to the original customer.

What happens if the back-to-back supply order is cancelled?

▼

The order-specific reservation should release, and the sales order line should return to an unfulfilled state eligible for re-sourcing. If cancellation happens after a partial receipt, the received quantity is retained and only the remaining reservation is released — both paths need explicit test coverage.

How do supply order date changes affect the sales order schedule date?

▼

A date change on the purchase order or work order — including a supplier-acknowledged delay — should re-flow to the sales order's schedule date so the customer promise stays accurate. Testing confirms this propagation happens automatically rather than requiring manual reconciliation.

Can back-to-back and drop-ship lines exist on the same order?

▼

Yes, when different lines on the same order use different sourcing rules. Each line should follow its own fulfillment path independently — testing must confirm one line's processing doesn't block or interfere with the other.

What happens on partial or over-receipt of back-to-back supply?

▼

A partial receipt should consume only the matching portion of the reservation, leaving the order line open for the balance. An over-receipt should be handled within tolerance without mis-reserving the excess quantity to the order. Both are boundary cases worth explicit testing.

How do you test back-to-back orders across business units?

▼

Create an order in the selling business unit for an item sourced from a different supplying business unit, and confirm the supply order and reservation still link correctly across the BU boundary — this is a common gap when BU-to-BU sourcing assignments are incomplete.

Does back-to-back order testing cover inventory reservation testing in depth?

▼

No. This page covers the order-specific reservation created as part of the back-to-back linkage. General inventory reservation, allocation, and on-hand mechanics are covered in depth on Inventory Testing.

How do you automate Oracle back-to-back order testing?

▼

SyntraFlow orchestrates the full chain — order entry, requisition or work order creation, reservation, and receipt — as one continuous scenario, asserting the linkage and reservation state at each step. It self-heals across Redwood page changes and captures evidence for every run.

How often should back-to-back flows be regression tested?

▼

On every Oracle quarterly update, and after any change to item sourcing rules, requisition approval setup, reservation configuration, or manufacturing routings. Because the flow spans three modules, a change in any one of them is a regression trigger for the whole chain.

What test data does back-to-back testing need?

▼

Items configured for back-to-back sourcing with both buy and make examples, valid suppliers and routings, business unit sourcing assignments, and approval hierarchies. SyntraFlow's Oracle Data Vault provisions this data so tests produce the intended supply and reservation reliably rather than relying on hand-built fixtures.

Can back-to-back supply orders be tested through APIs?

▼

Yes. Orders created through integration or REST should trigger the same supply-order creation and reservation linkage as orders entered through the UI. A complete suite tests both paths and confirms they produce identical results, since integrated and bulk orders rely on the API path.