F110 prints the check on the wrong page/leaf when vendor invoices overflow

[Former Member]

Hi all,

When paying vendor invoices with a check printed through F110, if a vendor has more invoices than fit on a single check leaf, the following should happen:

- Invoices overflow to the next page

- Any checks before the last one are left blank and voided by the system

- The check on the last page is printed with the total amount and is marked as valid by the system

However, what's happening is the following:

- Invoices overflow to the second page

- The check on the first page is printed with the amount, date, etc. and marked as void by the system

- The check on the second page comes out blank and is marked as valid by the system

For some reason the form or print program isn't waiting until the last page to print the check. I can't find anything about check printing in case of an overflow in SAP Notes or transaction FBZP. Is this controlled by a setting in the program variant, or somewhere else?

Thanks!

Edited by: Pedro G. on Sep 9, 2010 5:43 PM

[brad_bohn]

In the standard pre-numbered scenario, that logic is controlled by the print program by issuing the calls for window CHECK, elements 540 and 545. If you've configured/developed away from the standard as most do, then someone may have done something to affect the processing. You can debug your print program and figure out the issue. I will also say that we use blank stock and a custom design for AP checks; in that page overrun scenario, I use a condition in the form itself to print the elements of the check at runtime on the last page only:

/: IF &REGUH-RBETR& EQ &REGUD-SNETT&
...
/: ENDIF

[Former Member]

Thanks for the reply, Brad.

I see the CHECK window on the FIRST page has text elements 540 and 545, but the rest of the lines are commented out. There seems to be nothing printing there. Instead, this particular check layout has the date and payee in one window and the amount in another one, both on the FIRST page of the SAPscript, but there are no calls to WRITE_FORM for either of those two windows. Does the CHECK window have any special properties that (should) cause it to always print at the end, and could I then apply those properties to these other two windows to fix the problem?

As for the debugger, I guess what I should be looking for is the moment when the check gets printed, and see what happened exactly before that triggered it? Then see if I can delay that trigger until the end?