PLC Direct Connection With SAP Extended Warehouse Management (EWM) 5.1

PLC Direct Connection with
SAP Extended Warehouse Management (EWM) 5.1
Introduction
PLC Direct Connection with SAP EWM 5.1

V1.1 8/2008
Table of Contents
1 Introduction 6
1.1 Example Warehouse 8
1.2 Requirements for a Material Flow System 11
2 SAP EWM Material Flow System (MFS): Function Overview 13
2.1 EWM PLC Communication 13
2.2 SAP EWM Material Flow Functions 14
2.3 EWM Control Station Functions 21
2.3.1 Warehouse Cockpit 21
2.3.2 Warehouse Management Monitor 22
2.3.3 Alert Monitor 25
2.3.4 Application Logs 25
2.3.5 Solving Problems 26
3 MFS Basics 27
3.1 Communication Protocol 27
3.2 EWM – PLC Communication (Message Types) 29
3.3 Storage Control 31
3.4 Handling Capacity Bottlenecks 32
3.5 Strategies 33
4 PLC Communication 36
4.1 Setting Up the Communication Interface 36
4.1.1 Telegram Structure 36
4.1.1.1 Structure /SCWM/S_MFS_TELETOTAL 36
4.1.1.2 Defining a Telegram Structure (DDICT) 38
4.1.2 Defining the Interface Type 39
4.1.3 Defining Telegram Types 39
4.1.4 Defining the PLC 41
4.1.5 Defining the Communication Channel 43
4.1.6 Defining Communication Errors from EWM to PLC 46
4.1.7 Communication Errors from PLC to EWM and the Reaction to Them 47
4.2 Setting the Connection 47
4.2.1 Setting up the RFC Destination (sm59) 47
4.2.2 Setting the RFC Destination for the PLC 49
4.2.3 Setting the Communication Channel 49
4.3 RFC Adapter SAP Plant Connectivity MDS 2.0 49
4.3.1 Configuring the RFC Adapter 49
4.3.2 Connection Check from the RFC Adapter 57
4.3.3 Starting the RFC Adapter 58
4.3.4 Connection Check from SAP (Transaction “sm59”) 59
4.4 Testing PLC Communication 60
4.4.1 Test Using RFC Module 60
4.4.2 Test with an External PLC Simulation Program 61
4.4.3 Starting a Communication Channel 61
4.4.4 Monitoring the Interface (EGF) 62

V1.1 8/2008
Introduction
4.4.5 Telegram Log 63

5 Connecting the Prestorage Area 64
5.1 Setting up a Warehouse 64
5.1.1 Storage Type 64
5.1.2 Storage Bins 66
5.1.3 Recommendation for Assigning Names to Storage Bins 67
5.1.4 Defining Communication Points 68
5.1.4.1 Communication Point Types 68
5.1.4.2 Communication Points 68
5.1.4.3 Capacity Mode for Communication Point 72
5.1.4.4 Communication Points in the Example Warehouse 73
5.1.4.5 Assigning Storage Bins to Communication Points 73
5.2 Layout-Oriented Storage Control 74
5.2.1 Creating Storage Groups 75
5.2.2 Specifying Storage Bins Using Storage Groups 76
5.2.3 Determining Intermediate Destinations (Storage Control) 77
5.2.4 Access Strategy Storage Control Table 77
5.2.5 Storage Control in Example Warehouse 78
5.2.6 Alternative Paths 79
5.2.7 Controlling a Clarification Bin 80
5.2.8 Controlling an External Clarification Bin 80
5.3 Warehouse Orders for Controls 81
5.3.1 Queue Determination 83
5.3.2 Create Queue for PLC 84
5.3.3 Warehouse Order Creation Rule 85
5.3.4 MFS Activity 86
5.3.5 MFS Warehouse Process Types 87
5.3.6 Activity Areas 88
5.3.7 Assignment of Storage Bins to Activity Areas 90
5.3.8 Sorting Storage Bins 90
5.3.8.1 Determining Sort Sequence 91
5.3.8.2 Sorting Storage Bins 91
5.3.9 Queue Determination 92
5.3.9.1 Queue Determination Criteria 93
5.3.9.2 Queue Access Sequence 93
5.4 Communication from Transfer Orders using PLC 94
5.4.1 PLC Communication Point Descriptions 94
5.4.1.1 Activating Mapping for Storage Bin Descriptions 94
5.4.1.2 Maintaining Mapping Table 94
5.4.2 PLC Warehouse Task 96
5.4.3 PLC Warehouse Task Confirmation 96
5.4.3.1 MFS Actions 97
5.4.3.2 Find MFS Actions 98
5.4.4 PLC Warehouse Task Confirmation with Error 98
5.4.4.1 Defining Exceptions 98
5.4.4.2 Linking Exceptions to PLC Error Codes 99
PLC Direct Connection with SAP EWM 5.1 Page 3/153

V1.1 8/2008
Introduction
5.4.5 Canceling a PLC Warehouse Task 100

5.5 Capacity and Status Management for Conveyor Lines 101
5.5.1 Setting Capacity Limits 101
5.5.1.1 Capacity Limits to Communication Points 101
5.5.1.2 Capacity Limits to Conveyor Segments 102
5.5.2 System Behavior for Capacity Bottlenecks 102
5.5.3 Malfunction 104
5.5.3.1 User Lock 104
5.5.3.2 Status Telegram 106
5.5.3.3 Conveyor Segment Groups 107
5.5.4 Blockage Clearing 107
5.5.5 Empty Location Messages 109
5.6 Scanner for Material Flow Tracking 110
5.6.1 Scanner Telegram 110
5.6.2 Scanner Telegram Processing 110
5.6.3 Exceptions – Example NOREAD 111
5.7 Automatic ID Point 112
5.7.1 Storage Control with ID Point 112
5.7.2 ID Point Telegram 112
5.7.3 ID Point Telegram Processing 113
5.7.4 Consideration of System Status and Capacity Utilization for Putaway Strategy 113
5.7.5 Equal Distribution in Aisles 115
5.7.6 Error on ID Point 115
5.7.7 Additional Options 115
5.8 Transfer Cars 115
5.8.1 Queue for TCAR 116
5.8.2 Queue Determination Criteria 116
5.8.3 Resource Type 118
5.8.4 Resource 118
5.8.5 Telegram Communication with Resources 119
6 Connecting an Automated High Rack Storage Area 120
6.1 Set Up Storage Bins in High Rack Storage Area 120
6.1.1 Storage Type 120
6.1.2 Storage Bin Types 121
6.1.3 Bin Access Types 121
6.1.4 Designator for Storage Bin Structures 121
6.1.5 Create Storage Bin Generation Procedure 121
6.1.6 Warehouse Bin Status Profile 122
6.1.7 Creating Storage Bins in High Rack Storage Area 124
6.1.8 Sorting Storage Bins 124
6.2 Layout-Oriented Storage Control 125
6.3 Validity of Last Stage (Putaways and Stock Transfers) 126
6.4 Stacker Cranes 127
6.4.1 Creating Queues and Queue Determination Criteria 127
6.4.2 Creating a Resource Type 128
6.4.3 Creating Resources 129

V1.1 8/2008
Introduction
6.4.4 Maintaining Mode for LSD Rounding 129

6.4.5 Error Bin Occupied 130
6.4.6 Error “Bin Empty” 133
6.5 Stock Removal 134
6.6 Stock Removal Strategies 136
6.7 Picking Goods-to-Man 136
7 Appendix 139
7.1 User Rights for PLC User 139
7.2 MFS Exceptions 141
7.3 Internal Process Codes 145
7.4 SAP EWM – RFC Adapter Interface 146
7.4.1 Function Module for Setting Up a Connection to a PLC 146
7.4.2 Function Module for Sending Telegrams to a PLC 147
7.4.3 Function Module for Receiving Telegrams from a PLC 148
7.4.4 Function Module for Terminating a Connection to a PLC 149
7.4.5 Function Module for Checking the Availability of the Communication Layer 149
List of Abbreviations 151
General Disclaimer 152

V1.1 8/2008
Introduction
1 Introduction
SAP EWM 5.1. allows direct control of automatic storage retrieval in the warehouse. This dispenses with any
additional warehouse control systems between SAP and programmable logic controllers (PLC). SAP EWM
communicates directly with the control level.
Besides dispensing with an additional software system, this offers the benefit of a close connection between
the material flow and warehouse management. Thus, warehouse management system (WMS) strategies can
be adjusted to the condition and utilization of automatic storage retrieval more easily. Additionally, the WMS
provides the material flow system (MFS) with functions and data, for destination inquiries, for example. In this
way, system mapping represents physical movements in the warehouse more closely.
This is an example of such a warehouse:

Business Scenario
Aisle 1 Aisle 2 Aisle 3
Crane2
Crane3
Highbay Storage Bins
RF1 Crane1
Conveyor System
TCAR Transfer Car
ID Point Put away Removal-HU

Put away Pick-HU
Pick Point
Full pallets
Pick-HU
Goods Receipt Clearing Goods Issue Empty Pallets
SAP AG 2007
The figure above shows a 3-aisle high rack storage area. A transfer car connects the prestorage area with the
infeed and outfeed conveyors of the three aisles. The prestorage area contains an automatic identification
point (ID point) and a pick point.
Logical System Levels
In automatic warehouses, various types of technology are used, for example:

Conveyor lines for containers, boxes, pallets, wire baskets (belts, chain conveyors, roller conveyors)
Stacker cranes (SC) for accessing storage bins without a driver
Transfer cars (TCAR) for moving storage units (handling units – HU) horizontally to different leg stages or
buffer spaces
Scanners, sensors for contour control, scales, and so on

V1.1 8/2008
Introduction
These devices are usually controlled by means of real-time systems1, which monitor and switch the sensors
and actuators involved (light barriers, switches, motors and so on). These real-time systems obtain their
orders from the superordinate warehouse control level which derives them from the warehouse requests.
Logical Layers in Automated Warehouses
Inbound & Outbound

Inventory Deliveries
Stock per HU & Bin

Warehouse Management Warehouse Tasks
Warehouse Equipment
Material Flow Control Detailed Warehouse Tasks
Real Time Controllers (PLC) Control of Equipment
Sensors & Drives
SAP AG 2007
Crucial differences between automated warehouses and warehouses operated manually or by radio
frequency are:
The resources are passive (as in the case of stacker cranes)
Capacity bottlenecks must be watched and controlled much more closely
Technical malfunctions must be taken into consideration
Logistical malfunctions must not block the material flow (for example: bin occupied, unknown HU on
automatic storage retrieval system)
Architecture Variants
The following architecture variants are normally available for connecting automated warehouses to an SAP
system:
1
PCs can also take on such functions in places. They may be connected to EWM in the same way as programmable logic controllers
and as such, "PLC" always also refers to equivalently deployed PC controllers in the following.

V1.1 8/2008
Introduction
Architecture Variants
Automated Warehouse with SAP

EWM 5.1
Inventory SAP ERP SAP ERP SAP ERP SAP ERP
3rd Pty. SAP LES SAP LES SAP EWM

Warehouse Mgmt. WM
SAP TRM
3rd Pty. 3rd Pty. 3rd Pty SAP MFS
Material Flow MFS MFS MFS
RFC-Adapter RFC-Adapter
Control of PLC PLC PLC PLC

Sensors & Drives
SAP AG 2007, SAP EWM 5.1 Material Flow System / 3
1.1 Example Warehouse
The scenario presented here should explain how an automated warehouse is connected to SAP EWM.
The system consists of an automatic high rack storage area with three aisles and automated putaway and
removal. Each aisle is equipped with a stacker crane (SC). A transfer car (TCAR) links the putaway and
picking area with the high rack storage area.
The storage bins are of single depth, TCARs and SCs each have one load handling attachment (LHA).
A scanner is installed at the ID point. At the same time, the handling unit (HU) is weighed there and its type
determined using base recognition and contour control. At this point, the PLC reports pallets to the EWM
system. The EWM system is to assign a storage bin and use that to derive a corresponding conveyor
command for the PLC. Faulty pallets are to be diverted to the clarification bin automatically.
When a pallet arrives at the transfer point before the SC, its label is scanned once more. This is meant to
prevent putaway errors caused by order misalignment.
For picking, the HUs from which you want to remove material must be moved to the pick point and
subsequently returned to stock. Whole (remaining) quantities are removed by means of a separate conveyor
next to the pick point. Pick-HUs are also transferred there by means of the TCAR.
Controllers Involved in the Example Warehouse
The warehouse is operated with four controllers (from the point of view of the EWM system). Three are used
for the SCs (in the upper section of the picture), while the fourth is used for the conveyor lines and the
transfer car (below).

V1.1 8/2008
Introduction
Programmable Logic Controller (PLC)
RBG3
PLC RACK2
RBG2
PLC RACK3
RBG1
PLC RACK1
EWM
TCAR
PLC CONSYS1 IP
PP
Clearing GI
GR
SAP AG 2007, EWM/MFS Implementation Example / 4
Material Flow in the Example Warehouse
In general, the capacity of the individual leg stages or points should be taken into account by SAP EWM, so
that the controllers are only provided with orders they can execute. This is especially important for TCARs
and SCs, as these will be blocked for other tasks if they cannot get rid of their load at their destination.
Thus, the material flow must meet the following requirements:

V1.1 8/2008
Introduction
Material Flow
1. Put away
2. Removal Full Pallets RGB2
3. Replenish Pick Point
4. Put away from PP
5. Remove Pick-HU
6. Clearing RGB3
4
6
2
3
RGB1
TCAR
IP
PP
5
1 6
Goods Receipt Clearing Goods Issue
SAP AG 2006, SCWM/MFS-Beispiellager / 3
Putaway Process
In the goods receipt area, the delivered quantities are packed in HUs and equipped with bar code labels. The
bar code contains the HU number. One of the employees places the packed HUs onto the putaway conveyor.
The PLC moves it to the ID point anonymously. The ID point comprises a number of devices connected to the
PLC, such as
A scanner
A scale
A contour control
The PLC sends a logon telegram to the EWM system, containing the
HU identification
HU type
Weight
Error code
Possible errors (reported by PLC):

Incorrect contours
Excessive weight
Noread
Faulty HUs are to be diverted to the clarification conveyor by the EWM system.
The MFS assigns a storage bin in accordance with the putaway strategy and directs the HU to the
appropriate aisle. During this, the capacity of the infeed conveyor in front of the aisle should be taken into
account, to prevent the TCAR from being blocked.

V1.1 8/2008
Introduction
On the infeed conveyor, the HUs are once more directed past a scanner. The PLC sends another logon
telegram. If there are any errors (offset), the HU must be transferred to the outfeed conveyor by means of the
SC and diverted to the clarification bin.
The SC is equipped with a sensor system that can recognize whether a bin is occupied. If this is the case, the
SC will confirm the transport order by issuing the error Bin occupied. The MFS is then required to assign an
alternative bin or divert the HU to the clarification bin.
Stock Removal Process
Complete stock picks should be removed to the goods issue (GI) conveyor directly.
Partial stock picks must be transported to the pick point. Here, a picking dialog takes place. When the goods
arrive at the pick point, the orders available for it should be displayed to the picker. The picker places the
quantities required on empty pallets and generates pick HUs. These are transported to the GI conveyor by
means of the transfer car. For withdrawal HUs that need to be returned to stock, a new storage bin search is
carried out at the point where they are transferred to the TCAR.
1.2 Requirements for a Material Flow System
With a view to the processes in the example warehouse, we can set out the following general requirements
for a material flow control system.
Communication Requirements
The MFS must be able to communicate with a number of controllers in an efficient and reliable way. Problems
caused by link failures must be identified and solved automatically. The system must ensure that each
message is processed exactly once. Errors or delays in the processing of a message must not block the
sender. The communication interface should be suitable for different technical protocols (such as TCP/IP,
RFC1006, RK512, 3964R) and different message types.
Material Flow Control Requirements
The material flow system must be acquainted with the individual transport stages and take account of existing
capacity restrictions. It must be able to receive and react to malfunction reports from the PLC. It must be able
to assign pending orders to available resources according to their priority and to react spontaneously to
feedback from the controllers.
Errors occurring in the material flow, such as Noread at the scanner, must be treated in such a way as to
avoid any obstructions to the material flow in the warehouse.
Control Station Requirements
The system must provide an overview of the current status of the orders and existing malfunctions. It must be
clear where the individual HUs are logically located in the warehouse and which system is currently
responsible for their further transport.
For error situations, there must be logs enabling the user to trace the path taken by individual HUs.
Telegrams must be logged for troubleshooting and analysis purposes.

V1.1 8/2008
Introduction
For differences between the logical status of the data and the physical status, the system must provide
functions enabling the user to synchronize both, such as posting changes for a HU, canceling an order,
creating an order manually and so on.
It must be possible to block individual leg stages and to interrupt communication with individual controllers
temporarily.
Events that call for manual interference must be made available to the control station and there must be a
way of directing this information to individual persons or functions.

V1.1 8/2008
Introduction
2 SAP EWM Material Flow System (MFS): Function Overview
The following section provides an overview of the functions available in SAP EWM MFS.
2.1 EWM PLC Communication
The following functions have been implemented in SAP EWM for communicating with controllers:
Telegram communication via TCP/IP using an RFC adapter.
Securing communication by means of sequence numbers, telegram confirmation in SAP EWM
Automatic connection monitoring (automatic restart of the communication channel if necessary)
Options for starting and stopping connections
Telegram log
Configurable telegram formats and identifiers
Configurable action modules for reacting to incoming telegram types
Status overview for communication interfaces
Sequential communication for each communication channel
Parallel communication across communication channels with one or more controllers.
Unlike in the predecessor products (TRM, SAP EWM 5.0), both communication partners (both SAP EWM and
PLC) can now initiate a communication process.
Pull principle: PLC queries SAP EWM, SAP EWM replies.
Push principle: SAP EWM triggers an action, PLC carries it out and replies.
Bidirectional Telegram Communication
•Message oriented
•Asynchronous Send / Receive
•Life Check
SAP EWM
RFC
„push“
Task Confirmation
Channel 1
Response
Task
Event
RFC-Adapter
„pull“ Channel 2
TCP/IP TCP/IP
PLC 1 PLC 2
RFC Adapter
SAP EWM sends and receives telegrams on the basis of RFC calls. For the technical transfer of these
telegrams from RFC to the PLC and from the PLC to RFC, you need an adapter. This adapter has the

