Oracle ERP Testing Tool > Test Library > SCM > Procurement > Suppliers

Syntra Standard Oracle Test Library

Oracle Fusion Supplier Bank Account Test Cases

Validate the creation and maintenance of supplier payment bank information in Oracle Fusion SCM Procurement — bank, branch and routing detail, payment method and currency — with sensitive banking values masked or restricted in test evidence and reports.

Test ID	ORCL.P2P.PROC.SUPPLIER.BANK
Application	Oracle Fusion Cloud
Product	SCM / Procurement
Module	Procurement
Process	Suppliers
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 8 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 validate that supplier payment bank information can be created and maintained in Oracle Fusion SCM Procurement where applicable, using valid bank, branch, account and routing details, payment method and currency, and that sensitive banking values are appropriately protected throughout the process.

The scenario should confirm that:

a new supplier bank account can be added with valid bank, branch, account and routing details
the bank account is correctly associated with the intended supplier (and supplier site, where applicable)
the selected payment method and currency are correctly reflected on the bank account
an existing supplier bank account can be updated where the business process requires it
sensitive banking values are masked or restricted in captured test evidence and reports
Oracle correctly enforces validation and security restrictions when data errors, configuration errors or unauthorized access are introduced (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION)

This scenario covers creation and maintenance of supplier payment bank information within Oracle Fusion SCM Procurement TEST/UAT environments only. It does not cover the underlying supplier or supplier site creation, which are covered by the separate Create Supplier and Create Supplier Site scenarios in the same Suppliers cluster, and it never uses real bank account numbers, routing numbers or other sensitive banking information.

When to Use This Test

Functional testing of supplier bank account setup for a new Oracle Fusion SCM Procurement implementation
Regression testing of supplier banking configuration after an Oracle quarterly update
UAT sign-off for payables/banking specialists who maintain supplier payment bank information
Security testing to confirm supplier banking data access is correctly restricted to authorized personas
Baseline case referenced by the Create Supplier, Update Supplier and Create Supplier Site scenarios within the same Suppliers cluster

Where This Test Fits in the Procure-to-Pay Suppliers Process

Navigate to Supplier

→

Open Banking Information

→

Add Bank Account

→

Enter Account/Routing Details

→

Select Payment Method/Currency

→

Save

→

Verify & Confirm Masking

Supplier Bank Account maintenance builds on an existing, active supplier record — typically created through the Create Supplier and Create Supplier Site scenarios in this same cluster — and is a precondition for electronic supplier payment processing in Accounts Payable. Because it involves sensitive banking data, access to this task is typically more restricted than general supplier record updates. Exact fields, mandatory attributes and access restrictions vary by Oracle Fusion implementation, banking country/branch configuration and customer-specific security setup.

Preconditions

The supplier exists and is active in the target Oracle Fusion SCM environment.
The test user has appropriate — typically restricted — access to maintain supplier banking data.
Bank and bank branch configuration required for the intended payment method is already set up in the environment.
A valid payment method and currency are configured for the supplier's business unit.
The supplier site to which the bank account will apply, where applicable, is active.

Exact fields, mandatory banking attributes, and access restrictions vary by Oracle Fusion implementation, banking country/branch configuration and customer-specific security setup.

Sample Test Data

Supplier	${SUPPLIER}
Supplier Site	${SUPPLIER_SITE}
Bank Name	${BANK_NAME}
Bank Branch	${BANK_BRANCH}
Routing Details	${ROUTING_DETAILS}
Bank Account Number	${BANK_ACCOUNT_NUMBER}
Payment Method	${PAYMENT_METHOD}
Currency	${CURRENCY}

Sample values are illustrative placeholder tokens only. Never use real bank account numbers, routing numbers or other sensitive banking information as test data — always substitute ${PLACEHOLDER} tokens with valid, non-sensitive values from the target Oracle Fusion TEST/UAT environment.

Test Steps

