gruene-seele/dev/product management/entwicklungsplan-aktualisiert-27-04-2026.md

Aktualisierter Entwicklungsplan: Warenwirtschaft, Produktion & Produktbestand

Version: 3.0 - Stand 13.05.2026
Prioritaet: Anpassungsbriefing vom 27.04.2026 zuerst einarbeiten
Referenzen: entwicklungsplan.md, briefing-anpassungen-27-04-2026.md, feedback.md, Screens unter screens/

---

1. Aktueller Ist-Stand

Laut bestehendem entwicklungsplan.md sind die Phasen 0 bis 5.1 umgesetzt:

• Phase 0: Bugfixes Produkt/INCI, Sync-Logik, Sortierung, Kopierfehler.
• Phase 1: INCI-Erweiterung, Rezepturfelder, Haltbarkeit, Produktkopie.
• Phase 2: Stammdaten-Module fuer Lagerorte, Lieferanten, Verpackung, Qualitaeten.
• Phase 3: Einkauf & Wareneingang als Zwei-Stufen-Workflow.
• Phase 4: Verpackung & Material am Produkt.
• Phase 5: Produktion MVP mit Chargen, Rezeptur-API und Packaging-Snapshot.
• Phase 5.1: Feedback-Korrekturen zu Menue, Rezeptur, Produktion und Verpackungsartikeln.

Noch offen aus dem alten Plan:

• Phase 6: Bestandsuebersichten & Alarme.
• Phase 7: Ausgang / Ausschuss.
• Phase 8: Rollen, Audit-Trail & Feinschliff.
• Phase 9: Einstellungen & Konfiguration.
• Offene Tests aus Phase 5.1, insbesondere Rezeptur/Hersteller-Rezeptur, Produktion kopieren/bearbeiten, aktive Produkte und Menue-Labels.

Das Anpassungsbriefing vom 27.04.2026 erweitert den Scope wesentlich. Deshalb wird vor den alten Phasen 6 bis 9 eine neue priorisierte Phase eingeschoben.

---

2. Neue Priorisierung

Sofortige Reihenfolge

Prioritaet	Phase	Titel	Status	Abhaengigkeit
P0	5.2	Anpassungsbriefing 27.04.2026	neu, sofort	Phasen 0-5.1
P1	6	Rohstoffbestand & Produktbestand	offen, angepasst	Phase 5.2
P2	7	Ausgang, manuelle Bestandsbewegungen & Historie	offen, erweitert	Phase 6
P3	8	Rechte, 2FA, Audit-Trail	offen, erweitert	Phase 5.2 + 7
P4	9	Einstellungen & Konfiguration	offen, erweitert	Phase 5.2

Wichtig: Funktionen aus Phase 6-9 duerfen erst final umgesetzt werden, wenn die neuen Stammdatenfelder, Produkt-Set-Logik und Produktbestandslogik aus Phase 5.2 geklaert und umgesetzt sind.

---

3. Phase 5.2: Anpassungsbriefing 27.04.2026

Ziel: Alle neuen Anforderungen aus briefing-anpassungen-27-04-2026.md in das bestehende Warenwirtschaftsmodell integrieren, bevor Bestandsuebersichten und Historien final gebaut werden.

5.2.1 Einstellungen: UST-Saetze und Lieferzeiten

Anforderungen

• Neue konfigurierbare UST-Saetze, z. B. 19 %, 7 %.
• UST nicht hart im Code, sondern als Stammdatum/Setting verwalten.
• Lieferzeiten als frei definierbare Textwerte, z. B. 3-5 Tage.

Umsetzung

• Neues Einstellungsmodul oder Erweiterung der bestehenden Warenwirtschafts-Einstellungen:
  • tax_rates: Name, Prozentwert, aktiv.
  • delivery_times: Textwert, aktiv, Sortierung.
• UST-Dropdowns in Einkauf und INCI nutzen diese Werte.
• Lieferzeit-Dropdowns/Textfelder bei Lieferant und INCI anbinden.

Akzeptanzkriterien

