Multilager
Überblick
Mehrere Lagerorte mit Vorrang und eigener Bestandsbewertung. Das Default-Lager übernimmt die Bestandsauflösung — es ist die Voreinstellung, wenn kein anderes bestimmt ist.
Vier Ebenen bauen aufeinander auf: Lagerort → Lagerplätze → Nachschub-Regeln → Bestand. Der Bestand je Lager ist dabei nur lesend; Buchungen entstehen über Umlagerungen und die Buchungswege der anderen Module — nie durch direktes Eintragen.
Kernaufgaben
Lagerorte pflegen. Je Ort Vorrang und Bewertung; der Klick auf die Zeile öffnet das Detail mit Lagerplätzen, Nachschub-Regeln und Bestand.
Lagerplätze ordnen. Bins werden nach Kommissionier-Reihenfolge sortiert: Pick-Priorität aufsteigend, dann Code. Diese Reihenfolge ist der Laufweg im Lager — wer sie sinnvoll setzt, spart bei jeder Kommissionierung Schritte.
Nachschub-Regeln setzen. Min/Max je Produkt: Fällt der verfügbare Bestand unter Min, entsteht ein Vorschlag, bis Max aufzufüllen. Es gibt genau eine Regel je Lager × Produkt — zwei widersprüchliche Regeln kann es damit nicht geben.
Konsignation führen. Lager → Konsignation zeigt, was beim Kunden liegt, was er verbraucht hat und was davon noch nicht berechnet ist. Der Ablauf hat drei Schritte: Bestand beim Kunden sehen (der Arbeitsvorrat „verbraucht und noch nicht berechnet"), Verbrauch melden (Artikel, Menge, optional die Referenz des Kunden-Belegs) und als berechnet vermerken, sobald die Rechnung raus ist. Solange die Ware im Konsignationsregal liegt, gehört sie uns — Erlös entsteht erst mit der Verbrauchsmeldung. Wer den Rückweg nicht von Hand abhaken will, lässt ihn von einer Automation am Ereignis Konsignations-Verbrauch gemeldet erledigen.
Umlagern. Eine Umlagerung läuft dreistufig: Entwurf anlegen → versenden (Abgang) → empfangen (Zugang). Die Ware ist zwischen Abgang und Zugang unterwegs und in keinem der beiden Lager verfügbar — genau so, wie es der Wirklichkeit entspricht.
Vorschläge lagerübergreifend prüfen. Die Auswertung aller Nachschub-Regeln zeigt, wo aufgefüllt werden muss.
B-Ware getrennt führen. Der Bestand je Lager ist nach Artikelzustand getrennt: Neuware, B-Ware/gebraucht, geprüft wiederaufbereitet und beschädigt stehen je in einer eigenen Zeile. Eine Retoure bucht die Ware in dem Zustand ein, den Sie an der Retourenposition erfasst haben — eine gebrauchte Rücksendung landet also nie im Neuwarenbestand. Verkaufbar für Aufträge ist nur Neuware; Nachschub-Regeln, Einlagerungsvorschlag und Inventur gibt es je Zustand (Vorgabe Neuware): eine Regel für B-Ware überwacht nur B-Ware, die Inventur zählt jeden Zustand in einer eigenen Zeile. Geprüfte B-Ware wird über Zustand umbuchen wieder Neuware; ein Kanal-Angebot mit Zustand liest genau dessen Bestand. Auch die Verteilung auf Lagerplätze gilt je Zustand: Auf einen Platz lässt sich B-Ware nur verorten, soweit B-Ware-Bestand noch nicht verortet ist (beim Einlagern den Zustand mit angeben).
Felder im Detail
Die Spalte Was es bewirkt beantwortet, was sich im System ändert — nicht, wie das Feld heißt. Der graue Name dahinter ist das Feld der API: unter ihm läuft dasselbe über Automation, Import und KI-Werkzeuge.
Lager anlegen und bearbeiten
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Kürzel code | ja | Text, max. 30 Zeichen | Die Kennung des Lagers in Buchungen, Etiketten und Auswertungen. Nicht mehr ändern, sobald Bestand darauf liegt. |
Name name | ja | Text, max. 100 Zeichen | Wie das Lager in Auswahl und Übersicht heißt. |
Lagerart type | nein | eigenes Lager (Vorgabe), Konsignationslager oder Dienstleister-Lager | Wem das Lager gehört und wer darin bucht. Ein Konsignationslager hält unsere Ware beim Kunden: Die Einlagerung ist eine Umlagerung ohne Erlös, berechnet wird erst der Verbrauch. Ein Dienstleister-Lager hält unsere Ware in einem fremden Betrieb: Dort wird für uns kommissioniert, und der Bestand kommt als Meldung des Dienstleisters herein, nicht aus unserer Buchung. |
Kunde des Konsignationslagers partnerCustomerId | bei Konsignation | bestehender Kunde | Bei wem das Lager steht. Ohne ihn wüsste die Verbrauchsmeldung nicht, wem sie berechnet wird. |
Betreibender Dienstleister partnerSupplierId | nein | bestehender Lieferant | Wer das Dienstleister-Lager betreibt. Freiwillig: Was ein solches Lager ausmacht, sind seine Meldungen, nicht ein Stammsatz. |
Kennung beim Dienstleister externalCode | nein | Text, max. 60 Zeichen | Unter welcher Kennung der Dienstleister dieses Lager führt. Er kennt uns unter seiner Nummer, nicht unter unserem Kürzel — ohne sie lassen sich seine Meldungen nicht zuordnen. |
Standard isDefault | nein | Ja/Nein | Welches Lager gewählt wird, wenn nichts anderes angegeben ist. Es gibt genau eines; die Auszeichnung wandert. |
Priorität priority | nein | Zahl | In welcher Reihenfolge Lager für eine Entnahme herangezogen werden. Kleinere Zahl heißt früher — so wird zuerst dort entnommen, wo es am günstigsten ist. |
Bewertungsverfahren valuationMethod | nein | FIFO oder Durchschnitt | Wie der Bestandswert gerechnet wird. FIFO bewertet nach Zugangsreihenfolge, Durchschnitt mit dem gleitenden Mittel. Das Verfahren nachträglich zu wechseln ändert den ausgewiesenen Lagerwert — es ist eine buchhalterische Entscheidung, keine Einstellung. |
Aktiv active | nein | Ja/Nein | Aus heißt: keine neuen Buchungen. Vorhandener Bestand bleibt sichtbar und muss erst umgelagert werden. |
Umlagerung
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Von Lager fromWarehouseUlid | ja | bestehendes Lager | Woher die Ware kommt. |
Nach Lager toWarehouseUlid | ja | bestehendes Lager | Wohin sie geht. |
Positionen items | ja | Artikel mit Menge | Was umgelagert wird. Mehr als vorhanden lässt sich nicht buchen. |
Bemerkung note | nein | Text | Warum umgelagert wird. |
Eine Umlagerung ist zweistufig: Der Abgang wird gebucht, die Ware gilt als unterwegs, und erst der Zugang schreibt sie dem Ziellager gut. Dazwischen ist sie nirgends verfügbar — das ist gewollt und bildet die Wirklichkeit ab, statt Bestand zu verdoppeln.
Nachschub-Regel
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Artikel productId | ja | lagergeführter Artikel | Welcher Artikel überwacht wird. |
Minimum minQty | ja | ganze Zahl | Fällt der verfügbare Bestand darunter, entsteht ein Vorschlag. |
Maximum maxQty | ja | ganze Zahl, mindestens das Minimum | Bis wohin aufgefüllt wird. |
Quell-Lager sourceWarehouseId | nein | anderes Lager | Woher umgelagert wird; leer heißt Nachbestellung. |
Zielplatz targetBinId | nein | Lagerplatz des Lagers | Mit Platz überwacht die Regel diesen Greifplatz und schlägt Nachschub aus der Reserve vor; ohne Platz gilt sie für das ganze Lager. |
Quellplatz sourceBinId | nein | Reserveplatz des Lagers | Fester Reserveplatz für den Nachschub; leer heißt der mengenstärkste Reserveplatz. |
Zustand condition | nein | Neuware (Vorgabe), B-Ware/gebraucht, geprüft wiederaufbereitet, beschädigt | Welchen Bestand die Regel überwacht. B-Ware deckt kein Neuware-Minimum; je Zustand gibt es eine eigene Regel. |
In der Registerkarte Nachschub-Regeln steht der Zustand jeder Regel in einer eigenen Spalte; im Dialog wählen Sie ihn beim Anlegen und beim Ändern (Vorgabe Neuware).
Nur über Schnittstelle und Automation
Diese Felder trägt keine Maske; sie lassen sich über die Schnittstelle, einen Import oder eine Automation setzen.
| Feld | Werte / Format | Was es bewirkt |
|---|---|---|
singleProductBins | Ja/Nein (Vorgabe: nein) | Sortenreine Einlagerung: auf einem Platz liegt höchstens ein Artikel. Eine Verortung auf ein Fach mit fremdem Artikel wird abgewiesen. Wer sortenrein lagert, greift blind — ein zweiter Artikel im Fach wird zum unbemerkten Fehlgriff. Aus heißt: Mischplätze sind erlaubt. |
putawayTargetRequired | Ja/Nein (Vorgabe: nein) | Pflicht-Zielplatz: ein Zugang ohne Platzangabe wird abgewiesen. Unverortete Menge ist Ware, die das Buch kennt und niemand findet. Aus heißt: unverortete Menge bleibt erlaubt. |
autoPutawayToDefaultBin | Ja/Nein (Vorgabe: nein) | Zugänge ohne Platzangabe landen auf dem Vorgabeplatz des Artikels, statt unverortet zu bleiben. Ohne gepflegten Vorgabeplatz ändert sich nichts. |
putawayStrategy | freier Platz, Name auf-/absteigend, Sortierung auf-/absteigend (Vorgabe: Sortierung aufsteigend) | Reihenfolge, in der freie Plätze beim Einlagern vorgeschlagen werden. Freier Platz füllt Lücken, die Namensstrategien laufen den Gang systematisch ab. Steht bewusst hier statt im Anlegen-Dialog: es ist einer von vier Einlagerungs-Schaltern, und die drei darüber gehören ebenso wenig in eine Maske, in der man ein Lager erst anlegt. |
address | Anschrift als strukturierte Angabe (Straße, PLZ, Ort, Land) | Wo das Lager liegt. Wird als Lieferanschrift für Bestellungen vorgeschlagen. |
Einstellungen & Rechte
- Modul
module.warehouses. warehouses.warehouse.view/.manage,warehouses.stock.view/.manage,
warehouses.transfer.manage.
- Der Gesamtbestand steht im Produktkatalog — hier steht seine Verteilung.
- Der Einkauf löst keine Umlagerung aus. Zeilen aus einem anderen Lager werden dort abgewiesen,
siehe Einkaufslisten.
FAQ & Fehlerbilder
Der Bestand im Lager lässt sich nicht ändern. So gewollt — er ist nur lesend. Buchen Sie über eine Umlagerung oder den Weg des jeweiligen Moduls.
Nach dem Versenden fehlt die Ware überall. Sie ist unterwegs. Erst das Empfangen bucht sie im Ziel zu.
Es entsteht kein Nachschub-Vorschlag. Prüfen Sie, ob für Lager und Produkt eine Regel existiert und ob der verfügbare Bestand wirklich unter Min liegt.
Zwei Regeln für dasselbe Produkt. Gibt es nicht — je Lager und Produkt ist genau eine Regel möglich.
Ein Artikel steht zweimal in der Bestandsliste. Er liegt in zwei Zuständen vor, zum Beispiel als Neuware und als B-Ware. Die Spalte Zustand zeigt, welche Zeile welche ist; mit dem Filter Zustand sehen Sie nur einen davon.
Der Zustand einer eingelagerten Retourenposition lässt sich nicht ändern. So gewollt: Die Ware steht bereits im Bestand des alten Zustands. Stellen Sie erst die Verwendung um (Ware geht wieder aus dem Lager), ändern Sie dann den Zustand und lagern Sie neu ein.