Oracle ERP Testing Tool > Test Library > SCM > End-to-End SCM

Syntra Standard Journey Oracle Test Library

Oracle Fusion Plan-to-Procure Test Scenarios

Validate the complete Plan-to-Procure journey in Oracle Fusion SCM — demand, planning data collection, supply plan run, planned purchase order generation, release, purchase order, supplier, receipt and inventory update — with emphasis on the planning-to-procurement hand-off, the planned order correctly becoming a real procurement document with correct quantity, date and supplier, orchestrating rather than duplicating the individual Supply Planning and Procurement family pages this journey links to.

Test ID	ORCL.E2E.PLAN2PROC
Application	Oracle Fusion Cloud
Product	SCM
Module	End-to-End SCM
Process	Plan-to-Procure
Business Flow	Plan-to-Produce
Scenario Type	End-to-End / Functional
Test Usage	Functional Testing / Regression Testing / UAT
Priority	High
Automation	SyntraFlow Ready
Library	Syntra Standard Journey

Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions across each Supply Planning and Procurement family page automatically while presenting the journey as business-readable test steps for documentation, review and reporting. This scenario is presented as 7 business-readable test steps; SyntraFlow's automation executes approximately 126 underlying Oracle Fusion UI actions to complete it.

Test Objective

The objective of this test is to validate the complete Plan-to-Procure journey in Oracle Fusion SCM — demand, planning data collection, supply plan run, planned purchase order generation, release, purchase order, supplier, receipt and inventory update — with emphasis on the planning-to-procurement hand-off, specifically that a planned order correctly becomes a real procurement document with the correct quantity, date and supplier, rather than re-testing each stage's individual field-level validation, which is already covered on the linked Supply Planning and Procurement family pages this scenario orchestrates.

The scenario should confirm that:

the net demand quantity calculated during planning data collection and the supply plan run correctly drives the recommended purchase requirement
the supply plan correctly generates a planned purchase order of the correct quantity, date and supplier for net demand
releasing the planned purchase order correctly creates a matching purchase order that carries forward quantity, date and supplier
the purchase order correctly requires and receives approval per configuration before it is available for receipt
a full or partial receipt correctly reconciles against the purchase order quantity, and inventory on-hand correctly updates
late supply and other exceptions are correctly flagged rather than silently accepted
an invalid supplier source, non-purchasable item or invalid organization assignment correctly blocks planned order release
unauthorized users are correctly blocked from creating or approving a procurement document at any stage of the journey

This scenario validates the hand-offs and cross-stage data integrity of the Plan-to-Procure journey in Oracle Fusion SCM TEST/UAT environments. It does not duplicate the individual field-level scenario coverage already tested on the Collect Planning Data, Run Supply Plan, Planned Orders, Release Planned Order, Planning Exceptions, Create Purchase Order, Approve Purchase Order, Receive Purchase Order and Partial Receipt family pages — this page links to and orchestrates those live pages into an end-to-end journey.

When to Use This Test

Regression testing that net demand correctly drives a planned purchase order that becomes a real procurement document with the correct quantity, date and supplier
Validating hand-offs across the linked Supply Planning and Procurement family pages — Collect Planning Data, Run Supply Plan, Planned Orders, Release Planned Order, Planning Exceptions, Create Purchase Order, Approve Purchase Order, Receive Purchase Order and Partial Receipt — rather than re-testing each page's individual field-level scenarios
UAT sign-off for planning and procurement teams who need confidence the full plan-to-procure journey works end-to-end, not just each transaction in isolation
Diagnosing cross-stage data mismatches, invalid supplier sources, late supply or blocked planned order release before escalating as a possible APPLICATION_ERROR
Baseline orchestration scenario referenced when validating that the planning engine correctly hands off a planned purchase order into procurement across Oracle Fusion SCM

The Plan-to-Procure Journey

Demand

→

Collect Planning Data

→

Run Supply Plan

→

Planned Purchase Order

→

Release

→

Purchase Order

→

Supplier

→

Receipt

→

Inventory

This Plan-to-Procure scenario spans the full demand-to-receipt journey across Supply Planning and Procurement within Oracle Fusion SCM, orchestrating the Collect Planning Data, Run Supply Plan, Planned Orders, Release Planned Order, Planning Exceptions, Create Purchase Order, Approve Purchase Order, Receive Purchase Order and Partial Receipt family pages rather than duplicating their individual scenario coverage. From receipt, received supply typically continues into downstream inventory transactions, invoice matching or further planning cycles.

Preconditions

