Resetting And Deleting A Payables Batch In Dynamics GP

Likes most ERP systems, Dynamics GP allows users to create transaction batches to manage a large volume of payments.  On occasion issues can arise which can cause a batch to get hung up in the system or fail to post.  When a batch fails GP will usually prompt the user to use the GP Batch Recovery window to try and reset or recover the batch.  Unfortunately there are some known issues with this method that often prevent the user from accomplishing this task. If you are unable to reset the batch using Batch Recovery then then best option is to handle this from the back-end.

batch_recovery_error

There are two important things to know when dealing with payables batches in GP.  First, all payables batches are stored in the SY00500 table.  This is the Posting Definitions Master table.  The second thing you want to take note of is the status code assigned to the mkdtopst and bchsttus columns.   The status codes are stored as integers and are not immediately obvious as to what they mean.  Below is a quick translation as to what each code represents:

0 – Available
1 – Marked
2 – Available
3 – Marked
4 – Marked
5 – Marked
6 – Marked
7 – Posting Interrupted
8 – Journal Printing Interrupted
9 – Table Updates Interrupted
10 – Recurring Batch Error
11 – Singe Use Error
15 – Computer Check Posting Error
110 – Checks Printing
130 – Remittance Processing

Though unlikely, this list could change in subsequent versions of Dynamics GP so it might be a good idea to check the Microsoft Support page to make sure you’re looking at the latest list of codes.

As a general guideline resetting any batches with a status greater than 6 is not recommended without first discussing the matter with the accounting team.  Batches that have partially posted or ones where checks have already been printed can lead to some very time consuming cleanup.  With that said, there are cases where resetting a batch which has partially posted or otherwise failed after posting can be the desired solution, but you’ll want your accounting team to instruct you to follow this path first.

The first step you’ll want to take before resetting or deleting a batch is to verify the batch exists in the Posting Definition Master table. The following script will do this.

Often times the batch names can be lengthy or obfuscated so I have included a LIKE command here to help locate the batch more easily.

Once you have located the batch in question you want to take note of the  mkdtopst and bchsttus columns.  To put it back in Available status you generally want to set it back to 0.  As noted above, there are actually two designations for Available.  However, the default is 0 and this is what should be used.

The following script will reset the batch and put it in Available status.

In some cases you may even need to delete the batch entirely.  If this is the case, the following script will remove the batch from GP.  Note that once deleted, the batch can not be recovered.

There are a variety of reason you may need to reset or delete a batch in GP.  If available, its always a good idea to perform these steps in a lab or test environment first to make sure they do not create additional problems.  As mentioned before, resetting a partially posted batch can cause transactions to double post and lead to a time consuming cleanup project.  Perform these tasks with caution.