JTL WMS Lagerübersicht mit abweichendem Bestand in Wawi-Vergleichsansicht

JTL WMS Lagerbestand stimmt nicht: Warum Wawi und WMS unterschiedliche Mengen zeigen

Du öffnest JTL-Wawi, rufst einen Artikel auf und siehst 47 Stück auf Lager. Du öffnest JTL-WMS und siehst dort 39. Beide Systeme greifen auf dieselbe Datenbank zu — trotzdem weichen die Zahlen ab. Das ist kein Einzelfall. Wir sehen das regelmäßig, und fast immer gibt es eine klare Ursache.

Woher kommt die Differenz zwischen WMS- und Wawi-Bestand? Und wie findest du das ohne stundenlangen Detektivlauf heraus?

Bestandsabweichungen zwischen JTL-WMS und JTL-Wawi entstehen durch sechs wiederkehrende Ursachen: gesperrte Lagerplätze, offene Umlagerungen, MDE-Scan-Fehler, Stücklisten-Probleme, doppelte Inventurbuchungen und Sync-Verzögerungen. Dieser Beitrag zeigt dir, wie du systematisch vorgehst — ohne Daten zu verlieren und ohne blind Bestände zu korrigieren.

Auf einen Blick

  • ✓Gesperrte Lagerplätze sind die häufigste Ursache — Wawi zeigt den Gesamtbestand, WMS nur den tatsächlich verfügbaren.
  • ✓Offene Umlagerungen blockieren Bestand still im Hintergrund, ohne sichtbare Fehlermeldung.
  • ✓Vor jeder Bestandskorrektur die Bewegungshistorie prüfen — sonst behebt man Symptome statt Ursachen.

Wir, die Vlarom E-Commerce Agentur, sind JTL Service Partner Gold aus Ahrensfelde bei Berlin und betreuen Händler deutschlandweit, die JTL-WMS täglich in vollautomatisierten Lagern einsetzen — von der Einführung bis zum laufenden Betrieb. Bestandsabweichungen zwischen WMS und Wawi gehören zu den Themen, mit denen wir uns am häufigsten befassen. Nicht weil das System schlecht wäre, sondern weil WMS-Lager komplex sind und viele Prozesse parallel laufen.

Wie häufig tritt das Problem auf, und was steckt dahinter?

Bestandsabweichungen klingen nach einem seltenen Fehler. In der Praxis ist das Gegenteil der Fall. Bei jedem Händler, der JTL-WMS neu einführt oder nach einem Update migriert, taucht mindestens eine der sechs Ursachen auf. Die Frage ist nicht ob, sondern wann — und wie schnell man das erkennt.

Quelle: interne Projektdaten — Auswertung aus WMS-Einführungsprojekten und WMS-Support-Tickets 2023–2025.

Was wir aus unserer Projektpraxis wissen:

  • →Über 70 % der Fälle: betreffen entweder gesperrte Lagerplätze oder offene Umlagerungen — beides lässt sich direkt in der WMS-Oberfläche prüfen, ohne in die Datenbank zu gehen.
  • →Doppelte Buchungen nach Inventur: sind ein bekanntes Muster: Ein gemeldetes Issue beschreibt, wie der Lagerstand in JTL-Wawi doppelt angezeigt wurde, obwohl die WMS-Inventur korrekt abgeschlossen war. Ursache war ein Fehler beim Abschluss-Commit (Quelle: forum.jtl-software.de, WMS-Thread 0.9.9915).
  • →Gesperrte Reklamationslager: erzeugen eine klassische Verwirrung: In der Wawi-Artikelübersicht steht der Gesamtbestand inklusive gesperrter Mengen — im WMS-Picklauf ist der Artikel aber nicht verfügbar. Ein Händler im JTL-Forum: ‚Es wird uns 3 Stück angezeigt, aber nur 2 sind greifbar, weil 1 Stück im Reklamationslager ist.‘ (forum.jtl-software.de)

Die gute Nachricht: Fast alle Bestandsabweichungen sind erklärbar und behebbar, wenn man die Ursache systematisch einkreist. Blinde Bestandskorrekturen lösen das Problem nicht. Sie überdecken es und erschweren die spätere Diagnose.

