EWM - Delete Handling Unit when adding to existing Handling Unit - Putaway strategy

[ewmguy11]

Hello SAP expert,

I have the following situation. I have a storage type (RL05) for a rack storage. Most important settings for the storage type are:

• Putaway rule 2: Addition to Existing Stock/Empty Bin
• HU requirement X: HU is required
• WT Generic 2: Only Storage type is suggested by the system (the workers in the warehouse want to choose the bin by themself...)
• Mixed storage/Mixed storage in HUs: no restrictions
• Level Add. to Stock H: Addition to Stock at Highest HU Level

Rest of the settings see screenshots:

 

To the case:
For example I have the HU 810000167 with a quantity of 1 ton of the product 1000000058 on the bin RL05-01-01-01-03. 

Then I get a new inbound delivery of the same product (or also another product) with maybe 0,5 tons and I want to put those 0,5 tons to the existing HU 810000167 and throw away the Handling Unit where the 0,5 tons were on. We are working with Handling Units 100% of the time and create the Handling Units already in the delivery with the Fiori App. And when doing the putaway to the existing HU, I get of course a nested Handling Unit. 

New inbound delivery with warehouse task of the product:

Confirm the warehouse task in the foreground to the existing HU 810000167 which is already on the bin:

Then the stock looks like this on the bin with a nested Handling Unit:

Is there a way to set up the system to delete the Handling Unit when adding it to another HU so I avoid that a nested Handling Unit is created?
What I would like to have as a result is only the HU 810000167 with a quantity of 1,5 tons. 

Thanks in advance!

[nn1]

I discovered that this only works when the WT is confirmed via RF. When confirming via backend the HU always gets nested.

[schulte-bahrenberg]

...looked at this topic also. I think these are the options that you have:

- putaway WT is a product WT: change destination HU via exception code CHHU (source HU will be deleted automatically)

- putaway WT is a HU WT: change destination HU via exception code CHHU and unpack the source HU via an implementation of Badi /scwm/ex_core_co_unp_outhu 

How to control the creation of product vs. HU WT was already mentioned in other comments below I think - won't repeat that here. 

Hope that helps!

Regards,

Hendrik

[bruce51]

Hi Hendrick, I have the same requirement, and would like to unpack the source pick HU into an HU already available in the the storage type. When I use the BADI /scwm/ex_core_co_unp_outhu the system empty the HU but does not unpack the pick HU content into the destination HU. My scenario is the following: I pick items by using a pick HU and move the pick HU to a storage type for "consolidation". I am in process oriented scenario. If an HU exist for the the same outbound delivery order I would like to complete the existing HU with the pick HU content if enough place. Using the exception code CHHU for the destination change, and once the WT confirmed the pick content would be unpacked into the HU. I tried with the BADI, but does not work. The BADI empties the HU in the bin, not in the destination HU. I am in RF scenario. I will take a look at the method REPACK_STOCK. Regards. Bruce

[nn1]

Hi,

Did you solve this issue?
We have the same requirement but we only end up with nested HU´s regardless if we use HU WT or product WT. 

[ewmguy11]

Hi,

yes, in the settings for the warehouse process type (SCM EWM -> EWM -> Cross Process Settings -> Warehouse Task -> Define Warehosue Process type) I had to deselect the following option "Select HU Without Storage Process". If this checkbox has not been selected, the product items of a handling unit without a storage process are put away via product warehouse tasks.

But it only works if you confirm the warehouse task via the /n/scwm/RFUI. Confirming the warehouse tasks in the monitor I was not able to make it to work, which is fine in my case.

I hope it helps.

Greetings

[nn1]

Hi ewmguy11,

Thanks for your answer!

Yes, we have the same setting in the process type, and also I discovered some day ago that it was possible from the RF.  But it's not possible from the monitor or via the Fiori APP.
I find it a little bit strange that you have customizing tables in order to control how the system reacts, but then there it's different coding for different user interfaces that behaves in different ways, which makes it confusing and time consuming when testing different settings. But now it's working anyway.

SAP sometimes works in mysterious ways;)

[bruce_huang]

Hi, 

From your example, you've created an HU WT for Qty 0.5 ton which leads to the nested HU. 

You should create the product WT instead.

BR,

Bruce Huang