8 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	Sign In With Appropriate Banking Access Sign in to Oracle Fusion using an authorised test user with appropriate — typically restricted — access to supplier banking data.	Oracle Fusion home page is displayed and the user session is established with the correct banking data access.
2	Navigate to Supplier Banking Information Navigate to the supplier record and open the banking information for the correct supplier, and supplier site where applicable. ${SUPPLIER} / ${SUPPLIER_SITE}	The supplier's banking information page opens for the correct supplier.
3	Add a New Bank Account Initiate adding a new bank account for the supplier. This single business step replaces multiple technical actions such as opening the add bank account panel and confirming the supplier context.	A new, unsaved bank account entry is opened for the supplier.
4	Enter Account and Routing Details Enter the bank name, branch, account number and routing details for the new bank account. ${BANK_NAME} / ${BANK_BRANCH} / ${ROUTING_DETAILS} / ${BANK_ACCOUNT_NUMBER}	The bank, branch, account and routing details are accepted without unexpected validation errors.
5	Select Payment Method and Currency Select the payment method and currency the bank account will support. ${PAYMENT_METHOD} / ${CURRENCY}	The selected payment method and currency are accepted and reflected on the bank account.
6	Review Entered Bank Account Information Review the entered bank, branch, account, routing and payment attribute information before saving. Reviewing the bank account before saving lets the tester catch an incorrect field entry before it is created.	The reviewed information matches the entered supplier, bank, routing and payment attribute data.
7	Save the Bank Account Save the bank account for the supplier in the test environment.	Oracle Fusion accepts the bank account submission and processes it without unexpected errors.
8	Verify Association and Appropriate Handling of Sensitive DataBusiness assertion Reopen the supplier's banking information and confirm the bank account is correctly associated, payment attributes are correct, and sensitive values are masked or restricted in captured evidence and reports. This is the primary business assertion for the scenario — a correctly associated bank account that also protects sensitive banking data is the expected pass condition, not merely a successful save.	The bank account is correctly associated with the supplier, payment attributes are correct, and sensitive banking values are masked or restricted in evidence and reports.

Expected Results

A new bank account is successfully added for the supplier.
The bank account is correctly associated with the correct supplier, and supplier site where applicable.
Payment method, currency and other payment attributes are correct.
Bank, branch and routing details are captured correctly.
Only appropriately authorized users can create, update or view supplier banking data.
Sensitive banking values are masked or restricted in test evidence and reports.

Key Validation Checkpoints

The bank account is associated correctly with the correct supplier and site.
Payment attributes — payment method, currency and account status — are correct.
Sensitive banking values are handled appropriately, with masking or restriction applied in evidence and reports.

Core Business Scenario

Supplier Bank Account

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 Supplier Bank Account scenario. Jarvis AI can extend this scenario by generating additional bank, currency, payment method and security variations using customer-specific test data and configuration available through Syntra DataVault, with sensitive banking fields masked.

Teams do not need to manually duplicate the same supplier bank account test dozens of times simply to cover different combinations of bank, branch, currency or payment method, or to separately validate that banking data access is correctly restricted. Jarvis uses the standard scenario as the foundation and generates relevant Positive, Negative, Boundary and Security variations for the customer's environment — with particular emphasis on security, given the sensitivity of banking data.

From Standard Test to Executed Regression Pack

Syntra Standard Test

Reusable Supplier Bank Account scenario and automation logic.

Customer DataVault

Provides approved customer-specific test data and configuration required for scenario generation — Suppliers, Bank Names, Branches, Payment Methods and Currencies, where configured and connected.

Jarvis AI

Analyses the standard scenario together with available test data and generates relevant bank, currency, payment method and security variations.

Positive + Negative Test Variations

Bank, branch, currency and payment-method-specific scenarios, plus exception and access-restriction conditions.

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, masked screenshots/evidence and exceptions.

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

AI-Generated Test Variations

The same Supplier Bank Account 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 Suppliers.

Positive Scenarios

Add a new supplier bank account
Add bank accounts in different currencies
Add bank accounts using different payment methods
Update an existing supplier bank account
Supplier configured with multiple eligible bank accounts

Negative Scenarios

Attempt to add an invalid bank account number
Attempt to add an account for an invalid or unconfigured bank
Attempt to add a duplicate bank account
Attempt to add an account at an inactive bank
Attempt to save a bank account without required routing details
Attempt to add or view a bank account under a security restriction preventing access

These are representative examples only. Bank account configuration, payment method availability and access restrictions depend entirely on the customer's Oracle Fusion configuration and banking setup — this list is not exhaustive and does not represent a claim of universal support.

Generated Using Your DataVault Test Data

Generic test data rarely represents the actual bank, branch, payment method and currency configuration of a real Oracle Fusion environment — and supplier banking data is too sensitive to publish in a public test library. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Supplier Bank Account variations relevant to the customer's actual implementation, with sensitive banking fields masked throughout.

Standard Library Definition

Supplier                ${SUPPLIER}
Supplier Site            ${SUPPLIER_SITE}
Bank Name                ${BANK_NAME}
Bank Branch              ${BANK_BRANCH}
Routing Details          ${ROUTING_DETAILS}
Bank Account Number      ${BANK_ACCOUNT_NUMBER}
Payment Method           ${PAYMENT_METHOD}
Currency                 ${CURRENCY}

