Oracle ERP Testing Tool > Test Library > SCM > Procurement > Receiving
Syntra Standard Oracle Test Library

Oracle Fusion Inspect Receipt Test Cases

Validate receipt inspection where inspection routing or configuration is enabled — reviewing the received quantity, recording accepted and rejected quantities, capturing inspection notes, and confirming inspection status and downstream inventory or return processing.

Test IDORCL.P2P.PROC.RCV.INSPECT
ApplicationOracle Fusion Cloud
ProductSCM / Procurement
ModuleProcurement
ProcessReceiving
Business FlowProcure-to-Pay
Scenario TypePositive / Functional
Test UsageFunctional Testing / Regression Testing / UAT
PriorityMedium
AutomationSyntraFlow Ready
LibrarySyntra Standard

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

Test Objective

Validate receipt inspection where inspection routing or configuration is enabled for the applicable item or purchase order — including review of the received quantity, recording of accepted and rejected quantities against the inspection, capture of inspection notes or a rejection reason, submission of the inspection decision, and confirmation that inspection status and downstream inventory or return processing reflect the recorded outcome.

The scenario should confirm that:

  • a receipt pending inspection can be opened and reviewed by an authorized inspector
  • accepted and rejected quantities can be recorded against the inspection and are accepted by Oracle Fusion
  • accepted and rejected quantities sum correctly to the received quantity
  • inspection notes or a rejection reason can be captured where applicable
  • inspection status updates correctly following the inspection decision
  • accepted quantity is correctly made available for downstream inventory processing
  • rejected quantity is correctly routed to the applicable return path, where configured
  • users without appropriate access cannot complete a receipt inspection

This scenario does not claim that every Oracle Fusion customer uses receipt inspection, nor that every inspection routing rule or disposition outcome is exercised — coverage depends on whether inspection routing is implemented and configured for the applicable item or purchase order.

When to Use This Test

  • Functional testing of a new Oracle Fusion Procurement inspection routing implementation, where the feature is configured
  • Regression testing after an Oracle quarterly update
  • UAT sign-off for receiving inspection workflows and access control
  • Baseline case referenced by receiving, return-to-supplier and receiving-exception scenarios within the same lifecycle

Where This Test Fits in the Receiving Process

Receive Purchase Order
Inspect Receipt
Return to Supplier
Receiving Exceptions

Where inspection routing is configured for an item or purchase order, inspection typically occurs after the receipt is created and before the received quantity is available for putaway or further processing. Not every Oracle Fusion customer configures or requires receipt inspection.

Preconditions

  1. Oracle Fusion Procurement access is configured and available for the test user.
  2. The item or purchase order line is configured for inspection routing, where inspection is implemented.
  3. A receipt exists for the item and is pending inspection.
  4. An inspector is assigned with appropriate access to complete receipt inspections.
  5. Inventory and return-to-supplier routing configuration exists for accepted and rejected quantities, where applicable.

Exact inspection routing rules, tolerance levels and return-to-supplier configuration vary by Oracle Fusion implementation. Receipt inspection is not used by every Oracle Fusion customer, and this test applies only where inspection routing is implemented and configured.

Sample Test Data

Receipt Number${RECEIPT_NUMBER}
Item${ITEM}
Received Quantity${RECEIVED_QUANTITY}
Accepted Quantity${ACCEPTED_QUANTITY}
Rejected Quantity${REJECTED_QUANTITY}
Inspector${INSPECTOR} — user assigned to complete the inspection
Inspection Notes / Reason${INSPECTION_NOTES} — required for rejected or partially rejected quantities, where configured

Inspection routing, tolerance levels and disposition rules are defined per Oracle Fusion customer implementation. This test intentionally uses placeholders such as ${ACCEPTED_QUANTITY} and ${REJECTED_QUANTITY} rather than fixed values — actual values should be sourced from DataVault or the customer's receiving configuration, where receipt inspection is implemented.

Test Steps

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

#User ActionExpected Result
1
Sign In
Sign in to Oracle Fusion as the user responsible for completing receipt inspections.
${INSPECTOR}
The user signs in successfully and lands on the home page.
2
Navigate to Pending Inspections
Navigate to the Receiving work area and open the list of receipts pending inspection.
The list of receipts pending inspection displays for the applicable inspector.
3
Open the Receipt
Open the specific receipt that is pending inspection.
${RECEIPT_NUMBER}

This single business step replaces multiple technical actions such as locating the receipt and opening the inspection entry page.

