Crash on order locking inventory 1

[clicker666]

I have a user who gets crashing at times while completing Sales Orders in Great Plains 7.5 SP5. Although resolving the crashing is the best fix for this, the secondary problem these crashes are creating requires more immediate attention.

When this user assigns inventory to an order, and the session crashes (before saving) the inventory is marked as assigned, and is no longer available for other orders. The initial order is, of course, no longer there because it was never saved. How do I release this inventory, or alternatively, prevent inventory from being assigned until an order is actually saved?

 

[clicker666]

I noted some other posts on this issue. Does anyone have a way for dealing with this other than checklinks and inventory reconcile? It's quite a pain to have to wait until *everyone* is out of the system to resolve this, it would be nice to have a non-downtime method that could resolve it right away.

 

[clicker666]

Doing the checklinks and reconcile doesn't release the inventory.

Interestingly enough, I can find the document in smartlist, under SOP. The document is blank though. All it has is a number, date and customer ID. No stock is present.

 

[jazgeek]

your header information is missing. either delete the records or complete the header information



-----------
and they wonder why they call it Great Pains!

jaz

 

[clicker666]

How, exactly would I delete it? I can't do anything with the document that I bring up in Smartlist.

 

[jazgeek]

sql

delete SOP10100 where DOCNUMBR = "BADDOC"
delete SOP10200 where DOCNUMBR = "BADDOC"

run checklinks afterwards to get rid of the excess
reconcile inventory afterwards



-----------
and they wonder why they call it Great Pains!

jaz

 

[jazgeek]

it might be SOPNUMBR instead of DOCNUMBR, I don't have a field description handy here.



-----------
and they wonder why they call it Great Pains!

jaz

 

[clicker666]

Thanks!

Isolating a known failed SOP Number I was able to use the following:

SELECT *
FROM SOP10100
WHERE DOCDATE='1/1/1900'

That seemed to be the common thread in the failed documents. I then confirmed those were the bad ones and deleted them.

For the second part I once again looked for the known failed SOP Number, and looked for a common feature. It appeared to be the SOP Type.

SELECT *
FROM SOP10200
WHERE SOPTYPE=0

I isolated a number of records, confirmed they contained the allocated inventory, and deleted them.

I'll run checklinks and reconcile tonight after everyone goes home, and post the results here. (Just for closure in case anyone else ever has this problem again.)

Thanks!

 

[clicker666]

Update:

The inventory people are happy! All the inventory is back to the proper numbers.

One question, so that I can narrow down the time it takes to complete this procedure.

I ran checklinks against all of the Inventory modules and all of the Sales modules. Are there particular modules I should target so that I can reduce the overall time for this? Also, I ran reconcile against all of the inventory modules. Can I select particular ones for this as well?

Tony