Warenwirtschaft: Doku-Ordner sortiert + Gesamt-Roadmap (README)

Product-Management-Ordner in 00-konzept / 01-entwicklungsplaene / 02-audit / 03-status-und-vorschlaege gegliedert (Datei-Moves bereits in 037ec4d). Ergänzt: - README.md als Einstieg mit grober Roadmap (Ist-Stand live/in Test, erledigte APs, offene AP-32/33c/14/15/16/17, Deckel-Varianten-Vorschlag) und Verweisen. - Leistungsübersicht + Deckel-Varianten-Vorschlag (23.07.) in den Ordner einsortiert und nun mitversioniert. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-26 10:38:04 +00:00 · 2026-08-26 10:38:04 +00:00 · 29ced440b0
commit 29ced440b0
parent a13c0f2ed1
3 changed files with 318 additions and 0 deletions
--- a//03-status-und-vorschlaege/leistungsuebersicht-warenwirtschaft-23-07-2026.md
+++ b//03-status-und-vorschlaege/leistungsuebersicht-warenwirtschaft-23-07-2026.md
@ -0,0 +1,83 @@
+# Leistungsübersicht: Warenwirtschafts-Modul
+
+**Stand: 23.07.2026 · Projektzeitraum: März – Juli 2026**
+
+Diese Übersicht fasst die Entwicklung des Warenwirtschafts-Moduls in logische Leistungspakete zusammen. Die Zeitangaben sind Aufwandsschätzungen in Personentagen (PT), abgeleitet aus den Entwicklungsplänen und der Umsetzungshistorie.
+
+---
+
+## Phase 1 — Konzeption & Grundausbau (März – April 2026)
+
+| # | Leistungspaket | Inhalt | Aufwand |
+|---|---|---|---|
+| 1 | **Konzeption & Briefing** | Anforderungsaufnahme, Fachkonzept (Datenmodell für Rohstoffe, Chargen, Rezepturen, Produktion), Entwicklungsplan mit Priorisierung | 3–4 PT |
+| 2 | **Grundausbau Warenwirtschaft** | Kompletter Grundstock des Moduls: Stammdaten (Lieferanten, Rohstoffe/INCI, Verpackungen, Lagerorte), Einkauf & Wareneingang mit Chargen- und MHD-Erfassung, Produktionserfassung mit Rezeptur-Verbrauch, Integration in den Admin-Bereich, automatisierte Tests | 15–18 PT |
+| 3 | **Feedback-Runde Frühjahr** | Einarbeitung des Kundenfeedbacks aus April (Briefing-Anpassungen 27.04.), Korrekturen und Detailverbesserungen | 2–3 PT |
+
+**Zwischensumme Phase 1: ca. 20–25 PT**
+
+---
+
+## Phase 2 — Stammdaten-Ausbau & Bestandsführung (Mai – Juni 2026)
+
+| # | Leistungspaket | Inhalt | Aufwand |
+|---|---|---|---|
+| 4 | **Korrekturen & Stammdaten-Ausbau** (AP-00–AP-09) | Testbasis nachgezogen, Quick-Fixes, iPad-taugliche Bedienung, Einstellungen für USt-Sätze & Lieferzeit-Vorlagen, Lieferanten-Erweiterung (Bestellweg, Lieferzeit), Rohstoff-Erweiterung (Mehrfach-Lieferanten, USt), Einkauf mit Netto/Brutto-Automatik & Duplizieren, Produktion vollständig auf Hersteller-Rezeptur umgestellt | 10–13 PT |
+| 5 | **Bestandsführung** (AP-02/03/10/11/12, AP-18/19) | Set-Produkte mit Bestandteilen, „Nicht vorrätig"-Kennzeichnung im Shop, **Rohstoffbestand** (Restmengen je Charge, Verbrauch/Tag, Reichweiten-Prognose, Kritisch-Warnungen, Bestell-Detailseite), **Produktbestand** mit revisionssicherer Historie und manuellen Buchungen, **Ausschuss-Erfassung**, einheitliches UI-Design, integrierte Hinweise-/Doku-Seite | 15–18 PT |
+| 6 | **Anforderungsrunde Juni** (AP-22/25/26) | Produktbestand-Erweiterungen (Dringlichkeits-Sortierung, Übersichts-Kacheln, Verbrauch/Monat), Lieferbestand mit „Wieder lieferbar ab"-Datum, konfigurierbare Ausschuss-Gründe | 2,5–4 PT |
+
+**Zwischensumme Phase 2: ca. 28–35 PT**
+
+---
+
+## Phase 3 — Produktion V2 & Code-Qualität (Juni – Juli 2026)
+
+| # | Leistungspaket | Inhalt | Aufwand |
+|---|---|---|---|
+| 7 | **Technische Optimierung** (OPT-1–4) | Performance (Datenbank-Indizes, Abfrage-Optimierung), Pagination großer Listen, Code-Vereinheitlichung der Einstellungs-Verwaltungen, Refactoring der Bestandsansicht | 3–5 PT |
+| 8 | **Fachlicher Ausbau** (AP-20/21/23/24/27) | INCI-Erweiterungen (Lieferanten mit URL, Alternativname, Lagerorte Raum/Regal/Fach inkl. Verwaltung), Rohstoffbestand-Filter + „Kein Rohstoffbestand"-Flag, **Rezeptur-Phasen** (Phase A/B/… mit Drag & Drop), Chargen-Nummern-Präfix mit Auto-Generierung, Wareneingang: Zusammenführen gleicher Chargen | 8–12 PT |
+| 9 | **Neue Produktions-Maske + Produktionsergebnis** (AP-28) | Komplett überarbeitete Produktionserfassung: mehrere Ergebnis-Produkte je Produktion, Phasen-Anzeige mit INCI-Liste, Buchung des Produktbestands aus dem tatsächlichen Ergebnis, Chargen-Auswahl nach FEFO | 5–8 PT |
+| 10 | **Kunden-Testleitfaden** | Klickbarer Testleitfaden für die Abnahme, im System als Menüpunkt „Leitfaden" hinterlegt | 1–1,5 PT |
+
+**Zwischensumme Phase 3: ca. 17–26 PT**
+
+---
+
+## Phase 4 — Audit, Shop-Anbindung & Versand (Juli 2026)
+
+| # | Leistungspaket | Inhalt | Aufwand |
+|---|---|---|---|
+| 11 | **Qualitäts- & Sicherheits-Audit inkl. Fixes** (OPT-6–9, AP-31) | Vollständiger Audit des Moduls (Bericht 15.07.), anschließend Behebung aller Befunde: Bestandswahrheit (Ausschuss in Chargen-Restmengen), Buchungs-Härtung gegen Doppelbuchungen, Rezeptur-Robustheit, Zugriffsschutz/CSRF-Härtung, Löschen mit Abhängigkeitsprüfung, 8 kleinere Befunde | 3–4 PT |
+| 12 | **Shop-Anbindung: automatischer Bestandsabzug** (AP-13) | Bestandsabzug beim Versand inkl. Set-Auflösung, Storno-Rückbuchung, Protokoll-Seite „API-Bestellungen" mit Fehler-Markierung, Stichtags-Schutz für Altbestellungen | 3–5 PT |
+| 13 | **Bestell-Abwicklung** (AP-33a/b) | Neuer Bereich „Bestellungen" mit Fulfillment-Board (iPad-optimiert), Status-Führung mit Versand-Sperre, Sammel-PDF: Lieferscheine/Rechnungen einer Auswahl als ein Dokument | 3,5–5 PT |
+| 14 | **DHL-Versand: Brückenlösung + Shop-Connector** (AP-32-Brücke) | Übernahme der DHL-Versandetiketten aus dem Shop ins Partnercenter, Weiterentwicklung des Connector-Plugins (Versionen 1.4.0 / 1.5.0), Logistik-Mail mit vollständigen Dokumenten (Lieferschein + Rechnung) | 2–3 PT |
+| 15 | **Abschluss-Review & Stabilisierung** | Systematisches Code-Review vor der Testphase mit 10 behobenen Befunden, API-Bugfixes (Variations-Zuordnung, interne Produkte, WP-Nummern-Ableitung), Regressionstest der gesamten Suite (296 Tests) | 2,5–3,5 PT |
+
+**Zwischensumme Phase 4: ca. 14–20 PT**
+
+---
+
+## Gesamtübersicht
+
+| Phase | Zeitraum | Aufwand |
+|---|---|---|
+| 1 — Konzeption & Grundausbau | März – April | 20–25 PT |
+| 2 — Stammdaten & Bestandsführung | Mai – Juni | 28–35 PT |
+| 3 — Produktion V2 & Code-Qualität | Juni – Juli | 17–26 PT |
+| 4 — Audit, Shop-Anbindung & Versand | Juli | 14–20 PT |
+| **Gesamt** | **März – Juli 2026** | **ca. 80–105 PT** |
+
+---
+
+## Noch offene / nachgelagerte Pakete (Kundenentscheid 16.07.2026: erst nach Testphase)
+
+| Paket | Inhalt | Schätzung |
+|---|---|---|
+| AP-32 (voll) | DHL-Etiketten direkt im System per API erstellen | 3–5 PT |
+| AP-33c | Etiketten-Stapeldruck + Automatik-Option | 1 PT |
+| AP-14 | Audit-Trail (lückenlose Änderungshistorie) | 2–3 PT |
+| AP-16 | 2-Faktor-Authentifizierung für Admins | 2–3 PT |
+| AP-15 | Blockbasierte Rechte (sehen/bearbeiten je Bereich) | 4–6 PT |
+| AP-17 | Zentrale Warenwirtschafts-Einstellungsseite | 1–2 PT |
+
+**Offen gesamt: ca. 13–20 PT**
--- a//03-status-und-vorschlaege/vorschlag-deckel-varianten-produktion-23-07-2026.md
+++ b//03-status-und-vorschlaege/vorschlag-deckel-varianten-produktion-23-07-2026.md
@ -0,0 +1,108 @@
+# Vorschlag: Deckel-Varianten (White Label) in Produktion & Bestand
+
+> **Stand:** 23.07.2026
+> **Anlass:** Kundenanforderung — Produkte wie die Deocreme haben identischen Inhalt und identische Verpackung, nur die **Farbe des Tiegel-Deckels** unterscheidet sich (White-Label-Varianten unter `admin/product/attributes`). Produziert wird **eine Charge**, die anschließend **nach Bedarf** unterschiedliche Deckel-Varianten bekommt — nicht jede Sorte einzeln.
+> **Frage:** Ist das schon abgedeckt oder muss erweitert werden?
+> **Kundenergänzung 23.07.2026:** Produkte mit Deckel-Varianten werden **nur direkt im System an Vertriebspartner** verkauft — kein Verkauf über die API/WooCommerce-Shops.
+> **Bezug:** Entwicklungsplan V6.0 (`entwicklungsplan-aktualisiert-06-07-2026.md`), insbes. AP-24 (Chargen-Präfix), AP-28 (Produktionsergebnis), AP-13 (Verkaufs-Abzug)
+
+---
+
+## 1. Kurzantwort
+
+**Das Chargen-Szenario selbst ist bereits abgedeckt.** Seit AP-28 gilt: eine Produktion = eine Charge, und das Produktionsergebnis darf aus **mehreren Zeilen** bestehen (Produkt + Stückzahl + Chargen-Nr. je Zeile, auch andere Produkte als geplant — Kundenentscheid 06.07.2026, Beispiel 40×50 ml + 50×5 ml). Eine Deocreme-Charge, die auf mehrere Produkte/Größen aufgeteilt wird, ist heute ohne Erweiterung buchbar — alle Zeilen können dieselbe Chargen-Nr. tragen.
+
+**Was das System bewusst nicht kennt: Bestand je Deckel-Farbe.** Die Deckel-Varianten sind reine **Attribute** („Variante Tiegel": Weiß/Schwarz/Gold/Silber × 15/40/140 ml), keine eigenen Artikel. Der gesamte Bestands- und Verkaufspfad (Produktbestand, Produktions-Buchung, AP-13-Abzug, API-SKU-Mapping) läuft strikt über `product_id` — die Variante ist überall bestandsneutral.
+
+**Ob erweitert werden muss, hängt an genau einer fachlichen Frage:**
+
+> **Werden die Deckel erst bei der Konfektion/dem Versand nach Bedarf aufgesetzt (dann reicht der heutige Stand fast vollständig) — oder liegen fertig konfektionierte Tiegel je Deckelfarbe im Regal und sollen als solche gezählt werden (dann braucht der Bestand eine Varianten-Dimension)?**
+
+Die Formulierung der Anforderung („eine Charge, die dann unterschiedliche Deckel-Varianten bekommt", „nach Bedarf hergestellt") spricht klar für Ersteres → **Empfehlung: Variante V1 (Abschnitt 4)** — kein Umbau der Produktion, nur zwei kleine optionale Ergänzungen.
+
+---
+
+## 2. Ist-Stand im System (verifiziert per Code + Live-DB, 23.07.2026)
+
+### 2.1 Varianten = Attribute, nicht Artikel
+- Attribut-Typ **„Variante Tiegel"** (Werte-Schema `TiegelML#LogoCM`) mit 13 Ausprägungen: Weiß/Schwarz/Gold/Silber je 15/40/140 ml, dazu Bodenetikett und Braunglasflasche 30 ml (`attributes`-Tabelle).
+- Zuordnung zum Produkt über `product_attributes` (Pivot). Aktuell tragen die White-Label-Produkte (Bio Tattoocreme 15/40 ml, Pfötchenbalm, Tattooseife …) je 1–4 Tiegel-Varianten. **Die Deocreme-Produkte haben derzeit noch keine Varianten-Zuordnung** — die würde bei Bedarf genauso über das Produktformular gepflegt.
+- Genutzt werden die Varianten im **White-Label-Prozess**: Der Partner lädt seine Etiketten hoch, und jedes Etikett wird einer oder mehreren Tiegel-Varianten zugeordnet (`resources/views/admin/lead/m_white_label.blade.php`, `image_wl_attributes`). Die Deckel-Farbe ist also **Konfigurationsmerkmal des Partner-Whitelabels**, kein Bestellmerkmal.
+
+### 2.2 Bestellungen kennen keine Variante
+- `shopping_order_items` speichert nur `product_id` + Menge/Preis — keine Attribut-Spalte.
+- **Vertriebsweg (Kundenergänzung 23.07.2026):** Produkte mit Deckel-Varianten werden **ausschließlich direkt im System an Vertriebspartner** verkauft — sie laufen **nicht** über die API/WooCommerce-Shops. Das API-SKU-Mapping (`wp/order` → `wp_number`) spielt für diese Produkte also keine Rolle; der Connector bleibt in jedem Fall unberührt.
+- Folge: Ein **exakter Verkaufs-Abzug je Deckelfarbe wäre heute trotzdem nicht möglich**, weil die Bestellposition die Variante nicht trägt. Da der Käufer aber immer der Vertriebspartner selbst ist, ließe sich die Farbe vergleichsweise zuverlässig aus dessen WL-Konfiguration ableiten — eindeutig ist das nur nicht, wenn ein Partner mehrere Varianten führt.
+
+### 2.3 Produktion & Bestand (AP-24/27/28, AP-13)
+- Eine Produktion = eine Charge; `Product::suggestedBatchNumber()` = Präfix + `ttmmjj`.
+- **Produktionsergebnis-Repeater** (`production_outputs`): beliebig viele Zeilen (Produkt, Stückzahl, Chargen-Nr.), Buchung je Output-Produkt idempotent per Differenz-Abgleich. Mehrere Zeilen können dieselbe Chargen-Nr. tragen.
+- Produktbestand (`product_stock_movements`) strikt je `product_id`; AP-13 bucht Verkäufe je Bestellposition (Sets aufgelöst).
+- **Verpackung:** je Produkt eine Stückliste (`product_packagings` → `PackagingItem`), Produktion schreibt einen Verbrauchs-Snapshot (`production_packagings` = Stückliste × produzierte Menge). Verpackungsartikel haben eigenen Bestand über Wareneingänge. In der Live-DB liegen bisher **nur Demo-Verpackungsartikel** — Tiegel/Deckel sind noch nicht als Verpackungsartikel gepflegt.
+
+---
+
+## 3. Die Entscheidungsfrage
+
+Physisch gibt es zwei denkbare Arbeitsweisen — sie führen zu unterschiedlichen Systemmodellen:
+
+| | **(A) Deckel bei Bedarf** (Konfektion/Versand) | **(B) Fertige Tiegel je Farbe im Regal** |
+|---|---|---|
+| Lagerrealität | Tiegel gefüllt, Deckel-Sortiment daneben | getrennte Stapel je Deckelfarbe |
+| Produktbestand | je Produkt (heutiger Stand reicht) | müsste je Produkt **und** Variante zählen |
+| Deckel-Bestand | je Farbe als **Verpackungsartikel** | im Fertigbestand enthalten |
+| Verkaufs-Abzug | je Produkt (AP-13, fertig) | bräuchte Varianten-Info in der Bestellung — existiert nicht; nur näherungsweise über WL-Konfig des Partners ableitbar (Verkauf ausschließlich direkt an Partner, keine API) |
+| Systemaufwand | ~0, optional 2 Kleinpakete | mittel bis groß, neue Dauer-Datenpflege |
+
+Die Anforderungsbeschreibung („eine Charge, die dann unterschiedliche Deckel-Varianten bekommt … nach Bedarf hergestellt") entspricht **(A)**.
+
+---
+
+## 4. Lösungsvarianten
+
+### V1 — Variante bleibt bestandsneutral, Deckel als Verpackungsartikel *(Empfehlung)*
+
+**Kern: kein Umbau.** Die Produktion einer Deocreme-Charge wird wie heute gebucht (ein Ergebnis je Produkt/Größe, gemeinsame Chargen-Nr.). Die Deckelfarbe entsteht erst bei der Konfektion und ist für den Produktbestand unsichtbar — genau wie physisch.
+
+Damit trotzdem niemand „blind" bei den Deckeln ist, zwei kleine, unabhängig beauftragbare Ergänzungen:
+
+1. **OPT-V1a — Deckel je Farbe als Verpackungsartikel führen (reine Datenpflege, kein Code):**
+   Verpackungsartikel „Deckel 50 ml weiß / schwarz / gold / silber" (+ Tiegel) anlegen, Bestand über den normalen Wareneingang. In die Produkt-Stückliste kommt nur, was farbunabhängig ist (Tiegel, Etikett); die farbigen Deckel bleiben **bewusst außerhalb der Stückliste**, weil die Farbe zum Produktionszeitpunkt noch nicht feststeht. Deckel-Verbrauch wird zunächst periodisch nachgetragen (Inventur/Sammelbuchung — der Bewegungs-Dialog existiert).
+   *Aufwand: 0 Entwicklungstage.*
+
+2. **OPT-V1b — Deckelfarbe in der Packliste des Abwicklungs-Boards (kleines AP):**
+   Der Versand-Mitarbeiter sieht heute in der Packliste Menge × Produkt. Ergänzung: bei White-Label-Bestellungen die Tiegel-Variante(n) aus der WL-Konfiguration des Partners anzeigen („Deckel: Gold 40 ml"), damit beim Konfektionieren nicht in der Partner-Akte nachgeschlagen werden muss. Bei Partnern mit mehreren Varianten werden alle angezeigt (Hinweis-Badge).
+   *Aufwand: ~0,5–1 Tag inkl. Test.*
+
+**Vorteile:** entspricht dem physischen Prozess; keine zweite Bestandswahrheit; AP-13/API bleiben unberührt; sofort nutzbar.
+**Grenze:** Der Produktbestand sagt nicht, wie viele fertig konfektionierte Gold-Tiegel existieren — weil es die in Arbeitsweise (A) dauerhaft gar nicht gibt.
+
+### V2 — Varianten-Split am Produktionsergebnis (nur falls Arbeitsweise B)
+
+Falls doch fertig konfektionierte Tiegel je Farbe gelagert und gezählt werden sollen:
+
+- `production_outputs` + `product_stock_movements` um **optionale** `attribute_id` erweitern; der Ergebnis-Repeater bekommt je Zeile ein Varianten-Dropdown (nur sichtbar, wenn das Produkt Tiegel-Varianten hat). Eine Charge → z. B. „60× Deo 50 ml (Weiß), 40× Deo 50 ml (Gold), Charge TP1230726".
+- Produktbestand zeigt unter dem Produkt eine **Aufschlüsselung je Variante**; Kacheln/kritisch-Logik bleiben auf Produktebene.
+- **Strukturproblem Verkaufsseite (durch Kundenergänzung 23.07. entschärft, aber nicht gelöst):** Bestellpositionen tragen keine Variante (§2.2). Da Varianten-Produkte ausschließlich direkt an Vertriebspartner verkauft werden (keine API), ließe sich der Abzug je Farbe aus der WL-Konfiguration des Partners ableiten — bei Partnern mit **mehreren** Varianten bleibt es aber ein Raten bzw. ein „ohne Variante"-Topf. Risiko **zweier Wahrheiten** (Produktsumme stimmt, Variantensplit driftet) — Korrektur per Umbuchungs-Dialog.
+- *Aufwand: 3–5 Tage (Produktion + Bestand + Historie + Umbuchung). Soll der Split exakt sein, käme eine Varianten-Auswahl im internen Bestellweg dazu (Checkout/Warenkorb, überschaubar — Connector/API sind sicher nicht betroffen).* 
+
+### V3 — Jede Deckelfarbe als eigenes Produkt *(nicht empfohlen)*
+
+Volle SKU-Trennung (wie die bestehende Trennung 50 ml vs. 15 ml). Damit wäre alles automatisch exakt — aber: eigene Artikelnummern je Farbe, Änderungen in WL-Konfiguration, Statistiken, Provisionslogik; Datenpflege vervierfacht sich je Produkt (API/Shops wären dank des direkten Vertriebswegs zwar nicht betroffen, das ändert die Bewertung aber nicht). Steht in keinem Verhältnis zu einem Merkmal, das weder Preis noch Inhalt noch Rezeptur ändert.
+
+---
+
+## 5. Empfehlung
+
+1. **V1 jetzt:** Für den Produktionsfall „eine Charge → mehrere Ergebnisse" ist **nichts zu entwickeln** — im Kundentest so kommunizieren und im Testleitfaden (§ Produktion) mit einem Deocreme-Beispiel dokumentieren.
+2. **OPT-V1a** (Deckel als Verpackungsartikel) als Pflege-Empfehlung an den Kunden geben — kostet nichts und schafft Deckel-Transparenz inkl. Nachbestell-Sicht.
+3. **OPT-V1b** (Deckelfarbe in der Packliste) als kleines AP in die Roadmap nach der Testphase aufnehmen (passt zu AP-33-Umfeld).
+4. **V2 nur dann**, wenn der Kunde Frage 1 unten mit „B" beantwortet — vorher nicht bauen.
+
+## 6. Klärungspunkte für den Kunden
+
+1. **Arbeitsweise:** Werden Deckel erst beim Konfektionieren/Versand aufgesetzt (A) — oder lagern fertige Tiegel getrennt je Deckelfarbe (B)? *(entscheidet V1 vs. V2)*
+2. **Deckel-Bestand:** Sollen die Deckel je Farbe als Verpackungsartikel mit Bestand + Mindestbestand geführt werden (OPT-V1a)? Wer pflegt die Wareneingänge?
+3. **Packliste:** Soll die Deckelfarbe des Partners im Abwicklungs-Board angezeigt werden (OPT-V1b)?
+4. **Deocreme-Varianten:** Sollen die Deocreme-Produkte die Tiegel-Varianten im Produktformular zugeordnet bekommen (heute nur bei Tattoocreme & Co. gepflegt)?
+5. **Chargen-Nr.:** Bestätigung der Semantik „eine Chargen-Nr. für alle Ergebnisse derselben Produktion" (heute bereits möglich — Vorbelegung übernimmt Präfix + Datum in jede Ergebnis-Zeile).
--- a/dev/product
+++ b/dev/product
@ -0,0 +1,127 @@
+# Warenwirtschaft — Projektübersicht & Entwicklungsplan
+
+> **Stand:** 26.08.2026
+> **Status:** Modul ist **live** und in der **Kundentestphase** (Dev-Container mit eingespielter Live-Datenbank inkl. Testdaten).
+> **Testsuite:** 303 Tests grün (1130 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
+Detaildokumente. Die maßgebliche, aktuellste Aufwands-/Leistungssicht ist die
+[Leistungsübersicht 23.07.2026](03-status-und-vorschlaege/leistungsuebersicht-warenwirtschaft-23-07-2026.md).
+
+---
+
+## Ordnerstruktur
+
+| Ordner | Inhalt |
+|---|---|
+| [`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 `…06-07-2026.md` (V6.0) |
+| [`02-audit/`](02-audit/) | Qualitäts- & Sicherheits-Audit vom 15.07.2026 |
+| [`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 |
+
+> Hinweis: Der Ordnername `product management ` trägt ein **abschließendes Leerzeichen**.
+> Das ist fehleranfällig (Shell/Tooling). Empfehlung: bei Gelegenheit in
+> `product-management` umbenennen — nicht ohne Rücksprache erledigt, da evtl.
+> externe Verweise darauf zeigen.
+
+---
+
+## Was das Modul kann (Ist-Stand, live)
+
+Eine vollständige Warenwirtschaft im Admin-Bereich des Partnercenters:
+
+- **Stammdaten:** Lieferanten (Bestellweg, Lieferzeit, Land-Default DE), Rohstoffe/INCI
+  (Mehrfach-Lieferanten inkl. URL, Qualität, Alternativname, Lagerort Raum/Regal/Fach),
+  Verpackungsartikel, Set-Produkte, konfigurierbare Einstellungen (USt-Sätze,
+  Lieferzeit-Vorlagen, Ausschuss-Gründe).
+- **Einkauf & Wareneingang:** Bestellungen mit Netto/Brutto-Automatik & Duplizieren,
+  Chargen-/MHD-Erfassung, Zusammenführen gleicher Chargen (FEFO).
+- **Produktion:** Rezeptur auf Hersteller-Basis mit **Phasen** (Drag & Drop), Chargen-Nr.
+  mit Präfix + Auto-Generierung (`TP1` + `ttmmjj`), neue Produktionsmaske mit
+  **Produktionsergebnis-Repeater** (mehrere Ergebnis-Produkte je Charge, FEFO-Chargenwahl).
+- **Bestände:** Rohstoffbestand (Restmengen je Charge, Verbrauchsprognose, Kritisch-Warnungen),
+  Produktbestand (revisionssichere Historie, manuelle Buchungen, Dringlichkeits-Sortierung,
+  Kacheln), Ausschuss-Erfassung.
+- **Shop-Anbindung (API):** automatischer **Bestandsabzug beim Versand** inkl. Set-Auflösung
+  und Storno-Rückbuchung, Protokoll-Seite „API-Bestellungen", Stichtags-Schutz für Altbestellungen.
+- **Abwicklung:** iPad-optimiertes **Fulfillment-Board** „Bestellungen" mit Versand-Sperre,
+  Sammel-PDF (Lieferscheine/Rechnungen einer Auswahl als ein Dokument).
+- **DHL-Versand (Brückenlösung):** Label wird im WooCommerce-Shop erzeugt und per
+  Connector 1.5.0 (Base64) ins Partnercenter übernommen; Anzeige von Label-Download +
+  Sendungsnummer. Details: [AP-32-Brückenlösung](03-status-und-vorschlaege/ap-32-brueckenloesung-connector-update.md).
+
+---
+
+## Erledigte Arbeitspakete
+
+Alle folgenden APs sind umgesetzt, committet und durch die Testsuite abgedeckt:
+
+- **AP-00–AP-12, AP-18, AP-19** — V4.0-Basis: Bugfixes, Stammdaten, Einkauf, Produktion,
+  Bestände, Ausschuss, WaWi-UI, integrierte Doku.
+- **AP-20** Rohstoffbestand-Filter + „Kein Rohstoffbestand"-Flag (Default „nur Rezeptur").
+- **AP-21** INCI-Erweiterungen (Lieferanten-Repeater + URL, Alternativname, Lagerort-CRUDs).
+- **AP-22** Produktbestand-Erweiterungen (Sortierung, Kacheln, Verbrauch/Monat).
+- **AP-23** Rezeptur-Phasen (Drag & Drop).
+- **AP-24** Chargen-Nr.-Präfix mit Auto-Generierung.
+- **AP-25** Lieferbestand „Wieder lieferbar ab"-Datum.
+- **AP-26** Ausschuss-Gründe konfigurierbar.
+- **AP-27** Wareneingang: Charge zusammenführen (FEFO).
+- **AP-28** Neue Produktions-Maske + Produktionsergebnis.
+- **AP-31** Löschen: Soft-Delete + Abhängigkeitsprüfung (`DeletionGuard`).
+- **AP-13** Shop-Bestandsabzug bei Versand (Sets, Gegenbuchungen, Stichtags-Schutz) + API-Protokoll.
+- **AP-33a/b** Fulfillment-Board + Sammel-Dokumente.
+- **OPT-1–OPT-4** Code-Optimierungen (N+1-Fix, Settings-CRUD-Basisklasse, Pagination, `show()`-Refactoring).
+- **OPT-6–OPT-9** Behebung aller Audit-Befunde (siehe unten).
+
+### Audit 15.07.2026 — vollständig abgearbeitet
+5 hohe, 10 mittlere, 16 niedrige Befunde; alle behoben oder per Kundenentscheid gelöst.
+Kern-Fixes: Ausschuss in Chargen-Restmengen (H-1), Härtung gegen Doppel-/Negativbuchungen
+(H-2/H-3), transaktionssicherer Rezeptur-Neuaufbau inkl. Phasen (H-4/H-5), CSRF-/AuthZ-Härtung
+(M-2/3/6/7/10). Audit bestätigte: solide Architektur, kein SQLi/XSS, kein falscher Plan-Status.
+Details: [Audit-Bericht](02-audit/audit-bericht-15-07-2026.md).
+
+### Review vor Live-Release (20.07.2026) — abgefangene Risiken
+- Stichtags-Schutz auf unveränderliches Flag `sale_stock_exempt` umgestellt (verhinderte
+  rückwirkenden Abzug bei Storno+Wiederversand von Altbestellungen).
+- Auto-Storno im Mahnwesen über zentralen `OrderStatusService::setShipped()` geführt
+  (verhinderte zahlbare Provision auf versendete, nie bezahlte Bestellung).
+- AP-32-Brücke auf Base64/Connector 1.5.0 gehärtet (kein 403/SSRF/Timeout mehr).
+
+---
+
+## Offene / nachgelagerte Pakete (nach Kundentestphase)
+
+Kundenentscheid 16.07.2026: erst nach der Testphase. Grober Restaufwand **ca. 28–42 PT**.
+
+| Paket | Inhalt | Schätzung | Abhängigkeit |
+|---|---|---|---|
+| **AP-32 (voll)** | DHL-Etiketten direkt im System per API erstellen | 3–5 PT | Braucht Kundenklärung: DHL-Geschäftskundenkonto (EKP), Versandprodukte, Paketmaße/-gewichte, Druck-Setup, Retouren-/Zolllabel (CH als Drittland) |
+| **AP-33c** | Etiketten-Stapeldruck + Automatik-Option | 1 PT | mit AP-32 |
+| **AP-14** | Audit-Trail (lückenlose Änderungshistorie) | 2–3 PT | — |
+| **AP-16** | 2-Faktor-Authentifizierung für Admins | 2–3 PT | sinnvoll vor AP-15 |
+| **AP-15** | Blockbasierte Rechte (sehen/bearbeiten je Bereich) | 4–6 PT | nach AP-16 |
+| **AP-17** | Zentrale WaWi-Einstellungsseite | 1–2 PT | — |
+
+**Entfällt:** OPT-5 (Horizont-Filter serverseitig) — clientseitig ausreichend (Kundenentscheid 06.07.).
+
+### Neue Anforderung in Klärung — Deckel-Varianten (White Label)
+Deocreme & Co.: eine Charge, danach unterschiedliche Deckel-Farben nach Bedarf. Analyse ergab:
+Chargen-Szenario ist bereits abgedeckt (AP-28). **Empfehlung V1** (kein Umbau) — nur zwei kleine
+optionale Ergänzungen: Deckel als Verpackungsartikel führen (OPT-V1a, 0 Entwicklungstage) und
+Deckelfarbe in der Packliste des Boards anzeigen (OPT-V1b, ~0,5–1 Tag). Varianten-Bestand je
+Farbe (V2, 3–5 PT) nur, falls fertig konfektionierte Tiegel je Farbe gezählt werden sollen.
+Offene Kundenfragen im Dokument. Details:
+[Vorschlag Deckel-Varianten](03-status-und-vorschlaege/vorschlag-deckel-varianten-produktion-23-07-2026.md).
+
+---
+
+## Bekannte, bewusst akzeptierte Grenzen
+
+- **Parallelität** ist per Pest nicht testbar; abgesichert über `lockForUpdate()` + Review
+  (geringes Risiko im Ein-Personen-Admin-Betrieb).
+- **Self-Shipping** durch Partner erzeugt bewusst keinen Bestandsabzug (Partner versendet aus eigenem Lager).
+- Board-gesetzte Versandstatus dürfen nicht von der Detailseiten-Automatik überschrieben werden
+  (Sperr-Flag `shipped_status_locked`) — in der Hinweise-Doku hinterlegt.
+- Bestellpositionen tragen keine Attribut-/Varianten-Dimension (relevant nur für Deckel-Varianten V2).