The Supply Planning and Procurement family pages referenced by this journey — Collect Planning Data, Run Supply Plan, Planned Orders, Release Planned Order, Planning Exceptions, Create Purchase Order, Approve Purchase Order, Receive Purchase Order and Partial Receipt — are individually functional in the target Oracle Fusion SCM environment.
A valid item, organization, sourcing rule, supplier and supply plan are available and enabled for planning and procurement.
Collected planning data is current for the supply plan under test.
The test user holds the roles required to execute each stage of the journey, or alternate unauthorized-user personas are available for security testing.
Supplier lead times, purchasing approval hierarchies and item purchasing/organization assignments are configured according to the target environment — this scenario does not assume a single universal supplier or approval configuration applies to every item.

Exact sourcing rules, supplier lead times, approval hierarchies and organization assignments vary by Oracle Fusion implementation and customer-specific configuration. This scenario validates that Oracle correctly enforces whatever configuration is in place at each hand-off, not a single universal rule.

Sample Test Data

Item	${ITEM}
Organization	${ORGANIZATION}
Plan Name	${PLAN_NAME}
Planned Order	${PLANNED_ORDER}
Supplier	${SUPPLIER}
Purchase Order	${PURCHASE_ORDER}
Quantity	${QUANTITY}
Receipt	${RECEIPT}

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 journey variation — for example, receipt fields apply only once a purchase order has been created and approved.

Test Steps

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

#	User Action	Expected Result
1	Collect Planning Data Collect current supply and demand planning data for the supply plan, referencing the standard Collect Planning Data test scenario. ${ITEM} / ${ORGANIZATION} / ${PLAN_NAME}	Planning data collection completes successfully and current supply and demand data is available to the supply plan.
2	Run the Supply Plan and Review Planned Purchase Orders Run the supply plan and review the planned purchase orders generated for net demand, referencing the standard Run Supply Plan and Planned Orders test scenarios. ${PLAN_NAME} / ${PLANNED_ORDER} / ${QUANTITY}	The supply plan correctly generates planned purchase order ${PLANNED_ORDER} for the correct quantity and required date.
3	Release the Planned Order to a Purchase Order Release the planned purchase order to create a procurement document, referencing the standard Release Planned Order test scenario. ${PLANNED_ORDER} / ${SUPPLIER} / ${REQUIRED_DATE}	Release correctly creates purchase order ${PURCHASE_ORDER} carrying forward the planned order's quantity, date and supplier.
4	Approve the Purchase Order Route the purchase order for approval per the configured approval hierarchy, referencing the standard Approve Purchase Order test scenario. ${PURCHASE_ORDER}	The purchase order correctly requires and receives approval before it is available for receipt.
5	Receive Against the Purchase Order Record a full or partial receipt against the approved purchase order, referencing the standard Receive Purchase Order and Partial Receipt test scenarios. ${PURCHASE_ORDER} / ${RECEIPT} / ${QUANTITY}	The receipt correctly reconciles against the purchase order quantity, whether full or partial.
6	Verify Inventory On-Hand UpdatesBusiness assertion Compare on-hand inventory for the item and organization before and after the receipt. ${ITEM} / ${ORGANIZATION} / ${RECEIPT} This is a primary business assertion for the journey — correctly updated on-hand inventory following receipt is the expected pass condition, not merely a successful transaction.	Inventory on-hand correctly increases by the received quantity following the receipt transaction.
7	Verify Planning Rerun Reflects the New SupplyBusiness assertion Rerun the supply plan after receipt and review the updated supply/demand balance, referencing the standard Run Supply Plan test scenario. ${PLAN_NAME} / ${ITEM} / ${REQUIRED_DATE} This is the final business assertion for the scenario — an updated, correctly reconciled supply/demand balance after rerun is the expected pass condition for the full journey.	Planning rerun correctly reflects the newly received supply, with the previously open requirement now covered.

Expected Results

Planning data collection completes successfully and current supply and demand data is available to the supply plan.
The supply plan correctly generates a planned purchase order of the correct quantity and required date for net demand.
Releasing the planned order correctly creates a purchase order carrying forward the planned order's quantity, date and supplier.
The purchase order correctly requires and receives approval before it is available for receipt.
Receipt correctly reconciles against the purchase order quantity, whether full or partial.
Inventory on-hand correctly increases by the received quantity following the receipt transaction.
Planning rerun correctly reflects the newly received supply, with the previously open requirement now covered.

Key Validation Checkpoints

net demand correctly generates a planned purchase order of the correct quantity and date
planned order supplier correctly carries into the released purchase order
purchase order correctly requires approval per configuration
receipt correctly reconciles against the purchase order quantity
late supply correctly flagged rather than silently accepted
planning rerun correctly reflects updated supply after receipt
invalid source/item/organization correctly blocks planned order release

