This one was a real menace for me, to say the least.
One of the Users reported the error message “This document has been posted.” for a particular SOP Document.
The following were the observations:
1. This document was never saved in a batch.
2. GP hung at the time of entering this document.
3. The User killed GP session in order to come out of the Hung Session.
4. User confirmed that he did not enter any Batch while creating this Document.
5. Once restarting GP (after the KILL), he entered the SOP Number (which he had noted down) and received this Error Message.
Following this, I first resorted in clearing all the Activity Records (ACTIVITY, SY00800, DEX_LOCK & DEX_SESSION). There is a KB article, KB#857082, explaining this issue and the resolution. BUT this did not solve the issue at all. I was still getting the same error message again.
I checked the SOP10100 table for the record and found that document residing there. Also in SOP10102 and SOP10200 tables. Now, I did the following:
1. Created an SOP Batch in GP.
2. Updated the SOP10100 record for that document with the Batch Number that I created in GP.
3. Tried opening the document, but in vain. Still the same error.
4. Checked several updates but to no avail.
After quite an amount of frustrating time, SQL Profiler and Dex Script Log, I found the following:
Batch Source (BCHSOURC) field of table SOP Header Work (SOP10100) MUST NOT BE EMPTY. It has to be “Sales Entry” (Note the Cases; It has to be exactly “Sales Entry“). If the Batch Source field is empty, GP understands that this document is a Real Time document and that it should not be residing in SOP Header Work table at all.
Alright, after I updated this field, I am good to go to open that stuck SOP Document.
NOTE: Always in scenarios like this, delete the SOP Document and recreate it. It’s not advisable to amend anything to this released SOP Document. We never know what else would be wrong with such documents.
Happy Debugging; What else could I say !?!?! :-).
Awesome finding! In my case I found that BCHSOURC was showing "*Sales Entry" instead of just "Sales Entry". I removed the asterisk and the transaction was available again. I need to investigate the origin of the asterisk.Thanks!Hector
Hi Hector,Thanks for dropping in.Basically "*" will be added to "Sales Entry" when a Transaction is under posting or editing process. System locks the transaction by doing this, even when the Batch Edit List runs.That's what I found. May be there is more to it.Vaidy
Thanks! I had a similar issue. Turns out I had "**Sales Entry" (note the 2 asterisks) intead of "Sales Entry" in the BCHSOURC field. I've been looking into why it's there with no luck so far.
Hi – I've done this before, but it's been so long I have to confess that I've forgotten where to go to find that batch. Can anyone give me the fields to click to find it? I'd like to take care of it myself instead of contacting my computer company everytime. Thanks
You should but the syntax for t-sql in here so that people who are new or newer can update the sop table, just a thought since I'm still new to T-SQL programming
Great resolution, it worked for me.
The correct syntax for those who do not know SQL is:
USE (Change to the name of your company DB IN SQL)
UPDATE SOP10100 SET BCHSOURC = ‘Sales Entry’ WHERE SOPNUMBE = ” (Change to the one that is stuck)
Disregard my previous post, I can’t post the SQL syntax here because the comment board is removing some of the special characters in my comments.
Please email me the SQL code that you wished to share. I shall post it for readers.
Awesome, works for me. It was “Sales Entry” missing. After updating BCHSOURC with “Sales Entry” I could open the order. Thanks for your help!!