Oracle Fusion Unapply Receipt Test Cases
Validate removal of an existing receipt application in Oracle Fusion Receivables and confirm the resulting effect on the previously applied transaction's balance and the receipt's unapplied balance.
| Test ID | ORCL.O2C.AR.RCP.UNAPPLY |
| Application | Oracle Fusion Cloud |
| Product | Financials |
| Module | Accounts Receivable |
| Process | Receipts |
| Business Flow | Order-to-Cash |
| 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 20 underlying Oracle Fusion UI actions to complete it.
Test Objective
The objective of this test is to verify that an authorised Accounts Receivable user can unapply an existing receipt application in Oracle Fusion Receivables, and confirm the resulting effect on the receipt and the previously applied transaction.
The scenario should confirm that:
- the selected application is eligible to be unapplied and has not already been removed
- the unapply action is accepted without unexpected errors
- the transaction balance is restored to reflect the removed application
- the receipt's unapplied balance increases by the corresponding amount
- application history is retained rather than silently erased
- the receipt remains available for valid reapplication to the same or a different transaction where permitted
This scenario does not claim that every downstream accounting, reconciliation or collections 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 Receivable unapply-receipt processing for a new implementation
- Regression testing of unapply eligibility, period and security validations after an Oracle quarterly update
- UAT sign-off for AR receipt controls that must correctly restrict and record unapplied applications
- Baseline case referenced by the apply-receipt, partial-receipt-application and reverse-receipt scenarios within the same AR receipt lifecycle
Where This Test Fits in the AR Receipt Lifecycle
This test covers removal of a previously recorded receipt application, and depends on an existing application that is eligible to be unapplied. Exact eligibility rules, downstream accounting and reapplication behavior depend on the customer's Oracle Fusion configuration.
Preconditions
- Oracle Fusion Receipts (Accounts Receivable) is configured and available to the test user.
- An existing receipt application exists and is eligible to be unapplied.
- The receipt and its related transaction are not in a status that prevents the unapply action.
- The test user has the appropriate security/privilege to unapply receipt applications.
- The accounting period intended for the unapply is open, or the unapply is otherwise permitted per period-close configuration.
Exact unapply eligibility rules, security privileges and period-close behavior may vary by Oracle Fusion implementation and configuration.
Sample Test Data
| Customer | ${CUSTOMER} |
| Receipt Number | ${RECEIPT_NUMBER} |
| Applied Transaction | ${TRANSACTION_NUMBER} |
| Applied Amount | ${APPLIED_AMOUNT} |
| Currency | ${CURRENCY} |
| Receipt Status | Applied — eligible for unapply |
| Accounting Period | Open period, or a later period where unapply is permitted by configuration |
Sample values are illustrative. Replace them with valid data from the target Oracle Fusion environment.
Test Steps
8 business-readable steps. SyntraFlow's automation executes ~20 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.
| # | User Action | Expected Result |
|---|---|---|
| 1 | Search for the Applied Receipt Navigate to the Oracle Fusion Receipts work area and search for the receipt with the existing application to be removed. ${CUSTOMER} / ${RECEIPT_NUMBER} This single business step replaces multiple technical actions such as opening search, entering the customer or receipt number, clicking Search and selecting the result. | The correct receipt is located and its existing application is confirmed. |
| 2 | Open the Receipt Open the located receipt to review its application details. | The receipt details page opens, showing the applied transaction and applied amount. |
| 3 | Select the Application to Remove Select the specific application line to be unapplied. ${TRANSACTION_NUMBER} | The correct application line is selected for removal. |
| 4 | Select Unapply Select the Unapply action for the chosen application. | The Unapply confirmation page or dialog opens for the selected application. |
| 5 | Confirm the Unapply Action Confirm and submit the unapply request. | Oracle Fusion successfully processes the unapply request without unexpected errors. |
| 6 | Verify Transaction Balance is RestoredBusiness assertion Confirm the balance of the transaction that was previously applied. ${TRANSACTION_NUMBER} / ${APPLIED_AMOUNT} | Transaction balance is restored to reflect the removed application. |
| 7 | Verify Receipt Unapplied Balance IncreasedBusiness assertion Confirm the unapplied balance of the receipt following the unapply. ${RECEIPT_NUMBER} | Receipt unapplied balance increases by the unapplied amount. |
| 8 | Verify Application History Reflects the ChangeBusiness assertion Confirm that the receipt's application history reflects the unapply action. This is the main business assertion for the scenario — removing an application must be traceable and must not silently erase receipt history. | Application history shows the removed application rather than silently disappearing, and the receipt remains available for valid reapplication where permitted. |
Expected Results
- An eligible receipt application unapplies successfully.
- Transaction balance is restored to reflect the removed application.
- Receipt unapplied balance increases correctly.
- Application history retains a record of the removed application.
- The receipt remains available for valid reapplication where permitted.
- No unexpected save errors occur.
- Security and period validations behave as expected for ineligible attempts.
- The unapplied application does not silently disappear from history or reporting.
Key Validation Checkpoints
- Application removed.
- Transaction balance restored appropriately.
- Receipt unapplied balance increased.
- Application history retained.
- Receipt remains available for valid reapplication where permitted.
Go Beyond the Standard Test with Jarvis AI
The Syntra Standard Test Library defines the core unapply-receipt 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 unapply-receipt test dozens of times simply to cover different combinations of customer, transaction, amount 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
Rather than maintaining dozens of near-duplicate copies of the same unapply-receipt 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 Unapply 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 Accounts Receivable Receipts.
- Unapply a full application
- Unapply a partial application
- Unapply one application from a multi-application receipt
- Unapply within the same accounting period
- Unapply and reapply to the same transaction
- Unapply and reapply to a different eligible transaction
- Unapply across different customers and transactions
- Attempt to unapply when no application exists
- Attempt to unapply an application not eligible for unapply
- Invalid receipt status
- Unapply attempted in a closed accounting period
- Unapply attempted without the appropriate security/privilege
- Unapply attempted on a transaction in an invalid state
- Unapply attempted after incompatible downstream processing, such as an application already accounted or reconciled where unapply 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 customers, transactions and period conditions in a real Oracle Fusion environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct unapply-receipt variations relevant to the customer's actual implementation.
Standard Library Definition
Customer ${CUSTOMER}
Receipt Number ${RECEIPT_NUMBER}
Applied Transaction ${TRANSACTION_NUMBER}
Applied Amount ${APPLIED_AMOUNT}
Currency ${CURRENCY}
DataVault
Receipts Applied / Partially Applied / Unapplied Applications Eligible / Ineligible / Already Removed Transactions Linked transaction balances and statuses Customers Customer A, Customer B, Customer C
Jarvis AI Generates
Scenario 01 — Customer A + Full Application Unapply Scenario 02 — Customer B + Partial Application Unapply Scenario 03 — Multi-Application Receipt, One Removed Scenario 04 — No Application Exists (Negative) Scenario 05 — Closed-Period Unapply (Negative) Scenario 06 — Unauthorized User Unapply (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 customer, receipt and transaction details remain within the customer's controlled SyntraFlow environment and access model.
Example Test Variations
Representative examples of unapply-receipt 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 | Unapply Full Application | Positive | Full applied amount is unapplied | Syntra Ready |
| VAR-002 | Unapply Partial Application | Positive | Partial applied amount is unapplied | Syntra Ready |
| VAR-003 | Unapply One of Multiple Applications | Positive | One application removed from a multi-application receipt | Syntra Ready |
| VAR-004 | Unapply Current-Period Application | Positive/Period | Unapply dated within the same accounting period as the application | Syntra Ready |
| VAR-005 | Unapply and Reapply to Same Transaction | Positive | Receipt reapplied to the original transaction after unapply | Syntra Ready |
| VAR-006 | Unapply and Reapply to Different Transaction | Positive | Receipt reapplied to a different eligible transaction after unapply | Syntra Ready |
| VAR-007 | Unapply — Customer A | Positive | Different customer/transaction reference | Syntra Ready |
| VAR-008 | Unapply — Customer B | Positive | Different customer/transaction reference | Syntra Ready |
| VAR-009 | Unapply Receipt in Foreign Currency | Positive | Applied amount recorded in a non-base currency | Syntra Ready |
| VAR-010 | Attempt to Unapply When No Application Exists | Negative | Receipt has no existing application to remove | Syntra Ready |
| VAR-011 | Attempt to Unapply an Ineligible Application | Negative | Application does not meet unapply eligibility rules | Syntra Ready |
| VAR-012 | Invalid Receipt Status | Negative/Status | Receipt status does not support unapply | Syntra Ready |
| VAR-013 | Unapply Attempted in Closed Period | Negative/Period | Application date falls within a closed accounting period | Syntra Ready |
| VAR-014 | Unapply Attempted Without Required Security | Negative | User lacks the unapply-receipt privilege | Syntra Ready |
| VAR-015 | Invalid Transaction State | Negative/Status | Related transaction is in a status that prevents unapply | Syntra Ready |
| VAR-016 | Unapply Attempted After Incompatible Downstream Processing | Negative | Application already reconciled or accounted where unapply is prohibited | Syntra Ready |
| VAR-017 | Unapply Attempted on Reversed Receipt | Negative/Status | Receipt has already been reversed | Syntra Ready |
No variations match this filter.
Why a Blocked Unapply Attempt Can Be a Passing Test
Positive Testing
Jarvis generates scenarios using combinations expected to successfully unapply an eligible receipt application.
Eligible Application + Open Period + Valid Security → Application Removed Successfully
Negative Testing
Jarvis can also generate scenarios designed to exercise Oracle's unapply eligibility rules, validations and security around receipt applications.
- No Application Exists → Expected Action-Prevented Validation
- Closed Accounting Period → Expected Period Validation
- Unauthorized User → Expected Security Validation
- Incompatible Downstream Processing → Expected Unapply-Blocked Validation
A negative test should not be marked as failed simply because Oracle correctly blocks an invalid unapply attempt. If the expected Oracle validation occurs, the negative test has passed.
| Scenario | Oracle Outcome | Test Result |
|---|---|---|
| Eligible application | Unapply completes successfully | PASS |
| No application exists | Action 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 unapply-receipt scenarios and group them into reusable execution packs.
AR Receipt Unapply Regression Pack
- Unapply Full Application
- Unapply Partial Application
- Unapply One of Multiple Applications
- Unapply Current-Period Application
- Unapply and Reapply to Same Transaction
- Unapply and Reapply to Different Transaction
- Attempt to Unapply When No Application Exists
- Unapply Attempted in Closed Period
- Unapply Attempted Without Required Security
- Invalid Transaction State
Run On-Demand or Schedule Automated Batch Execution
SyntraFlow can execute selected unapply-receipt scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.
Once scheduled, SyntraFlow executes the selected unapply-receipt scenarios unattended and records the outcome of each test and business assertion.
| Pack | AR Receipt Unapply Regression Pack |
| Schedule | Quarterly Update Regression |
| Tests | 17 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.
Regression Pack → Scenario → Business Step → Automation Action → Evidence
AR Receipt Lifecycle
Lockbox Receipt Processing creates receipts through an automated batch path and shares the Create / Import stage. Exact processing depends on receipt method, customer setup, currency and customer-specific Oracle Fusion configuration. Stages link to the corresponding test scenario family.
Understand Why a Test Failed
SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.
From Business Scenario to Execution Evidence
Business teams get readable test documentation; automation teams retain detailed execution traceability.
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.
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.
Business Step → Underlying UI Actions
What SyntraFlow Captures Per Run
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 |
|---|---|---|
| Select Unapply | Pass | — |
| Confirm the Unapply Action | Pass | — |
| Verify Application History Reflects the Change | Pass | Pass |
Related AR Receipt Tests
Unapplying a receipt is one stage of the same AR receipt lifecycle — explore the related apply, partial-application and reverse scenarios below.
Turn This Standard Test into Your Oracle AR Receipt Regression Suite
Start with the Syntra Standard unapply-receipt 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.
Use This Oracle Fusion Test Case
Download Test Case
Excel, CSV or JSON export.
Coming soonAutomate with SyntraFlow
Run this script against your own tenant today.