As users of the A/P module's Automatic Payment Print Program know all too well, if a run of consecutive checks is mistakenly sent to be printed on ordinary paper, R/3 proceeds to update the Check Register, even though none of the erroneous checks can ever be used. This article shows how to recover from such check-printing mistakes and "erase" them from the Check Register so the checks can be reprinted properly.
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"1 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.
Kim Ciesla
Kim Ciesla is a senior financial consultant and instructor with SAP America, supporting and implementing SAP R/3 Financials. Kim has worked at SAP America for 19 years and has developed expertise in the areas of Collections and Dispute Management, lockbox, Accounts Receivable, Accounts Payable, and General Ledger, with an extensive background in cross-application functionality. In her free time, she is a world traveler, visiting 41 countries to date.
You may contact the author at kim.ciesla@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.