• SuperAdmin kann UST-Saetze und Lieferzeiten pflegen.
• Einkauf und INCI koennen nur aktive UST-Saetze auswaehlen.
• Lieferzeiten bleiben bewusst als Text flexibel.

5.2.2 Produkte: Einzelprodukt, Set und Hauptprodukt-Zuordnung

Anforderungen

• Produkte werden in zwei Klassen unterschieden:
  • Einzelprodukt: hat Rezeptur, Hersteller-Rezeptur, Verpackung & Material, Warenwirtschaft.
  • Set: hat keine eigene Rezeptur/Produktion, sondern besteht aus mehreren Einzelprodukten mit Menge.
• Im Produktformular wird eine Checkbox/Option eingebaut: Ist Set.
• Wenn Ist Set aktiv ist:
  • Karten Rezeptur, Verpackung & Material und Warenwirtschaft ausblenden.
  • Neue Karte Set-Bestandteile anzeigen.
  • Modal mit auswaehlbaren Einzelprodukten, keine Sets.
• Produktbestand darf nur Hauptprodukte anzeigen.
• Child-/Set-Produkte muessen dem Hauptprodukt zugeordnet werden koennen, z. B. 50 x Bio Tattoocreme 15 ml.

Umsetzung

• products erweitern:
  • is_set boolean.
  • main_product_id nullable FK auf products.
  • optional main_product_quantity fuer Child-Produkte.
• Neue Pivot-Tabelle fuer Sets:
  • product_set_items: set_product_id, component_product_id, quantity.
• Produktformular:
  • Umschaltlogik fuer Einzelprodukt/Set.
  • Set-Bestandteile wie bestehende Rezeptur-/Packaging-Modals aufbauen.
• Validierung:
  • Set darf keine Sets enthalten.
  • Set braucht mindestens einen Bestandteil.
  • Einzelprodukt darf Rezeptur/Packaging/Warenwirtschaft pflegen.

Akzeptanzkriterien

• Ein Set kann aus mehreren Einzelprodukten bestehen.
• Beim Verkauf eines Sets werden die enthaltenen Einzelprodukte im Produktbestand reduziert.
• Set-Produkte erscheinen nicht als selbst produzierbare Produkte.
• Produktbestand zeigt nur Haupt-/Einzelprodukte, nicht die Child-/Set-Varianten.

5.2.3 Einkauf & Wareneingang erweitern

Anforderungen

• Einkauf bekommt UST-Dropdown.
• Brutto-Preis pro kg und Netto-Preis pro kg: eines der beiden Felder kann eingegeben werden, das andere berechnet sich automatisch.
• Ausgefuellten Einkauf duplizierbar machen.
• Aktionsicons Auge/Stift/Muelleimer in Tabellen groesser und mit mehr Abstand, iPad-tauglich.

Umsetzung

• stock_entries erweitern:
  • tax_rate_id oder gespeicherter Snapshot tax_rate_percent.
  • price_per_kg_net.
  • price_per_kg_gross.
• Frontend-JS:
  • Netto/Brutto anhand UST gegenseitig berechnen.
  • Rundung einheitlich definieren.
• Copy-Route fuer Einkauf:
  • Dupliziert Stufe-1-Felder.
  • Laesst Chargennummer, MHD, Eingangsdaten und Status leer bzw. setzt wieder auf pending.
• Gemeinsame Tabellen-Aktionsklasse einfuehren:
  • groessere Buttons.
  • mehr Abstand.
  • konsequent fuer Einkaufs-, Lieferanten-, Produktions-, Bestands- und Stammdatentabellen.

Akzeptanzkriterien

• Einkauf kann mit Netto oder Brutto angelegt werden.
• Beim Wechsel des UST-Satzes wird das Gegenfeld aktualisiert.
• Ein Einkauf kann fuer mehrere Kanister/Chargen komfortabel dupliziert werden.
• Tabellenaktionen sind auf dem iPad gut klickbar.

5.2.4 Lieferanten erweitern

Anforderungen

