Oracle ERP Testing Tool > Test Library > Financials > Accounts Payable > Payments

Syntra Standard Oracle Test Library

Oracle Fusion Void Supplier Payment Test Cases

Validate voiding of an eligible supplier payment in Oracle Fusion Payables and confirm the resulting effect on payment status and the related invoice's balance and eligibility for further payment.

Test ID	ORCL.P2P.AP.PAY.VOID
Application	Oracle Fusion Cloud
Product	Financials
Module	Accounts Payable
Process	Payments
Business Flow	Procure-to-Pay
Scenario Type	Positive / Functional
Test Usage	Functional Testing / Regression Testing / UAT
Priority	High
Automation	SyntraFlow Ready
Library	Syntra Standard

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

Test Objective

The objective of this test is to verify that an authorised Accounts Payable user can void an eligible supplier payment in Oracle Fusion Payables, and confirm the resulting effect on the payment and its related invoice.

The scenario should confirm that:

the selected payment is eligible to be voided and has not already been voided
the void date is accepted
the void reason is accepted and retained against the void transaction
payment status correctly updates to Voided
the related invoice balance and eligibility for further payment are updated correctly
the original payment remains traceable in payment history rather than being removed
accounting impact of the void is handled correctly where applicable

This scenario does not claim that every downstream accounting, reconciliation or bank-file scenario is covered — those depend on the customer's specific Oracle Fusion configuration and are addressed by separate test scenarios.

When to Use This Test

Functional testing of Oracle Fusion Accounts Payable void-payment processing for a new implementation
Regression testing of void eligibility, period and security validations after an Oracle quarterly update
UAT sign-off for AP payment controls that must correctly restrict and record voided payments
Baseline case referenced by the create-payment, partial-payment and payment-accounting scenarios within the same AP payment lifecycle

Where This Test Fits in the AP Payment Lifecycle

Existing Payment

→

Check Eligibility

→

Void Payment

→

Enter Void Date/Reason

→

Confirm

→

Payment Status Updated

→

Invoice Balance/Eligibility Updated

This test covers voiding of a previously issued supplier payment, and depends on an existing payment that is eligible to be voided. Exact eligibility rules, downstream accounting and bank-file implications depend on the customer's Oracle Fusion configuration.

← Previous Stage

Process / Electronic Payment

Next Stage →

Payment Accounting

Preconditions

Oracle Fusion Payments (Accounts Payable) is configured and available to the test user.
An existing supplier payment exists and is eligible to be voided.
The payment has not already been voided.
The test user has the appropriate security/privilege to void payments.
The accounting period intended for the void is open, or the void is otherwise permitted per period-close configuration.
The invoice associated with the payment is available and traceable.

Exact void eligibility rules, security privileges and period-close behavior may vary by Oracle Fusion implementation and configuration.

Sample Test Data

Supplier	${SUPPLIER}
Payment Number	${PAYMENT_NUMBER}
Payment Status	Issued — eligible for void
Payment Amount	${PAYMENT_AMOUNT}
Payment Method	${PAYMENT_METHOD}
Related Invoice	${INVOICE_NUMBER}
Void Date	${VOID_DATE}
Void Reason	${VOID_REASON}
Accounting Period	Open period, or a later period where void is permitted by configuration

Sample values are illustrative. Replace them with valid data from the target Oracle Fusion environment.

Test Steps

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