DataVault

Suppliers / Supplier Sites
  Active suppliers and sites per business unit
Banks / Branches
  Configured banks and branches per country
Bank Accounts
  Masked account and routing references per supplier
Payment Methods
  Configured electronic and manual payment methods
Currencies
  USD, GBP, EUR + unconfigured pairs

Jarvis AI Generates

Scenario 01 — New Bank Account + USD + EFT Payment Method
Scenario 02 — New Bank Account + EUR + Check Payment Method
Scenario 03 — Update Existing Bank Account
Scenario 04 — Supplier With Multiple Eligible Bank Accounts
Scenario 05 — Invalid Bank Account Number
Scenario 06 — Unauthorized User Attempts Add Bank Account
...

Supplier banking test data is highly sensitive. The public Syntra Standard Test Library uses illustrative ${PLACEHOLDER} data only — never real account or routing numbers. Where DataVault is connected, customer-specific supplier bank account data remains within the customer's controlled SyntraFlow environment and access model, with sensitive fields masked in captured evidence and reports according to DataVault's data masking policies. See Syntra DataVault Data Masking for details.

Example Test Variations

Representative examples of Supplier Bank Account scenarios Jarvis can generate from this business scenario, spanning bank, currency, payment method and security conditions. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.

ID	Variation	Type	Key Difference	Execution
VAR-001	Add Standard Bank Account	Positive	Valid bank, branch, account and routing details accepted	Syntra Ready
VAR-002	Add Bank Account — USD	Positive/Currency	Payment currency = USD	Syntra Ready
VAR-003	Add Bank Account — EUR	Positive/Currency	Payment currency = EUR	Syntra Ready
VAR-004	Add Bank Account — GBP	Positive/Currency	Payment currency = GBP	Syntra Ready
VAR-005	Add Bank Account — Electronic Funds Transfer	Positive/Method	Payment method = electronic funds transfer	Syntra Ready
VAR-006	Add Bank Account — Check Payment Method	Positive/Method	Payment method = check	Syntra Ready
VAR-007	Update Existing Bank Account	Positive	Existing bank account details are updated	Syntra Ready
VAR-008	Multiple Eligible Bank Accounts	Positive	Supplier configured with more than one eligible bank account	Syntra Ready
VAR-009	Invalid Bank Account Number	Negative	Account number fails Oracle format/validation	Syntra Ready
VAR-010	Invalid Bank	Negative	Selected bank is invalid or not configured	Syntra Ready
VAR-011	Duplicate Bank Account	Negative	Bank account already exists for the supplier	Syntra Ready
VAR-012	Inactive Bank	Negative	Bank exists but is inactive	Syntra Ready
VAR-013	Missing Routing Details	Negative	Required routing or bank identification information is missing	Syntra Ready
VAR-014	Security Restriction — Unauthorized Access	Negative/Security	Requesting user lacks access to view or maintain banking data	Syntra Ready

Automatically Expand Positive and Negative Supplier Bank Account Coverage

Positive Testing

Jarvis generates scenarios using bank, branch, account, payment method and currency combinations expected to successfully add or update a supplier bank account in Oracle Fusion.

Valid Bank + Valid Branch + Valid Routing Details + Configured Payment Method → Bank Account Added

Negative Testing

Jarvis can also generate scenarios designed to exercise Oracle's validations around bank account number format, bank status, duplicate detection and banking data security.

Invalid Bank Account Number → Expected Format Validation
Inactive Bank → Expected Bank Status Validation
Duplicate Bank Account → Expected Duplicate Validation
Missing Routing Details → Expected Mandatory Field Validation
Unauthorized User → Expected Access Restriction

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

Scenario	Oracle Outcome	Test Result
Valid supplier	Supplier created	PASS
Duplicate supplier	Duplicate validation occurs	PASS
Invalid tax ID	Tax validation occurs	PASS
Security restriction	Access prevented	PASS
Unexpected application exception	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

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

Supplier Bank Account Regression Pack

Add Standard Bank Account
Add Bank Account — USD
Add Bank Account — EUR
Add Bank Account — Electronic Funds Transfer
Update Existing Bank Account
Multiple Eligible Bank Accounts
Invalid Bank Account Number
Duplicate Bank Account
Missing Routing Details
Security Restriction — Unauthorized Access

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

Once scheduled, SyntraFlow executes the selected Supplier Bank Account scenarios unattended and records the outcome of each test and business assertion, with sensitive fields masked in the resulting evidence.

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

