#MSCONNECT GP – Bug in taGetPMNextVoucherNumber causes duplicate voucher numbers to be issued

David Meego - Click for blog homepageTime to vote.

This is the fourth in a series of blog posts where I will be highlighting Microsoft Connect product suggestions that need the community’s support. If you agree with the product suggestion, please help get as many votes as you can.

The issue which is the subject of today’s article is eConnect calls for getting the next transaction number generating duplicate numbers, submitted by Steve Endow.

This issue affects sites using eConnect where they have a high throughput of documents happening at the same time. The code that provides the next transaction number is not contained in a SQL Transaction which means it does not detect if the code is being executed more than once at the same time and so two independent calls can receive the same next transaction number. This will cause the second of the transactions to fail to import with a duplicate number error.

I know that Steve’s product suggestion references the Payables Management script (taGetPMNextVoucherNumber), but I would like all of the related “GetNextNumber” scripts reviewed and fixed if necessary.

For more information on the issue, see Steve’s blog post:

So if you think it is important that these eConnect scripts are fixed so they can handle the multi user concurrency issues without returning duplicate numbers, please vote using the links below.

Click on the link below:

Here is the URL for the link

Note: If the link does not work for you, go to https://connect.microsoft.com/directory/ and sign in with your Microsoft Account (MSA) and then find Microsoft Dynamics – Microsoft Dynamics GP in the list and click Join. Then try the links above again.Thanks


This article was originally posted on http://www.winthropdc.com/blog.

5 thoughts on “#MSCONNECT GP – Bug in taGetPMNextVoucherNumber causes duplicate voucher numbers to be issued

  1. I voted for this, but I have another for your list…


    the stored procedure is: sopGetMasterNumber

    It has been broken since at least 1994 (yes, 1994! 22 years!). Many people have attempted to address it, some with triggers. Triggers are also still dangerous to Dynamics GP since the dev team hasn’t updated their code to use SCOPE IDENTITY rather than IDENTITY to return the DEX_ROW_ID of the recently created/updated record. Patrick Roth wrote a guest column on your previous blog. Oops, another suggestion.


    Tim Foster


Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s