Last updated on MARCH 24, 2017
Applies to:Oracle Receivables - Version 18.104.22.168 to 22.214.171.124 [Release 11.5.10]
Information in this document applies to any platform.
FORM:ARXRWMAI.FMB - Receipts
ConcurrentProgram:ARZCAR_RECEIPT - Automatic Receipts Creation Program
Reversing receipts created by Automatic Receipts generates unbalanced accounting entries.
Steps to reproduce this issue:
1. Created the following Receipt Class:
Name: TEST CE REMITTANCE
Creation Method: Automatic
Remittance Method: Standard
Clearance Method: By Matching
Payment Method: DE REMITTANCES
Lead days = 5
2. Created Payment Term CE BB as follows:
Credit Check = Yes
Discount Basis = Lines Only
Installment Options = Include tax and freight in first installment
Due: 8 Days
Discount: 4% 8 days
3. Created the following invoices:
All of them with the payment term = CE BB, trx_date = 24-AUG-2006, gl_date = 24-AUG-2006.
4. Created batch 1187 Type Automatic. Automatic Receipts created receipt Number 4 (cash_receipt_id = 33698, status = CONFIRMED).
5. Unapply the receipt to the following transactions: 12524, 12527, 12528, 12529, 12530. Saved the changes.
6. Change the amount of the receipt so there will be no UNAPP amount.
7. Remitted the receipt.
8. Change Responsibility to Cash Management, Vision Operations (USA).
9. Go to Bank Statements --> Manual Clearing --> Clear Transactions.
10. Enter the Bank account for the payment method (make sure only Receipt is checked).
11. Enter receipt number (in this case receipt_number = 4).
12. Mark the receipt, click on Clear Transactions.
13. Change Responsibililty to Receivables, Vision Operations (USA).
14. Query receipt 4.
15. Click on Reverse (Reason = Non-sufficient funds).
16. Click OK.
The following warning pops-up:
"This action created unbalanced accounting entries. Please contact Oracle Support Services"
The reason you are getting this warning is that I have patch 4898885 (ONE OFF VALIDATE SUBLEDGERS WHILE INSERTING / UPDATING RECORDS (11I.AR.O)) applied. Otherwise, you will not be able to post this receipt.
The are two possible manifestations of the error:
1. Receipts appear on Unposted Items Report and fail to post in GL.
The journal entries created for the receipt are not balanced. This situation manifests if the user has not applied the patch provided for Bug 4474065 to prevent the creation/saving of unbalanced journal entries.
Bug 4474065 provides a feature that raises an error when unbalanced accounting is encountered. This prevents the creation of data corruption. The patches for this feature are:
11i.AR.L: Patch 4638595
11i..AR.N: Patch 4478669
11i.AR.O: patch 5053864
Upon closer inspection, the receipts that manifest this error are Reversed Receipts. Review of the history shows that the receipt is applied, then unapplied, then reversed.
For a $500 receipt, following is an illustrationi of the records in AR_RECEIVABLE_APPLICATIONS:
- when receipt is created
- when receipt is applied
UNAPP - 500
- when the receipt is unapplied
- when this receipt is reversed, we expect:
However an additional record is created:
2. When you attempt to reverse a receipt, the process is rolled back and an error is raised:
This action is not permitted because it would create Unbalanced Accounting Entries. Please Contact Oracle Support Service
The above is the new behavior after applying the patches listed in note box in the previous section.
Steps to Reproduce:
- Create an automatic receipt method
- Create a customer
- Enter multiple invoices and make sure they have assigned this payment method and a bank account.
- Generate an automatic receipt for all 3
- Remit the receipt
- Unapply the 3 invoices from receipt
- Reverse the receipt.
- The corruption is reported to happen only for Automatic receipts. It is not known to happen for manual receipts or for Lockbox (quickcash batches) import.
- The corruption only happens under the following conditions:
- Receipt is applied to 2 or more invoices
- Receipt is remitted prior to reversal
- the sequence of events is: Applied, Unapplied, Reversed
- Review of data in AR_RECEIVABLE_APPLICATIONS_ALL indicates that the issue stems from the incorrect setting of the REVERSAL_GL_DATE during the Unapplication of the receipt. The REVERSAL_GL_DATE incorrectly remains NULL, which causes the code to think that an additional UNAPP row is necessary.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms