Wondering how sap mm module is working in Implementation projects. SAP MM contains many aspects that should be covered during implementation projects. For sure in every project the business need is being on priority, but on the other side there should be some recommendation from the consultant to the business regarding the standard processes that can help them have an easier business needs fulfilled. Sometimes consultants just go for enhancements to resolve the issue, which is a valid way of thinking, but consultants should ask themselves "Is SAP providing a standard way to cover that part instead of reaching to the enhancement decision?".

Personalized object worklists (POWLs) are a major part of the day-to-day life of any SAP user, whether a consultant implementing SAP ERP for a client or an end user running their core business processes in SAP.

Users often desire to set up their home page in a particular way, preferring to see information that is most relevant to them, which provides actionable insights to perform their job responsibilities in an efficient manner.

In this blog post, let us see, as a functional consultant, how to quickly configure a new TM POWL query w/o disrupting the standard provided ones and assign it to an existing application and category.

Discover how SAP Environment, Health & Safety (EHS) Public Cloud can be seamlessly integrated into your existing SAP landscape. This guidebook provides a step-by-step approach to help organizations successfully set up and integrate SAP EHS Public Cloud side-by-side with existing SAP solutions such as SAP S/4HANA On-Premise, SAP Master Data Governance (MDG), and SAP SuccessFactors. Learn from real-world implementation experience, best practices, and lessons learned to build a scalable, compliant, and future-ready EHS environment.

Business Scenario: High Rack can store different Handling unit types such as A1, A2, A3 and B1. Stock will be Replenished to Fix bins; however, Fix bins can store only HUs with B1 Handling unit type. Before pushing stock to fixed bins HUs with same HU type as B1 should directly move to fix bins and HU type other than B1 need to repack in a WorkCentre.   

Configuration:

1) Define Handling Unit Types

SPRO > Integration with Other SAP Components >Extended Warehouse Management > Additional Material Attributes >Attribute Values for Additional Material Master Fields >Define Handling Unit Type

2) Define HU Type Groups and Assign HU Types

SPRO > SCM EWM > EWM > Cross-Process Settings > Handling Units > Define HU Type Groups

SPRO > SCM EWM > EWM > Cross-Process Settings > Handling Units > Define HU Types for Each Warehouse Number and Assign HU Type Group

3) Define Storage Types

SPRO > SCM EWM > EWM > Master Data> Define Storage Types

a) High Rack Storage

b) Work Center Storage 

c) Fix Bin Storage

4) Define Activity Area

SPRO > SCM EWM > EWM > Master Data> Activity Areas > Define Sort Sequence for Activity Areas

5) Define POSC

SPRO > SCM EWM > EWM > Cross-Process Settings > Warehouse Task > Define Process-Oriented Storage Control

Storage Process – Definition

Assign Storage Process steps

Process-Oriented Storage Control

- IB03 step is maintained here to move products from Workcenter which will be repacked in OB02 step. In OB02 only HU Types maintained under PALL HU type group will be repacked. 

6)  Define Work Center

SPRO > SCM EWM > EWM > Master Data> Work Center > Define Work Center

7) Define Warehouse Order Creation rule

SPRO > SCM EWM > EWM > Cross-Process Settings > Warehouse Order > Define Limit Values for the Size of a Warehouse Order

Field Activity area used to limit the creation of warehouse order where products of different HU types are stored in High Rack

SPRO > SCM EWM > EWM > Cross-Process Settings > Warehouse Order > Define Packing Profile for Warehouse Order Creation

SPRO > SCM EWM > EWM > Cross-Process Settings > Warehouse Order > Define Creation Rules for Warehouse Orders

Define Search Sequence of Creation Rules for Activity Areas

8)Picking Strategies

SPRO > SCM EWM > EWM > Goods Issue Process > Strategies > Specify Storage Type Search Sequence

Determine Storage Type Search Sequence for Stock Removal

9) Activate Replenishment

SPRO > SCM EWM > EWM > Internal Warehouse Processes > Replenishment Control > Activate Replenishment Strategies in Storage Types

Master Data: 

1) Create material Master

a) Materials

b) Packaging materials

2) Packaging specification

