Troubleshooting Accounts Receivable Manual Receipts Issues (P03B102, P03B0001)

Resolution 1: The GL Date (DGJ) is a key field on the Customer Ledger (F03B11), Receipts Header (F03B13), Receipts Detail (F03B14) and Account Ledger (F0911) tables, which cannot be changed via an application once entered. Likewise, the Receipt Date (DMTJ) is also a key field in the latter three tables. These fields are input inhibited once the records have been created.

If the receipt is not posted, it can be deleted by selecting the receipt record on Standard Receipts Entry - Work with Customer Receipts Inquiry (P03B102) and clicking the Delete button. A new receipt can be entered with the correct GL date.
However, if the receipt is posted, there is no way to change the GL date of the receipt through any application. The only option is to void the receipt, post the void, and then re-enter a new receipt with a correct GL date.

Issue 2: Receipts are posting to the wrong account.

Resolution 2: If, after you post a receipts batch, you discover that receipts posted to unintended, or wrong accounts you must:

1. Void the receipt, and post the void.

2. Review and correct the associated Automatic Accounting instruction (AAI) to direct to the desired account number. Link to Overview and Set Up of Accounts Receivable Automatic Accounting Instructions for search rules and setup.

3. Re-enter a new receipt and post the batch.

Note: The Post program uses the bank account defined in the header of the Cash Receipts entry screen, which defaults in upon receipt entry for the RB or RBxxxx (where xxxx is the GL Offset, if defined) UNLESS it is manually overridden.

Issue 3: Open invoices not displayed on either the 'Select Invoice' form or the 'Load Invoices' form.

Resolution 3: There could be a number of reasons for this, such as:

The most common reason open invoices are not returned using Load or Select form exit is due to the type of document you are trying to load or select. As per the current design, there are three document types hard-coded to be excluded while fetching Open Invoices from the Customer Ledger (F03B11). This is because of the following:

RU: Unapplied Cash - Although a record in the F03B11 is a "placeholder" invoice (RU doc type) in the Customer Ledger (F03B11) table. This record is not an original document type, rather a matching document type. As it is not an original document type, it cannot be selected when creating a new cash receipt. (Note: The only exception to this is the matching document type of RB for charge-backs, as these are considered invoices.)
To close out an RU, you need to inquire on the unapplied cash receipt itself via Standard Receipts (P03B102), select it, then apply the amount to open invoices (RI and/or RM original document types, or RBs for chargebacks).
R5: Deductions are always processed by Deduction Processing (P03B40), where deductions can either be voided, reversed or write-off or chargeback, etc. And the R5 F03B11 standalone document itself has no significance when considered for matching.
R1: Drafts are processed using Draft processing and should not be accessible while offsetting receipts. These are a type of 'memo' or placeholder documents, to remind whoever reviews the account that the invoice related to the draft has been closed, but the money may not yet have been received from the customer.

If you have a foreign invoice and you want to pay in the base currency, you will need to change the currency code field to either asterisk or to the foreign currency of the invoice.

Less common, but other possible reasons:

Corruption of the records of these specific invoices. If possible, try voiding the invoices, and posting the voids. Then re-enter the invoices and post them. The new invoices should now be available to be selected or loaded.
Another user could be entering a cash receipt for these two invoices at this same time, effectively locking the two invoice records. Check Business Object Reservations (P00095) for records for these two invoices. If you find any records for the invoices in P00095, contact the user who is locking them.
The invoice records are converted data, e.g. from release XE to 9.1, which left some records in a 'Record Reserved' status. The solution in this case is to remove the object reservation for these records via Business Object Reservations (P00095).

If none of the above resolved the issue, we recommend opening a Service Request with Global Customer Support via My Oracle Support (MOS) to further analyze and troubleshoot the issue.

Issue 4: AAI Missing or AAI Account Set Up error.

Resolution 4: There are several reasons this error is returned when entering a receipt. Link to Troubleshooting Account Receivable Automatic Accounting Instruction AAI Errors (P0012, R09801) for a complete list of errors and their resolutions.

Issue 5: Transaction cannot be committed. Web Client Exception error "There was a problem with the server while running the business function CommitReceiptHeader" when either trying to enter an unapplied cash receipt or when attempting to apply an unpplied cash receipt.

