Warenwirtschaft: Doku — Nachprüfung N-01…N-06 mit Nacharbeitsstand, README/V7/Erstbericht aktualisiert

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md

@@ -5,7 +5,7 @@
 > **Vorgänger:** V6.0 ([entwicklungsplan-aktualisiert-2026-07-06.md](entwicklungsplan-aktualisiert-2026-07-06.md))
 > **Verifikation:** Jeder Befund wurde am Code **und** an der eingespielten Live-DB geprüft (Dev-Container). Die Datei-/Zeilenangaben sind der aktuelle Stand.
 > **Status (historisch, 26.08.2026):** Planungsdokument — zu diesem Zeitpunkt noch nichts umgesetzt.
-> **Status (aktuell, 08.09.2026):** AP-34…AP-51 umgesetzt (Tabelle unten). Die anschließende [Umsetzungsprüfung vom 08.09.2026](../02-audit/umsetzungspruefung-2026-09-08.md) fand 18 Restfehler, die ebenfalls alle behoben sind (Abschnitt 9 dort). Suite: 362 grün.
+> **Status (aktuell, 08.09.2026):** AP-34…AP-51 umgesetzt (Tabelle unten). Die anschließende [Umsetzungsprüfung vom 08.09.2026](../02-audit/umsetzungspruefung-2026-09-08.md) fand 18 Restfehler, die ebenfalls alle behoben sind (Abschnitt 9 dort); die [Nachprüfung](../02-audit/nachpruefung-befundbehebung-2026-09-08.md) ergab 6 weitere Restpunkte, ebenfalls behoben (Abschnitt 6 dort). Suite: 368 grün.
 
 Die mit **`#`** markierten Punkte hat der Kunde als **buggy/dringend** priorisiert. Aufwände in Personentagen (PT), inkl. Test.
 
@@ -33,7 +33,7 @@ Die mit **`#`** markierten Punkte hat der Kunde als **buggy/dringend** priorisie
 | **AP-38** WooCommerce-Ampel (Cron/Auth) | ✅ erledigt (0c8d321 ERP+Connector, b6ca332 Cron-Selbstheilung) — Live-Ursache behoben |
 | übrige APs | — |
 
-Suite (26.08.2026): **338 grün**; nach der Nacharbeit vom 08.09.2026: **362 grün**. Erledigt: **AP-34…AP-51 vollständig** (AP-34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51). **Keine offenen APs mehr.** Verbleibend nur der **Connector-Rollout v1.6.0** in den Shop (AP-34 + AP-38).
+Suite (26.08.2026): **338 grün**; nach der Nacharbeit und Nachprüfung vom 08.09.2026: **368 grün**. Erledigt: **AP-34…AP-51 vollständig** (AP-34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51). **Keine offenen APs mehr.** Verbleibend nur der **Connector-Rollout v1.6.0** in den Shop (AP-34 + AP-38).
 
 > **AP-43-Hinweis:** „Zwischenspeichern" legt die Produktion als **Entwurf** ab (kein Bestand gebucht); erst **„Produktion abschließen"** bucht Roh-/Produkt-/Verpackungsbestand. Entwürfe zählen nirgends in den Bestand — auch nicht in die Chargenverfügbarkeit (F-01). Pflicht bleiben im Entwurf nur Produkt, Standort, Datum und Planmenge; Chargen- und Ergebniszeilen dürfen unvollständig sein und werden verlustfrei gesichert (F-03). Eine bereits abgeschlossene Produktion kann nicht zurück in den Entwurf.
 

dev/product management /02-audit/nachpruefung-befundbehebung-2026-09-08.md

