gruene-seele/dev/product management/entwicklungsplan-aktualisiert-12-06-2026.md

Aktualisierter Entwicklungsplan: Warenwirtschaft, Produktion & Produktbestand

Version: 5.0 - Stand 12.06.2026 Ersetzt: entwicklungsplan-aktualisiert-02-06-2026.md (V4.0) als operative Arbeitsgrundlage Neue Anforderungsquelle: docs/nächsten Anforderungen an die WaWi.md (Kunde, 12.06.2026) + Screens screens/2026-12-06-Rezeptur-phase.jpeg, screens/2026-12-06-neue-produktion.jpeg Referenzen: V4.0 (AP-00 … AP-19), briefing-anpassungen-27-04-2026.md, feedback.md, konzept-final.md, docs/Todos.md Methodik: Backlog aus kleinen, sequenziell abarbeitbaren Arbeitspaketen (AP). Jedes AP hat Ziel, konkrete Schritte mit Dateipfaden, DB-Änderungen, Akzeptanzkriterien und Tests. Reihenfolge so gewählt, dass jedes AP einzeln deploybar ist.

---

0. Was dieses Dokument neu macht

V4.0 hat AP-00 bis AP-19 abgeschlossen (Bugfixes, Einstellungen, Lieferanten/INCI/Einkauf erweitert, Produktion auf Hersteller-Rezeptur, Sets, „Nicht vorrätig", Rohstoffbestand, Produktbestand + Historie, Ausgang/Ausschuss, Hinweise-Doku, UI-Vereinheitlichung). AP-13 (Shop-Bestandsabzug) liegt als Konzept vor, ist aber noch nicht umgesetzt.

V5.0 nimmt die neue Anforderungsrunde vom 12.06.2026 auf. Diese ist überwiegend Feinschliff und Ergänzung an bereits gebauten Bausteinen (Rohstoffbestand, INCI, Produktbestand, Ausschuss, Wareneingang) plus zwei größere fachliche Erweiterungen:

1. Rezeptur-Phasen auf der Hersteller-Rezeptur (Screen 1).
2. Neue Produktions-Maske mit Produktionsergebnis — der Produktbestand wird nicht mehr aus der geplanten Stückzahl gebucht, sondern aus dem real eingetragenen Ergebnis (mehrere Outputs möglich). Der Rohstoffverbrauch bleibt wie gehabt chargenbasiert (Screen 2).

Der reale Code-Stand wurde erneut verifiziert (12.06.2026); die daraus folgenden Abgrenzungen stehen je AP unter „Ist-Stand".

Geprüfte Dateien u. a.: RawMaterialStockController, ProductStockController + ProductStockService, IngredientController + app/Models/Ingredient.php + resources/views/admin/ingredient/*, StockDisposalController, StockEntryController + app/Models/StockEntry.php, ProductionController + app/Services/ProductionService.php + app/Models/Production*.php, app/Models/Product.php, GeneralSettingController, app/Models/Location.php, Migrationen unter database/migrations/.

---

0a. Umsetzungsprotokoll V5.0 (laufend)

Jede abgeschlossene Teil-Lieferung wird hier mit Datum, betroffenen Dateien und Test-Status protokolliert.

Datum	AP	Kurzbeschreibung	Tests
12.06.2026	AP-22 (Produktbestand-Erweiterungen)	Migration 2026_06_12_175615_add_show_in_product_stock_to_products_table (products.show_in_product_stock bool default 1). Product fillable+cast; Checkbox „Im Produktbestand anzeigen" in der Warenwirtschaft-Card (ProductRepository normalisiert; Hinweistext „Abrechnung Druckkosten / Logo-Etiketten"). ProductStockController@index + ProductStockService::criticalProductCount() filtern auf das Flag (ausgeblendete Produkte zählen nicht im Badge). Dringlichkeits-Sortierung: Übersicht serverseitig default nach Status-Rang (kritisch → niedrig → ok), innerhalb nach Bestand aufsteigend, dann Name; Klick auf den „Status"-Spaltenkopf toggelt die Reihenfolge (JS über data-rank). Kacheln: alle vier Kacheln (Produkte/Bestand OK/Niedrig/Kritisch) klickbar — „Produkte" hebt den Filter auf, die anderen filtern exakt ihren Status (Checkbox „nur kritische" bleibt erhalten). Neue Spalte „Verbrauch/Monat": ProductStockService::monthlyConsumptionByProduct() = Ø der out-Bewegungen der letzten 6 Monate (rollierendes Fenster), ohne source=production (Produktions-Gegenbuchungen sind Korrekturen, kein Verbrauch); mit AP-13 fließen Verkäufe (source=sale) automatisch ein. Migration auf DB ausgeführt.	ProductStockTest erweitert (13 grün, 37 Assertions): Flag blendet aus Übersicht + Kritisch-Zähler aus, Verbrauch/Monat-Mittelung (Fenstergrenze, production-Ausschluss, Eingänge zählen nie), Default-Sortierung kritisch vor ok, Render Verbrauch-Spalte + 4 Kachel-Filter. Regression Produkt-Suite (32 grün)
12.06.2026	AP-25 (Lieferbestand: Datum statt Tage)	„Nicht vorrätig" wird jetzt über ein festes Datum („Wieder lieferbar ab", Datepicker datepicker-base, dd.mm.yyyy) statt über eine Tagesangabe gepflegt; Datenmodell unverändert (out_of_stock_until DATE passte bereits). ProductRepository::update() parst out_of_stock_date via Carbon::createFromFormat('d.m.Y') (ungültige Eingabe ⇒ null statt Crash); „unbestimmt" behält Vorrang, Deaktivierung leert beides. Resttage-Helper (outOfStockRemainingDays()/outOfStockNotice()) unverändert — zählen täglich automatisch herunter. Interne Bestellliste wieder kaufbar: User/OrderController::datatable zeigt den roten Hinweis jetzt zusätzlich zu den Mengen-Buttons (vorher ersetzte er sie) — der VP entscheidet selbst, ob er später beliefert wird; Produkt-Detail-Modal zeigte den Hinweis bereits nur zusätzlich. Formular-Card „Verfügbarkeit" + JS-Toggle (js-out-of-stock-date) angepasst.	tests/Feature/ProductOutOfStockTest.php umgebaut (8 grün, 29 Assertions): Datum→out_of_stock_until, Unbestimmt-Vorrang, Deaktivierung leert, ungültiges Datum ⇒ null, Vergangenheit gilt nicht, Resttage zählen mit travel() herunter, HTTP-Store mit Datum, Bestellliste zeigt Hinweis + Mengen-Buttons. Regression ProductSetTest/ProductPhase51Test/ProductStockTest (24 grün)
12.06.2026	AP-26 (Ausschuss-Gründe konfigurierbar)	Neue Stammdaten-Tabelle disposal_reasons (label, active, pos) via Migration 2026_06_12_170531_create_disposal_reasons_table; Model DisposalReason (cast active, scopeActive), DisposalReasonFactory, Seeder-Erweiterung InventoryStammdatenSeeder (bisherige 6 Gründe idempotent per firstOrCreate übernommen). CRUD: DisposalReasonController (create/store/edit/update/destroy → Redirect general), Store/UpdateDisposalReasonRequest (label Pflicht max 100, passend zur stock_disposals.reason-Spalte). Dritte Karte „Ausschuss-Gründe" auf Einstellungen → Allgemein (general/index.blade.php + GeneralSettingController), View disposal-reasons/form.blade.php. Route Resource disposal-reasons (ohne index/show) in der superadmin-Gruppe. StockDisposalController::reasons() liest jetzt aktive disposal_reasons (Reihenfolge pos, dann label) statt der hartkodierten Liste; StoreStockDisposalRequest bleibt bewusst ohne in:-Zwang (bestehende Disposals behalten ihren String-Grund). Migration + Seed auf DB ausgeführt.	tests/Feature/DisposalReasonSettingsTest.php (8 grün, 24 Assertions): Render Allgemein-Karte, CRUD, Pflicht-Label, active-Scope, Ausschuss-Formular zeigt nur aktive Gründe in Sortierung, Zugriffsschutz Nicht-SuperAdmin. Regression StockDisposalTest/TaxRateSettingsTest/DeliveryTimeSettingsTest (24 grün)
offen	AP-20	Rohstoffbestand-Filter „alle / nur aus Herstellerrezepturen" + INCI-Flag „Kein Rohstoffbestand"	–
offen	AP-21	INCI: Lieferant + URL je Zeile (Repeater, „+ weiterer Lieferant"), „nur aktive"-Filter, „Alternativer Name", Lagerort (Raum/Regal/Buchstabe) inkl. zentraler Einstellungen	–
offen	AP-23	Rezeptur-Phasen auf der Hersteller-Rezeptur (Phase A/B …, je Phase Rohstoffe + Notiz, Drag&Drop, Gesamt 100 %)	–
offen	AP-24	Chargen-Nr.-Präfix auf Produktebene + Auto-Generierung (editierbar) in der Produktion	–
offen	AP-27	Wareneingang: gleiche Charge addieren (Bestand zusammenführen), Einkaufsvorgang bleibt separat erfasst	–
offen	AP-28	Neue Produktions-Maske + Produktionsergebnis (mehrere Outputs, entkoppelt von der Planung; Produktbestand aus Ergebnis, Rohstoffbestand aus Chargen, Phasen-Anzeige, Regal-Spalte)	–

Status Roadmap V5.0 (12.06.2026): AP-26, AP-25 und AP-22 sind erledigt (Details siehe Protokoll oben). Offen aus V5.0: AP-21, AP-20, AP-23, AP-24, AP-27, AP-28.

Übernommen aus V4.0 / weiterhin offen: AP-13 (Shop-Bestandsabzug bei Versand inkl. Sets, Konzept liegt vor), AP-14 (Audit-Trail), AP-15 (Blockbasierte Rechte), AP-16 (2FA), AP-17 (WaWi-Einstellungen).

➡️ HIER GEHT ES WEITER: AP-21 (INCI-Erweiterungen). Das ist das nächste Paket in der Reihenfolge und zugleich die Grundlage für AP-20 (liefert scopeUsedInActiveRecipes() + „Kein Rohstoffbestand"-Flag-Formularfeld) und für die neue Produktions-Maske AP-28 (liefert Alternativname + Lagerort/„Regal"-Spalte). Vor dem Start die Lagerort-Modell-Frage final entscheiden (§5 Punkt 1 — Empfehlung: drei getrennte Stammdaten-Tabellen Raum/Regal/Fach). Danach: AP-20 → AP-23 → AP-24 → AP-27+AP-28 gemeinsam.

---

1. Verifizierter Ist-Stand (12.06.2026) — relevant für die neue Runde

Bereich	Ist im Code	Neue Anforderung verlangt
Rohstoffbestand (RawMaterialStockController@index)	Listet alle aktiven Rohstoffe (active=true), unabhängig von Rezeptur-Zugehörigkeit. Filter: Suche, „nur kritische", Status-Kacheln.	Umschalt-Filter „alle" / „nur aus Herstellerrezepturen"; Rohstoffe ohne Bestandsführung (Allergene etc.) per Flag ausblenden.
INCI / ingredients (app/Models/Ingredient.php, IngredientController, ingredient/form.blade.php)	Felder: name, inci, effect, active, pos, default_factor, min_stock_alert, material_quality_id, tax_rate_id, delivery_time(_days). Lieferanten über Pivot ingredient_supplier (Spalten preferred, supplier_sku, url vorhanden), Form macht aber nur Multi-Select der Lieferanten — keine Per-Lieferant-URL-Eingabe. Kein alt_name, kein „Kein Rohstoffbestand"-Flag, kein Lagerort.	alt_name (Alternativer Name), Per-Lieferant-URL-Repeater mit „+", „nur aktive"-Filter, Lagerort (Raum/Regal/Buchstabe), „Kein Rohstoffbestand"-Flag.
Produktbestand (ProductStockController@index, ProductStockService)	Sortiert nach pos,name. Kacheln: nur warning/critical klickbar (all/ok nicht). Filtert active=true, is_set=false, main_product_id IS NULL. Kein Sichtbarkeits-Flag, keine „Verbrauch/Monat"-Spalte.	Default-Sortierung nach Dringlichkeit, alle Kacheln klickbar, Produkt-Flag „im Produktbestand anzeigen", Spalte „Verbrauch/Monat" (Ø 6 Mon.).
Rezeptur / product_ingredients	Spalten: product_id, ingredient_id, pos, gram, factor, recipe_type (product/manufacturer). Kein Phasen-Begriff.	Phasen auf der Hersteller-Rezeptur (Phase A/B …, je Phase Rohstoffe + Notiz, Gesamt 100 %).
Produkt / products	Hat out_of_stock_until, out_of_stock_indefinite, min/critical_product_stock, Set-Felder, no_recipe_required. Kein Chargen-Präfix, kein Produktbestand-Sichtbarkeits-Flag.	batch_prefix, show_in_product_stock, Lieferbestand auf Datum umstellen.
Ausschuss (StockDisposalController::reasons())	Gründe hartkodiert im Controller (6 Werte).	Gründe als konfigurierbare Stammdaten (Einstellungen).
Wareneingang / stock_entries	batch_number (string) vorhanden, keine Erkennung/Zusammenführung gleicher Chargen. Restbestand wird ohnehin chargenweise über production_ingredients gerechnet.	Beim Erfassen prüfen, ob batch_number für denselben Rohstoff schon existiert → Mengen zusammenführen, Einkaufsvorgang trotzdem separat erfassen.
Produktion / productions	Ein quantity (Output), produced_at, location_id, notes. production_ingredients (stock_entry_id, quantity_used). Produktbestand wird heute aus quantity gebucht (ProductStockService::recordProductionStock). Kein Ergebnis-/Mehrfach-Output-Begriff, keine Phasen-Anzeige, keine Regal-Spalte.	Neue Maske: Planung (Produkt/Größe/Datum/geplante Stückzahl) nur informativ; Produktionsergebnis mit mehreren Outputs (Produkt, produzierte Stückzahl, Chargen-Nr.) bucht den Produktbestand; Rohstoffverbrauch chargenbasiert wie bisher; Phasen + Regal-Spalte.
Locations	locations: name, active. Keine Raum/Regal-Struktur.	Lagerort-Bausteine (Raum/Regal/Buchstabe) zentral pflegbar, am INCI referenziert.

---

2. Interpretation der neuen Anforderungen (Mapping auf APs)

#	Anforderung (12.06.)	AP
Rohstoffbestand 1a/1b	Filter „alle Rohstoffe" / „nur aus Herstellerrezepturen"	AP-20
Rohstoffbestand (INCI-Flag)	„Kein Rohstoffbestand"-Kontrollkästchen (Allergene etc. ausblenden)	AP-20
INCI 1	Lieferant + URL je Zeile, URL leer ⇒ Mailbestellung; „+ weiteren Lieferanten"	AP-21
INCI 2	INCI-Liste „nur aktive" (≥ 1 aktives Produkt)	AP-21
INCI 3	Feld „Alternativer Name" (z. B. LECITHIN → Phospholipon 80 H)	AP-21
INCI 4	Lagerort RAUM | REGAL-NR. | BUCHSTABE, zentral unter Einstellungen pflegbar	AP-21
Produktbestand 1	Sortierung nach Dringlichkeit (default), Kacheln „Produkte"/„Bestand ok" klickbar	AP-22
Produktbestand 2	Produkt-Flag „im Produktbestand anzeigen"	AP-22
Produktbestand 3	Spalte „Verbrauch pro Monat" (Ø letzte 6 Monate)	AP-22
Produktebene 1	Rezeptur-Phasen unter der Hersteller-Rezeptur (Screen 1)	AP-23
Produktebene 2	Chargen-Nr.-Präfix (Kategorie-Kürzel + Produkt-Nr. + Produktionsdatum)	AP-24
Lieferbestand	Datum statt Tage, Produkt bleibt kaufbar, Resttage für VP zählen herunter	AP-25
Ausschuss	Gründe unter Einstellungen selbst anlegen	AP-26
Wareneingang	Gleiche Charge addieren, Einkaufsvorgang trotzdem erfassen	AP-27
Produktion	Neue Maske + Produktionsergebnis (mehrere Outputs), Phasen, Regal (Screen 2)	AP-28

---

3. Priorisierte Roadmap V5.0

Leitidee der Reihenfolge: Erst die kleinen, isolierten Ergänzungen an bestehenden Seiten (schnell sichtbarer Nutzen, geringes Risiko), dann die Datenmodell-Grundlagen (Phasen, Chargen-Präfix), zuletzt die große Produktions-Maske, die auf Phasen + Präfix + Lagerort aufsetzt.

Reihenfolge	AP	Titel	Abhängigkeit	Aufwand
1	✅ AP-26	Ausschuss-Gründe konfigurierbar — erledigt 12.06.2026	–	0,5–1 Tag
2	✅ AP-25	Lieferbestand: Datum statt Tage (Revision AP-03) — erledigt 12.06.2026	–	0,5–1 Tag
3	✅ AP-22	Produktbestand-Erweiterungen (Sortierung, Kacheln, Flag, Verbrauch/Monat) — erledigt 12.06.2026	–	1,5–2,5 Tage
4	➡️ AP-21	NÄCHSTER SCHRITT: INCI-Erweiterungen (Lieferant+URL, nur aktive, Alternativname, Lagerort + Einstellungen)	AP-05-Muster (Stammdaten)	2,5–4 Tage
5	AP-20	Rohstoffbestand-Filter + „Kein Rohstoffbestand"-Flag	AP-21 (Flag/Lagerort am INCI)	1–2 Tage
6	AP-23	Rezeptur-Phasen (Hersteller-Rezeptur)	–	3–5 Tage
7	AP-24	Chargen-Nr.-Präfix (Produktebene)	–	1 Tag
8	AP-28	Neue Produktions-Maske + Produktionsergebnis	AP-21 (Lagerort), AP-23 (Phasen), AP-24 (Präfix)	5–8 Tage

Querschnitt: Alle neuen/angepassten Seiten verwenden das Design-System aus AP-19 (resources/views/admin/inventory/partials/wawi-ui.blade.php) und die Datumsfeld-Konvention (datepicker-base, dd.mm.yyyy). Jede DB-Änderung wird per Migration nachgezogen, jedes AP mit vendor/bin/pint --dirty und Pest-Tests abgeschlossen.

---

4. Arbeitspakete im Detail

AP-26 — Ausschuss-Gründe konfigurierbar

Anforderung: „Ich möchte die Gründe für den Ausschluss unter Einstellungen selber anlegen können."

Ist-Stand: Gründe sind in StockDisposalController::reasons() (≈ Z. 114–124) hartkodiert.

DB

• Neue Tabelle disposal_reasons: label VARCHAR, active bool, pos int. Seeder mit den bisherigen 6 Werten (idempotent per firstOrCreate), damit Bestandsdaten unverändert bleiben.

Code

• Model DisposalReason (scopeActive, casts), Factory, InventoryStammdatenSeeder-Erweiterung.
• CRUD DisposalReasonController (create/store/edit/update/destroy → Redirect general) + Store/UpdateDisposalReasonRequest — analog zu TaxRateController/DeliveryTimeController.
• Dritte Karte „Ausschuss-Gründe" auf der Seite Einstellungen → Allgemein (general/index.blade.php) + GeneralSettingController um disposalReasons erweitern.
• StockDisposalController: reasons() liest jetzt aktive disposal_reasons (Reihenfolge pos); create/Formular nutzt sie. StoreStockDisposalRequest validiert weiterhin nur „nicht leer" (kein harter in:-Zwang, da frei pflegbar).
• Routen Resource disposal-reasons (ohne index/show) in der superadmin-Gruppe; Sidenav unverändert (liegt unter „Allgemein").

Akzeptanz: SuperAdmin legt/ändert/deaktiviert Ausschuss-Gründe; das Ausschuss-Formular zeigt nur aktive Gründe in gepflegter Reihenfolge; bestehende Disposals behalten ihren (als String gespeicherten) Grund.

Tests: DisposalReasonSettingsTest (Render, CRUD, Validierung, active-Scope, Zugriffsschutz) + Regression StockDisposalTest.

Status: Erledigt (12.06.2026). Umgesetzt wie geplant — Tabelle disposal_reasons, CRUD analog TaxRate/DeliveryTime, dritte Karte unter Einstellungen → Allgemein, StockDisposalController::reasons() liest aktive DB-Gründe. Details siehe Umsetzungsprotokoll (§0a). Tests: tests/Feature/DisposalReasonSettingsTest.php (8 grün).

---

AP-25 — Lieferbestand: Datum statt Tage (Revision AP-03)

Anforderung: „Bei ‚erst in 12 Tagen wieder lieferbar' machen wir das Produkt doch wieder kaufbar — der VP entscheidet selbst. Ich präferiere, dass ich auf Produktebene ein Datum einstelle und für den VP dann die Anzahl der Tage erscheint, die sich täglich aktualisiert."

Ist-Stand: AP-03 hat out_of_stock_until (DATE) + out_of_stock_indefinite (bool). Eingabe erfolgt heute über ein Tagefeld (now()->addDays($tage)); Kauf bleibt im Shop bereits möglich. Interne Bestellliste (OrderController::datatable + admin/modal/show_product) ersetzt die Mengen-Buttons aktuell durch einen Hinweis → laut neuer Anforderung soll kaufbar bleiben.

Kern der Änderung: Eingabe-Logik von „Tage" auf „Datum" umstellen (Datenmodell out_of_stock_until bleibt — passt bereits), Resttage werden für den VP weiterhin tagesgenau berechnet und gezählt. Kauf überall möglich (auch interne Bestellliste).

Code

• Produktformular (Card „Verfügbarkeit", resources/views/admin/product/… + JS toggleOutOfStock in edit.blade.php): Tagefeld → Datepicker „Wieder lieferbar ab" (datepicker-base, dd.mm.yyyy), vorbefüllt aus out_of_stock_until->format('d.m.Y'). Checkbox „unbestimmt" bleibt.
• ProductRepository::update(): statt addDays($tage) jetzt Carbon::parse($datum) aus dem Datepicker; „unbestimmt" hat weiter Vorrang (Datum=null), Deaktivierung leert beides. Helfer outOfStockRemainingDays()/outOfStockNotice() bleiben unverändert (zählen schon tagesgenau herunter).
• Interne Bestellliste kaufbar machen: in OrderController::datatable (Produkt-Spalte) und admin/modal/show_product die Mengen-Buttons nicht mehr unterdrücken; stattdessen Hinweis „In ca. X Tag(en) wieder da!" zusätzlich anzeigen (Kauf bleibt). Shop zeigt den Hinweis bereits zusätzlich.

Akzeptanz: Auf Produktebene wird ein Datum gesetzt; VP sieht im Shop und in der internen Bestellliste „In ca. X Tagen wieder da!", die Tage zählen täglich herunter, das Produkt bleibt überall kaufbar; nach Ablauf verschwindet der Hinweis automatisch.

Tests: ProductOutOfStockTest anpassen (Datum→Resttage statt Tage→Datum; kaufbar in interner Liste; Vergangenheit gilt nicht; „unbestimmt"-Vorrang). Hinweise-Doku (AP-18) aktualisieren (Kauf-Sperre weiterhin nur optionale Zukunftsoption).

Status: Erledigt (12.06.2026). Datepicker „Wieder lieferbar ab" statt Tagefeld; ProductRepository parst d.m.Y (ungültig ⇒ null); interne Bestellliste zeigt den Hinweis jetzt zusätzlich zu den Mengen-Buttons (Kauf überall möglich). Hinweise-Doku aktualisiert. Details siehe Umsetzungsprotokoll (§0a). Tests: tests/Feature/ProductOutOfStockTest.php (8 grün).

---

AP-22 — Produktbestand-Erweiterungen

Anforderungen:

1. Sortierung nach Dringlichkeit (Klick auf „Status" sortiert dringlichste oben; darf default so sein). Kacheln „Produkte" und „Bestand ok" sollen ebenfalls klickbar sein.
2. Produkt-Flag: „im Produktbestand anzeigen ja/nein" (z. B. Abrechnung Druckkosten / Logo-Etiketten gehören da nicht rein).
3. Spalte „Verbrauch pro Monat" (Ø der letzten 6 Monate).

Ist-Stand: Sortierung pos,name; nur warning/critical-Kacheln klickbar; Filter active, is_set=false, main_product_id IS NULL; keine Verbrauchsspalte; kein Sichtbarkeits-Flag.

DB (products)

• show_in_product_stock bool default 1 (Migration). Bestehende Produkte bleiben sichtbar; gezielt abwählbar.

Code

• Flag: Product fillable + cast; Checkbox „Im Produktbestand anzeigen" in der Warenwirtschaft-Card des Produktformulars; ProductRepository::update() normalisiert (isset ? 1 : 0). ProductStockController@index filtert zusätzlich where('show_in_product_stock', true). Auch criticalProductCount() (ProductStockService) respektiert das Flag.
• Dringlichkeits-Sortierung: ProductStockService::productStatus() liefert bereits critical/warning/ok. Default-Reihenfolge serverseitig nach Status-Rang (critical → warning → ok), innerhalb gleich nach Reichweite/Name; DataTables-order auf die Status-Spalte (mit data-order-Rang) setzen, sodass ein Klick auf „Status" die dringlichsten oben hält.
• Kacheln klickbar: in product-stock/index.blade.php allen vier wawi-stat-Kacheln (all/ok/warning/critical) is-clickable + data-filter geben; JS-Filter (analog Rohstoffbestand) auf alle vier Werte erweitern. „Produkte" (=all) hebt Filter auf, „Bestand ok" filtert auf ok.
• Verbrauch/Monat: neue Methode ProductStockService::monthlyConsumptionByProduct() = Ø der out-Bewegungen mit source IN ('sale','production_out',…) bzw. der relevanten Abgänge der letzten 6 Kalendermonate (Summe der Abgänge / 6). Spalte „Verbrauch/Monat" in der Übersicht (rechtsbündig, Einheit Stück).

  Klärung (vermerkt, nicht blockierend): „Verbrauch" = abgehende Bewegungen. Solange AP-13 (Verkaufsabzug) nicht live ist, basiert der Wert auf manuellen out-Bewegungen; mit AP-13 fließen Verkäufe automatisch ein. Default-Fenster 6 Monate.

Akzeptanz: Übersicht ist standardmäßig nach Dringlichkeit sortiert; alle vier Kacheln filtern; ausgeblendete Produkte (Flag aus) erscheinen nicht und zählen nicht in den Kritisch-Badge; „Verbrauch/Monat" zeigt den 6-Monats-Durchschnitt.

Tests: ProductStockTest erweitern (Flag blendet aus + aus Kritisch-Zähler, Verbrauch/Monat-Mittelung über 6 Monate, Status-Sortierrang, Render der vier Kachel-Filter).

Status: Erledigt (12.06.2026). Abweichung zur Planung: Sortier-Toggle nicht über DataTables-order, sondern leichtgewichtig per eigenem JS (data-rank an der Zeile, Klick auf den „Status"-Kopf sortiert um) — die Seite nutzt kein DataTables. „Verbrauch/Monat" als rollierendes 6-Monats-Fenster umgesetzt (statt Kalendermonate; Klärungspunkt §5.3 bleibt zur Bestätigung offen), Produktions-Gegenbuchungen (source=production) ausgenommen. Details siehe Umsetzungsprotokoll (§0a). Tests: ProductStockTest (13 grün).

---

AP-21 — INCI-Erweiterungen (Lieferant+URL, nur aktive, Alternativname, Lagerort)

Anforderungen (INCI-Ebene 1–4):

1. Pro INCI mehrere Lieferanten mit eigener URL (URL frei ⇒ Bestellung per Mail), „+ weiteren Lieferanten anlegen".
2. INCI-Liste „nur aktive" filtern (aktiv = in mind. einer Hersteller-Rezeptur eines aktiven Produkts).
3. Feld „Alternativer Name" (Handelsname; findbar für Mitarbeiter).
4. Feld Lagerort im Schema RAUM | REGAL-NR. | BUCHSTABE; die einzelnen Bausteine zentral unter Einstellungen pflegbar.

Ist-Stand: ingredient_supplier.url existiert im Schema, wird im Formular aber nicht ausgespielt (nur Multi-Select). Kein alt_name, kein Lagerort, keine „nur aktive"-Liste.

DB

• ingredients.alt_name VARCHAR nullable (Migration).
• Lagerort am INCI: ingredients.location_room_id, location_shelf_id, location_slot_id (nullable FKs) oder kompakt drei Strings — Entscheidung: drei FK auf neue Stammdaten (Punkt 4 verlangt zentrale Pflege).
• Zentrale Stammdaten unter Einstellungen — drei kleine Tabellen storage_rooms (Raum), storage_shelves (Regal-Nr.), storage_slots (Buchstabe), je label, active, pos. (Alternativ generische storage_segments mit type-Enum room|shelf|slot; bei der Umsetzung die einfachere von beiden wählen — Default: drei Tabellen für klare Dropdowns.)
• Lieferanten-URL: Pivot ingredient_supplier.url ist vorhanden → keine Migration nötig; nur das Formular muss die Spalte bespielen.

Code

• Ingredient: fillable alt_name + Lagerort-FKs; Relationen room()/shelf()/slot(); Helper storageLabel() = "Raum 1 | Regal 3 | O" (für die Anzeige in Rohstoffbestand-Detail und in der Produktions-Maske, Spalte „Regal").
• Lieferanten-Repeater in ingredient/form.blade.php: pro Zeile Lieferant-Select + URL-Textfeld (type="text", max 2048) + Entfernen; „+ weiterer Lieferant"-Button (JS klont eine Zeile). Speichern via suppliers()->sync([$id => ['url' => …, 'preferred' => …]]) (Pivot-Daten). StoreIngredientRequest validiert paarweise (suppliers.*.id exists, suppliers.*.url nullable string max 2048). Ableitung Bestellweg: je INCI-Lieferant gilt url leer ⇒ Mailbestellung, sonst Shop-Link — diese Ableitung ersetzt im Rohstoffbestand-Detail (AP-10) den bisherigen supplier.order_method-Fallback (INCI-spezifisch sticht).
• „Alternativer Name": Eingabefeld neben „Name"/„INCI"; Anzeige als eigene Spalte in der INCI-Verwaltungsliste und in der Produktions-INCI-Liste (Screen 2 zeigt Spalte „Alternativer Name").
• Lagerort: drei abhängige Dropdowns (Raum/Regal/Buchstabe) aus den Stammdaten; Anzeige als „Regal"-Spalte (Screen 2) und im Rohstoffbestand-Detail.
• Einstellungen → Allgemein: je eine Karte „Räume", „Regale", „Fächer/Buchstaben" mit CRUD (Muster AP-05); GeneralSettingController um die drei Listen erweitern; Routen-Resources (superadmin).
• „nur aktive"-Filter der INCI-Liste: Scope Ingredient::scopeUsedInActiveRecipes() = whereHas('products', fn($q) => $q->where('recipe_type','manufacturer')->whereHas('product', active)) (Pivot-Pfad über product_ingredients mit recipe_type='manufacturer' zu aktiven Produkten). In der INCI-Übersicht (IngredientController@index bzw. die Verwaltungsliste) eine Checkbox „nur aktive" (server- oder DataTables-clientseitig). Achtung: „aktiv" hier ≙ in Herstellerrezeptur eines aktiven Produkts — nicht das Feld ingredients.active. Begriffe in der UI sauber trennen („nur aktive (in Rezeptur)").

Akzeptanz: Pro INCI können mehrere Lieferanten mit je eigener URL gepflegt werden (leer = Mail); INCI hat einen Alternativnamen und einen zentral gepflegten Lagerort; die INCI-Liste lässt sich auf „nur in aktiven Herstellerrezepturen verwendete" filtern; Lagerort und Alternativname erscinen in Rohstoffbestand-Detail und Produktions-Maske.

Tests: IngredientOrderFieldsTest erweitern (Per-Lieferant-URL speichern/sync, alt_name, Lagerort-FKs); neuer IngredientActiveRecipeFilterTest (Scope liefert nur INCI aus aktiven Herstellerrezepturen); StorageSettingsTest (CRUD Räume/Regale/Fächer, Zugriffsschutz).

---

AP-20 — Rohstoffbestand-Filter + „Kein Rohstoffbestand"-Flag

Anforderungen (Rohstoffbestand 1):

• Filter (a) alle Rohstoffe (auch nicht in aktiven Produkten — z. B. für Neuentwicklung eingekauft) und (b) nur Rohstoffe aus Herstellerrezepturen.
• INCI-Kontrollkästchen „Kein Rohstoffbestand" — Rohstoffe/Einträge (Allergene etc.), die gar nicht im Rohstoffbestand auftauchen sollen.

Ist-Stand: RawMaterialStockController@index listet alle aktiven Rohstoffe ohne Rezeptur-Bezug; kein Ausschluss-Flag.

DB (ingredients)

• exclude_from_stock bool default 0 (Migration). (Name bewusst „Kein Rohstoffbestand".)

Code

• Ingredient: fillable + cast exclude_from_stock; Checkbox „Kein Rohstoffbestand (z. B. Allergen-Angabe, nicht bevorratet)" im INCI-Formular.
• RawMaterialStockController@index:
  • grundsätzlich where('exclude_from_stock', false).
  • Umschalt-Filter Modus (?scope=all|recipe, Default all): bei recipe zusätzlich scopeUsedInActiveRecipes() (aus AP-21) anwenden. UI: zwei Pills/Tabs „Alle" / „Nur aus Herstellerrezepturen" im wawi-toolbar.
  • criticalIngredientCount() (für den Badge) respektiert ebenfalls exclude_from_stock.
• Optional: gleiche Ausschlusslogik in der Ausschuss-/Disposal-Auswahl, damit Allergen-INCIs dort nicht auftauchen (nice-to-have, nicht zwingend).

Akzeptanz: Rohstoffbestand lässt sich zwischen „alle" und „nur aus Herstellerrezepturen" umschalten; mit „Kein Rohstoffbestand" markierte INCI erscheinen nie im Rohstoffbestand (auch nicht im Kritisch-Badge).

Tests: RawMaterialStockTest erweitern (Modus „recipe" zeigt nur Rezeptur-INCI; exclude_from_stock blendet aus + aus Kritisch-Zähler; Default „alle" zeigt auch nicht-verwendete).

Abhängigkeit: AP-21 (liefert scopeUsedInActiveRecipes() + INCI-Formularfeld).

---

AP-23 — Rezeptur-Phasen (Hersteller-Rezeptur)

Anforderung (Produktebene 1): „Auf Produktebene müssen unter der Hersteller-Rezeptur noch die Phasen angelegt werden können." (Screen 2026-12-06-Rezeptur-phase.jpeg.)

Screen-Analyse: Mehrere Phasen (Phase A, Phase B …), je Phase eine Liste aus Rohstoff-Auswahl + Anteil %, ein Notiz-Textfeld pro Phase, „+" zum Hinzufügen einer Rohstoffzeile, Drag-Handle (≡) zum Sortieren, „+ Neue Phase". Gesamt 100,000 % über alle Phasen.

Ist-Stand: product_ingredients hat recipe_type (product/manufacturer), gram, factor, pos — keinen Phasen-Begriff.

DB

• Phasen als eigene Tabelle recipe_phases: product_id FK, recipe_type (vorerst nur manufacturer, Feld für spätere Ausweitung), name VARCHAR (z. B. „Phase A"), note TEXT nullable, pos int. Unique (product_id,recipe_type,name).
• product_ingredients.recipe_phase_id nullable FK (nur Hersteller-Zeilen tragen eine Phase; Produkt-Rezeptur bleibt phasenlos). Bestehende Hersteller-Zeilen ⇒ recipe_phase_id = NULL (= „ohne Phase"), Migration bricht nichts.

Code

• Models RecipePhase (+ Product::recipePhases(), phaseIngredients()); ProductIngredient um recipe_phase_id + phase()-Relation.
• Produktformular (Card „Hersteller-Rezeptur", resources/views/admin/product/…): Umbau analog Screen 1 — Phasen-Blöcke (jede mit Rohstoffzeilen, Anteil %, Notizfeld), Drag&Drop (Rohstoffzeilen innerhalb der Phase + Phasen untereinander), „+ Rohstoff" je Phase, „+ Neue Phase". Gesamtsumme 100 % über alle Phasen (vorhandene 100%-Validierung auf die Summe aller Phasen umstellen).
• Repository: Speichern persistiert Phasen (recipe_phases) und ordnet Hersteller-Rezepturzeilen ihrer Phase zu (recipe_phase_id); Product::copy() kopiert Phasen + Zuordnung mit.
• Rückwärtskompatibilität: Produkte ohne Phasen funktionieren weiter (eine implizite „Phase ohne Namen"). Die Produkt-Rezeptur (recipe_type='product') bleibt unverändert ohne Phasen.
• Konsumenten: ProductionService::requiredGramsByIngredient()/buildRecipePayload() rechnen weiterhin über alle Hersteller-Zeilen (Summe ist phasenunabhängig) — Phasen sind primär Darstellung/Reihenfolge; die Produktions-Maske (AP-28) gruppiert die Anzeige nach Phase.

Akzeptanz: Unter der Hersteller-Rezeptur lassen sich beliebig viele Phasen mit Rohstoffen, Anteilen und einer Phasen-Notiz anlegen, sortieren und löschen; die Gesamtsumme über alle Phasen muss 100 % ergeben; Kopieren übernimmt die Phasenstruktur.

Tests: RecipePhaseTest (Phasen + Zeilen speichern/sortieren, 100%-Summe über Phasen, Hersteller-Zeile trägt recipe_phase_id, Kopie inkl. Phasen, Produktion rechnet unverändert über alle Zeilen). Regression ProductionManufacturerRecipeTest.

---

AP-24 — Chargen-Nr.-Präfix (Produktebene)

Anforderung (Produktebene 2): Präfix aus Kategorie-Kürzel (TP – Tattoopflege) + Produkt-Nr. (1) + Produktionsdatum → Beispiel TP1150626. Das Präfix „TP1" wird auf Produktebene angelegt; in der Produktions-Maske erzeugt sich die Chargen-Nr. von selbst im Textfeld, bleibt aber editierbar (alte Etiketten).

Ist-Stand: Kein batch_prefix am Produkt; Produktion hat keine Chargen-Nr.-Logik. Screen 2 zeigt im „Produktionsergebnis" das Feld „Chargen-Nr." vorbefüllt mit KP1100626.

DB (products)

• batch_prefix VARCHAR nullable (z. B. „TP1").

Code

• Product: fillable batch_prefix; Eingabefeld „Chargen-Nr.-Präfix" in der Warenwirtschaft-Card des Produktformulars (Hilfetext: „Kürzel + Produkt-Nr., z. B. TP1 → Charge TP1150626").
• Helper Product::suggestedBatchNumber(?Carbon $date) = batch_prefix . $date->format('dmy') (Beispiel TP1 + 150626). Wird in AP-28 (Produktionsergebnis) als Vorbelegung des editierbaren Chargen-Nr.-Felds genutzt.

  Format-Klärung (vermerkt): Beispiel „TP1150626" = TP1 + 150626 (Produktionsdatum ddmmyy, hier 15.06.26). Bestätigung Datumsformat (ddmmyy) beim Kunden, falls abweichend (z. B. dmmyy).

Akzeptanz: Pro Produkt ist ein Chargen-Präfix hinterlegbar; in der Produktion wird die Chargen-Nr. daraus + Produktionsdatum vorgeschlagen und bleibt frei editierbar.

Tests: BatchPrefixTest (Präfix speichern; suggestedBatchNumber() setzt Präfix + Datum korrekt zusammen).

---

AP-28 — Neue Produktions-Maske + Produktionsergebnis

Anforderung (Produktion): Neue Maske (Screen 2026-12-06-neue-produktion.jpeg). Phasen fließen ein. Wichtig: Der Produktbestand errechnet sich nicht aus der oben gewählten Auswahl Produkt + Stückzahl (nur Planung). Ganz unten („Produktionsergebnis") trägt man ein, was real entstanden ist — mehrere Outputs möglich (Beispiel: Plan 50×50 ml → Ergebnis 40×50 ml + 50×5 ml). Der Rohstoffbestand berechnet sich wie gehabt aus den Werten hinter jeder Charge.

Screen-Analyse (Aufbau der Maske):

1. Kopf/Planung: Produkt, Größe, Produktionsdatum, Planung Stückzahl (rein informativ).
2. INCI-Liste (Hersteller-Rezeptur): Tabelle mit Name, Alternativer Name (AP-21), Qualität, Anteil %, Gramm, Regal (Lagerort, AP-21). Summenzeile 100 % / Gesamt-Gramm.
3. Verpackung (Vorschau): Artikel + Stück gesamt (aus BOM).
4. Notizen + „Speichern"/„Drucken".
5. Phasen-Erfassung (Phase A/B …, AP-23): je Rohstoffzeile Soll-Gramm + Status-Ampel (grün/orange) + Charge wählen + Ist-Gramm-Eingabe; je Phase ein Notiz-Textfeld. Gesamt-Gramm. → treibt den Rohstoffbestand (chargenbasiert, wie bisher production_ingredients).
6. Produktionsergebnis: Zeilen mit Produkt, Produzierte Stückzahl, Chargen-Nr. (vorbefüllt aus AP-24, editierbar), „+" für weitere Ergebniszeile. → treibt den Produktbestand.

Ist-Stand: productions.quantity ist der einzige Output und bucht heute den Produktbestand (ProductStockService::recordProductionStock). Keine Mehrfach-Outputs, keine Phasen-Anzeige, keine Regal-Spalte, kein Chargen-Nr.-Feld.

DB

• Neue Tabelle production_outputs: production_id FK cascade, product_id FK, quantity UINT, batch_number VARCHAR nullable, pos int. (Ein Production-Lauf ⇒ n Ergebniszeilen.)
• productions.quantity bleibt als geplante Stückzahl erhalten (umdeuten zu „Planung"; Spaltenname unverändert, um Bestandsdaten/Tests stabil zu halten) — optional Kommentar/Accessor planned_quantity.
• Migration der Buchungslogik (wichtig): Produktbestand wird künftig aus production_outputs gebucht, nicht mehr aus productions.quantity.

Code

• Model ProductionOutput (+ Production::outputs()).
• ProductStockService::recordProductionStock(Production) umstellen: idempotenter Differenz-Abgleich jetzt pro Output-Produkt (Summe der production_outputs.quantity je product_id), append-only — statt der bisherigen Einzel-quantity. Beim Bearbeiten einer Produktion wird die Differenz je betroffenem Produkt nachgebucht (vorhandenes idempotentes Muster beibehalten).
• ProductionService::store()/updateProduction(): nimmt zusätzlich outputs[] (Produkt + Stückzahl + Chargen-Nr.) entgegen, persistiert sie, ruft danach recordProductionStock. Rohstoffverbrauch (production_ingredients) bleibt unverändert chargenbasiert. StoreProductionRequest: outputs Pflicht (≥ 1 Zeile), je Zeile product_id exists + quantity ≥ 1; batch_number nullable string.
• Phasen-Anzeige: Hersteller-Rezeptur nach Phase gruppieren (RecipePhase, AP-23); Soll-Gramm/Ampel/Charge wie heute, nur nach Phase gegliedert + Phasen-Notiz anzeigen.
• Views: productions/_form_fields.blade.php + _scripts.blade.php (von create/edit/copy genutzt) erweitern:
  • INCI-Tabelle um Spalten „Alternativer Name" + „Regal" (Ingredient::storageLabel()).
  • Phasen-Gruppierung der Charge-Erfassung.
  • Produktionsergebnis-Block unten: Repeater (Produkt-Select default = geplantes Produkt, Stückzahl, Chargen-Nr. vorbefüllt aus Product::suggestedBatchNumber(produced_at), editierbar; „+" für weitere Zeile). Standard: eine Ergebniszeile mit geplantem Produkt + geplanter Stückzahl als Vorschlag.
• Klarer Hinweis-Text in der Maske: „Planung oben ist unverbindlich. Der Produktbestand entsteht aus dem Produktionsergebnis unten." (Anforderung explizit.)
• Produktentwicklung (Platzhalter aus AP-09) bleibt unberührt.

Akzeptanz:

• Die geplante Stückzahl oben bucht nichts; nur das Produktionsergebnis unten bucht den Produktbestand (auch mehrere Output-Produkte, z. B. 40×50 ml + 50×5 ml).
• Rohstoffbestand wird weiterhin aus den je Charge eingetragenen Ist-Mengen reduziert.
• Chargen-Nr. je Ergebniszeile ist vorbefüllt (Präfix + Datum) und editierbar.
• INCI-Liste zeigt Alternativname + Regal; die Charge-Erfassung ist nach Phasen gegliedert; Bearbeiten einer Produktion korrigiert den Produktbestand sauber per Differenz.

Tests: ProductionOutputTest (mehrere Outputs buchen Produktbestand je Produkt; Plan-Stückzahl bucht nicht; Bearbeiten korrigiert per Differenz; Rohstoffverbrauch unverändert chargenbasiert; Chargen-Nr.-Vorbelegung; Validierung ≥ 1 Output). Regression ProductStockTest + ProductionManufacturerRecipeTest (Produktionsbuchung jetzt über Outputs).

Migrationshinweis Bestandsdaten: Für bereits erfasste Produktionen ohne production_outputs einmalig je Produktion eine Output-Zeile (product_id=Produktionsprodukt, quantity=productions.quantity) backfillen, damit der gebuchte Produktbestand konsistent bleibt. Backfill als Teil der Migration (idempotent).

---

5. Offene Klärungspunkte (nicht blockierend, parallel mit Kunde abstimmen)

1. Lagerort-Modell (AP-21): drei getrennte Stammdaten (Raum/Regal/Fach) vs. eine generische Tabelle. Empfehlung: drei Tabellen (klare Dropdowns). → bei Umsetzungsstart final entscheiden.
2. Chargen-Nr.-Datumsformat (AP-24): Beispiel „TP1150626" als TP1+ddmmyy interpretiert (15.06.26). Bestätigen.
3. „Verbrauch/Monat" (AP-22): Definition „abgehende Bewegungen, Ø 6 Monate". Vor AP-13 nur manuelle/Produktions-Abgänge; mit AP-13 fließen Verkäufe ein. Bestätigen, ob 6 Kalendermonate gewünscht.
4. Produktionsergebnis-Produkte (AP-28): Dürfen Output-Produkte andere Produkte als das geplante sein (z. B. anderes Gebinde 5 ml als eigenes Produkt)? Screen + Beispiel legen ja nahe (40×50 ml + 50×5 ml ⇒ zwei Produkte/Varianten). → bestätigen; ggf. Varianten als eigene Produkte/main_product_id führen.
5. Wareneingang-Charge (AP-27): „addiert sich dazu" — Bestand zusammenführen, aber jeder Einkaufsvorgang bleibt als eigener stock_entry erhalten (nur Anzeige/Restbestand summiert je batch_number). Bestätigt durch die Formulierung „den Einkaufsvorgang erfassen wir trotzdem" → so umgesetzt.

---

6. AP-27 — Wareneingang: gleiche Charge zusammenführen

Anforderung: Gleiche Charge (z. B. Sonnenblumenöl XY-123) kommt erneut → soll sich beim weiteren Einkauf dazuaddieren. In der Maske erst prüfen, ob die Charge schon im Haus ist. Die Charge wird nicht einfach erweitert — der Einkaufsvorgang wird trotzdem (separat) erfasst.

Ist-Stand: stock_entries.batch_number vorhanden; keine Erkennung. Restbestand wird ohnehin pro batch_number/stock_entry über production_ingredients gerechnet.

Interpretation: Jeder Einkauf bleibt ein eigener stock_entry (Audit/Preis/Datum je Vorgang). „Dazuaddieren" = Restbestand und Anzeige werden je batch_number (+ Rohstoff) summiert. In der Erfassungsmaske ein Hinweis/Autofill, wenn die Charge für denselben Rohstoff bereits existiert (MHD/Lagerort vorbelegen, Bestätigung „zu bestehender Charge hinzufügen").

Code

• StockEntryController (create/store): beim Eingeben von batch_number + ingredient_id per kleinem JSON-Endpoint prüfen, ob eine Charge existiert; UI-Hinweis „Charge bereits im Haus — Menge wird dieser Charge zugerechnet" + Vorbelegung best_before/location_id aus dem bestehenden Eintrag (überschreibbar).
• InventoryService: Restbestand-/Detailansicht (AP-10) so anpassen, dass Chargen je batch_number über mehrere stock_entries summiert dargestellt werden (Eingang = Summe received_quantity aller Einträge dieser Charge; Verbrauch wie gehabt). Falls remainingByLocationForIngredient()/Charge-Liste bereits pro stock_entry gruppiert: auf Gruppierung nach batch_number umstellen.
• Produktion (Charge-Auswahl): Charge-Dropdown nach batch_number gruppieren (nicht je Einzel-stock_entry), Restbestand = Summe der Charge; Verbrauch bucht FEFO auf die Einträge der Charge.

Akzeptanz: Erfasst man eine bereits vorhandene Charge erneut, weist die Maske darauf hin und führt die Mengen in Bestand/Anzeige zusammen; jeder Einkauf bleibt als eigener Vorgang (Preis/Datum) erhalten; Produktion sieht die Charge mit summiertem Restbestand.

Tests: StockEntryChargeMergeTest (zwei Einkäufe gleicher Charge ⇒ summierter Restbestand, zwei separate stock_entry-Zeilen; Existenz-Check-Endpoint; Produktion sieht Charge einmal mit Summen-Rest). Regression RawMaterialStockTest, StockEntryPriceTest.

Einordnung: AP-27 ist in der Roadmap (Abschnitt 3) bewusst nicht terminiert vorgereiht, da es Anzeige-Logik des Rohstoffbestands (AP-10) und der Produktion (AP-28) berührt. Empfehlung: zusammen mit AP-28 umsetzen (gemeinsame Chargen-Gruppierung), spätestens davor. In der Reihenfolge daher zwischen AP-24 und AP-28 einzuplanen.

---

7. Empfohlene Sofort-Reihenfolge (nächste Schritte)

✅ Erledigt (12.06.2026): AP-26 (Ausschuss-Gründe konfigurierbar), AP-25 (Lieferbestand: Datum statt Tage, überall kaufbar), AP-22 (Produktbestand: Dringlichkeits-Sortierung / 4 klickbare Kacheln / Sichtbarkeits-Flag / Verbrauch-Monat). Hinweise-Doku (AP-18) jeweils fortgeschrieben.

➡️ Hier geht es weiter:

1. AP-21 (INCI: Lieferant+URL-Repeater, „nur aktive", Alternativname, Lagerort + Einstellungen) — Grundlage für AP-20 und für die Produktions-Maske. Vorab final entscheiden: Lagerort-Modell (§5 Punkt 1, Empfehlung: drei getrennte Stammdaten-Tabellen Raum/Regal/Fach).
2. AP-20 (Rohstoffbestand-Filter + „Kein Rohstoffbestand"-Flag) — direkt nach AP-21, nutzt dessen Scope + Formularfeld.
3. AP-23 (Rezeptur-Phasen) → AP-24 (Chargen-Präfix; Datumsformat ddmmyy bestätigen, §5 Punkt 2) → AP-27 + AP-28 (Wareneingang-Charge-Merge gemeinsam mit der neuen Produktions-Maske inkl. Produktionsergebnis; Output-Produkte-Frage §5 Punkt 4 bestätigen).
4. Danach offene V4.0-Pakete: AP-13 (Shop-Bestandsabzug, Konzept liegt vor), AP-14 (Audit-Trail), AP-15 (Blockrechte), AP-16 (2FA), AP-17 (WaWi-Einstellungen).
5. AP-18 (Hinweise-Doku) mit jedem AP fortschreiben.

---

8. Pflege dieses Dokuments

• Jedes abgeschlossene AP im Umsetzungsprotokoll (0a) mit Datum + Kurzbeschreibung + Test-Status protokollieren.
• Bei DB-Änderungen Migration-Dateinamen referenzieren; Casts in casts() pflegen (L11-Konvention).
• Vor jedem Commit: vendor/bin/pint --dirty und betroffene Tests (php artisan test --filter=...).
• UI-Konventionen (aus V4.0 weiter gültig): Design-System partials/wawi-ui.blade.php (AP-19); Datumsfelder als datepicker-base (dd.mm.yyyy, kein natives type="date"); Status über wawi-pill (ok/warning/danger).
• Neue Anforderungsquelle dieser Runde: docs/nächsten Anforderungen an die WaWi.md (12.06.2026) + die beiden 12.06.-Screens.