The receipt opens showing the item and received quantity awaiting inspection.
4
Review Received Quantity
Review the item and received quantity recorded on the receipt.
${ITEM} / ${RECEIVED_QUANTITY}
Item and received quantity details are displayed accurately for inspection.
5
Enter Accepted and Rejected Quantities
Enter the accepted and rejected quantities resulting from the inspection.
${ACCEPTED_QUANTITY} / ${REJECTED_QUANTITY}
Accepted and rejected quantities are accepted by Oracle Fusion without unexpected errors.
6
Enter Inspection Notes or Reason
Enter inspection notes or a rejection reason, where applicable to the inspection outcome.
${INSPECTION_NOTES}
Notes or a rejection reason are recorded against the inspection.
7
Submit Inspection
Submit the completed inspection decision.
The inspection is submitted without unexpected errors.
8
Verify Accepted/Rejected Quantities and Downstream StatusBusiness assertion
Confirm the accepted and rejected quantities, inspection status, and downstream inventory or return-to-supplier processing reflect the recorded inspection outcome.
${ACCEPTED_QUANTITY} / ${REJECTED_QUANTITY}

This is the main business assertion for the scenario — the test does not stop merely because the inspection submission was accepted successfully.

Accepted quantity is correctly available for downstream inventory processing and rejected quantity is correctly routed to the applicable return path, with inspection status updated to reflect the decision.

Expected Results

  • Received quantity and item details are correctly displayed for a receipt pending inspection.
  • Accepted and rejected quantities can be recorded and sum correctly to the received quantity.
  • Inspection notes or a rejection reason are captured where applicable to the outcome.
  • The inspection is submitted and inspection status updates accordingly.
  • Accepted quantity is correctly made available downstream for inventory processing.
  • Rejected quantity is correctly routed to the applicable return-to-supplier path, where configured.
  • Users without appropriate access cannot complete a receipt inspection.

Key Validation Checkpoints

  • Accepted and rejected quantities are recorded correctly and sum to the received quantity.
  • Inspection status updates correctly following the inspection decision.
  • Downstream inventory and/or return-to-supplier routing reflects the recorded inspection outcome.
Core Business Scenario
Inspect Receipt
Business Steps
8
Test Variations
AI-Generated
Test Data
DataVault-Driven
Execution
On-Demand / Scheduled / Batch
Automation
SyntraFlow Ready
Jarvis AI

Go Beyond the Standard Test with Jarvis AI

The Syntra Standard Test Library defines the core receipt inspection business scenario. Jarvis AI can extend this scenario by generating additional positive and negative test variations using customer-specific test data and configuration available through Syntra DataVault.

Teams do not need to manually duplicate the same inspection test dozens of times simply to cover different items, quantities and inspection outcomes. Jarvis uses the standard business scenario as the foundation and generates relevant variations for the customer's configured inspection routing, where receipt inspection is implemented.

From Standard Test to Executed Regression Pack

01
Syntra Standard Test
Reusable business process and automation logic.
02
Customer DataVault
Provides approved customer-specific test data and configuration required for scenario generation — Items, Receipts, Inspectors and other relevant test attributes.
03
Jarvis AI
Analyses the standard scenario together with available test data and generates relevant scenario variations.
04
Positive + Negative Test Variations
Positive, negative, boundary and configuration-specific scenarios.
05
Regression Pack
Selected variations can be grouped into an executable suite.
06
On-Demand / Scheduled / Batch Execution
Execute immediately or schedule the regression pack for unattended batch execution.
07
Results + Evidence + Exceptions
Capture execution results, business assertions, screenshots/evidence and exceptions.

Rather than maintaining dozens of near-duplicate copies of the same inspection test, SyntraFlow maintains the core business scenario and allows Jarvis AI to generate relevant variations using the customer's available receiving configuration — sourced from DataVault or customer configuration, and only where receipt inspection is implemented.

AI-Generated Test Variations

The same Inspect Receipt 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 Procurement Receiving.

Positive Scenarios
  • Accept all received quantity
  • Reject all received quantity
  • Partial accept / partial reject
  • Different inspection outcomes
  • Different items
Negative Scenarios
  • Item not eligible for inspection
  • Invalid quantity entered
  • Inspection quantity exceeds received quantity
  • Missing inspection reason
  • Unauthorized user attempts inspection

These are representative examples only. Inspection routing, tolerance levels and expected behavior depend on the customer's Oracle Fusion configuration — receipt inspection is not used by every Oracle Fusion customer, and inspection data is never hard-coded; it is sourced from DataVault or the customer's configuration where available.

Generated Using Your DataVault Test Data

Generic test data cannot represent a real Oracle Fusion receiving configuration. Where connected, Jarvis can use approved test data available through Syntra DataVault — item, receipt, quantities and inspector — to create variations relevant to the customer's actual implementation, where receipt inspection is configured.