Resolution 5: A common cause of web client exception errors in Receipt Entry (P03B102) is a failure to insert records in the Receipt Header (F03B13) table due to a duplicate primary key. This cause can be verified by looking at the JDE log that was created when the errors were thrown. If this log shows a "Violation of PRIMARY KEY constraint 'F03B13_PK'" error message, the issue can be resolved by:

Query the Receipt Header (F03B13) table and identify the highest PYID value.
Review next numbers for system 03B using Set Up Next Numbers by System (P0002). Payment ID (PYID) is the last line, line 10. Ensure the next number value is one number higher than the highest PYID value in the Receipt Header (F03B13).
Clear cache.

check for special characters in the RPALPH. Once the characters are removed, the Unapplied Cash receipt can be applied.

Issue 6: Transaction cannot be committed. Web Client Exception error "There was a problem with the server while running the business function CreateMaintainRUDetail" when trying to enter an unapplied cash receipt.

Resolution 6: Please review jde.log. If there is a unique constraint violated error related to F03B11_PK, most likely there is a corrupt RU record in the F03B11 that isn't allowing the Insert to F03B11. Query the F03B11 for RPDCT=RU and RPDOC = 0 or null. If found, delete the record using SQL.

Issue 7: Why does Standard Receipts (P03B102) set error 1121 - "Bank Account Currency Code Invalid", when creating a cash receipt in USD for a CAD company, using a bank account belonging to a USD company, to pay a USD invoice for a customer of the CAD company?

Resolution 7: You can process a receipt in any currency and apply it to invoices in any currency as long as the company base currency on the receipt is the SAME as the domestic currency of the invoices and as the base currency of the company to which the bank account belongs.

Since the company of the receipt is a CAD company, but the company of the bank account is a USD company, P03B102 sets error 1121.

You have to use a bank account belonging to to the CAD company. If the funds have to be in the USD company, then you'll need to create a journal entry via P0911 to move them from the CAD company's account to the USD company's account.

Void Issues

Issue 1: Error ID 1499 - NSF or Reverse Not Allowed when trying to delete an unposted GL Receipt.

Resolution 1: Set the Delete/NSF Unposted Receipts processing option on the Edits tab of Standard Receipts Entry (P03B102) to allow unposted receipts to be deleted.

Issue 2: Error ID 351R - Delete/Void /NSF of Reconciled Receipt

CAUSE . . .You may not perform a Delete/Void /NSF on a receipt that has been reconciled.

RESOLUTION
You must first unreconcile this receipt and then reattempt Delete/Void /NSF.

Resolution 2: You need to unreconicle the receipt to be able to delete/Void or mark it as NSF. Refer to How Can an AR Invoice Be Voided (un-matched) From a Reconciled AR Cash Receipt, So That The Correct Invoice can Be Applied to it? for instructions.

Issue 3: Web Client Exception error "There was a problem with the server while running the business function VoidPayItems" when trying to void a pay item from a posted receipt.

Resolution 3: When voiding the invoice from a posted receipt, the system still creates an RU document through this process. Review jde.log. If there is a unique constraint violated error related to F03B11_PK, most likely there is a corrupt RU record in the F03B11 that isn't allowing the Update to occur at all. Query the F03B11 for RPDCT=RU and RPDOC = 0 or null. If found, delete the record using SQL.

Issue 4: Trying to void a receipt, error: You are attempting to delete, reverse or NSF a check which has one of the following: An outstanding spread or adjustment, deduction, a paid or partially paid chargeback or a prior reverse or NSF.

Resolution 4: You need to void the spread, adjustment, or deduction first, then post the void. Only then you can void or NSF the receipt itself. If the receipt has already been reversed or NSF once, it cannot be repeated.

Issue 5: Unable to delete/void unapplied cash (Doc Ty RU) from customer ledger or standard Invoice entry.

Resolution 5: Although you can display the RU on Customer Ledger Inquiry (P03B2002) screen, these transactions are created via receipt entry programs. Use Standard Receipt Entry to delete unapplied receipts.

Chargeback (RB) Issues

Issue 1: Why is the system not using the GL offset for the chargeback reason code (for example DA) when creating a chargeback receipt, even though the RCDA AAI has been set up?

Resolution 1: The chargeback reason code is not used to determine the accounting entry. Instead, the Chargeback G/L Offset must be used. The account used for posting the chargeback is determined from the AAI item RC + GL offset of the customer. The Chargeback G/L offset defaults from the invoice G/L Offset, but may be overridden.