V1.1 8/2008
Introduction
purpose of passing on the telegrams unchecked. It does not save them, supplement them or follow their
status, nor does it check whether they have been sent successfully or inform the sender in the case of failure.
The logic for securing transmission is integrated both in SAP EWM and in the PLC. Parameters for the
connections between SAP EWM and PLC are also set at the communication end points.
The logic for securing the connection and the adapter parameters only include the following:
The adapter actively ensures that it can be called from SAP – in other words, it checks at certain intervals
whether its connection to SAP is still active and logs back onto the SAP system if necessary.
For this, it needs access to SAP. The access data must be set in the adapter.
For the TCP/IP connection, SAP is planning to issue such an adapter (on the basis of SAP xMII) at the
beginning of 2009.
For other types of technology (such as RK512), you can and must use special adapters. The interface for
these is described in the appendix.
RFC Adapter Functions
RFC-Adapter
Bridge between SAP RFC protocol and TCP/IP

Fully transparent: Keeps no data, does not evaluate data, does not keep track
of data
PLC connections are maintained in EWM (number of connections, IP-
Addresses / Ports, telegram length, communication protocol)
Registers itself in SAP, reconnects in case of connection loss
Easy to install / administrate
Configuration: SAP Logon (nothing else)
Start / Stop: Explicitly by administration tool or implicitly with machine start
Analyse: Logging option
RFC-Adapter from SAP
available Q1/2009
Windows 2003 Server (.NET)
Use of other RFC – Adapters possible
© SAP 2007 / Page 5
2.2 SAP EWM Material Flow Functions
SAP EWM 5.1 offers the following features for controlling the material flow by means of automated
warehouses:
Configurable paths (storage control)
Configurable capacity limits

V1.1 8/2008
Introduction
Consideration of equipment faults

Scanner connections
Automatic ID Point
Connection with conveyor lines
Connection with resources (stacker cranes, transfer cars)
SC interleaving
Reaction to bin errors (Bin occupied/Bin empty)
Reaction to material flow errors (unexpected scanner logon)
Diversion of faulty HUs to clarification bin
Monitoring and troubleshooting functions as part of the regular warehouse management monitor
MFS messages in the Alert Monitor
Storage Control via Communication Points
SAP EWM maps the system to be controlled by means of communication points. Communication points are
stations in the storage retrieval system at which it communicates with the PLC. Here, the PLC registers HUs
(on the basis of scanner information or material flow tracking) and awaits new destination specifications.
EWM controls Single Steps
Aisle 1 Aisle 2
EWM
Final
Destination
Intermediate
Destinations
CP12
Task
CP11
Event
1
Scanner
CP02 CP01 TCAR
PLC
The concept for these communication points is an important aspect of warehouse planning. More
communication points lead to closer material flow tracking in EWM, but also to more intensive communication
and consequently more load on the EWM system. For each stage between communication points, a
warehouse task is created.
Communication points are useful where

the system needs to choose a direction
there is a change of resource (pick-up and drop-off point)
orders unknown to the PLC need to be assigned according to priority

V1.1 8/2008
Introduction
Automatic ID Point and Diversion to Clarification Bin
The ID point is a special communication point2. The PLC reads data from a scanner and checks the contour
of the HU to be put away using a measuring device. The HU is also weighed if necessary. Non-storable HUs
or HUs that have not been registered must be diverted to the clarification bin. To do this, SAP EWM
evaluates the error code in the PLC’s logon telegram and prescribes the path to the clarification bin if
necessary.
Put away
Crane1 Craine 2
Built-in Functions
•Scanner telegram from PLC Crane3
•Evaluate / accept HU properties
•HU Type
•HU Weight
•Trigger put away strategy
•Reject in case of error
•Contur
•Noread
•HU unknown RGB1
TCAR
BAdI
ID-Point
•Consider state and capacity of
equipment in put away strategy
PP
GR Clearing GI
Avoiding Blocks
It is important, especially for vehicles, that the control system take account of the capacity limits on pick-up
and drop-off points. Once a load has been picked up, the system must be able to drop it safely at its
destination. SAP EWM can avoid dead lock situations and is able to react to availability events
spontaneously.
2
In the context of automated warehouses, the term ID point mostly refers to the point of storage bin allocation. Prepared and registered
HUs are identified automatically.

V1.1 8/2008
Introduction
EWM Prevents Dead Lock Situations

HU 2
„CP13“: Capacity 1
HU 1
TCAR
Task for HU 2 is postponed until HU 1 has IP

left CP13.
CP13 gets empty

•by „Location Left“ message or
PP
•by task confirmation HU 1 at next CP
Stacker Crane Interleaving
Stacker crane performance is significantly affected by the length and proportion of empty runs. For aisle-
specific vehicles arranged in the usual way (with the putaway and stock removal station at the same end of
the aisle), SAP EWM provides an interleaving strategy: Putaways and stock removals are transported
alternately. In order to find the right balance between order priority and path optimization, you can classify
orders (by latest start date) and thereby influence the scope of the order due list within which interleaving is to
be applied.

V1.1 8/2008
Introduction
Task Interleaving for Rack Feeders
Order Pool:
Aisle 1
Latest Start Date Classification
HU 2
Queue Aisle 1 HU 3
HU Dir Earliest Start Date Latest Start Date LSD classified
1 OUT 14:15 16:15 16:00
2 OUT 14:30 16:30 16:00 HU 1

3 OUT 14:45 16:45 16:00
4 IN 16:29 16:29 16:00

HU 4 HU 5
LSD Classification:
Classify by 1 hour
GR GI
The last move was a stock removal task

Current Time: 16:30 so the next move will be a put away task
Reaction to Material Flow Errors
In cases of logical misalignment in the warehouse, the EWM system reacts flexibly. If the PLC reports an HU
to the EWM system in an unexpected place (due to a technical malfunction or after manual interference), the
system reposts the HU for the new location and looks for a path from there to its destination.

V1.1 8/2008
Introduction
Reaction to Material Flow Errors
Destination
LP LP
Active task
CP CP
Original way
Deviation
(Material flow error)
CP CP
New way
Unexpected Scanner Message:

HU location is adjusted
New way is determined
Equipment Faults
If parts of the equipment are unavailable, this can either be reported by PLC telegram or set manually at the
control station. The EWM system then holds back orders affecting those parts of the equipment. Alternative
routes can be stored in Customizing. You have to implement a Business Add-In (BAdI) to determine the way
and extent to which they are to be used.
Equipment Fault
Equipment availability can be set in EWM
•by PLC
•by supervisor
EWM stops tasks for faulty equipments
Implementaion of alternate routes possible
State telegram from PLC:

TCAR broken
HU 2
TCAR
Supervisor: HU 1
CP02 blocked
PP
GI
GR Clearing

V1.1 8/2008
Introduction
Bin Errors
Logical bin errors (a destination bin is physically occupied due to a posting or material flow error, a source bin
is empty) are automatically identified by means of special sensors on the stacker cranes and reported to the
EWM system. The EWM can react to this automatically.
For HUs whose destination bin is occupied, SAP EWM equipped to determine an alternative destination. This
can either be a firmly defined alternative bin/clarification bin (to be stored in the resource master data) or a
storage bin that has been newly determined by means of a putaway strategy (BAdI implementation).
If the error Bin empty occurs, the corresponding order is cancelled on the grounds that it cannot be executed.
Bin occupied: New Task to alternate Bin (BAdI) or Clearing
Aisle 1 Aisle 2
EWM
c) new task
1 2
b) „bin occupied“
CP12
a) Put away task CP11
TCAR
CP02 I-Point
PLC

V1.1 8/2008
Introduction
Bin empty: Pick Denial – Alert – Workflow
Aisle 1 Aisle 2
EWM
c) Pick denial
Storage bin
empty
b) „Bin empty“
CP12
CP13
a) Stock Removal Task
CP14
TCAR
I-Punkt
CP05
CP06
PLC
GI
2.3 EWM Control Station Functions
2.3.1 Warehouse Cockpit
The Warehouse Cockpit provides an overview of the current state of the PLC communication channels. The
following screen represents a snapshot of the status of the 4 controllers for the example warehouse:
The RFC adapter is not registered (first column).
For this reason, none of the four controllers can be reached (second column).
There are no outbound telegrams in the EWM outbound buffer (third column).
There are no faulty telegrams in the EWM inbound buffer. All telegrams received before the connection
broke off or stopped have been processed (fourth column).
There are no malfunction reports for any of the resources connected via PLC (fifth column).
The system is currently running through the process responsible for repeating unconfirmed telegrams at
intervals and for checking the connection by means of LIFE telegrams.

V1.1 8/2008
Introduction
Monitoring the State of PLC Communication Channels

Warehouse Cockpit
2.3.2 Warehouse Management Monitor
The warehouse management monitor is the central instrument for the warehouse activity monitor. It offers
you various functions enabling you to monitor the warehouse and react to problems. This relates to both the
objects in the warehouse (communication points, segments, resources) and the HUs with their corresponding
and the telegrams exchanged on their behalf.

V1.1 8/2008
Introduction
Warehouse Object Overview
Monitor Equipment
Currently blocked Communication Points
Currently blocked Conveyor Segments
Resources and their States
Overview of HUs, Warehouse Tasks, Telegrams
Monitor Handling Unit States

See HUs at their current CP or Ressource / View open tasks and their states
Drill down to see the telegrams

V1.1 8/2008
Introduction
Telegram Log
Evaluate PLC Telegrams
EWM Telegram Log

•Sort by any field
•Filter any values from any fields
Processing Faulty Telegrams in the Inbound Buffer
Clearing Telegram Buffer
Telegrams may be reprocessed manually from inbound buffer

It is possible to edit wrong values before

V1.1 8/2008
Introduction
2.3.3 Alert Monitor
The Alert Monitor is another important instrument. All important information, warning and error messages that
occur during warehouse operation are collected here.
Alert Monitor
The monitor is used by various functions in SAP EWM. You can limit the display to messages relevant for the
MFS.
Alerts are normally generated by EWM exceptions. You can establish a link between EWM exceptions and
other actions, such as notifying a control station employee by text messaging (SMS).
2.3.4 Application Logs
The largest part of MFS processing takes place in the background. This makes it all the more important to be
able to retrace how a certain error situation came about by means of processing logs.
The processing modules lay down granular accounts of their steps in the application logs. These can be
evaluated on the basis of dates and times. You can also find processing times here.

V1.1 8/2008
Introduction
Application Log
By Date / Time
2.3.5 Solving Problems
The majority of problems occurring in an automated warehouse can be solved by the system automatically,
such as by diverting unidentifiable HUs (NOREAD at the scanner). Orders for unprepared leg stages or
devices are held back. Some BAdIs enable you to use alternative routes in cases of overload or malfunction.
HUs reported at unexpected locations are reposted in the background and, if possible, transported to their
original destination without user interference.
There are, however, situations the program cannot solve by itself. These are usually deviations on the three
levels:
Physical state
Logical mapping in the PLC
Logical mapping in SAP EWM
SAP EWM provides authorized employees with a number of functions enabling them to amend the situation:
You can resend telegrams that have already been confirmed
You can confirm warehouse tasks manually
You can repost HUs to other locations from where they can be transported further
You can cancel orders
You can divert HUs from the system
You can lock communication points, segments or resources
You can stop communication for individual channels

V1.1 8/2008
Introduction
3 MFS Basics
The Main MFS Objects
EWM maps the warehouse to be controlled on the basis of communication points, segments and resources.
Communication points (CP) are intermediate locations in the warehouse where communication with a
PLC takes place.
A segment is the connection between two communication points.
Segments can be grouped into segment groups, for example in order to manage their status on a shared
basis.
Automatically operated vehicles that pick up, transfer and drop off loads are mapped as resources.
Communication points, segments and resources have a certain capacity and can either be
malfunctioning or ready.
To transport HUs, EWM generates warehouse tasks (WT) and warehouse orders (WO) and arranges
these in queues. In the MFS, each warehouse order is assigned one warehouse task only.
Queues for vehicles are processed by resources. Queues for conveyor lines are communicated directly to
the PLC.
To execute warehouse tasks, the EWM system generates telegrams and sends these to the appropriate
PLC via communication channels.
MFS Objects
EWM LA
HU LB Queue Rsrc
CP CP CP PLC Channel
Segm
TELE
PLC
CP CP
CP RSRC
SAP AG 2007, EWM/MFS Example Warehouse / 5
3.1 Communication Protocol
In order to keep the real-time systems PLC and EWM separate, you should avoid synchronous calls between
them. The interface is message-based. In order to ensure that each order and each confirmation is
transmitted exactly once, SAP EWM implements a communication protocol. This protocol must also be
implemented on the PLC side.

V1.1 8/2008
Introduction
Communication Principle
The protocol is based on telegram sequence numbers: Each telegram is assigned an unambiguous number
by the sender. If these sequence numbers are used in the appropriate way, the following two potential
problems are avoided:
Telegram loss
Double processing
Avoiding telegram loss: the recipient acknowledges each telegram it receives. To do this, it returns it to the
sender with the original sequence number. The sender repeats telegrams for which it has not received an
acknowledgement within a certain period. It only sends the next telegram after the previous one has been
acknowledged.
Avoiding double processing: The recipient uses the sequence number to determine whether it has already
received the telegram or not. Telegrams received previously are confirmed but not processed. The sender
never sends a new telegram with the same sequence number as the previous one.
Both partners allow resetting the sequence number for the special purpose of setting up or synchronizing
communication.
Communication Protocol is Part of EWM
The sender repeats a message as long as it isn‘t acknowledged (every n secs.).

He does not send another message before the previous one has been acknowledged.
EWM
Send buffer Channel 1
No Telegram Snd Ack
17 State Request CP13 Y N
18 TASK CP02 – CP03 N N Last No. received 923
RFC Acknowledge
Telegram
Telegram
No. 923
No. 17
Channel 1
RFC-Adapter
Acknowledge
Telegram Telegram
No. 17 No. 923
TCP/IP
Last No. received 17 Send buffer Channel 1
No Telegram Snd Ack
PLC 1 923 State CP13 Y N

924 CONF CP02 – CP03 N N
The receiver sends an acknowledge message for every message he receives,

but he processes a message only the first time he receives it.
© SAP 2007 / Page 46

V1.1 8/2008
Introduction
Exceptions in Communication
Irregularities or errors in communication are handled as follows:
On the recipient side:

Received sequence number too low: Telegram is acknowledged but not processed.
Received sequence number too high: Telegram is accepted (in other words, acknowledged and
processed) and lower sequence numbers are no longer accepted.
The sequence number received is the highest possible (“999” for three-digit numbers): The next valid
sequence number is “1”.
Received sequence number is “0”: Telegram is accepted. The next valid sequence number is “1”.
On the sender side:

For a telegram sent, no acknowledgement telegram arrives within a set period. The telegram is repeated
with the same sequence number.
Even after a telegram has been repeated several times, there is no acknowledgement: The channel is
closed and reopened. After reopening, the telegram is repeated once more with the same sequence
number3.
The sender has lost the last sequence number (such as if the PLC has been changed): The sender starts
with the sequence number “0”.
On both the sender and the recipient side:

If no telegrams have been received or successfully sent (in other words, acknowledged) over a longer
period, a Life telegram is sent to ensure that the “intermission” is not due to a connection failure.
On the RFC adapter side:

The connection to SAP is continuously monitored. If it is lost, the adapter tries to reconnect at set
intervals.
3.2 EWM – PLC Communication (Message Types)
Conveyor Lines
SAP EWM provides you with the following message types for controlling conveyor lines:
SAP EWM: Warehouse task (HU – CP – FROM – TO)
PLC: Warehouse task confirmation (HU – CP – FROM – TO, with error code if appropriate4)
SAP EWM: Cancellation request for warehouse task (HU – FROM – TO)
PLC: Cancellation reply for warehouse task (HU – FROM – TO, with error code if appropriate)
PLC: Scanner message (HU – CP, with error code if appropriate)
SAP EWM: Status request for communication point, segment or segment group (CP/SEG/SEGGR)
PLC: Status message (ready/malfunctioning) for communication point, segment or segment group
(CP/SEG/SEGGR)
PLC: Blank message for communication point (CP)
3
The sender can only “escape” this situation if a) the expected acknowledgement telegram arrives or b) by manual interference,
(by deleting the unacknowledged telegram from the outbound buffer). The telegram is then considered as sent. If the recipient has not
received it, you can send it manually from the telegram log (with a new sequence number).
4
In the case of negative confirmation, EWM needs to be able to determine if the error occurred at the source or at the destination (in
other words, whether the HU has left its source location or not). This is shown by the entry in the field “CP”, the “reporting”
communication point. If the CP field contains the source, the HU has not left its source location.

V1.1 8/2008
Introduction
Control of Conveyors
Attributes
Capacity SEG 1 SEG 2

CP 1 Cap. 3 CP 2 Cap. x CP 3
Status Cap. x
Cap. 1 Ready Cap. N Broken (PLC)
Ready Ready Blocked (Supervisor)
Messages
„TASK“ HU 1
EWM to PLC
„Location left“ HU 1
PLC to EWM optional
„TASK CONF“ HU 1
PLC to EWM
© SAP 2007 / Page 47
Resources
EWM provides the following message types for controlling resources:
Status:
SAP EWM: Status request for resource
PLC : Status message (ready/malfunctioning) for resource
Full movement (one-step confirmation):

SAP EWM: Warehouse task (HU – Resource - FROM – TO)
PLC : Warehouse task confirmation (HU – Resource – FROM – TO, with error code if appropriate)
Full movement with start message (two-step confirmation):

SAP EWM: Warehouse task (HU – Resource – FROM – TO)
PLC: Start message (HU – Resource – FROM – TO, with error code if appropriate)
PLC: Warehouse task confirmation (HU – Resource – FROM – TO, with error code if appropriate)
Half movement (two-step commissioning):

SAP EWM: Warehouse task (HU – Resource – FROM)
PLC: Warehouse task confirmation (HU – Resource – FROM, with error code if appropriate)
SAP EWM: Warehouse task (HU – Resource – TO)
PLC: Warehouse task confirmation (HU – Resource – TO, with error code if appropriate)
Order cancellation:
SAP EWM: Cancellation request for warehouse task (HU – Resource – FROM – TO)
PLC: Cancellation reply for warehouse task (HU – Resource – FROM – TO, with error code if appropriate)

