RSMUS.comEven with all of the preventive measures for stuck batches in place, invariably you still may experience a posting interruption where the batch must be recovered. There are several error messages in Microsoft Dynamics GP that indicate a stuck batch.
The most common one states that the batch has been sent to the batch recovery window. The message prompts the user to go to the Batch Recovery window and attempt to “recover” the batch. To recover the batch, the user should go to Tools > Routines > Batch Recovery. Mark the checkbox beside your batch and click Continue. If the batch originated in one of the subsidiary modules, you may need to go to your Financial Batches and find the batch and post it in the General Ledger. If your posting setups dictate that your batches Post Through the GL, the batch recovery process will not complete this step for you, and you will need to manually post the batch in General Ledger. The batch ID will not be the same ID you entered when you created the batch, it will have a prefix that corresponds to the transaction origin of the subsidiary ledger where the batch was originally entered such as PMTRX for a batch that originated in the Payables Transaction Entry window. Sometimes the Batch Recovery routine and then posting the batch in the General Ledger is all that is necessary to recover the batch and complete the posting process.
However, more often the batch recovery routine will fail to complete and return another error or message similar to the one you received when trying to post the batch from the subsidiary ledger. It may also continue to loop back and prompt you to go to Batch Recovery. You may also be presented with a More Info button on the error message. You should always select the More Info button and make note of any additional information provided. If the batch recovery fails, the next step will be to run a script in SQL to release the batch back to an Available status. If you do not feel comfortable with using the following instructions, then request assistance from your Dynamics GP support specialist.
To release the batch, we recommend you follow the steps outlined in this KB article, A batch is held in the posting, receiving, busy, marked, locked, or edited status in Microsoft Dynamics GP. We understand that it may not be feasible to have everyone log off your system and make a backup just to clear a few tables and return to posting. Below is the shortcut method:
Run the following script against the company database:
SELECT MKDTOPST, BCHSTTUS, * FROM SY00500 where BACHNUMB = ‘XXXXX’ (Replace XXXXX with the batch ID)
The SY00500 table is the Posting Definitions table and will contain all of your unposted batches from all modules. An unposted batch will contain zeros in both the MKDTOPST and BCHSTTUS columns of SY00500. Batches that are batch stuck will contain a number other than 0 in either or both the MKDTOPST and the BCHSTTUS fields. If there is a 1 in the MKDTOPST, this indicates it has been marked to post and cannot be edited. The batch may also contain a number other than 1 in the BCHSTTUS field; the different batch status codes can be found in this KB article, Batch status codes (BCHSTTUS) in the SY00500 Posting Definitions master table. Once you’ve located the batch to be corrected, run the following update statement against the company database:
UPDATE SY00500 SET MKDTOPST=0, BCHSTTUS=0 WHERE BACHNUMB=’XXXXX’ (Replace XXXXX with the actual batch ID)
This will set the batch back to an available status. Sometimes running the update statement is all that is required to correct the problem, but depending upon the extent of the posting interruption, you also may have a locked record in the SY00800 table. So before you attempt to post your batch again, you should run the following script against the DYNAMICS DB: SELECT *FROM SY00800 WHERE BACHNUMB = ‘XXXXX’ and USERID = ‘XXXXX”
Replace XXXXX with the batch id and the user id in question. If no results are returned, then have the user print the Batch Edit List, verify the entries for accuracy, and then try posting the batch again. If results are returned, make note of the DEX_ROW_ID and run the following script: delete SY00800 WHERE DEX_ROW_ID = ‘XXXXX’
Replace XXXXX with the DEX_ROW_ID noted previously
Once you have run these scripts, 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 should re-print the edit list and examine any errors displayed within the report. If you do not review the edit list and errors still exist in the batch, the batch will continue to fail and you will have to run the scripts again to recover the batch. To avoid a repeat stuck batch, perform the following:
- Review the edit list and correct any errors listed.
- Determine if any of the transactions within the batch fully posted to the subsidiary ledger.
- Determine if any of the transactions within the batch successfully posted to the General Ledger.
If a transaction has successfully posted to the subsidiary ledger but NOT to the General Ledger, you may want to void and re-enter the transaction in the subsidiary ledger to retain the link and drill back capabilities from the General Ledger to subsidiary ledger. However, if you void the transaction in the subsidiary ledger, remember to check the posting setup for Voided Transactions to unmark the “Post Through” check box. Leave the “Post To” setting marked. Then when the void is completed, you will need to go to the Financial Batches and delete the batch that contains the Void. You can then re-enter the transaction in the sub ledger, and post the transaction through to the General Ledger. If the transaction has successfully posted through to both ledgers, you can just delete the transaction from the batch. Any remaining transactions in the batch should then successfully post to the sub ledger and the General Ledger.
If you experiencing interruptions with your Dynamics GP batch postings and need a partner to support your system, RSM offers access to Certified Microsoft Professionals, help desk and phone support, knowledge and experience with third party products and dedicated account management. Please contact our professionals for more information at erp@rsmus.com or by phone at 855.437.7202.
By: Nancy Hogan – Pennsylvania Microsoft Dynamics GP partner
