From f42e5a8fd47d37b1bc15f1de2ce5efa373b2212a Mon Sep 17 00:00:00 2001 From: Kevin Adametz Date: Fri, 28 Aug 2026 11:53:34 +0000 Subject: [PATCH] =?UTF-8?q?Warenwirtschaft:=20AP-34=20=E2=80=94=20?= =?UTF-8?q?=E2=80=9E-Suffix"-Schema=20als=20gewollten=20Mechanismus=20doku?= =?UTF-8?q?mentieren?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Kunde hat den eigentlichen Varianten-Fall präzisiert (28.08.): 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, der auf die Kernnummer gebucht werden muss. Der bestehende Importer macht das bereits korrekt (volle SKU zuerst, sonst „-"-Split auf die Kernnummer). Da wp_number eine Integer-Spalte ist, kann keine echte Artikelnummer einen „-" enthalten — dashed SKUs fallen also immer sauber auf die Kernnummer zurück, eigenständige Nummern treffen ihr eigenes Produkt. Nur Doku korrigiert: Kommentare im ShoppingUserController und der Testname waren als „Legacy-Fallback" fehletikettiert — es ist der beabsichtigte Mechanismus für Shop-Duplikate. Kommentar erklärt jetzt beide Fälle; Test umbenannt auf „shop-duplikat kernnummer-suffix bucht dasselbe kern-produkt". Keine Logikänderung. Suite 338 grün. Co-Authored-By: Claude Opus 4.8 --- .../Api/ShoppingUserController.php | 28 +++++++++++++------ tests/Feature/ApiOrderLogTest.php | 9 +++--- 2 files changed, 24 insertions(+), 13 deletions(-) diff --git a/app/Http/Controllers/Api/ShoppingUserController.php b/app/Http/Controllers/Api/ShoppingUserController.php index e188f6d..e970191 100755 --- a/app/Http/Controllers/Api/ShoppingUserController.php +++ b/app/Http/Controllers/Api/ShoppingUserController.php @@ -722,21 +722,31 @@ class ShoppingUserController extends Controller $error[] = 'article parameter is missing'; } else { - // AP-34 (26.08.2026): Jede Produktvariante ist im Shop eine eigene - // Bestellposition mit eigener Artikel-Nr. — in der DB eine eigene - // products-Zeile mit eigener wp_number (kein main_product_id, keine - // „-"-Suffixe). Der Connector sendet ab v1.6 die Variations-SKU statt - // der Eltern-SKU. Zuordnung deshalb primär über die VOLLE SKU gegen - // wp_number; der frühere „-"-Split bleibt nur optionaler Fallback für - // evtl. alte Variations-SKUs im Format „basisnr-suffix". Das Original - // bleibt in $order->article, damit das API-Protokoll die echte SKU zeigt. + // AP-34 — Zwei bewusst unterschiedene Fälle (Kunde bestätigt 28.08.2026): + // + // 1) Physisch verschiedene Produkte (z. B. 50 ml vs. 5 ml, mit/ohne + // Natron) sind im Shop eigene Produkte mit EIGENER Artikelnummer und + // im ERP eigene products-Zeilen mit eigener wp_number. Jede Zeile + // bucht ihr eigenes Produkt ⇒ Zuordnung primär über die VOLLE SKU. + // + // 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, z. B. 100500-a, + // 100500-b. Das ist derselbe physische Artikel und MUSS auf die + // Kernnummer (100500) gebucht werden ⇒ „-"-Split als gewollter Fallback, + // wenn die volle SKU selbst kein eigenes Produkt trifft. + // + // Reihenfolge (volle SKU zuerst) hält beide Fälle sauber auseinander: + // eine echte, eigenständige Nummer trifft immer ihr eigenes Produkt, + // nur die „-Suffix"-Duplikate fallen auf die Kernnummer zurück. Das + // Original bleibt in $order->article, damit das Protokoll die echte SKU zeigt. $article = trim((string) $order->article); $product = $article !== '' ? Product::whereWpNumber($article)->first() : null; - // Legacy-Fallback: alte Variations-SKU „basisnr-suffix" → Basisnummer + // Shop-Duplikat „kernnummer-suffix" (Kopie für Aktion/Bild) → Kernnummer. if (! $product && str_contains($article, '-')) { $baseArticle = trim(explode('-', $article, 2)[0]); if ($baseArticle !== '') { diff --git a/tests/Feature/ApiOrderLogTest.php b/tests/Feature/ApiOrderLogTest.php index de76a69..437a248 100644 --- a/tests/Feature/ApiOrderLogTest.php +++ b/tests/Feature/ApiOrderLogTest.php @@ -178,12 +178,13 @@ test('AP-34: jede variante wird über ihre eigene volle SKU dem richtigen produk ->and(ShoppingOrderItem::query()->where('shopping_order_id', $log->shopping_order_id)->where('product_id', $parent->id)->count())->toBe(0); }); -test('variations-sku im legacy-format „basisnr-suffix" wird als fallback zugeordnet', function () { - // Rückwärtskompatibilität: sollte der Shop noch eine alte Variations-SKU im - // Format „10042-1" senden, greift der „-"-Split-Fallback auf die Basisnummer. +test('AP-34: shop-duplikat „kernnummer-suffix" bucht dasselbe kern-produkt', function () { + // Kopiert ein Anwender ein Produkt für eine Aktion / ein neues Bild, verlangt + // WooCommerce eine eindeutige SKU (Kernnummer + Suffix, z. B. 10042-1). Das ist + // derselbe physische Artikel und muss auf das Kern-Produkt (10042) gebucht werden. Mail::fake(); Passport::actingAs(apilogMakeUser()); - $product = apilogMakeProduct('Apilog Variante', 10042); + $product = apilogMakeProduct('Apilog Aktionskopie', 10042); apilogMakeShoppingUser(4716); $this->postJson('https://api.'.config('app.api_domain').'/wp/order', [