V1.1 8/2008
Introduction
Control of Resources
Attributes
Cap. x / Ready
Capacity
Status CP01 R001 CP02
Messages 1-Step 2-Step
HU 1 „Pick from“
EWM to PLC Task: HU 1
FROM - TO R001
CP01 CP02
HU 1
PLC to EWM „Picked from“
CP01 R001 CP02
HU 1
EWM to PLC „Drop to“
CP01 R001 CP02
HU 1
„Dropped to“
PLC to EWM „Task Conf.“ CP01 R001 CP02
© SAP 2007 / Page 48
Note:
The standard function modules determine the meaning of a telegram not only on the basis of the telegram type (telegram ID) but also on
the basis of existing field entries. Thus, it is especially important for the different types of order confirmations from PLC to SAP EWM that
exactly the specified key fields are filled. The messages for half movements in EWM are not organized in the following way:
Incorrect example:
“TA1” HU “1” from “X” to “Y” (“pull”)
“TC1” HU “1” from “X” to “Y” (“pulled”)
“TA2” HU “1” from “X” to “Y” (“push”)
“TC2” HU “1” from “X” to “Y” (“pushed”)
Half movements in EWM are organized according to the following principle:

Correct example:
“TA” for resource “R” HU “1” from “X” to “_” (“pull”)
“TC” for resource “R” HU “1” from “X” to “_” (“pulled”)
“TA” for resource “R” HU “1” from “_” to “Y” (“push”)
“TC” for resource “R” HU “1” from “_” to “Y” (“pushed”)
During “pulling”, the “Destination” telegram field is empty, whereas the “Source” field is empty during “pushing”.
3.3 Storage Control
Path Concept
You can divide warehouse tasks into smaller steps using layout oriented storage control. You can achieve
this by defining intermediate destinations for certain source-destination relationships. If no intermediate
destination has been defined, the EWM system assumes that the warehouse task can be executed directly.

V1.1 8/2008
Introduction
If you have defined an intermediate destination, the EWM system sets the status of the affected warehouse
task to inactive and creates another, active warehouse task for the intermediate destination. Once this has
been executed, the EWM system adjusts the current location in the passive warehouse task accordingly and
checks whether you have defined a further intermediate destination. The EWM system only activates the
inactive warehouse task if no further intermediate location has been defined.
Layout oriented Storage Process Control
LB 1
HU
inactiv
Step 1
LB 2
activ
Bin 1 Bin 2 Bin n Final Bin
LB 1
HU
inactiv
Step n
LB 3
activ
LB 1
HU
activ
Final Step
3.4 Handling Capacity Bottlenecks
Setting Capacity Restrictions
For each communication point, segment and resource type, you can set a maximum capacity (number of
HUs). The EWM system then holds back orders that exceed this limit.
Availability Events
To ensure further transport if a capacity has become available again after a stop, the EWM system checks
the communication points and resources affected by an availability event. You can choose and set these in
the Customizing for each communication point.
Availability events are:

A HU reaches the next (intermediate) destination. The warehouse task source is cleared.
A HU has left its source. The PLC reports the source as empty.
A communication point or a segment is ready again (there is an unblock message from the PLC or the
block in the warehouse management monitor is removed).
A HU that had occupied a certain capacity is reported at a different location in the warehouse (reposting).
A warehouse task occupying some capacity at the destination is canceled.

V1.1 8/2008
Introduction
Customizing Triggers
If CP11 gets availabe again

TCAR will be triggered:
CP12 CP13 CP16 CP17 CP20 CP21
HU 1

Availability events:
•Location left (HU started)
•Task confirmed (HU arrived at next destination) TCAR
•Equipment fault reset

HU 2
CP00 CP04 CP06 CP08
CP09
3.5 Strategies
SC Interleaving
The EWM system assigns each stacker crane with one putaway and one stock removal in turn in order to
reduce empty routes. (This function needs to be activated in Customizing.)
The system takes into account those orders

whose earliest start date has been reached
whose latest start date after classification (rounding) is in the currently most urgent appointment group
which can be executed (destination not occupied)
From this limited order pool, the system chooses one order for the next preferred direction (putaway/stock
removal) for each crane.
If there are several orders for the currently preferred direction, the system chooses the one with the highest
priority and, if there are several of these, the one with the lowest warehouse order number.
The priority is determined by the warehouse process type.

V1.1 8/2008
Introduction
Task Interleaving for Rack Feeders
Aisle 1
Order Pool:
HU 2
Queue Aisle 1 HU 3
HU Dir Earliest Start Date Latest Start Date LSD classified Prio LA
1 OUT 14:15 16:15 16:00 2 10
2 OUT 14:30 16:30 16:00 1 11 HU 5 HU 1

3 OUT 14:45 16:45 16:00 1 12
4 IN 16:29 16:29 16:00 2 13

HU 4
LSD Classification:
Classify by 1 hour
GR GI
•The last move was a put away task (HU 5)

•All tasks are considered (same LSD classified).
•Interleaving strategy decides for stock removal
Current Time: 16:30 •There are 2 removal tasks with priority 1
•Ressource will select smallest LA-# next (HU 2).
Late Orders overrule Task Interleaving, Priority not
Order Pool: Aisle 1

HU 2
Queue Aisle 1 HU 1
HU Dir Earliest Start Date Latest Start Date LSD classified Prio LA
1 OUT 13:15 15:15 15:00 2 10
2 OUT 13:30 15:30 15:00 1 11 HU 3

3 OUT 14:45 16:45 16:00 1 12
4 IN 16:29 16:29 16:00 2 13

HU 4 HU 5
LSD Classification:
Classify by 1 hour
GR GI
•The last move was a stock removal task (HU 5).

•HU 2 should be next (overdue task with highest priority)
•But: Destination of HU 2 and HU 1 is occupied.
Current Time: 16:30 •All other tasks are considered (next LSD classified).
•Interleaving strategy will execute HU 4 next.
•(Priority does not overrule interleaving)
Alternative Routes/Load Distribution

If there is a malfunction or insufficient capacity or if you want to distribute the load more evenly, you will often
wish to use alternative routes. Alternative routes can be stored in Customizing. In the standard version, the
program always uses the first of the defined routes. In cases of malfunction or insufficient capacity it switches
to the next alternative.

V1.1 8/2008
Introduction
There is BAdI for implementing load distribution.
Consideration of System Status and Load for Putaway Strategy
Not included.
Empty Route Optimization for Transfer Car
Not included.
Line Availability Beyond Next Communication Point/Segment/Resource
Capacity limits can be defined in Customizing.
To evaluate these, you have to implement a BAdI.
Multi-Depth Storage
Not included.
Resources with Several Pick-Up Devices
Not included.

V1.1 8/2008
Introduction
4 PLC Communication
The following steps are necessary:
Setting Up the Communication Interface
Choose a telegram structure for the PLC telegrams (header and item)
Define interface type for similar controls (such as several stacker cranes)
Define PLC and communication channels
Map error codes for communication errors as exceptions
Setting Connection Parameters
Set up an RFC destination and enter it in the PLC master data

Enter the IP address and port(s) of the PLC in the master data of the communication channels
RFC Adapter
Configure and start the RFC adapter
Test
Connection check
Test with EWM simulation module (internal to SAP)
Test with external simulation program
4.1 Setting Up the Communication Interface
4.1.1 Telegram Structure
4.1.1.1 Structure /SCWM/S_MFS_TELETOTAL
SAP EWM handles telegrams internally by means of a comprehensive structure that contains the superset of
the data fields provided in the standard for communicating with controllers. The specific telegram structures
are converted from or to /SCWM/S_MFS_TELETOTAL before they are sent or after they are received. This is
achieved by means of identical names for the fields. Therefore, it is important that the field names you
create for the specific telegrams are the same as the names of the corresponding fields in the
/SCWM/S_MFS_TELETOTAL structure. All data types, including figures and units of measurement, are
communicated as signs (no packed fields). Field lengths may differ.

V1.1 8/2008
Introduction
Telegram Structures
EWM
MFS_TELETOTAL
SEQU_NO
TELETYPE
HUIDENT
HUTYP
...
RSRC
CP
Function CS
WT
Modul ...
SOURCE SEQU_NO
DEST TELETYPE
... HUIDENT Z_TELE
LENGTH SOURCE
WIDTH DEST
... MFS_ERROR
MFS_ERROR
SEQU_NO Z_TELE
TELETYPE
HUIDENT
SOURCE
PLC Event DEST
PLC MFS_ERROR
/SCWM/S_MFS_TELECORE Header Data:

V1.1 8/2008
Introduction
Structure /SCWM/S_MFS_TELETOTAL:
If you need any fields not contained in this structure, you have to extend the include structure
/SCWM/INCL_EEW_MFSTELE. Its data fields then also have the same names and are thus transferred from
or to the relevant PLC telegram.
4.1.1.2 Defining a Telegram Structure (DDICT)
SE80: SAP Menu/Tools/ABAP Workbench/Overview/Object Navigator
In the Data Dictionary, you have to define the telegram structures to be used in communicating with the
controllers. These structures should be created in the customer name space. To do this, you can call the
Repository Browser in transaction SE80 (ABAP Workbench Object Navigator). You need a structure for the
telegram header and one for the actual telegram data. We recommend that you use the same structure for all
telegram types.5
Creating a new structure in the DDICT:
5
Example: A PLC reads 212 bytes in a cycle. In most cases it will not be worth defining shorter structures for shorter telegram types if
the longest structure you need is shorter than 213 bytes.

V1.1 8/2008
Introduction
4.1.2 Defining the Interface Type
There are a number of parameters for the PLC interface. In order to only have to define these settings once
for a number of similar controllers, you can use interface types. This is especially useful for stacker cranes as
there are usually several of them that are addressed in the same way.
Define an abbreviation for the interface type …
… assign this type to the PLC objects and relate all further settings to the interface type rather than the PLC.
4.1.3 Defining Telegram Types
Each telegram is identified by a telegram type. This is a character string which informs the recipient of the
telegram’s meaning. If you determine the telegram structure to be used in each case at the same time, then
this Customizing activity is called Define Telegram Structure:
Use the option “for PLC Interface Type” (“for PLC” is used to ensure compatibility with the earlier SAP
EWM5.0) …

V1.1 8/2008
Introduction
… and first only define the telegram types needed to establish and secure the connection. SAP EWM
provides a number of predefined telegram categories for which you now define the identifiers used in the
customer project.
Telegram types you need:

A Synchronization setup: Used by SAP EWM to establish the connection to PLC.
B Synchronization start: Sent by the PLC as a reply to the synchronization setup telegram from EWM.
D Synchronization end: Sent by the PLC to the EWM to finish synchronization. The EWM system
concludes that the PLC’s transmission buffer is empty and the PLC is ready to receive new orders.
K Life telegram: Sent by the EWM system to the PLC if it has not received any telegrams from the PLC
within a set period.
At the same time, you can specify the name of the previously defined telegram structure.
Recommendation: In general, it is more useful to work with uniform telegram lengths. The increased
throughput you achieve is insignificant and sometimes paid for with a greater programming effort on the PLC
side or more complicated protocol analyses.

V1.1 8/2008
Introduction
4.1.4 Defining the PLC
Each external communication partner must be made known to the EWM system as a PLC. It makes no
difference if it actually is a PLC. A PC control or, in the extreme case, even an external subsystem that
independently controls a certain part of the warehouse, is, in this sense, a “PLC”.
If you are using head controls, you should only define these. They pass the tasks on to the appropriate local
controls.
The PLC is the communication partner for the EWM system. In this example warehouse, there are 4 PLCs:
Programmable Logic Controller (PLC)
RBG3
PLC RACK2
RBG2
PLC RACK3
RBG1
PLC RACK1
EWM
TCAR
PLC CONSYS1 IP
PP
Clearing GI
GR
SAP AG 2006, SCWM/MFS-Beispiellager / 4
You can access the Customizing under Material Flow System (MFS) Master Data:
First define the PLC for the prestorage area:

V1.1 8/2008
Introduction
What the Attributes Mean
Interface Type
Interface type used (see 4.1.2 Defining the Interface Type).
Header Data Structure
Name of the structure of the telegram header (see 4.1.1.2 Defining a Telegram Structure (DDICT)). All
telegrams that are exchanged with a PLC must have a standardized header. The structure must be
previously defined in DDICT and the name must be entered here.
Putaway Process Type
Ensures compatibility with the earlier SAP EWM 5.0: Putaway process type to be used at the ID point.
As of SAP EWM 5.1., the putaway process type is stored at the communication point.
Process Type For Cases of Error
Needed at the ID point or for other scanners: Process type for diversion (such as in the case of a contour
error; does not differentiate errors from each other)
MFS Exception Code
Is selected when the destination storage bin needs to be changed during a WT confirmation.
Mapping
Shows whether the communication point names need to be translated between EWM and PLC. If this is
marked, the program will search for PLC names for the EWM names and vice versa in a mapping table when
telegrams are converted. You can maintain the table in the application menu using transaction
/SCWM/MFS_OBJMAP – Map EWM to PLC objects. As storage bin addresses need to be unambiguous across
storage types in SAP EWM (and it is therefore recommended to include the storage type in the encryption), and
as this specification is, on the other hand, not needed for the PLC, mapping is usually required.

V1.1 8/2008
Introduction
Identification
A sender ID which the EWM system is to enter in the telegrams to the PLC. (Name of EWM as PLC
communication partner). Has no meaning in SAP EWM. The PLC may expect a particular sender. If the
Check Telegram indicator is set in the communication channel, the EWM system checks whether this ID is
entered as the recipient when telegrams come in. If the Check Telegram option is on, telegrams without this
recipient name are not processed.
4.1.5 Defining the Communication Channel
At least one communication channel must be defined for each PLC. The communication details are stored in it.

V1.1 8/2008
Introduction
What the Attributes Mean
Telegram Retries
A value between 1 and 9. After the number of unsuccessful (unacknowledged) repetitions of a telegram to the
PLC entered here has been reached, the system triggers the exception defined below (see Exception
Code MFS).
Interval Tel. Retry
If there has been no acknowledgment telegram for a telegram sent: After how many seconds should the
telegram be repeated?
Highest Seq. No. For Sending
Highest sequence number when sending telegrams on this channel: The following telegram is assigned the
sequence number 1.
Highest Seq. No. For Receiving
Highest sequence number when receiving telegrams on this channel: The expected sequence number after
this is 1.
Fill Character
Empty spaces in a telegram can be replaced by a special character so that it can be read more easily in
protocols or during transmission.
Handshake Confirmation
A character informing the recipient that this is an acknowledgement telegram (logical confirmation).
Handshake Request
A character informing the recipient that this is an order telegram, not an acknowledgement telegram.
Handshake Mode
Here you can specify if telegrams should be acknowledged and what information should be contained in the
acknowledgement. The following options are available:
Recommended: A Send Complete Telegram
S/R Switch
Indicator specifying whether the sender and recipient should be switched in the acknowledgement telegram.
Life Tel. Interval
After how many seconds without telegram traffic (on this channel) should a Life telegram be sent.

V1.1 8/2008
Introduction
Life Tel. Type
Telegram ID for the Life telegram. Must be defined previously.
Get Seq. No.
Indicator specifying whether sequence numbers should also be assigned to Life telegrams.
Recommendation: Yes
Start Character
You can choose a 1-place or 2-place start character for telegrams here. The start character can be used to
check whether a telegram has been wrongly compiled in the communication layer. If so agreed, telegrams
without this start character are rejected.
End Character
You can choose a 1-place or 2-place end character for telegrams. Used in the same way as the start
character.
Note: Start and end characters are useful if you are working with different telegram lengths.
The end character is also necessary if the communication layer used (RFC – TCP/IP converter) does not
expand the telegrams received from SAP EWM to their full length6. The reason for this is that strings can
only be transferred from ABAP to the RFC layer if the complete length is used up. The telegram string is
too short if the last field is not filled.
Telegram Length
Specifying the telegram length. If there is an entry, you are working with a fixed telegram length. In other
words, the EWM system expects all telegrams, including acknowledgement telegrams, to be this long.
Shorter or longer telegrams are rejected.
Check Telegram
Here you can activate an additional check for fields that are usually not needed for processing. These are:
Sender, Recipient. If this check is activated, telegrams with the wrong sender/recipient are rejected.
Exception Code MFS
Here, you enter an exception code defining system behavior in cases of connection failure. Despite several
retries (Telegram Retries field), SAP EWM has not received acknowledgement for a telegram it has sent. It
now makes sense to close the channel and establish the connection anew. You define and store this
behavior in an exception code which you enter here, for example:
REST: Restart Communication Channel (see Chapter 7.2).
6
When a communication channel is started, EWM transmits the telegram length to the RFC adapter. The RFC adapter should add as
many blank spaces to the messages received via RFC as are needed to reach that length.

V1.1 8/2008
Introduction
Standard Error
Error code by which the EWM system signals to the PLC that an incoming telegram could not be processed.
It is set in the acknowledgement telegram to the PLC if no specific code for the actual error has been
maintained in Customizing (see 4.1.6).
No Sync
Here you can deactivate the synchronization telegram string which the EWM system uses to initiate or
reestablish a connection. Warning: In this case, you absolutely must activate the Life telegrams. Otherwise,
the connection will only be established with the first user telegram from EWM to PLC. The PLC cannot send
any telegrams until then.
4.1.6 Defining Communication Errors from EWM to PLC
This means you determine codes for errors affecting telegram communication. The following menu option
determines the codes that the EWM system uses to report errors in the communication protocol to the PLC.
Communication Errors Detected by EWM
A-F are errors: The telegram is not processed.
G means: Telegram received repeatedly (already processed).
H means: The sequence number was not checked because the counter in the warehouse management
monitor has been reset. The telegram has been processed nevertheless.
You can specify for all errors whether the communication channel is to be closed and restarted.

V1.1 8/2008
Introduction
4.1.7 Communication Errors from PLC to EWM and the Reaction to Them
Communication Errors Reported by the PLC
It is defined here which exceptions7 should be triggered in SAP EWM when communication errors occur.
The following section sets out examples of exceptions:
Exception MBOF: Buffer Overflow: The PLC cannot receive any further telegrams at present. The EWM
system is requested to postpone the telegram and send it later.
Exception MSEQ: The PLC does not accept the sequence number (it has received a telegram with a higher
sequence number before). This can happen when the sequence number has been reset in EWM but not in
the PLC.
Exception MTEL: The PLC does not accept the telegram because it contains incorrect data, such as the
wrong recipient, or missing end character.
4.2 Setting the Connection
4.2.1 Setting up the RFC Destination (sm59)
The actual PLC communication is performed by an external communication layer:

SAP EWM communicates via RFC.
The communication layer uses a program ID to register as an RFC destination and, in this role, offers 4
function modules that can be called externally. It takes over the telegrams and sends them to the PLC via
TCP/IP socket.
7
See appendix to Chapter 7.2. You will find an example for using and configuring exceptions in Chapter 5.6.3

V1.1 8/2008
Introduction
Creating a new connection under TCP/IP connections:
Specify the timeout to a comparably low value. Do not use the default gateway value for CPI-C Timeout.
Once the RFC adapter is connected, the EWM telegram repetition process will be blocked for the specified
time, if the connection has been lost.

