A few years ago, I had an idea for a post about batches and why I recommend them but I never followed through on the idea. I had written a short post last year about Transaction vs. Batch posting but that’s as close as I got to elaborating on my blog thought.
I was reminded today of why I wanted to write this article, which isn’t about batches specifically but about edit lists, which you only can use if you use batches in Dynamics GP. Two incidents in recent weeks have re-affirmed my belief that using batches, reviewing your work prior to posting and specifically, using the edit lists, is an important practice to follow.
Two Recent Support Incidents
There are two issues that I was involved with recently where in one case, we really wished there was an edit list to refer to and in the second case, having an edit list proved to be a real time saver during a posting issue.
Issue #1: Lost internet connection in the middle of posting a batch
In this case, the client had some kind of network issue in a satellite office location just as the user was posting a Receivings Transaction Entry batch. Their network connection completely dropped, and the user had clicked on the Post button just before the connection was lost. They received several error messages of course, including the “Table Not Found” message, confirming the disconnect from SQL. The batch was stuck in “posting” status, and they called me to see what to do next.
Good news: the user had printed an edit list and as part of their normal process, reviewed the edit list prior to posting. This turned out to be a huge time saver. I ran the necessary scripts to reset the batch status, and asked them to re-print the edit list and check it carefully for any differences vs. the original edit list they printed. Had they not printed the first one, they wouldn’t have anything to check against, and would have to go from memory, or from a pile of packing slips on their desk or something to recreate what should be there and if anything was missing etc.
Having an edit list saved their bacon… it turned what could have been a long painful process into a 10 minute cross check and then they continued with posting the batch and everything was fine.
Issue #2: Deletion of integrated transactions by accident
In this case, the client has a nightly process where various transactions are integrated from a third party system for billing and refunds. One integration is for refunds, which is integrated to Accounts Payable. A user had to edit the GL distributions on a couple of the entries for some reason, and was doing that but somehow managed to accidentally delete two of the transactions in the batch.
Bad news: the user didn’t print an edit list first. They had a report from the source system of what should be in the batch, so they knew which two customers should be in the refunds batch, but the report is in a different order than how it integrates into Dynamics GP and doesn’t give the user any info on how they are integrated, i.e. document dates, document numbers, customer numbers etc.. When they went to re-key the missing transactions, some questions came up such as “what should I use as a document number?”. If they had an edit list, this would be a no-brainer - all the info would be there for you to rekey exactly as it was referenced in the original transaction.
In this case, it took a while to figure out what the random document numbering was and where it came from and to find it, to properly recreate this as the external system would expect to see it in GP. This integrating system pulls some data back out of GP every night to update their own records to make sure data integrated properly. I wasn’t sure how it cross checks this info, if it looks by things like document number or not, so I wanted them to recreate it exactly, if we could.
It worked out, but took longer than necessary, only because there was no process that would ensure they have paperwork on hand in case of such an issue, to reference.
Recommendation
Here’s my recommendation to all of my clients:
- Use batches and review your work prior to posting
- Print Edit Lists, even if it’s to PDF not paper
Lots of people complain that they find batches take more time than they are worth. I disagree, but I’m a process person, I believe in reviewing work prior to posting as it’s easier to correct issues before you post, and less messy!
Lots of people also complain that printing edit lists and posting journals are wastes of paper. I don’t disagree with this, but that doesn’t mean you don’t have other options, with printing to PDF becoming so commonplace. Issues like network connection problems are pretty rare, but they occur when you least expect it, and usually, when you are least ready to deal with it.
Users don’t delete transactions every day and most times, if they do, re-keying them is pretty simple. With data integrating from another system, perhaps you don’t have the luxury of recreating that data if you need to, and no pile of invoices on your desk to recreate them from. What do you do then? Restore from backup sometimes isn’t a great option either but you don’t want your best option to be restore from backup.
In this case, it just reminded me why edit lists are useful and having them can really make the difference between a big headache and a minor annoyance. Print them or save them to PDF, and if posting goes fine, delete them… it takes very little time to do this, and can save so much effort later if there are issues.