From c7ddf7906eb454040fa2cf6d98fb8a2c80d4ea1b Mon Sep 17 00:00:00 2001 From: Kevin Adametz Date: Fri, 28 Aug 2026 11:54:12 +0000 Subject: [PATCH] =?UTF-8?q?Warenwirtschaft:=20Plan=20V7.0=20=E2=80=94=20AP?= =?UTF-8?q?-34=20Shop-Duplikat-Konvention=20dokumentiert?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- .../01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md b/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md index 359fef1..88ebb55 100644 --- a/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md +++ b/dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md @@ -38,7 +38,11 @@ Suite: **338 grün**. Erledigt: **AP-34…AP-51 vollständig** (AP-34/35/36/37/3 > **Rollout-Hinweis AP-34:** Der ERP-Teil ist live-fähig (matcht die volle Variations-SKU gegen `wp_number`, „-"-Split nur noch Fallback). Der Shop zeigt die korrekte Zuordnung aber erst, wenn das **Connector-Plugin v1.6.0** (`dev/partnercenter-api/`, sendet ab jetzt die Variations-SKU statt der Eltern-SKU) im WooCommerce-Shop installiert ist. **Vorbedingung:** jede Variation braucht im Shop eine gepflegte eigene Artikel-Nr. (SKU) = die `wp_number` des jeweiligen ERP-Produkts. -> **Modell-Bestätigung AP-34 (28.08.2026, mit Kunde geklärt):** Jede Größe/Variante ist im Shop **ein eigenes Produkt mit eigener Artikelnummer**, und der **Bestand wird je Variante getrennt** geführt (50 ml und 5 ml haben eigenen Bestand). Es gibt **kein** Zusammenfassen mehrerer Varianten auf ein „Basisprodukt A" — das wäre nur bei physisch identischen Varianten korrekt und würde bei verschiedenen Größen den Bestand verfälschen. Die umgesetzte Logik (jede Variante bucht ihr eigenes ERP-Produkt über die volle Artikelnummer) entspricht damit exakt dem Kundenmodell; **keine Code-Änderung nötig**. Kontrolle im Betrieb über die Übersicht „API-Bestellungen" (Protokoll „article not found" + Warnungen doppelte/fehlende WP-Nummern). +> **Modell-Bestätigung AP-34 (28.08.2026, mit Kunde geklärt):** Es gibt **zwei bewusst unterschiedene Fälle**: +> 1. **Physisch verschiedene Produkte** (50 ml vs. 5 ml, mit/ohne Natron) = im Shop **eigene Produkte mit eigener Artikelnummer**, im ERP eigene `wp_number`, **Bestand je Variante getrennt**. Kein Zusammenfassen auf ein „Basisprodukt" (würde bei verschiedenen Größen den Bestand verfälschen). Zuordnung über die **volle** Artikelnummer. +> 2. **Shop-Duplikate desselben Produkts:** Kopiert ein Anwender ein Produkt für eine Aktion / ein neues Bild, verlangt WooCommerce eine eindeutige SKU → Konvention **Kernnummer + Suffix** (`100500`, `100500-a`, `100500-b`). Derselbe physische Artikel ⇒ muss auf die **Kernnummer** gebucht werden. Genau dafür der **`-`-Split** (greift, wenn die volle SKU selbst kein eigenes Produkt trifft). +> +> Weil `products.wp_number` eine **Integer-Spalte** ist, kann eine echte Artikelnummer **nie** einen „-" enthalten — SKUs mit „-" fallen also immer sauber auf die Kernnummer zurück, eigenständige Nummern treffen ihr eigenes Produkt. Beide Fälle sind durch die Reihenfolge (volle SKU zuerst, dann Kernnummer-Split) korrekt abgedeckt; **keine Code-Änderung nötig** (nur Kommentare/Test klargestellt, Commit `f42e5a8`). Kontrolle im Betrieb über die Übersicht „API-Bestellungen" (Protokoll „article not found" + Warnungen doppelte/fehlende WP-Nummern). Hinweis: eine Aktions-Kopie mit **abweichendem Preis** wird trotzdem korrekt auf das Kern-Produkt gebucht, erhält im Protokoll nur einen informativen „different price"-Vermerk. ---