V1.1 8/2008
Introduction
4.2.2 Setting the RFC Destination for the PLC
In the EWM system, the RFC destination must be set for each PLC. In the application menu, you can do this
using transaction /SCWM/MFS_PLC:
Here, a preliminary version of the future SAP RFC adapter is being used. Therefore, the setting is “SAP
Communication Layer”. Its interface is known to SAP EWM, thus you do not need to specify the function
modules here. (If you are planning to use other layers, you must enter their calling interfaces here.)
The Logging indicator activates the telegram log: All telegrams that are part of the communication with this
PLC are stored in the database and available for future evaluations.
4.2.3 Setting the Communication Channel
The communication layer should be easily configured and only pass on data. This is why the PLC address is
also maintained in SAP EWM and not in the communication layer.
You define an IP address and port for each communication channel:
At the start call, the EWM system transmits these connection parameters to the communication layer.
4.3 RFC Adapter SAP Plant Connectivity MDS 2.0
4.3.1 Configuring the RFC Adapter
Here, the SAP RFC Adapter SAP Plant Connectivity MDS 2.0 is used. It contains an RFC interface and a
socket interface. The application is based on .NET3.5 and is completely transparent both in its messages and

V1.1 8/2008
Introduction
with regard to the socket addresses. It has to be installed on a Windows system (Windows XP or Windows
2003). SAP Plant Connectivity MDS is delivered with a “Management Console” and set up as a Windows
service. By use of the Management Console you define source channels and use them in agents. The agents
receive notifications, which are directed to destination channels.
An agent is installed as a Windows service by the Management Console automatically. It can be started and
stopped from the Management Console or using the Windows services.
A single agent can handle several channels. When a PLC communication channel is started in EWM, the IP
address and the port of the PLC are transmitted to the agent from SAP. A single socket channel and a single
RFC channel, connected by a single agent (service), can be used to address several PLCs, as shown in the
following picture:
SAP Plant Connectivity MDS 2.0
EWM
Windows
.NET3.5
Service
RFCChannel
PCo
Management
Console
SocketChannel
PLC1 PLC2 PLC3
© SAP 2008 / Page 1
Of course it is possible to setup more than one service and to have a separate service for each connection.

V1.1 8/2008
Introduction
SAP Plant Connectivity MDS 2.0
EWM
Windows .NET3.5
Service1 Service2 Service3
RFCChannel1 RFCChannel2 RFCChannel3 PCo

Management
Console
SocketChannel1 SocketChannel2 SocketChannel3
PLC1 PLC2 PLC3
© SAP 2008 / Page 2
To configure a connection, first create a source channel. In SAP Plant Connectivity MDS, a source channel is
a PLC channel. The PLCs are connected via socket:
If the installation was right, there is only one choice: A socket Agent.

V1.1 8/2008
Introduction
It is important that the option “Remove stream terminator when receiving data” is unchecked. Otherwise the
telegram strings, which are sent to SAP, will be too short.
Save the channel.
Now create a new destination channel. The destination, in the words of SAP Plant Connectivity, is the SAP
system. To SAP there must be a RFC channel:
Select “RFCDestination” and name it like the SAP system and client (just as a proposal).

V1.1 8/2008
Introduction
Then the client and server connection parameters have to be set. You have to specify the SAP connection
parameters and the program ID under which it is supposed to register in the system:
Make sure that the reliability option is activated. The RFC adapter then tries to reestablish the connection to
the SAP system at certain intervals (here 10 seconds) if an error has occurred. 8 Otherwise the channel won’t
reconnect to SAP automatically after a connection loss.
The user should be a specific technical user. (Required authorization: See 7.1)
Save the channel.
Once the two channels have been defined, the service must be created, which connects them. Add a new
agent instance:
8
EWM is responsible for monitoring the connection to the PLC. See 3.1 Communication Protocol

V1.1 8/2008
Introduction
Make sure that the right source channel is selected (if you have created more than one), and give the
instance a name. This name will appear as windows service:
The service will be created and added in the Agent Instances view:

V1.1 8/2008
Introduction
It can be seen as Windows service under Start Administrative Tools Computer Management
Services:
So far the agent only knows its source channel. To connect the destination channel to it, a notification has to
be added9:
Again, make sure you select the right agent name, if you have created more than one. The name of the
notification does not matter:
The notification must be set to enabled:
9
This comes from the fact, that MDS is used in the MII environment as well: Source channels receive notifications from the PLCs, and
MDS can scan these notifications to take a decision to which destination they should be addressed. This philosophy is used here in the
EWM environment as well, even if MDS doesn’t have to scan the messages but just address them all to one destination channel instead.

V1.1 8/2008
Introduction
Please note the chain in the title bar (in blue): Source channel agent Notification.
The trigger type isn’t used in EWM environment. But now the destination has to be added, the RFC channel:
Select the RFC channel and enter name and description:
Now the configuration is finished. Save your settings:

V1.1 8/2008
Introduction
4.3.2 Connection Check from the RFC Adapter
As soon as you have set up the connection data, you can carry out a connection check from MDS to EWM:

V1.1 8/2008
Introduction
4.3.3 Starting the RFC Adapter
To start the service there are 3 options:
Start option a): Start the service manually from the Management Console:
Start option b): Start the service manually from the Windows Services Utility

V1.1 8/2008
Introduction
Start option c) Set the Service Start Mode to Automatic. It then will be started automatically with the
computer:
The service runs independently of the Management Console.
4.3.4 Connection Check from SAP (Transaction “sm59”)

Now the connection check from SAP should also work. Clicking the Connection Test button …
… leads to the following result:

V1.1 8/2008
Introduction
4.4 Testing PLC Communication
4.4.1 Test Using RFC Module
You also have the option of using EWM to simulate a simple PLC using ABAP. To do this, choose a
proprietary communication layer instead of the SAP communication layer when maintaining the PLC.
Moreover, you must not specify an RFC destination, so that the simulation runs on the currently used
application server. The simulation itself is implemented in the function module /SCWM/MFS_SIM_RECEIVE.
You must specify this as the send module.
With these settings, you will have set up the PLC simulation by SAP EWM. The simulation evaluates the
existing Customizing settings for the appropriate PLC and replies accordingly. Further simulation customizing
is neither necessary nor available.
As soon as a telegram has come in, the simulation sends the appropriate acknowledgement telegram. After
another 3 seconds, the simulation sends the following replies, depending on the incoming telegram:
Synchronization setup Synchronization start
Synchronization start Synchronization end
Status request Status message
Warehouse task Warehouse task confirmation
Cancellation request for WT Cancellation confirmation for WT
Other types of telegrams are ignored.
The simulation gets the appropriate telegram structure from Customizing.
By specifying the parameter /SCWM/MFSSIM_VEL_FAC in the user master data, you can vary the 3-second
response time. You can enter the response time you prefer in seconds. Values below 1 second are not
permitted.

V1.1 8/2008
Introduction
Please note: The simulation does not process incoming telegrams in a strictly serialized manner. The replies
are reciprocated after the response time, depending on when they come in. Thus, telegrams may overtake
one another.
4.4.2 Test with an External PLC Simulation Program
If you want to test an item under more realistic conditions, and as long as you do not have a real PLC, you
are well advised to use an external simulation program that will both implement the communication log and
be able to respond correctly to future warehouse task telegrams.10.
This is an example of how to use an external simulation tool: The tool opens a port and waits for EWM (or the
RFC adapter ) to log on as a client.
4.4.3 Starting a Communication Channel
In the Warehouse Management Monitor …
10
Not included in the SAP delivery.

V1.1 8/2008
Introduction
… under …
… more methods ...
Synchronization is executed. The following is a PLC simulation log:
After successful synchronization, the status changes to B:
4.4.4 Monitoring the Interface (EGF)

V1.1 8/2008
Introduction
4.4.5 Telegram Log
You can display current telegrams in the Warehouse Management Monitor:

V1.1 8/2008
Introduction
5 Connecting the Prestorage Area
The way conveyor lines are connected to SAP EWM is here explained using the prestorage area as an
example. The following steps are necessary:
Setting up a warehouse type with storage bins and communication points
Setting up routes (storage control)
Defining how warehouse tasks are assigned to PLCs
Communicating warehouse tasks to the PLC
5.1 Setting up a Warehouse
While a HUs are being transported through a warehouse, they are always in storage bins. All possible
locations of HUs must also be storage bins.
In an automated warehouse, the HUs move from one communication point to another. You can think of
communication points as additional attributes of storage bins. Every communication point is also a storage
bin, but only the storage bins on the automated storage retrieval system are also communication points,
whereas the storage bins in the actual warehouse are not.
You define all points in the system as both storage bins and communication points if they require any SAP
EWM action, such as
deciding on a subsequent transfer direction (setting the course),
taking account of capacity bottlenecks (priority control) or
transferring a HU from PLC to PLC or from conveyor line to resource or vice versa (change of resource).
It is clear that the number of communication points is the decisive factor influencing performance. The more
communication points there are, the more transport steps are controlled by SAP EWM, the more warehouse
tasks are created and confirmed and the more communication with the PLC takes place.
In order to obtain a good Warehouse Management Monitor overview of what is happening, especially in an
automated warehouse, it is useful to set up a specific storage type for the storage bins in the prestorage
area.11.
First, you must create a storage type. Then, you create storage bins and communication points and connect
them to each other.
5.1.1 Storage Type
In the following, you will find the standard settings for MFS-operated prestorage areas. The storage type role
H (automatic high rack storage area) is crucial. It controls the selection of MFS-relevant warehouse tasks and
HUs in the Warehouse Management Monitor.
11
The so-called storage groups (see the chapter on storage control) are another reason. In automated warehouses, storage groups
(four-character terms) are used more extensively than in manually operated warehouses. Within a storage type, storage groups are
unambiguous.

V1.1 8/2008
Introduction
The ID Point Active and Pick Point Active indicators need not be set. As of SAP EWM 5.1, you can use
layout-oriented storage control for this logic.

V1.1 8/2008
Introduction
5.1.2 Storage Bins
For each communication point, you must create a storage bin and assign it to the communication point. The
storage bins need not have any particular attributes. However, the Storage Group (StGrp) characteristic you
define for them has an important role in storage control (see Chapter 5.2).
You are provided with a special tool for generating storage bins. To do this, you define a naming structure.
This tool then creates the storage bins automatically. However, if you want to give the storage bins “speaking
names” (similar to the communication points), a structure may not offer you the best options. In this case, it is

V1.1 8/2008
Introduction
better to create storage bins manually. (It is probably not a good idea to dispense with speaking names for
communication points.) For the example warehouse, the result should look approximately as follows12:
5.1.3 Recommendation for Assigning Names to Storage Bins
In an MFS context, 3 designators are needed for one location:

Communication point, storage bin, storage group.
It will thus give you a better overview if you express this identity in the names you assign. However, the
following restrictions apply:
Within the warehouse number, storage bin names are global
Communication point names have 18 characters and are valid both for the warehouse number and the PLC
Storage groups have four characters and are valid for one storage type
Recommendation:
Communication point: as short as possible, for example CP04, or start with the abbreviation for the
storage type, for example VZ01-CP04
The storage group can then be identical (for example: CP04)
Storage bin names starting with the storage type (for example: VZ01-CP04).
When communicating with the PLC, the standard EWM system uses the storage bin names. If the PLC
requires shorter names (or other names) as transport addresses, you can use a conversion table:
PLC mapping assignment for storage bin (for example: VZ01-CP04 CP04) (see Chapter 5.4.1)
12
The storage bin type (BT – Bin type) is not clearly set in this example. Please ignore this. Also, the bin access type (Acc. Type) is not
yet important here. It can be helpful in resource control. (See Chapter 5.5.1.2)

V1.1 8/2008
Introduction
5.1.4 Defining Communication Points
5.1.4.1 Communication Point Types
Communication points can be characterized by various communication point types. Later, this is used to
distinguish different ways of processing incoming telegrams.
The following communication point types are recommended:
5.1.4.2 Communication Points
Communication points contain the additional attributes the MFS needs for storage bins on the retrieval
system.13
Example of communication point “CP01” (ID point):
13
The example warehouse could probably be operated with fewer communication points. For exercise purposes, we have been
generous with these.

V1.1 8/2008
Introduction
Description of the communication point attributes (some are not yet important and will be used later in
Chapter 5.5):
PLC
Here, you enter the PLC controlling this communication point. If this is a pick-up and drop-off point between
two controllers (such as putaway/removal station SC), this is the PLC that will report if the bin is available.
The assignment of warehouse tasks to controllers is controlled by warehouse task queues, not by the PLC
assignment of the communication points involved.
Communication Point
Unambiguous name of the communication point (within the warehouse number and PLC)
Description
Explanatory text without control functions
RPTyp
(Communication Point Type) This allows you to control specific PLC telegram processing for this point. A
scanner telegram for an ID point is processed differently from a scanner telegram that is only needed for
material flow tracking. When defining MFS actions, you can set the subsequent processing for each telegram
type and communication point type (see Chapter 5.4.3).

V1.1 8/2008
Introduction
ID Point
A communication point marked this way is a storage bin allocation point. The storage bin search for all
incoming HUs is triggered here. Already existing warehouse tasks are cancelled. Any error codes attached to
the HU are deleted. Thus, further transportation is determined by the result of the putaway strategy
(depending on the material and process type).
If you do not wish this, you have to provide your own action module for processing the ID point telegram
(see Chapter 5.7.3)
End
Shows whether storage control is completed here.
In fact, this is a protection against Customizing gaps in automated warehouses. The indicator is meant to
convey to the program that it is not due to a configuration error if no further entry is found in the storage
control table.
With each WT confirmation, the program looks for a subsequent entry in storage control. If it finds such an
entry, the End indicator is not evaluated.
If it does not find such an entry, it activates the passive warehouse task if the End indicator is set. If the End
indicator is not set, the program assumes there has been a configuration error, and the inactive WT stays
inactive. The HU is stopped and no telegram is sent to the PLC.14
Clarification Bin
Shows that this is a clarification bin on the retrieval system. End point of diversion in case of error. A HU that
arrives here after being diverted on account of an error is not transported any further. An inactive warehouse
task is not activated.
If you want to access an external clarification bin, you can enter it under Clarification Storage Section. In that
case, the Clarification Bin indicator should not be set.
Scanner
Scanner communication point. The module for confirming warehouse tasks can react to the errors Noread
and Unknown HU issued by scanner communication points.
Putaway Process Type
As of SAP EWM 5.1., the putaway process type can also be stored at the communication point. (Formerly in
the PLC only.) This entry makes sense for ID points. It affects the putaway strategy.
Delete Error
If a HU arrives at a communication point marked in this way, any errors set for the HU are automatically
deleted.
14
For more information on using the End indicator, also see Chapter 6.3

V1.1 8/2008
Introduction
Reason: If a HU (for example, at the ID point) is diverted to the clarification bin, the reason for this diversion is
stored with the HU in the form of an exception code. This ensures that this information can also be accessed
at any intermediate communication points on the way to the clarification bin, even when the affected
warehouse task could not be created yet (such as because of a capacity bottleneck). When it arrives at the
clarification bin, you might wish that the error code be reset automatically so that the HU can be put on
without further inference from an operator, as when there has been a contour error displayed by the PLC.
Thus, the operator would not need any information from SAP EWM and would prefer to simply transfer the
HU back to the ID point after removing the contour error.
No Follow-Up WT
You can use this to deactivate the automatic creation of the WT for the next stage – even when you have
defined one. The automatic flow then stops here.
Useful for forced routes in the warehouse. The PLC registers a HU at a point (WT confirmation), but there are
no alternatives to the route to the next scanner, or these are not controlled by the EWM system. SAP EWM
then posts the HU to the communication point and it remains there for the time being. Only when it is
registered with the next scanner does the flow continue – from there.
Capacity
The number of HUs that are located or may be posted to this communication point at the same time (depends
on the capacity mode)
Capacity Mode
Controls the type of capacity check (see below)
Capacity Exception Code
Exception code controlling processing in case of capacity overload. There are two predefined exception
codes:
STAY: Results in no WT being created in the case of a capacity bottleneck. The HU remains at the
communication point without an active WT until the next availability event.
NSND: Results in a subsequent WT being created but not sent to the PLC in the case of a capacity
bottleneck. The HU remains at the communication point with a prepared, active WT until the next availability
event.
In the standard system, the capacity is never checked in advance but only for the next intermediate
destination to be reached according to storage control.
Clarification
The next communication point the HU should be moved to on the way from here to the clarification bin in
case of error. This considerably simplifies storage control. The routes to the clarification bin need not be
configured like “normal” destinations by specifying a final destination. They consist of individual steps of
which only the next one needs to be set at each point.

V1.1 8/2008
Introduction
Clarification PLC
PLC to which the clarification communication point has been assigned (part of the communication point key).
No Check Capacity
You can deactivate the check for the capacity of the route to the clarification bin (next segment/CP).
Do Not Check
You can deactivate the check for the status (ready/malfunctioning) of the route to the clarification bin (next
segment/CP).
Clarification Storage Type/Section/Bin/Process Type
Often, the clarification bin itself is not part of the retrieval system but is located in a specially marked space
near the warehouse activity monitor. You can define a storage bin and enter it as the clarification bin here.
For HUs that arrive at this communication point on account of an error, another warehouse task is created for
this storage bin. In this way, you can make sure that a radio-controlled forklift is called in order to lift the HU
off the retrieval system and transport it to the actual clarification bin.
5.1.4.3 Capacity Mode for Communication Point
Option A: HUs at Communication Point Without Active Warehouse Tasks
When the system is determining the free capacity of the communication point, it should take into
account all HUs that are currently posted to the storage bin assigned to the CP and for which there is no
warehouse task for further transport yet.
This is the least restrictive setting: The capacity is only limited by HUs that a) have already arrived there and
b) have not been assigned a warehouse task for further transport. (Inactive warehouse tasks are ignored.)
Option B: HUs at Communication Point

The system should take into account all HUs posted to the storage bin assigned to the communication
point, even if they have been assigned an active warehouse task for further transport.
This option keeps a CP occupied even if there is already an active warehouse task for further transport.
However, this only lasts as long as the warehouse task does not have the status Started. The Started status
can be set by means of a start message to the PLC15.
However, this option does not take into account incoming HUs. In a situation where it is possible that a
subsequent HU should ask for capacity before the previous HU has been confirmed and posted, you should
not use this option.
15
This can be helpful for the stock removal stations of the aisles: The SC can start a new stock removal as soon as the drop-off space
is empty (and not only when the HU that has been removed has reached its destination). Without this start message, you either risk
blockage (in the worst case, the whole stacker crane is blocked) or you lose time.

