Troubleshooting Printing Automatic Payments Within EnterpriseOne Accounts Payable (R04572)

Purpose
Troubleshooting Steps
 Question 1: We Wrote and Updated the payment group and posted it, but we accidentally deleted the R04572 from our submitted jobs, how can we get it back to print the checks?
 Question 2: Why does the check on the Canadian check format (R04572C) print large amounts in numbers instead of in words, even if the number of characters for the amount in words is less than 83?
 Question 3: When printing a check with more than ten lines of detail, why does the first page (VOID) have a different check number than the second page?
 Question 4: When printing a check with details that span across multiple pages, why are the totals incorrect?
 Question 5: When doing a check run, what causes an excessive number of checks printing with the literal "**VOID VOID VOID VOID VOID**" and Next Payment Numbers are getting used?
 Question 6: After setting up two versions of the same print program, why is only one of them called when a payment group with the payment instrument for this print program UBE is written?
 Question 7: The standard check print UBE (R04572) does not support our needs. Will Oracle support us if we have to customize the print program?
 Question 8: What are the steps to change the print program on an existing payment group to a custom UBE instead of the Standard Cheque Printing (R04572)?

Purpose

This document helps troubleshoot printing automatic payment issues.

Troubleshooting Steps

Question 1: We Wrote and Updated the payment group and posted it, but we accidentally deleted the R04572 from our submitted jobs, how can we get it back to print the checks?

Answer 1: Once it is deleted it is complete. If the check batch was Written and Updated and the batch was posted, you would need to Void each check in that Batch, post the voids. This reopens the vouchers so you can create the payment group again with new check numbers. If the check batch was Written, but not Updated yet so therefore not posted either, you can either Reset or Undo the group and start over.

Caution: When resetting or undoing a group, be sure to review your next number set up so they align correctly with your check stock and be aware of you use any alignment checks before your first check starts to print.

Question 2: Why does the check on the Canadian check format (R04572C) print large amounts in numbers instead of in words, even if the number of characters for the amount in words is less than 83?

Answer 2: Per Question 15, the standard check format has a limit for the amount in words of 83, so only amounts that are less than 83 characters when written in words can be printed in this field. However, for the Canadian Check format (R04572C) the available field is even smaller: only 73 characters. Therefore, if an amount converted into words has more than 73 characters, it is not converted into words but written in numbers.

Question 3: When printing a check with more than ten lines of detail, why does the first page (VOID) have a different check number than the second page?

Answer 3: The maximum number of line items for a check R04572 is 10. If a payment has more than 10 lines and the Create Payment Control Group (R04570) processing option to print Attachments (R04573) is not set up, the system prints the first 10 lines on the first check, and the remaining lines on the subsequent check number.

Because all the information is printed on check stock, the system is using actual check numbers. This is functioning as design. Presently there are no plans to enhance the application.

Question 4: When printing a check with details that span across multiple pages, why are the totals incorrect?

Answer 4: The standard payment programs, including standard checks (R04572) and EFT (R04572T2) were designed only to accomodate 10 lines of detail per page. If the Bank Account (P0030G) is set up to allow more than 10 detail lines and a payment's detail spans multiple pages, the amounts are going to be off due to the original design of these reports. The workarounds available:

  1. Set Detail Lines Per Stub for the bank accounts to 10 so that only a max of 10 are printed per stub. If more than 10, additional stubs are printed for a check or you can use attachments by setting Processing Option 2: Print Attachments on the Print tab of the Create Payment Control Groups (R04570).
  2. Customize the print program to support more than 10 stub lines.

Question 5: When doing a check run, what causes an excessive number of checks printing with the literal "**VOID VOID VOID VOID VOID**" and Next Payment Numbers are getting used?

Answer 5: There is a field: Number of Alignment Forms in the Set Up G/L Bank Account (P0030G) > Default Print Options. Typically a number is this field is meant to align check stock on an impact printer. Ink Printers do not require alignment checks.

Question 6: After setting up two versions of the same print program, why is only one of them called when a payment group with the payment instrument for this print program UBE is written?

Answer 6: The version that is called is the one set up for the payment instrument in Payment Instrument Defaults (P0417) or the one that is set in the processing options of Work with Payment Groups (P04571). The latter is only used if the version in P0417 for the write program for the payment instrument is blank.

To get P04571 to call the desired print program version when writing a payment group there are the following options:

  1. Set up two different payment instruments in P0417, one for each version of the print program UBE.
  2. Set up two records in P0417 for the same payment instrument, but one for the bank(s) using only one of the versions, and the other for the bank(s) using the other version.
  3. Set up three versions of Work with Payment Groups (P04571), as per the following and make sure that in P0417 the default print program version for the payment instrument is set to be BLANK (otherwise this version is always chosen, regardless of what version you specify in the P04571 processing options)
Note: If there are existing payment groups that were created before any of the above options was executed, you need to reset then undo the payment groups. Then run Create Payment Groups (R04570) again so that the correct write program version is recorded in the F04571, F04572 and F04573 worktables.

Question 7: The standard check print UBE (R04572) does not support our needs. Will Oracle support us if we have to customize the print program?

Answer 7: No. All customizations are the sole responsibility of the customer to support. Oracle Support recommends the engagement of Oracle Consulting Services and/or any other third-party consulting firm to assist a customer with customizations. Oracle GSC advises that customization assistance does not come with application support. We do have a support group called Technical Business Solutions that can assist with very specific design tool questions.

Question 8: What are the steps to change the print program on an existing payment group to a custom UBE instead of the Standard Cheque Printing (R04572)?

Answer 8: For the system to call your own custom UBE (for example R5804572) instead of R04572, use the following steps:

  1. Open P04571.
  2. Click find button.
  3. Highlight the desired Payment Group and select Row exit > Controls.
  4. On the Revise Payment Group Controls form, in the Payment (PGMP) field, revise the program from P04572 to Pxxxxx for your custom UBE. (Remember that although your UBE name starts with a 'R', here in this Payment field you need to start with a 'P' instead). This also must exist in UDC 04/PP.
  5. Enter the Print Version field. This will be your version name you used for the R5804572. If you leave this field blank then system will use ZJDE0001 and if you do not have a ZJDE0001 version defined for your R5804572, then it will fail).