• Lieferant braucht Auswahl, ob Bestellung per Mail oder Online-Shop erfolgt.
• Je nach Auswahl soll spaeter in Rohstoffbestand/Bestellhilfe ein Link zum Shop oder ein Mail-Link erscheinen.
• Lieferant bekommt Lieferzeit als frei pflegbares Textfeld.

Umsetzung

• suppliers erweitern:
  • order_method enum/string: email, online_shop.
  • order_email nullable, falls abweichend von Kontakt-Mail.
  • order_url nullable, falls abweichend von allgemeiner URL.
  • delivery_time nullable string.
• Lieferantenformular:
  • Radio/Select fuer Bestellart.
  • passende Felder anzeigen.
• Spaetere Nutzung in Rohstoffbestand:
  • Button Bestellen erzeugt mailto: oder oeffnet Shop-URL.

Akzeptanzkriterien

• Pro Lieferant ist erkennbar, wie bestellt wird.
• Rohstoffbestand kann daraus einen konkreten Bestell-Link ableiten.
• Lieferzeit des Lieferanten ist sichtbar und editierbar.

5.2.5 INCI erweitern

Anforderungen

• Pro INCI Mehrfachauswahl der Lieferanten, bei denen es gekauft werden kann.
• Pro INCI UST-Satz hinterlegen.
• Pro INCI optional eigene Lieferzeit; diese ueberschreibt die Lieferzeit des Lieferanten.

Umsetzung

• Neue Pivot-Tabelle:
  • ingredient_supplier: ingredient_id, supplier_id, optional preferred, supplier_sku, url.
• ingredients erweitern:
  • tax_rate_id oder Snapshot.
  • delivery_time nullable string.
• INCI-Formular:
  • Lieferanten-Mehrfachauswahl per Select2.
  • UST-Dropdown.
  • Lieferzeit-Textfeld.

Akzeptanzkriterien

• Ein INCI kann mehrere Lieferanten haben.
• Rohstoffbestand kann alle moeglichen Lieferanten mit Lieferzeit anzeigen.
• INCI-Lieferzeit ueberschreibt Lieferanten-Lieferzeit.

5.2.6 Produktion korrigieren

Anforderungen

• Neue Produktion optisch vereinfachen:
  • weniger Linien.
  • Ueberschriften Charge und Menge bei einzelnen Rohstoffen entfernen.
  • bei Mengenangaben g hinter die Zahl.
• Chargen-Dropdown zeigt Lieferant, Charge und MHD:
  • Beispiel: Manske GmbH - DE-170722 - 30.09.2028.
  • MHD-Text nicht anzeigen.
  • Nur Chargen anzeigen, von denen noch Bestand vorhanden ist.
• Basis fuer Produktion ist die Hersteller-Rezeptur.
• Fehler beim Hinzufuegen einer Charge beheben: Es duerfen nicht automatisch zwei neue Felder erscheinen.
• Wenn oben z. B. Stueckzahl geaendert wird:
  • bestehende ausgefuellte Chargen/Mengen bleiben erhalten.
  • nur Soll-Angaben in Gramm werden neu berechnet.
• iPad-Layout: Produktionsdatum und produzierte Stueckzahl duerfen nicht ueberlappen.
• Neuer Untermenuepunkt Produktentwicklung unter Produktion als Platzhalter.

Umsetzung

• ProductionController::recipeJson() auf Hersteller-Rezeptur als Basis umstellen.
• Chargenquery im InventoryService oder ProductionService:
  • nur received Chargen.
  • Restbestand pro Charge > 0.
  • Label mit Lieferant, Chargennummer, Datum d.m.Y.
• JS fuer Chargen-Splitting korrigieren:
  • genau eine neue Zeile pro Klick.
  • vorhandene Eingaben beim Neuberechnen nicht ueberschreiben.
• Responsive Bootstrap-Grid fuer Kopfdaten der Produktion ueberarbeiten.
• Route/View fuer Produktentwicklung als Platzhalterseite:
  • Hinweis: Konzept folgt.
  • noch keine Bestandsbuchung.

Akzeptanzkriterien

