Zu jeder speicherprogrammierter Steuerung muss ein Kommunikationskanal gepflegt werden, der im ersten Schritt definiert werden muss. Nachrichtenverbindungen zwischen MFS und einer SPS werden durch eine IP-Adresse und einen Port definiert. Um die Kommunikation zwischen MFS und einer SPS zu ermöglichen, muss ein Kommunikationskanal für diese SPS definieren. Man legt dabei einige Eigenschaften fest, z. B. die Länge der Nachrichten und ob mit Telegrammbestätigungen gearbeitet wird.

Im Anwendungsmenü müssen außerdem IP-Adresse und Port eingestellt werden, über die die SPS erreichbar ist. Man kann zur Kommunikation mit derselben SPS mehrere Kanäle verwenden. Diese müssen dann jeweils einen eigenen Port nutzen. Man kann festlegen, dass bestimmte Telegramme über den einen Kanal und andere Telegramme über einen anderen Kanal kommuniziert werden sollen.

Telegramme eines Kommunikationskanals werden sequenziell an die SPS übermittelt, das heißt, EWM versendet Telegramm 2 erst dann, wenn für das zuvor versendete Telegramm 1 eine Empfangsbestätigung eingetroffen ist. In der Regel ist ein Kommunikationskanal pro Steuerung ausreichend. Über einen zweiten Kommunikationskanal (und ggf. weitere) kann die Kommunikation jedoch beschleunigt werden.

Es muss unterschieden werden ob SAP EWM mit MFS neu eingeführt wird oder ob EWM mit MFS erweitert wird. Im Falle einer Neueinführung sollte bei der SPS-Programmierung darauf geachtet werden, dass alle Voraussetzungen für eine reibungslose Kommunikation mit SAP EWM eingerichtet werden (ggf. mit SAP Plant Connectivity). Die technischen Anlagen sollten vom Intelligenzgrad sehr niedrig programmiert werden.

Sollte es sich um einer Erweiterung bzw. um eine Modernisierung eines Lagers handeln, muss zunächst die Funktionsweise der Untergelagerten Steuerung (S5,S7) verstanden werden. In den meisten Fällen muss ein Retrofit der technischen Anlagen durchgeführt werden. Die veralteten SPS-Analgen können durch den voranschreitenden Generationenwechsel nicht mehr gewartet werden und sind für Erweiterungen nicht flexibel genug entwickelt. In diesem Fall lohnt es sich für den Kunden nicht mehr, in die Logik der SPS-Programmierung zu investieren.

Eine Ressource ist ein Fahrzeug, das eine Lageraufgabe ausführt und somit eine HU von einem Meldepunkt zum nächsten bringt. Diese SPS-gesteuerten Fahrzeuge können im MFS mithilfe von Ressourcen abgebildet werden. Ressourcen und ihre Bewegungen, z. B. von Regalbediengeräten, können aus EWM heraus optimiert werden. Im Gegensatz dazu müssen sogenannte Fahrzeuge, die von der SPS selbst mittels eines eigenen Auftragspuffers optimiert werden, in EWM nicht als Ressource eingerichtet werden.

Dies wäre z. B. sinnvoll für einen Verteilwagen. In diesen Fällen genügt es, die vom Verteilwagen bedienten Meldepunkte zu definieren. Um eine Ressource zu erstellen, definiert man zunächst Ressourcentypen, um gleichartige Ressourcen zu gruppieren. Für jeden Ressourcentyp kann man anschließend die folgenden Parameter definieren: Die maximale Anzahl an Telegrammen pro Ressource und ob für diese Ressource das Doppelspiel angewandt werden soll.

In diesem Fall bekommt eine Ressource nach einer Einlageraufgabe sofort eine Auslagerungsaufgabe, um Leerlauf für die Ressource zu vermeiden. Das Doppelspiel ist in EWM nur für Ressourcen mit einem Lastaufnahmemittel einsetzbar. Darüber hinaus müssen sich die Ein- und Auslagerplätze am gleichen Gassenende befinden. Beim Doppelspiel betrachtet das System jeweils einen Pool von Aufträgen. Grundlage hierfür ist der späteste Starttermin (SST). Aufträge, deren SST erreicht ist bzw. in einem einstellbaren Zeitraum erreicht sein wird, gelten bezüglich des Doppelspiels als gleichwertig. Die Zeitstrecke wird dabei gerastert, z. B. in volle Stunden. Man legt dieses Raster im Customizing fest.

Mit dem Feld Ressource LB-Quittierung kann man das Ressourcenverhalten bei der Quittierung von Lageraufgaben definieren. Hierfür gibt es drei Optionen: