sap wm ewm leogistics [shutterstock: 466563128, Sergey Nivens]
[shutterstock: 466563128, Sergey Nivens]
Blog Logistics

SAP WM Vs. SAP EWM: All Pros And Cons At A Glance

Warehouse management (WM), stock room management, embedded EWM or decentralized EWM - there is a colorful bouquet of possibilities in both solutions. Here’s how to decide between them.

In the first part of our blog series, we took a closer look at the new terminology in SAP EWM as well as the organizational units. We also took a detailed look at the new S/4-based system. In this second part, we would like to provide you with further decision-making assistance on how to make a smooth changeover and go into more detail on additional functions.

EWM versus WM: Process flows

In addition to the differences regarding master data, there is another significant one: Process flow, or the communication between warehouse management and adjacent modules.

“Embedded EWM” is not necessarily the same as “embedded”, as many customers assume. The difference: Certain interface settings must be made. More precisely, certain documents must be exchanged to ensure a smooth process. In the following diagrams, I would like to contrast the SAP WM and EWM process flows.

ad_banner
Goods receipt for purchase order: Differences between WM and EWM.
Goods receipt for purchase order: Differences between WM and EWM.

EWM versus WM: Goods receipt

Currently, the customer is used to posting the goods receipt via MIGO, then receiving a transfer requirement and completing the put-away via the resulting transfer order. In contrast to SAP WM, SAP EWM requires inbound deliveries (VL31N) from SAP ERP so that the customer can complete the put-away.

The inbound delivery is replicated in SAP EWM. This represents the transfer requirement in SAP EWM to later start the put-away via warehouse tasks. Here is the crucial difference: The goods receipt takes place in SAP EWM for the inbound delivery (transaction/SCWM/PRDI) and is reported back to SAP ERP. Only after the goods receipt is the put-away started, the goods stored in the bin, and the process completed with a confirmation.

Alternatively, the goods receipt can be posted with the confirmation of the put-away. The first approach is more common, however, since the two storage location strategies provided by SAP EWM would otherwise be redundant. Only with the “GR posting” is an intermediate storage location posted (Received on Dock), so that everyone in the system can see that these goods have already been received.

However, it is not available for further processes until it is in the final storage bin. Then the system will automatically post a transfer to a second storage location (Available for Sales) when the warehouse receipt is confirmed. This has the benefit that the goods can only be accessed when they are actually available in the bin.

EWM versus WM: Transparency

In contrast to SAP WM, SAP EWM can start earlier in the process and create more transparency. As early as the unloading of the truck, warehouse tasks can be mapped for the movements from the truck to the goods receipt area.

In addition, the system recognizes mixed pallets, which are automatically routed to a deconsolidation station. The employee repacks these into pallets that are homogeneous in terms of material/batch, which ensures optimum use of storage space.

Goods receipt to order: Possible processes that can be mapped in EWM.
Goods receipt to order: Possible processes that can be mapped in EWM.

Keep impact on personnel low

For many customers, the process with deliveries is unfamiliar territory at first, as questions immediately arise, such as:

  • Who places the delivery?
  • When do I create the inbound delivery?
  • How does purchasing set up its order confirmation process?
  • Which fields can I still change in the ERP for the inbound delivery?

For the employees, the process is new at first, but this is not a reason to do without SAP EWM entirely. On the contrary, the changeover could be a reason to persuade the supplier to process the inbound deliveries automatically via a DESADV in order to become more efficient in the supply chain as well. After all, there is also the chance to exchange pallet data in advance, so that the incoming goods department is less burdened. Alternatively, there are always ways and means to streamline the process and keep the impact on personnel as low as possible.

Gradual releases bring more integration

With the introduction of SAP’s S/4 Hana system, EWM and all its features were embedded in S/4 at the beginning without truly being more integrated. Therefore, SAP is continuously working on creating more integration.

Since the 2020 release, it is now possible to post a goods receipt for a purchase order without inbound deliveries (synchronous update). However, this function cannot be used with QM integration, which will only be available in a later release.

EWM: Synchronous posting in the goods receipt process.
EWM: Synchronous posting in the goods receipt process.

EWM versus WM: Goods receipt to production order

The SAP WM process works in the same way as for the “goods receipt for purchase order”. In SAP EWM, the goods receipt for the production order works very similarly. There is only one difference: The starting point is not the inbound delivery, but the MIGO, which at the end creates the inbound delivery in SAP ERP in the background and replicates it again for SAP EWM. The rest of the process is exactly the same as for the purchase order. This means that even if you post the MIGO, no material document is created at first. This comes, as usual, from the inbound delivery in SAP EWM (or SCWM/PRDI). The MIGO initially triggers only the inbound delivery.