• Produktion basiert auf Hersteller-Rezeptur.
• Chargenliste zeigt nur verfuegbare Chargen mit Lieferant und Datum.
• Aenderung der Stueckzahl zerstoert keine manuell eingetragenen Chargen.
• iPad-Darstellung ist nutzbar.
• Menuepunkt Produktentwicklung existiert sichtbar.

5.2.7 Rohstoffbestand als neuer Schwerpunkt

Anforderungen

• Neuer Menuepunkt Rohstoffbestand.
• Uebersicht zeigt, welche Rohstoffe im Lager sind.
• Muss Lieferanten, Lieferzeiten und Bestellmoeglichkeiten beruecksichtigen.
• Grundlage fuer spaetere Nachbestellung/Knappheitsanzeige.

Umsetzung

• Bestehende alte Phase 6 Bestand Rohstoffe wird inhaltlich auf Rohstoffbestand priorisiert.
• Spaltenvorschlag:
  • INCI/Rohstoff.
  • Qualitaet.
  • Gesamtbestand.
  • Bestand je Lagerort.
  • reserviert/verbraucht durch Produktionen.
  • Meldebestand oder berechneter Bedarf.
  • Status.
  • Lieferanten.
  • Lieferzeit.
  • Bestellaktion.
• Lieferzeitlogik:
  • INCI-Lieferzeit vor Lieferanten-Lieferzeit.
• Bestellaktion:
  • Online-Shop-Link oder Mail-Link je Lieferant.

Akzeptanzkriterien

• Rohstoffbestand zeigt reale Restbestaende aus Wareneingang minus Produktion/Ausgang.
• Nur Chargen mit Restbestand fliessen ein.
• Kritische Rohstoffe sind visuell markiert.
• Bestellweg ist direkt aus der Uebersicht erreichbar.

5.2.8 Produktbestand & Historie

Anforderungen

• Neuer Hauptmenuepunkt Produktbestand.
• Unterpunkt Historie.
• Produktbestand erlaubt einfache Ein- und Ausgaenge.
• Historie dokumentiert jeden Ein- und Ausgang revisionssicher, auch Verkauf ueber Shops und manuelle Eingaben.
• Screens zeigen:
  • Suche.
  • Checkbox nur kritische anzeigen.
  • Bestand je Produkt.
  • rote/gelbe Markierung bei kritischem Bestand.
  • Aktionsbuttons +, -, Produzieren.
• Produktbestand zeigt nur Hauptprodukte.

Umsetzung

• Neue Tabellen:
  • product_stock_movements: Produkt, Richtung in/out, Menge, Grund, Quelle, User, Datum, Referenz.
  • optional product_stock_thresholds oder Felder an products: min_product_stock, critical_product_stock.
• Produktbestand wird berechnet:
  • Summe Produktion/manuelle Eingaenge minus Verkauf/manuelle Ausgaenge/Set-Verbrauch.
• Manueller Eingang/Ausgang:
  • Menge Pflicht.
  • Grund Pflicht.
  • Richtung Pflicht.
• Historie:
  • filterbar nach Produkt, Quelle, Zeitraum, User.
  • unveraenderbar bzw. Korrektur nur ueber Gegenbuchung.
• Shop-Verkaeufe:
  • Produktbestand nach Bestellung reduzieren.
  • Bei Sets Bestand der enthaltenen Einzelprodukte reduzieren.

Akzeptanzkriterien

• Produktbestand ist schnell pflegbar.
• Jede Bewegung steht in der Historie.
• Set-Verkaeufe reduzieren die enthaltenen Einzelprodukte.
• Kritische Produkte koennen gefiltert werden.

5.2.9 Nicht vorrätig mit Zeitangabe

Anforderungen

• Produkt bekommt Checkbox Nicht vorrätig.
• Zahl in Tagen wird hinterlegt.
• Im Shop erscheint z. B. In ca. 14 Tagen wieder da!.
• Die Zahl zaehlt automatisch runter und aktualisiert sich in der Bestellansicht.

Umsetzung

