SAP EWM Lagerintegration — embedded oder dezentral? So wird ein Lager an EWM angebunden

SAP EWM verwaltet Lagerplätze, Lageraufgaben und Ressourcen — aber die Bestände, Bestellungen und Kundenaufträge "gehören" dem ERP-System. Damit beide Welten zusammenspielen, muss das Lager sauber angebunden sein: organisatorisch über Werk, Lagerort und Lagernummer, technisch über Schnittstellen oder eine gemeinsame Datenbank. Genau diese Integrationsthemen gehören zu den Grundlagen der SAP EWM Anwenderzertifizierung (UC_EWM_S42023) — und sie entscheiden darüber, ob du Prüfungsfragen zu embedded vs. dezentralem EWM sicher beantwortest.

In diesem Artikel lernst du:

• warum Bestandsführung und Lagerverwaltung zwei verschiedene Sichten auf denselben Bestand sind
• welche Lagerverwaltungslösungen es in SAP S/4HANA gibt — und wo Stock Room Management hingehört
• wie ein Lagerort über die Lagernummer an EWM angebunden wird (inklusive der 1:n-Regeln)
• wie Stammdaten und Transaktionsdaten zwischen ERP und EWM ausgetauscht werden
• wie der Belegfluss bei An- und Auslieferung über die Systemgrenze läuft
• welche Unterschiede zwischen embedded und dezentralem EWM die Prüfung gern abfragt

Bestandsführung vs. Lagerverwaltung: zwei Sichten auf denselben Bestand

Die Bestandsführung (MM-IM) im ERP beantwortet die Frage: Wie viel Bestand welcher Bestandsart liegt in welchem Werk und Lagerort? Sie kennt Mengen und Werte — aber keinen physischen Ort. Die Lagerverwaltung ergänzt die fehlende Dimension: Sie weiß, wo genau im Lager die Ware liegt — bis hinunter zum einzelnen Lagerplatz.

Diese Arbeitsteilung ist der Kern der Integration: Das ERP führt den Bestand auf Ebene Werk/Lagerort, EWM organisiert die physische Arbeit dahinter. Jede Warenbewegung, die EWM abschließt, muss deshalb in die Bestandsführung zurückgemeldet werden — sonst laufen Mengen- und Lagersicht auseinander. Wie die EWM-interne Struktur aus Lagertypen, Lagerbereichen und Lagerplätzen aussieht, liest du im Artikel zu den EWM-Lagerstrukturen.

Die Lagerverwaltungslösungen in SAP S/4HANA

In SAP S/4HANA stehen zwei integrierte Lagerverwaltungslösungen zur Verfügung — ein beliebtes Prüfungsthema:

• Eingebettetes SAP EWM (embedded EWM): läuft direkt im S/4HANA-System, ohne separate Installation. Es kann je Lagernummer als einfache Lagerverwaltung (basic) oder erweiterte Lagerverwaltung (advanced) betrieben werden und ist der direkte Nachfolger des klassischen LE-WM.
• Lagerraumverwaltung (Stock Room Management): die schlanke Lösung für kleine, manuell betriebene Läger. Sie umfasst Grundfunktionen wie Einlagerungsabwicklung, Kommissionierung und Lagerplatzverwaltung auf Lagerplatzebene — erweiterte Funktionen wie Aufgaben- und Ressourcenmanagement oder logistische Zusatzleistungen bleiben dem vollen EWM vorbehalten.

Daneben gibt es SAP EWM weiterhin als dezentrales EWM: ein eigenes System auf S/4HANA-Basis, das per Schnittstelle mit einem oder mehreren ERP-Backends verbunden wird. Typische Gründe für den dezentralen Betrieb sind Performance bei sehr hohem Belegdurchsatz, die 24/7-Verfügbarkeit des Lagers unabhängig vom ERP-System und ein geringeres Ausfallrisiko: Steht das ERP still, arbeitet das Lager weiter.