@@ -0,0 +1,193 @@
+# Warenwirtschaft: Nachprüfung der Befundbehebung vom 08.09.2026
+
+**Ergebnis: Die Nacharbeit ist überwiegend wirksam, aber noch nicht vollständig abgeschlossen.** Von den 18 ursprünglichen Befunden sind zehn im geprüften Umfang behoben. Bei sechs Befunden bestehen reproduzierbare Restfehler oder eine weiterhin wirksame Altlast. Zwei weitere Korrekturen sind im Code nachvollziehbar, benötigen aber noch die bereits vorgesehene MySQL- bzw. Geräteabnahme. Eine uneingeschränkte Bestätigung „alles ordnungsgemäß behoben“ ist deshalb derzeit nicht gerechtfertigt.
+
+Die reguläre Testsuite besteht mit **362 Tests und 1.432 Assertions**. Zusätzliche Prüfungen der zusammenhängenden Abläufe zeigen jedoch weiterhin Datenverlust in Entwürfen, verlorene Phasenzuordnungen, veränderten historischen Verpackungsverbrauch sowie eine erneute Einheitenverwechslung beim Bearbeiten kopierter ml-Einkäufe.
+
+## 1. Prüfgrundlage und Umfang
+
+- Ausgangspunkt: [Umsetzungsprüfung vom 08.09.2026](umsetzungspruefung-2026-09-08.md), insbesondere F-01 bis F-18 und der nachträglich ergänzte Abschnitt 9 zur Behebung.
+- Ursprünglicher Code-Prüfstand: `912dce65d4608739db34e5f794b65220f083375c`.
+- Nachgeprüfter Stand: `dd93a992654dc836b2fed8f5cb26e49272d67261` einschließlich des vorhandenen Arbeitsverzeichnisses. Verglichen wurden die Änderungen seit dem ursprünglichen Prüfstand und die angrenzenden, für die Korrekturen relevanten Codepfade.
+- Methoden: Codeprüfung, gesamte vorhandene Testsuite, sieben zusätzliche PHP-Diagnosen mit synthetischen Daten und JavaScript-Ausführung der tatsächlich von Blade gerenderten Formularskripte in einer lokalen DOM-Umgebung.
+- **Keine Änderung an Anwendungscode, vorhandenen Tests, Migrationen oder Konfiguration.** Im Projekt wurde ausschließlich diese Nachprüfungsdokumentation ergänzt. Keine Migration gegen eine bestehende Entwicklungs- oder Produktivdatenbank ausgeführt.
+
+Bereits vorhandene lokale Änderungen an `app/Repositories/InvoiceRepository.php`, `app/Services/Invoice.php`, `resources/lang/de/email.php` sowie die unversionierten `.claude/`, `AGENTS.md` und `app/Mail/MailCancellation.php` wurden beibehalten. Das Suite-Ergebnis bezieht sich auf diesen Arbeitsstand.
+
+Die nachfolgenden IDs **N-01 bis N-06** bezeichnen die Restbefunde dieser Nachprüfung; die ursprünglichen F-IDs bleiben zur Zuordnung erhalten. „Behoben“ bedeutet jeweils: Der beschriebene ursprüngliche Fehler ist im lokal geprüften Umfang korrigiert. Es ist keine Aussage über einen bereits erfolgten Live-Rollout.
+
+## 2. Status aller ursprünglichen Befunde
+
+| Befund | Ergebnis der Nachprüfung | Begründung / Nachweis |
+|---|---|---|
+| F-01 – Entwurf als Chargenverbrauch | **Behoben** | `consumedByStockEntry()` schließt `draft` aus. Die ergänzten Entwurfstests prüfen auch Chargen- und Standortverfügbarkeit sowie die weitere Verwendung des Bestands. |
+| F-02 – Ergebnisprodukte ausgefiltert | **Behoben** | Planung und Ergebnisse verwenden getrennte Produktkataloge. Aktive Einzelprodukte sind unabhängig von `production_relevant` als Ergebnis verfügbar; vorhandene Ergebnisprodukte werden beim Bearbeiten ergänzt. Regressionen in `ProductionScalingTest`. |
+| F-03 – Verlust unvollständiger Entwürfe | **Teilweise behoben** | Gültige und nicht verfügbare Chargen bleiben gemeinsam gespeichert; Ergebnisprodukt mit Stückzahl 0 wird akzeptiert. Eine Ist-Menge ohne gewählte Charge wird weiterhin verworfen. **N-01.** |
+| F-04 – Mehrfachrohstoff / Phasenzuordnung | **Teilweise behoben** | 6 g in Phase A und 4 g in Phase B werden zunächst korrekt wieder geöffnet. Erneutes Speichern des Artikels löscht aber die Produktions-Phasenbezüge. Zusätzlich reicht der neue Schlüssel für wiederholte Zeilen innerhalb derselben Phase nicht aus. **N-02.** |
+| F-05 – Historischer Verpackungs-Snapshot | **Teilweise behoben** | Die ursprüngliche reine Notizkorrektur erhält den Snapshot. Ein Chargensplit bei gleicher Gesamtstückzahl baut ihn trotzdem aus der aktuellen Stückliste neu auf. **N-03.** |
+| F-06 – Alte Eingaben nach Validierungsfehler | **Behoben** | Der Controller priorisiert `old('ingredient_lines')`; die reguläre Regression bestätigt die wiederhergestellten Chargen und Mengen. Die gemeinsame Identitätsproblematik wiederholter Rezepturzeilen bleibt F-04 zugeordnet. |
+| F-07 – Verpackungsvorschau | **Teilweise behoben** | Ergebnisstückzahlen, Hinzufügen und Entfernen von Ergebniszeilen aktualisieren die Vorschau. Bei unverändert bearbeiteten historischen Produktionen zeigt sie jedoch die heutige Stückliste, obwohl der alte Snapshot erhalten bleibt. **N-04.** |
+| F-08 – Dezimales Füllgewicht | **Behoben** | Migration auf `decimal(10,3)`, Float-Cast, normalisierte positive Eingabe und passende Formularausgabe. Tests bestätigen unter anderem 39,5 g und Rezepturskala 0,395. Live-Migrationsstand separat prüfen. |
+| F-09 – Ausschuss ohne Charge | **Teilweise behoben** | Neue ungebundene Erfassungen prüfen den Lagerort und werden FEFO auf Eingänge verteilt. Bestehender Ausschuss ohne Chargenbezug bleibt in der Chargenverfügbarkeit unberücksichtigt. Diese Einschränkung ist bereits als Implementierungsentscheidung dokumentiert. **N-05.** |
+| F-10 – Versand trotz fehlender Freigabe | **Behoben** | Die Board-Schreibroute prüft vor `shipped=2` die Versandbereitschaft innerhalb der Bestellsperre. Konfektionieren vor Zahlung bleibt ausdrücklich möglich. Regressionen in `OrderFulfillmentTest`. |
+| F-11 – Einkaufspreise für Copyreader | **Behoben** | Preisdaten werden nur für Admins abgefragt; die Rohstoff-Detailansicht rendert Preisüberschrift und Preiszellen ebenfalls nur für Admins. Rollenregression besteht. |
+| F-12 – Verbrauch ohne Gegenbuchungen | **Behoben** | Verkaufs-Gegenbuchungen werden im Auswertungszeitraum netto verrechnet. Manuelle Zugänge und Produktionskorrekturen werden passend zur dokumentierten Regel behandelt. Regression in `ProductStockTest`. |
+| F-13 – Stille Kappung der Historie | **Behoben** | Gesamtzahl und Begrenzung werden angezeigt; `all=1` macht die vollständige Liste zugänglich. Echte Pagination bleibt eine gesonderte Optimierung. |
+| F-14 – Prozentwerte als g/Stück | **Behoben** | Herstellerzeilen werden pro Produkt summiert; Prozentanteil, Verbrauch einschließlich Faktoren und Nettogramm werden getrennt dargestellt. Ohne Massebasis werden keine vermeintlich exakten Grammwerte ausgegeben. Regression in `RawMaterialStockTest`. |
+| F-15 – ml-Einkauf kopieren | **Teilweise behoben** | Direkte Kopie und unmittelbarer Wareneingang funktionieren. Der neue Dichte-Fallback überlebt bei entfernter Stammdatendichte die anschließende Bearbeitungsmaske nicht. **N-06.** |
+| F-16 – Prüfungen außerhalb der Sperren | **Codekorrektur nachvollziehbar; Integrationsnachweis offen** | Bestellvorbedingung läuft nach `lockForUpdate`; Wareneingang lädt und prüft den gesperrten Datensatz neu; Rohstoffausschuss prüft den Restbestand nach Sperren der Eingänge erneut. SQLite-Tests bestätigen Ablehnung veralteter/unerlaubter Abläufe, aber keine echte MySQL-Parallelität. |
+| F-17 – Köln-Default | **Behoben** | `Location::defaultId()` wird für Einkauf, Produktion und Ausschuss verwendet und berücksichtigt nur aktive Standorte. Regression bestätigt Köln und den Rückfall auf einen anderen aktiven Standort. |
+| F-18 – Zwischenspeichern / iPad-Notizen | **Codekorrektur nachvollziehbar; Geräteabnahme offen** | Zusätzliche Entwurfsbuttons, größere Touch-Eingabe und automatisches Wachstum des Notizfelds sind vorhanden. HTML-Regressionsprüfung besteht; tatsächliche iPad-Tastatur, Darstellung und Bedienung sind noch nicht abgenommen. |
+
+**Zählung:** 10 behoben, 6 teilweise behoben, 2 mit offenem Integrations-/Gerätenachweis. Die grüne Behebungstabelle in Abschnitt 9 des Erstberichts sollte unter Berücksichtigung dieser Nachprüfung gelesen werden.
+
+## 3. Verbleibende Befunde
+
+### N-01 / F-03 – Eingetragene Menge ohne ausgewählte Charge geht beim Zwischenspeichern verloren
+
+**Priorität: P1 – Verlust von Arbeitsdaten. Nachweis: HTTP-/Datenbankdiagnose.**
+
+**Fundstellen:** `app/Http/Requests/Inventory/StoreProductionRequest.php:101`; `app/Services/ProductionService.php:787`.
+
+Beide Filter behalten eine Entwurfszeile nur, wenn neben dem Rohstoff bereits `batch_key` oder `stock_entry_id` gesetzt ist. Eine vorhandene Ist-Menge allein reicht weiterhin nicht. Damit ist die Aussage „verlustfrei“ nur für einen Teil unvollständiger Zeilen erfüllt.
+
+**Reproduktion:** Gültige Kopfdaten, ein Rohstoff, `quantity_used = '9,8'`, `batch_key = ''`, `save_mode = draft` an die Produktionsroute senden. Die Speicherung endet ohne Validierungsfehler und legt einen Entwurf an. Dieser enthält jedoch **null Verbrauchszeilen**. Die eingegebenen 9,8 g sind nicht gespeichert.
+
+**Empfohlene Korrektur:** Auch mengenhaltige Zeilen ohne Chargenauswahl speichern und beim Öffnen mit leerer Charge wiederherstellen. Erst beim Abschluss den vollständigen Chargenbezug verlangen. Beide Filter und die Wiederherstellung müssen dieselbe Regel verwenden.
+
+**Abnahmekriterium:** Menge eintragen → ohne Charge zwischenspeichern → wieder öffnen → Menge unverändert vorhanden → Charge ergänzen → abschließen. Zusätzlich Entwurf mit gewählter Charge und leerer Menge sowie mit nicht mehr verfügbarer Charge prüfen.
+
+### N-02 / F-04 – Normales Artikelspeichern zerstört die neuen Phasenzuordnungen
+
+**Priorität: P1 – Verlust gespeicherter Zuordnung; Bearbeitung wird fehlerhaft. Nachweis: HTTP-/Datenbank- und DOM-Diagnose.**
+
+**Fundstellen:** `app/Repositories/ProductRepository.php:268`, insbesondere Löschen ab Zeile 280 und Neuanlage in `persistRecipePhases()` ab Zeile 335; `database/migrations/2026_09_08_110000_add_recipe_phase_id_to_production_ingredients_table.php:17`; `resources/views/admin/product/form.blade.php:771`; `resources/views/admin/inventory/productions/_scripts.blade.php:272`.
+
+Der neue Fremdschlüssel der Verbrauchszeile verwendet `nullOnDelete()`. Gleichzeitig löscht `updateManufacturerIngredients()` bei jedem Speichern der Herstellerrezeptur sämtliche Phasen und legt sie neu an. Das normale Artikelformular sendet dafür stets `manufacturer_inci_sync_sent`. Auch inhaltlich unveränderte Phasen erhalten dadurch neue IDs; bestehende Produktionszeilen verlieren ihre Zuordnung automatisch durch den Fremdschlüssel.
+
+**Reproduktion:** Einen Rohstoff mit 6 g in Phase A und 4 g in Phase B verwenden. Einen Entwurf und eine abgeschlossene Produktion anlegen. Vorher zeigt das Produktionsformular korrekt **6 / 4 g**. Den Artikel über `admin_product_store` mit unveränderten Phasennamen, Reihenfolge und Rezepturwerten erneut speichern. Danach sind die Phasenbezüge **aller vier Verbrauchszeilen NULL**. Beim Öffnen des Entwurfs rendert das tatsächliche Formularskript **10 g in Phase A und ein leeres Feld in Phase B**. Die Gesamtmenge bleibt hier 10 g; verloren geht die ursprüngliche Verteilung. Die leere Pflichtzeile muss für einen Abschluss manuell korrigiert werden.
+
+Der neue F-04-Test prüft ausschließlich den Ablauf ohne zwischenzeitliches Artikelspeichern und übermittelt beim Abschluss erneut die ursprünglich vorbereiteten Testzeilen. Er entdeckt diesen Fehler deshalb nicht.
+
+**Zusätzlicher Randfall:** Zwei vom Backend akzeptierte Rezepturzeilen desselben Rohstoffs innerhalb derselben Phase erhalten beide den Schlüssel `ingredient_id|recipe_phase_id`. Bei 6 + 4 g derselben Charge gruppiert das Backend auf 10 g, und das Formular setzt diese Summe in beide Rezepturzeilen ein: **10 + 10 = 20 g**. Dieser Fall wurde ebenfalls im DOM reproduziert. Einordnung: Der aktuelle Rohstoffpicker sperrt bereits verwendete Rohstoffe sogar phasenübergreifend (`resources/views/admin/product/edit.blade.php:463`); die Diagnose verwendet daher gezielt vom Repository unterstützte Bestandsdaten und belegt nicht, dass man diese Doppelzeilen über den normalen Picker neu anlegen kann. Datenmodell, Picker und Produktionsformular sollten dieselbe Regel für Mehrfachverwendung haben.
+
+**Empfohlene Korrektur:** Stabile Phasen-/Rezepturzeilenidentitäten erhalten und bestehende Phasen aktualisieren. Für tatsächlich gelöschte oder veränderte Rezepturen eine historische Zuordnung festlegen, statt Verbrauchsbezüge still zu leeren. Wenn Mehrfachzeilen zulässig sind, reicht „Rohstoff + Phase“ als Zeilenidentität nicht aus; andernfalls unerlaubte Doppelzeilen serverseitig eindeutig validieren.
+
+**Abnahmekriterium:** Produktion mit mehreren Phasen speichern → Artikel unverändert speichern → Produktion öffnen → jede Ist-Menge bleibt in ihrer ursprünglichen Zeile. Für Entwurf und abgeschlossene Produktion prüfen. Anschließend echte Phasenänderung und den gewählten Umgang mit historischen Daten testen.
+
+### N-03 / F-05 – Reiner Ergebnis-Chargensplit ersetzt weiterhin historischen Verpackungsverbrauch
+
+**Priorität: P1 – Unerwartete Änderung historischer Bestände. Nachweis: Servicetest.**
+
+**Fundstellen:** `app/Services/ProductionService.php:164`, `:183`, `:351` (`outputSignature`).
+
+Die neue Signatur vergleicht jede Ergebniszeile als `Produkt-ID:Stückzahl`. Sie summiert die Stückzahlen nicht pro Produkt. Eine andere Verteilung auf Ergebniszeilen gilt deshalb als Mengenänderung, obwohl die insgesamt hergestellten Produkte unverändert bleiben.
+
+**Reproduktion:** Zehn Ergebnisstücke mit je einem Tiegel buchen: Snapshot **10 Tiegel**. Anschließend die Artikelstückliste auf zwei Tiegel ändern. In der Produktion lediglich die Ergebnischarge auf zwei Zeilen mit **6 + 4 Stück desselben Produkts** aufteilen. Die Ergebnisgesamtmenge bleibt zehn. Der gespeicherte Verpackungsverbrauch steigt trotzdem auf **20 Tiegel**.
+
+Die dokumentierte Entscheidung zur Nacharbeit erlaubt eine Neuberechnung bei einer echten Produkt-/Mengenkorrektur. Eine reine Aufteilung derselben Gesamtstückzahl erfüllt dieses Kriterium nicht.
+
+**Empfohlene Korrektur:** Für die Entscheidung über den Snapshot die Gesamtstückzahl je Ergebnisprodukt vergleichen. Falls Chargen eine eigene Verpackungsregel erhalten sollen, diese ausdrücklich modellieren; derzeit berechnet auch die Stückliste den Verbrauch pro Produktstück.
+
+**Abnahmekriterium:** Nach einer Stücklistenänderung verändern Notiz, Datum, Chargennummer, Reihenfolge sowie Split/Zusammenführen gleichbleibender Ergebnisstückzahlen den Snapshot nicht. Tatsächliche Änderung der Produktsummen folgt weiterhin der dokumentierten Korrekturregel.
+
+### N-04 / F-07 – Verpackungsvorschau widerspricht dem nun erhaltenen historischen Snapshot
+
+**Priorität: P2 – Fachlich falsche Vorschau. Nachweis: Servicetest und DOM-Diagnose.**
+
+**Fundstellen:** `app/Http/Controllers/Admin/Inventory/ProductionController.php:295`; `resources/views/admin/inventory/productions/_scripts.blade.php:368`; Gegenregel in `app/Services/ProductionService.php:183`.
+
+Die Vorschau erhält immer die aktuellen Verpackungsstücklisten der Ergebnisprodukte. Bei einer abgeschlossenen Produktion mit unveränderten Ergebnissen behält der Service seit F-05 dagegen ausdrücklich den historischen Snapshot. Beide Seiten verwenden damit unterschiedliche Berechnungsregeln.
+
+**Reproduktion:** Ein Ergebnisstück mit einem Tiegel buchen, Artikelstückliste anschließend auf zwei Tiegel ändern. Alte Produktion öffnen: Vorschau **2 Tiegel**. Nur eine Notiz ändern und speichern: Snapshot bleibt korrekt bei **1 Tiegel**. Die angezeigte Vorschau entspricht also nicht dem tatsächlich gespeicherten Verbrauch.
+
+**Positiv bestätigt:** Änderungen der Ergebnisstückzahl sowie Hinzufügen, Bearbeiten und Entfernen weiterer Ergebniszeilen aktualisieren die aktuelle Stücklistenvorschau korrekt. Der ursprüngliche fehlende Event-Abgleich ist behoben.
+
+**Empfohlene Korrektur:** Die Vorschau muss dieselbe Entscheidung wie die Speicherung treffen: bei unveränderten Produktsummen den historischen Snapshot zeigen, bei echter Änderung die dafür vorgesehene Neuberechnung. Eine zusätzlich angezeigte heutige Stückliste muss klar vom wirksamen Verbrauch unterschieden werden.
+
+### N-05 / F-09 – Bestehender Ausschuss ohne Chargenbezug bleibt inkonsistent
+
+**Priorität: P2 – Falsche verfügbare Chargenmengen im Altbestand. Nachweis: Datenbank-/Servicediagnose.**
+
+**Fundstellen:** `app/Services/ProductionService.php:505`–`:512`, insbesondere `whereNotNull('stock_entry_id')`; neue Verteilung in `app/Http/Controllers/Admin/Inventory/StockDisposalController.php:147`; dokumentierte Altbestandsentscheidung im Erstbericht, Abschnitt 9.
+
+Die neue FEFO-Verteilung greift beim Anlegen über den Controller. Sie ändert bereits bestehende ungebundene Ausschussbuchungen nicht. Deren Mengen reduzieren weiterhin den Gesamt-/Standortbestand, aber keinen angebotenen Chargenrest.
+
+**Reproduktion:** 1.000 g Wareneingang und eine bestehende Ausschussbuchung über 1.000 g ohne `stock_entry_id`. Ergebnis: Gesamtbestand **0 g**, für die Produktion angebotene Chargenmenge weiterhin **1.000 g**. Dies ist derselbe Altbestandsfall wie D-07 des Erstberichts.
+
+**Einordnung:** Kein unerwarteter neuer Fehler der FEFO-Korrektur. Die Entscheidung, Altdaten unverändert zu lassen, ist offen dokumentiert. Sie bedeutet jedoch, dass F-09 nur für neue Erfassungen gelöst ist. Ob und in welchem Umfang solche Datensätze tatsächlich vorhanden sind, wurde nicht in einer bestehenden Datenbank ermittelt.
+
+**Empfohlene Nacharbeit:** Betroffenen Altbestand zunächst lesend erfassen und eine nachvollziehbare Abgleich-/Zuordnungsregel festlegen. Historische Chargen nicht ohne fachliche Grundlage erfinden. Alternativ die verbleibende Einschränkung ausdrücklich akzeptieren und in den betroffenen Bestandsansichten kenntlich machen. Einen grünen Gesamtstatus erst nach Datenabgleich oder ausdrücklich begrenzter Abnahme vergeben.
+
+### N-06 / F-15 – Dichte-Fallback der ml-Kopie geht im anschließenden Bearbeiten verloren
+
+**Priorität: P2 – Falsche Einheit und spätere Bestandsbuchung. Nachweis: HTTP-, Datenbank- und DOM-Diagnose mit Select2.**
+
+**Fundstellen:** `app/Http/Controllers/Admin/Inventory/StockEntryController.php:166`; `app/Repositories/StockEntryRepository.php:29`, `:54`; `resources/views/admin/inventory/stock-entries/_form.blade.php:110`; `resources/views/admin/inventory/stock-entries/_scripts.blade.php:70`–`:98`; `app/Http/Requests/Inventory/UpdateStockEntryRequest.php:73`.
+
+Beim direkten Kopieren wird der Dichte-Snapshot jetzt als Rückfall korrekt verwendet. Die Kopierroute leitet aber anschließend auf das Bearbeitungsformular weiter. Dieses bestimmt die zulässige Einheit ausschließlich aus der aktuellen Rohstoffdichte. Ein vorhandener `density_used`-Snapshot wird dabei nicht berücksichtigt.
+
+**Reproduktion:** Vorlage mit **100 ml**, Dichte-Snapshot **0,79**, kanonischer Bestellmenge **79 g**. Die Stammdatendichte des Rohstoffs ist inzwischen leer. Kopieren legt korrekt eine ml-Bestellung mit 79 g an. Der Server rendert im Bearbeitungsformular 100,00 ml. Nach Initialisierung des tatsächlichen Skripts wird die ausgewählte ml-Option deaktiviert; die Formularserialisierung enthält keine `ordered_unit`, die Zahl bleibt **100,00**. Der Update-Request erlaubt die fehlende Einheit, und das Repository fällt auf `gram` zurück. Nach Speichern und Wareneingang „100“ stehen deshalb **100 g statt 79 g** im Eingang.
+
+Die vorhandene Regression für den fehlenden Dichtewert endet unmittelbar nach dem Kopieren. Die weitere Standardaktion „Menge/Charge prüfen und speichern“, zu der die Kopiermeldung selbst auffordert, ist dort nicht abgedeckt.
+
+**Empfohlene Korrektur:** Bei unverändertem Rohstoff einen vorhandenen Dichte-Snapshot konsistent in Formular, Update-Validierung und Repository verwenden. Einheitenwechsel dürfen keine numerisch unveränderte ml-Menge als Gramm übernehmen. Für einen tatsächlichen Rohstoffwechsel muss die Übernahme einer fremden alten Dichte ausgeschlossen werden.
+
+**Abnahmekriterium:** ml-Einkauf → Stammdatendichte entfernen → kopieren → Bearbeitungsformular initialisieren → unverändert speichern → Wareneingang. Durchgehend 100 ml / 0,79 / 79 g erhalten. Zusätzlich unveränderte und geänderte Stammdatendichte sowie einen Rohstoffwechsel prüfen.
+
+## 4. Testprotokoll und Aussagekraft
+
+| Prüfung | Ausführung / Umgebung | Ergebnis |
+|---|---|---|
+| Gesamte vorhandene Suite | `php artisan test`; PHP 8.4.1, SQLite `:memory:` | **362 bestanden, 1.432 Assertions**, 5,68 s |
+| Zusätzliche PHP-Diagnosen | `vendor/bin/phpunit -c phpunit.xml --do-not-cache-result --display-phpunit-deprecations /tmp/WawiFollowupProbeTest.php` | **7 Tests, 45 Assertions, 5 fachliche Fehlschläge**, 0,546 s |
+| Zusätzliche DOM-Prüfungen | `node /tmp/wawi-followup-dom.cjs`; Node 20.20.2, vorhandenes jsdom 8.5.0, jQuery 3.3.1 und lokales Select2 | **14 Einzelprüfungen: 9 bestanden, 5 fehlgeschlagen** |
+
+Die zusätzlichen PHP-Tests verlangen das gewünschte korrekte Verhalten. Ihre Fehlschläge sind deshalb konkrete Fehlernachweise, keine erwarteten Erfolgsmeldungen für fehlerhaftes Verhalten. Die fünf Fehlschläge betreffen N-01, N-02, N-03, N-05 und N-06. Die beiden erfolgreichen Tests bestätigen den Erhalt des Verpackungs-Snapshots bei einer Notizkorrektur und stellen den akzeptierten Mehrfachzeilen-Datensatz für die DOM-Prüfung bereit.
+
+Für die DOM-Prüfung wurden HTML und Rezeptur-JSON über Laravel-Testrequests aus synthetischen Daten erzeugt. Ausgeführt wurde das tatsächlich gerenderte Produktionsskript; die Rezeptur-AJAX-Antwort wurde durch genau diesen zuvor erzeugten JSON-Payload ersetzt. Beim ml-Einkauf wurde zusätzlich das lokal vorhandene Select2 ausgeführt. Externe Ressourcen wurden nicht geladen. Das ist ein ausführbarer Nachweis der Formularlogik, aber kein vollständiger Browser-, CSS-, Touch- oder iPad-Test.
+
+| Zusätzlicher Ablauf | Beobachtung |
+|---|---|
+| Entwurf mit 9,8 g ohne Charge | Erfolgreiche Speicherung mit 0 Verbrauchszeilen |
+| Phasen 6 / 4 g vor erneutem Artikelspeichern | Formular zeigt korrekt 6 / 4 g; Summe 10 g |
+| Dieselbe Rezeptur über Artikelroute erneut speichern | Vier Produktions-Phasenbezüge werden NULL; Entwurfsformular zeigt 10 g / leer |
+| Zwei Zeilen desselben Rohstoffs in derselben Phase | Formular zeigt 10 / 10 g statt 6 / 4 g |
+| Zehn gleiche Ergebnisstücke auf 6 + 4 aufteilen, Stückliste inzwischen geändert | Verpackungs-Snapshot steigt von 10 auf 20 |
+| Alte Produktion unverändert, heutige Stückliste geändert | Vorschau 2; gespeicherter Verbrauch 1 |
+| Ergebnisstückzahl ändern, Zeile hinzufügen/ändern/entfernen | Vorschau aktualisiert die Summen der aktuellen Stückliste korrekt |
+| Bestehender Ausschuss ohne Charge über gesamten Eingang | Gesamtbestand 0 g, angebotene Charge 1.000 g |
+| ml-Kopie bei fehlender Stammdatendichte öffnen und speichern | Einheit wird nicht übermittelt; anschließender Wareneingang 100 g statt 79 g |
+
+Die temporären Diagnoseprogramme und erzeugten HTML-/JSON-Dateien liegen außerhalb des Repositories in `/tmp`. Sie sind Arbeitsartefakte und kein dauerhaft vorausgesetzter Bestandteil des Projekts. Die Aufbauten, Soll-/Ist-Werte und Fundstellen sind deshalb in dieser Dokumentation festgehalten. Bestehende Projekt-Testdateien wurden nicht ergänzt oder verändert.
+
+PHPUnit meldet weiterhin das veraltete XML-Konfigurationsschema. Dies ist von den fünf fachlichen Fehlschlägen getrennt zu behandeln.
+
+## 5. Noch erforderliche Abnahme und empfohlene Reihenfolge
+
+1. **Entwurfs- und Phasendaten schützen:** N-01 und N-02 korrigieren; zwischenzeitliches Artikelspeichern in die Produktionsregression aufnehmen.
+2. **Verpackungsverbrauch und Vorschau gemeinsam prüfen:** N-03 und N-04 mit derselben fachlichen Änderungsregel beheben; insbesondere gleichbleibende Produktsummen bei wechselnden Ergebniszeilen testen.
+3. **ml-Kopie über den vollständigen Bedienweg absichern:** N-06 einschließlich Initialisierung der Bearbeitungsmaske und anschließendem Speichern/Wareneingang prüfen.
+4. **Altbestandsregel abnehmen:** N-05 anhand tatsächlich vorhandener ungebundener Ausschussbuchungen bewerten und den Umgang damit dokumentieren.
+5. **Betriebsnachweise nachführen:** MySQL-Parallelität für Board-Status, Wareneingang und konkurrierenden Ausschuss sowie reale Browser-/iPad-Bedienung prüfen.
+
+Die drei Migrationen `2026_09_08_100000`, `2026_09_08_110000` und `2026_09_08_120000` wurden durch den Aufbau der SQLite-Testdatenbank ausgeführt. Damit ist **nicht** nachgewiesen, dass sie auf einer bestehenden MySQL-Entwicklungs-/Live-Datenbank bereits angewendet wurden oder dort mit den vorhandenen Daten problemlos laufen. Dieser Rollout-Nachweis bleibt erforderlich; diese Prüfung hat keine bestehende Datenbank verändert.
+
+Die im Erstbericht getrennt aufgeführten nachgelagerten Arbeitspakete, fehlenden Übersichten/Filter, Optimierungen sowie der WooCommerce-Connector-Rollout bleiben gemäß dokumentiertem Umfang weiterhin offen. Die Nacharbeit an F-01 bis F-18 ist keine Umsetzung oder Abnahme dieser zusätzlichen Punkte.
+
+**Abnahmestand:** Die bestätigten Korrekturen können als erledigt geführt werden. Die sechs teilbehobenen Befunde benötigen weitere Nacharbeit bzw. beim Altbestand eine ausdrückliche fachliche Entscheidung. Für F-16 und F-18 fehlt weiterhin der passende Laufzeit-/Gerätenachweis.
+
+## 6. Stand der Nacharbeit zu N-01…N-06 (08.09.2026)
+
+Alle sechs Restbefunde wurden am 08.09.2026 umgesetzt, jeweils mit Regressionstest entlang der oben genannten Abnahmekriterien. Suite danach: **368 Tests grün, 1.482 Assertions**.
+
+| Befund | Status | Umsetzung |
+|---|---|---|
+| N-01 / F-03 | ✅ `313c627` | Ist-Menge ohne Charge wird im Entwurf gesichert (Request- und Service-Filter, `formBatchKey()` liefert `''`), beim Öffnen mit leerer Charge vorbelegt; Abschluss verlangt die Charge. Test: Menge → Entwurf → öffnen → Charge ergänzen → abschließen. |
+| N-02 / F-04 | ✅ `520d4e2` | `persistRecipePhases()` aktualisiert bestehende Phasen (Zuordnung über effektiven Namen, dann Reihenfolge) und löscht nur entfernte; Phasen-IDs und damit `production_ingredients.recipe_phase_id` bleiben beim Artikelspeichern erhalten. Derselbe Rohstoff mehrfach in derselben Phase wird serverseitig abgelehnt (der Picker verhindert es ohnehin). Test: Entwurf mit 6/4 g → Artikel unverändert speichern → Zuordnung bleibt; Umbenennen/Phase ergänzen → keine Zeile verliert ihre Phase. |
+| N-03 / F-05 | ✅ `313c627` | `outputSignature()` summiert Stückzahlen je Produkt; Chargensplit bei gleicher Summe erhält den Snapshot. Test in `ProductionScalingTest` (3 → 2 + 1 bei geänderter Stückliste). |
+| N-04 / F-07 | ✅ `9acb053` | Bearbeitungsformular gebuchter Produktionen erhält Snapshot + Ergebnissummen; die Vorschau zeigt bei unveränderten Produktsummen den gespeicherten Verbrauch (mit Hinweis), sonst die Neuberechnung mit Hinweis „wird neu berechnet“. |
+| N-05 / F-09 | ✅ `313c627` | Fachliche Regel (ohne Datenänderung): Alt-Ausschuss ohne Chargenbezug wird für die **Verfügbarkeit** je Standort FEFO auf die Chargen angerechnet (`ProductionService::applyUnboundDisposals()`, genutzt von Produktion, Chargenübersicht/-zusammenführung, Batch-Check und Chargen-Ausschussprüfung). Damit stimmen Gesamt-, Standort- und Chargenmengen auch für Altdaten überein; D-07 des Erstberichts ist damit für neue **und** alte Buchungen gelöst. Es werden keine historischen Chargenbezüge erfunden oder gespeichert. |
+| N-06 / F-15 | ✅ `5d82875` | Bearbeitungsformular gibt bei fehlender Stammdatendichte den Dichte-Snapshot als `data-density` aus (ml bleibt wählbar); `UpdateStockEntryRequest` und `StockEntryRepository::update()` nutzen den Snapshot als Rückfall — nur bei unverändertem Rohstoff. Test über den vollständigen Bedienweg (kopieren → bearbeiten → speichern → Wareneingang = 79 g) sowie Rohstoffwechsel (abgelehnt). |
+
+**Weiterhin offen (unverändert):** MySQL-Parallelitätsnachweis (F-16), iPad-Geräteabnahme (F-18), Rollout der Migrationen `2026_09_08_*` auf Dev-/Live-DB, Connector v1.6.0 sowie die im Erstbericht nachgelagerten Pakete/Optimierungen.