Die 6 häufigsten Ursachen für WMS-Bestandsabweichungen

Nicht jede Differenz zwischen WMS und Wawi ist ein Fehler. Manche sind gewollt, zum Beispiel wenn Lagerplätze gesperrt sind. Andere entstehen durch Prozessfehler, die sich über Tage aufschichten. Hier sind die sechs Ursachen, die wir am häufigsten sehen.

Häufigste Ursache

Gesperrte Lagerplätze

Lagerplätze können in JTL-WMS für die Auslieferung gesperrt sein (Feld: ‚Für den verfügbaren Bestand sperren‘). Der Bestand liegt physisch da, wird aber vom Picksystem nicht als verfügbar gewertet.

Wawi zeigt den Gesamtbestand inklusive gesperrter Mengen. WMS zeigt nur den verfügbaren. Dadurch entstehen Differenzen, die kein Fehler sind — aber trotzdem irritieren. Prüfe im WMS unter Lagerplatzübersicht den Status jedes auffälligen Platzes.

Stille Falle

Offene Umlagerungen

Wenn eine Umlagerung im WMS angestoßen aber nicht abgeschlossen wurde, ist der Bestand am Quellplatz bereits reserviert — aber am Zielplatz noch nicht angekommen.

Das Ergebnis: Wawi zeigt den Soll-Bestand, WMS sieht die Reservierung. Abgebrochene Umlagerungen bleiben manchmal tagelang offen, besonders nach MDE-Verbindungsabbrüchen. Öffne im WMS die offenen Umlagerungsaufgaben und prüfe, welche davon hängen.

Prozessfehler

MDE-Scan-Fehler beim Wareneingang

Wenn ein Artikel beim Wareneingang doppelt gescannt oder falsch bestätigt wird, bucht WMS eine falsche Menge ein. Der Wawi-Bestand steigt korrekt, der physische Bestand stimmt aber nicht überein.

Das Gegenteil passiert auch: Scan abgebrochen, Artikel liegt am Wareneingangsplatz, wurde aber nicht vollständig in den WMS-Bestand übernommen. Prüfe in solchen Fällen die Bewegungshistorie des betroffenen Artikels im WMS.

Systemkomplexität

Stücklisten-Probleme

Stücklisten-Artikel werden in JTL-WMS anders behandelt als Einzelartikel. Wenn ein Stücklisten-Vater verkauft wird, zieht das System die Bestandskomponenten ab. Fehlt die korrekte WMS-Konfiguration für den Vaterartikel, entstehen Diskrepanzen.

Ein häufiges Muster: Der Vaterartikel zeigt in Wawi Bestand, weil die Einzelkomponenten noch da sind — aber WMS kann keinen vollständigen Picklauf für den Vater anlegen. Prüfe die WMS-Konfiguration der Stücklisten-Artikel separat.

Bekannter Bug

Doppelte Buchungen nach Inventur

Nach WMS-Inventuren tauchen gelegentlich doppelt gebuchte Bestände auf: Die WMS-Inventur zeigt alles korrekt, Wawi aber die doppelte Menge. Ursache ist ein Buchungsfehler beim Inventur-Commit.

Ein gemeldetes Issue aus der Community beschreibt exakt dieses Muster: ‚Lagerstand falsch obwohl Inventur mit WMS korrekt.‘ Die History zeigt dann, dass der Bestand zweifach gebucht wurde. In diesem Fall hilft nur eine gezielte Minusbuchung im WMS nach Prüfung der History.

Infrastruktur

Sync-Verzögerungen und Verbindungsabbrüche

JTL-WMS kommuniziert mit Wawi über den JTL-WMS-Server. Bei Netzwerkproblemen, Server-Neustarts oder zu kurzen Timeout-Einstellungen können Buchungen im Puffer hängen bleiben.

Das Ergebnis: Wawi und WMS zeigen kurzzeitig unterschiedliche Bestände — was sich nach erneutem Verbindungsaufbau von selbst löst. Wenn die Differenz nach einem Neustart verschwindet, war die Ursache ein Sync-Problem, kein Datenfehler.

Was hilft, und was du besser lässt

Was funktioniert

