Das SAP Extended Warehouse Management (EWM) ist das Herzstück vieler moderner Logistikprozesse. Wareneingänge, Warenausgänge, interne Umlagerungen oder die Produktionsversorgung – alles läuft hier zusammen und wird zentral gesteuert. Und genau deshalb gilt: Wenn im EWM etwas nicht rundläuft, steht im Zweifel nicht nur ein Prozess, sondern ein relevanter Teil der Lieferkette.
Die strukturierte Fehlersuche und fundierte Fehleranalyse sind daher kein reines IT-Thema, sondern ein geschäftskritischer Erfolgsfaktor. Deshalb wollen wir uns in unserem heutigen Blogbeitrag auf das Thema „Fehlersuche und -analyse im EWM“ konzentrieren und praxisnahe Tipps geben, damit diese auch erfolgreich funktioniert.
Warum es keine „5-Schritte-Anleitung“ zur Fehlersuche im EWM gibt
Eine einfache Standard-Liste greift hier allerdings zu kurz. SAP EWM ist hochgradig prozessgetrieben, tief integriert (z. B. mit SAP S/4HANA, TM, PP oder QM) und stark vom jeweiligen Customizing abhängig. Fehler können entstehen durch:
- Fehlerhaftes oder unvollständiges Customizing
- Inkonsistente Stammdaten (Produkt, Lagerprozessart, Verpackungsvorschriften etc.)
- Integrationsprobleme zwischen ERP und EWM
- Queue- oder IDoc-Fehler
- Erweiterungen (BAdIs, User-Exits, kundeneigene Logik)
- Berechtigungsprobleme
- Performance- oder Sperrkonflikte
- oder schlicht durch unerwartete Prozesskonstellationen im operativen Alltag
Hinzu kommt: Viele Fehlermeldungen im EWM sind technisch korrekt – aber fachlich nicht selbsterklärend. Wer hier nur auf die Message-ID oder nur den Text schaut, wird selten die eigentliche Ursache erkennen. EWM-Nutzer kennen meist das Problem der „nichtssagenden“ Fehlermeldungen sehr gut. Spätestens bei der Hilfe zur Lösung des Fehlers wird es häufig dürftig.
Genau deshalb lässt sich die Fehlersuche in EWM nicht pauschal in einem einzigen Blogbeitrag erklären. Es gibt nicht „den EWM-Fehler“. Es gibt Prozessfehler, Integrationsfehler, Customizing-Fehler, Entwicklungsfehler und systemische Inkonsistenzen. Jede Kategorie folgt anderen Mustern und erfordert ein anderes Vorgehen.
Deshalb stellen wir in diesem Beitrag allgemeine Vorgehensweisen vor, die sich als erster Schritt für jeden eignen. Wir beginnen hier bei generell vorliegenden Problemen wie Übertragungsfehler, Sperreinträge oder Berechtigungen und gehen danach in Richtung feiner Auswertungen über Logs und Traces. Und darüber hinaus geben wir zusätzlich mögliche weitere Schritte, die nachfolgend getätigt werden können.
Übertragungsfehler EWM – ERP: Prüfen der Queues
Treten Unregelmäßigkeiten auf – insbesondere bei Schnittstellenthemen wie einem fehlenden Statusübertrag – empfiehlt sich als erster Schritt ein Blick in die Queues. Oft findet sich dort bereits ein Eintrag zum betreffenden Beleg, der die Ursache direkt aufzeigt. Grundsätzlich gilt: In einem laufenden EWM-System sollten die Queues regelmäßig geprüft werden, um hängengebliebene Einträge frühzeitig zu erkennen. Aufzurufen sind die Queues über die Transaktionen „SMQ1“ und „SMQ2“. Diese bezeichnen zwei unterschiedliche Queues (Warteschlangen) in SAP. Die Abkürzung SMQ steht für „Synchronous Message Queue“. Diese Queues dienen dazu, Daten oder Nachrichten von einem System an ein anderes zu übertragen. Sie kommen immer dann zum Einsatz, wenn Informationen systemübergreifend versendet werden.
- SMQ1 (Sender- bzw. Ausgangsqueue) ist für das Versenden von Nachrichten. Wird eine Nachricht verschickt, landet sie zunächst in der SMQ1-Queue des sendenden Systems. Von dort aus kann sie weiterverarbeitet werden.
- SMQ2 (Empfänger- bzw. Eingangsqueue) ist für den Empfang dieser Nachrichten zuständig. Das empfangende System liest die bereitgestellten Einträge über SMQ2 ein.
Vereinfacht gesagt: Das sendende System stellt die Nachricht über SMQ1 bereit, und das empfangende System ruft sie über SMQ2 ab. Hierdurch können Daten wie Auftragsinformationen, Lieferabrufe und Bestandsaktualisierungen einfach und effizient zwischen dem ERP- und dem EWM-System übertragen werden.
In SAP kann es bei der Nachrichtenübertragung zu Fehlern in der Queue kommen. Solche fehlerhaften Einträge führen schnell zu Inkonsistenzen zwischen den beteiligten Systemen. Tritt während der Übertragung ein Problem auf, bleibt die Nachricht in der Queue stehen und wird nicht weiterverarbeitet. Diese Einträge sind in der Transaktion SMQ2 sichtbar. Dort können sie analysiert und – falls erforderlich – manuell korrigiert werden. Wichtig ist, solche Queue-Fehler zeitnah zu identifizieren und zu beheben, damit der Datenaustausch zwischen den Systemen stabil und reibungslos funktioniert.
Aufzurufen sind die Queueeinträge neben den genannten Transaktionen, aber auch einfach über den Lagerverwaltungsmonitor. Hier findet sich über den Knoten „Werkzeuge“ direkt die „Nachrichten-Queue“:
Hier kann auch ausgewählt werden, ob sowohl Eingangs- als auch Ausgangsqueue berücksichtigt werden sollen und andere Selektionen getätigt werden.
Klassische Einträge sind bei Tests z. B.:
- „Buchen nur in Perioden 2026/02 und 2026/01 möglich im Buchungskreis 1100“ → Die Periode wurde nicht korrekt geöffnet und es kann nicht verbucht werden
- „Sie haben keine Berechtigung für diesen Vorgang mit Bewegungsart 411“ → Berechtigungen wurden nicht korrekt vergeben
- „Das angeforderte Objekt XY ist momentan gesperrt durch User XY“ → Falls bereits ein anderer Nutzer zur selben Zeit auf ein Objekt zugreift, landet auch dann der Eintrag in der Queue
- „Es ist kein Positionstyp vorhanden (Tab. T184L LF 0001 CHSP )“ → Dies geht etwa in die Richtung von fehlendem Customizing
Wenn die Ursache bereits aus den Meldungen abgeleitet werden kann, ist dies schon einmal ein weiterer Schritt – aber leider nach wie vor nicht die Lösung der Ursache. Je nachdem müssen dann entsprechend Berechtigungen nachgeschärft werden (lesen Sie in diesem Artikel, wie) oder das Customizing nachgetragen bzw. korrigiert werden. Teilweise helfen auch die Message-ID, die Nachrichtennummer und der Hinweis. Diese können in der Internetrecherche verwendet werden.
Ist der Fehler behoben, kann der Queue-Eintrag nochmal angestoßen werden und läuft dann durch – oder hängt am nächsten Fehler und die Analyse darf von vorne beginnen; ein Szenario, welches viele EWM Berater gut kennen.
Sperrkonflikte
Wie erläutert, können sich Nutzer gegenseitig sperren, sodass andere Nutzer gewisse Funktionen nicht ausführen können. Einträge können dann z. B. bei der Hintergrundverarbeitung in der Queue landen oder der Nutzer kommt gar nicht erst an die Funktion, die er ausführen möchte. Um Sperren anzusehen, kann die Transaktion SM12 verwendet werden. Hier können Sperren auch aufgehoben werden. Aber Achtung: das sollte natürlich nur ausgeführt werden, wenn klar ist, dass der betroffene Nutzer aktuell keine aktive Bearbeitung vornimmt. Besser ist es immer, wenn der Nutzer selbst die Transaktion verlässt.
In folgendem Beispiel sperrt der Nutzer einen Lagerauftrag (WHO):
Berechtigungsfehler im EWM
Berechtigungsfehler sind bei der Fehlersuche im EWM häufig unterschätzt wird. Denn nicht jeder Fehler ist ein Customizing- oder Prozessproblem – oft steckt schlicht eine fehlende oder falsch zugeordnete Rolle dahinter. Typisch sind Fälle, in denen ein Benutzer zwar eine Lieferung anzeigen, aber keine Lageraufgabe bestätigen kann oder bestimmte Knoten im Lagerverwaltungsmonitor nicht sieht. Gerade im EWM mit seiner Vielzahl an Transaktionen (/SCWM/*), RF-Transaktionen, PPF-Aktionen und Hintergrundverarbeitungen greifen Berechtigungsobjekte auf unterschiedlichen Ebenen.
Ob ein Berechtigungsproblem vorliegt, kann über die Transaktion SU53 geprüft werden. Hier finden sich die fehlgeschlagenen Berechtigungsprüfungen. Aber Achtung: Die Liste beinhaltet auch teilweise Einträge, die der Nutzer nicht aktiv angefragt hat und entsprechend nicht braucht! Mehr zu den Berechtigungen und Rollen im EWM finden Sie in unserem zugehörigen Blogbeitrag.
Aus Projekten wissen wir: Eine saubere Rollenkonzeption, klare Trennung von Dialog- und Hintergrundbenutzern sowie eine strukturierte Analyse mit SU53, STAUTHTRACE oder dem Berechtigungs-Trace sind oft der schnellste Weg zur Lösung.
Ganz klassisch: Dumps
Klassisch sind im SAP Umfeld auch die Dumps. Vor allem noch in der Testphase vor Go-Live bei Änderungen in der Programmierung können diese häufig auftreten. Tritt ein Dump auf, erhält der betroffene Nutzer direkt die relevanten Fehlerinformationen, die er zur weiteren Analyse weiterleiten kann. Wenn er diese nicht mehr vorliegen hat, lassen sich Dumps über die Transaktion ST22 nachvollziehen. In der Regel ist hier ein Entwickler gefragt, der die dortigen Informationen korrekt interpretieren und deren Ursprung finden kann.
Was ist mit einer HU passiert? Welche LBs wurden wann bearbeitet?
Häufig treten auch „Fehler im EWM“ auf, die schlicht durch die falsche Benutzung entstanden sind. User quittieren Lageraufgaben etwa falsch und entnehmen Bestand von der falschen HU, was zu Bestandsdifferenzen auf den betroffenen HUs führt. Um hier zu verstehen, was passiert ist, hilft ein Blick in die Lageraufgaben, z. B. zur jeweiligen HU. Darüber kann nachvollzogen werden, was wann entnommen wurde oder etwa, was dazu geschüttet/gepackt wurde. Ebenfalls ist nachvollziehbar, welcher User dies ausgeführt hat und wann. Über diesen „Blick in die Vergangenheit“ lassen sich viele einzelne Schritte nachvollziehen. Ausführbar ist dies über die Methoden im Lagerverwaltungsmonitor /SCWM/MON.
Was genau hat ein Benutzer ausgeführt?
Wenn genauer analysiert werden soll, was ein Benutzer nun wie gemacht hat, empfiehlt sich ein Blick in die Logs. Über die Transaktionen SLG und SLGD kann eingesehen werden, welcher Nutzer was ausgeführt hat. Damit diese Auswertung sinnvolle Ergebnisse liefert, müssen die richtigen Benutzer, Zeitpunkte und z. B. Klassen oder Fehlermeldungen mitgegeben werden. Wenn zuvor die Lageraufgaben analysiert wurden, kann in jenen Transaktionen zur Zeit der Quittierung nachgesehen werden, welche Schritte der User genau unternommen hat.
Achtung: Wie viele Aktionen geloggt werden, kann eingestellt werden. Zu Go-Live Zeiten empfiehlt sich daher ein detailliertes Log. Später kann dieses wieder reduziert werden.
Unser Top-Tipp bei Schiefständen
Sie haben Schiefstände im SAP EWM System? Diese treten vor allem bei Tests auf, wenn noch viel am Customizing gedreht wird oder eigene Programmierungen ziehen. EWM hat hierauf eine Antwort: Die Transaktion CHM_LOG. Etwas ungewohnt zu bedienen, können mit dieser verschiedenste Ad-Hoc Prüfungen durchgeführt werden und so etwa schiefe oder negative Bestände gefunden und danach auch direkt über die Transaktion aufgelöst werden. Aber auch darüber hinaus sind verschiedenste Auswertungen zu Lieferungen und Belegen möglich. In den folgenden Screenshots wurde eine Ad-Hoc Prüfung auf negative physische Menge durchgeführt und die gefundenen Einträge können dann auch direkt gelöscht bzw. reduziert werden.
Ausblick auf härtere EWM-Fehler
Häufig sind Fehler dann auf das fehlerhafte Customizing oder eben Fehler im Programmcode zurückzuführen. Da die einzelnen Fälle zu spezifisch sind, gibt es keine allgemein gültige Lösung zur Fehlerbehebung. . Wir empfehlen jedoch noch folgende Punkte:
- Es hakt irgendwo, z. B. in der Inventur, aber Sie wissen nicht, wo genau? In solchen Fällen gehen wir meist nochmal dem IMG-Pfad der Inventur nach und klicken die einzelnen Customizingmöglichkeiten durch – häufig findet sich dort die Antwort auf das Problem
- Transaktion SM30: Eine Tabelle muss laut Fehlermeldung gepflegt werden, aber Sie wissen nicht wo? Finden sie den SPRO-Pfad einfach über diese Transaktion
- Googeln Sie ihre Fehlermeldungen (vor allem die technischen Bezeichnungen dieser) – häufig hatten bereits andere Personen in SAP Help Foren diese Probleme und schildern, wie sie den Fehler gelöst haben
- Debuggen: Wenn der Fehler in der Programmierung liegt, hilft am Ende natürlich Debuggen am besten weiter, um zu verstehen, wie sich das Programm verhält und wann es falsch abbiegt – und warum.
Hilfreiche Transaktionen im Überblick
Im Verlauf des Beitrags haben wir immer wieder Transaktionen genannt. Hier finden Sie sie im Überblick – inklusive tiefgreifenderen Transaktionen im Umfeld der Fehlersuche.
- SLG1 – Anwendungslog auswerten
- SLGD – Anwendungsprotokolle auswerten
- ST22 – Analyse von Dumps
- SM12 – Sperreinträge
- /SCWM/WOLOG – Protokoll für Lageraufträge aktivieren
- /SCWM/CHM_PRF – Prüfprotokollanalyse
- /SCWM/CHM_LOG – Erkennen von Inkonsistenzen
- /SCWM/ACTLOG – Application Log für EWM aktivieren
- /IWFND/ERROR_LOG – Fehlerprotokoll von SAP Gateway
- STATS_FE – Nachvollziehbarkeit von Klicks in Fiori
Fazit
Die Fehlersuche im SAP System ist selten einfach – erst recht nicht im SAP EWM Modul. Viele Nutzer klagen hier über Fehlermeldung mit nur wenig konkreter Aussage und kaum Hilfe zur Lösung. Da muss man schon mehr Erfahrung mitbringen, um einem komplexeren Fehler auf die Schliche zu kommen – und um ihn am Ende auch erfolgreich zu beheben. Da braucht es schon meist ein paar Jahre der EWM Erfahrung.
Sollten Sie vor einem hartnäckigen Fehler stehen, den Sie nicht lösen können, probieren Sie unsere Tipps und Tricks aus. Wenn Sie weitere Unterstützung benötigen, melden Sie sich bei uns. Unsere EWM Experten helfen Ihnen gerne!
Das könnte Sie auch interessieren: