Dynamics Community Forum Thread Details

SOP Invoice wont' Move to History - Not the Normal Issues

Greetings,

I’ve run into a situation with a SOP Invoice that I cannot resolve. There was a posting interruption on a single invoice and once I recovered the transaction and posted, it did not move to history. I’ve done everything that we normally do in this situation (SY00500, SY00800, SY00801, dex_lock, dex_session, Reconcile, Remove Completed, checklinks). The Posting Status in SOP10100 = 0 which I thought may be the issue, so I updated it to 9 and ran reconcile/remove with no luck.

The source of the invoice is a regular SOP Order and a portion of the order was transferred to B/O. This is not a situation where the Invoice is in both Open and History tables, only in Open.

Any suggestions on where to look? Thanks in advance!

Jim

Jim,

I am mostly convinced that such posting interruptions issues can only be handled on the back end, which requires manual (insert/update/delete) statements. In your specific case, I would simply recommend one of the following solutions:

Scenario One | Posting interruption caused a corruption on the SOP level only, which means that Inventory and General Ledger have been affected accordingly

In such a case, I would recommend recovering the SOP tables as illustrated below

You will have to manually transfer the SOP records from the header and details tables, which store the transaction header information and line items:

For SOP Header SOP10100 (Work)> SOP30200 (History)
FOR SOP Details SOP10200 > SOP30300 (SOP Line Items)

As for the SOP distribution, comment, bin quantities (if any) and commissions, they are shared tables among the work and history and you will have to do nothing about them. No harm at all from checking the records

SOP10102 Distribution
SOP10202 Line items comment
SOP10101 commissions
SOP10203 Bin Quantity

Scenario Two | Posting interruption caused a corruption on the SOP level only, and the posting process didn't complete to post records on the inventory and GL level (which means IV and GL has no records at all)

In this case, I would recommend deleting the work records from the SOP table, which are illustrated above in the previous scenario.

For both Scenarios , you will have to check the receivables whether associated amount has been recorded on the customer level. Consider the debit or credit memo solution either to increase or decrease the customer balance accordingly rather than playing with the RM tables.

For permanent recovery, find the root causes of such posting interruption as I can clearly see that they are frequent, and cut the bleeding by taking the corrective actions. I have been handled several environment which had old versions of Dynamics GP and poor infrastructure (hardware specifically) , and the bleeding was catastrophic. The resolution was always to provide the minimum requirements of infrastructure in order for Dynamics GP to work properly and prevent such bleeding. Believe, the preventive maintenance has always been far less costly than the corrective one.

Please feel free to share any further concerns,

Quick Links

Leaderboard