Sales Order Processing posting statuses
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.
Transcript
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.
Example:
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!
MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
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.
Transcript
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.
Example:
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!
MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Comments
Any help will be appreciated.
short code
Dim salesprocessholdsetupKey As New SalesProcessHoldSetupKey()
salesprocessholdsetupKey.Id = ddl_hold.SelectedItem.Text
Dim salesprocessholdkey As New SalesProcessHoldKey
salesprocessholdkey.SalesProcessHoldSetupKey = salesprocessholdsetupKey
Dim processhold As New SalesProcessHold()
processhold.Key = salesprocessholdkey
'error throws me on this line, it says object reference not set for processhold. Actually i tried to create the object but there is no in built class for processhold.
salesOrder.ProcessHolds(0) = processhold
Thanks
Regardless of the status, if you have the same document in work and in history, it means something went wrong during posting.
You will need to troubleshoot the issue and determine whether you need to remove the document from the work and/or history tables.
MG.-
Mariano Gomez, MVP
I have a SQL query in front of me on the SOP30200 and SOP30300. All of the Invoice transactions that I see follow what you say in this post. However, I have both Order and Quote transactions that have a Posting Status of 0 which I would assume indicates Unposted. Does that make sense?
Jon
Quotes and Orders do not get posted, but must have some status. In this case 0 (Unposted).
Why do you want to delete the transaction? Since it has no line items, it should not impact inventory. The line items would be in the SOP30300.
Kind regards,
Leslie