Core Business Scenario

Plan-to-Procure

Journey Scenarios

30 Journey Scenarios

Journey Stages

9 Stages

Linked Family Pages

9 Linked Pages

Test Data

DataVault-Driven

Automation

SyntraFlow Ready

Jarvis AI

Go Beyond the Standard Test with Jarvis AI

The Syntra Standard Test Library defines the core Plan-to-Procure journey as an orchestration across the Supply Planning and Procurement family pages within SCM. Jarvis AI extends this scenario by following the pipeline from SCM to Functional Area, Process/Scenario Family and Standard Test Scenarios, then combining it with DataVault test data to generate Jarvis Variations — organized as Positive, Negative, Boundary, Integration and Security categories — before they can be assembled into a Regression Pack and Scheduled Execution, with results surfaced through Failure Intelligence.

Teams do not need to manually stitch together planning-data-collection, supply-plan-run, planned-purchase-order, release, purchase-order, approval and receipt tests for every item, organization or exception path. Jarvis uses the standard journey as the foundation and generates relevant Positive, Negative, Boundary, Integration and Security variations for the customer's environment — including invalid supplier sources, non-purchasable items, invalid organization assignments and late supply exceptions — since correctly enforced planning-to-procurement hand-offs between stages, not just individually correct transactions, is what this journey scenario proves. These Jarvis-generated variations do not create additional public SEO pages, and this page itself does not duplicate the individual scenario coverage already tested on the family pages it links to; this page remains the canonical reference for the end-to-end journey.

From Standard Test to Executed Regression Pack

SCM

Oracle Fusion SCM product area.

Functional Area — End-to-End SCM

Cross-module orchestration functional area spanning Supply Planning and Procurement within SCM.

Process / Scenario Family — Plan-to-Procure

The Plan-to-Procure journey spanning demand and planning through release, purchase order, approval and receipt.

Standard Test Scenario — Plan-to-Procure

Reusable end-to-end journey definition orchestrating the Supply Planning and Procurement family pages.

Customer DataVault

Provides approved customer-specific test data and configuration required for journey generation — Items, Organizations, Suppliers, Plans and Purchase Orders.

Jarvis Variations

Analyses the standard journey together with available test data and generates Positive, Negative, Boundary, Integration and Security variations. These variations do not create additional public test-library pages.

Regression Pack

Selected journey variations can be grouped into an executable suite.

Scheduled Execution

Execute immediately or schedule the regression pack for unattended batch execution.

Failure Intelligence

Capture execution results, business assertions, screenshots/evidence and exceptions, classified into likely failure categories.

Rather than re-testing every planning-data field, planned order, purchase order and receipt field individually — already covered on their respective family pages — SyntraFlow maintains one core Plan-to-Procure journey scenario, with 30 example end-to-end scenarios documented below, and allows Jarvis AI to generate item, organization and security-specific journey variations using the customer's available test data. These variations do not create additional public SEO pages.

AI-Generated Test Variations

The same Plan-to-Procure 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 End-to-End.

Positive Scenarios

Journey validating forecast, sales order and safety stock demand triggers correctly generate a purchase requirement
Journey validating existing supply — on-hand or open purchase orders — correctly covers demand without unnecessary new supply
Journey validating the planned purchase order is generated with the correct quantity and date
Journey validating release correctly creates a purchase order carrying forward the planned order's quantity, date and supplier
Journey validating the purchase order correctly routes for approval per configuration
Journey validating a full or partial receipt correctly reconciles against the purchase order quantity
Journey validating a planning rerun after receipt correctly reflects the updated supply/demand balance

Negative Scenarios

Journey where an invalid supplier source correctly blocks planned order release
Journey where a non-purchasable item correctly blocks planned order release
Journey where an invalid organization assignment correctly blocks planned order release
Journey where late supply against the required date is correctly flagged

These are representative examples only. Journey behavior, supplier selection and available hand-off paths can depend on the customer's Oracle Fusion configuration, sourcing rules and security — not every Oracle configuration behaves identically.

Generated Using Your DataVault Test Data

Generic test data rarely represents every item, organization, supplier and exception path in a real Oracle Fusion Plan-to-Procure journey. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct journey scenarios relevant to the customer's actual implementation.

Standard Library Definition