#	User Action	Expected Result
1	Search for the Existing Payment Navigate to the Oracle Fusion Payments work area and search for the existing supplier payment to be voided. ${SUPPLIER} / ${PAYMENT_NUMBER} This single business step replaces multiple technical actions such as opening search, entering the supplier or payment number, clicking Search and selecting the result.	The correct payment is located and its current status is confirmed as eligible for void.
2	Open the Payment Open the located payment to review its details.	The payment details page opens, showing payment amount, payment method and the related invoice.
3	Select Void Select the Void action for the payment.	The Void Payment page or dialog opens for the selected payment.
4	Enter Void Date Enter the date the payment is to be voided. ${VOID_DATE}	The void date is accepted without unexpected validation errors.
5	Enter Void Reason Enter the reason for voiding the payment. ${VOID_REASON}	The void reason is accepted and retained against the void transaction.
6	Confirm Void Confirm and submit the void.	Oracle Fusion successfully processes the void request without unexpected errors.
7	Verify Payment Status Confirm the payment's status following the void.	Payment status updates to Voided, with the void date and void reason correctly recorded.
8	Verify Invoice Balance/Eligibility UpdatedBusiness assertion Confirm the balance and payment eligibility of the invoice associated with the voided payment. ${INVOICE_NUMBER}	Invoice balance and eligibility for further payment are updated correctly to reflect the void.
9	Verify Original Payment Remains Traceable in HistoryBusiness assertion Confirm that the original payment record remains visible and traceable in payment history. This is the main business assertion for the scenario — a payment void must be traceable and must not silently remove financial history.	The original payment remains traceable, showing its Voided status and the linked void transaction, rather than being removed from history.

Expected Results

An eligible supplier payment voids successfully.
Payment status updates correctly to Voided.
Void date and void reason are correctly recorded.
Invoice balance and payment eligibility are updated to reflect the void.
The original payment remains traceable in payment history.
Accounting impact of the void is handled correctly where applicable.
No unexpected save errors occur.
The voided payment does not silently disappear from history or reporting.

Key Validation Checkpoints

Payment status becomes Voided.
Void date is correctly recorded.
Void reason is retained.
Invoice balance/status is updated correctly.
Invoice becomes eligible for further payment where applicable.
Accounting impact is handled appropriately.
Original payment remains traceable.

Core Business Scenario

Void Payment

Business Steps

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 void-payment 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 void-payment test dozens of times simply to cover different combinations of payment method, supplier, timing and eligibility condition. Jarvis uses the standard business scenario as the foundation and generates relevant variations for the customer's environment.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable business process and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — payments, suppliers, payment methods, invoices and other relevant test attributes.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant scenario variations.

Positive + Negative Test Variations

Positive, negative, boundary and configuration-specific scenarios.

Regression Pack

Selected variations can be grouped into an executable suite.

On-Demand / Scheduled / Batch Execution

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

Results + Evidence + Exceptions

Capture execution results, business assertions, screenshots/evidence and exceptions.

Rather than maintaining dozens of near-duplicate copies of the same void-payment test, SyntraFlow maintains the core business scenario and allows Jarvis AI to generate relevant variations using the customer's available test data.

AI-Generated Test Variations

The same Void Payment 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 Accounts Payable Payments.

Positive Scenarios

Void an eligible payment
Void within the same accounting period
Void in a later period where permitted by configuration
Void across different payment methods
Void across different suppliers
Void a full-amount payment
Void a partial payment
Void a payment and subsequently repay the invoice
Void with a valid, recorded reason

Negative Scenarios

Attempt to void an already-voided payment
Attempt to void a payment not eligible for void
Invalid void date entered
Void attempted in a closed accounting period
Void reason missing where required
Void attempted without the appropriate security/privilege
Void attempted on a payment in an invalid status
Void attempted after incompatible downstream processing, such as a payment already accounted or reconciled where void is prohibited

These are representative examples only. Negative scenarios and expected behavior can depend on the customer's Oracle Fusion configuration, controls and security — not every Oracle configuration behaves identically.

Generated Using Your DataVault Test Data

Generic test data rarely represents the full range of payment methods, suppliers and period conditions in a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct void-payment variations relevant to the customer's actual implementation.

Standard Library Definition

Supplier            ${SUPPLIER}
Payment Number      ${PAYMENT_NUMBER}
Payment Amount      ${PAYMENT_AMOUNT}
Payment Method      ${PAYMENT_METHOD}
Void Date           ${VOID_DATE}
Void Reason         ${VOID_REASON}
Related Invoice     ${INVOICE_NUMBER}

DataVault

Payments
  Eligible / Ineligible / Already Voided
Suppliers
  Supplier A, Supplier B, Supplier C
Payment Methods
  Check, EFT, Wire
Accounting Periods
  Open, Closed, Later-Open
Invoices
  Linked invoice balances and statuses

Jarvis AI Generates

Scenario 01 — Supplier A + Check + Same-Period Void
Scenario 02 — Supplier B + EFT + Later-Period Void
Scenario 03 — Partial Payment Void
Scenario 04 — Already-Voided Payment (Negative)
Scenario 05 — Closed-Period Void (Negative)
Scenario 06 — Unauthorized User Void (Negative)
...

Customer-specific test data and AI-generated variations are not published to the Syntra Standard Test Library. Where DataVault is connected, customer-specific data such as supplier, payment and invoice details remain within the customer's controlled SyntraFlow environment and access model.

Example Test Variations

Representative examples of void-payment 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.

ID	Variation	Type	Key Difference	Execution
VAR-001	Void Eligible Payment	Positive	Standard eligible payment voided successfully	Syntra Ready
VAR-002	Void Same-Period Payment	Positive/Period	Void dated within the same accounting period as the payment	Syntra Ready
VAR-003	Void Later-Period Payment (Where Permitted)	Positive/Period	Void dated in a later period permitted by configuration	Syntra Ready
VAR-004	Void Check Payment	Positive	Payment method = Check	Syntra Ready
VAR-005	Void EFT Payment	Positive	Payment method = Electronic Funds Transfer	Syntra Ready
VAR-006	Void Wire Payment	Positive	Payment method = Wire	Syntra Ready
VAR-007	Void Payment — Supplier A	Positive	Different supplier reference	Syntra Ready
VAR-008	Void Payment — Supplier B	Positive	Different supplier reference	Syntra Ready
VAR-009	Void Full-Amount Payment	Positive	Full payment amount voided	Syntra Ready
VAR-010	Void Partial Payment	Positive	Partial payment amount voided	Syntra Ready
VAR-011	Void Then Reissue Payment	Positive/Downstream	Invoice repaid after void with a new payment	Syntra Ready
VAR-012	Void With Valid Reason	Positive/Reason	Void reason recorded and retained	Syntra Ready
VAR-013	Attempt to Void an Already-Voided Payment	Negative	Payment status is already Voided	Syntra Ready
VAR-014	Attempt to Void an Ineligible Payment	Negative	Payment does not meet void eligibility rules	Syntra Ready
VAR-015	Invalid Void Date	Negative/Period	Void date is invalid or out of range	Syntra Ready
VAR-016	Void Attempted in Closed Period	Negative/Period	Void date falls within a closed accounting period	Syntra Ready
VAR-017	Missing Void Reason	Negative/Reason	Required void reason left blank	Syntra Ready
VAR-018	Void Attempted Without Required Security	Negative/Security	User lacks the void-payment privilege	Syntra Ready
VAR-019	Void Attempted on Invalid Payment Status	Negative	Payment status does not support void	Syntra Ready
VAR-020	Void Attempted After Incompatible Downstream Processing	Negative/Downstream	Payment already accounted or reconciled where void is prohibited	Syntra Ready

Why a Blocked Void Attempt Can Be a Passing Test

Positive Testing

Jarvis generates scenarios using combinations expected to successfully void an eligible supplier payment.

Eligible Payment + Valid Void Date + Valid Reason → Payment Voided Successfully

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's void eligibility rules, validations and security around payment voiding.

Already-Voided Payment → Expected Duplicate-Void Validation
Closed Accounting Period → Expected Period Validation
Missing Void Reason → Expected Required-Field Validation
Unauthorized User → Expected Security Validation
Incompatible Downstream Processing → Expected Void-Blocked Validation

A negative test should not be marked as failed simply because Oracle correctly blocks an invalid void attempt. If the expected Oracle validation occurs, the negative test has passed.

