- SAP Managed Tags
Introduction:
Hi, everyone. in this blog i want to explain the BAdi implementation in the automotive spare parts business, particularly in warehouses dealing with mixed pallets. These pallets often contain many small line items- sometimes 400 or more individual parts in the single case(HU).
When we handle these mixed pallets, we typically deconsolidate the smaller materials and scan them individually as we remove them from the larger pallet. The scanning is done using a keyboard scanner connected to the deconsolidation work center.
Here’s the challenge: sometimes the same material appears across multiple line items in an inbound delivery. For example, one material might appear in five or six different line items. When the warehouse operator scans the material, the system attempts to propose the multiple warehouse task for the same material.
If a material has multiple warehouse tasks in the same handling unit (HU), SAP shows a pop-up asking the user to select the correct task. While this works, it slows down productivity because warehouse operators must make repeated manual selections for each small part.
In this example, we are working with Inbound Delivery 180000463, which contains mixed materials. Within the same case, the same material appears across different line items because, in the Inbound Delivery, it was created and packed under separate line items. Please refer to the images below.
For this example, I have set up a POSC scenario. The POSC process flow is as follows: HUs are unloaded from the door to the Goods Receipt zone, then moved from the GR zone to the deconsolidation work center. At the deconsolidation work center, the materials are deconsolidated, and based on the search strategy, the system determines the final putaway bin.
To simplify this demonstration, I have already created the required warehouse tasks, and the mixed-material handling unit is now available at the deconsolidation work center.
T code-/scwm/dcons - Login to the deconsolidation workcenter
Now, here’s the issue. When I scan a material, the same material is often linked to multiple warehouse tasks, since it appears under different inbound delivery line items.
As a result, the system prompts the user to manually select the appropriate warehouse task. In this example, there are only five tasks to choose from, but in some cases, there can be as many as 20 or 30. This means the warehouse operator has to repeatedly select the each task and then proceed, after which the quantity field is populated.
This manual selection process is not efficient and it consumes a lot of time and reduces productivity.
To improve efficiency, instead of showing a pop-up, we can use a standard SAP BAdI enhancement to automatically propose the first warehouse task and populate the quantity field. This way, the system handles the task selection in the background, reducing manual effort and improving productivity.
To implement this enhancement, we first need to identify the correct BAdI that is triggered after the product is scanned. Here, the system lists the warehouse tasks only after the scanning the product, which means there must be a BAdI connected to fetching that list of warehouse tasks.
We can identify the appropriate BAdI in two ways. The first method is by using the debugger to trace the process and determine which BAdI is being called. In the following example, we will use the debugger approach to locate the correct BAdI.
The known way of finding the BAdi is, setting the breakpoint in the method GET_INSTANCE in the class CL_EXITHANDLER
In this method, when we set a breakpoint in the GET_INSTANCE method, the changing parameter EXIT_NAME will display the BAdI name. This approach helps us identify classic BAdIs.
However, to identify a kernel BAdI, we need to set a breakpoint in the statements CALL BADI and GET BADI. This allows us to trace and determine which kernel BAdI is being triggered during the process.
In the example shown below, the breakpoint was triggered when I scanned the product at the deconsolidation work center. This is the exact point where we need to check the EXIT_NAME variable in the debugger (visible on the right-hand side).
We should continue checking each instance until we find the relevant variable that points to the correct BAdI. To do this, we can execute the program using F8, which will move to the next possible BAdI.
In this case, I observed that no relevant BAdIs were found-it executed completely and then displayed the list of warehouse tasks. This indicates that there is no classic BAdI involved in this step. Therefore, we now need to look for a kernel BAdI (new BAdI) instead.
To find the kernel BAdI, here’s what I do: after scanning the source HU and the material, I activate the debugger by entering the command /h in the command field. Once debugging is switched on, I set a breakpoint at the statements CALL BADI or GET BADI.
When the system reaches these points during execution, the debugger will stop, allowing us to identify the relevant kernel BAdI that is triggered after the scan.
Now, as you can see in the screenshot above, we’ve identified the correct BAdI. The code shows the statement where lo_badi is being called, and it references the method GET_WAREHOUSE_TASK. This appears to be the right place where the system fetches the warehouse tasks after scanning, so we can proceed with our analysis using this method.
Next, I’ll press F5 to go inside the code. Once inside, you can see at the top that the BAdI name and the corresponding method name are displayed. This confirms that we’ve found the correct BAdI.
To validate this further, we can set a breakpoint inside the BAdI implementation. By doing so, we can observe which variables and objects are being captured and what data is being processed. Using this information, we can simulate and test our enhancement logic effectively.
Alternatively, we can also locate the relevant BAdI through SPRO. To do this, go to:
SPRO → SCM Extended Warehouse Management → Extended Warehouse Management → Business Add-Ins (BAdIs) for Extended Warehouse Management.
Under this section, navigate to the master data, and within that, you’ll find the workcenter. There, you can see the BAdI named “BAdI: Determination of Warehouse Task for Deconsolidation"
So, this is another way to identify the relevant BAdI related to the deconsolidation process in EWM.
So, we can now confirm that this BAdI and its method are correct by setting a breakpoint. Once the breakpoint is set, you can observe the parameters, which are mostly related to the warehouse task. This helps validate that we’re working with the right enhancement point.
You can also confirm it by placing the breakpoint using the BAdI implementation ID. Then, execute the process again-when the debugger stops at that point, you’ll know you’ve reached the correct area in the code.
In the image below, it is clearly shown that when I executed the deconsolidation and scanned the product, the system triggered debugging and stopped at the breakpoint we set in the BADI implementation. This confirms 100% that this BADI method is relevant to this place.
You can also see the Locals on the right-hand side, which is very important. The table IS_HUDR contains the HU details, while IV_INPUT shows the scanned material.
Looking at the changing parameters:
IT_WHTA_OPEN lists all the open warehouse tasks. Currently, there are eight entries in this internal table.
CV_WHTA is the changing table where, based on the user’s selection, the system populates the selected quantity.
Now that we have the list of open warehouse tasks from IT_WHTA_OPEN, we can write logic to automatically populate CV_WHTA. Once auto-populated, the system can select the next two warehouse tasks automatically, so the user won’t have to select them one by one.
Please find the below sample code for the ref.
Now that we’ve implemented and activated the BAdI, we can proceed to check its behavior at runtime through debugging. Since the breakpoint has been set under the specific user ID, it will trigger during execution. From there, we can run the process and observe the flow step by step.
In the above picture, you can see that the breakpoint has been hit. The internal table IT_WHTA_OPEN contains 8 warehouse tasks. There is also a function module used to convert the scanned material number into its unconverted form. The output of this conversion is stored in LV_SCAN_MATID, which you can see on the right-hand side.
Using this unconverted material ID, we search within the internal table IT_WHTA_OPEN. During the loop through this internal table, we compare each entry’s material ID with the scanned material ID. If a match is found, we assign the corresponding TANUM ( warehouse task number) to CV_WHTA, and then exit the loop.
As a result, the system automatically proposes the relevant error task on the front-end screen.
Conclusion:
Through this BAdI, the deconsolidation screen can automatically populate the next warehouse tasks sequentially. This explanation mainly focuses on understanding the BAdI-how to identify it, how it works, and how it will be applied in the deconsolidation process rather than the core POSC process.
I would appreciate your suggestions and feedback. Please note that all testing has been performed on the IDES S/4HANA 2023 system .Thank you.
Best Regards,
Kannan Chokkanathan.
Bluesky| User | Count |
|---|---|
| 4 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