Item                 ${ITEM}
Organization         ${ORGANIZATION}
Plan Name            ${PLAN_NAME}
Planned Order        ${PLANNED_ORDER}
Supplier             ${SUPPLIER}
Purchase Order       ${PURCHASE_ORDER}
Quantity             ${QUANTITY}
Receipt              ${RECEIPT}

DataVault

Items
  Active, purchasable items with sourcing rules by organization
Organizations
  Planning and procurement organizations
Supply Plans
  Collected planning data by plan
Suppliers
  Approved suppliers and lead times by item
Security
  Roles authorised at each stage of the journey

Jarvis AI Generates

Scenario 01 — Standard Journey, ${ITEM}
Scenario 02 — Planned Order Released to ${SUPPLIER}
Scenario 03 — Partial Receipt Against ${PURCHASE_ORDER}
Scenario 04 — Invalid Supplier Source Blocked
Scenario 05 — Late Supply Exception
Scenario 06 — Unauthorized User Attempts Release
...

Demand, planning, purchase order and receipt data used in Plan-to-Procure testing are masked or synthetic through Syntra DataVault — never real production data. The public Syntra Standard Test Library uses illustrative placeholder data only, and where DataVault is connected, customer-specific item, organization and supplier dimensions remain within the customer's controlled SyntraFlow environment and access model, protected according to DataVault's data masking policies. See /datavault/data-masking/ for details.

Example Test Variations

This catalog spans 30 end-to-end Plan-to-Procure journey scenarios validating demand-to-planned-order-to-purchase-order-to-receipt continuity across Supply Planning and Procurement, plus negative/boundary journey testing. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.

