Kundenfeedback aus der Testphase am Code + Live-DB verifiziert und in einen Umsetzungsplan überführt (AP-34…AP-51, ~15–26 PT): 9 bestätigte Bugs (u. a. Varianten-Artikelnummer, Produktionsmengen 100 g statt Füllmenge, leere Rezepturphasen, „Enthalten in"-Doppelung) plus Erweiterungen. WooCommerce-Ampel ist voraussichtlich shopseitig (Status-Cron/Auth), kein ERP-Fehler. Sechs Klärungspunkte (D-1…D-6) offen. Noch nichts umgesetzt. Rohfeedback des Kunden liegt als entwicklungsplan-aktualisiert-2026-08-26.md bei. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
8.2 KiB
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.
Ordnerstruktur
| Ordner | Inhalt |
|---|---|
00-konzept/ |
Ausgangs-Briefings, Fachkonzept, frühes Feedback (März–April 2026) |
01-entwicklungsplaene/ |
Versionierte Entwicklungspläne — maßgeblich ist die neueste Fassung …06-07-2026.md (V6.0) |
02-audit/ |
Qualitäts- & Sicherheits-Audit vom 15.07.2026 |
03-status-und-vorschlaege/ |
Aktuelle Leistungsübersicht, AP-32-Brückenlösung, Vorschlag Deckel-Varianten |
screens/ |
Screenshots / Mockups zu Beständen, Rezeptur-Phasen, Produktion |
Hinweis: Der Ordnername
product managementträgt ein abschließendes Leerzeichen. Das ist fehleranfällig (Shell/Tooling). Empfehlung: bei Gelegenheit inproduct-managementumbenennen — 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.
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.
Review vor Live-Release (20.07.2026) — abgefangene Risiken
- Stichtags-Schutz auf unveränderliches Flag
sale_stock_exemptumgestellt (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).
Testphasen-Feedback 26.08.2026 → Plan V7.0
Aus der laufenden Testphase kam eine neue Feedback-/Bug-Runde. Alle Punkte sind am Code und an der Live-DB verifiziert und in einen Umsetzungsplan überführt: Entwicklungsplan V7.0 (9 bestätigte Bugs + Erweiterungen, ca. 15–26 PT, AP-34…AP-51). Wichtig: die WooCommerce-Ampel ist voraussichtlich kein Partnercenter-Fehler, sondern shopseitig (Status-Cron/Auth). Rohfassung des Feedbacks: entwicklungsplan-aktualisiert-2026-08-26.md. Offene Klärungspunkte (D-1…D-6) im Plan blockieren den Start einzelner Pakete.
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.
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).