diff --git a/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md b/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md index 5e7341d..5405796 100644 --- a/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md +++ b/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md @@ -39,6 +39,7 @@ V6.0 basiert auf einer **vollständigen Code-Verifikation vom 06.07.2026** (alle | AP-27 | Wareneingang: Charge zusammenführen | ✅ fertig 06.07.2026 (`7a5b5e0`) | Batch-Check-Endpoint + Vorbelegung, Chargen-Gruppierung Detail/Produktion, FEFO-`expandBatchLines()`, `StockEntryChargeMergeTest` (7 grün) | | AP-28 | Neue Produktions-Maske + Produktionsergebnis | ✅ fertig 06.07.2026 (`99a6c92`) | `production_outputs` + Backfill (Migration `2026_07_06_153907`), Buchung je Output-Produkt, Phasen-Maske + INCI-Liste + Ergebnis-Repeater, `ProductionOutputTest` (8 grün) | | AP-13 | Shop-Bestandsabzug bei Versand (inkl. Sets) | ⏸ **nachgelagert** (Kundenentscheid 06.07.2026: weitere Anforderungen werden erst geprüft) | Konzept liegt vor (V4.0); `monthlyConsumptionByProduct()` und `production_outputs`-Buchung sind vorbereitet | +| AP-32 | Versand im System: DHL-Etiketten per API | 🆕 **neu aufgenommen 15.07.2026** (Kundenanforderung) | Umsetzungsansatz in §4; Andockpunkt = Versand-Statuswechsel (wie AP-13) | | AP-14 | Audit-Trail | ⏸ nachgelagert | kein Package, keine Spur | | AP-15 | Blockbasierte Rechte | ⏸ nachgelagert | nur `isAdmin()`-Stufen | | AP-16 | 2FA (Google Authenticator) | ⏸ nachgelagert | kein TOTP-Package in composer.json | @@ -108,11 +109,12 @@ Alle Punkte dieser älteren Runde sind in V4.0 eingeflossen und umgesetzt (URL-F | 7 | ✅ OPT-3 + OPT-4 | Pagination + show()-Refactoring — **erledigt 06.07.2026** | – | 1,5–2,5 Tage | | 8 | ✅ AP-27 | Wareneingang: Chargen-Merge — **erledigt 06.07.2026** | OPT-4 | 1–2 Tage | | 9 | ✅ AP-28 | Neue Produktions-Maske + Produktionsergebnis — **erledigt 06.07.2026** | AP-21, AP-23, AP-24, AP-27 | 5–8 Tage | -| 10 | ⏸ AP-13 | Shop-Bestandsabzug bei Versand (inkl. Sets; Konzept aus V4.0) — **nachgelagert** | AP-28 (saubere Buchungslogik) ✅ | 3–5 Tage | -| 11 | ⏸ AP-14 | Audit-Trail — nachgelagert | – | 2–3 Tage | -| 12 | ⏸ AP-16 | 2FA für Admins (Google Authenticator) — nachgelagert | – | 2–3 Tage | -| 13 | ⏸ AP-15 | Blockbasierte Rechte (sehen/bearbeiten je Block) — nachgelagert | AP-16 sinnvoll davor | 4–6 Tage | -| 14 | ⏸ AP-17 | WaWi-Einstellungsseite (Schwellwerte, Fenster, Defaults) — nachgelagert | – | 1–2 Tage | +| 10 | ⏸ AP-13 | Shop-Bestandsabzug bei Versand (inkl. Sets; Umsetzungsansatz §4, 15.07.2026) — **nachgelagert** | AP-28 (saubere Buchungslogik) ✅ | 3–5 Tage | +| 11 | 🆕 AP-32 | Versand im System: DHL-Etiketten per API (Kundenanforderung 15.07.2026, Ansatz §4) | AP-13 sinnvoll davor/gemeinsam (gleicher Andockpunkt) | 3–5 Tage | +| 12 | ⏸ AP-14 | Audit-Trail — nachgelagert | – | 2–3 Tage | +| 13 | ⏸ AP-16 | 2FA für Admins (Google Authenticator) — nachgelagert | – | 2–3 Tage | +| 14 | ⏸ AP-15 | Blockbasierte Rechte (sehen/bearbeiten je Block) — nachgelagert | AP-16 sinnvoll davor | 4–6 Tage | +| 15 | ⏸ AP-17 | WaWi-Einstellungsseite (Schwellwerte, Fenster, Defaults) — nachgelagert | – | 1–2 Tage | > **Blockabschluss 06.07.2026:** Positionen 1–9 (OPT-1/2/3/4 + AP-21/20/23/24/27/28) sind vollständig umgesetzt und einzeln committet. Die Positionen 10–14 sind auf Kundenwunsch **nachgelagert** — vor der Umsetzung prüft der Kunde weitere Anforderungen, die dort mit einfließen sollen. @@ -153,6 +155,29 @@ Der Warenkorb kommt also **per Knopfdruck** (Fulfillment-Übergabe), nicht autom 4. **Bewusste Lücke (fachlich korrekt):** Self-Shipping-Bestellungen der Partner übertragen keinen Warenkorb und erzeugen keinen Abzug — der Partner versendet aus eigenem Bestand, das Partnercenter-Lager wird nicht berührt. **Mit dem Kunden bestätigen.** 5. **Mitzulösen:** (a) unbekannte SKUs sichtbar machen — heute geht „article not found" nur in der API-Antwort unter, die Position fehlt dann still in Bestellung und Abzug; (b) `wp_number`-Konsistenzprüfung (aktive Produkte ohne/mit doppelter SKU). +> ✅ **Kundenentscheid 15.07.2026:** Ansatz bestätigt — so umsetzen. + +### AP-32 — Versand im System: DHL-Etiketten per API (neu aufgenommen 15.07.2026) + +**Kundenanforderung 15.07.2026:** Der Versand soll vollständig im Partnercenter abgewickelt werden — nicht nur der Statuswechsel per Button, sondern am Ende auch die **Erstellung der Versandetiketten über die DHL-API**. + +**Zielbild:** Aus der Bestellansicht heraus wird das DHL-Label per API erzeugt (PDF zum Druck), die **Sendungsnummer an der Bestellung gespeichert** und der Status auf „versendet" gesetzt — dieser Statuswechsel ist derselbe Andockpunkt wie der AP-13-Bestandsabzug, beides greift dann in einem Schritt. Perspektivisch kann die Sendungsnummer über den bestehenden `wp/status`-Poll auch an WooCommerce zurückgegeben werden (Tracking-Link für den Endkunden; kleines Plugin-Update, optional). + +**Technische Eckpunkte:** +- **DHL „Parcel DE Shipping" API (REST, v2)** — Nachfolger der SOAP-Geschäftskundenversand-API; benötigt ein DHL-Geschäftskundenkonto (Geschäftskundenportal), API-Key über das DHL-Entwicklerportal, Sandbox vorhanden. Label anlegen + stornieren, PDF in gängigen Druckformaten. +- **Datenlage im System ist gut:** Lieferadresse (`ShoppingUser`/`ShoppingOrder`), Gewicht je Bestellung (`shopping_orders.weight`, wird beim Checkout aus den Produktgewichten berechnet) und Länderkennung sind vorhanden. +- **Neue Felder an `shopping_orders`:** Sendungsnummer, Label-Referenz/Storno-Referenz, Versandprodukt; Label-PDF als Download/Druck aus der Bestellansicht. +- **Länder:** DE/FR/NL sind EU-Standard; **CH ist Drittland** → Zolldaten (Inhaltsangaben, Warenwert, ggf. CN23) müssen mit übergeben werden — eigener Fall in der Umsetzung. + +**Vor Umsetzung mit dem Kunden zu klären (nächste Anforderungsrunde):** +1. DHL-Geschäftskundenkonto vorhanden? (EKP-Nummer + Abrechnungsnummern je Versandprodukt) +2. Welche Versandprodukte? (DHL Paket, Warenpost/Kleinpaket; national/international) +3. Standard-Paketmaße/-gewichte oder je Bestellung manuell? +4. Druck-Setup (Format A4 vs. Etikettendrucker 910-300-700) +5. Retourenlabel mit erzeugen? (separates DHL-Produkt „Retoure") + +**Aufwand:** 3–5 Tage (ohne Retourenlabel). **Reihenfolge:** direkt nach oder gemeinsam mit AP-13 — gleicher Andockpunkt am Versand-Statuswechsel, gemeinsamer Test-Aufbau. + ### Geklärte Punkte mit dem Kunden (beantwortet 06.07.2026) 1. **Lagerort-Modell (AP-21):** ✅ **drei getrennte Stammdaten-Tabellen** (Raum/Regal/Fach) — wie empfohlen. 2. **Chargen-Nr.-Datumsformat (AP-24):** ✅ `TP1` + `ddmmyy` bestätigt (Beispiel TP1150626 = 15.06.26). **Bei AP-24-Umsetzung in der Hinweise-Doku (AP-18) hinterlegen.** @@ -192,8 +217,9 @@ Der Warenkorb kommt also **per Knopfdruck** (Fulfillment-Übergabe), nicht autom | 15.07.2026 | **Audit-Niedrigbefunde** | N-2/3/4/5/7/8/9/15 (Preis nur aus Eingängen, exaktes Verbrauchsfenster, einheitliche Kritisch-Zählung, Limit-Hinweis Ausschussliste, konsistentes Zahlenparsing, Kopie ohne Alt-Chargen-Nr., withTrashed-Korrekturen, Markdown-html_input=strip). Bewusst offen: N-1/6/10/13 (Design-/Kundenentscheid). Commit `d34f0a7`. | Volle Suite: **231 grün, 823 Assertions** | | 15.07.2026 | **N-1/N-6/N-10 (Kundenentscheide)** | **N-1:** Chargen-Gruppierung je Lieferant (`batchGroupKey` = `b::`, Batch-Check prüft Lieferant) — Kundenentscheid: Lot-Nummern kommen von extern und können kollidieren (`9b6c9de`). **N-6:** WaWi-Eingaben lesen einen einzelnen Punkt mit 1–2 Nachkommastellen als Dezimaltrenner („5.1" = 5,1; „1.500" = 1500) — neuer Helper `reFormatWawiNumber()` + JS-Parser vereinheitlicht (`016e8bb`). **N-10:** Bewegungs-Modal zeigt aktuellen Bestand + Bestätigung bei Minus-Buchung (`6af6760`). | +2 Tests. Volle Suite: **233 grün, 832 Assertions** | | _offen_ | AP-13 | Shop-Bestandsabzug — **Umsetzungsansatz dokumentiert (§4, 15.07.2026):** Hook am Versand-Statuswechsel, kein Plugin-Update nötig; WooCommerce-Plugin als Referenz eingecheckt (`592b03a`) | – | +| _offen_ | AP-32 | Versand im System: DHL-Etiketten per API — **neu aufgenommen + Ansatz dokumentiert (§4, 15.07.2026)**; Klärungspunkte (DHL-Konto, Versandprodukte, Druck-Setup) für nächste Anforderungsrunde notiert | – | | _offen_ | AP-14/15/16/17 | Audit-Trail, Blockrechte, 2FA, WaWi-Einstellungen | – | > **✅ BLOCK ABGESCHLOSSEN (06.07.2026).** Alle fachlichen Pakete der Anforderungsrunde vom 12.06.2026 sind umgesetzt (OPT-1 … OPT-4, AP-20/21/23/24/27/28); die Quelldateien `docs/nächsten Anforderungen an die WaWi.md` und `docs/Todos.md` sind vollständig eingearbeitet. Suite: 201 Tests grün, 731 Assertions. > -> **Nachgelagert (auf Kundenwunsch, neue Anforderungen werden vorher geprüft):** AP-13 (Shop-Bestandsabzug bei Versand, inkl. Sets — Konzept in V4.0, Buchung gegen `production_outputs`-Bestände, Abgang `source='sale'`, Sets auflösen, Stornos/Retouren als Gegenbuchung; `monthlyConsumptionByProduct()` berücksichtigt `source='sale'` bereits automatisch), danach AP-14 (Audit-Trail) → AP-16 (2FA) → AP-15 (Blockrechte) → AP-17 (WaWi-Einstellungen). **Wiedereinstieg:** neue Anforderungen des Kunden mit diesem Plan abgleichen und als V6.1/V7.0 fortschreiben. +> **Nachgelagert (auf Kundenwunsch, neue Anforderungen werden vorher geprüft):** AP-13 (Shop-Bestandsabzug bei Versand, inkl. Sets — Umsetzungsansatz §4, bestätigt 15.07.2026: Hook am Versand-Statuswechsel, Abgang `source='sale'`, Sets auflösen, Stornos als Gegenbuchung; kein Plugin-Update nötig) → AP-32 (DHL-Etiketten per API, neu 15.07.2026 — gleicher Andockpunkt, Klärungspunkte in §4), danach AP-14 (Audit-Trail) → AP-16 (2FA) → AP-15 (Blockrechte) → AP-17 (WaWi-Einstellungen). **Wiedereinstieg:** neue Anforderungen des Kunden mit diesem Plan abgleichen und als V6.1/V7.0 fortschreiben.