Bewegungshistorie im WMS lesen, bevor irgendwas korrigiert wird. Offene Umlagerungsaufgaben prüfen. Lagerplatz-Status kontrollieren. Inventur-Commits nach einem Abbruch erneut prüfen. Das löst über 80 % der Fälle ohne Datenverlust.

Was nicht funktioniert

Blinde Bestandskorrekturen via Plus- oder Minusbuchung ohne vorherige Diagnose. Das überdeckt die eigentliche Ursache und erzeugt neue Inkonsistenzen — besonders wenn es sich um einen offenen Inventur-Commit handelt.

Die Lektion

Aus der Projektpraxis: Die Bewegungshistorie in JTL-WMS ist das wichtigste Werkzeug bei Bestandsdifferenzen. Dort ist jeder Buchungsvorgang mit Zeitstempel, Benutzer und Mengenänderung dokumentiert. Wer dort anfängt, spart sich den Umweg über die Datenbank.

Strukturierte Diagnose: So gehst du vor

Bevor du irgendeinen Bestand korrigierst, lege ein Backup an. Bestandsbuchungen in JTL-WMS sind nicht einfach rückgängig zu machen. Die folgende Checkliste führt dich von der schnellen Erstdiagnose bis zur gezielten Korrektur — ohne blinde Eingriffe. Ausführliche Informationen zu internen WMS-Prozessen findest du in der offiziellen JTL-Dokumentation unter [guide.jtl-software.com/jtl-wms/interne-prozesse/](https://guide.jtl-software.com/jtl-wms/interne-prozesse/).

Backup sichern und betroffene Artikel dokumentieren

Erstelle vor jeder Bestandskorrektur ein Datenbank-Backup der eazybusiness-Datenbank — auch für scheinbar kleine Korrekturen via Minusbuchung. Notiere alle betroffenen Artikel mit Artikelnummer, Wawi-Bestand, WMS-Bestand und der Differenz. Ob Wawi mehr oder weniger als WMS zeigt, gibt den ersten Hinweis auf die Ursache. Wenn du dir beim Backup unsicher bist, wende dich an einen JTL Service Partner.

Lagerplatz-Status prüfen

Öffne im JTL-WMS die Lagerplatzübersicht (Pfad: WMS > Interne Prozesse > Lagerplatzübersicht). Prüfe für die betroffenen Artikel, ob einer der Lagerplätze den Status ‚gesperrt‘ oder ‚für Auslieferung gesperrt‘ trägt. Das JTL-WMS-Lagerkonzept ist dokumentiert unter guide.jtl-software.com/jtl-wms/. Wenn ein Lagerplatz gesperrt ist, zeigt Wawi den Gesamtbestand inklusive dieser Mengen — WMS berücksichtigt sie bei Pickläufen nicht.

Offene Umlagerungsaufgaben prüfen

Öffne im WMS den Bereich für offene Umlagerungsaufgaben. Suche nach Einträgen, die keinem aktiven Pick zugeordnet sind und schon längere Zeit offen stehen. Abgebrochene Umlagerungen reservieren Bestand am Quellplatz, ohne ihn am Zielplatz gutzuschreiben. Solche Aufgaben müssen gezielt abgeschlossen oder storniert werden.

Bewegungshistorie lesen

Öffne im WMS die Artikelübersicht und rufe für den betroffenen Artikel die Bewegungshistorie auf. Du siehst dort jeden Buchungsvorgang mit Datum, Uhrzeit, Benutzer und Mengenbewegung. Suche nach doppelten Einträgen mit identischem Zeitstempel — das ist ein Indiz für doppelte Inventurbuchungen. Negative Buchungen ohne erkennbaren Auftragsbezug deuten auf Sync-Fehler hin. MDE-Scan-Fehler beim Wareneingang erkennst du daran, dass der Buchungszeitstempel mit einem Wareneingangsvorgang übereinstimmt, die Menge aber nicht stimmt.

Gezielte Korrektur und Verifikation

Wenn du die Ursache eindeutig identifiziert hast, führe die Korrektur durch: gesperrte Lagerplätze entsperren, offene Umlagerungen abschließen, falsche Buchungen via Minusbuchung im WMS ausgleichen. Prüfe danach den Bestand in Wawi und WMS erneut und verifiziere, dass offene Aufträge korrekt beliefert werden können. Eine Teil-Inventur der betroffenen Artikel im Anschluss gibt dir Gewissheit. Wenn die Ursache unklar bleibt, hole dir Unterstützung von einem JTL Service Partner — blinde Korrekturen kosten am Ende mehr Zeit als eine gezielte Analyse.

Häufige Fragen zu WMS-Bestandsabweichungen

Warum zeigt JTL-Wawi mehr Bestand als JTL-WMS?

Das passiert am häufigsten durch gesperrte Lagerplätze. Wawi addiert bei der Bestandsanzeige alle Lagerplätze zusammen — inklusive derer, die für Auslieferung gesperrt sind. WMS dagegen weist gesperrten Bestand als nicht verfügbar aus und zeigt ihn im Picklauf nicht an. Das Ergebnis: Wawi nennt 15 Stück, WMS hat davon 3 auf einem Reklamationsplatz gesperrt und stellt nur 12 für Picks bereit. Das ist kein Systemfehler, sondern das gewollte Verhalten. Prüfe in solchen Fällen zuerst die Lagerplatzübersicht im WMS auf gesperrte Plätze.

Ja, das ist ein bekanntes Muster. Wenn eine Inventur im WMS nicht sauber abgeschlossen wird — durch einen Serverabsturz oder Verbindungsabbruch während des Commits — kann der Bestand in JTL-Wawi doppelt gebucht werden. Das WMS zeigt die korrekten Werte, Wawi aber die doppelte Menge. In der Bewegungshistorie erkennst du das an zwei identischen positiven Buchungen mit demselben oder sehr ähnlichem Zeitstempel. Die Korrektur erfolgt durch eine gezielte Minusbuchung im WMS für die überschüssige Menge — nach vorherigem Backup.

Offene Umlagerungsaufgaben entstehen, wenn ein Lagermitarbeiter eine Umlagerung im WMS angestoßen, aber nicht abgeschlossen hat — zum Beispiel weil die MDE-Verbindung abgebrochen ist oder die Aufgabe manuell abgebrochen wurde. Der Bestand am Quellplatz ist bereits reserviert, kommt am Zielplatz aber nicht an. Im WMS findest du offene Aufgaben über den Bereich Umlagerung. Aufgaben, die länger als einen Arbeitstag offen sind ohne aktiven Benutzer dahinter, solltest du gezielt abschließen oder stornieren.

Ja. Stücklisten-Vaterartikel werden im WMS anders behandelt als einfache Artikel. Wenn die WMS-Konfiguration für einen Vaterartikel fehlt oder falsch gesetzt ist, kann Wawi einen verfügbaren Bestand anzeigen, obwohl WMS keinen vollständigen Picklauf für den Vater anlegen kann. Prüfe bei solchen Artikeln die WMS-Konfiguration des Vaterartikels und stelle sicher, dass alle Komponenten korrekt den zugeordneten Lagerplätzen zugewiesen sind.

Ziehe einen JTL Service Partner hinzu, wenn die Ursache nach der Checkliste unklar bleibt, wenn die Differenz mehrere hundert Artikel betrifft oder wenn du in der Bewegungshistorie Buchungen siehst, die du nicht zuordnen kannst. Bestandskorrekturen ohne gesicherte Diagnose können die Datenbank in einen inkonsistenten Zustand bringen, der schwer zu beheben ist. Als Vlarom E-Commerce Agentur und JTL Service Partner Gold diagnostizieren wir solche Fälle regelmäßig — melde dich gerne für eine erste Einschätzung.

WMS-Support aus der Praxis

Bestandsdifferenz nicht erklärbar? Wir schauen rein.

Wir sind JTL Service Partner Gold und kennen die Muster hinter WMS-Bestandsabweichungen aus der täglichen Projektarbeit. Wenn die Diagnose-Checkliste dein Problem nicht löst oder du dir bei einer Bestandskorrektur nicht sicher bist — ruf uns direkt an unter +49 30 91473862, schreibe an info@vlarom.de oder nutze unser Kontaktformular für eine erste Einschätzung.