Refresh stock forecast after each sale

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

@@ -8,27 +8,28 @@ Tägliche Berechnung und Speicherung des voraussichtlichen Leer-Datums jeder akt
 
 ## 2. Prozess-Einbettung
 
-Direkt ausgeführter, täglich um 06:00 Uhr gestarteter Lager-Prozess über den zentralen ERP-Cron-Einstieg.
+Direkt ausgeführter Lager-Prozess mit zwei Triggern: synchron nach jeder erfolgreichen Verkaufsallokation in der Lagerschnittstelle sowie täglich um 06:00 Uhr über den zentralen ERP-Cron-Einstieg.
 
 ## 3. Input
 
-- keine externen Prozessparameter
+- optional eine einzelne `product_id` bei synchronem Verkaufstrigger
 - 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.
+1. Bei einem Verkaufstrigger die betroffenen Produkt-IDs aus der erfolgreichen Allokation übernehmen; beim Cron-Trigger alle aktiven Produkte bestimmen.
+2. Aktive Produkte und ihre aktuelle Charge aus `product`, `stock_lot` und `v_stock_lot_balance` laden.
+3. Verkaufsallokationen der letzten 365 Tage aus `sales_order_line_lot_allocation`, `sales_order_line` und `sales_order` laden.
+4. `allocated`- und `reserved`-Mengen nach Bestell- beziehungsweise OTC-Verkaufsdatum je Produkt und Kalendertag aggregieren.
+5. Stornierte Auftrags- und Positionsmengen aus der Nachfrage herausrechnen.
+6. Den gewichteten Tagesabsatz mit einer Halbwertszeit von 60 Tagen berechnen.
+7. Für jede aktuelle Charge das Leer-Datum aus physischem Bestand und gewichteter Nachfrage berechnen.
+8. Jede erfolgreiche Berechnung in `stock_lot_forecast_history` speichern und den aktuellen Snapshot in `stock_lot` aktualisieren.
+9. Im Cron 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.
+Der Cron läuft täglich um 06:00 Uhr Europe/Zurich und verarbeitet alle aktiven Produkte deterministisch nach `product.id`. Verkaufstrigger aktualisieren die betroffenen Produkte synchron innerhalb der laufenden Verkaufs-Transaktion. Produktfehler im Cron sind batch-tolerant; technische Gesamtfehler schlagen den jeweiligen Lauf hart fehl.
 
 ## 6. Output