Standard Library Definition

Receipt Number           ${RECEIPT_NUMBER}
Item                      ${ITEM}
Received Quantity         ${RECEIVED_QUANTITY}
Accepted Quantity         ${ACCEPTED_QUANTITY}
Rejected Quantity         ${REJECTED_QUANTITY}
Inspector                 ${INSPECTOR}
Inspection Notes / Reason ${INSPECTION_NOTES}

DataVault

Items
  Item A (Inspection Required)
  Item B (Inspection Required)
Receipts
  Receipt 1001
  Receipt 1002
Inspectors
  Inspector A
  Inspector B
Inspection Outcomes
  Accepted
  Rejected
  Partial Accept / Reject
  Pending Review

Jarvis AI Generates

Scenario 01 — Item A + Accept All
Scenario 02 — Item A + Reject All
Scenario 03 — Item B + Partial Accept/Reject
Scenario 04 — Item Not Eligible for Inspection
Scenario 05 — Inspection Quantity Exceeds Received Quantity
Scenario 06 — Unauthorized User Attempts Inspection
...

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. Receiving configuration — including inspection routing, tolerance levels and return-to-supplier rules — is customer-specific and, where DataVault is connected, is sourced from DataVault or the customer's own configuration rather than assumed by SyntraFlow.

Example Test Variations

Representative examples of scenarios Jarvis can generate from this business scenario. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.

IDVariationTypeKey DifferenceExecution
VAR-001Accept All Received QuantityPositive/OutcomeFull received quantity accepted; nothing rejectedSyntra Ready
VAR-002Reject All Received QuantityPositive/OutcomeFull received quantity rejected; nothing acceptedSyntra Ready
VAR-003Partial Accept / Partial RejectPositive/OutcomeReceived quantity split between accepted and rejectedSyntra Ready
VAR-004Inspection Outcome — Pending ReviewPositive/OutcomeInspection recorded but held for further review before final dispositionSyntra Ready
VAR-005Item — Item APositive/ItemInspection completed against Item ASyntra Ready
VAR-006Item — Item BPositive/ItemInspection completed against Item BSyntra Ready
VAR-007Accepted Quantity Routed to InventoryPositive/OutcomeAccepted quantity confirmed available in the applicable inventory locationSyntra Ready
VAR-008Rejected Quantity Routed to Return to SupplierPositive/OutcomeRejected quantity confirmed routed to the return-to-supplier path, where configuredSyntra Ready
VAR-009Item Not Eligible for InspectionNegative/ItemInspection attempted against an item not configured for inspection routingSyntra Ready
VAR-010Invalid Quantity EnteredNegativeAccepted or rejected quantity entered as a non-numeric or negative valueSyntra Ready
VAR-011Inspection Quantity Exceeds Received QuantityNegative/OutcomeCombined accepted and rejected quantity entered greater than the received quantitySyntra Ready
VAR-012Missing Inspection ReasonNegativeRejected quantity submitted without a required inspection reasonSyntra Ready
VAR-013Unauthorized User Attempts InspectionNegativeA user without inspector access attempts to complete a receipt inspectionSyntra Ready

Automatically Expand Positive and Negative Test Coverage

Positive Testing

Jarvis generates scenarios using combinations expected to successfully complete the receipt inspection business process, where inspection routing is enabled.

Receipt + ${ITEM} + Accepted/Rejected Quantities Entered → Inspection Status Updated and Downstream Routing Correct

Negative Testing

Jarvis can generate scenarios designed to exercise Oracle's receiving validations, quantity checks and access controls.

  • Item Not Eligible for Inspection → Expected Configuration Validation
  • Invalid Quantity Entered → Expected Field Validation
  • Inspection Quantity Exceeds Received Quantity → Expected Quantity Validation
  • Missing Inspection Reason → Expected Submission Validation
  • Unauthorized User Attempts Inspection → Expected Access Validation

A negative receiving scenario passes when Oracle correctly raises the expected validation.

ScenarioOracle OutcomeTest Result
Valid receiptReceipt createdPASS
Closed POPO status validation occursPASS
Over receiptQuantity validation occursPASS
Security restrictionAccess preventedPASS
Unexpected application exceptionUnexpected failureFAIL

Turn AI-Generated Variations into a Regression Pack

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

Inspect Receipt Regression Pack

  • Accept All Received Quantity
  • Reject All Received Quantity
  • Partial Accept / Partial Reject
  • Item — Item A
  • Item — Item B
  • Accepted Quantity Routed to Inventory
  • Rejected Quantity Routed to Return to Supplier
  • Item Not Eligible for Inspection
  • Inspection Quantity Exceeds Received Quantity
  • Unauthorized User Attempts Inspection
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 scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.

