Kevin Adametz
d93c676b6b
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>
138 lines
8.2 KiB
Markdown
138 lines
8.2 KiB
Markdown
# 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).
|
||
|
||
---
|
||
|
||
## 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](01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md)**
|
||
(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](01-entwicklungsplaene/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](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).
|