The system locates the account using this hierarchy, where xxxx is the value of the Chargeback G/L Offset field:
• RCxxxx for the company entered on the receipt or draft
• RCxxxx for company 00000
• RC for the company entered on the receipt or draft
• RC for company 00000

Unapplied Cash Issues

Issue 1: Open RU invoices not displayed on either the 'Select Invoice' form or the 'Load Invoices' form.

Resolution 1: This is functioning as designed. The RU record in the F03B11 is a "placeholder". This record is not an original document type, rather a matching document type. Because of this, it cannot be selected when creating a new cash receipt. To close out an RU, you need to inquire on the unapplied cash receipt itself via Standard Receipts (P03B102), select it, then apply the amount to open invoices (RI and/or RM original document types, or RBs for chargebacks).

Issue 2: Unapplied cash receipts (RU) display in Customer Ledger with a posted code of D even though they have not been posted.

Resolution 2: When the unapplied cash (document type RU) is created in EnterpriseOne, a customer ledger (F03B11) "placeholder" record is generated for the amount of the unapplied cash to record it in the Customer Ledger. There is also a Receipt Detail (F03B14) record created for the cash receipt. The amount open for the F03B14 record is tied to the receipts header record (F03B13) for the cash receipt with a unique payment ID number that connects the two records together. When the batch is posted, the F03B14 record related to the unapplied cash is used to generate the associated Account Ledger (F0911) transactions. The F03B11 record is not part of the posting process for the transaction, which is why the program has been written to create the record in posted status; if it were created as unposted, the same amount could be posted twice. The F03B11 record is only there as a reminder record that the money has been received from the customer, but has not yet been applied to an invoice.

Issue 3: Unapplied cash receipt (RU) still shows up in Customer Ledger Inquiry after it has been applied to an invoice.

Resolution 3: When an unapplied receipt (RU) is applied to an invoice before the RU is posted, the RU is converted into a regular RC receipt, and the F03B11 record for the RU is deleted. However, when an RU is applied to an invoice after the RU is posted, the RU's F03B11 record remains, but without an open amount and with a pay status of P for Paid. Also a record in the Receipts Details table (F03B14) is created with a line identifier (alias RC5) of 0 (zero), for the RU.

Issue 4: After invoices are selected to match against a posted unapplied receipt (RU), the new batch number assigned cannot be queried from Standard Receipt Entry.

Resolution 4: When a posted unapplied receipt (RU) is selected to match against invoices, the system creates a matching record with a new batch number (ICU) in the Receipts Detail table (F03B14). There is no additional record created in Receipts Header (F03B13) and the original RU record retains its original batch number. Only the RU record in the Receipts Header (F03B13) displays on Standard Receipts (P03B102). When drilling down into the receipt detail, the complete transactions of the RU (those with the same payment ID number (PYID) in Receipts Detail (F03B14)) will display.

Write Offs

Issue 1: Unwanted automatic write offs are being created during manual receipt entry.

Resolution 1: To prevent automatic write offs, set the Maximum Underpayment Amount and Maximum Overpayment Amount fields to 0 (zero) and the Overpayment and Underpayment Reason Codes processing options to blank in the Auto Write Off tab on the Standard Receipts Entry (P03B102) program.

Miscellaneous Issues

Issue 1: The receipt amount is defaulting into the Payment Amount as the invoice amount, even if it is greater than the actual receipt amount.

Resolution 1: This is determined by the value of the processing option Apply Invoices on the Process tab of Manual Receipt Entry (P03B102). It works in conjunction with the Type Input Code processing options on the Defaults tab. If the Apply Invoices processing option is set to 1, the system defaults the invoice amount, rather than the receipt amount. If this is set to blank, it will apply up to the receipt amount.

Issue 2: Why do cash receipt batches (batch type RB) stay in a status of “In Use”, though users properly close the Standard Receipts program (P03B102), form ‘Receipt Entry’ (W03B102E)?

Resolution 2: The issue was reported to development and is not feasible to fix due to the scope of the fix that would be needed.

As a workaround you need to not only close form W03B102E, but also form W03B102A which is the main inquiry form, before trying to post the receipt. If necessary change the batch status from U to A via the ‘Revise’ row exit in Receipts Journal Review (P0011).