FAQ - Frequently Asked Questions Regarding Writing, Updating, Undoing Work With Payment Groups (P04571, R04571, R04575)

Answer 1: Processing Option 2: Post Void Payments in the Update tab of the Work with Payment Groups (P04571) determines if an audit trail exists for payments that have been undone. Please note that this is only valid if a payment or payment group has been Undone. If using the Reset functionality, no audit trail is created.

Note: It allows you to keep track of payments that have been undone or reset. Use this processing option to specify whether you want the system to post void payments (i.e zero dollar check) to the general ledger (F0911). Void payments include alignment checks and reset payments. Void payments also include checks that are printed as Void so that the stub can be used for additional information continued from the previous stub (when using attachments R04573). Void payments are not the same as voided payments. A void payment is a check that has the words VOID***VOID*** VOID printed on it.

Question 2: What print program is Processing Option 1: Default Print Program Version on the Default tab referring to?

Answer 2: The Print Program is defined based on GL Bank Account and Payment Instrument in the Work with Payment Instrument Defaults application (P0417). This processing option is used to determine what version of the print program is used if a version is not also specified in the Work with Payment Instrument Defaults (P0417).

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: Is it possible to have different payment GL Dates for payments in a single payment group?

Answer 4: It is not possible to have multiple GL Dates in a single payment group.

Question 5: Why does the automatic payment process automatically populate the Cleared Date field?

Answer 5: The Cleared Date (data dictionary item VLDT) is automatically populated during the payment process. However, it can be changed to a desired date during the automatic payment process:

In Work with Payment Groups (P04571), inquire on the desired payment group.
Highlight the payment group.
Click Select.
Choose the Value Date option from the Form exit.
Complete Global Value Date (VLDT) field.
Select the Load Date option from the Form exit.
Click OK.
Press Close to return to the Work with Payment Groups (P04571).

Question 6: Why is the Work with Payment Groups (P04571) unable to search for payment groups with a blank Payment Instrument (PYIN)?

Answer 6: The program is unable to search by a blank value. If it is necessary to search on the default payment instrument (data dictionary item PYIN), you should use a different value as your default Payment Instrument by updating the Supplier Master (P04012) and outstanding vouchers (P0411S) accordingly.

Question 7: In the Work with Payment Detail application, is it possible to select an entire voucher instead of the vouchers individual pay items when choosing the Undo option in the Row Exit?

Answer 7: The Payment Creation field (data dictionary item SCK) in the Supplier Master (P04012) determines if individual pay items or entire vouchers can be selected in the Work with Payment Detail application (P04573):

If the Payment Creation Payment Detail application (P04573), thereby requiring each pay item to be selected individually for the Undo option in the Row Exit.
If the Payment Creation (SCK) field for a supplier is set to By Voucher (value equal to 3), payments in the Payment Detail application (P04573) are created and displayed as single vouchers, despite the number of pay items. This configuration eliminates the need (or the ability) to select each individual pay item in a voucher to use the Undo option in the Row Exit.

Question 8: Currently when user clicks on "Update" from Work With Payment Group P04571, system is defaulted to call print attachment program R04575 version ZJDE0001. If user wants to use other version beside ZJDE0001 where should this be setup?

Answer 8: System is hard coded to call AP Auto Payments - Update Driver R04575 version ZJDE0001 in Work With Payment Group. It is not possible to use other custom version unless you change the code in the program.

Question 9: Which payment programs need to be run in a single-threaded job queue?

Answer 9: It is recommended that the following payment programs are run in a single-threaded job queue to reduce the possibility of duplicate payments:

AP Auto Payments - Print Driver (R04571).
AP Auto Payments - Update Driver (R04575).

Question 10: Is there a way to use a custom Document Type for payments based on the Payment Instrument?

Answer 10: All Payment Document types are hard coded to be used depending on the process used to create the payment, e.g. PT for EFT payments, PK for regular Automatic Payments, PN for Manual Payments, PB for UK BACS, etc. There are no processing options to change this document type.

Question 11: Does EnterpriseOne offer functionality on credit card payments?

Answer 11: No, EnterpriseOne currently does not have functionality in Accounts Payable to set up credit card payment information. Workaround suggestions include:

Set up an alternate payee where the alternate payee is the credit card company.
Use the P0030A (Bank Account Cross Reference) to store the credit card information for the specific vendor. Input the credit card number in the bank account number field. The description field could hold the detailed information so the vendor could apply the payment. To put the information into a txt file, you could use the EFT process. Payments are written to the F04572OW table. Our EFT payments are in CTX format (or PPD format starting at release 8.9 and above). Oracle Software Support would not be able to support this setup, as you may need to customize the text file to meet your bank's requirements.
Set up a new payment instrument but make sure it is associated to a valid JDE version of the payment program so you can create the ACH file format properly. You can test the P04572T2 to see if it meets your needs or if you are currently using a JDE program to write other ACH payments, copy the details from that payment instrument to the new one. This allows you to use the same format as other payments, but the payment group itself remains separate and will not print a live check.

NOTE: These are suggested workarounds, however, they are not supported by Oracle Software Support (OSS).

Question 12: We want to pay certain suppliers with the corporate American Express (AMEX) cards. How do we set up AMEX to make payments to them?

Answer 12: The Factor/Special Payee field is the appropriate place to put the AMEX address book number for the suppliers that are paid via AMEX. This ensures that suppliers' vouchers can still be entered for the suppliers themselves, but the payee (i.e. the person or company paying the bill) are Amex. The only other thing to keep in mind is to group payment control groups (via R04570) based on payee, so the payment is created to be sent to AMEX.

Question 13: How do you create a Record Code (RC) 2 in the F04573 table?

Answer 13: To summarize, when you run create payment control groups (R04570), change the first processing option under Summarize to 1. After the payment has been written, double check the F04573. You should see 2 lines for the payment with an RC 1 and RC 2.

Question 14: Is it possible to create or modify the Payment Order file so that it aligns with the requirements of a specific bank?

Answer 14: No, this is not possible. E1 provides a simple payment writing process that cannot be changed or modified without customization. To meet a bank's specific requirements pertaining to the Payment Order file, you will need to customize your payment process.

Question 15: Is it possible to use the automatic payment process without creating an actual payment?

Answer 15: When you use the Automatic Payment Process, the system will always create either a check or an EFT payment file when you WRT the payment. Even if you setup a dummy print payment program (like for example P5504572NPxxx), you need to have a valid object R5504572NPxxx. If object R5504572NPxxx does not exist, the Work with Payment Groups application will not allow you to write (WRT) the payment and move it to the next status (UPD - Update).

You can use the Automatic Payment Process and then remove the EFT payment file from the F04572OW and F0457 tables so it does not accidentally get sent to the bank. The unique key for both tables is the Member ID field, which is also visible in the P0457 application (scroll to your right to see the field). If you inquire by the Member ID field, you should see all the records belonging to that EFT payment file (one record in F0457, multiple records in F04572OW).

You can use the Manual Payment program P0413M without creating a check or EFT payment file if you do not check the box “Print Payment”. The Manual Payment application will create record(s) in the F0413 (Payment Header) and F0414 (Payment Detail), but no actual payment