3) Additional Attributes for activity area /N/SCWM/SEBA

4) Assign Fixed Bins /N/SCWM/BINMAT

5) Create Bins and Assign Storage Section

6)  Load Storage bin sorting /N/SCWM/SRTUP

Testing:

1) Replenish Stock /N/SCWM/REPL

Enter Mandatory parameters such as warehouse number and PED and execute.

Select line item to Replenish and click on execute

We can observe WT are created for Fix bins.

2) Confirm Warehouse Order

Products stored in AA CART with HU type B1 packaging are grouped in WO02 warehouse order. Whereas Products stored in AA PALL with HU types A1, A2 and A3 packaging are grouped in WO01 warehouse order and this help us to direct products with other HU type to repack into Pick HU of Hu type B1 using packaging specification.  

We can observe Multiple Pick HUs are created with HU type B1.

Click on Confirm in Foreground, Pick HU will be updated as Destination HU while Source Hu is still blank, hence user can scan/pick any available Handling unit to confirm WT/WO. Here 1st step OB01 is completed.

We can observe here once the order is confirmed, Destination bin is updated in WO as workcenter bin.

Confirm other order

For Warehouse order WO02, destination is Fix bin as no repacking needed.

3) Pack Products in Workcenter /N/SCWM/PACK

As control for picking HU is 3 Only adopt content (mat. + lower-level HUs) into pick HU at warehouse process type, qty moved directly into pick HU. We can select Pick HU and print them in workcenter. Once all the activities completed, click on Complete process step for HU.

New WT will be created on refresh to move repacked HUs to fix bins 

Step IB03 to move products to fix bin storage with HU type B1. Products will automatically pick their destination bin from Fix bin assignment (/SCWM/BINMAT).

EWM , TM , ASR 

Automate Digital and Physical Together. How to Orchestrate Production and Warehouse Operations with Mobile Robots, Forklifts, and Moving Assets – Integrated with SAP EWM. 

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.

Working with Handling Units in EWM often involves understanding how the HU data is created, updated and handled by the EWM application. This post is to share my insights about the technical aspects of the HU data access.

Introduction

The previous two episodes have demonstrated how to create and register a custom mass processing function code in COHV as well as have provided an outline of the actual implementation of the mass processing. However, the implementation has not done anything useful, yet.

Now, it is the time to add some meat to the implementation and dive into more advanced topics like test mode, function parametrization and order updates.

Test mode

Let us start with test mode. Typically, SAP standard mass processing functions provide a test mode option that runs all data processing without actually saving any changes or updates. That is particularly useful if you want to test a mass processing run without committing the updates.
Figure 1 Test mode on

Figure 2 Test mode off

The implementation of the mass processing function does not need to explicitly handle test mode operation, i.e. either to rollback or commit changes. That is done by COHV backbone. Make sure to test thoroughly if the test mode is used to make sure that the custom mass processing function is compatible with the test mode handling in COHV. If you are not sure, the rule of thumb is not to use the test mode.

Passing parameters to the mass processing function

Mass processing functions can be supplied with additional parameters. That is often used in SAP standard functions, and it can be enabled for custom ones.

First, additional parameters need to be added to the transparent table and the dialog structure that have been created in the episode 2. Make sure to add the same fields of the same type to the table and to the structure.
Figure 3 The transparent table with a parameter

Figure 4 The dialog structure with a parameter

Once that is done, the parameter will appear in COHV.
Figure 6 The function's parameter in COHV

Mass processing logic implementation

Now, let’s implement the mass processing logic to update production orders. My goal is to change production orders quantity by the value passed with the function parameter. The implementation goes into Z_CO_WORK999_EXEX_SINGLE function. Refer to the previous episode for the details of the function creation.
Figure 7 A snippet of the mass processing logic implementation

Here is the entire implementation of the custom mass processing logic, which consists of the following steps:

1. Get a production order number from LS_COWBPAR-OBJNR
2. Read the order’s header details with the BAPI_PRODORD_GET_DETAIL function
3. Modify the order quantity by the value of the function parameter. It is available in the LS_COWBPAR-QTYCHANGE field
4. Update the order with the BAPI_PRODORD_CHANGE function