This procedure seems very unusual for customers, as they are used to a material document being created after a MIGO posting. Here, too, the material document is triggered from SAP EWM at the end, so that the process in SAP EWM can also be handled in the same way as the other processes. The synchronous booking can be used just like the GR for the purchase order.

Goods issue for customer delivery

Goods issue for customer delivery: Differences between WM and EWM.
Goods issue for customer delivery: Differences between WM and EWM.

Before the goods issue is posted for customer outbound delivery, the transfer orders must be created and processed in SAP WM. After that, the goods issue posting for outbound delivery is possible.

In an EWM warehouse, an outbound delivery must first be created on the ERP side with the VL01N so that it can be replicated to EWM. Then, as usual, the warehouse tasks are created and confirmed via the transaction/SCWM/PRDO. The goods issue can then be posted in EWM for outbound delivery and transferred to the ERP system.

Subsequently, it would still be possible in EWM to map the loading onto the truck with the help of warehouse tasks in order to create transparency in the process and, if necessary, to post the goods issue only with the loading onto the truck.

Goods issue for customer delivery: Possible processes that can be mapped in EWM.
Goods issue for customer delivery: Possible processes that can be mapped in EWM.

This process should be more familiar to most customers, as the sequence in WM is the same. However, the advantage of EWM clearly is the transparency of the downstream process of loading.

EWM versus WM: Functions

Basic EWM offers more functionality than SAP WM. However, there are two features that are already available without an additional EWM license. These are the layout-oriented storage control (LOSC) and the process-oriented storage control (POSC).

Storage control can only be used if handling units are formed in the warehouse. It is also possible to use LOSC and POSC simultaneously, whereby all steps from POSC are always processed first. Afterwards, LOSC checks whether the process step is possible from the LOSC point of view.

LOSC

Layout-oriented storage control enables the route of a pallet to be defined within the process. Usually, many customers are familiar with this topic from the introduction of automated warehouses. In this context, it is important that the pallet runs over identification points before a final storage and is “guided” there.

Likewise, pallets may need to be repacked before they reach their final destination. Therefore, picking points can be defined over which the pallet must run if repacking is relevant beforehand.

An example of layout-oriented process control in EWM.
An example of layout-oriented process control in EWM.

POSC

The warehouse management system offers the possibility to control the different goods receipt process steps, such as unloading, deconsolidation (e.g., repacking mixed pallets to materially homogeneous pallets), QM processing or put-away in a sensible sequence. At HU level, the steps are completed and automatically transferred to the next one. The process chain is completed with the put-away to a final bin.

An example of process-oriented process control in EWM.
An example of process-oriented process control in EWM.

EWM vs. WM: Warehouse monitor

It is often difficult for warehouse managers to have an overview of all processes and to be able to react correctly in a short time. In WM, stocks are checked using LX03, but transfer orders are created using LT10. Old documents are checked with LT24. In addition, there are many transactions to start certain actions. However, one does not have the possibility to act from a LX03.

With the EWM warehouse monitor (or SCWM/MON), one now has everything in sight and the possibility to act from the monitor. Everything that takes place in EWM can be accessed from here. It is possible to create storage tasks for stocks and to confirm them from the monitor. It is also possible to start a mass confirmation of warehouse tasks.

The monitor always helps to keep the overview and to be able to react accordingly. If the layout of the monitor does not suit you, it can be customized. With the help of a multi-split screen, it is possible for users to see a lot of information at a single glance.

EWM vs. WM: Greater user-friendliness

With the introduction of S/4 Hana, SAP is also taking a new approach to the user interface. The goal is to make it easier for users to work with SAP. For this purpose, Fiori was established, which can be accessed in the web browser with the help of the Fiori Launchpad. This makes it possible to launch the applications on all modern end devices such as smartphones or tablets. They then automatically adapt to the screen. The apps are intended to liberate users from SAP GUI, since every transaction in SAP GUI is also available in the Fiori Launchpad. Consequently, users can focus on browser-based work. Customers who still have an ECC 6.0 can also benefit from Fiori.

