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 !?!?! :-).