V1.1 8/2008
Introduction
Option C: HUs at Communication Point and HUs with Active WTs for the CP
Same as above, but now HUs that are moving towards the CP should also be taken into account. The
fact that a HU is moving towards a CP is determined by there being an active WT with this destination
for it.
This is the most restrictive option: It takes into account all HUs
that are located at the communication point and whose further transportation has not been started yet and
also all that are in the immediately vicinity of the CP (with active warehouse task) or directly approaching it
(with already posted warehouse task).
However, it also does not take into account more distant HUs that are to pass this CP. For this, project-
specific enhancements should be provided if necessary.
5.1.4.4 Communication Points in the Example Warehouse
5.1.4.5 Assigning Storage Bins to Communication Points
Now you have to assign the storage bins to the communication points. As the storage bins are application
data, this is done in the application menu.
Anticipation of Chapter 5.6: For scanner communication points, you also have to specify a packaging material
number enabling you to create pseudo-HUs and divert these if unknown HUs have been registered or if there
are any Noread messages:

V1.1 8/2008
Introduction
5.2 Layout-Oriented Storage Control
“Storage Control” refers to HUs being controlled by the warehouse.
This can be predefined by the process (process-oriented storage control). This is not explained here. The
MFS is only relevant once this control decision has been made.
If the destination to be reached according to the process cannot be reached on a direct route, you can define
intermediate destinations using layout-oriented storage control.
One of the most important tricks is that only exceptions are defined, deviations from the direct route. If the
program cannot find a suitable entry in storage control, it opts for the direct route.16
The procedure is further simplified by the fact that the specifications of the source and the destination can be
differently broad.
Exact (referring to the individual storage bin)
Referring to a group of storage bins
For all bins of one storage type
For transports from/to all storage bins for which no narrower criterion has been specified.
Layout-oriented storage control is based on storage types and storage groups.
16
In the MFS, that is, when the HU is at a communication point, the “End” indicator must be set for this communication point.
(See 5.1.4.2)

V1.1 8/2008
Introduction
The structure is:

From storage type (and, optionally, storage group)
To storage type (and, optionally, storage group)
Via intermediate location.
You can use storage groups to distinguish the storage bins of one storage type with regard to storage control.
Several storage bins can be part of the same storage group.
So, you first define storage groups and then you use them for storage control.
5.2.1 Creating Storage Groups
The only purpose of storage groups is to control the material flow. They are a kind of intermediate layer
between storage types and storage bins and can be defined in more or less detail. In cases where the
storage type is sufficient for differentiation, you can do without storage groups.
In the retrieval system, each communication point must be approached specifically, so you must be able to
address each of these storage bins on the basis of its own storage group. You can usually group the storage
bins of a high rack storage area by aisles, so that one storage group per aisle is sufficient.
Storage Control Groups
RACK 1
LP
LTYP GR
LP
LP
Storage Control Group

RCK1
LP
LP CP01 CP02
LP
LP
Storage Control Group Storage Control Group
RACK 2
CP01 CP02
LP
LP
LP
GR

RCK2
SAP AG 2007, EW M/MFS Example Warehouse / 16
Note: In Chapter 5.1.3, there are some recommendations on assigning names.

V1.1 8/2008
Introduction
These are the storage groups for the prestorage area in the example warehouse:
5.2.2 Specifying Storage Bins Using Storage Groups
Storage groups are characteristics of storage bins. They must be entered in the storage bins. If you need to
change the storage bins of the communication points, you must change them individually. Using mass
change, you can change the storage bins of the high rack storage area on the basis of aisles.

V1.1 8/2008
Introduction
5.2.3 Determining Intermediate Destinations (Storage Control)
The layout-oriented storage control works according to the “from-to-via” principle.
“From” (source) and “to” (destination) are storage types and storage groups, whereas “via” is an individual
storage bin.
You do not have to give an exact specification for the source and destination. The following options are
available for these two specifications:
No specification – entry applies to all storage bins that do not have other entries.
Storage type specification – entry applies to all storage bins of the storage type.
Storage type and storage group specification – entry applies to all storage bins with this storage group.
Example:
All warehouse tasks to storage type 0280 via storage bin 0285-CP00:
All warehouse tasks from storage type 0280 to storage type 9020 via storage bin 0285-CP0817:
5.2.4 Access Strategy Storage Control Table
As you have the option of setting exact specifications differently for source and target, it is important to know
18
the sequence in which the program searches for a suitable entry. This is shown in the following matrix:
17
There is something special about this entry. It involves the pick point. We will come back to this later. For now, this entry is used only
as an example for the specification of source and destination.
18
We will go into the additional option of differentiating between HU type groups and partial or complete stock pick or empty pallets in
warehouse control later.

V1.1 8/2008
Introduction
This matrix is understood as follows19:

1. Access to the table with all criteria. If not marked:
2. Access without regard to whether a full HU, partial quantity (trip to pick point), or an empty pallet is
concerned. If not marked:
3. Access without the “HU type group” criterion. If not marked:
4. And so on.
5.2.5 Storage Control in Example Warehouse

20
Here is a section from the layout-oriented storage control for the example warehouse .
19
The headings “vlber” for the source storage section and “nlber” for destination storage section are wrong. What is meant are source
storage group and destination storage group.
20
This example anticipates the high rack storage area (control of individual aisles).

V1.1 8/2008
Introduction
The intermediate location 0285-CP02 should move from communication point CP01 (identified using storage
group CP01 from its storage bin 0285-CP01) to storage type 0280.
Next, the intermediate destination 0285-CP11 should move from communication point CP02 (again identified
using the storage group of the storage bin assigned to the CP) to one of the storage bins in aisle 1 (storage
group RCK1).
The other entries are discussed in section 6.2 (Resource Management).
5.2.6 Alternative Paths
You can enter alternative intermediate destinations under the same criteria. In this example, the path would
run from CP14 to 9020 via either CP05 (the normal outfeed conveyor) or CP03 (the clarification conveyor):
Note:
In the standard system, load distribution is not implemented between alternative routes. The program would
always choose the first entry (CP05 in the example) and would switch to CP03 only if there is a malfunction or
insufficient capacity. To achieve load distribution, you must program a BAdI:

V1.1 8/2008
Introduction
5.2.7 Controlling a Clarification Bin
In an automated warehouse, the control system must be able to divert an HU to the clarification bin from any
point in the system if necessary. Following the principle of layout-oriented storage control as described
above, setting up the control system might be time-consuming in some circumstances. For this reason, there
is another mechanism available: you simply save the next communication point at each communication point
on the way to the clarification bin.
Example: An HU reported from scanner CP12 using NOREAD is diverted to the clarification bin through the
following entries for the clarification bin.
CP12 CP13
CP13 CP14
CP14 CP03
CP03 CP04
The Clarification bin indicator is set at CP04 (see the following section).
5.2.8 Controlling an External Clarification Bin
Oftentimes you may want to include an external clarification bin that is outside the automatic storage retrieval.
When an HU arrives at the last place of the conveyor line, the system should assign a forklift to take the HU
from the automatic storage retrieval. The actual clarification bin is located in the open space in front of the
equipment.

V1.1 8/2008
Introduction
You can also enter this in the communication point. This example shows the communication point, CP04, that
is to be moved in the case of malfunctions:
The EWM system creates another warehouse task with the specified warehouse process type for the
transport from CP04 to CLEARING. This applies only for HUs for which an exception is set and that are,
therefore, diverted to the clarification bin.
5.3 Warehouse Orders for Controls
To be able to transfer for executing at controls, warehouse tasks must be

placed in queues and
grouped in warehouse orders.
You can use

queue determination criteria and
warehouse order creation rules.
While manual warehouse tasks can, in principle, be carried out by several resources, the following rules apply
in regard to this in MFS:
Each queue can be carried out by only one PLC (MFS must know the PLC to which the warehouse tasks
should be transmitted).
Each warehouse order can contain only one warehouse task. MFS examines each warehouse task
separately and not in relation to the others. Each warehouse task is individually transferred to the PLC.

V1.1 8/2008
Introduction
Warehouse Tasks and Warehouse Orders
Manual Execution Execution by a PLC
Warehouse Task 1 Warehouse Task 1

Warehouse Task 2
Warehouse Task 2
1:1
n:1
Warehouse Order 1
Warehouse Order 2
Warehouse Order 1
Queue 1 Queue 1
n:m n:1
Resource 1
Resource 2 PLC Resource
Therefore, (at least) one queue must be defined for each PLC21, and criteria must be set to control the
warehouse tasks in the queues and to create warehouse orders:
Warehouse Task Execution
CP CP
Storage Bin Storage Bin
Warehouse Task
Queue Determination Criteria Order Creation Rule
Queue Warehouse Order
is communicated to executes
PLC optional: Resource
21
Advance: actually for each resource. In this context, conveyor lines are a special case. They are operated without resources. One
queue must be defined for the conveyor line orders of the PLC. If a transfer car is also controlled through the PLC and is mapped as a
resource, you need a second queue for the transfer car. The warehouse tasks of this queue are then also transmitted through this PLC.

V1.1 8/2008
Introduction
5.3.1 Queue Determination
Queue Determination Criteria
Queue Determination
Source Storage Bin Destination Storage Bin
Warehouse Task
Warehouse Process
Bin Access Type Activity MFSI
Type
from to
Activity Area Queue Determination Criteria Activity Area
combines tasks
Queue Warehouese Order
MFS 1:1
is communicated to
executes
PLC Resource
Warehouse Order Creation Criteria. Each warehouse order contains only one warehouse task. The sort
sequence of the storage bins for each activity area and activity must be available for data-technical reasons.
Warehouse Order Creation
From Storage Bin To Storage Bin
Warehouse Task Warehouse Process Type Activity MFSI
To Activity
From Activity Area
Area
Sort Sequence Sort Sequence

Act. Area / Activity
Order Creation Rule Act. Area / Activity
combines tasks
Queue Warehouse Order
MFS 1:1
is communicated to executes
PLC Resource
for technical reason

V1.1 8/2008
Introduction
5.3.2 Create Queue for PLC
First, define a queue for the warehouse orders of our PLC.
Note: there are two customizing activities for defining queues. One under Cross-Process Settings/Resource
Management. We will need this later on.
Now define a queue that is carried out by a PLC. Select:
Creating a queue for PLC tasks and assigning the PLC:
Select operating environment 4 for conveyor lines. If the warehouse tasks of this queue are carried out by
vehicles (such as stacker cranes or transfer cars) and SAP EWM should run these vehicles as separate
objects, operating environment 5 must be set. See chapter 6.
This is the crucial point where the assignment of warehouse tasks for controls is determined. Not the
affiliation of communication points to controls and, as we will later see, not the settings for the resources.
Furthermore, the “only” thing still to do is to make sure that the storage tasks end up in this queue.
This means:
A queue can be carried out only by a PLC.
This is determined by customizing.
One PLC can carry out several queues.

V1.1 8/2008
Introduction
5.3.3 Warehouse Order Creation Rule
MFS warehouse orders can each contain only one warehouse task.
Define a warehouse order creation rule for warehouse orders that have only one warehouse task:
The limit is defined in a separate activity:

V1.1 8/2008
Introduction
5.3.4 MFS Activity
SAP recommends using a separate activity for MFS tasks. You can switch off the functionality of Labor
Management for this activity, which will improve performance in MFS. Labor Management is intended for
manual resources. This activity is needed as storage bins must be sorted based on activities. (See 5.3.8)

V1.1 8/2008
Introduction
5.3.5 MFS Warehouse Process Types
The activity and warehouse order creation rule are selected in the warehouse process type:

V1.1 8/2008
Introduction
If you need other warehouse process types, they must also be set in the same way.
5.3.6 Activity Areas
Warehouse order creation and queue assignment are based on activity areas.
They define activity areas and assign storage bins to these activity areas. You also need to clarify the source-
destination relationships that you have in the warehouse and the controls from which each of these should be
operated. Here is an example:

V1.1 8/2008
Introduction
Activity Areas
Activity Area Activity Area Activity Area

Activity Area RCK1 RCK2 RCK3
GR
Activity Area CONV1

Activity Area
GI
Orders from activity area GR to CONV1 ate to be carried out by forklift, orders from CONV to CONV by the
conveyor PLC, orders from CONV1 to RCK1 or vice versa by the PLC that controls the stacker crane, and so
on22.
In the following, you will see a possibility to define the activity areas if you do not need make a distinction in
regard to the aisles of a high rack storage area. Activity area 0286 is the area for the clarification bin located
outside of the automatic storage retrieval that is moved by the forklift.
22
The advanced control from the putaway station to the stock removal station (would go to the conveyor PLC instead of the SC
according to these criteria) can be solved using the bin access type (see section 6).

V1.1 8/2008
Introduction
5.3.7 Assignment of Storage Bins to Activity Areas
Now you need to assign the storage bins to these activity areas. Since we have a separate storage type for
the storage bins operated by the PLC, assigning the bins is simple:
5.3.8 Sorting Storage Bins
We are still missing a step for preparing the warehouse order creation.
Warehouse orders group together warehouse tasks according to certain criteria to be able to transfer the
tasks to resources that execute them. The easiest way to picture this is to think of multiple processing of a
picker that should be sent to the individual storage bins in a logical order. The warehouse tasks must also be
sorted based on the picker’s activity, picking in multiple processing. You can achieve this by sorting the
storage bins of an activity area based on activity.
In MFS, every warehouse task will now be handled individually and transferred to resources/PLC to be
executed. For data-technical reasons, however, a warehouse order must be created for the task. The order
contains only one warehouse task. Warehouse order creation requires that storage bins in the activity area
are sorted based on activity.

V1.1 8/2008
Introduction
This can be done by

determining the criteria that the storage bins must meet to belong to the activity areas (which already
happened)
determining the sort sequence for it (this is still open) and
then sorting the storage bins (this is also still open).
Both of the open points are described in the following:
5.3.8.1 Determining Sort Sequence
Since sorting does not play a role for MFS activities, you do not have to enter sort criteria. All you need is a
criteria record for the activity area and activity.
5.3.8.2 Sorting Storage Bins
After you have stored all values for sorting, you can now sort the storage bins. During this process, an
activity-specific index for the affected storage bins is created.
Perform the following steps in the application menu:

V1.1 8/2008
Introduction
Attention: You must repeat this step if new storage bins are added.
5.3.9 Queue Determination
Based on activity areas, you can now set the queue in which the warehouse tasks should be placed. To do
so, define queue determination criteria and, in a control table, set the sequence in which these criteria should
be applied.

V1.1 8/2008
Introduction
5.3.9.1 Queue Determination Criteria
Setting the determination criteria for the PLC of the prestorage area is simple: all warehouse tasks that are
started from activity area 0285 and should be sent to activity area 0285 should be placed in queue
CONSYS1.
Queue determination criteria for queue CONSYS1:
Queue determination can, if necessary, be controlled with greater precision using the storage bin access type
of the source location, warehouse process type, and activity of the warehouse task. We will come back to this
later.
5.3.9.2 Queue Access Sequence
There are multiple steps for accessing the queue determination table23.
In this example, the program searches using the warehouse process type of the warehouse task. This is
useful in connection with automatic storage retrieval if you must make a posting change for the HUs in
automatic storage retrieval without a PLC order. When you create the storage task, use another warehouse
process type and control it into another queue:
If there is not an entry for the warehouse process type, the program searches using source activity area,
destination activity area, storage bin access type, and so on.
23
The heading “Stor. Bin” is short for “Storage Bin Access Type”.

V1.1 8/2008
Introduction
5.4 Communication from Transfer Orders using PLC
Warehouse tasks are now divided into smaller stages and other warehouse tasks are created for these
individual steps. In addition, these warehouse tasks are placed in PLC-specific queues. In this example, this
is PLC queue CONSYS1.
Now these warehouse tasks and the relevant confirmations must be transmitted using the PLC. For this, you
will need appropriate telegram structures and message types. It also may be the case that the PLC uses
other names for the communication points than the one you created in SAP EWM (such as, for reasons of
comprehensibility).
We will start with the last point.
5.4.1 PLC Communication Point Descriptions
In the PLC telegram, the EWM system uses the storage bin names for addressing source and destination. If
the storage bin names were selected differently from what the PLC expected, you may be able to use a
conversion table.
To do so, you must activate mapping in PLC customizing and then maintain the conversion table.
5.4.1.1 Activating Mapping for Storage Bin Descriptions
In customizing, go to …
Set the Mapping indicator:
5.4.1.2 Maintaining Mapping Table
SAP provides a tool for creating entries in the conversion table. The tool derives the name the PLC uses to
recognize the storage bin from the storage bin name. Define a rule for this according to the following
procedure:
Use position “x” of the EWM storage bin name for position “y” of the PLC storage bin name.

V1.1 8/2008
Introduction
If this rule is not sufficient, you can use the following BAdI:
If you cannot find a rule (or if all entries cannot be generated with it), you must go to the following table in
application menu ...
… and manually maintain it:

V1.1 8/2008
Introduction
5.4.2 PLC Warehouse Task
The telegram structure defined in section 4.1.1.2 already contains the necessary fields for transfer orders and
transfer confirmations. The relevant telegram types are still missing.
You need:
Warehouse task (EWM to PLC)
Warehouse task confirmation (PLC to EWM)24
If necessary, cancellation request for warehouse task (EWM to PLC)
Also if necessary, positive/negative cancellation reply (PLC to EWM)
When the warehouse task is sent to the PLC, the EWM system pulls the telegram type (telegram ID “WT”)
and the telegram structure to be used by using telegram category E (warehouse task). The telegram is sent
to the PLC.
5.4.3 PLC Warehouse Task Confirmation
After the warehouse task has been executed, the PLC sends a warehouse task confirmation. The function
module responsible for processing is determined through the telegram type (telegram ID “WTCO”) and
possibly the communication point type.
This occurs according to the following principle:
24
This is not to be confused with the confirmation telegram, “received telegram”, which serves only to ensure communication.
(See Chapter 3.1)

V1.1 8/2008
Introduction
Customizing Action „Task confirmation“
Confirm task CP01-CP02

Create new task CP02 – CP11
WTCO HU 1 from CP01 to CP02 WT HU1 from CP02 to CP11
HU 1 arrives at CP02 PLC
You must follow the steps below to make the setting:
5.4.3.1 MFS Actions
Define MFS actions …
… that you link to the ABAP function modules.
Here, we are talking about a significant flexibility factor in the system: user-specific function modules
can be added in a simply way.
The modules displayed above have the following functions:

01: Process cancellation message for WT (reply to a cancellation request)

V1.1 8/2008
Introduction
02: Process execution confirmation for WT

