Storage unit management questions

[Former Member]

Hi All,

First, I would like to thank people for their prompt and useful help around these forums.

Unfortunately I have some more questions regarding storage units.

1. When I create a picking TO for a delivery, the system automatically determines the storage units to be picked. However, those storage units may not be available - they are behind/under other pallets. Is there a standard way to prevent the system of determining the SUs during TO creation? We would like to chose the SUs by mobile device during confirmation.

2. I have set up the GI area as SU managed, because I do not want the SU to be lost in case it needs to be moved back. Now if I want to pick a partial pallet, the system recreates the SU in the GI area - this causes a short dump due to external SU numbering. What would be the best way to avoid this? Basically for partial pallets, the SU number is no longer relevant - but how to tell this to the system? I was thinking that in this case a user exit could give the picked pallet another number. Is this possible and/or is there a better solution? A workaround could be to split the pallet into a non-SU managed st. type, but thats a lot of additional work.

Thanks.

[Former Member · Accepted solution]

I can answer the first question,

If you do not want the system to prompt the SU during picking, then do not set up the search strategy (TCode OMLY).

For the second question, I will have to check the available user exits for feasibility.

Regards,

Aroop

[Former Member]

Hi gurus...

I have the following problem.Scenario: I am doing the picking in two steps, I have activated the SUs management in the intermediate warehouse type of the picking in two steps.

Issue: When I create the TO, the system assigns a destination SU, nonetheless, I need to assign that SU (external) in the confirmation (because in that moment I stick the pre-printed label in the pallet.) I do not see the way to modify the SU DESTINATION that the system proposes.

I also thought of using the assignation of HUs, but it is not possible in the first step of the picking in two steps (movement 850), it is only possible in the movement 916.

Please I apreciated your help!!!!

Thanks in advance

Gloria

[Former Member]

Some more explanation.

When using bulk storage the system does not determine SUs when creating the pick TO. This is good. However if SU mgmnt is active at 916, then I got the message: Internal number range too long. Thats because we do not use the internal number range at all, we use external. So it seems, the picking TO wants to assign SUs (at st. type 916) at the creation of the TO. Since there are no SUs determined from the source bin, it wants to assign new SUs. Thats just WEIRD!!!

This means if we want to reverse a picking, we need to assign the external numbers again.

Edited by: HunLogistic on Jan 22, 2010 9:55 AM

[csaba_szommer]

http://help.sap.com/erp2005_ehp_04/helpdata/EN/c6/f846014afa11d182b90000e829fbfe/frameset.htm

Stock removal from the warehouse usually has the goods issue interim storage type as the destination storage type in WMS. This kind of interim storage type cannot be SU-managed. Therefore the information on the SU is lost when the SUs are removed from the warehouse.
The SU no longer exists in WMS as soon as you confirm the transfer order item for this SU.

So, this is normal behaviour of the system and I don't think you should change it...

Regards,

Csaba

[Former Member]

Hello,

My suggestion is deactivate SU in 916, you should try the transaction LT0G during the reversal proccess, this enable to return the stock with the same number of SU, in fact you can added before creating the TO that request the return.

I hope it helps.

[Former Member]

Thanks for your responses.

Switching off stock removal strategy did not work, because then I had to specify bin when creating a TO and that resulted in the system determining SU numbers.

The solution is to use bulk storage. However it does not seem possible to retain the SU number at st. type 916, because the system wanted to assign a new SU number from the number range at 916. So I had to switch off SU management at 916. Would it be possible to avoid this somehow?

Lots of development will be needed to fulfill the requirements of our client or we have to use handling unit management, but that is a lot of additional administration.

Edited by: HunLogistic on Jan 22, 2010 9:51 AM

[Former Member]

Hi,

See my answers below:

1. When I create a picking TO for a delivery, the system automatically determines the storage units to be picked. However, those storage units may not be available - they are behind/under other pallets. Is there a standard way to prevent the system of determining the SUs during TO creation? We would like to chose the SUs by mobile device during confirmation.

Make the Storage Type as SU Managed Bulk . Then system won't suggest any SU on the TO and allows you to pick any SU in the bin.

2. I have set up the GI area as SU managed, because I do not want the SU to be lost in case it needs to be moved back. Now if I want to pick a partial pallet, the system recreates the SU in the GI area - this causes a short dump due to external SU numbering. What would be the best way to avoid this? Basically for partial pallets, the SU number is no longer relevant - but how to tell this to the system? I was thinking that in this case a user exit could give the picked pallet another number. Is this possible and/or is there a better solution? A workaround could be to split the pallet into a non-SU managed st. type, but thats a lot of additional work.

Did you make 916 SU active to retain the SU number? But once PGI is done, that data will be gone any way.

Another alternative is that, set the packing relevant flag at the Delivery type level. And try to use pack functionality. In this case, you can use the same SU number to pack it to HU in case of full pallet and different HU number in case of partial pallet. There will no dumps in such a case.Also SU numbers will be retained even after PGI.

Hope that helps.

Thanks

Vinod.