dev/product management /02-audit/umsetzungspruefung-2026-09-08.md

@@ -456,4 +456,6 @@ Alle 18 Befunde wurden am 08.09.2026 gegen den Code verifiziert (alle bestätigt
 - **F-12:** Netto-Verrechnung nur für `source=sale, direction=in` (technische Gegenbuchungen); manuelle Eingänge zählen weiterhin nicht gegen den Verbrauch.
 - **F-16:** Parallelität bleibt ohne MySQL-Integrationstest; die Vorbedingungen werden jetzt innerhalb der Sperren erneut geprüft (Board-Status, Wareneingang, Ausschuss).
 
+**Nachprüfung:** Die [Nachprüfung der Befundbehebung vom 08.09.2026](nachpruefung-befundbehebung-2026-09-08.md) bestätigte 10 Befunde als behoben und fand bei F-03/F-04/F-05/F-07/F-09/F-15 Restfehler (N-01…N-06). Diese sind ebenfalls umgesetzt (Abschnitt 6 dort; Suite 368 grün). Die Tabelle oben ist zusammen mit dieser Nachprüfung zu lesen.
+
 **Weiterhin offen (nicht Teil der Nacharbeit):** Abschnitt 4.3 (AP-14/15/16/17, AP-32 voll, AP-33c, Deckel-Varianten, LUCID), Abschnitt 4.4 (Verpackungsbestand als Übersicht, Bestandsalarm-E-Mail, zusätzliche Board-Filter), Abschnitt 5 (Optimierungen) sowie der Connector-Rollout v1.6.0 und die Browser-/iPad-Abnahme.

dev/product management /README.md

@@ -2,7 +2,7 @@
 
 > **Stand:** 08.09.2026
 > **Status:** Modul ist **live** und in der **Kundentestphase** (Dev-Container mit eingespielter Live-Datenbank inkl. Testdaten).
-> **Testsuite:** 362 Tests grün (1.432 Assertions, 0 Failures).
+> **Testsuite:** 368 Tests grün (1.482 Assertions, 0 Failures).
 
 Dieses Dokument ist der Einstieg in den Ordner. Es skizziert den Gesamtstand,
 listet die erledigten und die noch offenen Arbeitspakete und verweist auf die
@@ -17,7 +17,7 @@ Detaildokumente. Die maßgebliche, aktuellste Aufwands-/Leistungssicht ist die
 |---|---|
 | [`00-konzept/`](00-konzept/) | Ausgangs-Briefings, Fachkonzept, frühes Feedback (März–April 2026) |
 | [`01-entwicklungsplaene/`](01-entwicklungsplaene/) | Versionierte Entwicklungspläne — maßgeblich ist die neueste Fassung [`entwicklungsplan-V7-2026-08-26.md`](01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md) (V7.0); V6.0 = `entwicklungsplan-aktualisiert-2026-07-06.md` |
-| [`02-audit/`](02-audit/) | Qualitäts- & Sicherheits-Audit vom 15.07.2026; [Umsetzungsprüfung 08.09.2026](02-audit/umsetzungspruefung-2026-09-08.md) (18 Befunde, alle umgesetzt) |
+| [`02-audit/`](02-audit/) | Qualitäts- & Sicherheits-Audit vom 15.07.2026; [Umsetzungsprüfung 08.09.2026](02-audit/umsetzungspruefung-2026-09-08.md) (18 Befunde) und [Nachprüfung der Behebung](02-audit/nachpruefung-befundbehebung-2026-09-08.md) (6 Restbefunde) — alle umgesetzt |
 | [`03-status-und-vorschlaege/`](03-status-und-vorschlaege/) | Aktuelle Leistungsübersicht, AP-32-Brückenlösung, Vorschlag Deckel-Varianten |
 | [`screens/`](screens/) | Screenshots / Mockups zu Beständen, Rezeptur-Phasen, Produktion |
 
@@ -111,7 +111,11 @@ Die unabhängige Prüfung der V7-Umsetzung
 gingen verloren, Rohstoffe in zwei Phasen wurden beim Wiederöffnen vervielfacht,
 historische Verpackungs-Snapshots wurden überschrieben, Versand ohne Zahlungsfreigabe und
 Einkaufspreise für Copyreader. **Alle 18 Befunde sind umgesetzt** (je ein Commit mit
-Regressionstest, Abschnitt 9 des Berichts). Drei neue Migrationen (`2026_09_08_*`) müssen
+Regressionstest, Abschnitt 9 des Berichts). Eine anschließende
+[Nachprüfung](02-audit/nachpruefung-befundbehebung-2026-09-08.md) fand sechs Restfehler
+(N-01…N-06: Entwurfsmenge ohne Charge, Phasenverlust beim Artikelspeichern, Chargensplit vs.
+Snapshot, Vorschau vs. Snapshot, Alt-Ausschuss ohne Charge, ml-Kopie im Bearbeiten), die
+ebenfalls behoben sind (Abschnitt 6 dort). Drei neue Migrationen (`2026_09_08_*`) müssen
 auf Dev-/Live-DB laufen. Weiterhin offen: die im Bericht (Abschnitte 4.3/4.4/5) genannten
 nachgelagerten Pakete, Optimierungen, Connector-Rollout v1.6.0 und die Browser-/iPad-Abnahme.