ID	Variation	Type	Key Difference	Execution
E2E-P2PROC-001	Forecast Generates Purchase Requirement	Positive	Net demand for ${ITEM} in ${ORGANIZATION} is generated from forecast demand within supply plan ${PLAN_NAME}; the planning engine correctly calculates a purchase requirement for quantity ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-002	Sales Order Demand Generates Purchase Requirement	Positive	Net demand for ${ITEM} is generated from an open sales order rather than forecast; the planning engine correctly nets the sales-order quantity ${QUANTITY} into a purchase requirement within ${PLAN_NAME}.	SyntraFlow Ready
E2E-P2PROC-003	Safety Stock Shortage Generates Purchase Supply	Positive	A safety stock shortfall for ${ITEM} in ${ORGANIZATION} correctly generates a purchase supply requirement for the replenishment quantity ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-004	On-Hand Fully Covers Demand	Positive	Net demand for ${ITEM} is fully covered by existing on-hand inventory in ${ORGANIZATION}; the planning engine correctly recommends no new planned purchase order for quantity ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-005	Existing PO Partially Covers Demand	Positive/Integration	An existing open purchase order partially covers net demand for ${ITEM}; the planning engine correctly nets the open PO quantity and recommends a planned purchase order for the remaining balance of ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-006	Existing PO Fully Covers Demand	Positive/Integration	An existing open purchase order fully covers net demand for ${ITEM}; the planning engine correctly recommends no new planned purchase order for quantity ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-007	Planned Purchase Order Generated	Positive	Net demand for ${ITEM} in ${ORGANIZATION} correctly generates planned purchase order ${PLANNED_ORDER} within supply plan ${PLAN_NAME} for quantity ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-008	Multiple Planned Purchase Orders	Positive	Net demand for ${ITEM} across multiple required dates correctly generates multiple planned purchase orders rather than a single order that misrepresents timing, each carrying its own quantity and required date.	SyntraFlow Ready
E2E-P2PROC-009	Planned Order Supplier Selection	Positive	Planned purchase order ${PLANNED_ORDER} for ${ITEM} correctly selects supplier ${SUPPLIER} per the item's configured sourcing rule, rather than an arbitrary or default supplier.	SyntraFlow Ready
E2E-P2PROC-010	Planned Order Date Validation	Positive/Boundary	The due date recommended on planned purchase order ${PLANNED_ORDER} for ${ITEM} is correctly calculated from required date ${REQUIRED_DATE} net of supplier lead time ${LEAD_TIME}.	SyntraFlow Ready
E2E-P2PROC-011	Planned Quantity Validation	Positive/Boundary	The quantity recommended on planned purchase order ${PLANNED_ORDER} for ${ITEM} correctly equals net demand quantity ${QUANTITY} after netting on-hand and existing supply.	SyntraFlow Ready
E2E-P2PROC-012	Release Planned Order	Positive	Releasing planned purchase order ${PLANNED_ORDER} for ${ITEM} correctly initiates creation of a procurement document, referencing Release Planned Order.	SyntraFlow Ready
E2E-P2PROC-013	Released Planned Order Creates Procurement Document	Positive/Integration	Releasing planned purchase order ${PLANNED_ORDER} correctly creates purchase order ${PURCHASE_ORDER} for supplier ${SUPPLIER}, carrying forward quantity ${QUANTITY} and required date ${REQUIRED_DATE}, referencing Create Purchase Order.	SyntraFlow Ready
E2E-P2PROC-014	Supplier Lead-Time Impact	Positive/Boundary	Supplier ${SUPPLIER}'s configured lead time ${LEAD_TIME} is correctly factored into the due date recommended on planned purchase order ${PLANNED_ORDER} for ${ITEM} relative to required date ${REQUIRED_DATE}.	SyntraFlow Ready
E2E-P2PROC-015	Invalid Supplier Source	Negative	Planned purchase order ${PLANNED_ORDER} for ${ITEM} references a supplier source that is not approved or active for ${ORGANIZATION}; release is correctly blocked rather than creating purchase order ${PURCHASE_ORDER} against an invalid supplier.	SyntraFlow Ready
E2E-P2PROC-016	Item Not Purchasable	Negative	${ITEM} is not enabled as purchasable in ${ORGANIZATION}; release of planned purchase order ${PLANNED_ORDER} is correctly blocked rather than generating purchase order ${PURCHASE_ORDER}.	SyntraFlow Ready
E2E-P2PROC-017	Invalid Organization Assignment	Negative	${ITEM} is not correctly assigned to ${ORGANIZATION} for procurement; release of planned purchase order ${PLANNED_ORDER} is correctly blocked rather than silently creating a purchase order in an unassigned organization.	SyntraFlow Ready
E2E-P2PROC-018	Late Supply Exception	Negative/Boundary	The due date recommended on planned purchase order ${PLANNED_ORDER} for ${ITEM}, net of supplier ${SUPPLIER}'s lead time ${LEAD_TIME}, falls after required date ${REQUIRED_DATE}; the planning engine correctly flags the late-supply exception rather than silently accepting it as on-time.	SyntraFlow Ready
E2E-P2PROC-019	Expedite Recommendation	Positive	A demand pull-in for ${ITEM} correctly generates an expedite recommendation on planned purchase order ${PLANNED_ORDER}, moving the recommended due date earlier to meet required date ${REQUIRED_DATE}.	SyntraFlow Ready
E2E-P2PROC-020	Defer Recommendation	Positive	A demand push-out for ${ITEM} correctly generates a defer recommendation on planned purchase order ${PLANNED_ORDER}, moving the recommended due date later to align with required date ${REQUIRED_DATE}.	SyntraFlow Ready
E2E-P2PROC-021	Cancel Recommendation	Positive	Excess planned supply for ${ITEM} in ${ORGANIZATION} correctly generates a cancel recommendation on planned purchase order ${PLANNED_ORDER} rather than leaving unneeded supply in the plan.	SyntraFlow Ready
E2E-P2PROC-022	PO Approved	Positive	Purchase order ${PURCHASE_ORDER} created from released planned purchase order ${PLANNED_ORDER} correctly routes for approval per the configured approval hierarchy before becoming available for receipt, referencing Approve Purchase Order.	SyntraFlow Ready
E2E-P2PROC-023	Partial Receipt	Positive	A partial receipt of quantity less than ${QUANTITY} against purchase order ${PURCHASE_ORDER} correctly records receipt ${RECEIPT} and leaves the remaining PO quantity open, referencing Partial Receipt.	SyntraFlow Ready
E2E-P2PROC-024	Full Receipt	Positive	A full receipt of quantity ${QUANTITY} against purchase order ${PURCHASE_ORDER} correctly records receipt ${RECEIPT} and closes the PO line for receiving, referencing Receive Purchase Order.	SyntraFlow Ready
E2E-P2PROC-025	Planning Rerun After Receipt	Positive/Integration	Rerunning supply plan ${PLAN_NAME} after receipt ${RECEIPT} for ${ITEM} correctly reflects the newly received on-hand quantity, referencing Run Supply Plan.	SyntraFlow Ready
E2E-P2PROC-026	Demand Covered After Receipt	Positive/Integration	After receipt ${RECEIPT} against purchase order ${PURCHASE_ORDER}, the originating net demand for ${ITEM} in ${ORGANIZATION} is correctly shown as covered rather than still open.	SyntraFlow Ready
E2E-P2PROC-027	Planning Collection Failure	Negative	Planning data collection for supply plan ${PLAN_NAME} fails or returns incomplete data for ${ITEM}; the supply plan run correctly reflects the collection failure rather than generating a planned purchase order from stale or incomplete data, referencing Collect Planning Data.	SyntraFlow Ready
E2E-P2PROC-028	Correct Planning Data and Rerun	Positive	After correcting the planning data collection issue for ${ITEM} and rerunning supply plan ${PLAN_NAME}, planned purchase order ${PLANNED_ORDER} is correctly generated for quantity ${QUANTITY}.	SyntraFlow Ready
E2E-P2PROC-029	Planning-to-Procurement Traceability	Positive/Integration	The document reference chain from net demand through planned purchase order ${PLANNED_ORDER} to purchase order ${PURCHASE_ORDER} and receipt ${RECEIPT} is correctly traceable end-to-end for ${ITEM}.	SyntraFlow Ready
E2E-P2PROC-030	End-to-End Supply Reconciliation	Positive/Integration	Across the full Plan-to-Procure journey for ${ITEM} in ${ORGANIZATION}, net demand quantity ${QUANTITY}, planned purchase order ${PLANNED_ORDER}, purchase order ${PURCHASE_ORDER} and receipt ${RECEIPT} are correctly reconciled to zero open requirement.	SyntraFlow Ready

