What happens when a user sends a print job to the A/P Module’s Automatic Payment Program, and then realizes that the whole run of consecutive checks is in error? It’s the inevitable, old "print on plain paper" trick. Or, maybe the print job was accidentally sent to the wrong printer.

Either way, since none of the actual checks got used but R/3 updated the Check Register anyway, what that user would (cont. on page 2) really like to do is take out a giant eraser, undo the results of his or her earlier printing command, load the check stock into the printer, and then ask the Automatic Payment Program to pretend it never printed anything in the first place.

But you can’t erase … Or, can you?

You can. And here’s why. When deciding whether or not to grant your print request, the "Print Checks" command in the Automatic Payment Program is going to read the online Check Register just as you or I would. For any "Payment Document"¹ with an existing check number in the online Check Register, the program will refuse the request to print, because it does not want to allow two checks for one Payment Document.

Here’s how it works. Let’s say you use the Automatic Payment Program to print checks #500002, #500003, and #500004 (and that you allow the Summary report to print on the next unused check #). Your online Check Register would look something similar to what’s shown in Figure 1.

Figure 1

The "Before" Shot — Example View of the Online Check Register

If you then realize that a printing error has occurred, you can take all the records that got put into the check register from the first pass and … whoosh … erase!

In the process, your online check numbering gets set back to where it had been before, as you see in the "Delete For Payment Run" transaction report shown in Figure 2.

Figure 2

The "Delete For Payment Run" Transaction Report

As a result, when you access the "Print Checks" command in the Automatic Payment Program for a second time, the Automatic Print Program finds no evidence of any existing checks assigned to the Payment Documents, grants your second request to print checks for those Payment Documents, and starts assigning check numbers beginning with the first one that came off during your "plain paper" error. No gaps!

So, in Figure 3, checks #500002, #500003, and #500004 have been erased from the Check Register, and the check numbering range reset back to #500001 as the last number to have been used.

Figure 3

The "After" Shot

The transaction for doing this is found in the A/P module, under the menu path: Environment > Check Information > Delete > For Payment Run.

Or, you can use the fastpath code of FCHD.

When check-printing mistakes happen, there is usually more than one option available for recovering.

The point here is not necessarily to recommend one option over the others to users, but rather to point out and explain why the standard R/3 transaction for erasing the rows in the online Check Register related to the mistake is allowed.

In the case of a "printed on plain paper" mistake, the underlying Payment Documents are fine. There are only two problems (which you now know you can work around):

1. R/3’s online Check Register has no way of knowing that the printing occurred on plain paper.

2. When asked to print a second time, the Automatic Payment Program will look in the Check Register to see if any checks are currently linked to those "Payment Documents" before deciding to say "Okay" (no links are found) or "Go Away!" (links are found) in response to your request.