Troubleshooting Work With Payment Control Groups (P04571, R04571, R04575, R04576)

This document helps troubleshoot issues with Work Within Payment Control Groups also known as Write, Updating or Undoing payment groups within EntepriseOne Accounts Payable.

Troubleshooting Steps

Question 1: Why does the system increment the Next Payment Number in the Work with GL Bank Accounts (P0030G) when canceling out on the Printer Selection (P986162) screen during the Write process?

Answer 1: If the user clicks OK on the warning message that appears during the Write process, but then decides to Cancel, the payment number needs to be manually reset because it has already been incremented prior to Printer Selection (P986162).

Question 2: What causes a voucher to get stuck in a # (Payment in Progress) Pay Status?

Answer 2: Vouchers getting stuck in a # Pay Status (data dictionary item PST) can be caused by a multitude of reasons. Here are a couple troubleshooting steps to try:

Ensure the AP Auto Payments (R04571) and AP Auto Payments Update Driver (R04575) UBEs are running in a single-threaded job queue.
When there are no automatic payment groups being processed, the payment worktables (i.e. F04571, F04572, F04573) should be clear. Using a database utility, ensure these tables are empty. Any leftover data found in these tables may cause unpredictable results during the payment process. If data exists in these tables when there are no payment groups in process, do a table generation on these three tables to clear all data and refresh the tables.

Question 3: When writing a payment, if pressing Cancel on the pop up message why does the system ignore the command and continue to the printer selection?

Answer 3: In UDC table 00/RR (Object in Use Application ID), ensure that the record for F0030 has a Special Handling Code (data dictionary item SPHD) of 1. If this field is left blank, the system ignores the cancel feature.

Question 4: When writing an automatic payment, why is a 'User Defined Error Code' triggered at the Printer Selection (P986162)?

Answer 4: This issue can be caused by an incorrect Payment Instrument (data dictionary item PYIN) setup in the Work with Payment Instrument Defaults application (P0417). If the payment instrument being used has been configured with an association to a GL Bank Account and the current payment is not using that GL Bank Account, the system cannot determine what print programs to use when writing a payment. To correct this issue, add a Payment Instrument Default for that Payment Instrument with no GL Bank Account association.

Question 5: After clicking OK on the Write Payments (W04572A) form, why does the system trigger a User Defined Code error for UDC table 04/PP (Produce Bank File)?

Answer 5: This issue usually occurs when the print program the system is trying to use is not defined in UDC 04/PP (Produce Bank File). To confirm that the Print Program exists in this UDC:

Go to Work with Payment Groups (P04571).
Highlight the payment group or pay item.
Use the Control option from the Row exit.
Pick a valid program and version using the Visual Assist.
Write the payment again.

Question 6: Is it possible to disable the Check Number Sequencing warning message that is displayed when writing payments in Work with Payment Groups (P04571)?

Answer 6: This warning message cannot be disabled.

Question 7: What steps should be taken if a payment group Next Status does not change after the Write process completes?

Answer 7: To correct this issue, follow the steps below:

Undo the payment group in the Work with Payment Groups application (P04571).
Ensure that the temporary tables AP Payment Processing - Header (F04571), AP Payment Processing - Summary (F04572) and AP Payment Processing Detail (F04573) have been cleared for the payment group in question.
Run the Create Payment Control Groups (R04570) to re-create the payment group.
Go to Work with Payment Groups (P04571) to find the new payment group.
Use the Write option from the Row exit.

Question 8: Why is a blank payment number assigned to a check?

Answer 8: This issue can be the result of one of the following:

The user overwrote the value in the Next Payment field of the Write Payments (P04572W2) form when writing the payment.
The Next Payment Number (data dictionary item NXTC) field in the Work with GL Bank Accounts (P0030G) for the related bank account is blank, and the user did not specify a number in the Next Number field in the Write Payments (P04572W2) form.

In either scenario, the system erroneously assigns a blank payment number to the first check. All subsequent payment numbers start with 1 and updates the Next Payment Number field for the GL Bank Account Information (P0030G).

Question 9: The system crashed during the Write of a Payment Group. How do we finish out the rest of the Write process?

Answer 9: With a system crash or power failure there is a high chance there is data corruption within the payment tables, Therefore, rather then finishing the payment group, the recommendation would be to undo all payment groups that exist in the "Work With Payment Group" screen for all statuses both Write and Update. Be sure no one is creating or working on payment groups during this process. Once you undo all groups, this should reset all vouchers back to open status, then run a query over the three payment tables: F04571, F04572 and F04573 to determine if there are any records in these tables. If there is data in these tables remove the records or regenerate the tables. (Have your IT group do this step). Once all records are cleared form the tables, then the user can recreate the payment group and should be able to successfully complete writing the payments.

If a voucher has a negative open amount, use its document number to query the F0414 to see what payment information appears for that voucher. If there is a PK or PN showing for the voucher, then it has been paid. If you see a PK (or PN) and a PO, the check has been voided and the voucher is unpaid. You may also see PK (or PN) and a PO and another PK, which means there was an initial payment, but it was voided, then it was paid again. If the voucher shows as paid per the F0414 table, you need to SQL the F0411 to show the voucher as paid; that is open amount equal zero and pay status field equal 'P'. If there is no payment or the payment was voided, then you need to SQL the F0411 to show the voucher as open; update the Open amount to equal Gross amount and pay status would be set to 'A' for approved for payment or H for on hold.

