Order Number Sticking

(0) Share

Report

Posted on by Community Member

Hello all

Our customer service team are experiencing a problem when creating orders, the issue only happens intermittently but it is a pain for them none the less.

Bassically user 1 will be entering an order (head details and line details filled out) and when another customer service rep goes to create a new order it generates all the information that has been created by the first user.

As I say though this is an intermittent error and not replicable so running a trace or turning on the dexsql.log is not an option. We have tried overloading the system with orders to see if we can force the issue out.

Has anyone come across this error before or have any ideas what it could be....I have checked that the system pulls the next order number from the sop40200 and it works fine 95% of the time.

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (0)

Community Member on at

Like (0)

Report

Joey, this is strange. What is the GP Version? Is this occurring in all the workstations? Do you have any customization or 3rd party product installed for SOP entry in place?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

GP10. Happens for all users and there is some VBA but this has been active for years and the issue only become noticeable in last few months

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Joey, Did you get a chance to look into the code behaviour for the document number defaulting.

Was this reply helpful? Yes No
Bill Campbell 12 on at

Like (0)

Report

An additional environment question - what hardware platform are your clients working on ? Individual workstaions, thin client, citrix client?

Just filling in some gaps.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I have not been able to witness the issue as it happens and when I have replicated and overloaded the system with orders i.e getting everyone who can to generate an order everything worked fine. so the sop40200 is doing its job as far as I can tell.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

GO is local and sql is networked, I think it might be a connection issue just not sure how it is :D

Was this reply helpful? Yes No
Bill Campbell 12 on at

Like (0)

Report

Sorry dont follow the response?

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (0)

Report

Oh yes we get that exactly, on sales order processing, sales order entry. I did a bit of work on it and raised it with MS some years back with no luck. It is due to the way GP reuses unused SOP numbers and the lack of locking between sessions in SQL.
I'll write up a blog post about it.
I solved it by disabling the script that reuses the numbers, but it does cause us to use up sop numbers at a high rate, as one is used up every time a user goes into the SOP Entry window.

My original post on this:
https://community.dynamics.com/gp/f/32/t/64371.aspx

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

thanks tim glad to see that it was a known issue. I logged it with MS and on this occasion were unable to help. Which is the script the reuses the numbers?

Was this reply helpful? Yes No
Tim Wappat 5,711 on at

Like (0)

Report

I've dug out my documentation. The solution involved calling the get next sop number procedure used by econnect by hacking the get next sop number stored procedure. Also introduced a logging table that logged the used sop numbers, preventing re-issue of the same number.

This worked fine for us but so unsupported that I'd rather not publish the details publicly, feel free to contact me directly.

I've posted the problem analysis here:

www.timwappat.info/.../Duplicate-sticking-sales-order-numbers-in-Dynamics-GP

Was this reply helpful? Yes No