Though every module of GP can be set to allow individual transaction posting, most users can benefit from batch posting.
A batch is a group of transactions that will be posted all at once.  Once you have a certain quantity of transactions, it just isn’t feasible to post one-by-one anyway, but for consistency of process even single transactions can also be put into and posted in a batch.

But if you’re using batches and not using Batch Edit Lists, you’re losing a lot of benefit.  The Batch Edit List can be printed from any module’s Batch Entry window from the printer icon on the top right of the window:

The Edit List can be printed to screen or printer and checked for accuracy or error messages before the batch is posted:

 

If you’ve ever had a transaction or batch fail mid-posting, leaving you with a stuck batch that can’t be deleted or completed without IT assistance, you know how frustrating they can be.  Stopping to look at the edit list for a few minutes can prevent batches that get stuck because of errors (especially “Account not found” or unbalanced distribution errors, as you won’t get a warning about them when you start to post.

And if you’ve ever posted something and realized 30 seconds (or worse, 30 days) later that it was wrong, you know there’s no “UnPost” button.  Obviously, the Batch Edit List can’t tell you if a transaction was entered for the wrong vendor or a price was typed incorrectly on an order or invoice, but a few minutes to compare the Edit List to the supporting documentation and confirming the batch totals might just save you a lot more minutes of correcting and re-creating later.

I recommend this set of steps to prepare before posting every batch:

1. Check your GP system date
2. Open the Batch Entry window and check the information there, including comments and, where applicable, the selected checkbook
3. Print the Edit List to the screen and/or printer and check for errors
4. Check the number of transactions and batch totals against the supporting documentation
5. Correct any errors in the Edit List (closed periods, distribution errors, etc)
6. Reprint the Edit List and check again if you made any changes
7. Post

If you have an unusually large batch of transactions, or an unusual batch – a new integration, a lot of changes had to be made to the transactions, new accounts/vendors/customers/inventory – this would be a good time to plan to have a database backup (DYNAMICS and the company database) made before you post.  If something goes wrong, you can restore back to the pre-posting state with no harm done.

I’ve had customers who did this as a matter of course – all batches were posted after a 4pm daily backup, all users knew not to enter any other transactions during this time, and Accounting notified IT at 4:30 whether they needed to restore from backup.  If you have large check runs, this sort of process is specifically recommended by Microsoft, as check batches snarl up especially badly if they fail mid-post or mid-print.

There is another side to stuck batches that has nothing to do with transactional errors, which we’ll discuss in a subsequent article.
See Part 2. Dynamics GP Stuck Batches and Part 3: ‘Unsticking’ Stuck Batches

Written By:
Lyn Warren
Customer Care Manager
FMT Consultants, LLC

Posted by: