If you have ever spent time on a warehouse floor during a heavy goods receipt shift, you know exactly how painful the “re-labeling bottleneck” is.

A vendor’s truck backs up to the dock. The pallets roll off, perfectly wrapped and already sporting crisp, clear vendor labels with external tracking numbers, in same cases question why receiving team has to stop, print out fresh internal labels or even using external reprinted HU. and slap them over the vendor's original ones. is why shouldn't use that and re-label using internal number.it wastes time of label paper,and it slows down the entire inbound flow.

SAP recently rolled out a note for that feature : SAP Note 3531190 – Usage of Alternative HU ID in EWM RF.

Here is a practical look at what this change does, how it fixes the workflow, and what you need to look out for before turning it on.

Standard RF transactions required workers to scan the internal EWM HU number for tasks like unloading, putaway, or picking, or even external reprinted HU from your HU buffer, If you didn't re-label the pallet, your RF gun simply wouldn’t recognize the vendor's barcode.

With this new update, SAP has introduced a flexible Business Add-In (BAdI) framework that essentially teaches your RF guns to understand both languages. As long as the vendor’s external tracking number is saved in the system as an “Alternative HU ID” (specifically ID type ‘E'), your warehouse floor gets a massive usability upgrade.

Note: The BAdI implementation can't be done directly from IMG (Customizing) because such objects can't be shipped via note. Please use transaction SE19 (BAdI Builder: Implementations) to create your BAdI implementation. In the note there is a attachment describe example in case of multiple HUs with same alternative HU ID how it looks like, If multiple HUs have the same alternative HU ID, the RF user must select the right one. For this, a list is shown with additional information which might help the RF user to identify the right one through value help.

Warehouse operators can now scan or type the vendor’s original label directly into any HU input field across all standard RF screens.

When a worker pulls up an HU on their RF device, the system automatically translates the internal EWM number on the backend and displays the vendor's external ID right on the screen. It keeps things consistent and highly intuitive for the person doing the heavy lifting.

If two different vendors happen to use the exact same external barcode sequence, the system won't just crash or error out. It will present the user with a list so they can select the correct internal HU (though, from an organizational standpoint, it's still best practice to try and keep vendor IDs unique).

Limitations to Keep in Mind:

There are a few operational boundaries you need to design your processes around:

• Alternative HU ID with more than 20 characters.
• Some HU display fields only display 20 characters and are not scrollable. For details see attachment.
• RF screens with more than one HU field.
• Output conversion shows interal EWM HU number instead of alternative HU ID. For details see attachment.
• Voice-Enabled RF transaction (Pick-by-Voice).
• Field length limitation and grammar for verifcation don't fit. For details see attachment.
• Creating new HUs in RF Unloading or in RF Receiving of HUs.
• As mentioned before it is required that the HU exists in EWM and that the alternative HU ID is stored in HU data. Creating completely new HU during RF Unloading or RF Receiving of HUs is therefore not possible. you might create the HU with an internal HU number and later on assign the alternative HU ID manually in a Packing Workcenter (transaction /SCWM/PACK).
• Using TAB key instead of ENTER key for field navigation.
• System needs to know the actual field to fill the value help list. This can only be done if the field to field navigation is done by pressing the ENTER key. If a user navigates from field to field using the TAB key, the backend is not informed and the information about the actual field is not correct. 
• Performance
• General hint that the BAdI implementation is called inside the conversion exit and that conversion exits are processed very often (even if the cursor is in another field). Because of this, the coding of the BAdI implementation should be as efficient and restricted as possible.