Positive and Negative Journey Testing

Positive Testing

Jarvis generates journey scenarios using demand signal, item, organization, supplier and plan combinations expected to successfully complete the Plan-to-Procure journey in Oracle Fusion.

Correctly Generated Planned Purchase Order + Valid Supplier Source + Approved Purchase Order → Receipt Reconciled

Negative Testing

Jarvis can also generate journey scenarios designed to exercise Oracle's validations around invalid supplier sources, non-purchasable items, invalid organization assignments and late supply at any stage of the hand-off.

Invalid Supplier Source → Expected Block on Planned Order Release
Item Not Purchasable → Expected Block on Planned Order Release
Invalid Organization Assignment → Expected Block on Planned Order Release
Late Supply Against Required Date → Expected Flag Rather Than Silent Acceptance

A negative end-to-end scenario passes when Oracle correctly enforces the expected data, configuration or security rule at any stage of the journey.

Scenario	Oracle Outcome	Test Result
Valid journey data at every stage	Journey completes end-to-end	PASS
Data mismatch between stages	Validation or warning occurs	PASS
Missing required upstream document	Validation occurs	PASS
Unauthorized user at any stage	Access prevented	PASS
Unexpected application exception	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

Users can select generated Plan-to-Procure journey scenarios and group them into reusable execution packs.

SCM End-to-End Plan-to-Procure Regression Pack

Forecast Generates Purchase Requirement
Planned Purchase Order Generated
Release Planned Order
Released Planned Order Creates Procurement Document
PO Approved
Partial Receipt
Full Receipt
Invalid Supplier Source
Late Supply Exception
Planning Rerun After Receipt

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

Once scheduled, SyntraFlow executes the selected Plan-to-Procure journey scenarios unattended and records the outcome of each stage hand-off and business assertion.

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

Pack	SCM End-to-End Plan-to-Procure Regression Pack
Schedule	Quarterly Update Regression
Tests	30 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 journey scenario, its business steps, the underlying automation actions across each Supply Planning and Procurement family page, 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

DataVault Journey Persona

This persona groups the linked-entity dimensions that must stay consistent across the Plan-to-Procure journey as DataVault-supplied test data flows from planning data collection through to the purchase order and receipt.

Persona: Standard Planning-Driven Procurement Journey

Item	${ITEM}
Organization	${ORGANIZATION}
Plan Name	${PLAN_NAME}
Planned Order	${PLANNED_ORDER}
Supplier	${SUPPLIER}
Purchase Order	${PURCHASE_ORDER}
Quantity	${QUANTITY}
Required Date	${REQUIRED_DATE}
Receipt	${RECEIPT}
Lead Time	${LEAD_TIME}

Keeping these dimensions linked across DataVault-supplied test data lets Jarvis generate journey variations that remain internally consistent from planning data collection through to the released purchase order and its receipt.

Security & Approval Variations

Access to each stage of the Plan-to-Procure journey — collecting planning data, running the supply plan, releasing a planned order to a purchase order, approving the purchase order, or receiving against it — is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that access behaves as expected at each stage — not to assert a single universal Oracle security model.

Persona	Action	Expected	Syntra Result
Planning Analyst	Release Planned Order to Purchase Order	Allowed	PASS
Procurement Buyer	Approve and Receive Purchase Order	Allowed	PASS
Unauthorized User	Attempts to Release Planned Order Without Role	Access prevented	PASS

Cross-Stage Business Assertions

