EWM BAdI Implementation Scenario-Bin Validation During Putaway (Manual Change)

[kannanchokkanathan1]

Introduction:

In this blog, I’ll explain a real-time business requirement related to bin validation during the putaway process, and how we can handle it using the BAdI /SCWM/IF_EX_CORE_PTS_VERIF~VERIFY.

Business Scenario:

In day-to-day warehouse operations, it is quite common for system-proposed storage bins (determined by the defined putaway strategy) to become temporarily unusable. This can happen for several operational reasons for instance:

• The bin might be physically damaged or under maintenance.
• It could be blocked physically for quality or safety reasons.
• The bin location may be temporarily occupied or inaccessible due to congestion or space constraints.

When such situations occur, warehouse operators working on RF devices or through the desktop transaction must override the system suggestion and select an alternate destination bin manually. To handle these exceptions correctly, operators use a predefined exception code (for example, CHBD - Change Destination Bin) that allows them to modify the target bin during task confirmation.

However, under standard SAP EWM behavior, the system performs only a basic check when the user enters a new bin. It does not validate whether the manually entered bin belongs to the same storage type as the system-proposed one. This means that:

• The operator can enter or scan any valid bin, even if it is part of a different storage type.
• No error or warning message is triggered by default.

While this flexibility can be useful in certain dynamic warehouse setups, it also poses a significant business risk, especially in compact or high-density warehouses where bins from different storage types are physically close to each other. A small scanning or entry error could lead to incorrect stock placement, causing:

• Inventory discrepancies between system and physical stock location.
• Errors in subsequent picking or replenishment processes.
• Reduced traceability of materials and increased audit effort.

Example Scenario:

The system proposes Storage Type: "Z00A", Bin: "ZONE-A-BIN-003" for putaway.

The operator, due to bin blockage, changes the destination to Storage Type: "Z00B", Bin: "ZONE-B-BIN-001.

In standard configuration, this change is accepted without any validation, even though Z00B might represent a completely different physical or logical area (for example, a cold storage zone or a bulk storage area).

Business Requirement:

To prevent such issues, the business requirement is to introduce a validation rule that ensures, 

• Operators cannot put away stock into a bin from a different storage type than the one proposed by the system.
• Validation should trigger only when the bin is manually changed (using exception CHBD or similar).
• It should work both in RF screens and GUI transactions.

This is a simple but powerful requirement that helps prevent data inconsistency and operational errors.

BAdI Used:

SAP provides a BAdI specifically for this purpose:

BAdI: /SCWM/IF_EX_CORE_PTS_VERIF
Method: VERIFY

You can find this under:

SPRO → SCM Extended Warehouse Management
→ Business Add-Ins for EWM
→ Goods Receipt Process
→ Putaway Strategies
→ BAdI: Check Destination Storage Bin

Please refer the my earlier blog to identify the BAdI in the program in more details, BAdI Implementation for Automatic Warehouse Task Selection in the Deconsolidation Work Center in EWM 

According to the SAP documentation, this BAdI is triggered only when the destination bin is manually entered.
That makes it ideal for our scenario.

Open the BAdI /SCWM/IF_EX_CORE_PTS_VERIF and go to the method VERIFY.
In this method, you can write the logic for validation. First, set a breakpoint inside the method to ensure the BAdI is being called during manual bin changes.

Refer to the screenshot below. The process starts with the inbound delivery, during which the warehouse task is created for that inbound delivery. In the RF transaction, the warehouse operator then tries to change the destination bin manually. Since we have hardcoded the breakpoint in the BAdI logic, the debugger is triggered at that point ,confirming that we have reached the correct place in the code.

When the operator manually changes the bin using an exception code (for example, CHBD) and clicks Enter, the debugger will stop at your breakpoint. This confirms that this is the right place and Badi to write the validation logic.

Within the BAdI, you will find local variables such as:

IS_LTAP

IS_T331

IS_T333

These structures/internal tables contain detailed information about the warehouse task, such as warehouse number, source bin, and destination bin. You can use these variables to write conditional logic.

For example, you can use the warehouse number (LGNUM) or other fields from IS_LTAP to apply validation filters. You can also perform a SELECT query on the open warehouse task table /SCWM/ORDIM_O to cross-check the original task data storage type and bin.

If the new bin belongs to a different storage type than the one proposed (based on the comparison logic), you can trigger an error message, prompting the operator to choose a bin within the same storage type.

You can also see the BAdI error message storage details in the screenshot below specifically, the ET_BAPIRET  internal table, which captures the error messages, and the EV_SEVERITY parameter, which stores the message type, such as error, warning, or information. Essentially, ET_BAPIRET serves as the output of this BAdI, and based on its content, the subsequent logic will execute accordingly.

Refer to the sample code  screenshot below. One key point to note is the use of filters -as shown, I’ve applied multiple filters. Based on the specific business requirement, you can restrict the BAdI call to certain scenarios as needed.

Okay, so now I’ve implemented the BAdI logic. When I execute the transaction again, the expected result is that the system should not allow me to proceed further - instead, it should display the corresponding error message.

Testing the Scenario:

• Create a Warehouse Task for Putaway.
• In RF, start the Putaway process.
• Use the exception code CHBD to manually change the bin.
• Enter a bin from a different storage type.
• Observe the system validation message:- “New storage bin should be within the same storage type.”

Conclusion:

Hence the implemented logic ensures:

• Operators can change bins only within the same storage type.
  System restricts bin change across different storage types.
  Works seamlessly in both RFUI and GUI transactions.

Thank you for reading. Please share your feedback or thoughts in the comments section below-it always helps improve future content.

Disclaimer: The screenshot shown in this blog, has been captured from the S/4HANA 2023 Embedded EWM system. It is provided solely for demonstration and explanatory purposes to illustrate the configuration and logic behavior described in this document. Please note that this setup and the associated data are purely test-based and do not represent any real-time or live industry data. 

Best Regards,

Kannan Chokkanathan.