Microsoft Dynamics GP: Why are check numbers skipped in Payables Management?

We get asked a lot why check numbers get skipped in Payables Management, and this can happen in a multi-user environment as explained below:  

When a user opens a window such as the Payables Manual Payment Entry window, the Next Check Number defaults in from setup, and a lock is placed on that number.  The Next Check number in setup is incremented at the same time. Now if the user backs out of the Payables Manual Payment Entry window and doesn't use that number, then the Next Check number in setup is reverted back, so it can be used next time and not skipped in this scenario (where the is only one user working).

(This can happen with any window that uses the next check number (check on the fly on an invoice, or building a computer check run {which increments when you print,the checks, etc), but most commonly happens from users using the Payables Manual Payment Entry window so I will use this window in my example below.)

However, in a multi-user environment, this scenario could happen:

• Let's first open the Checkbook Maintenance window (Cards |Maintenance | Checkbook) to view that the Next Check Number is '0055001' in this example:

• If User 1 opens the Payables Manual Payment Entry window, the next check number of '0055001' (from the setup window above) is defaulted into the window on the left below.  You can see on the right that the Next Check Number in setup is immediately incremented to '0055002' causing a lock on the '0055001' check number.  

• If User 1 decides not to use this number and closes the Payables Manual Payment Entry window, then the Next Check Number in setup will revert back to '0055001' so it can be used again. The Next Check Number in setup can revert from '0055002' back to '0055001'. 

• However, if User 1 leaves the window open, and User 2 opens the Payables Manual Payment Entry window, then the Next Check Number of '0055002' defaults into the window, and the Next Check Number in setup is incremented to '0055003 immediately' (as shown on the right) causing a lock on check number '0055002' as well.  Then User 2 posts this manual payment using Check Number '0055002'. 

• Let's say User 1 closes down the Payables Manual Payment Entry window and decides not to use check number '0055001'.

• The Next Check Number in setup was last at '0055003' and cannot revert back to '0055001' because check number '0055002' has been used, so it stays on the Next check number of ''0055003', resulting in check number '0055001' getting skipped.  

• If User 1 (or any other user) opens the Payables Manual Payment Entry window now, then the Next Check Number of '0055003' from setup will default into the window to be used. 

In Summary, the Next Check Number will simply default in from the Checkbook setup.   If a user has a window open where the Next Check Number has defaulted in, that check number is locked as long as the user has the window open.  If no other users have grabbed successive check numbers, then the system can revert the Next Check Number back in the Checkbook Setup window, as long as it can revert back to that number, and no numbers have been used in-between.  However, if another user has since opened another window and locks that number, then the system is unable to revert the Next Check Number back in setup if numbers have been used in-between. 

So users commonly then ask how you can prevent this from happening?

You really can't since this is the design of the system. I have heard of some companies that schedule the days or hours that certain users can issue any kind of payments, but that is not practical or efficient for all companies to do either.  Educating the users on how this works is the best start.  When they post manual payments, it is just good practice to close the window down immediately and release that next number back, before another user grabs the Next Check Number.  This is not going to resolve it, but will help to have users close down the Manual payment entry window as soon as they have posted one and not lock up that next number. 

I hope this information is helpful to you in the future.  

Thank you, 
Cheryl Waswick
Sr. Technical Support Engineer
Microsoft Dynamics GP Support