Once is a fluke. Twice makes you think about it. Last month we had a client who had a large batch of sales transactions (think 1,000s of transactions). They printed an edit list, and the system locked up. So what did they do? Something they thought would be benign...they used Ctrl-Alt-Delete to end their GP session. And here is where it goes awry...
When they logged back in to GP, it told them that there was a batch in batch recovery. Okay. Fine. So they go to recover the batch, and are MORTIFIED when it goes ahead and POSTS THE BATCH. Before they were ready, before they had completed some additional steps to their own process. Ugh. Double Ugh. Triple Ugh.
So we worked through restoring a backup, and I admittedly did not think too much about it other than it being an odd fluke. Until it happened again, to a different client. And then I got to thinking how it makes PERFECT SENSE. Yes, perfect sense.
Printing an edit list uses the same report as printing a posting journal, so presumably it changes the batch's status when printing. So it would make sense if that process is interrupted, that the status in the SY00500 table for the batch might indicate that it was indeed in the posting process. So batch recovery would take that information and act on it.
So what to do? Rather than use batch recovery in this instance, I would recommend using the batch stuck scripts available in this KB article:
https://support.microsoft.com/en-us/kb/850289
Make sure to use the "Let Me Fix It Myself" option of actually running the scripts to reset the batch status and make it available for continued review/editing.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.![]()
When they logged back in to GP, it told them that there was a batch in batch recovery. Okay. Fine. So they go to recover the batch, and are MORTIFIED when it goes ahead and POSTS THE BATCH. Before they were ready, before they had completed some additional steps to their own process. Ugh. Double Ugh. Triple Ugh.
So we worked through restoring a backup, and I admittedly did not think too much about it other than it being an odd fluke. Until it happened again, to a different client. And then I got to thinking how it makes PERFECT SENSE. Yes, perfect sense.
Printing an edit list uses the same report as printing a posting journal, so presumably it changes the batch's status when printing. So it would make sense if that process is interrupted, that the status in the SY00500 table for the batch might indicate that it was indeed in the posting process. So batch recovery would take that information and act on it.
So what to do? Rather than use batch recovery in this instance, I would recommend using the batch stuck scripts available in this KB article:
https://support.microsoft.com/en-us/kb/850289
Make sure to use the "Let Me Fix It Myself" option of actually running the scripts to reset the batch status and make it available for continued review/editing.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.