NOTE: If part of the group did finish, you need to either void out the payments or make sure when you write the new group to set the align checks to match so they print correctly in the new PDF.

Question 10: Why is a User Defined Code error given when Writing payments in Work with Payment Groups (P04571)?

Answer 10: This issue may be caused by incomplete records in the AP Payment Processing Header (F04571). If any of the following fields are blank, it is because the Payment Instrument (data dictionary item PYIN) is not configured correctly:

Payment Print Program (PGMP).
Register Print Program (PGMR).
Attachments Print Program (PGMA).
Debit Statement Print Program (PGMD).

To fix this issue, undo the payment group and correct the payment instrument setup.

Question 11: When resetting a payment group and reusing a check, when we print the check, why does the number reused show twice; once as zero dollars and as VOID and then a second time but for the correct amount?

Answer 11: This is functioning as designed. WhenProcessing Option 2: Post Void Payments on the Update tab of the Work with Payment Groups (P04571) is turned set to 1, the system is designed to create zero dollar checks for all voids. This functionality can help prevent fraud so that users can not print checks, reset the group and still mail and cash the check. There are no current plans to redesign this feature at this time.

Question 12: Why does the system only process the first 20 payment groups when a large number of payment groups have been selected to Write in Work with Payment Control Groups (P04571)?

Answer 12: When selecting more than 20 payment groups in Work with Payment Groups (P04571) to write payments, use the Write Row exit, which opens Write Payments (P04572), form W04572A. On this form, click the Go To End button to have all the rows loaded and to process all payment groups. Otherwise, only payment groups corresponding to the first 19 different GL bank accounts visible are processed.

Question 13: How can an invalid "Record In Use" error be cleared if no one is accessing a payment group and no one is able to make an update to this group?

Answer 14: To clear this error on a payment group:

Access the A/P Payment Processing – Header Table (F04571).
Find the Generic Flag 4 (GLFL4) field. Thisfield is used for locking the Payment Group. If it is populated, then the corresponding payment record cannot be chosen for update.
Reset the field to <blank>. Since there isn’t a standard application to do this, the field will need to be reset using a database utility program with record update capability.

WARNING: Please be aware that since this resolution may require SQL, it is strongly recommended any changes be made in Test and verifying the results prior to making any changes in Production.

Question 15: An A/P Check was printed (written), mailed, and cashed, but in E1 the F0911 states "void payment" and there are no F0411 records. The invoices on the check were not flagged as paid, so the following week the same invoices were paid again, along with more invoices, why?

We would like to figure out:

What happened
How to prevent this from happening again
How to verify that other checks have not been sent out like this

Answer 15:

Since the AP Payment process is being done in "worktables", then it is possible for a check to be written, printed and mailed but, then the payment group undone or reset. This would reopen the vouchers for further payment even though the check has been mailed.
To prevent this, one suggestion is to have a Work with Payment Group version for "AP Processors" that has the reset and undo options secured. Then have a second version for "AP Supervisor or Manager" which allows them to undo or reset a payment group if necessary.
Can SQL query the F0411 to first identify all document numbers that have an open amount greater than zero then query the F0414 to see if any of these open documents have payment records.

Note: Behind the Work With Payment Group program, there is a processing option to turn on that creates a "VOID" record, which is what this client experienced, if a check is reset/undone during the Write process. It creates only a F0911 "VOID PAYMENT" record for security purpose. This feature is functioning as design. Answer above can be used for additional security if this processing option feature is turned off.

Question 16: Can old records in the F04571 table, which aren't associated with any records in the F04572 or F04573 records, be deleted?

Answer 16: If there are any records in the AP Payment temporary tables (F04571, F04572 or F04573) that are not part of a current payment group, they should be deleted. These are corrupt, orphan records that could cause problems when attempting to Write or Update payment groups. The recommendation for when these corrupt, erroneous records are found is to:

Ensure that there are no Create Payment Control Groups (R04570) jobs processing.
In Work with Payment Groups (P04571), find all payment groups in process.
Select all payment groups.
Choose the Undo option from the Row exit.
Cleared the remaining data and regenerate the three temporary tables (F04571, F04572, F04573).

Question 17: What causes the Update Driver (R04575) or the A/P Auto Payment Register(R04576) to fail with a work center error indicating that the "record being inserted into table F0414 already exists"?

Answer 17: This error is generally thrown if there is an inconsistency in the Next Numbers (P00022) for Payment ID (PYID) in the F0414/F0413 tables. If the Next Number is lower than the highest Payment ID in the Payment Header (F0413), then this causes the system to throw duplicate primary key errors so no records can be inserted. To resolve this issue:

1. Query the F0413 for the highest PYID value.
2. Check the P00022 for F0413 Table Name and ensure that this value is higher than the value returned in step 1. If it is not, then you should adjust this and re-test.

Question 18: After upgrading to a new release, we have trouble sporadically with writing and/or updating payments. We have tried everything on this list but still have trouble. Is there anything else we can try?

Answer 18: Make sure that you have created new versions for R04570 and R04572 in your new release. Using older versions from previous release have been known to cause issues such as these.

Question 19: Why P04571 is allowing to Update a Payment Control Group (PCG) several times, resulting the vouchers including in the PCG with an Open Amount "zero" or negative after the payment group is Undo?

Answer 19: When PCG is created for a voucher and in supplier master, payment creation is set to "By pay item" , then after Writing PCG, Update can be done on PCG multiple times , which corrupts the Open Amount. In 9.0, apply BUG 11055053.