Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
SOP entry, user creates a new order to find that it populates with lines from an order that another user is currently entering somewhere else in the room. Effectively they have both been issued the same new SOP number, I guess. Occurring more frequently since going to GP2010 but did happen before on 9 too. Anyone else seen this solved it or mitigated the risk of people overwriting each other's orders?
I should add that this form is modified and is running a Visual Studio Addin code.
Could it be that I am upsetting something inadvertently? The code is doing things like checking for previous customer PO numbers (yes I know these days this is in the prof tool kit) and defaulting the batch field and a bit of other stuff. Like preventing save until all is well with the order.
Is this a reproducible event? I would first try removing the VS dll out of the add-ons folder and see if this problem goes away.
Not reproducible on demand, this happens once every couple of days (perhaps) with about thirty SOP users. I'm currently getting users to log when it happens so I can get a genuine quantitative handle on it without user exaggeration.
Removing the modifications is not really going to work for me as they contain a lot of business workflow logic, essential validation that if removed would present more risk than this problem.
Do people start a new SOP document and then back away without doing anything? I am wondering if the SOP number goes back into the pool to be used again.
what do you mean by "back away", they may leave the new SOP number sitting for a while before the next call comes in before then entering the debtor id or may "x" out the window having been on a new SOP number... or do you mean some other scenario I need to be aware of?
Let's say you have 30 people entering orders.
User 27 is sitting on the SOP screen and has tabbed down to the order number and gets SOP # 0100011 and then just sits there.
In the mean time, other users are taking orders and now the next SOP # is 01000030.
Now user 27 exits the screen and never enters anything for order 0100011 so now this order number can be reused. I am not sure if the next user will get 0100011 or will he/she get 0100030.
Can anyone else chime in on this?
Certainly if the number is released back an no further numbers have been issued, then that previous number will be reissued.
This is why I feel the client may be incorrectly releasing the number then at a later time saving its tables back to the DB overwriting the poor soul who got issued the number again.
What triggers are there in the SOP Entry Form for the release of the SOP Number back into the "pool"?
Check out this script to see if Master Numbers are shared by more than one sales document. Perhaps there will be a clue with this.
-- Script to identify duplicate Master Numbers
-- on Dynamics GP SOP Documents
With WorkHistUnion (MSTRNUMB, SOPNUMBE )as
(SELECT MSTRNUMB,SOPNUMBE FROM SOP10100 WHERE SOPTYPE=2
SELECT MSTRNUMB,SOPNUMBE FROM SOP30200 WHERE SOPTYPE=2)
SELECT MSTRNUMB, COUNT(MSTRNUMB)from WorkHistUnionGROUP
BY MSTRNUMBHAVING COUNT(MSTRNUMB)>1ORDER BY MSTRNUM
I found this at
There is other useful informnation on this site regarding GP SOP.
Thanks for checking out my site - I guess I'll have to blog about my findings on this problem too!
Tonight I'll set up a SQL monitor on the next sop number, create an order and see if I can get it to release the number back prematurely, that will indicate where my problem is.
I'm also going to dig into what the stored procedure gets up to (taGetSopNumber).
Thanks for letting me think through the issue with you.
I remember way back in the days of eEnterprise having a similar problem and they provided an updated script. I would only image that today they should have the latest and greatest script getting the next SOP number. Sorry about referring you to your own article but I guess that shows how popular your article is. Hopefully you will find an answer. I would be curious to know what they answer is so please keep me posted.
It is reproducable, yes, I have seen it before. It took 4 years to figure this one out because it was so random.
User one enters an order and saves it. They do NOT leave the Sales Transaction Entry window nor do they look up another document. Just take their hands off the keyboard.
User two opens the Sales Transaction Entry window and takes the "next number" Frequently they get the same number since the original order has not been completed but is partially released.
This has been reported to GP
Thanks Richard for confirming the issue, but going back to my original question "Anyone else seen this solved it or mitigated the risk of people overwriting each other's orders?"
I could force a form close() on the SOP Transaction Entry window to force the user clear of the order after each save? Very annoying for the end user but would ensure data integrity.
Perhaps I need to introduce my own transaction "locking" mechanism where I myself hold a record of the order locks outside of the GP tables so I have confidence over no two users having the same order number on screen at the same time?
(recently we bought the Accolade complete GP set of texts, excellent reference material, wish I'd had it 10 years ago!)
I encountered this this today, this is the solution that I came up with dynDeveloper.com/.../0WX0
For anyone intererested in the solution without linking out the forum, the discussion continues here:
This thread is talking about the SOPNUMBER being the same. Your solution is about the master number, does that make it appropriate for this problem too, (where two users get the order number hence overwrite each others order lines)?
Business Applications communities