Warenwirtschaft: AP-32 (Versand mit DHL-Etiketten per API) neu aufgenommen

Kundenanforderung 15.07.: Versand komplett im System inkl. Label-Erstellung
ueber die DHL Parcel DE Shipping API. Gleicher Andockpunkt wie AP-13
(Versand-Statuswechsel). AP-13-Ansatz vom Kunden bestaetigt.
Klaerungspunkte (DHL-Konto, Versandprodukte, CH-Zoll, Druck-Setup) notiert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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:<supplier>:<lot>`, 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.