From 6051aa6ea140f0b7d9471bafe8cc1bdbaf5706f0 Mon Sep 17 00:00:00 2001 From: Kevin Adametz Date: Thu, 16 Jul 2026 12:12:23 +0000 Subject: [PATCH] =?UTF-8?q?Warenwirtschaft:=20Doku=20=E2=80=94=20Liefersch?= =?UTF-8?q?ein-Fix=20in=20Hinweisen=20und=20Plan-Protokoll?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5 --- .../entwicklungsplan-aktualisiert-06-07-2026.md | 1 + resources/docs/hinweise.md | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md b/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md index 1660e2b..2d2688c 100644 --- a/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md +++ b/dev/product management /entwicklungsplan-aktualisiert-06-07-2026.md @@ -269,6 +269,7 @@ Der Warenkorb kommt also **per Knopfdruck** (Fulfillment-Übergabe), nicht autom | 16.07.2026 | **AP-33a (Bestell-Abwicklung: Nav „Bestellungen" + Fulfillment-Board)** | Neuer Sidenav-Punkt **„Bestellungen"** (copyreader) mit Unterpunkten **Abwicklung** (neu) und **API-Bestellungen** (umgezogen). Board `admin/inventory/orders` (`OrderFulfillmentController`): 4 Filter-Kacheln (heute eingegangen / zu konfektionieren / versandfertig / heute versendet), je Bestellung Packliste aufklappbar (Sets mit Komponenten), Gewicht, Zahlstatus-Pill, Quelle-Badge (API/Shop/Promo), Suche. **Versandfertig-Regel** (Kundenentscheid): `ShoppingOrder::isReadyToShip()` — Rechnung (fnc) sofort, Vorkasse (vor) erst bei `paid`, API (`extern`) immer, `non`/`failed` nie. **Dokumente:** Erstellen (Rechnung + Lieferschein, ohne Mailversand) über bestehendes `InvoiceRepository::create()`; Downloads (einzeln/kombiniert via `PDFMerger`) über eigene copyreader-Routen, da `storage_file` admin ≥ 7 verlangt; **API-Bestellungen bekommen keine Rechnung** — externer Link (`wp_invoice_path`). **Statuswechsel:** Logik aus `SalesController::store()` in neuen **`OrderStatusService::setShipped()`** extrahiert (Transaktion, Lock, Margin-/Promotion-Folgen, AP-13-Abzug) — Verkäufe-Modal und Board nutzen dieselbe Implementierung; Board nur vorwärts (1/2), nur aus Status 0/1. **Sperr-Flag** `shopping_orders.shipped_status_locked` (Migration `2026_07_16_130000`, Kundenentscheid Punkt 3): vom Board gesetzte Status werden vom Auto-Wechsel der Detailseiten (offen → in Bearbeitung, 3 Stellen) nicht mehr überschrieben. Commit `a367d85`. | Neuer `OrderFulfillmentTest` (10 grün: Render/Packliste, Rechte, Versandfertig-Regel, Statuswechsel + Lock + Bestandsabzug, nur-vorwärts, Alt-Status unangetastet, Detailseiten-Sperre, Dokumente ohne Mail, API ohne Rechnung). Volle Suite: **268 grün, 987 Assertions** | | 16.07.2026 | **AP-13-Nachtrag: Stichtags-Schutz für Alt-Bestellungen** | Beim Blick auf Bestellung 1687 (versendet 12/2025) entdeckt: erneutes Speichern des Versandstatus einer **vor AP-13 versendeten** Bestellung hätte rückwirkend vom heutigen Bestand abgezogen. `syncSaleStock()` überspringt jetzt Bestellungen mit `shipped_at` vor dem Stichtag `ProductStockService::SALE_STOCK_SINCE` (16.07.2026). Kundenentscheid dokumentiert: Self-Shipping ohne Abzug bestätigt. | `SaleStockDeductionTest` +1 (11 grün). Suite: **258 grün, 944 Assertions** | | 16.07.2026 | **AP-13 (API-Bestellungen — Protokoll + SKU-Fehlermarkierung, Kundenanforderung 16.07.)** | Neue Tabelle **`api_order_logs`** (Migration `2026_07_16_090000`) + Model `ApiOrderLog`; `ShoppingUserController` protokolliert **jede** `wp/order`-Übertragung — erfolgreiche inkl. Zuordnungsergebnis je Position (SKU, Produkt, Menge, Preis, API-Meldungen), abgelehnte mit Grund (Kunde unbekannt, Bestellung existiert bereits, Speicherfehler). Positionen ohne Produktzuordnung ⇒ `has_errors` + Zusammenfassung („x von y Positionen ohne Produktzuordnung"). **Neuer Menüpunkt „API-Bestellungen"** (copyreader, `admin/inventory/api-orders`): Liste (Limit 500/`?all=1`, Filter „nur Fehler"), rote Markierung, **Modal „Ansehen"** mit Positionstabelle (Meldungen deutsch übersetzt, Roh-Payload bei abgelehnten). Dazu SKU-Konsistenz (Plan §4 „mitzulösen"): Warnkarte **doppelte WP-Nummern** aktiver Produkte, aufklappbare Liste **aktive Produkte ohne WP-Nummer**. Commit `71d5591`. | Neuer `ApiOrderLogTest` (8 grün, Ende-zu-Ende über `wp/order` mit `Passport::actingAs`). Suite: **257 grün, 940 Assertions** | +| 16.07.2026 | **Bugfix Logistik-Mail (Kundenmeldung)** | Fehlversand an die Rechnungsadresse: die Versand-Mail (`MailLogistic`) hängte den **Lieferschein nur bei White-Label-Bestellungen** an. Jetzt wird er **immer** mitgesendet (unabhängig von Logo/White-Label); fehlt die PDF-Datei auf der Platte, wird sie mit bestehender Rechnungsnummer regeneriert. Dazu **tote Duplikat-Klasse `app/Mail/MailLogitic.php` entfernt** (Tippfehler-Dateiname, definierte `MailLogistic` in einer Altversion ohne Lieferschein-Anhang — Kollisionsrisiko im Classmap-Autoload). Commit `7d77314`. | Neuer `LogisticMailTest` (3 grün: Anhang ohne White-Label, Regeneration fehlender Datei, Versand-Button). Volle Suite: **275 grün, 1012 Assertions** | | _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 | – | diff --git a/resources/docs/hinweise.md b/resources/docs/hinweise.md index a216568..29b425e 100644 --- a/resources/docs/hinweise.md +++ b/resources/docs/hinweise.md @@ -184,6 +184,12 @@ selbst versenden, übertragen keinen Warenkorb ins Partnercenter und erzeugen bewusst keinen Bestandsabzug – der Partner versendet aus eigenem Bestand (Kundenentscheid 16.07.2026: bestätigt). +- **Versand-Mail enthält immer den Lieferschein (Fix 16.07.2026):** Die + Logistik-Mail („Rechnung/Lieferschein an den Versand") hängt jetzt **immer** + Rechnung **und** Lieferschein an — unabhängig davon, ob die Bestellung + White-Label-/Logo-Produkte enthält. Vorher fehlte der Lieferschein bei + Bestellungen ohne eigenes Etikett, was zu Fehlversänden an die + Rechnungsadresse führen konnte. - **Status-Vorrang der Warenwirtschaft (Kundenentscheid 16.07.2026 — wichtig):** Das Öffnen einer Bestell-Detailseite setzt eine offene Bestellung bislang automatisch auf „in Bearbeitung". **Sobald der Status einmal über die