Troubleshooting Accounts Payable Duplicate Payment Batches (R09801, P09801)

Purpose

This document has been created to help troubleshoot a specific automatic payment batch (K) post failure due to duplicate payment batches.

Troubleshooting Steps

Overview

This troubleshooting document provides assistance with resolving this specific post failure condition below:

• A post failure OR AP integrity issue within JD Edwards EnterpriseOne Accounts Payable automatic payment batch (K) that involves:
• 2 or more duplicate payment batches paying the same vouchers more than once.
• Running AP integrity shows that 2 or more batches duplicates of each other.
• Key factors included:
• Issue is in non-currency environment
• No taxes/vertex involved
• No discounts involved

Basic Post Overview Video Presentation

Below you will find a link to our AP Payment basic post presentation. This includes an overview for automatic payment processing, manual payment with voucher match payment processing and manual payment without voucher match payment processing.

Data Collection Instructions - (Summarized Details)

Oracle support will ask for these items below to troubleshoot this specific post failure scenario:

1. Query F0413 and F0911 by each batch number (ICU) that are duplicates, export to excel.
1. The General Ledger (F0911) only exists if batch has partially or successfully posted. You may find zero records.
2. The General Ledger (F0911) is the key table that determines how the payment batch can be resolved.
2. From the F0413 query in step 1 above, gather all unique payment ID numbers (PYID) and query the F0414 for each separate duplicate batch number found, export to excel.
3. From F0414 in step 2 above, gather all unique voucher document numbers, query F0411, export to excel.
   1. A/P Payment Detail table (F0414) does not have batch number (ICU) as a field. The A/P Payment Header table (F0413) connects to the detail table (F0414) only by payment ID number.
4. Attach R09801 for same batch number
5. Attach R09801E for same batch number
6. Attach image of work center error(s) for same batch number

Data Collection Instructions - (Full Details)

Successful Post Summary (One Valid Payment Batch Type (K))

• When you create an automatic payment you first go through a series of processes.
• First you run the "Create Payment Control Group" program (R04570) process where you create data within the temporary payment worktables:
• F04571 (Temporary Payment Header)
• F04572 (Temporary Payment Headers)
• F04573 (Temporary Payment Details - Voucher details)
• After the payment control group is created you then use the "Work With Payment Control Groups" program (P04571) process to write the payments.
• After you review the payments that were created, then you use the same "Work With Payment Control Groups" program (P04571) to update the payment control group which converts the data from the temporary payment tables to the main payment tables, which are:
  
  • F0011 (Batch Header)
  • F0413 (Payment Header - Payment summary information)
  • F0414 (Payment Details - Voucher details)
• When the group is updated, if the batch is not auto posted, there are no General Ledger entries (F0911) created yet.
• When you post the payment batch the A/P Payment tables (F0413 and F0414) are updated with a post code of D and the payment records are added to the General Ledger along with an AE entry to trade both with post codes of P.
• Reminder - Your AE entries are either created in detail, per voucher the payments pay, or by batch depending on your offset method set in the constants.

Good Record Example before Automatic Payment Posts to General Ledger

F0413 Key Fields

F0414 Key Fields

Good Record Example After Automatic Payment Posts to the General Ledger

F0413 Key Fields

F0414 Key Fields

F0911 Key Fields

Duplicate Payment Batches Scenarios

See examples of different scenarios of where there are duplicate or triplicate payment batches and how to fix them.

Scenario 1: Duplicate Payment Batches (Type K) - First batch created pays vouchers and is posted successfully like example above, however, vouchers show as negative open total, why?

1. Find second payment batch (unique batch number, unique payment ID not matching first batch but are paying the same vouchers as first payment batch is), it is either fully posted, partially posted or post failed.
2. Follow the query instructions above to export out all the data, good original batch plus duplicate bad batch.
   
   1. First, confirm good batch is in balance and posted successfully to the General Ledger. Once this is confirmed nothing will need to be done to this batch, it will stay in the system as is.
   2. Next, from the query confirm if the second (bad) duplicate batch has been posted to the General Ledger fully or not.
      
      1. If fully, all you need to do is void each of these payments in this batch, then post the batch to post the voids. This will reopen the vouchers to approved for payment status again which you do not want to leave. Get with your DBA, IT and SQL the pay status for these vouchers back to P for paid and set the open amount to zero dollars since the good batch still is there and okay. Done. Or
      2. If the second batch is not posted to the General Ledger and no attempt to post it has been done, then you should be able to delete the payments (no audit trail), note it will reopen the vouchers so you will have to SQL the pay status to P and open amount to zero on the vouchers in this scenario as well. Done.

Scenario 2: Triplicate Payment Batches (Type K) - First batch created pays vouchers and is posted successfully like example above, however, vouchers show as 3 times negative open total, why?