These assertions validate that quantity, date, document linkage and supplier data remain consistent as the journey crosses from Supply Planning into Procurement.

QUANTITY_CONTINUITYDATE_CONTINUITYDOCUMENT_LINKAGEENTITY_CONTINUITY

Stage Transition	Assertion	Example	Status
Planning -> Planned Purchase Order	Net Demand Qty = Planned PO Qty	Net demand ${QUANTITY} for ${ITEM} = planned order ${PLANNED_ORDER} qty	PASS
Planned PO -> Release	Release correctly creates a matching purchase order	Released planned order ${PLANNED_ORDER} creates ${PURCHASE_ORDER}	PASS
PO -> Receipt	Received Qty <= PO Qty / configured tolerance	Receipt qty ${RECEIPT_QTY} within tolerance of PO qty ${PO_QTY}	PASS
Receipt -> Planning Rerun	Received supply correctly reduces net requirement	Planning rerun for ${ITEM} reflects new on-hand from ${RECEIPT}	PASS

Illustrative example using DataVault variables — not hard-coded production values.

Stage-by-Stage Execution Evidence

This example shows execution status recorded at each stage of one illustrative Plan-to-Procure journey run, including how a failure at one stage blocks downstream stages.

1Demand / Planning

PASS

2Planned Purchase Order

PASS

3Release

PASS

4Purchase Order

PASS

5Receipt

FAIL

6Inventory

NOT RUN

Failed Stage

Receipt

Upstream Passed

Downstream Blocked

Illustrative example run — not a live execution.

Journey Failure Model

This example shows how a failure at the Receipt stage is classified and reported without blocking visibility into which upstream stages already passed.

Journey: Plan-to-Procure Failed Stage: Receipt

Upstream Status

Planning	PASS
Planned Purchase Order	PASS
Purchase Order	PASS

Scenario

Late Supply Exception

Expected Result

Purchase order receipt occurs on or before the planned order's required date.

Actual Result

Supplier lead time places the expected receipt date 6 days after the required date.

Failure Classification

CONFIGURATION_ERROR

Blocking Impact / Downstream Status

Inventory not replenished by the required date; downstream demand at risk.

Recommended Action

Verify supplier lead-time setup, expedite the purchase order, or evaluate an alternate supply source.

Do not label as an Oracle application defect without eliminating data, configuration, security, automation, environment and integration causes first.

Additional Named Regression Packs

This journey can be executed as one pack or split into focused packs covering specific behavior.

Plan-to-Procure Standard Pack

Forecast Generates Purchase Requirement
Planned Purchase Order Generated
Release Planned Order
PO Approved
Full Receipt
Demand Covered After Receipt

Plan-to-Procure Exception Pack

Invalid Supplier Source
Item Not Purchasable
Invalid Organization Assignment
Late Supply Exception
Planning Collection Failure

Plan-to-Procure Rebalancing Pack

Expedite Recommendation
Defer Recommendation
Cancel Recommendation
Planning Rerun After Receipt

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 Plan-to-Procure journey, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary, Integration and Security coverage for the customer's environment, following the SCM → Functional Area → Scenario Family → Standard Test Scenarios → DataVault Test Data → Jarvis Variations → Regression Pack → Scheduled Execution → Failure Intelligence pipeline. These variations do not create additional public SEO pages, and this page itself does not duplicate the individual scenario coverage already tested on the Supply Planning and Procurement family pages it links to and orchestrates.

Generate

Positive, Negative, Boundary, Integration and Security journey variations.

Parameterize

Use relevant test data from DataVault.

Assemble

Build reusable regression packs.

Execute

Run journey scenarios autonomously across family pages.

Schedule

Execute unattended test batches.

Validate

Evaluate expected cross-stage 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 — Plan-to-Procure, 7 Business Steps

↓

DataVault — Customer-Specific Test Data

↓

Jarvis AI — Generate Positive + Negative + Boundary + Integration + Security Variations

↓

Regression Pack — Select Relevant Journey Coverage

↓

SyntraFlow Execution — Each Journey Variation

↓

Detailed UI Actions Across Family Pages

↓

Cross-Stage Business Assertions

↓

Evidence

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Release the Planned Order to a Purchase Order

May internally include

Open Release Planned Order → Select Planned Order → Confirm Supplier/Quantity/Date → Release → Open Create Purchase Order → Confirm Document Created → Confirm Cross-Reference to Planned Order

Business Step

Receive Against the Purchase Order

May internally include

Open Receive Purchase Order → Search Purchase Order → Enter Receipt Quantity → Confirm Full or Partial Receipt → Save → Confirm Inventory On-Hand Updated

