Das Regal hat immer recht. Der Bestand nicht.
„Der Bestand stimmt sowieso nie." Diesen Satz habe ich in so vielen Lagern gehört, dass er mir irgendwann wie eine Naturkonstante vorkam.
Er ist nie als Beschwerde gemeint. Er ist eine Arbeitsanweisung: Wer im Lager arbeitet, schaut nicht ins System, sondern ins Regal. Wer im Einkauf arbeitet, schaut ins System — und bestellt nach Zahlen, denen im Lager niemand traut.
Beide haben recht. Und die Differenz zwischen ihnen ist kein Datenproblem, sondern die Summe aller Bewegungen, die stattgefunden haben, ohne dass eine Buchung daraus wurde.
Der Zettel am Stapler
Umlagerungen sind das klassische Beispiel. Ware wird von einem Platz auf einen anderen gestellt, weil es der Ablauf gerade verlangt. Im System steht sie weiter dort, wo sie vorgestern stand. Irgendwann findet jemand sie nicht, sucht zwanzig Minuten und legt dann eine Korrektur an — oder auch nicht.
Die Korrekturen, die trotzdem entstehen, sind der zweite Teil des Problems: Sie kommen gebündelt, oft Tage später, und sie tragen keinen Grund. Eine Bestandskorrektur ohne Anlass ist buchhalterisch eine Wertveränderung, die niemand erklären kann. Beim Jahresabschluss wird daraus eine Diskussion.
Das Lagerverwaltungssystem weiß von all dem. Es hat den Scan, den Platz, den Zeitpunkt. Was fehlt, ist der Weg nach Dynamics 365 — und die Regel, was dort damit passieren darf.
Fünf Journale, nicht eine Schnittstelle
Das Lagermodul von FlexxLink nimmt genau die Journale entgegen, die ein Lager wirklich erzeugt, statt einer Universalschnittstelle für „Bestandsdaten":
Alle diese Nachrichten laufen im selben Arbeitsbereich zusammen — Schnittstellentyp „Lagerjournal". Das ist mehr als Ordnung: Prüfregeln lassen sich je Journalart unterschiedlich setzen, und eine Zählung darf strenger behandelt werden als eine Umlagerung.
Anlegen ist nicht buchen
Der wichtigste Schalter in diesem Modul ist der unscheinbarste. Eine eingehende Nachricht wird geprüft, freigegeben — und dann in Dynamics 365 als Journal angelegt. Gebucht wird sie nur, wenn das ausdrücklich eingestellt ist.
Damit hat man beides zur Auswahl, je Journalart: Umlagerungen laufen automatisch durch, weil sie den Wert nicht verändern; Korrekturen und Zählungen bleiben als Journal stehen, bis jemand sie ansieht. Wer das umgekehrt konfiguriert, bekommt zwei Wochen später eine Inventurdifferenz, die niemand mehr zuordnen kann.
Eine Lagerbewegung ist keine Statusmeldung. Sie ist eine Buchung — und für Korrekturen gilt dasselbe wie für jede andere: erst prüfen, dann freigeben, dann buchen.
Kennzeichen und Chargen — der Teil, der Projekte aufhält
Lagerdimensionen sind der Ort, an dem Integrationen scheitern. Ein Lagersystem meldet ein Kennzeichen, das in D365 noch nicht existiert; eine Charge kommt an, die dort nie angelegt wurde. Klassisch heißt das: Nachricht fällt durch, jemand legt Stammdaten an, Nachricht erneut senden.
Das Modul prüft deshalb geforderte Kennzeichen beim Import und kann fehlende anlegen, wenn die Einrichtung es erlaubt — dasselbe für Chargennummern. Gesucht wird innerhalb des übergebenen Standorts und Lagers.
Zwei Grenzen gehören dazu, und ich nenne sie lieber vorher: übergeordnete Kennzeichen werden nicht automatisch erzeugt, und wenn dieselbe Kennzeichennummer irgendwo anders im Mandanten existiert, läuft die Anlage in einen Fehler. Das ist kein Mangel, sondern die Stelle, an der man sich im Projekt auf eine Nummernlogik einigen muss.
Die Zählung als Kreislauf
Die Inventur ist der Fall, an dem sich zeigt, ob eine Anbindung in beide Richtungen denkt. Aus D365 wird ein Zähljournal an das Lagersystem exportiert — ausgelöst von Hand aus dem Journal heraus, mit allen Zeilen, Lagerdimensionen, Positionsnummern und Artikeldetails.
Gezählt wird dort, wo die Regale stehen. Die Ergebnisse kommen über die eingehende Zählschnittstelle zurück und schreiben in das bestehende Journal statt ein neues anzulegen. Am Ende steht eine Zählung, die von D365 begonnen und von D365 abgeschlossen wurde — dazwischen hat das Lager gearbeitet, nicht die Buchhaltung.
Woran man erkennt, dass die Bewegungen fehlen
Man muss dafür nicht in die Technik schauen. Vier Fragen genügen:
Die zweite Frage ist die unangenehme. Bestandskorrekturen ohne Grund sind der Preis für alle Bewegungen, die nie gebucht wurden — und sie tauchen im Abschluss auf, nicht im Lager.
Was eine Anbindung nicht löst
Sie macht keine Lagerplatzstruktur richtig, die im Regal anders aussieht als im System. Sie ersetzt keine Entscheidung darüber, wer zählen darf und wer korrigieren darf. Und sie ersetzt keine Nummernlogik für Kennzeichen — die muss einmal vereinbart werden, sonst holt sie einen beim ersten Duplikat ein.
Was sie leistet, ist schmaler und wichtiger: Jede Bewegung, die das Lagersystem kennt, wird in D365 zu einem Journal mit Herkunft, Prüfung und Zeitpunkt. Der Rest ist Organisation.
Ein Bestand, dem niemand traut, ist teurer als ein Bestand, der falsch ist. Denn beim falschen Bestand korrigiert man eine Zahl — beim misstrauten Bestand geht jemand nachsehen. Jeden Tag.
Das ist der Überblick. Die Einzelteile — Prüfregeln je Journalart, Kennzeichenlogik, Chargen, die Zählung im Detail — folgen als eigene Beiträge. Wenn bei Ihnen der Satz „der Bestand stimmt sowieso nie" fällt, erzählen Sie mir von Ihrem Lager. Das Modul selbst mit Testzugang gibt es bei soluvine.com — gebaut hat es das Entwicklerteam, mit dem ich seit Damgaard zusammenarbeite.
Diesen Beitrag gibt es auch auf Englisch. Read in English
Alle Beiträge