Eine Feinheit, die das Verständnis enorm erleichtert: Aus Sicht des ERP ist EWM konzeptionell immer eine dezentrale Lagerverwaltung — auch das eingebettete EWM ist technisch gesehen eine dezentrale Lösung, bei der die Lieferung systemintern von einem Teil an den anderen verteilt wird. Der praktische Unterschied: Beim embedded EWM entfallen Nachrichtenübertragung und Zwischenbelege, weil beide Komponenten auf derselben Datenbank arbeiten.

Die Brücke im Customizing: Werk + Lagerort ↔ Lagernummer

Organisatorisch wird ein Lager über genau zwei ERP-Organisationseinheiten an EWM angebunden: Werk und Lagerort. Ihre Kombination wird einer Lagernummer zugeordnet — und die Einstellungen dieser Lagernummer bestimmen, welche Art von Lagerverwaltung dahinter arbeitet. Der Lagerort trennt Bestände dabei logisch unterhalb des Werks (ein Werk kann mehrere Lagerorte haben), die Lagernummer steht für den physischen Lagerkomplex.

Für die Zuordnung gelten klare Spielregeln:

• Mehrere Werk-Lagerort-Kombinationen → eine Lagernummer: möglich. Sogar Lagerorte verschiedener Werke können auf denselben physischen Lagerkomplex zeigen.
• Eine Werk-Lagerort-Kombination → mehrere Lagernummern: nicht möglich. Die Zuordnung ist eindeutig.
• Nicht jede Kombination braucht eine Lagernummer — Bestände ohne Lagerplatzverwaltung (etwa Packmittel) bleiben einfach ohne.

Eingestellt wird das im Customizing unter Unternehmensstruktur → Zuordnung → Logistics Execution → Lagernummer zu Werk und Lagerort zuordnen. Ein Beispiel: Das Werk 2400 mit Lagerort 24A0 wird der Lagernummer 240 zugeordnet. Dabei lohnt ein genauer Blick auf die Stellenzahl — im ERP ist die Lagernummer dreistellig, in EWM vierstellig; bei integriertem EWM wird die ERP-Lagernummer deshalb zusätzlich mit der EWM-Lagernummer (etwa W240) verknüpft.

Stammdaten: vom Material zum Lagerprodukt

Stammdaten werden grundsätzlich im ERP gepflegt und für EWM bereitgestellt. Wie sie dorthin kommen, hängt vom Deployment ab:

• Embedded EWM: keine Verteilung nötig — EWM nutzt die gemeinsamen Stammdaten der S/4HANA-Datenbank direkt.
• Dezentrales EWM bis Version 9.5 (auf SCM-Basis): Übertragung über das Core Interface (CIF).
• Dezentrales EWM auf S/4HANA-Basis: Das CIF wird hier nicht mehr verwendet — die Übertragung läuft über das ALE-Verteilungsmodell (IDocs) und zunehmend über das Datenreplikations-Framework (DRF).

Inhaltlich werden ERP-Stammdaten auf EWM-Objekte abgebildet: Werke, Versandstellen, Kunden und Lieferanten werden zu Lokationen und Geschäftspartnern; aus dem Materialstamm wird der Produktstamm mit Kurztexten, Mengeneinheiten, Materialgruppe sowie Gewichts- und Volumenangaben. Sollen Prozesse wie Einlagerung, Kommissionierung oder Nachschub produktabhängig gesteuert werden, wird es optional zum Lagerprodukt erweitert — je Lagernummer und Verfügungsberechtigtem, mit der Transaktion /SCWM/MAT1 und eigenen Sichten für Lagerdaten, Lagerungsdisposition und Lagertypdaten.

Wie die Systeme sprechen: qRFC, IDoc — oder gar nicht

Für die laufenden Transaktionsdaten (Lieferbelege, Bestätigungen, Warenbewegungen) gilt beim dezentralen EWM die Standardarchitektur: Die Übertragung zwischen ERP und EWM erfolgt per qRFC (queued Remote Function Call) und IDoc. Das embedded EWM braucht beides nicht — es greift direkt auf die gemeinsame Datenbank zu, eine Nachrichtenübertragung findet nicht statt.

Eine Verwechslungsfalle für die Prüfung: Das ältere dezentrale WM (LE-WM als eigenständiges System) replizierte Lieferungen über BAPIs — das ist die Antwortoption, die bei EWM-Fragen regelmäßig als Distraktor auftaucht. Merke: dezentrales EWM = qRFC + IDoc.

Belegfluss Wareneingang: über die Systemgrenze und zurück

Der Wareneingang startet im ERP mit der Bestellung. Damit das Lager von der erwarteten Lieferung erfährt, wird im ERP eine Anlieferung angelegt — manuell oder automatisch aus einem Lieferavis des Lieferanten. Ob zur Bestellposition eine Anlieferung erforderlich ist, steuert der Bestätigungssteuerschlüssel; die Details dazu findest du im Artikel zu Lageraufgaben und Lageraufträgen.

Ab hier unterscheidet sich der Weg je nach Deployment:

• Dezentral: Die ERP-Anlieferung wird an EWM übertragen und dort zunächst als Anlieferungsbenachrichtigung angelegt. Daraus erzeugt das System (per PPF) die EWM-Anlieferung — den Ausführungsbeleg, mit dem das Lager arbeitet. Ab EWM 9.5 lässt sich der Zwischenbeleg überspringen.
• Embedded: Die Anlieferungsbenachrichtigung existiert nicht — die EWM-Anlieferung wird direkt angelegt.

Die EWM-Anlieferung ist zugleich die Lageranforderung für den Wareneingang. Änderungen an ihr werden an das ERP zurückgemeldet, und mit dem Status "Ausführung abgeschlossen" bildet sie die Grundlage für die Lieferempfangsbestätigung im ERP. Entscheidend für das Verständnis der Integration: Die Wareneingangsbuchung im ERP wird von EWM angestoßen — erst dann entstehen dort Materialbeleg und Buchhaltungsbeleg, und die Bestandsführung ist wieder synchron.

Damit das ERP sieht, dass angekommene Ware noch nicht verkaufsbereit ist, arbeitet das Standardszenario mit zwei Lagerorten: Beim Wareneingang gehört der Bestand zum Lagerort RD00 ("Wareneingang am Tor"), nach abgeschlossener Einlagerung bucht EWM ihn auf den Lagerort AF00 ("für den Verkauf verfügbar") um. So bleibt der Einlagerungsfortschritt sogar in der ERP-Bestandsführung sichtbar.

Belegfluss Warenausgang: vom Kundenauftrag zur Rückmeldung

Im Warenausgang beginnt die Kette mit dem Kundenauftrag — er kommt typischerweise aus dem ERP- oder einem CRM-System. Daraus entsteht die ERP-Auslieferung, die an EWM übergeben wird:

• Dezentral: EWM legt zunächst eine Auslieferungsanforderung als Zwischenbeleg an, daraus entsteht der Auslieferungsauftrag. Ab EWM 9.5 ist der Zwischenbeleg abschaltbar.
• Embedded: Der Auslieferungsauftrag wird direkt angelegt.

Der Auslieferungsauftrag ist die Lageranforderung des Warenausgangs: Er definiert den Arbeitsvorrat für Kommissionierung, Verpacken und Verladen. Welche Prozessschritte das Lager dabei durchläuft, beschreibt der Artikel zu Wareneingangs- und Warenausgangsprozessen in EWM. Am Ende des Prozesses entsteht die EWM-Auslieferung — sie sendet die Warenausgangsbuchung an das ERP zurück, wo Bestandsführungs- und Finanzbelege erzeugt werden. Wird nur ein Teil der Menge geliefert, kommt es zum Lieferungssplit. Übrigens: Auch Umlagerungsbestellungen zwischen Werken lösen den Warenausgangsprozess in EWM aus.

Was embedded EWM anders macht: drei Prüfungs-Anker