Scenario	Oracle Outcome	Test Result
Eligible payment	Void completes successfully	PASS
Already voided payment	Void prevented	PASS
Closed period	Period validation occurs	PASS
Unauthorized user	Security validation occurs	PASS
Unexpected system error	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

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

AP Payment Void Regression Pack

Void Eligible Payment
Void Same-Period Payment
Void Later-Period Payment (Where Permitted)
Void Check Payment
Void EFT Payment
Void Partial Payment
Void Then Reissue Payment
Attempt to Void an Already-Voided Payment
Void Attempted in Closed Period
Void Attempted Without Required Security

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

Once scheduled, SyntraFlow executes the selected void-payment scenarios unattended and records the outcome of each test and business assertion.

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

Pack	AP Payment Void Regression Pack
Schedule	Quarterly Update Regression
Tests	20 scenarios
Execution	Batch Mode
Start	10:00 PM
Environment	Oracle Fusion TEST
Status	Scheduled

Illustrative example — not a live schedule.

Review Results Across the Entire Test Pack

Users can drill from the regression pack into a scenario, its business steps, the underlying automation actions, and the evidence captured for each.

Illustrative example data — not actual production metrics.

Total Scenarios

Passed

Failed

Exceptions

Positive Tests

Negative Tests

Business Assertions

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

AP Payment Lifecycle

Several scenario families share the same lifecycle position — for example, Create Payment, Pay Invoice in Full and Partial Payment are all ways of creating a payment. Exact processing depends on payment method, bank-account configuration and customer-specific Oracle Fusion setup. Stages link to a representative test scenario family.

Create / Select→Validate→Process / Electronic Payment→

Void where required

→Account

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.

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 — Void Payment, 9 Business Steps

↓

DataVault — Customer-Specific Test Data

↓

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

Search for the Existing Payment

May internally include

Open Payments Work Area → Focus Search → Enter Supplier/Payment Number → Search → Select Payment → Confirm Eligible Status

Business Step

Confirm Void

May internally include

Review Void Details → Click Confirm/Submit → Capture Confirmation Response → Refresh Payment Status

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.

Step	Action Status	Business Validation
Enter Void Reason	Pass	—
Confirm Void	Pass	—
Verify Original Payment Remains Traceable in History	Pass	Pass

Related AP Payment Tests

Voiding a payment is one stage of the same AP payment lifecycle — explore the related create-payment, partial-payment and accounting scenarios below.

Create Payment Partial Payment Payment Accounting

Turn This Standard Test into Your Oracle AP Payment Regression Suite

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

Automate with SyntraFlow Explore Accounts Payable Payments 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

Accounts Payable Payments Test Library Accounts Payable Test Library Financials Test Library Oracle Fusion Test Library Oracle ERP Testing Tool Syntra DataVault

Frequently Asked Questions

What does voiding a payment actually reverse in Oracle Fusion?

Voiding reverses the payment itself — it cancels the payment transaction and restores the related invoice's balance and eligibility for further payment. It does not necessarily remove the underlying obligation to pay the supplier, which typically remains open on the invoice unless separately addressed.

Can a voided payment be re-created or reissued?

Where the underlying invoice remains open and eligible, a new payment can typically be created against it after the void. This scenario includes a variation that covers voiding a payment and subsequently repaying the invoice.

What happens to the invoice after a payment is voided?

The invoice balance is restored to reflect the voided amount and the invoice becomes eligible for further payment where applicable. Exact behavior can depend on the customer's Oracle Fusion configuration and invoice status.

What security considerations apply to voiding a payment?

Voiding a payment is a sensitive financial-control action. This scenario includes a negative variation confirming that a user without the appropriate security/privilege is correctly prevented from voiding a payment.

How are the many void-payment test variations generated?

Jarvis AI uses this standard void scenario together with available DataVault test data — suppliers, payment methods, payment amounts and accounting periods — to generate relevant positive and negative variations for the customer's environment.