Stock not cleared from 916 storage type in sap wm

[Former Member]

Hi,

We are facing one issue where user has picked the material against out bound delivery but has not completed PGI.

Thus,till that time we have stock in 916 storage type against that delivery no. But because of change in customer requirement, PGI will not be done against some of these deliveries.

Now as per process, we should first do LT0G to return stock to location and then LT12 to confirm the TO created out of this activity.

Subsequently, delivery can be deleted.

However, in our case sometimes users directly deletes the delivery without actually doing LT0G and LT12 transaction. Thus, the stock remains stuck in 916 storage type.

Is there any standard SAP message which can be set as warning or error , so as to stop deletion of delivery if LT0G(return to stock) is not completed.

Thanks,

Vishnu

[mihailo_sundic · Accepted solution]

Ok, here's how to do it:

In OVM1 find message VL 173 - set it as E - Error message.
In SE91 you can set a custom description for the message to be explanatory, e.g.:
"Please do a LT0G prior to deleting confirmed line items or entire delivery."

By the way, this is a good question since all the implementations have problems with this check which is disabled by default, and it just doesn't make sense, even in IM it should be enabled since it prevents deletion of items / deliveries which have a value in confirmed / picked qty.

Glad to help on this, cheers.

[joao_sousa2 · Accepted solution]

As a side note is it really a good practice to use LT0G? Shouldn't the warehouse workers actually confirm that the stock was returned to the original bin?

Lets say the cargo was waiting loading when the delivery is canceled. You need to physically store the materials back in the warehouse, and should have a TO to support that in RF.

This is the only transaction in which you can actually reverse a TO.

[mihailo_sundic · Accepted solution]

I don't agree with some of the posters that using LT0G is not good practice.
You can also create RF version of LT0G and then use it withing warehouse to quickly
return the picked goods to warehouse from picking zone.

Never had any problems with both LT0G and its custom RF version (ZLT0G in my case).

[joao_sousa2 · Accepted solution]

For my point of view work in a warehouse should be task/queue oriented and LT0G (standard, not RF variants) defeats that purpose. Especially in a RF enabled warehouse, a adminstrative person sitting at a desk, shouldn't be able to post movements in storage bins.

Also the physical process of returning the picked quantities to the storage bins is not "quick", and the source storage bins may now be full with something else.

For me the best practice should be to store the goods in a similar way to how they are stored from 902 or 922, where you run the putway strategy, and generate work orders for the restorage of the material.

And like I said, LT0G doesn't even work for HU-managed storage location, and SAP never enabled that functionality.

[mihailo_sundic · Accepted solution]

Our custom LT0G doesn't necessarily putaway pallet to the source storage bin, it checks putaway strategy and the available capacity and proposes the most suitable bin. Just like 902 putaway works.

[joao_sousa2 · Accepted solution]

Like I said, my problem is with standard LT0G. Your custom development, although it shares the name with LT0G, is something else.

[Former Member · Accepted solution]

Thanks for your response.

The meesage is shwoing error when delivery is deleted before LT0G.

However, One of my requirement is to show this message only in plant where warehouse is implemented and not in other plants.

Can we do any configuration for this also.

Thanks,

Vishnu

[Former Member]

This message was moderated.

[mihailo_sundic]

Yes there is a standard message, I have implemented it in all of my WM projects.

Let me get back to you on the exact message number and the process for activating it.

[Former Member]

That is really a training and process issue in my opinion. The staff need to understand that moving stock into or out of 916 with a 999 TO does not update the delivery statuses and in the exact same way they need to understand that deleting a delivery does not put the stock back in the source bin. They need to understand the way a pick TO updates a delivery while other TO types do not just as much as they need to understand they should not delete a delivery before adressing the stock.

It is not any more difficult to move stock out of 916 with LT01 after a delivery is deleted then it is to return the stock with LT0G so really the only issue I see is training and basic understanding is needed.

If the staff dont have this understanding you will see issues indefinetly with people moving stock into and out of 916 thinking it will update the delivery (when we know very well it does not).

Just my thoughts on your question - sorry to not give you a specific solution for your error message

I can recomend that you set the TO confirmation to immediate when using LT0G - theres no point in having them use LT12 to confirm.

[Former Member]

Thanks Jacob,

Ya i understand that it is a process issue, however this issue happens sometimes in a week where due to high volume of transactions , end users forget to complete return to stock step and directly deletes the delivery. This typically happens when delivery is created by one person while ot is deleted by another one.

So i was looking for some message which can be set  through SPRO.

Otherwise, we will go for some enhancement.

Thanks,

Vishnu

[Former Member]

Job security - enhancements for user errors 🙂

If you use packing materials in the outbound deliveries I know that you can maintain a hardstop error if the delivery still contains HU. If you use shipments you can maintain a hardstop for "still contained in shipment or loaded status" That may help to aviod the issue because they may remeber they need to unpick/unpack before they delete when they get the hardstop "still contains HU" or "contained in shipment". I am not aware of a standard hard stop for delivery deletion after pick confirmation with no HU or shipment involved.

If anyone else is please reply for Vishnu 🙂

[joao_sousa2]

Job security - enhancements for user errors 🙂

There is job security either way. If you don't do the enhancement your job is to keep correcting user mistakes.

[joao_sousa2]

LT0G is a dangerous transaction to use process wise, since the goods have been picking and the return to storage should follow a controlled process (i.e the return to storage should be done with another TO).

It doesn't work with HU managed warehouses and SAP never made it available for those, probably because it's not such a good idea to use (process wise).

It's not possible in standard SAP but you can easy create an enhancement that check that in the delivery processing badi. It's very simple.