What SyntraFlow Captures Per Run

Cross-page journey orchestrationParameterised input valuesReusable navigation across family pagesAutomation action traceScreenshots / evidence captureExecution timingBusiness assertions across stagesEnvironment-independent test data

Action Status vs. Business Validation

A successful UI interaction at any single stage does not automatically prove the end-to-end journey is correct — this is illustrative of how SyntraFlow separates action success from cross-stage business validation; it does not reflect a specific live execution. When a hand-off fails, SyntraFlow's evidence trail is designed to help a tester classify the likely cause across an 8-category taxonomy — DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: Late Supply Exception — Likely category: CONFIGURATION_ERROR — Evidence: Supplier lead time for ${ITEM} places the expected receipt date after required date ${REQUIRED_DATE} — Recommendation: Verify supplier lead-time setup, expedite the purchase order, or evaluate an alternate supply source. A failure should never be labeled as an Oracle defect without first eliminating data, configuration, security, automation, environment and integration causes.

Step	Action Status	Business Validation
Released Planned Order Creates Procurement Document	Pass	—
Demand Covered After Receipt	Pass	Pass
Planning Rerun After Receipt	Pass	Pass

Related End-to-End Journeys & Family Tests

Plan-to-Procure orchestrates the Supply Planning and Procurement family pages into a single journey, and links directly to the individual family pages it references.

Plan-to-Produce (End-to-End)Procure-to-Pay (End-to-End)Demand-to-Supply (End-to-End)

Turn This Standard Journey into Your Oracle SCM Plan-to-Procure Regression Suite

Start with the Syntra Standard Plan-to-Procure journey, use DataVault to provide environment-specific test data, let Jarvis generate additional item, organization and security variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore SCM End-to-End 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 SCM End-to-End Test Library Collect Planning Data Run Supply Plan Planned Orders Release Planned Order Planning Exceptions Create Purchase Order Approve Purchase Order Receive Purchase Order Partial Receipt Syntra DataVault DataVault Data Masking

Frequently Asked Questions

How does this Plan-to-Procure page differ from the individual Collect Planning Data, Run Supply Plan, Release Planned Order and other family pages?

This page does not duplicate the atomic scenario coverage already tested individually on the Collect Planning Data, Run Supply Plan, Planned Orders, Release Planned Order, Planning Exceptions, Create Purchase Order, Approve Purchase Order, Receive Purchase Order and Partial Receipt family pages, which span Supply Planning and Procurement. Instead, it describes and links to those live pages, showing how they connect into an end-to-end plan-to-procure flow, and adds scenarios that specifically test the hand-offs and cross-stage data integrity between them — for example, whether the planned order correctly becomes a purchase order with the correct quantity, date and supplier, and whether a receipt correctly reconciles against that purchase order.

What does the Journey Failure Model on this page show?

The Journey Failure Model shows a representative example of how a failure at one stage — for example, Receipt — is captured alongside which upstream stages already passed, the expected versus actual result, a failure classification, and the downstream impact. It is illustrative, not a live execution, and is designed to help a tester quickly understand where in the journey a hand-off broke down.

Does this scenario assume the same supplier is always selected for a planned purchase order?

No. Supplier selection on a planned purchase order depends on the item's configured sourcing rule, organization and available approved suppliers, and is never treated as a universal recommendation. This scenario validates that the planning engine correctly selects and carries forward whichever supplier is configured for each item, rather than assuming one supplier applies across the board.

What do the cross-stage business assertions validate on this page?

The cross-stage assertions validate that quantity, date, document linkage and supplier data remain consistent as the journey crosses from planning into procurement — for example, that net demand quantity correctly matches the planned purchase order quantity, that the planned order's due date correctly carries into the purchase order's need-by date, and that the planned order, purchase order and receipt correctly cross-reference each other.

What do the failure-intelligence categories mean for a failed Plan-to-Procure journey test?

When a hand-off between stages fails, SyntraFlow's evidence trail helps a tester classify the likely cause across an 8-category taxonomy — DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR. A failure should never be labeled as an Oracle defect without first eliminating data, configuration, security, automation, environment and integration causes.

How does security testing work across a multi-stage journey like this?

Access to each stage — collecting planning data, releasing a planned order to a purchase order, approving the purchase order, or receiving against it — is controlled by Oracle Fusion's security configuration, which varies by customer. SyntraFlow can execute representative persona-based variations across the journey, such as a planning analyst or procurement buyer versus an unauthorized user, to confirm that access behaves as expected at each stage, without asserting a single universal Oracle security model.