Once scheduled, SyntraFlow executes the selected 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
PackInspect Receipt Regression Pack
ScheduleQuarterly Update Regression
Tests13 scenarios
ExecutionBatch Mode
Start10:00 PM
EnvironmentOracle Fusion TEST
StatusScheduled

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.

13
Total Scenarios
12
Passed
1
Failed
0
Exceptions
8
Positive Tests
5
Negative Tests
36
Business Assertions

Regression Pack → Scenario → Business Step → Automation Action → Evidence

Security & Persona Variations

SyntraFlow validates receipt inspection access control by confirming that an assigned inspector can complete a receipt inspection, and that an unauthorized user is correctly prevented from completing one.

PersonaActionExpectedSyntra Result
InspectorComplete InspectionAllowedPASS
Unauthorized UserAttempts InspectionAccess preventedPASS

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 business scenario, available DataVault test data and expected business outcomes to generate additional test coverage for the customer's environment, including Positive, Negative, Boundary and Security variations relative to the customer's configured inspection routing.

Generate
Positive and negative variations.
Parameterize
Use relevant test data from DataVault.
Assemble
Build reusable regression packs.
Execute
Run scenarios autonomously.
Schedule
Execute unattended test batches.
Validate
Evaluate expected business outcomes.

How SyntraFlow Automates This Test

The Standard Test defines the scenario; DataVault, Jarvis AI and SyntraFlow's execution engine take it from a single reusable business definition to executed, evidenced regression coverage.

Standard Library — Inspect Receipt, 8 Business Steps
DataVault — Customer-Specific Item and Inspection Configuration
Jarvis AI — Generate Positive + Negative Variations
Regression Pack — Select Relevant Coverage
SyntraFlow Execution — Each Variation
Detailed UI Actions
Business Assertions
Evidence
PASS / FAIL

Business Step → Underlying UI Actions

Business Step
Enter Accepted and Rejected Quantities
May internally include
Open Inspection Entry → Enter Accepted Quantity → Enter Rejected Quantity → Validate Quantities Sum to Received
Business Step
Submit Inspection
May internally include
Open Inspection Review → Confirm Notes/Reason → Submit Inspection → Confirm Status Update

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

StepAction StatusBusiness Validation
Submit InspectionPass
Confirm Status Update AcceptedPass
Verify Accepted/Rejected Quantities and Downstream StatusPassPass

Related Receiving Tests

Receipt inspection is one stage of the broader receiving lifecycle — explore the related receipt creation, return and exception-handling scenarios below.

Turn This Standard Test into Your Oracle Inspect Receipt Regression Suite

Start with the Syntra Standard receipt inspection test, use DataVault to provide environment-specific item and inspection configuration, let Jarvis generate additional positive and negative variations, and execute the resulting regression pack automatically with SyntraFlow.

Use This Oracle Fusion Test Case

Download Test Case

Excel, CSV or JSON export.

Coming soon

Automate with SyntraFlow

Run this script against your own tenant today.

Frequently Asked Questions

What triggers inspection routing for a receipt in Oracle Fusion?
Inspection routing is driven by item and purchase order configuration — for example, an item may be flagged as inspection-required, or a supplier or category may be configured to route receipts for inspection. Exact routing rules are defined per Oracle Fusion customer implementation.
Does every receipt require inspection?
No. Receipt inspection applies only where inspection routing is enabled or configured for the applicable item, category or purchase order. Many receipts move directly to putaway without an inspection step. This test applies only where inspection routing is implemented.
What happens to the rejected quantity after inspection?
Where inspection routing is configured, rejected quantity is typically routed to a return-to-supplier or disposition path, depending on the customer's receiving configuration. SyntraFlow variations validate that rejected quantity is correctly reflected and routed, consistent with the applicable configuration.
How is security tested as part of this scenario?
SyntraFlow includes variations that confirm an assigned inspector can complete a receipt inspection, and that a user without the required role or access is correctly prevented from completing one — see the Security & Persona Variations section below.
How does SyntraFlow help identify why an inspection test failed?
SyntraFlow execution evidence is designed to help distinguish between data, configuration, security, automation, application, environment and expected-validation causes of a failure. For example: Inspect Receipt failed — Likely category: CONFIGURATION_ERROR — Evidence: item is not configured for inspection routing — Recommended action: review inspection routing configuration for the item. A failure should not be labeled as an Oracle defect without supporting evidence.