• products erweitern:
  • out_of_stock_until date nullable oder out_of_stock_days plus Startdatum.
  • Empfehlung: out_of_stock_until, weil daraus Resttage sauber berechnet werden.
• Produktformular:
  • Checkbox.
  • Tagefeld.
  • beim Speichern now()->addDays($days).
• Shopanzeige:
  • Wenn Datum in Zukunft: Kaufbutton ersetzen/ergaenzen mit Hinweis.
  • Resttage dynamisch berechnen.
• Scheduler optional:
  • Status nach Ablauf automatisch deaktivieren oder Anzeige laeuft durch Datumslogik aus.

Akzeptanzkriterien

• Produkt kann zeitweise als nicht vorrätig markiert werden.
• Hinweis im Shop zeigt aktuelle Resttage.
• Nach Ablauf verschwindet der Hinweis automatisch.

5.2.10 Admin-Sicherheit: 2FA und blockbasierte Rechte

Anforderungen

• 2FA per Google Authenticator fuer Admins.
• Rechtevergabe pro Block:
  • ansehen.
  • bearbeiten.
  • optional loeschen/freigeben.
• Mitarbeiter koennen Admins sein, aber nur ausgewaehlte Bereiche sehen/bearbeiten.

Umsetzung

• 2FA:
  • Pruefen, ob bestehende Auth-Struktur mit App\User und Guard user erweitert wird.
  • TOTP-Secret am User speichern.
  • Setup-Flow fuer Admins.
  • Login-Zwischenschritt fuer 2FA-Code.
• Rechte:
  • Neues Berechtigungsmodell statt nur numerischem admin-Level fuer Warenwirtschaftsbloecke.
  • Tabellen z. B. admin_permission_blocks, admin_permission_user.
  • Bloecke: Produkte, Einkauf, Rohstoffbestand, Produktbestand, Produktion, Lieferanten, Einstellungen, Historie.
  • Middleware/Gates fuer view und edit.

Akzeptanzkriterien

• Admin kann ohne 2FA nicht in geschuetzte Bereiche, sobald 2FA aktiviert ist.
• SuperAdmin kann pro Mitarbeiter Rechte je Block vergeben.
• Navigation zeigt nur erlaubte Bloecke.
• Bearbeiten ist getrennt von Einsehen steuerbar.

---

4. Angepasste offene Phasen nach 5.2

Phase 6: Rohstoffbestand & Produktbestand

Status: offen, erweitert durch Screens und Anpassungsbriefing.

Inhalt

• InventoryService finalisieren.
• Rohstoffbestand mit Lieferanten-, Lieferzeit-, UST- und Bestellinformationen.
• Produktbestand mit Hauptproduktfilter, kritischen Markierungen, manuellen Bewegungen und Produzieren-Shortcut.
• Bestand pro Lagerort und Gesamtbestand.
• Kritisch-Filter analog Screen.

Tests

• Bestandsberechnung Rohstoffe pro Charge und Lagerort.
• Nur Chargen mit Restbestand werden angezeigt.
• Produktbestand zeigt nur Hauptprodukte.
• Set-Verkauf reduziert Einzelproduktbestand.
• Kritisch-Filter zeigt nur Produkte/Rohstoffe unter Schwellwert.

Phase 7: Ausgang, Bewegungen & Historie

Status: offen, inhaltlich erweitert.

Inhalt

• Alter Ausgang / Ausschuss bleibt fuer Rohstoffe/Verpackung relevant.
• Produktbestand bekommt eigene Bewegungslogik.
• Produktbestand-Historie als Finanzamt-/Audit-Archiv.
• Jeder manuelle Ein- und Ausgang braucht Grund, User und Datum.

Tests

• Rohstoff-Ausgang reduziert Rohstoffbestand.
• Produkt-Ausgang reduziert Produktbestand.
• Historie dokumentiert alle Quellen: Produktion, Verkauf, manuell, Set.
• Manuelle Korrektur ohne Grund wird abgelehnt.

Phase 8: Rollen, Audit-Trail, 2FA

Status: offen, erweitert.

Inhalt

• Bisheriger Audit-Trail bleibt Pflicht.
• Blockbasierte Rechte ersetzen fuer neue Module reine Level-Annahmen.
• 2FA fuer Admins.
• Bestehende Rollenlevel bleiben als Grundschutz erhalten, werden aber fuer Modulrechte verfeinert.

Tests

• User mit Leserecht kann sehen, aber nicht speichern.
• User ohne Blockrecht sieht den Menuepunkt nicht.
• 2FA-Zwischenschritt greift fuer Admins.
• Audit-Log wird bei jeder Bestandsbewegung geschrieben.

Phase 9: Einstellungen & Konfiguration

Status: offen, erweitert.

Inhalt

• UST-Saetze.
• Lieferzeiten.
• Bestandsalarm-E-Mail.
• Standard-Lagerort.
• Produktbestand-Schwellwerte, falls global sinnvoll.
• Optional: Standardtexte fuer Nicht vorrätig.

Tests

• Nur SuperAdmin kann Einstellungen pflegen.
• UST-Saetze koennen deaktiviert, aber historische Werte weiterhin angezeigt werden.
• Lieferzeiten stehen in Lieferanten und INCIs zur Auswahl.

---

5. Offene Klaerungspunkte

• Soll Nicht vorrätig den Kauf komplett sperren oder nur einen Hinweis anzeigen?
• Wird Produktbestand beim Status bezahlt, versendet oder direkt bei Bestellung reduziert?
• Sollen Produktbestandsbewegungen auch Stornos/Retouren automatisch abbilden?
• Soll die blockbasierte Rechtevergabe nur fuer Warenwirtschaft/Produktmanagement gelten oder fuer alle Admin-Bereiche?
• Soll Produktentwicklung bereits Bestandsabzug erzeugen oder zunaechst nur ein Platzhalter-Menuepunkt sein?
• Soll ein Child-Produkt zwingend genau ein Hauptprodukt haben oder koennen mehrere Einzelprodukte in einem Verkaufsprodukt gebuendelt werden? Fuer echte Sets ist die Pivot-Loesung vorgesehen.

---

6. Empfohlene naechste Umsetzungsschritte

1. Datenmodell fuer is_set, Set-Bestandteile, Hauptprodukt-Zuordnung und Produktbestand finalisieren.
2. Einstellungen fuer UST-Saetze und Lieferzeiten umsetzen, weil Einkauf/INCI/Lieferanten davon abhaengen.
3. Lieferanten und INCIs um Bestellweg, Lieferzeit, UST und Lieferanten-Zuordnung erweitern.
4. Einkauf um Netto/Brutto/UST, Duplizieren und iPad-taugliche Aktionsbuttons erweitern.
5. Produktion auf Hersteller-Rezeptur, bessere Chargenlabels und stabile JS-Neuberechnung korrigieren.
6. Produktbestand mit Historie und manuellen Bewegungen bauen.
7. Rohstoffbestand mit Lieferanten-/Bestellinformationen bauen.
8. Danach alte Phasen 7-9 finalisieren: Ausgang, Audit, Rechte, 2FA, Einstellungen.

---

7. Grobe Aufwandsschaetzung

Block	Aufwand
Einstellungen UST/Lieferzeiten	1-2 Tage
Produkt Set-/Hauptproduktmodell	3-5 Tage
Einkaufserweiterungen	2-3 Tage
Lieferanten/INCI-Erweiterungen	2-4 Tage
Produktionskorrekturen	2-4 Tage
Rohstoffbestand	4-6 Tage
Produktbestand + Historie	5-8 Tage
Nicht vorrätig	1-2 Tage
2FA Admins	3-5 Tage
Blockbasierte Rechte	5-8 Tage
Tests & Feinschliff	4-6 Tage

Neue Gesamtannahme fuer offene Arbeit: ca. 6-9 Wochen bei einem Entwickler, abhaengig davon, wie tief Shop-Verkaeufe, Stornos und Rechtevergabe integriert werden sollen.