Pack	Supplier Bank Account Regression Pack
Schedule	Weekly Regression
Tests	14 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 masked evidence captured for each.

Illustrative example data — not actual production metrics.

Total Scenarios

Passed

Failed

Exceptions

Positive Tests

Negative Tests

Business Assertions

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

Security & Banking Data Access Variations

Access to create, update or view supplier banking data is typically more restricted than general supplier record updates, and is commonly limited to payables or banking specialist personas given the sensitivity of the data involved. Jarvis can generate representative persona-based variations to confirm that banking data access behaves as expected for each role — not to assert a single universal Oracle security model.

Persona	Action	Expected	Syntra Result
Payables/Banking Specialist	Add Bank Account	Allowed	PASS
Unauthorized User	Attempts Add Bank Account	Access prevented	PASS

Understand Why a Test Failed

SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.

DataConfigurationSecurityAutomationApplicationEnvironmentExpected Validation

Jarvis Failure Intelligence — Coming Soon

From Business Scenario to Execution Evidence

Business teams get readable test documentation; automation teams retain detailed execution traceability.

Standard Business Scenario

AI-Generated Variation

Regression Pack

Business Test Step

Automation Actions

Business Assertion

Screenshot / Evidence (masked)

Execution Result

Meet Jarvis — SyntraFlow's AI Testing Engine

Jarvis extends the Syntra Standard Test Library by analysing the Supplier Bank Account scenario, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary and Security coverage for the customer's environment — with particular emphasis on Security, given the sensitivity of supplier banking data.

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 — Supplier Bank Account, 8 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 (masked)

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Enter Account and Routing Details

May internally include

Open Add Bank Account Panel → Enter Bank/Branch → Enter Account Number → Enter Routing Details → Validate Format

Business Step

Verify Association and Appropriate Handling of Sensitive Data

May internally include

Reopen Banking Information → Confirm Association → Capture Evidence → Apply Masking Rule to Bank Fields → Confirm Masked Output

What SyntraFlow Captures Per Run

Parameterised input valuesReusable navigationAutomation action traceScreenshots / evidence capture with sensitive-field maskingExecution timingPass / fail statusBusiness assertionsEnvironment-independent test data

Action Status vs. Business Validation

A successful UI interaction does not automatically prove the bank account was associated correctly or that sensitive data was protected — this is illustrative of how SyntraFlow separates action success from business validation; it does not reflect a specific live execution. When a step fails, SyntraFlow's evidence trail is designed to help a tester classify the likely cause — for example DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, AUTOMATION_ERROR, INTEGRATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: Supplier Bank Account failed — Likely category: SECURITY_ERROR — Evidence: user does not have access to banking data — Recommended action: review banking data security role. A failure should never be labeled as an Oracle defect without supporting evidence.

Step	Action Status	Business Validation
Enter Account and Routing Details	Pass	—
Save the Bank Account	Pass	—
Verify Association and Appropriate Handling of Sensitive Data	Pass	Pass

Related Supplier Tests

Supplier Bank Account is part of the same Suppliers cluster — explore the related create, update and site scenarios below.

Create Supplier Update Supplier Create Supplier Site

Turn This Standard Test into Your Oracle SCM Supplier Bank Account Regression Suite

Start with the Syntra Standard Supplier Bank Account test, use DataVault to provide environment-specific, masked test data, let Jarvis generate additional bank, currency, payment method and security variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Suppliers 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

Suppliers Test Library Procurement Test Library SCM Test Library Test Library Home Oracle ERP Testing Tool Syntra DataVault DataVault Data Masking

Frequently Asked Questions

What supplier banking data does this test validate?

It validates that a supplier bank account can be created and maintained in Oracle Fusion SCM Procurement with correct bank, branch, account and routing details, payment method and currency, and that the account is correctly associated with the intended supplier and supplier site.

How is sensitive banking data masked or protected during testing?

SyntraFlow and Syntra DataVault support masking of sensitive banking fields — such as full account or routing numbers — in captured screenshots, evidence and reports, so this information is not unnecessarily exposed. See Syntra DataVault Data Masking for details.

Who typically has access to supplier bank account data?

Does this test ever use real bank account numbers?

No. This test always uses ${PLACEHOLDER} tokens such as ${BANK_ACCOUNT_NUMBER} and ${ROUTING_DETAILS} in place of real values. Real bank account numbers, routing numbers or other sensitive banking information should never be entered as test data.

How is security tested for supplier bank account access?

Jarvis can generate representative persona-based variations — such as an authorised payables/banking specialist versus an unauthorized user — to confirm that access to supplier banking data behaves as expected, without asserting a single universal Oracle security model.