Outlining the Basics of SAP EWM

SAP Extended Warehouse Management (SAP EWM) was originally designed to run as a decentralized system and based on an SAP SCM platform. With the integration in the 1610 release of SAP S/4HANA, it is possible to use it as embedded EWM, which means not decentralized. With the release of SAP S/4HANA 1809 FP02, it is possible to use an SAP S/4HANA system as a decentralized EWM instance. This is the planned architecture for all future SAP EWM releases, embedded or decentralized.

Integration

Although SAP EWM is a self-contained application, it does require integration with an SAP ERP system to act as a back-end in order to access master and transaction data. Use of certain functions or features in SAP EWM such as slotting and availability-checking may also require an interface with SAP applications and systems such as SAP Customer Relationship Management (SAP CRM), Global Available to Promise (Global ATP) in SAP Advanced Planing and Optimization (SAP APO), and Service Parts Planning in APO.

The exception is when a warehouse is set up as Transit Warehouse. This only requires an integration with SAP Transportation Management.

Some functions that were introduced with the different SAP EWM releases, such as batch selection, kit-to-stock, and production integration, require a back-end system with a certain release or add-on. Review the SAP EWM release notes to determine the functions that require a specific release or software version.

Communication

Two kinds of data can be transferred between the SAP ERP and the SAP EWM system — master data and transactional data. In an embedded SAP EWM that is part of an SAP S/4HANA system, the transfer of master data is not required. The SAP ERP part and the SAP EWM part in SAP S/4HANA share the basic master data. For a decentralized EWM scenario, the SAP ERP system is the leading system for master data, so the data is generally transferred in one direction, from SAP ERP to SAP EWM. For a decentralized EWM based on SAP NetWeaver, this data is transferred using the Core Interface (CIF), the standard interface between SAP ERP and SAP SCM systems. Technically, this is done by using Queued Remote Function Calls (qRFC). When using an SAP S/4HANA-based decentral EWM, the master data transfer is by using an ALE Distribution Model with IDocs, or the Data Replication Framework (DRF) with services, depending on the ERP system.

For transactional data, a separate distribution model is used. The transactional data distribution model uses qRFC.

Note

Details about the data transfer between SAP ERP and SAP EWM are discussed later in this course.

The various SAP EWM processes are grouped into process areas, as shown in the following figure:

The main process areas in SAP EWM are inbound processing, storage and operations, and outbound processing.

The following are the inbound processes:

• Transportation unit processing:

  When the transportation unit arrives, it is registered at the checkpoint. The transportation unit is unloaded and each pallet is checked again before being further processed.

• Goods receipt, management, and optimization:

  At the core of the inbound processes is the goods receipt process. This process directs the movement of products from the warehouse door to their final destination bins in the warehouse.

• Inbound quality management:

  Materials received into the warehouse may require quality inspections. These inspections are managed using the quality inspection engine (QIE) or quality management (QM). Quality inspection documents are created for the products to be inspected.

• Internal routing:

  Internal routing determines how products or handling units (HUs) are moved within the warehouse based on configuration settings and master data.

Storage and operations comprise the following:

• Physical inventory:

  You can carry out an inventory of products and bins for stock control and balance sheet purposes. A storage-bin-specific physical inventory counts all the products and HUs in a storage bin. A product-specific physical inventory counts a specific product in one or more storage bins and/or HUs.

• Replenishment/Rearrangement:

  You use replenishment control to restock a picking area depending on the demand for products in that picking area. Replenishment strategies are based on slotting or open warehouse requests. You use rearrangement processes to optimize the arrangement of your products in the warehouse by moving stock such as fast-moving items to the relevant storage bin as determined by the slotting process.

• Kit-to-stock management:

  You use the kit-to-stock process to create kits and then transfer them to stock. A kit is a list of products that are always delivered together. Kit-to-stock management provides you with a simple, streamlined kit-creation process that is executed and documented in the warehouse. You can either trigger kit creation manually in the SAP ERP system based on a production order, or in the SAP EWM system directly, using a value-added service order (VAS order).

The following are the outbound processes:

• Outbound planning (route, wave, bin):

  In outbound planning, the system determines the route and bin based on the settings in customizing. You can combine or split items from warehouse requests for outbound deliveries in waves. These waves can be picked or processed at the same or different times. Waves are created manually or automatically in SAP EWM.

• Picking optimization, packing, staging, and load management:

  The goods issue process represents the pick, pack, staging, and loading of products from the warehouse. Picking directs the removal of a product from a source location where the product is stored to an optimized destination location. Packing generally involves removing stock from a storage bin and placing it into a pick handling unit. Depending on your packing requirements, the pick HU may be taken to a packing work center where the products in the pick HU are packed further into other HUs for shipping.

With minor exceptions, all process-related data is communicated between the SAP ERP and SAP EWM systems in delivery documents. A delivery document contains all the data required to document and control a business process.

Exceptions from this process flow are:

