Add daily stock lot sellout forecast

docs/modules/erp/lager/processes/main/erp.lager.stock_lot_forecast_refresh.md

@@ -0,0 +1,94 @@
+# erp.lager.stock_lot_forecast_refresh
+Stand: 2026-09-06
+Status: Verbindliche Prozess-Spezifikation
+
+## 1. Zweck
+
+Tägliche Berechnung und Speicherung des voraussichtlichen Leer-Datums jeder aktuellen Charge aktiver Produkte.
+
+## 2. Prozess-Einbettung
+
+Direkt ausgeführter, täglich um 06:00 Uhr gestarteter Lager-Prozess über den zentralen ERP-Cron-Einstieg.
+
+## 3. Input
+
+- keine externen Prozessparameter
+- aktive Produkte, aktuelle Chargen, physischer Chargenbestand und gültige Verkaufsallokationen aus dem eigenen Datenbestand
+
+## 4. Exakter Prozessablauf
+
+1. Aktive Produkte und ihre aktuelle Charge aus `product`, `stock_lot` und `v_stock_lot_balance` laden.
+2. Verkaufsallokationen der letzten 365 Tage aus `sales_order_line_lot_allocation`, `sales_order_line` und `sales_order` laden.
+3. `allocated`- und `reserved`-Mengen nach Bestell- beziehungsweise OTC-Verkaufsdatum je Produkt und Kalendertag aggregieren.
+4. Stornierte Auftrags- und Positionsmengen aus der Nachfrage herausrechnen.
+5. Den gewichteten Tagesabsatz mit einer Halbwertszeit von 60 Tagen berechnen.
+6. Für jede aktuelle Charge das Leer-Datum aus physischem Bestand und gewichteter Nachfrage berechnen.
+7. Jede erfolgreiche Berechnung in `stock_lot_forecast_history` speichern und den aktuellen Snapshot in `stock_lot` aktualisieren.
+8. Fehler einzelner Produkte sammeln und mit den übrigen Produkten fortfahren.
+
+## 5. Batch, Betriebsmodell und Einbettung
+
+Ein täglicher Lauf um 06:00 Uhr Europe/Zurich verarbeitet alle aktiven Produkte deterministisch nach `product.id`. Produktfehler sind batch-tolerant; technische Gesamtfehler schlagen den Lauf hart fehl.
+
+## 6. Output
+
+Ein normalisiertes JSON-Ergebnis mit Gesamtzahl, erfolgreich verarbeiteten Produkten, Fehleranzahl und fehlerhaften Produkt-IDs.
+
+## 7. Erfolgskriterien
+
+- Jede aktuelle Charge erhält täglich einen aktuellen Prognosesnapshot.
+- Verkäufe ohne Bestand über virtuelle `reserved`-Allokationen beeinflussen die Nachfrage.
+- Die vollständige Berechnungshistorie bleibt erhalten.
+- Ein einzelner Produktfehler verhindert keine weiteren Berechnungen.
+- Eine leere Charge erhält das aktuelle Datum als Leer-Datum.
+
+## 8. Fehlerschranke
+
+Einzelne fachliche oder technische Fehler je Produkt führen zu `partial_success` und werden mit Produkt-ID erfasst. Nicht verfügbare Kernquellen, Datenbankfehler oder fehlende Prozessinfrastruktur führen zu `failed`.
+
+## 9. Fachliche Betriebsregel
+
+Die GUI zeigt das aktuelle Leer-Datum in der Produkttabelle. Die Darstellung wird rot und fett, wenn die Charge leer ist oder das Leer-Datum innerhalb von drei Kalendermonaten vor dem MHD liegt.
+
+## 10. Sub-Prozess-Referenzen
+
+Keine.
+
+## 11. End-to-End Sub-Prozess-Kette
+
+ERP-Cron um 06:00 Uhr → Forecast-Prozess → Nachfrageaggregation → Chargenprognose → Historie und aktueller Snapshot → Lager/Produkte-Tabelle.
+
+## 12. Sub-Prozess-Wiederverwendung
+
+Die bestehende Lagerbestands-View `v_stock_lot_balance` und die bestehende Prozesslauf-Tabelle `process_runs` werden wiederverwendet. Ein zusätzlicher Sub-Prozess ist für den kleinen, deterministischen Batch nicht erforderlich.
+
+## 13. Step-Liste
+
+1. `load_current_lots`
+2. `load_daily_sales`
+3. `calculate_weighted_demand`
+4. `persist_forecast`
+5. `aggregate_result`
+
+## 14. Parallelisierung
+
+Nicht erforderlich. Die Produktmenge ist klein; die Verarbeitung erfolgt deterministisch und seriell mit toleranter Einzelfehlerbehandlung.
+
+## 15. Output-Payload
+
+```json
+{
+  "status": "done|partial_success|failed",
+  "total_products": 0,
+  "processed_products": 0,
+  "failed_products": 0,
+  "failed_product_ids": []
+}
+```
+
+## 16. Done-Kriterien
+
+- Prozesslauf in `process_runs` abgeschlossen.
+- Erfolgreiche Prognosen in `stock_lot_forecast_history` gespeichert.
+- Aktuelle Chargen-Snapshots aktualisiert.
+- Produktfehler vollständig und kompakt im Prozessresultat erfasst.

docs/modules/system/README.md

@@ -15,6 +15,7 @@ Technische Laufzeit-, Start-, Trigger- und Supervisor-Logik.
 ## Technisch umgesetzt
 
 - `modules/system/deploy.php`
+- `modules/system/naurua-erp-cron.php`
 
 ## Wrapper