03: HU has left the communication point
04: Buffer space became empty, initiate refilling
05: ID point registration (starting point), this means storage bin allocation
06: Process PLC status message (communication point, segment, segment group, resource)
5.4.3.2 Find MFS Actions
Next, link these keys to telegram types. You can also differentiate according to communication point type.
In this example, telegram type WTCO should trigger action 02 independent of the communication point type.
This function module should also process a scanner telegram for an SP type communication point.
5.4.4 PLC Warehouse Task Confirmation with Error
Furthermore, the PLC telegram can contain an error code to which you should respond.
You define exceptions that should be triggered as a result of certain PLC error codes.
In the example, “PLC temporarily refuses the order” (for example, because the order buffer was full, the
device was already busy, and so on):
5.4.4.1 Defining Exceptions

V1.1 8/2008
Introduction
The internal process code REDE controls processing after an exception occurs. In this case, the warehouse
task is reset to status Y Relevant for subsystem and resent at the next opportunity. See the exception
overview in the appendix, section 7.2.
5.4.4.2 Linking Exceptions to PLC Error Codes
Once the exception is defined, you can link it to a PLC error code:
For example, you determine that exception MDNY should be triggered if the PLC reports error code “90” in a
warehouse task confirmation.
Note the access sequence for the preceding table. You can set the criteria that the EWM system should
preferably use to determine the PLC exception.
In this example, the criteria are set in such a way that if the meaning of an error code is determined in the
PLC telegram, the interface type of the PLC reporting the error, the type of telegram that contains the error,
the error code itself, and the category of the object on which the telegram is based should be taken into
account. Lastly, if you add an entry without the Telegram error indicator, all other (possibly undefined) error
codes with a common exception are intercepted.
If there is no entry available, the error code applies independent of the object type.

V1.1 8/2008
Introduction
If you use both entries together, exception MDNY is triggered if error “90” occurs in a telegram of type WTCO
of a PLC that uses interface type “F”.
5.4.5 Canceling a PLC Warehouse Task
Warehouse tasks sent to the PLC cannot be cancelled in SAP EWM as they are. The EWM system sends a
cancellation request to the PLC and the EWM system does not cancel the task until the request is granted.
The HU stays posted to its current storage bin, the source of the cancelled task. An inactive warehouse task
that may possibly exist must be cancelled separately if necessary. Since it is not transferred to the PLC, the
task is cancelled without consulting the PLC.
If you do not cancel the inactive warehouse task, a new, active warehouse task is immediately created
(independent of the state and utilization of the affected resources) when the active WT is cancelled.
Warehouse Task Cancellation
Whs Supervisor EWM PLC
Cancel Whs Task

Cancel request
Started?
Cancel response
Cancellation
Refresh Window
Result
A Warehouse Tasks which has been communicated to the PLC

is not cancelled directly.
The PLC is asked to cancel the task before.
And only if cancelled by the PLC the task is cancelled by EWM.
(Acknowledgment telegrams are not shown)
The current status and success of this transaction can be seen by the Subsystem indicator (SUB ID) and by
the WT status in the warehouse management monitor.

V1.1 8/2008
Introduction
1 = Cancellation was requested by the control station, telegram still not sent to PLC
2 = Cancellation requested at PLC
The WT status of a cancelled order is A:
If the PLC refuses the cancellation, the SUB ID is reset to “X”.
5.5 Capacity and Status Management for Conveyor Lines
A fundamental task of the material flow system is taking into consideration capacity bottlenecks and
malfunctions. SAP EWM offers functions for setting capacity limits, for status tracking if malfunctions occur,
and for restarting when blocks are removed.
5.5.1 Setting Capacity Limits
You can limit the capacity for conveyor lines through communication points and segments.
5.5.1.1 Capacity Limits to Communication Points
As previously described in section 5.1.4, you can limit the capacity of communication points. Limitation
always relates to the number of HUs. The system differentiates between different HU types (such as long and
short containers).
You can also set whether incoming or outgoing HUs should already or still be counted for the assignment
(see 5.1.4.3).
In the standard system, the EWM system always checks only the capacity of the next communication point –
see below – and of the defined segment, if necessary. Capacity restrictions further ahead are not taken into
account. For this case, you need to implement a BAdI, if necessary.

V1.1 8/2008
Introduction
5.5.1.2 Capacity Limits to Conveyor Segments
A second option for capacity restrictions are conveyor segments. A conveyor segment forms the leg between
two communication points. You need conveyor segments only if you
would like to manage their status (ready/malfunction), or
their capacity is limited and you cannot or do not want to control this using the communication points
involved.
Often, managing the status and capacity on the communication points is sufficient. In this case, you do not
need conveyor segments at all.
Definition of Conveyor Segments
Example: Segment CP11-CP12 should include only 2 HUs:
You assign the segment in the layout-oriented storage control to the respective transfer step:
Only if the segment is entered here, is its capacity and availability taken into account when warehouse tasks
are created or sent.
5.5.2 System Behavior for Capacity Bottlenecks
If capacity bottlenecks occur, various reactions are appropriate depending on the situation:
Create warehouse task, but do not send it until the capacity is available again.
Do not create a warehouse task at the moment. Do not create a warehouse task until the capacity is
available again and the current relationships are taken into account (such as, another warehouse task
may be more urgent).
Find an alternative route.

V1.1 8/2008
Introduction
SAP EWM supports this through configuration options.
You influence this behavior as follows:

Definition of an exception for capacity bottlenecks, such as MCAP.
Internal process code NSND, if the WT was created, but should not be sent.
Internal process code STAY, if the WT should not be created.
For STAY: definition of alternative routes in the layout-oriented storage control, if alternative routes should
be used for a capacity bottleneck or malfunction.
For STAY and alternative routes: programming a BAdI, if the current load situation should be taken into
account when the alternative route is selected (see 5.2.6).25
Entry of exception MCAP at communication point or segment.
Note (Anticipation of Resources)
If the first stage from the high rack storage area is involved, without an alternative the internal process code
STAY has the consequence that the resource does not know anything about the HU’s transportation need.
No trigger is initiated that would automatically create the WT. An HU stopped with the process code STAY will
be further transported only if the HU is on a communication point for which a trigger is defined (see 5.5.4).
The HU will not be further transported if it is on a storage bin that is not a communication point.
Define Exception
The exceptions must be defined in the context “communication point” or “segment” and for the Background
processing operating environment.
Define exception:
Context MF5 – Background processing environment:
Internal process code “create but do not send WT”:
25
This also applies if alternative routes should be used without a capacity bottleneck/malfunction.

V1.1 8/2008
Introduction
5.5.3 Malfunction
The EWM system manages the availability status of communication points and segments in two
characteristics and separately manages them based on two actors.
Characteristic status:
Available
Not available
Actors:
PLC
User (control station)
Logically, what is available is only that which was not blocked by either actors, and a notice of readiness of an
actor does not change the status of the other.
Non-availability has exactly the same effect as non-capacity; meaning that the exception code stored at the
communication point controls the reaction.
5.5.3.1 User Lock
The user lock is set by selecting an exception intended for this in the warehouse management monitor.
The exception must be made available in customizing.

V1.1 8/2008
Introduction
Definition of exception MBLK for various contexts:
You must define the exception for all affected contexts and for each of the operating environments. The
context controls the type of object to which the exception applies26.
If the exception is defined in the Desktop operating environment, it can be set in the warehouse management
monitor. The Background operating environment must be added so that if the exception occurs, the program
finds the internal process code and, if necessary, creates an alert.
Optional: trigger creating a warning in the alert monitor:
26
See appendix 7.2.

V1.1 8/2008
Introduction
5.5.3.2 Status Telegram
To be able to receive malfunction reports from the PLC, a telegram type must be defined for it. The EWM
system can also actively request the status of a communication point or segment for each telegram at the PLC:
Therefore, define 2 telegram types:

One for the status request from SAP EWM to PLC and
One for the status message from PLC to SAP EWM
Then you determine the action that should be called when a telegram with type “status message” is received ...
… and assign the action module.
Lastly, you need to create the exception code that the PLC uses to report the “malfunction” status and define
an exception. You can do this in the same way as you did for the MBLK exception in the previous section.
However, you need only the Background operating environment (A0) as the exception is set through a PLC
telegram and not by an operator.
If the PLC error code contains only

the number “0”, or
a blank space, or
an underscore, “_”, or
a combination of these characters,
the EWM system interprets the telegram as “object is ready”.

V1.1 8/2008
Introduction
5.5.3.3 Conveyor Segment Groups
You can use segment groups to reduce the number of status messages. The PLC reports an entire area as
“malfunction” or “ready” in a single status telegram. For example, “Conveying to/from aisle 1”.
You define segments for the legs between the affected communication points (in the example, the putaway
conveyor and stock removal conveyor in aisle 1 and also a segment for leading through from putaway station
to stock removal station) and include these segments in a group. The PLC status telegram switches the
status of all affected segments27.
Conveyor Segment Group Type
First define a group type, for example, status group.
Conveyor Segment Group
Then determine a segment group for this type, such as in the example.
Group Conveyor Segments
Then assign the individual segments to groups.
5.5.4 Blockage Clearing
HUs that cannot be given further instruction for capacity reasons or due to malfunctions must be triggered
when the obstruction is no longer present. These availability events can be when the:
Communication point or segment/resource malfunction is removed (overall status changes to “available”)
Communication point is relieved because an outgoing HU reached the next target.
Communication point is relieved because an empty location message or an order-start telegram arrived.
Additional availability events that are not automatically evaluated in the standard system are when:
A warehouse task for an HU that wanted to start this communication point is cancelled.
An HU is manually posted away (per the control station order) by a communication point.
27
In the telegram, the field for the segment group from the structure /SCWM/S_MFS_TELETOTAL must be included (see section 4.1.1.1).

V1.1 8/2008
Introduction
During these availability events a customizing table is evaluated in which you store the trigger: MFS objects
that should be triggered during these events to check whether warehouse tasks can be sent. In the following
example, the queue for the transfer car is started when communication point CP11 is discharged. In this
queue, there is an order for HU 2 that previously could not be carried out28:
Customizing Triggers
If CP11 gets availabe again

TCAR will be triggered:
HU 1

Availability events:
•Location left (HU started)
•Task confirmed (HU arrived at next destination) TCAR
•Equipment fault reset

HU 2
CP00 CP04 CP06 CP08
CP09
The following are considered as objects:

Communication Points
MFS queues
Setting communication point dependencies in customizing under:
28
Note: the requirement is that you have stored an exception in CP11 for the case of capacity bottlenecks that is be configured in such a
way that each follow-up WT is stored (NSND). Only then is the transportation need of HU 2 known in the TCAR queue. If you use internal
process code STAY, point CP10 (where HU 2 is in the example) must be included in the communication point dependencies. This
duplicates the trigger events when the transfer car is used.

V1.1 8/2008
Introduction
Example:
During an availability event for communication point CP02, CP01 should be informed.
During an availability event for CP03, communication point CP01 should be informed as well as the
transfer car.
5.5.5 Empty Location Messages
A communication point becomes available when one of the events described in section 5.5.4 occurs. You
must define a telegram for the empty location message of a communication point.
Create telegram ID:
Assign action:
A warehouse task that started from a communication point for which a LOC_EMPTY telegram applies
receives SUB ID = W and is no longer counted in the schedule of a communication point from which it
started.

V1.1 8/2008
Introduction
5.6 Scanner for Material Flow Tracking
5.6.1 Scanner Telegram
To distinguish other telegram types, you can use a user-defined telegram type for scanner telegrams. This
example uses telegram type SCAN. This telegram type can later be used for the automatic ID point (see
section 5.7).
5.6.2 Scanner Telegram Processing
Scanners that are used for material flow tracking (meaning they do not have a special function, such as the
ID point) can be processed in SAP EWM using the usual warehouse task confirmation function.
This module contains the following functions:

1. It implicitly reposts an HU that was expected at a different location and tries to forward it from this
new location to the original destination.
2. It creates a new, empty HU for an unknown HU and routes it to the clarification bin.
3. It reacts to the NOREAD exception along with 2.
Prerequisite for 1)
There is an entry in the layout-oriented storage control for source and destination.
Or the scanner communication point is marked as an end point. The inactive WT is activated.
Or the scanner communication point is marked as a clarification bin. The HU stays where it is.
Prerequisite for 2)
In the communication point (application data), a material number for the packaging material is maintained.
In the communication point (customizing), the next communication point is maintained in the direction of
the clarification bin.
Prerequisite for 3)
The error code reported by the PLC is linked to a EWM exception.
Otherwise the prerequisites from point 2 would apply.

V1.1 8/2008
Introduction
5.6.3 Exceptions – Example NOREAD
Link PLC Error Code to Exception
Define Exception NOREAD
Assign Internal Process Code for Subsequent Processing
If no process code is assigned, the HU stays where it is without a warehouse task.
Create Alert

V1.1 8/2008
Introduction
5.7 Automatic ID Point
The communication point where the storage bin allocation for the HUs to be stocked takes place is labeled as
an “ID point”. The HUs run a contour control. HUs containing errors are diverted.
For putaways with an ID point, the first warehouse task is created only up to the first ID point. This task ends
when it reaches the ID point, and a new warehouse task to the final storage bin is created.
The following sections contain further information on the necessary settings concerning the ID point.
5.7.1 Storage Control with ID Point
As of SAP EWM 5.1, you can set an ID point using the layout-oriented storage control. In manual
warehouses, a separate storage type is no longer required for the ID point. In automated warehouses, SAP
recommends the previous way. The ID point is controlled by an entry of the following type:
Row 1 says that all movements to storage type 0280 (high rack storage area) that do not have a special entry
for their source should be controlled using intermediate location 0285-CP00, which serves as an ID point.
The program changes the destination of the warehouse task to the location entered here as the intermediate
location. With the ID point, this “intermediate location” is also used as the destination point. (The previous
destination, a place in the final storage type, is overwritten.)
Next, the program checks whether there is another entry for this new specification for the destination, using
the destination data of the ID point. If there is, the warehouse task is set to the “inactive” ID point, and another
active WT for the intermediate destination (that preceded the ID point) is created.
In the example warehouse, this is not the case, and the WT 9010 – CP00, for example, could have been
transferred to a forklift that picks up the HU from the goods receipt and places it on the automatic storage
retrieval.
When the intermediate destination is “CP00” and not “CP01”,

the starting point is displayed to the forklift operator as the destination and
the HU confirmed by the operator is not yet regarded as arrived at CP01. Arrival at CP01 (the location of
the storage bin allocation and therefore the actual ID point) should first be posted by the PLC scanner
telegram.
5.7.2 ID Point Telegram
You can use the SCAN telegram type introduced in section 5.6.1. Expand the general telegram structure if
29
you want to receive other data.
29
Uniform telegram structures make it easier to read the telegram, and the costs involving data volume and performance are usually
negligible.

V1.1 8/2008
Introduction
5.7.3 ID Point Telegram Processing
You can process the ID point telegram by using a user-defined function module. The module is controlled as
follows:
Configurable Action Modules
Transport order HU1 from CP01 to CP02
SCAN CP01 HU1

TA HU1 CP01 CP02
Scanner message HU1 to communication point CP01 PLC
SAP AG 2007, SAP EWM 5.1

Material Flow System
/ 26
Legend:
Lokation leer Telegramm (Kategorie I) Location Empty Telegram (Category I)
Nachschub anstossen (Kategorie I) Trigger Replenishment (Category I)
I-Punkt Telegramm (Kategorie J) ID Point Telegram (Category J)
Status Telegramm (Kategorie C) Status Telegram (Category C)
Lageraufgabe quittieren (Kategorie G) Confirm Warehouse Task (Category G)
Lageraufgabe stornieren (Kategorie H) Cancel Warehouse Task (Category H)
The module includes:

Canceling active and passive warehouse tasks that may already/still exist for the HU
Changing the posting of the HU to the ID point storage bin
Resetting an error that may have been entered at the HU (such as, from a previous diversion)
Evaluating the exception from the telegram, possibly setting error at the HU
NOREAD: creating a new, empty HU using the packaging material stored at the communication point
Unknown HU: creating a new, empty HU using the packaging material stored at the communication point,
if the HU is within the permissible HU number range, use the HU number reported by the PLC, otherwise
do the same as with NOREAD
If there is no error, calling the putaway strategy
Further treatment for errors: according to customizing of the exception
5.7.4 Consideration of System Status and Capacity Utilization for Putaway Strategy
… using BAdI:

V1.1 8/2008
Introduction

V1.1 8/2008
Introduction
5.7.5 Equal Distribution in Aisles
In the standard system, this is intended only as a cross-line stock putaway: the free storage bins are cross-
sorted related to the putaway. In the example warehouse, this means that the foremost locations of the lowest
level in aisle 2 are assigned after the foremost locations of the lowest level in aisle 1 (left shelf, right shelf).
The next row is not assigned until the foremost locations of all aisles are full, and so on.
In the standard system, equal distribution in the aisles is not carried out with regard to the material.
5.7.6 Error on ID Point
In addition to the errors described in section 5.6 (such as NOREAD), the following errors might occur at the
ID point:
Incorrect contours
Excessive weight
Foot error
See section 5.6 for configuration of the follow-on action for these errors.
5.7.7 Additional Options
Verify Weight
… using BAdI:
Transfer Pallet Type
If the PLC reports a new HU type in the ID point telegram, it is copied.
5.8 Transfer Cars
Automated vehicles, that is facilities using conveyor technology that move to the source of a warehouse task,
take a load, and drop it of at the destination, can be mapped in SAP EWM as resources. The following
options are available for SAP EWM:
Manage the capacity of this conveyor
Assign the conveyor in interleaving between putaway and stock removal (only for stacker cranes)
Control the conveyor using “pull-push orders”
Typical resources in this sense are:

Stacker cranes
Transfer cars
Connecting stacker cranes is described in unit 6.

V1.1 8/2008
Introduction
Basically, you have the option of telling SAP EWM to ignore a transfer car. Controlling its movements is left
up to the PLC. The EWM system treats the car like a network of intersection-free conveyor segments
between the pick-up and drop-off points that the car serves. This type of connection is no different than that of
conveyor lines. The connections do not have to be mapped.
If you want to take into account the status and capacity of a transfer car in SAP EWM, map the transfer car as
a resource.
Note: In the standard SAP EWM, there is not an option for optimizing the path of the transfer car. The orders
are transferred to the PLC in order of their priority and creation (LSD – latest start date).
Here you need:

A queue for the transfer car with matching queue determination criteria
A resource type
A resource
5.8.1 Queue for TCAR
Creating a queue for the warehouse tasks of the transfer car:
The operating environment is now MFS with Resource Management.
This queue can be transferred through the same PLC as the queue that receives the warehouse tasks for the
conveyor lines.
5.8.2 Queue Determination Criteria
The bin access type is a simple possibility for separately controlling warehouse tasks for the conveyor lines
and for the transfer cars.
The storage bins of the communication points, where the transfer car should make the pick up, are labeled
with their own bin access type, and this access type is used in the queue determination criteria.
Bin access type at the storage bin:

V1.1 8/2008
Introduction
It is important that the access sequence for this determination criteria table takes into account the bin access
type at the prominent location (row 2: third indicator from the left):

V1.1 8/2008
Introduction
5.8.3 Resource Type
The resource type is set up in customizing.
Interleaving: should not be activated for transfer cars.

Maximum number of telegrams: maximum number of orders that may be transferred to the TCAR.
Type of commissioning: the following options are available.
- A combined pull-push order from SAP EWM to PLC

- B and A, however, the TCAR confirms the order start during HU pick-up (order source is free again)
- Two-step commissioning: pull-order, pull-confirmation, push-order, push-confirmation
5.8.4 Resource
You must create a resource for the resource type in the application menu.
Determine the location to which the EWM system can drop off a picked-up HU in the case of an error. In this
example, this is the clarification conveyor.

V1.1 8/2008
Introduction
5.8.5 Telegram Communication with Resources
An important note:
The EWM and control generally communicate through the HU number. The data of a telegram must contain
at least:
HU number
Source bin
Destination bin
If resources are in use, you can use two-step commissioning (“pull-push” orders). The PLC should also follow
the procedure below so that the communication between SAP EWM and the PLC works.
Pull-order and pull-confirmation:

HU number
Resource name
Source bin
(Destination bin must be empty)
Push-order and push-confirmation:

HU number
Resource name
(Source bin must be empty)
Destination bin
If the telegram structure contains the CP field (current communication point), make sure that the field is not
filled in for resource orders.

V1.1 8/2008
Introduction
6 Connecting an Automated High Rack Storage Area
In the example warehouse, the three stacker cranes now need to be connected to SAP EWM as well.
The following steps are necessary to do this:
Storage bins of the high rack storage area aisles must be created and added to the layout-oriented
storage control (3 storage groups)
Three activity areas are needed for the stacker cranes
Stacker cranes must be mapped as resources
The PLC and communication channels must be created
Queues are needed for the warehouse tasks of the stacker cranes and the appropriate determination
criteria
6.1 Set Up Storage Bins in High Rack Storage Area
6.1.1 Storage Type
The high rack storage area must have storage type role J.

V1.1 8/2008
Introduction
6.1.2 Storage Bin Types
(… Special bin types are not necessary for MFS. Requests, if required, result only from the storage, as is so
for manual warehouses …)
6.1.3 Bin Access Types
You can affect queue determination through bin access types. SAP recommends using a separate bin access
type for each aisle:
6.1.4 Designator for Storage Bin Structures
You can freely assign designators.
6.1.5 Create Storage Bin Generation Procedure
Follow the same procedure as you would for manual warehouses.30
You may also have to add an indicator for the shelf side. The depth (“D”, last place of coordinates) is intended
for this.
The sample high rack storage area has 3 aisles. Each aisle has 5 columns (“SS”), 3 levels (“LL”), and 5 bins
for each field. In the aisles, there is a left (“D” =1) and right (“D” = 2) for each of these bins.
30
For storage control, it is important that the storage bins belong to a storage group (aisle 1, aisle 2, …). When you create a procedure
for each aisle, you can enter the storage group right away. However, it is relatively easy to do at a later time from the application menu
(“Mass change”).

V1.1 8/2008
Introduction
6.1.6 Warehouse Bin Status Profile
If there is not a status profile for the storage bins, you must create one:

V1.1 8/2008
Introduction
Define status values:
Assign allowed object type:

V1.1 8/2008
Introduction
6.1.7 Creating Storage Bins in High Rack Storage Area
Select a profile:
Then you can generate the storage bins.
6.1.8 Sorting Storage Bins
Preliminary Note
SAP EWM gives you the possibility to direct resources to storage bins on optimized routes. For this purpose,
warehouse tasks (WTs) are bundled into warehouse orders (WOs). “Sorting” controls the order in which the
WTs within a WO should be processed.
In some circumstances depending on the type of activity (putaway, stock removal, inventory and so on), you
may want to use a different sequence for processing the WTs of a WO. For this reason, you always need to
sort the storage bins based on activities.
Sort MFS-Operated Storage Bins
In the MFS environment, WTs are not normally bundled. Each WT stands for itself and can be independently
carried out. Therefore, sorting does not play a role. However, for data-technical reasons, such a sequence
must be stored at the storage bins.

V1.1 8/2008
Introduction
Perform this activity for both storage types. Attention: You have to repeat these steps if new storage bins are
created.
6.2 Layout-Oriented Storage Control
Storage control must be extended to incorporate the paths in the three aisles.
For this, you need three additional storage groups:
Storage groups are used in the storage control. In the following image, the entries from ID point CP01 are
marked in aisle 131:
31
The meaning of the last row is explained in the following section 6.3.

V1.1 8/2008
Introduction
6.3 Validity of Last Stage (Putaways and Stock Transfers)
Generally, the storage control does not need an entry for the last stage. If no other entry is found in the
storage control, the program assumes that it is dealing with the last stage and activates the passive WT. You
may not want this in an automated warehouse. Just because there is not an entry in the storage control, does
not mean that the resulting order is necessarily useful for the affected PLC. For example, an HU could be
taken to the wrong aisle due to an offset on the automatic storage retrieval. There is no entry in customizing
of the storage control for the stage from the putaway location to the actual destination (a storage bin in a
different aisle). Therefore, an unnecessary warehouse order would be sent to the PLC (depending on queue
determination rules).
There are two precautionary measures in SAP EWM.

You can set the end indicator in the implementation guide (IMG) for SAP EWM at the communication
point. If you do not set this indicator and there is no another entry in the storage control, the program
assumes that there is a customizing error and cancels processing.
You do not need to define the intermediate destination in a storage control entry. In this case, do not set
the End indicator at the communication point; this will cause the program to search for an entry in the
storage control. Only if there is a suitable entry (that is, one with the correct aisle), does the program
activate the inactive warehouse task as there is no intermediate location specified. In this way, an order
for a stage in the wrong aisle is prevented.
You can also do this to control stock transfers within an aisle using customizing.
Example: last communication point before the destination (putaway aisle 1):

V1.1 8/2008
Introduction
Storage control:
In interaction with the setting at communication point CP12, this entry in the storage control makes sure that
only HUs with the destination “aisle 1” are put away by CP12.
6.4 Stacker Cranes
You need to follow the steps below for setting up a stacker crane as a resource.
Create PLC and communication channel (see section 4.1)
Create queue for warehouse tasks of the resource
Set up queue determination criteria
Create Resource Type
Create resource
6.4.1 Creating Queues and Queue Determination Criteria
Create queues:
Set up queue determination:

V1.1 8/2008
Introduction
The first and last three rows make sure that all orders that have one of the “RCKx” activity areas as source or
destination end up in the correct queue.
The three marked entries in the middle also control the stock transfer orders from putaway station to stock
removal station of a stacker crane in the appropriate stacker crane queue. The storage bin of the relevant
putaway station must have bin access type RCKx.
6.4.2 Creating a Resource Type
Provide resource types in customizing.
You need several resource types only if the resources to be controlled with regard to the criteria set here are
different: interleaving yes/no, size of order buffer, step sequence of telegram communication relating to an
order.
Interleaving
If interleaving is activated, SAP EWM alternately assigns the resource a putaway and a stock removal in each
case. Each putaway is followed by a stock removal (when available and executable). The opposite also
applies.
Interleaving overlays the order priority (coming from the warehouse process type). This takes into account all
WTs
whose earliest start date has been reached,
whose destination is undisturbed and has free capacity,
whose latest classified start date is the most urgent of those in the queue.
A latest classified start date is a rounding of the “latest start date” (LSD). You can control rounding for the
LSD using the “mode” (see 6.4.4).
Example: see section 3.5.
Maximum Number of Telegrams
Size of the PLC order buffer in relation to this resource type.

V1.1 8/2008
Introduction
Resource WT Confirmation
The following is a list of the WT confirmation options available:
A One-Step Confirmation (full movement) this is the standard case. The resource receives an order with
the task from source to destination and confirms the order after it is completed.
B Two-Step Confirmation (full movement with start message): the resource receives an order with the task
from source to destination, confirms the order at the source, and then confirms it at the destination.
Two-Step Commissioning (half movement): the resource confirms that an HU has been picked up and
waits for a target that it will also confirm after completion (also called “pull-push orders”).
6.4.3 Creating Resources
Create the resources in the master data:
Here you can also assign the order queues that should be processed by the relevant resource.
The error bin is the storage bin that should be used if the error Bin occupied occurs (the BAdI can override
32
this) .
6.4.4 Maintaining Mode for LSD Rounding
Order priority plays a big role for resources. It is determined by the warehouse process type. The latest start
date is even more important. Each order receives a latest start date (which usually comes from the delivery).
When selecting the next order for a resource, you should pay attention to a certain pool of orders of equal
importance to select the one among them that means the smallest empty route for the resource. For this
reason, classify the latest start date. You can set how much you want to round to be dependent on the
activity.
32
See section 6.4.5.

V1.1 8/2008
Introduction
First define a mode:
The latest start date should be rounded to the hour (for example, 15:15 to 15:00).
Then assign the mode to the activity.
6.4.5 Error Bin Occupied
You can set the reaction to the Bin occupied error through a EWM exception.
Evaluate Telegram Error Code
The PLC reports an error in the telegram, such as “10”. This error code is assigned under …
… to a EWM exception.
The result is that the exception is entered in the HU:

V1.1 8/2008
Introduction
Link Process Code BINO
You can set the follow-on action in customizing of the exception:
Definition of the MBNO exception:
The context must be MF3 and the execution step A0 (if these attributes are set, the program searches for the
exception). Store BINO as an internal process code. This will trigger subsequent processing.
Creating an Alert
Add an alert to an exception.
A row with the name of the exception appears in the alert monitor:

V1.1 8/2008
Introduction
How the Internal Process Code BINO Works
Subsequent processing BINO tries to determine a new destination for the current warehouse task
by calling the BAdI for determining a substitute storage bin in the same aisle
if it is not implemented or does not have a result: error bin of the resource
… and directly sends a new telegram to the PLC if it is successful.
The BAdI is located:
You can enter the storage bin for error situations in the master data of the resource:
In the example warehouse, 0285-CP13 is the stock removal station of aisle 1. Since there is an error entered
in the HU, the HU is derived to the clarification bin if the BAdI is not successful.
Triggering Process Block for Destination Bin
You can also add subsequent processing for status management to the exception MBNO:
In this case, Action 04 means that this involves the destination bin of the warehouse task:

V1.1 8/2008
Introduction
The status values must be selected accordingly:
The prerequisite is that the status profile is assigned to the storage bins.
6.4.6 Error “Bin Empty”
You also have to define a EWM exception here and assign the error code of the telegram to this exception.
Exception BIN EMPTY
The BINE process code cancels the current warehouse task and tries to meet the related requirements with a
new warehouse task.
By using status management, you can set that the storage bin reported as empty is blocked for checking
purposes:

V1.1 8/2008
Introduction
In this case, you can use the action ID to control that this involves the source bin ...
… that should be blocked from additional attempts to remove stock.
6.5 Stock Removal
Product WT and HU WT
For stock removals, the system usually creates at least two warehouse tasks for each source HU:
A product warehouse task for the quantity to be take from the HU (even for complete stock pick) and
An HU warehouse task for the HU to be moved.
If the HU warehouse task cannot be directly carried out according to the storage control requirement, a third
WT is additionally created (having regard to the system availability and settings):
An HU storage task for the first transfer step.
The product warehouse task is inactive. The original HU warehouse task is also inactive if it cannot be carried
out directly.

V1.1 8/2008
Introduction
The product WT is active if the original HU WT is confirmed.
The original HU WT is active if the HU arrives at the storage bin from which it can directly reach the
destination.
Storage Control for Complete Stock Removals
It is easy to configure full pallet stock removals. You simply must store the paths from the aisles to the GI
zone. All preparations for this have already been made.
Using aisle 1 as an example, everything from a storage bin to the storage group RCK1 in storage type 0280 33
must then go through the stock removal station of aisle 1, communication point CP13.
From CP13 forced route (independent of destination) to CP14:
Starting here, the GI zone (storage bin in storage type 9020) comes into play as a destination. Everything
from CP14 to 9020 through the conveyor for full pallet stock removal CP05:
From CP05 forced route to CP06:
The End indicator is set at communication point CP06. This means that this is where storage control ends
(in this example). The inactive warehouse task can be activated.
33
As long as there nothing that is defined in more detail, such as stock transfer from bin to bin in the aisle.

V1.1 8/2008
Introduction
6.6 Stock Removal Strategies
Uniformly Distributed Load in Aisles
Not contained (as long as this does not “statistically” result from the putaway strategy).
Taking into Account Malfunctions
Only relating to the completion of a warehouse task for the current resource or communication point/segment.
If there is malfunction in the aisles, the affected storage bins can be blocked automatically.
Stock Removal Only for Deliveries (“Non-Passing Locations”)
Not contained. You can add this to the “non-passing location” through a BAdI in the WT confirmation
processing.
6.7 Picking Goods-to-Man
Storage Control
Partial picks must be controlled using the pick point. You can define this also in the layout-oriented storage
control. You define an entry with pick point that applies only for HUs from which a partial quantity can be
removed.

V1.1 8/2008
Introduction
The following settings are available for the “Whole HU” parameter.
Select option “A” for partial quantities.
The program then changes the destination of the HU warehouse task to the specified intermediate location
(0285-CP08 in this example) and checks whether other intermediate destinations are defined for the way
there. In this example, there are meanwhile three warehouse tasks for this procedure:
An inactive product WT for the quantity to be commissioned
An inactive HU WT for the pick point
An active HU WT for each of the next intermediate locations
Transfer to Pick Point
Configuring the path to the pick point is no different than the storage control for other paths. The transfer to
the pick point should work automatically. In this example, this is modeled based on the completed warehouse
tasks.
After arrival at pick point CP08, the product WT is still open (row 1). This is now processed in the packing
transaction.
Creating Pick HU
In the packing transaction for pick point 1, you can see the pick WT:
You create a pick HU at the communication point for pick HUs (CP09) – more precisely: at storage bin 0285-
CP09.
Picking
Then the quantity can be repacked using drag and drop and the picking process can then be confirmed.

V1.1 8/2008
Introduction
Conveying Pick HU
When you close the pick HU (check symbol in the header), warehouse tasks are created for conveying the HU:
You can see this again in the warehouse management monitor:
The HU is further transferred to 9020 according to the layout-oriented storage control using CP10, CP05, and
CP06.
Returning Withdrawal HU to Stock
To return the withdrawal HU to stock, select it and start the putback by using the arrow symbol in the header.

V1.1 8/2008
Introduction
7 Appendix
7.1 User Rights for PLC User
This role requires the following rights:

V1.1 8/2008
Introduction

V1.1 8/2008
7.2 MFS Exceptions
Table of the exceptions including the corresponding operating environment and internal process codes
Ext.
Permissible Exception
Event Source Trigger Valid Ext. Internal Code is
Exception Environ- Exception Process
Trigger Exception Code Context ment Code Code Behavior Set To
Scanner Telegram
Noread PLC Tele <MFSERR> Tele Back- MSCA a) none a) HU stays where it is a) -
ground b) CRCL b) Diversion to clarification bin b) HU
Unknown HU was reported EWM Code MFS7 Tele Back- MUFO a) none a) HU stays where it is a) -
ground b) HUNO b) Temp HU is created and diverted to b) HU
clarification bin
HU posting change to different EWM Custom PLC MLOC Tele Back- MLOC CHBD HU is reposted
position ground
Further treatment of HU reposted EWM Code MFS1 Tele Back- MLO2 a) none a) - a) -
to different destination ground b) CRCL b) Diversion to clarification bin b) HU
ID Point Telegram
Noread See scanner
Unknown HU See scanner
Reported at unexpected See scanner
destination
Incorrect contours PLC Tele <MFSERR> Tele Back- MCON a) none a) HU stays where it is a) -
Undefined HU type PLC Tele <MFSERR> Tele Back- MHUT a) none a) HU stays where it is a) -
Undefined HU type EWM Code Alert, Telegram is not processed
Excessive weight PLC Tele <MFSERR> Tele Back- MWEI a) none a) HU stays where it is a) -
Excessive weight EWM BAdI BADI
Putaway strategy cannot find EWM Code Alert, HU stays where it is
storage bin
Weight/Quantity not plausible EWM BAdI BADI
Found stor. bin, but is temporarily EWM BAdI BADI
not available. Somewhere in
transit capacity is missing or there
is a malfunction
Found stor. bin, but is not available EWM BAdI BADI
in the long term. Somewhere in
transit long-term block

V1.1 8/2008
Introduction
Create Follow-Up WT
No way to destination of EWM Code Alert, HU stays where it is
appropriate WT (no matching
entry in storage control)
Next segment no capacity EWM Customizing MCAP Seg Back- MCAP a) NSND a) Warehouse task is created, but not sent
segment ground b) STAY b) Warehouse task is not created
Next CP no capacity EWM Customizing MCAP CP Back- MCAP a) NSND a) Warehouse task is created, but not sent
CP ground b) STAY b) Warehouse task is not created
Resource no capacity EWM (WT is created, HU stays where it is)
Next segment is blocked EWM <Segment> Seg Back- MBLK a) NSND a) Warehouse task is created, but not sent
(long-term) ground b) STAY b) Warehouse task is not created
Next segment is malfunctioning EWM <Segment> Seg Back- MBRK a) NSND a) Warehouse task is created, but not sent
(short-term) ground b) STAY b) Warehouse task is not created
Next CP is blocked (long-term) EWM <Communica- CP Back- MBLK a) NSND a) Warehouse task is created, but not sent
tion point> ground b) STAY b) Warehouse task is not created
Next CP is malfunctioning EWM <Communica- CP Back- MBRK a) NSND a) Warehouse task is created, but not sent
(short-term) tion point> ground b) STAY b) Warehouse task is not created
Resource is blocked (long-term) EWM <Resource> Res Back- MBLK a) NSND a) Warehouse task is created, but not sent
ground b) STAY b) Warehouse task is not created
Resource is malfunctioning EWM <Resource> Res Back- MBRK a) NSND a) Warehouse task is created, but not sent
(short-term) ground b) STAY b) Warehouse task is not created
Process WT Confirmation
There are no open WTs for the EWM Code See scanner (different destination)
HU with destination reported by
PLC (open WTs with different
destination or no open WTs)
Order cannot be executed at the PLC Tele <MFSERR> Tele Back- MDNY REDE WT is reset to status Y (relevant for external
moment (for example, device ground system)
busy, not ready)
Order cannot be executed in PLC Tele <MFSERR> Tele Back- MTEL none Alert
general (for example, unknown ground
destination)
Source empty (storage bin) PLC Tele <MFSERR> Tele Back- MBNE a) - a) Alert is created, WT is not confirmed, a) -
(Note: PLC may not use this error ground b) BINE Resource still occupied b) Stor. bin
code for CP.) b) WT is cancelled, “Bin denial” logic posts (using
individual quantities/whole HU (?) to StatusMgmt)
difference and searches new stock. Stor. bin
block created using status management at
alert.