Drei Besonderheiten des eingebetteten EWM tauchen in Prüfungsfragen immer wieder als Unterscheidungsmerkmal auf:

• Keine Zwischenbelege: Anlieferungsbenachrichtigung und Auslieferungsanforderung gibt es nur im dezentralen EWM.
• Direkte Integration in Produktionsszenarien: In einem Kanban-Szenario kann das embedded EWM direkt eine Lageraufgabe anlegen — ohne Umweg über Lieferbelege, die das dezentrale EWM dafür braucht.
• Erwarteter Wareneingang (EWE): Sollen Wareneingänge aus der Produktion in EWM vorbereitet werden, dient im dezentralen Szenario der Beleg "Erwarteter Wareneingang" als Referenz, um eine Anlieferung anzulegen — die Voranmeldung für Produktionsrückmeldungen, abzugrenzen vom Lieferavis des Lieferanten.

Warum die Lagerintegration prüfungsrelevant ist

Im offiziellen Leitfaden zur UC_EWM_S42023 sind die Grundlagen von SAP EWM — Deployment-Optionen, Organisationsstrukturen und der Belegfluss zwischen ERP und EWM — als eigenständige Themenblöcke gesetzt. Typische Fragestellungen:

• Frage: Welche Lagerverwaltungslösungen sind in SAP S/4HANA verfügbar? (Eingebettetes SAP EWM und die Lagerraumverwaltung/Stock Room Management)
• Frage: Über welche beiden Organisationseinheiten im ERP wird das EWM-Lager bestimmt? (Werk und Lagerort)
• Frage: Mit welchen Methoden werden Transaktionsdaten zwischen ERP und dezentralem EWM übertragen? (Per IDoc und qRFC — im embedded EWM entfällt die Übertragung dank gemeinsamer Datenbank)
• Frage: Welche Belege erstellt EWM im Wareneingang? (Die Anlieferungsbenachrichtigung und die Anlieferung)
• Frage: Was dient als Lageranforderung für den Warenausgangsprozess? (Der Auslieferungsauftrag)
• Frage: Kann eine Werk-Lagerort-Kombination mehreren Lagernummern zugeordnet werden? (Nein — umgekehrt können aber mehrere Werk-Lagerort-Kombinationen auf eine Lagernummer zeigen)
• Frage: Was sind Merkmale von Lagerorten? (Sie unterscheiden Materialbestände unterhalb der Werksebene; einem Werk können mehrere Lagerorte zugeordnet sein)
• Frage: Welcher Beleg kann im embedded EWM direkt aus einem Kanban-Szenario angelegt werden? (Eine Lageraufgabe)

Das Muster hinter vielen dieser Fragen: Das Prüfungsteam testet, ob du die Systemgrenze sauber ziehen kannst — welcher Beleg gehört dem ERP, welcher EWM, und welche Zwischenbelege existieren nur im dezentralen Szenario.

Fazit

Die Lagerintegration beantwortet drei Fragen: Wo wird die Verbindung definiert (Werk + Lagerort → Lagernummer), wie tauschen die Systeme Daten aus (gemeinsame Datenbank beim embedded EWM, qRFC/IDoc und ALE/DRF beim dezentralen) und welche Belege wandern über die Grenze (Anlieferung und Auslieferung mit ihren EWM-Gegenstücken samt Rückmeldung an Bestandsführung und Finanzbuchhaltung). Wer diese Architektur einmal verstanden hat, kann embedded- und dezentral-Fragen sicher auseinanderhalten — und versteht nebenbei, warum EWM-Prozesse immer mit einem ERP-Beleg beginnen und enden.

Im SAP EWM Modul auf sapprep.de findest du simulierte Übungsfragen zu genau diesen Themen — von Deployment-Optionen über die Lagernummer-Zuordnung bis zum Belegfluss, mit Erklärungen auf Basis der offiziellen SAP-Schulungsunterlagen.

👉 Jetzt 15 Fragen kostenlos testen oder direkt das EWM-Modul ansehen.