refactor: decompose DepartureNotificationHandler into specialized helper methods and update project documentation with process diagrams

03_Realisierung/Taskboard.md

@@ -2,23 +2,23 @@
 
 
 ## 02 HostBooking Analysieren
-### Status: 🟩 Active
+### Status: ⬛ Done
 
 Feststellen wo (welche Bedingungen) im HostBooking Aufträge gestartet werden. V.a. Nachrichten TransportOrderCompleted und DepartureNotification sind relevant. Bitte ggfs. Behälter-Typen beachten.
 INFO: Formlose Notizen mit: Code-Stelle, Bedingungen, Prozess/Szenario genügen
 
 **Nächste Schritte:**
-- [ ] Quellcode des HostBooking-Prozesses lokalisieren
+- [x] Quellcode des HostBooking-Prozesses lokalisieren
-- [ ] Analyse der Verarbeitung von 'TransportOrderCompleted' (Telegramm-Rückmeldung)
+- [x] Analyse der Verarbeitung von 'TransportOrderCompleted' (Telegramm-Rückmeldung)
-- [ ] Analyse der 'DepartureNotification' (Abmeldung von Plätzen)
+- [x] Analyse der 'DepartureNotification' (Abmeldung von Plätzen)
-- [ ] Identifikation von Stellen, an denen Aufträge direkt gestartet werden (Ziel: Zentralisierung)
+- [x] Identifikation von Stellen, an denen Aufträge direkt gestartet werden (Ziel: Zentralisierung)
-- [ ] Prüfung der Abhängigkeiten von Behälter-Typen (Container Types)
+- [x] Prüfung der Abhängigkeiten von Behälter-Typen (Container Types)
 
 ------------------------------------------
 
 
 ## 03 Konzept erstellen
-### Status: ⬜ New
+### Status: 🟩 Active
 
 Idee dokumentieren: Wie können die Code Stellen die einen Auftrag starten aus dem HostBooking so umgebaut werden, dass der ConveyorDispo den Start übernimmt. Am besten ins Ablauf-Diagramm aus (01 ConveyorDispo Analysieren) ergänzen. 
 

04_Dokumentation/DOKUMENTATIONS GERUEST.md

@@ -33,10 +33,32 @@ Das Ziel des Projekts ist die Optimierung und Stabilisierung der Auftragsverarbe
 
 ## 3. Analyse & Konzept (Bewertung: Ausgangssituation)
 ### 3.1 Ist-Analyse
-*Detaillierte technische Beschreibung des aktuellen Problems (Race Condition zwischen OrdersHost und ConveyorDispo).*
+Die technische Ist-Analyse der Quellcode-Basis von GEBHARDT StoreWare identifizierte zwei Haupttypen von Race Conditions, die durch die dezentrale Logik-Hoheit verursacht werden:
+
+#### A. Technische Race Condition (Status-Konflikt bei Neuanlage)
+Trifft eine `DepartureNotification` für eine unbekannte Ladeeinheit (LE) ein, erzeugt der `DepartureNotificationHandler` im Prozess `HostBooking` einen neuen `OrdersHost`-Eintrag im Status `Initial`.
+* **Fehlerablauf:** Noch während der Handler-Durchlauf aktiv ist, sendet er ein Start-Telegramm an die SPS. Parallel dazu identifiziert der zyklische Worker `StartInitialOrdersHost` (Teil des Prozesses `ConveyorDispo`) den neuen `Initial`-Eintrag und initiiert seinerseits einen Startvorgang.
+* **Folge:** 
+  - **Telegramm-Kollision:** Die SPS erhält zeitnah zwei Start-Befehle für dieselbe LE, was zu Fehlsteuerungen führt.
+  - **Datenbank-Inkonsistenz:** Beide Prozesse versuchen simultan den Datensatz zu aktualisieren, was zu `DbUpdateConcurrencyExceptions` führt. Der Auftrag verbleibt oft in einem inkonsistenten Status ("Auftragsleiche").
+
+#### B. Architektonische Race Condition (Umgehung der Ressourcenprüfung)
+Befindet sich ein Behälter im Status `InDestinationZone` (kurz vor dem Ziel), greift eine Sonderlogik für Sequencer-Anbindungen.
+* **Fehlerablauf:** Der Handler im `HostBooking` ändert eigenmächtig das Ziel auf den `ConnectedSequencer` und erzwingt mittels `ForceSetStatusInProgress` den physischen Start.
+* **Folge:** 
+  - **Kapazitäts-Blindheit:** Da dieser Start am zentralen `ConveyorDispo` vorbeigeschleust wird, findet keine Prüfung der Sequencer-Auslastung (Throttling) statt. Die physische Kapazität des Sequencers wird überschritten, was zu Anlagenstaus und Deadlocks im Materialfluss führt.
 
 ### 3.2 Soll-Konzept
-*Definition der funktionalen und nicht-funktionalen Anforderungen.*
+Das Ziel des Soll-Konzepts ist die Überführung der dezentrale Start-Logik in eine monolithische Architektur innerhalb des `ConveyorDispo`.
+
+**Funktionale Anforderungen:**
+- **Exklusivität:** Nur der Prozess `ConveyorDispo` darf den Status eines `OrdersHost`-Auftrags von `Initial` (oder einem neuen Zwischenstatus wie `ReadyToStart`) auf `InProgress` ändern und das entsprechende Start-Telegramm senden.
+- **Entkopplung:** Der `DepartureNotificationHandler` wird zum reinen "Event-Melder" refactored. Er aktualisiert den physischen Ort der LE und setzt den Auftragsstatus lediglich auf `Initial`, um den Startwunsch für den `ConveyorDispo` zu signalisieren.
+- **Zentralisierung:** Alle Start-Entscheidungen (inkl. Sequencer-Anbindung und Ressourcenprüfung) werden im `OrderManager` des `ConveyorDispo` konsolidiert.
+
+**Nicht-funktionale Anforderungen:**
+- **Datenintegrität:** Eliminierung von `ConcurrencyExceptions` durch klare Zuständigkeitstrennung.
+- **Wartbarkeit:** Reduzierung von redundantem Code (DRY) und Beseitigung von "Sonderlocken" in den Handlern.
 
 ### 3.3 Wirtschaftlichkeitsbetrachtung
 *ROI-Analyse: Wie viel kostet der Fehler aktuell? Wie schnell amortisiert sich die Entwicklung?*