gitmedia/gruene-seele
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Warenwirtschaft: Plan V7.0 — AP-34 Shop-Duplikat-Konvention dokumentiert

Browse source 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Kevin Adametz 2026-08-28 11:54:12 +00:00
parent f42e5a8fd4
commit c7ddf7906e
1 changed files with 5 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

6
dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md
View file

@ -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. > **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.
--- ---