1. Find second and third payment batches (unique batch number, unique payment ID not matching first batch but are paying the same vouchers as first payment batch is), it is either fully posted, partially posted or post failed.
2. Follow the query instructions above to export out all the data, good original batch plus next two duplicate bad batches.
   
   1. First, confirm good batch is in balance and posted successfully to the General Ledger. Once this is confirmed nothing will need to be done to this batch, it will stay in the system as is.
   2. Next, follow scenario 1 steps and repeat for the 3rd duplicate batch.

NOTE - If The duplicate payments are using the same Check number, you will need to SQL the "bad" check number and put 99 in front of it in F0413 and F0911 records so you can void.

Preventing Duplicate Payment Groups (P04571)

Prior to payment processing, duplicate vouchers should be identified because this can lead to duplicate payments. The Suspected Duplicate Payments UBE (R04601) is used to find duplicate vouchers. Information on this report is retrieved from the Accounts Payable Ledger (F0411) table. Vouchers appear on this report based on one of the following criteria:

• Duplicate Invoice Number (data dictionary item VINV).
• Duplicate amounts within an invoice.

This report does not adjust the status of any vouchers listed. The report totals are dependent on the following sequence:

1. Address Number (AN8)
2. Invoice Number (VINV)
3. Document Number (DOC)
4. Document Type (DCT)
5. Document Company (KC0)
6. Pay Item (SFX)
7. Pay Item Extension Number (SFXE)

To avoid duplicate vouchers, the Duplicate Invoice Number Edit (data dictionary item DUIN) in the Accounts Payable Constants (P0000) should be set to H (Hard Error). This setting prevents any duplicate invoice numbers to be entered and thus eliminates the need for the Suspected Duplicate Payments (R04601) UBE to run.

Check Temporary Payment Tables for Corruption

The automatic payment process uses three temporary worktables:

• A/P Payment Processing - Header (F04571).
• A/P Payment Processing - Summary (F04572).
• A/P Payment Processing - Detail (F04573).

If duplicate payments are a consistent issue, it is possible that these three tables are corrupted. Follow these steps to check these tables for corruption:

1. Ensure that there are no Create Payment Control Groups (R04570) jobs processing.
2. In Work with Payment Groups (P04571), find all payment groups in process.
3. Select all payment groups.
4. Choose the Undo option from the Row exit.
5. After the Work with Payment Groups (P04571) returns no more groups, use a database utility to query over the three worktables. If no groups exist, these tables should be empty. If data exists, the tables must be cleared out and regenerated.

Verify Payment ID Next Number Set Up

It is also possible that the Next Number being used to assign Payment Numbers (data dictionary item PYID) is incorrect. Find the highest Payment Number in the Accounts Payable Matching Document (F0413). Verify that this number is lower than the Unique Key ID (data dictionary item UKID) where the Object Name (data dictionary item OBNM) is F0413 in the Unique Key File - Next Available Unique Key (F00022).

Verify Code for Programs/UBEs

For Automatic Payment processing, it is extremely important that the latest code for all programs and UBEs is being used. Check the Update Center for the latest ESUs.

Additional Tips

• It is pertinent that the AP Auto Payments (R04571) and the AP Auto Payment Update Driver (R04575) are run in a single-threaded job queue. Oracle Software Support recommends that all other payment programs are also run in a single-threaded job queue: the Print program (R04572, R04572T1, etc), the Attachment program (R04573), the Debit Statement program (R04574) and the Payment Register (R04576). These are the programs that are associated to the Payment Instrument as set up in P0417
• When running Create Payment Groups (R04570) user removes Pay Status (PST) of A from the Data Selection. This modification can cause duplicate payments for Vouchers already paid. An Enhancement starting in 8.9 has improved this feature, however, Oracle Software Support still recommends leaving this value in the data selection.
• When experiencing duplicate payment issues, Oracle suggests that standard programs and versions (XJDE0001 or ZJDE0001) be used to test prior to opening a Service Request.

Frequently Asked Questions

Question 1: When duplicate payments are created, what is the best option to resolve an issue where the paid voucher is updated twice, the Open Amount is listed as a debit and the Pay Status as A?

Answer 1: When duplicate payments are created in the system with the same Payment Number (data dictionary item DOCM) and GL Bank Account, the best option is to void one of the duplicate payments using the batch number (data dictionary item ICU):

1. Access the Void Payment Entry application (P0413M).
2. Search based on Batch Number.
3. Inquire on the Payment Number.
4. Void the duplicate payment.
• This step creates the necessary entries to void the payment and the Open Amount for the related voucher is updated and should net back to zero. Verify the voucher's Pay Status (data dictionary item PST) is now marked as P.
5. Post the void transaction.

Question 2: Is there a report that identifies possible duplicate payments?

Answer 2: The Suspected Duplicate Payments report (R04601) can be used to locate duplicate invoice numbers prior to a payment run. This report is used to prevent duplicate payments from occurring.