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', [