V1.1 8/2008
Introduction
Destination occupied (storage bin) PLC Tele <MFSERR> Tele Back- MBNO a) - a) Alert is created, WT is not confirmed, a) -
(Note: PLC may not use this error ground b) BINO Resource still occupied b) Stor. bin
code for CP.) b) Searching for new stor. bin, WT is changed (using
and immediately sent. StatusMgmt)
Storage bin can be blocked and subsequent
processing can be triggered through
StatusMgmt and Workflow.
Process Confirmation of
Cancellation
PLC refuses cancellation PLC Tele <MFSERR> Tele Back- MCAN NOCN Status of warehouse order is reset to “sent”.
ground
Status Telegram from PLC

Short-term communication point PLC Tele <MFSERR> CP Back- MBRK a) NSND Process code is evaluated during WT CP
malfunction ground b) STAY processing
Short-term segment malfunction PLC Tele <MFSERR> Seg Back- MBRK a) NSND Process code is evaluated during WT Segm
ground b) STAY processing
Short-term resource malfunction PLC Tele <MFSERR> Res Back- MBRK a) NSND Process code is evaluated during WT Res
Long-term communication point PLC Tele <MFSERR> CP Back- MBRK a) NSND Process code is evaluated during WT CP
malfunction ground b) STAY processing
Long-term segment malfunction PLC Tele <MFSERR> Seg Back- MBRK a) NSND Process code is evaluated during WT Segm
Long-term resource malfunction PLC Tele <MFSERR> Res Back- MBLK a) NSND Process code is evaluated during WT Res
Unblocking communication point PLC Tele MFS5 CP Back- MRDY none Unblock message is logged as alert.
ground
Unblocking segment PLC Tele MFS2 Segm Back- MRDY none Unblock message is logged as alert.
ground
Unblocking resource PLC Tele MFS4 Res Back- MRDY none Unblock message is logged as alert.
ground
Monitor
Set HU error Operator GUI CP Dialog MHUX CRCL Accesses when HU is triggered HU
Delete HU error Operator GUI Dialog No effect HU
Short-term communication point Operator GUI CP Dialog MBRK a) NSND Process code is evaluated during WT CP
malfunction b) STAY processing
Short-term segment malfunction Operator GUI Segm Dialog MBRK a) NSND Process code is evaluated during WT Segment
b) STAY processing
Short-term resource malfunction Operator GUI Res Dialog MBRK a) NSND Process code is evaluated during WT Resource
b) STAY processing

V1.1 8/2008
Introduction
Long-term communication point Operator GUI CP Dialog MBLK a) NSND Process code is evaluated during WT CP
malfunction (block) b) STAY processing
Long-term segment malfunction Operator GUI Segm Dialog MBLK a) NSND Process code is evaluated during WT Segment
(block) b) STAY processing
Long-term resource malfunction Operator GUI Res Dialog MBLK a) NSND Process code is evaluated during WT Resource
(block) b) STAY processing
Unblocking communication point Operator GUI MFS5 CP Dialog MRDY none Unblock message is logged as alert.
Unblocking segment Operator GUI MFS2 Segm Dialog MRDY none Unblock message is logged as alert.
Unblocking resource Operator GUI MFS4 Res Dialog MRDY none Unblock message is logged as alert.
Stop communication channel Operator GUI Is not logged
Start a communication channel Operator GUI MFS6 Chan- Dialog MCO1 none Alert
nel
Events for Communication Channel

PLC not ready for receipt PLC Tele <COMMERR> Chan- Back- MCOM COMM Alert is created Channel
nel ground
Sending repeatedly fails EWM Custom. Not applicable Chan- Back- MSND a) none a) Sending must be manually retriggered Channel
channel nel ground b) REST b) Channel is closed and reopened
PLC receiver buffer is full PLC Tele <COMMERR> Chan- Back- MBOF BOVF Telegram acknowledgement is ignored, which
nel ground repeats the telegram
Events for Telegram

PLC does not accept sequence PLC Tele <COMMERR> Chan- Back- MSEQ SEQW Telegram is repeated with sequence no. 0.
number nel ground
General Rules for Contexts:

MF1 Communication channel All exceptions that refer to the state of the communication channel. (not to the transferred telegrams)
MF2 Transportation
segment/segment group Status change and status evaluation for segments or segment groups
MF3 Telegram Everything that deals with telegram log and telegram contents
This also includes all material flow problems whether they are reported by PLC (except for status-related) or whether they are detected by EWM
(except for status-related)
MF4 Resource Status change and status evaluation to resources
MF5 Communication point Status change and status evaluation to communication points
General Rules for Operating Environment:

A0 Processing in background All exceptions that should be used by the programs, in particular all exceptions in context MF3
A1 Processing in dialog All exceptions that the user should be able to set. In particular, these are exceptions with status contexts MF2, MF4, and MF5.

V1.1 8/2008
7.3 Internal Process Codes
Internal Process Code BOVF

Process code BOVF ignores the PLC confirmation telegram. As a result, the telegram is automatically
repeated.
This code is carried out in function module /SCWM/MFS_ACK_EXCEPTION for context MF1 and step A0.
Internal Process Code COMM

Process code COMM does not trigger an additional action. The status is set on the communication
channel. The customer can use the possibilities of exception handling (alert, workflow, and so on).
This code is carried out in function module /SCWM/MFS_COMM_EXCEPTION for context MF1 and
step A0.
Internal Process Code REST
Process code REST restarts the communication.

This code is carried out in function module /SCWM/MFS_COMM_EXCEPTION for context MF1 and
step A0.
Internal Process Code SEQW

Process code SEQW immediately repeats the current telegram with sequence number 0.
This code is carried out in function module /SCWM/MFS_ACK_EXCEPTION for context MF1 and step A0.
Internal Process Code CRCL
Process code CRCL updates the exception to the HU. Then it cancels all open warehouse tasks to the HU
and creates a new warehouse task for the HU to the clarification bin.
This code is carried out in function module /SCWM/MFS_REQ_EXCEPTION for context MF3 and step A0.
This code is carried out in function module /SCWM/MFS_WT_CONFIRM for context MF5 and step A0.
This code is carried out in function module /SCWM/TROUTL_DET and /SCWM/TROUTL_DET_SEG for
context MF2, step A0 and A1 and for context MF5, step A0 and A1.
Internal Process Code NSND

Process code NSND creates, but does not send, the warehouse task for the HU.
context MF2, step A0 and A1, for context MF4, step A0 and A1, and for context MF5, step A0 and A1.
Internal Process Code STAY
Process code STAY does not create the warehouse task for the HU.
context MF2, step A0 and A1, for context MF4, step A0 and A1, and for context MF5, step A0 and A1.
Internal Process Code BINE
Process code BINE cancels all warehouse tasks for the HU and tries to create a new warehouse tasks
through the “bin denial full” logic.

V1.1 8/2008
Introduction
Internal Process Code BINO

Process code BINO attempts to determine a new, empty storage bin. As a result, the current warehouse
task is changed and the telegram with the new data immediately sent.
Internal Process Code HUNO

Process code HUNO updates the exception to the HU. Then it cancels all open warehouse tasks to the
HU and creates a new warehouse task for the HU to the clarification bin.
Internal Process Code NOCN

Process code NOCN changes the indicator for sending the cancellation request (IDSUB = 2) to “X” in the
warehouse task.
7.4 SAP EWM – RFC Adapter Interface
SAP EWM uses an external communication layer to communicate with the controls. This communication
layer must be registered as an external program on the SAP system and offer the function modules described
below:
Connection setup (optional),
Send telegram (mandatory),
Connection termination (optional),
Status check (optional).
The names of the function modules can be configured in SAP EWM.
Call function module /SCWM/MFS_RECEIVE2 to transfer data to SAP EWM.
The EWM system transfers the IP address and port of the control to be connected to the function Connection
setup.
The EWM system transfers the telegrams to be sent to the PLC through the Send telegram module.
When terminating a connection, the communication layer should close the affected socket.
The status check should give the EWM system information on whether the communication layer itself is
intact.
7.4.1 Function Module for Setting Up a Connection to a PLC
You call this module to pass the necessary connection parameters to the communication layer. The
communication layer should be logged on as client at the designated port.

V1.1 8/2008
Introduction
Name
The name of the function module can be set in IMG, for example, “START_CHANNEL”.
Input Parameters
Parameter Name Type Length Use
IV_LGNUM CHAR 4 Warehouse Number
IV_PLC CHAR 8 Name for the PLC that should be used to establish the connection
IV_CHANNEL CHAR 1 Identification for this connection to this PLC (it is possible to operate
several channels to a PLC in parallel)
IV_IP_ADDRESS CHAR 15 PLC IP address
IV_PORT NUMC 5 Port that is used to reach the PLC
IV_TERMINATOR CHAR 2 Character string that identifies the end of the transferred message
IV_TELELEN NUMC 3 Fixed telegram length
Return Parameters
- None
Exceptions
Exception Meaning
1 Communication error, IP/port not available. The parameters are still held in the
communication layer and used when subsequent sending attempts are made.
2 System error, constant. Communication not possible
99 Other error
7.4.2 Function Module for Sending Telegrams to a PLC
You call this parameter to pass a telegram to the communication layer for forwarding to the PLC.
Name
The name of the function module can be set in IMG, for example, “SEND”.
Input Parameters
IV_LGNUM CHAR 4 Warehouse number
IV_PLC CHAR 8 Name for the PLC that should be used to establish the connection
IV_CHANNEL CHAR 1 Identification for this connection to this PLC (it is possible to operate several
channels to a PLC in parallel)
IV_TELEGRAM CHAR 255 Telegram string.

End character string transferred in the specified length and/or completed
with the length during start

V1.1 8/2008
Introduction
Return Parameters
EV_TELEGRAM CHAR 255 Telegram string, optional
Exceptions
Exception Meaning
1 Communication error
99 Other error
7.4.3 Function Module for Receiving Telegrams from a PLC
You call this parameter to pass a telegram received from the PLC to the EWM system.
Name
The name of the function module is: “/SCWM/MFS_RECEIVE2”.
Input Parameters
IV_LGNUM CHAR 4 Warehouse number (optional)
IV_PLC CHAR 8 Name for the PLC that should be used to establish the connection (optional)
channels to a PLC in parallel) (optional)
IV_IP_ADDRESS CHAR 15 PLC IP address (optional)
IV_PORT NUMC 5 Port that is used to reach the PLC (optional)
IV_TELEGRAM CHAR 255 Telegram string.

End character string transferred in the specified length and/or completed
with the length during start
For the optional parameters:
SAP EWM can be called with either

IV_LGNUM, IV_PLC, and IV_CHANNEL
or IV_IPADDRESS and IV_PORT
If you choose the second alternative, the warehouse number, PLC, and communication channel are
determined from the IP address and port through customizing.

V1.1 8/2008
Introduction
Return Parameters
EV_ERROR CHAR 1 “X” = error during telegram transfer
Exceptions
Exception Meaning
99 Other error
7.4.4 Function Module for Terminating a Connection to a PLC
You call this module to pass a request to terminate the connection to the communication layer.
Name
The name of the function module can be set in IMG, for example, “CLOSE”.
Input Parameters
IV_LGNUM CHAR 4 Warehouse number
IV_PLC CHAR 8 Name for the PLC that should be used to terminate the connection
channels to a PLC in parallel)
Return Parameters
None
Exceptions
Exception Meaning
99 Other error
7.4.5 Function Module for Checking the Availability of the Communication Layer
You call this module to check the status of the communication layer.
Name
The name of the function module can be set in IMG, for example, “HEALTH_CHECK”.
Input Parameters
None

V1.1 8/2008
Introduction
Return Parameters
EV_HEALTH CHAR 1 “A” = communication layer ready (green traffic light),

“B” = communication layer is currently being started or stopped (yellow
traffic light),
“C” = communication layer is running, but is not yet ready, for example, due
to log overflow (red traffic light),
Other values are valued as unknown (no traffic light – gray)
Exceptions
Exception Meaning
99 Other error

V1.1 8/2008
Introduction
List of Abbreviations
ASR Automatic storage retrieval
CP Communication point. Point on the system where SAP EWM communicates

with the PLC
CTCAR Cross transfer car (=TCAR)
HU Handling unit
ID Point Identification point, mainly used for the point where the storage bin is
determined in relation to automated warehouses
LHA Load handling attachment (such as the fork of a stacker crane)
PLC Programmable logic controller
SC Stacker crane
Segment Connection between two communication points
SV Shelf vehicle (=SC)
TCAR Transfer car
WO Warehouse order, warehouse orders in the MFS environment always receive

only one warehouse task
WT Warehouse task, task for moving an HU or a quantity from one storage bin to
another

V1.1 8/2008
Introduction
General Disclaimer
SAP does not represent or endorse the accuracy or reliability of any of the information, content, or advertisements (collectively, the "Materials")
contained on, distributed through, or linked, downloaded, or accessed from any of the services contained on this Web site (the "Service"), nor the
quality of any products, information, or other materials displayed, purchased, or obtained by you as a result of an advertisement or any other
information or offer in or in connection with the Service (the "Products"). You hereby acknowledge that any reliance upon any Materials shall be at
your sole risk. SAP reserves the right, in its sole discretion and without any obligation, to make improvements to, or correct any error or omissions
in any portion of the Service or the Materials.
THE SERVICE AND THE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE, WITH RESPECT TO THE SERVICE OR ANY MATERIALS AND PRODUCTS. IN NO EVENT SHALL SAP BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES OF ANY KIND WHATSOEVER WITH RESPECT
TO THE SERVICE, THE MATERIALS, AND THE PRODUCTS.
SAP encourages you to exercise discretion while browsing the Internet using this site.
SAP makes no representations concerning any endeavor to review the content of sites linked to this site or any of the Materials, and so SAP isn't
responsible for the accuracy, copyright compliance, legality, or decency of material contained in sites listed in the directory or in the Materials.
SAP respects the rights (including the intellectual property rights) of others, and we ask our users to do the same. SAP may, in appropriate
circumstances and in its sole discretion, terminate the accounts of users that infringe or otherwise violate such rights of others.
If you believe that your work has been copied in a way that constitutes copyright infringement, please follow the instructions at the top of this
page.
© Copyright 2008 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The
information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries,
pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power
Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS,
HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and
Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the
United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix
Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C® , World Wide Web Consortium, Massachusetts Institute of
Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

V1.1 8/2008
Introduction
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries
all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this
document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for
informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect
to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

V1.1 8/2008

PLC Direct Connection With SAP Extended Warehouse Management (EWM) 5.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PLC Direct Connection With SAP Extended Warehouse Management (EWM) 5.1

Uploaded by

Copyright:

Available Formats

PLC Direct Connection with

SAP Extended Warehouse Management (EWM) 5.1

PLC Direct Connection with SAP EWM 5.1

PLC Direct Connection with SAP EWM 5.1

4.4.5 Telegram Log 63

PLC Direct Connection with SAP EWM 5.1 Page 3/153

5.4.5 Canceling a PLC Warehouse Task 100

PLC Direct Connection with SAP EWM 5.1 Page 4/153

6.4.4 Maintaining Mode for LSD Rounding 129

PLC Direct Connection with SAP EWM 5.1 Page 5/153

This is an example of such a warehouse:

ID Point Put away Removal-HU

Goods Receipt Clearing Goods Issue Empty Pallets

Logical System Levels

In automatic warehouses, various types of technology are used, for example:

PLC Direct Connection with SAP EWM 5.1 Page 6/153

Inbound & Outbound

Stock per HU & Bin

Real Time Controllers (PLC) Control of Equipment

Sensors & Drives

PLC Direct Connection with SAP EWM 5.1 Page 7/153

Automated Warehouse with SAP

Inventory SAP ERP SAP ERP SAP ERP SAP ERP

3rd Pty. SAP LES SAP LES SAP EWM

Control of PLC PLC PLC PLC

SAP AG 2007, SAP EWM 5.1 Material Flow System / 3

1.1 Example Warehouse

Controllers Involved in the Example Warehouse

PLC Direct Connection with SAP EWM 5.1 Page 8/153

Programmable Logic Controller (PLC)

SAP AG 2007, EWM/MFS Implementation Example / 4

Material Flow in the Example Warehouse

Thus, the material flow must meet the following requirements:

PLC Direct Connection with SAP EWM 5.1 Page 9/153

SAP AG 2006, SCWM/MFS-Beispiellager / 3

Possible errors (reported by PLC):

PLC Direct Connection with SAP EWM 5.1 Page 10/153

Stock Removal Process

1.2 Requirements for a Material Flow System

Material Flow Control Requirements

Control Station Requirements

PLC Direct Connection with SAP EWM 5.1 Page 11/153

PLC Direct Connection with SAP EWM 5.1 Page 12/153

2 SAP EWM Material Flow System (MFS): Function Overview

2.1 EWM PLC Communication

Bidirectional Telegram Communication

SAP AG 2007, SAP EWM 5.1 Material Flow System / 5

PLC Direct Connection with SAP EWM 5.1 Page 13/153

RFC Adapter Functions

Bridge between SAP RFC protocol and TCP/IP

© SAP 2007 / Page 5

2.2 SAP EWM Material Flow Functions

PLC Direct Connection with SAP EWM 5.1 Page 14/153

Consideration of equipment faults

Storage Control via Communication Points

SAP AG 2007, SAP EWM 5.1 Material Flow System / 9

Communication points are useful where

PLC Direct Connection with SAP EWM 5.1 Page 15/153

Automatic ID Point and Diversion to Clarification Bin

SAP AG 2007, SAP EWM 5.1 Material Flow System / 11

PLC Direct Connection with SAP EWM 5.1 Page 16/153

EWM Prevents Dead Lock Situations

Task for HU 2 is postponed until HU 1 has IP