It is important to distinguish whether you are using real Fiori or a “Fiori-ized” app. A real one was newly developed by SAP with special regard to added value and user-friendliness. A “Fiori-ized” app represents an SAP GUI transaction rendered for the Fiori launchpad. The functions and layout mirror the SAP GUI transaction. However, users would not see any difference here. This step was necessary because it was not possible to provide new apps from the start for all the business processes required in SAP.

To keep track of which apps are currently available, you should work with the SAP Fiori Apps Reference Library. There you will find all the information you need to use an app. With each new release, more and more “real” Fiori is offered.

Now, we have learned that we can use stock room management on an S/4 system to replace the WM module from ERP/ECC 6.0. However, there is some bad news here: There are no Fiori apps for stock room management provided in the standard.

Since EWM is the strategic product for SAP, only real and “Fiori-ized” apps are offered here. If customers are planning a Fiori strategy, they must think carefully about whether stock room management is necessary. If customers still decide in favor of Fiori and stock room management, then the only option left is to develop their own Fiori apps.

EWM has a clear advantage here. There are already very good real Fiori functions that create real value for users, and the range is constantly growing. Nevertheless, from my point of view, the standard Fiori does not replace the well-known RF applications for mobile data collection. Fiori apps are more suitable for desktops that also have a fixed workstation, such as for the “packing in goods issue” process. Nevertheless, my recommendation is to clarify beforehand which processes the customer has and then to decide whether an already available Fiori fits and can possibly be used for mobile after all.

EWM versus WM: Other important features

  • Batch management. For many industries, it is necessary to manage batches. This is partly to ensure traceability and partly to distinguish product characteristics. In WM, it was already possible to manage batches at the bin level. However, what was not possible in the standard system was to find batches based on batch characteristics in a classification. EWM now offers the possibility to pick batches based on the batch search strategy, e.g. from an SD order, according to the corresponding characteristic values.
  • Serial numbers. Serial numbers are used to clearly identify parts in the warehouse in order to ensure traceability later on. Unfortunately, traceability at the bin level in WM is not possible. This was only possible if serial numbers were assigned based on HUs, and traceability was performed at HU level. In a LX03, the serial numbers were not displayed. With EWM, this now changes fundamentally. Here, tracing at the location level is possible at any time, even without an HU. Meanwhile, it is even possible to use only one serial number profile for EWM and ERP. In the past, two profiles always had to be maintained.
  • HU management. Sometimes it is necessary to manage inventories at pallet number level. For this purpose, there is the handling unit management (HUM). To be able to use it, it is necessary to activate HUM on storage location level. This means that all stocks at the storage location must be packed into a handling unit. The handling units can then only be moved with special transactions. If a WM warehouse is activated for the same storage location, then the handling unit can also be managed in WM. The handling unit number is then taken over as the storage unit from WM. Handling unit management has now been simplified with EWM. It is no longer necessary to activate HUM at the storage location level. The HU duty is taken at storage type level. It is even possible to store packed or unpacked materials in one bin. SSCC assignment is also controlled by EWM. Packing on multiple packing levels is also possible and is also represented in EWM (nested HUs). How the handling units are packed is mapped via the EWM pack specifications. The right packing instructions are drawn to the right process via the condition method. The HU data is also exchanged automatically in the GR or GI process, so that handling units can be seen in VL03N, for example.

Our recommendation

It is understandable that customers are struggling to find a strategy that fits their warehouse management needs, but we can help you! We will take a determined look at your needs, which includes a fair assessment of whether stock room management might make sense after all, even if it is not SAP’s strategic product.

Furthermore, we recommend not to reject EWM prematurely just because it seems more complex and unfamiliar. The important thing is to put the right resources in the right place. Especially basic EWM offers great added value for our customers – without any additional costs!­­­­

About the author

Daniel Rotter, Leogistics

Daniel Rotter is Senior Consultant SAP Logistics at Leogistics.

1 Comment

Click here to post a comment

  • ” Fiori apps are more suitable for desktops that also have a fixed workstation, such as for the “packing in goods issue” process. Nevertheless, my recommendation is to clarify beforehand which processes the customer has and then to decide whether an already available Fiori fits and can possibly be used for mobile after all.”

    Agree with the beforehand clarification completely – normally when we’re extending EWM beyond the workstation – to iPads & mobile devices in particular – Design Thinking will usually indicate if a Fiori OOTB can be adapted for the client’s situation. Our clients find that Fiori is very valuable beyond the fixed workstation for EWM/TM users with this approach – thanks for the article!

ad_banner
Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy. terms and conditions .


Our Authors