• Advanced Production Integration: When using the advanced production integration, a production material request (PMR) is directly created in the EWM system when material staging is requested from the manufacturing order. The PMR technically is like other delivery documents in EWM, but there is no corresponding delivery document in ERP.
• Direct outbound deliveries: When you create a direct outbound delivery the process is started in EWM and the delivery is then copied to ERP.
• Kit-to-Stock: When the kit-to-stock process is started in EWM, an inbound delivery and an outbound delivery order is first created in EWM and then copied to ERP.
• From S/4HANA 2020 on it is possible to work in embedded EWM without inbound deliveries for goods receipts posted with transaction MIGO (in the initial release for manufacturing orders, since FPS01 also for purchase orders).

The inbound process flow for a procurement process and the relationship of the inbound delivery documents are shown in the following figure:

The inbound delivery process is represented in the system by the following documents:

• Inbound delivery notification:

  This document contains the relevant logistics data for the inbound delivery process, beginning with the origin of the inbound delivery (shipping notification, delivery note, or purchase order). The document also contains the data from the advanced shipping notification received from the supplier. In SAP S/4HANA embedded EWM, the inbound delivery notification does not exist. Since SAP EWM 9.5, or with the use of SAP S/4HANA decentralized EWM, the use of the inbound delivery notification is optional.

• Inbound delivery:

  This document contains the data required for triggering and monitoring the complete inbound delivery process. This process starts upon receipt of the goods in the yard and ends when the goods have arrived at the final putaway bin. The inbound delivery is created after activating an inbound delivery notification, and it inherits all the relevant data from the inbound delivery notification.

The outbound process flow, indicating the relationships of the outbound delivery documents, is shown in the following figure:

The outbound delivery process is represented in the system by the following documents:

• Outbound delivery request:

  This document contains the relevant logistics data for the outbound delivery process, starting with the origin of the outbound delivery process, for example, the sales order. The outbound delivery request inherits data from a reference document (an outbound delivery), and creates an outbound delivery order.

  In SAP S/4HANA embedded EWM, the outbound delivery request does not exist. Instead, the outbound delivery order is created directly. Since SAP EWM 9.5, or with the use of SAP S/4HANA-based decentralized EWM, the use of the outbound delivery request is optional.

• Outbound delivery order:

  This document contains the data required for triggering and monitoring the complete outbound delivery process. The process starts with the initial planning activities for the outbound delivery and continues until the goods have been loaded and sent.

• Outbound delivery:

  This document represents the goods to be delivered together to a single goods recipient. This document is created in order to control a delivery split. It is always created, whether a split occurs or not.

The posting changes process flow, indicating the relationships of the posting changes documents, is shown in the following figure:

Posting changes are generated internally in SAP EWM or you can create them in the SAP ERP system. In SAP EWM, the term posting change is used to refer to a change in the material/product, batch, stock type, or stock usage. For example, you could use a posting change to scrap a product that has been damaged in the warehouse. Posting changes initiated in SAP ERP are processed in SAP EWM by using the following documents:​

• Posting change request:

  This document contains all the relevant logistics data that the system copies over from the initiator of the process, that is, the delivery that comes from SAP ERP.

  In SAP S/4HANA embedded EWM, the posting change request does not exist. Since SAP EWM 9.5, or with SAP S/4HANA decentralized EWM, the use of the posting change request is optional.

• Posting change:

  This document contains the data required for triggering and monitoring the complete posting change process. It is from this document that the warehouse tasks are created to carry out the posting change movement.

A warehouse request is an EWM document that enables processing of warehouse activities. These activities are steps like goods receipt or goods issue posting, posting changes, putaway or picking. So, the inbound delivery, the outbound delivery order, or the posting change are examples for warehouse requests.

From the warehouse request documents, SAP EWM creates the warehouse tasks required to complete the warehouse processes. When a warehouse request is created, a warehouse process type is determined for the document. The warehouse process type contains data related to the direction of the movement (putaway, picking), location information (default source or destination), and process-related settings.

SAP EWM uses warehouse tasks and warehouse orders to execute the physical movement of goods in the warehouse.

A warehouse task is an EWM document created to execute logical or physical goods movements or stock changes, such as the following:

• Putaway / Picking / Internal goods movement:

  These types of warehouse tasks are used for physical movements of a quantity of a product from a source bin to a destination bin.

• Posting changes:

  A posting change is used to reassign a quantity of a product to a different plant and stock type, or when its stock category changes. For example, if a quantity of a product is to be scrapped, its stock category changes from unrestricted to scrapped.

• Goods receipt / Goods issue postings:

  Such warehouse tasks are generated in SAP EWM to represent the goods receipt or goods issue inventory posting in the SAP ERP system.

Warehouse tasks can be created manually. They are triggered automatically from a process like wave picking or generated dynamically as a result of a preceding warehouse movement. They are created either with a reference to a warehouse request document, or without a reference - for example, for an internal goods movement. Warehouse tasks are controlled by the warehouse process type.

There are two types of warehouse tasks: product warehouse tasks and handling unit (HU) warehouse tasks.

Warehouse tasks are grouped into warehouse orders to form work packages for warehouse employees (resources) to perform. The warehouse order consists of warehouse tasks or physical inventory items. After warehouse tasks are created, they are assigned to warehouse orders based on warehouse order creation rules (WOCRs). WOCRs are defined in customizing and are determined for activity areas and activities. The source or destination bins in the warehouse tasks are used to determine the activity areas used to obtain the WOCRs that are applied to the task.