Well, everyday I learn something new. My friend and fellow MVP Victoria Yudin had been wondering what could be the possible values stored in the PSTGSTUS ('Posting Status') column of the tables dbo.SOP10100 (technical name: SOP_HDR_WORK) and dbo.SOP30200 (technical name: SOP_HDR_HIST) statuses as a result of a posting operation in Sales Order Processing.
In fact, just recently on the Dynamics GP Newsgroup, someone reported seing a status 508 in the SOP30200 table. The complete list was provided by a Microsoft support engineer on the Partners forum -- take note as they are not documented in the SDK.
All transactions in SOP10100 that have not been posted yet should have a PSTGSTUS value of 0 (unposted). This value of this field will change to 2 (posted) when posted and the record will move to SOP30200. With this in mind, all transactions in SOP10100 should have PSTGSTUS value of 0 and all transactions in SOP30200 should have PSTGSTUS value of 2 (posted). Any other values in either table would indicate that there was a posting interruption.
I have found invalid values of 12, 14, 508, etc. These values may have been assigned to the record in different stages of the posting process. Meaning, the posting process did not complete and the transactions need to be recovered in the Batch Recovery window.
1. Transaction 1 in SOP10100 (Work) with PSTGSTUS = 0.
2. Transaction 1 is posted:
a. PSTGSTUS is assigned the value of 7 while GP is checking for duplicate Document Numbers.
b. PSTGSTUS is assigned the value of 12 while GP is verifying the accuracy of the amounts between the detail and header records.
c. PSTGSTUS is assigned the value of 14 while GP is calculating that the total detail amounts match the header amount.
d. PSTGSTUS is assigned the value of 508 while GP is is in the process of transferring the record from Work (SOP10100) to History (SOP30200).
e. PSTGSTUS is assigned the value of 600 while GP is validating if the detail and header records match in the History tables (SOP30200 and SOP30300).
f. PSTGSTUS is assigned the value of 2 upon the end of the posting process.
In this example, if the posting process was interrupted after step a, then the record will still be in SOP10100 with a PSTGSTUS = 7. Or, if the posting process was interrupted after step d, then the transaction may still be in SOP10100 with a PSTGSTUS = 508.
The example above is not the exact posting process in GP. This is just a way of showing how a record in SOP10100 can have a PSTGSTUS value other than 0 and 2.
I must personally add that a transaction will only make it to SOP30200 with statuses of 2 or 3, as the transcript indicates, the other status are more used as a workflow within the posting process than really a status.
Until next post!
Mariano Gomez, MVP
Maximum Global Business, LLC