Odoo Inventory: Lagerverwaltung im ERP und Grenzen

Der Shop zeigt drei Stück verfügbar. Das Lager findet beim Kommissionieren nur eins. Der Einkauf hat längst nachbestellt, weil seine Tabelle einen anderen Stand kennt. Und am Monatsende bewertet die Buchhaltung einen Bestand, den so niemand mehr im Regal hat. Vier Sichten auf dieselbe Ware, vier Wahrheiten.

Das Bild wiederholt sich, sobald ein Unternehmen über einen Kanal hinauswächst: Der Verkauf bucht im Shopsystem, das Lager pflegt eine eigene Liste, der Einkauf rechnet in Excel, und die Werte driften jeden Tag ein Stück weiter auseinander. Jede Korrektur ist Handarbeit. Die Fragen dahinter sind immer dieselben:

Warum stimmt der verfügbare Bestand im Shop nie mit dem realen Lager überein? Wer hat recht, wenn Einkauf, Verkauf und Buchhaltung drei verschiedene Mengen melden? Lassen sich mehrere Standorte, Chargen und Seriennummern sauber abbilden, ohne ein zweites System danebenzustellen?

Hinter all dem steckt ein Datenproblem: Solange jeder Kanal seinen eigenen Stand hält, gibt es keinen verlässlichen Bestand, nur Versionen davon.

Odoo trennt sauber zwischen Lagern und Lagerorten. Ein Lager ist das physische Gebäude, ein Lagerort eine Zone, ein Gang oder ein Regalplatz darin. Dazu kommen logische Orte, die kein Regal sind: Transit zwischen zwei Standorten, ein Produktionsort, ein Verlustort für Inventurdifferenzen, virtuelle Orte für Lieferanten und Kunden. Diese Struktur klingt nach Buchhaltung. Sie ist es auch, nur übertragen auf physische Ware.

Der Weg einer Position durch das Lager ist damit immer vollständig protokolliert. Kein Stück verändert seinen Bestand, ohne dass eine Bewegung mit Quelle und Ziel entsteht. Das ist der Unterschied zwischen „wir glauben, es sind noch zwölf" und „zwölf Stück liegen auf diesem Lagerort, zuletzt bewegt am Dienstag durch diesen Beleg". Die erste Aussage führt zu Diskussionen, die zweite zu Entscheidungen.

Diese Genauigkeit ist auch die Voraussetzung für alles, was darauf aufbaut. Die Inventur lässt sich als geplante, wiederkehrende Zählung einzelner Lagerorte oder Artikelgruppen fahren: ein Cycle Count, der schnelldrehende Ware häufiger prüft und ruhige Bestände seltener, statt einmal im Jahr das ganze Lager stillzulegen. Jede dabei gefundene Abweichung wird über den Inventurdifferenz-Lagerort gebucht und bleibt damit nachvollziehbar. Eine Rückverfolgung funktioniert, weil jede Bewegung an einem Beleg hängt. Und die Bewertung in der Buchhaltung kann automatisch mitlaufen, weil jeder Mengenfluss bereits ein gebuchter Vorgang ist.

Wer Lebensmittel, Kosmetik, Pharmanahes oder technische Produkte bewegt, ist auf lückenlose Rückverfolgbarkeit angewiesen, regulatorisch wie betrieblich. Odoo führt sie über Chargen und Seriennummern. Eine Charge fasst eine Produktionsmenge zusammen, eine Seriennummer identifiziert ein einzelnes Stück. Beide werden über den gesamten Weg mitgeführt: Wareneingang, Lagerung, optional Produktion, Versand.

Das zahlt sich im Ernstfall aus. Kommt eine Reklamation oder ein Rückruf, lässt sich vorwärts wie rückwärts auflösen, welcher Wareneingang in welche Lieferung geflossen ist und welcher Kunde welche Charge erhalten hat. Für Entnahmestrategien wie FIFO oder das verfallsorientierte FEFO ist die Chargenführung die Grundlage. Ohne sie bleibt jede Strategie eine Absichtserklärung.

Die Erfassung läuft über Barcodes. Odoo unterstützt das Scannen per 1D- und 2D-Codes; mit Odoo 18 kam ein Barcode-Scanner als progressive Web-App dazu, der ohne native Installation auf dem Mobilgerät läuft. Damit werden Wareneingang, Umlagerung und Kommissionierung am Regal gebucht, nicht hinterher am Schreibtisch. Der Effekt ist weniger Übertragungsfehler und ein Bestand, der dem realen Lager näher kommt. Wichtig für die Planung: Das Barcode-Scanning gehört zu den Funktionen, die in der Community-Edition fehlen.

Für Handels- und Versandbetriebe entscheidet die letzte Meile. Odoo bringt Anbindungen an gängige Versanddienstleister mit, sodass Versandart, Label und Tracking aus dem Lieferschein heraus entstehen, statt in einem getrennten Versandtool. Über den Verkauf und die Shop-Anbindung lässt sich derselbe Bestand über mehrere Kanäle führen: ein Stand für eigenen Shop, Marktplätze und stationären Verkauf, statt einer Reservierungstabelle je Kanal.

Genau das ist der Punkt, an dem viele Insellösungen kippen. Drei Kanäle mit drei Beständen erzeugen Überverkäufe, sobald dasselbe Stück zweimal verkauft wird, bevor die Stände abgeglichen sind. Ein gemeinsamer Bestand löst das an der Wurzel, weil die Reservierung beim Verkauf sofort auf den einen Lagerstand wirkt.

Wo die Standard-Connectoren enden, beginnt die Integrationsarbeit. Tiefe Carrier-Anbindungen, 3PL-Schnittstellen, EDI mit Handelspartnern oder die Anbindung von Förder- und Verpackungstechnik im Lager sind kein Modul-Klick, sondern Entwicklung über eine API. Für externe Schnittstellen zu Drittsystemen verlangt Odoo zudem den passenden Lizenz-Plan. Dass das im Hochvolumen funktioniert, haben wir an einer eigenen Maschinenanbindung im Lager gezeigt, bei der eine selbst entwickelte Middleware Odoo direkt mit der Verpackungsstraße verbindet. Der durchgängige Auftragsfluss davor, von der Verkaufschance bis zum bestätigten Auftrag, läuft über die Module CRM und Sales, die direkt in die Lagerreservierung übergeben.