WM stock not acting as it should

[Former Member]

Hello, I hope you are all doing well

I have a challenge that is proving very difficult to find the root cause. My WM stock situation is not acting as it should

My current theory is that one of the t.o. update tables must be failing to update so the system does not see the existing transfer orders for some time.

Actually 3 issues related to the same errors in my opinion;

1. system is allowing stock removal of inv. already promised on open t.o. (when we do not allow negative stock per config)

2. system is sending picks to bins without enough stock

3. locking quant's in 110 that require SAP intervention to clear, the quant's are locked due to discrepancies in the t.o. update tables. (LQUA and LQUAB)

I think these are all from the same root cause but I could be wrong.

What could the root cause be?

Where should I look to prove or disprove my thoery about the t.o updates to WM causing this?

If I could find a t.o. that shows updated in both the header and line items but do not update to WM until some time later I could prove my thoery...

Is there another table that must update before the t.o. will show in t.o. searches (a table other then the header/line item tables)?

ANy thoughts, ideas would be appreciated since I am stuck with no answer

[JL23 · Accepted solution]

If SAP would fail with the update, then the user usually gets an express message and you can see the update failure in SM13 and can analyze why it failed posting.

Check the definition of your storage type whether you lock for picking at storage bin, or only at quant, or not at all.

This could at least be one reason why you can have TOs in parallel.

That SAP proposes picks from bins without enough quantity might have to do with wrong information in summary table LQUAB.

which is in turn caused by wrong capacity check method, or earlier changes to capacity check method while you had stock in the storage type

[Former Member · Accepted solution]

> If SAP would fail with the update, then the user usually gets an express message and you can see the update failure in SM13 and can analyze why it failed posting.
> 
> Check the definition of your storage type whether you lock for picking  at storage bin, or only at quant, or not at all.
> This could at least be one reason why you can have TOs in parallel.
> 
> That SAP proposes picks from bins without enough quantity might have to do with wrong information in summary table LQUAB.
> which is in turn caused by wrong capacity check method, or earlier changes to capacity check method while you had stock in the storage type

Hello, Thanks for responding

I think the user for the actual update would be the batch job? (since the t.o. are created /confirmed OK from user perspective, just the system update that has failed)

Unfortunitly I am not having authorization for SM13 in production systems and we do not see the error in development systems.

I don't understand "whether you lock for picking at storage bin, or only at quant, or not at all" I see no option in storage type definitions to select or de-select locking. Also note there have been no changes to our storage type definition details that I know of and the problem is new (years since go live.)

The locking issue we see from table descrepencies are on the quant level if that's what you were refering to.

I cannot see any selection for capacity check method (nothing it selected or checked)

Any ideas?

Edit: I think it is safe to say that the locking quant issue we are seeing where LQUA and LQUAB tables do not match show proof that the update may take a long time or fail. I think it is clear that is the cause of the other two issues.

How do I prove it to my seniors?

Edited by: Arakish on Sep 14, 2010 12:14 AM

[Former Member]

Also note the update to LQUA and LQUAB failing my be the root cause, I cannot find a time stamp for updates to LQUAB (quant totals table)

Is there a way to see a time stamp for this other then viewing the tables (since it doesn't seem to be avialable in SQVI)?