Reservation-Pattern
Bestand ist nicht gleich Bestand. SpeamCore unterscheidet drei Zustände — physischer Bestand, reservierter Bestand, verfügbarer Bestand. Diese Seite erklärt warum und wie.
Das Problem
Stell dir vor: Auftrag A braucht 10 Schrauben, Auftrag B will auch 10 Schrauben. Im Lager sind 15. Wer bekommt was?
Ohne Reservation: beide Aufträge denken sie haben 15 verfügbar — Konflikt am Tag der Wartung.
Mit Reservation: bei Auftragsanlage werden 10 für A reserviert. B sieht nur noch 5 verfügbar — Disposition kann reagieren.
Die drei Zustände
Pro Produkt + Lager:
- Physisch: was tatsächlich da liegt (real countable)
- Reserviert: für offene Aufträge eingeplant aber noch nicht entnommen
- Verfügbar: physisch − reserviert
Wann wird reserviert?
Bei mehreren Trigger-Events:
- Auftrags-Anlage mit Material-Liste — Material wird vorab reserviert
- Bestellung ausgelöst für Kundenauftrag — eingehender Bestand reserviert
- Manuelle Reservation — z.B. für Großauftrag, wo Material vorab gesichert wird
Lifecycle einer Reservation
Warum nicht direkt abbuchen?
Direkte Abbuchung bei Auftrags-Anlage wäre einfacher. Probleme:
- Bestand stimmt nicht mit Realität — 10 Schrauben sind noch im Lager, aber System sagt 5
- Storno-Probleme — bei Auftrags-Storno müsste rückgängig gebucht werden
- Inventur-Diskrepanz — physische Zählung passt nicht zu Buchbestand
Reservation ist der saubere Mittelweg: Buchbestand = Realität, Verfügbar = nur was noch frei ist.
Sichten in der UI
Lagerprodukte-Tab am Lager
Zeigt pro Produkt:
| Produkt | Physisch | Reserviert | Verfügbar |
|---|---|---|---|
| Schrauben M6 | 100 | 30 | 70 |
| Sirenen Bosch | 5 | 5 | 0 |
Material-Tab am Auftrag
Zeigt was reserviert ist:
| Material | Menge geplant | Menge entnommen | Status |
|---|---|---|---|
| Schrauben M6 | 10 | 0 | reserviert |
| Sirene Bosch | 1 | 1 | entnommen |
Disposition-Sicht
Beim Auftrag-Anlegen wird automatisch geprüft, ob genug verfügbar ist. Wenn nicht: Warnung mit Vorschlag (Bestellen, anderen Auftrag verschieben, kürzere Menge).
Edge-Cases
Reservation ohne Material verbraucht
Wenn der Techniker am Ende weniger verbraucht als reserviert (z.B. nur 8 statt 10 Schrauben):
- Entnahme von 8 buchen
- Reservation auf 8 reduzieren (oder komplett auflösen)
- Verfügbarkeit auf 92 zurück
Reservation überzogen
Wenn der Techniker mehr braucht als reserviert (z.B. 12 statt 10):
- Auftrag-Material-Liste erweitern (KI-Chat oder manuell)
- Neue Reservation für die zusätzlichen 2
- Wenn nicht verfügbar: Sondermaßnahme (Spontan-Bestellung, Tausch zwischen Aufträgen)
Mehrere parallele Aufträge
First-Come-First-Reserve. Wer den Auftrag zuerst anlegt, reserviert zuerst. Bei knappen Beständen Disposition / Lager-Leitung schlichten.
Inventur-Differenzen
Bei Inventur können physische Werte abweichen. Reservation bleibt erstmal, Bestand wird auf neuen Wert korrigiert. Wenn dadurch Verfügbarkeit ins Minus geht: Disposition + Lager + ggf. Sondereinkauf.
Implementations-Detail
Im Backend ist die Reservation eine eigene Tabelle (reservations) mit:
productId(was)warehouseId(wo)amount(wie viel)sourceType+sourceId(vom welchem Auftrag / Bestellung)status(active | consumed | released)
verfügbar = bestand − sum(reservations.amount where status=active und warehouse=X und product=Y).
KI-Chat für Bestand-Recherche
Welche Produkte sind aktuell „im Minus" verfügbar — also mehr reserviert
als physisch da?
Welche Reservationen werden in den nächsten 14 Tagen fällig (geplante Tour-
Termine), wo der Bestand knapp ist?