‘Unsticking’ Stuck Batches in Microsoft Dynamics GP – Part 3

In the past, we’ve discussed the importance surrounding Edit Lists and covered some of the typical reasons causing batches to get stuck (see Part 1 and Part 2 in this blog series). This third blog post will concentrate on the processes involved in “unsticking” the batch.

There are several error messages in Dynamics GP that suggest a stuck batch. The most common one stipulates that the batch has been pushed to a batch recovery window, and prompts the user to go to the window and attempt to “recover” the batch. Ideally, in case of a stuck batch, the user would navigate to the batch recovery window, click process and solve the problem. Cross your fingers and hope for the best!

Most of the time, however, the batch will not complete its posting but spit out an error message similar to the one you received when trying to post the batch from the subledger. Once a batch is stuck and irretrievable in the batch recovery window, you need to ask your GP administrator with access to SQL for assistance.

At this point, it is advisable to follow the KB article to ‘unstick’ the batch. You won’t get very far until you’re asked to log everyone off the system to clear a few tables. It is preferable to follow the article but not always necessary or realistic in today’s 24 hour business climate. I’m often informed by our clients that the posting is needed immediately and that down time is not an option. Fortunately, there is a way to ‘unstick’ a batch while not having to log everyone out of the system.

Against the company database, run the following:

SELECT MKDTOPST, BCHSTTUS, * FROM SY00500 where BACHNUMB = ‘xxxx’
(Replace xxx with the batch ID)

It’s hard to tell exactly where the batch got stuck on its way to posting. An unposted batch will contain zeros in both the MKDTOPST and BCHSTTUS columns of SY00500. Your stuck batch will probably include a 1 in MKDTOPST, meaning it has been marked to post and cannot be edited. The batch will also contain a number other than 1 in BCHSTTUS; batch status codes can be found here. Once you’ve located the batch to be corrected, you can run this update statement:

UPDATE SY00500 SET MKDTOPST=0, BCHSTTUS=0 WHERE BACHNUMB=’xxxx’
(Replace xxx with the actual batch ID)

Upon completion of the successful execution of the update statement, the batch will no longer appear in the batch recovery window and will return to the module where it originated. At this point, the user is now able to re-print the edit list and examine any errors displayed within the report. If you do not review the edit list and decide to post sight unseen, the batch will most likely fail and you’ll have to repeat the above process. To avoid a repeat stuck batch, perform the following:

1. Review the edit list and correct any errors listed
2. Determine if any of the transactions within the batch fully posted to the subledger
3. Determine if any of the transactions within the batch successfully posted to the General Ledger

If a transaction has successfully posted to the sub ledger but NOT the general ledger, you may want to void the transaction in the sub ledger to maintain the integrity of the drill back functionality from GL to subledger. If the transaction has posted successfully in both ledgers, you simple just need to delete the transaction from the batch. The batch should successfully post once you’ve completed these steps.

Please do not hesitate to contact FMT Consultants’ Customer Care should you have problems or questions in regards to stuck batches.

Written by:
Eric Marschke, Customer Care Consultant
FMT Consultants

Posted by: Jakob Bechgaard