Another classic example of why we should read Newsgroup and Community posts, to learn more and extend the level of our Expertise.

I read this Dynamics GP Community post, SOP Transaction Issue, and there was a discussion on this issue. While this query is yet to be answered or provided a solution with, there are couple of things that we may learn.

1. David mentioned that the issue could be due to multiple users accessing the Next SOP Number. And the code might probably have dealt with Next SOP Number wrongly. I have been instructing this to anyone who asks me how to retrieve the Next Number (for any document that matters). As soon as you retrieve the Next Number from the Setup, you have to increment it by one and save the value in respective Setup Table. For instance, if I generate the SOP Number thru’ my code, I should first retrieve the Next SOP Number from SOP Setup table, then increment the SOP Number by one and finally update the incremented value on to SOP Setup table.

2. Ron Draganowski (of Olsen Theilen Technologies Ltd.) explained how SOP Entry form works when we enter a transaction. The issue of using GET TABLE statement on SOP_HDR_WORK table, was clearly explained. I shall brief you of what he explained: Once we start entering an SOP Document (precisely after tabbing out of SOP Number field), a dummy record is created with only SOP Type and SOP Number in SOP_HDR_WORK table and it is duly locked to store the rest of the values when the Save Record occurs. Now the point here is: Most of us would not know that while inside the SOP Entry process, using GET TABLE on SOP_HDR_WORK will silently release the locked record. And this will have a drastic effect in the later stage of the SOP document process.

Read this Community Post for more and complete details from David and Ron.

VAIDY