White Label: Sofortpaket WL-00 und Bestandsprüfung WL-01

- Etikettgröße im Lieferschein korrekt parsen ("40#3,5" ergab 3 statt 3,5 cm)
- Produktkopie optional inkl. Kundenzuordnungen und Logo-Dateien (zweiter Kopier-Link)
- whitelabel:transfer-assignments: gezielte, wiederholbare Übertragung ohne Dubletten
- whitelabel:migrate-colors: Zuordnungen anhand der Bildfarbe auf die Farbprodukte übertragen (Dry-Run ohne --execute)
- whitelabel:report: rein lesende Bestandsprüfung (fehlende Zuordnungen, Farbwidersprüche, Dateien, Dubletten)
- Migration für attributes.value (Schema-Drift, auf Live No-op)
- Analyse/Entwicklungsplan um Gegenprüfung, systemischen Befund und neue Paketreihenfolge ergänzt

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

dev/white-label/analyse-und-entwicklungsplan-2026-09-17.md

@@ -0,0 +1,252 @@
+# White Label: Befunde, Verwaltungsbereich und Zuordnungslogik
+
+Stand: 17.09.2026 (ergänzt nach Gegenprüfung gegen Code und Datenbank am selben Tag). Grundlage: Prüfung des vorhandenen Codes, der angeschlossenen Datenbank und des gespeicherten Lieferscheins zur Bestellung 2050.
+
+**Status:** Analyse und Entwicklungsplan. Das Sofortpaket WL-00 und die Bestandsprüfung WL-01 sind umgesetzt (siehe Abschnitt 5 und 8). Die Pakete WL-02 bis WL-05 sind noch nicht implementiert.
+
+## 1. Ergebnis der Untersuchung
+
+Das Kundenlogo geht bei Bestellung 2050 nicht durch einen fehlgeschlagenen Dateitransfer verloren. Es ist vorhanden, aber anderen Produkten zugeordnet. Beim Anlegen der neuen Farbprodukte wurde keine passende Kundenzuordnung hergestellt. Zusätzlich unterdrückt die aktuelle Lieferscheinlogik die bekannte Tiegelfarbe, sobald ein Standardetikett verwendet wird.
+
+### Konkreter Fall: Bestellung 2050
+
+- Kundin: Sintia Assmann, Kunden-ID 207.
+- Bestelldatum: 16.09.2026.
+- Bestellreferenz auf dem Lieferschein: 2026092050.
+- Vorhandenes Dokument: `Lieferschein-2026091604.pdf`.
+
+| Bestelltes Produkt | Produkt-ID | Artikelnummer | Menge | Kundeneigenes Logo zugeordnet |
+| --- | --- | --- | --- | --- |
+| Bio Tattoocreme 40 ml, Tiegel SCHWARZ | 180 | 100122 | 10 + 1 | Nein |
+| Bio Tattoocreme 15 ml, Tiegel SCHWARZ | 183 | 100110 | 30 | Nein |
+
+Im gespeicherten PDF sind die Standardetiketten eingebettet. Alle drei Positionen tragen die Angabe **„Tiegel: Standard“**. Die White-Label-Produktbezeichnungen enthalten keine Farbe.
+
+Die Kundenlogos einschließlich ihrer Bilddateien existieren weiterhin:
+
+| Bisheriges Produkt | Produkt-ID | Kunden-Produkt-Zuordnung | Variante am Kundenlogo |
+| --- | --- | --- | --- |
+| Tattoocreme 40 ml, heute als Tiegel GOLD bezeichnet | 37 | 186 | Schwarz 40 ml, Attribut 6 |
+| Tattoocreme 15 ml, heute als Tiegel GOLD bezeichnet | 84 | 188 | Schwarz 15 ml, Attribut 3 |
+
+Weitere Kundenzuordnungen bestehen für die Produkte 38, 85 und 86. Für 180 und 183 fehlen sie vollständig. Die vorherige Bestellung 1729 vom 17.02.2026 verwendete noch die Produkte 37 und 84 und ist als Bestellung mit Kundenlogo gekennzeichnet. Die neuen schwarzen Produkte wurden am 27.07.2026 angelegt.
+
+**Einordnung:** Der Wechsel der Produkt-IDs erklärt den Ausfall. Die Kopierfunktion übernimmt Standardetiketten und mögliche Varianten, aber keine Kundenzuordnungen. Aus den geprüften Daten allein lässt sich der damalige Bedienablauf nicht vollständig rekonstruieren.
+
+### 2050 ist kein Einzelfall
+
+Am 27.07.2026 wurden 15 Farbprodukte (IDs 180–194) als Kopien der bisherigen Tattoocreme-Artikel angelegt. Seitdem gibt es weitere Bestellungen von Partnern, die eigene Logos besitzen, aber eines der neuen Farbprodukte **ohne Kundenzuordnung** bestellt haben:
+
+| Bestellung | Partner-ID | Produkt |
+| --- | --- | --- |
+| 1880, 1991 | 66 | 180 (40 ml Schwarz) |
+| 1929 | 358 | 180 (40 ml Schwarz) |
+| 2021 | 324 | 180 (40 ml Schwarz) |
+| 2003 | 324 | 183 (15 ml Schwarz), 186 (15 ml · 2 Stück Schwarz) |
+| 1930 | 154 | 185 (15 ml Weiß) |
+| 2050 | 207 | 180, 183 |
+
+Ob diese Partner ein Standardetikett wollten, ist fachlich je Fall zu klären. Die Liste wird von der Bestandsprüfung (`whitelabel:report`, Abschnitt 8) fortlaufend erzeugt.
+
+### Der eigentliche Befund: alle Partner-Logos liegen noch auf den alten Artikeln
+
+Die Bestandsprüfung zeigt **223 Kundenbilder von rund 43 Partnern**, deren Variante Schwarz, Weiß oder Silber ist, die aber auf den fünf alten Artikeln 37, 38, 84, 85 und 86 liegen – also auf den Produkten, die seit dem 27.07.2026 „Tiegel GOLD“ heißen. Vor der Umbenennung waren diese Artikel die Mehrfarb-Produkte; die Farbe kam aus der Variante am Kundenbild. Für die neuen Farbprodukte 180–194 existiert praktisch keine Kundenzuordnung.
+
+Folge: **Jeder dieser Partner verliert sein Logo, sobald er das zu seiner Farbe passende neue Produkt bestellt.** Bestellung 2050 ist der erste bemerkte Fall, nicht der einzige. Die Zuordnung ist mechanisch eindeutig (alter Artikel + Bildfarbe → gleichfarbige Kopie) und wird vom Befehl `whitelabel:migrate-colors` (Abschnitt 6) automatisch aufgelöst; kein Fall blieb dabei unauflösbar.
+
+## 2. Schwachstellen der bestehenden Verwaltung
+
+1. **Verteilte Pflege:** Produkte, mögliche Varianten, Standardetiketten und Kundenlogos werden an unterschiedlichen Stellen verwaltet. Eine gemeinsame Übersicht fehlt.
+2. **Strikte Produktbindung ohne Übertragungshilfe:** Die Logoauswahl verlangt dieselbe Produkt-ID in Bestellung und Kundenzuordnung. Ein ähnlich benanntes oder kopiertes Produkt erbt kein Kundenlogo.
+3. **Zwei parallele Farbmodelle:** Es gibt eigene Artikel für Schwarz, Gold, Weiß und Silber. Gleichzeitig führen selbst die schwarzen Produkte 180 und 183 weiterhin alle vier Farben als mögliche White-Label-Varianten.
+4. **Unklare Beschriftung:** Die Kundenverwaltung zeigt zugeordnete Produkte mit ihrer White-Label-Bezeichnung. Da diese keine Farbe enthält, können verschiedene Farbprodukte gleich aussehen.
+5. **Versteckte Voraussetzung für Kundenlogos:** Ein Kundenlogo ersetzt nur ein bestehendes Standardetikett mit überlappender Attribut-ID. Ohne Standardetikett oder passende Attribute wird es nicht berücksichtigt.
+6. **Farbe wird aus dem Etikett abgeleitet:** Standardetiketten erhalten pauschal die Bezeichnung „Standard“. Die tatsächlich bestellte Tiegelfarbe bleibt dabei unberücksichtigt.
+7. **Mehrdeutige Auswahl:** Bei mehreren Varianten an einem Etikett wird die Anzeige wiederholt überschrieben. Die zuletzt verarbeitete Variante bleibt übrig; eine fachlich eindeutige Auswahl fehlt. Konkrete Ursache: Das Hilfsarray `$varinats` in `prepairForDelivery()` wird nie befüllt, die Prüfung `isset($varinats[...])` ist deshalb immer falsch.
+8. **Keine historische Absicherung in der Bestellposition:** Farbe und ausgewähltes Logo werden derzeit bei der Dokumenterstellung aus aktuellen Stammdaten ermittelt. Eine spätere Neuerstellung kann dadurch andere Angaben liefern.
+9. **Gespeicherte PDFs aktualisieren sich nicht automatisch:** Eine korrigierte Kundenzuordnung allein repariert einen bestehenden Lieferschein nicht.
+10. **Etikettgröße wurde falsch geparst (behoben in WL-00):** Die Attributwerte tragen die Abmessung mit deutschem Komma (`40#3,5`). `(float) "3,5"` ergibt in PHP `3.0`; 40-ml-Etiketten wurden im Lieferschein mit 3 cm statt 3,5 cm gerendert. Das Format `Volumen#Größe` im Attributwert ist ein weiterer Grund, Abmessungen künftig als echte Zahlenfelder zu speichern.
+
+Die Daten zeigen außerdem einen wichtigen Migrationskonflikt: Die alten Produkte 37 und 84 heißen heute „GOLD“, ihre Kundenlogos sind aber „Schwarz“ zugeordnet. Alte Bestellungen dürfen deshalb nicht nachträglich allein aus aktuellen Produktnamen interpretiert werden.
+
+## 3. Zielbild: eigener Navigationspunkt „White Label“
+
+Bestehende Produkte und Kunden weiterverwenden. Der neue Bereich wird die zentrale Oberfläche für White-Label-Konfigurationen; keine zweite, unabhängig gepflegte Produktverwaltung aufbauen.
+
+### Ansicht „Kundenzuordnungen“
+
+- Suche und Filter nach Kunde, Produkt, Artikelnummer, Farbe und Prüfstatus.
+- Pro Zuordnung: Kunde, vollständiger Produktname, Artikelnummer, Farbe, Logo-Vorschau, Etikettposition und Status.
+- Aktionen: anlegen, bearbeiten, deaktivieren und gezielt auf andere Farbprodukte übertragen.
+- Auch unvollständige Zuordnungen und relevante Bestellpositionen ohne Kundenzuordnung sichtbar machen.
+
+Beispiel für die gewünschte Darstellung:
+
+| Kunde | Produkt | Farbe | Etikett | Status |
+| --- | --- | --- | --- | --- |
+| Sintia Assmann | Tattoocreme 40 ml · 100122 | Schwarz | Vorschau des Kundenlogos | Vollständig |
+
+### Ansicht „Produkte“
+
+- Alle White-Label-Produkte mit eindeutiger Farbe und Größe.
+- Standardetiketten, benötigte Etikettpositionen und Anzahl der Kundenzuordnungen anzeigen.
+- Fehlende Farbe, fehlende Bilddateien und widersprüchliche Altdaten hervorheben.
+- Beim Kopieren eines Produkts eine ausdrückliche Auswahl zur Übernahme von Kundenzuordnungen anbieten. Zielprodukt und Etikettpositionen vor der Übernahme prüfen; vorhandene Zuordnungen nicht still überschreiben.
+
+### Ablauf beim Anlegen einer Zuordnung
+
+1. Kunde und konkretes Produkt auswählen.
+2. Farbe und Größe aus der Produktkonfiguration anzeigen. Keine zweite, widersprüchliche Farbauswahl am Logo anbieten.
+3. Vorhandenes Kundenlogo auswählen oder neues Bild hochladen und einer Etikettposition zuweisen.
+4. Vorschau der späteren Lieferscheinangabe anzeigen, beispielsweise „Tiegel: Schwarz · Etikett: Kundenlogo“.
+5. Validieren und speichern. Fehler müssen die betroffene Zuordnung und den notwendigen nächsten Schritt nennen.
+
+## 4. Lösung zur Bereinigung der Zuordnungslogik
+
+### 4.1 Farbe, Etikettposition und Logo getrennt modellieren
+
+**Grundregel:** Das bestellte Produkt bestimmt die Tiegelfarbe. Die Kombination aus Kunde und Produkt bestimmt die kundenspezifischen Etiketten. Die Position bestimmt, welches Etikett ersetzt wird. Diese Entscheidungen dürfen nicht mehr durch die Schnittmenge beliebiger Farbattribute entstehen.
+
+Vorgeschlagene Struktur:
+
+| Ebene | Verbindliche Information | Umsetzungsvorschlag |
+| --- | --- | --- |
+| Produkt | Genau eine freigegebene Farbe/Größe je Farbprodukt | Explizite Variantenreferenz `products.whitelabel_variant_id` auf ein bestehendes Attribut. Für Nicht-White-Label-Produkte optional. Die Attributnamen enthalten heute die Größe („Schwarz 40 ml"); für die Ausgabe „Tiegel: Schwarz" braucht das Attribut ein eigenes Farbfeld oder eine saubere Trennung von Farbe und Größe. |
+| Etikettposition | Welche Etiketten das Produkt benötigt | Spalten `position` (deckel/seite/boden) und `size_cm` direkt an `product_images`. Im Bestand hat keines der 28 White-Label-Produkte mehr als ein Standardetikett und es gibt keine Dubletten; ein eigenes Positions-Table ist dafür nicht nötig und kann später ergänzt werden, falls Produkte mit mehreren Etiketten kommen. |
+| Kundenzuordnung | Ein Datensatz je Kunde und Produkt | `user_whitelabel_products` weiterverwenden; nach Bereinigung bestehender Dubletten Eindeutigkeit auf `(user_id, product_id)` absichern. |
+| Kundenetikett | Welches Bild an welcher Position verwendet wird | Bestehende Bilddatensätze über eine eindeutige Positionsreferenz zuordnen. Pro Kundenzuordnung und Position höchstens ein aktives Kundenetikett. |
+| Bestellposition | Tatsächlich aufgelöste Farbe und Etiketten | Unveränderlichen Datenstand für Dokumente speichern, siehe Abschnitt 4.4. |
+
+Ein Kundenetikett darf eine definierte Position auch dann belegen, wenn dort kein Standardbild vorhanden ist.
+
+Die bisherigen Attributlisten an Bildern bleiben während der Migration lesbar, werden nach der Umstellung aber nicht mehr zur produktiven Farbauswahl oder Ersetzung verwendet. Produktnamen und kopierte Slugs dienen höchstens als Prüfhilfe, nicht als verbindliche Farbquelle.
+
+**`attribute_variants` stilllegen:** Hat das Produkt genau eine Farbe, sind die vier „möglichen Varianten" je Produkt nur noch Altlast und die Quelle des Doppelmodells (Schwachstelle 3). Nach WL-02 bietet das Produktformular das Feld nicht mehr an, sonst wird dort weiter gepflegt.
+
+### 4.2 Eine gemeinsame Auflösungsfunktion
+
+Einen Service, beispielsweise `WhiteLabelResolver`, für Verwaltungsvorschau, Bestellprüfung und Dokumentvorbereitung einführen. Der Service liest Daten und liefert das Ergebnis einschließlich Fehlern und Herkunft der Etiketten zurück. Er speichert keine Bestellung und erzeugt keine PDF-Dateien.
+
+Regeln pro Bestellposition:
+
+1. White-Label-Eigenschaft und eindeutige Produktvariante prüfen.
+2. Aktive Kundenzuordnung für **genau diesen Kunden und dieses Produkt** suchen.
+3. Für jede benötigte Etikettposition das eindeutig zugeordnete Kundenbild verwenden.
+4. Ist für diese Position kein Kundenbild vorgesehen, das gültige Standardbild verwenden.
+5. Ist ein Kundenbild ausdrücklich zugeordnet, aber fehlt die Datei oder ist die Zuordnung widersprüchlich, einen Fehler melden. Kein stiller Rückfall auf ein Standardbild.
+6. Fehlen für eine benötigte Position sowohl Kunden- als auch Standardbild, die Position als unvollständig melden.
+7. Die Tiegelfarbe immer aus der Produktvariante ausgeben, unabhängig von der Bildquelle.
+
+| Situation | Ergebnis |
+| --- | --- |
+| Eindeutiges Kundenlogo mit vorhandener Datei | Kundenlogo + Produktfarbe |
+| Keine Kundenzuordnung, gültiges Standardetikett | Standardetikett + Produktfarbe |
+| Kundenlogo vorgesehen, aber ungültig oder Datei fehlt | Fehler; kein automatischer Austausch durch Standardetikett |
+| Mehrere aktive Kundenlogos für dieselbe Position | Konflikt; keine Auswahl nach Reihenfolge |
+| Kundenlogo vorhanden, Standardbild fehlt | Kundenlogo zulässig, wenn Position und Abmessungen vollständig definiert sind |
+| Farbe oder erforderliches Etikett fehlt | Unvollständig; Freigabe des Lieferscheins verhindern |
+
+**Fehlende Zuordnung erkennen:** Ein Standardetikett kann fachlich korrekt sein. Das System darf daher nicht jedes Produkt ohne Kundenlogo als Fehler behandeln. Hat der Kunde bei anderen Produkten eigene Logos, zeigt die Bestellprüfung einen Hinweis „Für dieses Produkt keine Kundenzuordnung vorhanden“. **Ort der Bestellprüfung:** Es gibt keine shopseitige White-Label-Logik. Der Hinweis gehört auf die Admin-Bestelldetailseite (`admin/sales/_detail`) und in die WaWi-Auftragsansicht, jeweils **vor** dem Klick auf „Rechnung erstellen“, da beide Wege Lieferscheine erzeugen. Bei Produktkopien wird dieser Hinweis durch die Übernahmefunktion ergänzt. Eine automatische Vererbung anhand ähnlicher Namen oder einer Rezepturbeziehung ist nicht vorgesehen.
+
+`user_white_label` soll künftig aus den tatsächlich ausgewählten Kundenetiketten abgeleitet werden. Das Kennzeichen darf nicht nur dauerhaft auf `true` gesetzt werden und nicht mit der allgemeinen White-Label-Eigenschaft des Produkts verwechselt werden. Die Speicherung erfolgt im Bestellablauf, nicht im Renderer.
+
+### 4.3 Darstellung im Lieferschein
+
+- Produktbezeichnung und Artikelnummer eindeutig anzeigen.
+- Farbe ausdrücklich ausgeben, auch beim Standardetikett: **„Tiegel: Schwarz“**.
+- Etikettquelle getrennt benennen: **„Kundenlogo“** oder **„Standardetikett“**.
+- Alle benötigten Etiketten an ihren Positionen mit korrekten Abmessungen abbilden.
+- Derselbe aufgelöste Datenstand muss in Verwaltungsvorschau und PDF verwendet werden.
+
+### 4.4 Historische Bestellungen schützen
+
+Für neue Bestellungen bei verbindlicher Bestellanlage einen Datenstand je Position speichern: eine JSON-Spalte `whitelabel_snapshot` an `shopping_order_items` mit Produkt-ID, Bezeichnung, Artikelnummer, Farbe/Größe, Etikettposition, Abmessung, Bildquelle, Bild-ID, Dateiname und Datei-Hash. Bei ungeklärten Zuordnungen einen offenen Prüfstatus speichern und vor Dokumentfreigabe auflösen.
+
+Die referenzierten Bilddateien müssen erhalten bleiben. Das wird am einfachsten erreicht, indem Kundenlogo-Dateien (`uwllogo`) beim Löschen oder Ersetzen nicht physisch entfernt, sondern nur deaktiviert werden. Ein vollständiges Versionierungssystem für Bilder ist für diesen Umfang unverhältnismäßig. Spätere Stammdatenänderungen verändern bestehende freigegebene Bestellpositionen nicht. Eine bewusste Korrektur wird mit altem und neuem Stand protokolliert.
+
+Alte Bestellungen nicht pauschal mit heutigen Stammdaten überschreiben. Bestehende PDFs erhalten. Für eine ausdrücklich angestoßene Neuerstellung ohne historischen Datenstand zunächst eine Vorschau und Prüfung verlangen. Das ist insbesondere für den Konflikt „alter Artikel heute GOLD, damals Kundenvariante Schwarz“ erforderlich.
+
+## 5. Kleiner Entwicklungsplan
+
+| Arbeitspaket | Inhalt | Abnahmekriterium | Stand |
+| --- | --- | --- | --- |
+| WL-00: Sofortpaket | Etikettgröße korrekt parsen (Schwachstelle 10). Produktkopie mit ausdrücklicher Option „Kundenzuordnungen übernehmen“. Befehl `whitelabel:transfer-assignments` zur wiederholbaren Übertragung von Kundenzuordnungen zwischen Produkten (Abschnitt 6). | Kopie und Übertragung erzeugen keine Dubletten; 40-ml-Etiketten sind 3,5 cm groß. | umgesetzt 17.09.2026 |
+| WL-01: Bestandsprüfung | Befehl `whitelabel:report`: Bestellungen ohne Kundenzuordnung bei Partnern mit Logos, Farbwidersprüche zwischen Kundenbild und Produkt, fehlende Dateien, Dubletten, Mehrfachetiketten, Bilder ohne Variantenzuordnung. Rein lesend. | Jeder Konflikt ist mit betroffenen IDs nachvollziehbar; keine automatische Bereinigung. | umgesetzt 17.09.2026 |
+| WL-02: Datenmodell und Auflösung | Eindeutige Produktvariante, Etikettposition/Größe am Bild, Zuordnungsregeln und gemeinsamen Resolver ergänzen. Eindeutige Altdaten übernehmen, Konflikte zur Prüfung vorlegen. `attribute_variants` stilllegen. | Gleiche Eingaben ergeben dieselbe Farbe und dieselben Etiketten; keine Auswahl nach Reihenfolge. | offen |
+| WL-03: Bestellung und Lieferschein | Datenstand je Position speichern, Resolver anbinden, Farbe und Etikettquelle getrennt ausgeben, Kennzeichen im Bestellablauf ableiten, Hinweis „keine Kundenzuordnung“ in Bestelldetail und WaWi-Auftrag. | Vorschau und PDF stimmen überein; bestehende Dokumente ändern sich nicht unbemerkt. | offen |
+| WL-04: Verwaltungsbereich | Navigation „White Label“, beide Ansichten, Anlage/Bearbeitung, Vorschau und Übertragung in der Oberfläche. Bestehende Admin-Berechtigungen und `user`-Guard verwenden. | Kundenlogos und Farbprodukte sind eindeutig erkennbar und zentral pflegbar. Alte Bearbeitungswege verwenden dieselben Regeln oder verweisen auf den neuen Bereich. | offen |
+| WL-05: Migration und Abnahme | Bestandskonflikte fachlich auflösen, Regressionstests und manuelle PDF-Prüfung. | Standardfälle bleiben korrekt; alle Befunde aus `whitelabel:report` sind entweder behoben oder bewusst akzeptiert. | offen |
+
+Die Reihenfolge ist bewusst: Das Sofortpaket stoppt den laufenden Schaden, die Bestandsprüfung liefert die Fälle. Danach zuerst Regeln und Lieferschein (fachlicher Nutzen), erst dann die Oberfläche als größtes Paket. Eine reine Verschiebung der bisherigen Formulare in einen neuen Menüpunkt würde die Fehlerursache erhalten.
+
+### Erforderliche Prüfungen für die Umsetzung
+
+- Fall 2050: Produkte 180 und 183, schwarzer Tiegel und Kundenlogo; alle drei Positionen und Mengen erhalten.
+- Standardetikett auf schwarzem Produkt: Farbe bleibt Schwarz.
+- Kundenlogo ohne Standardbild an einer vollständig definierten Position funktioniert.
+- Fehlende Bilddateien, Dubletten und widersprüchliche Farben ergeben verständliche Fehler.
+- Mehrere Etikettpositionen bleiben getrennt; eine Kundenüberschreibung verändert keine andere Position.
+- Produktkopie: Kundenzuordnungen nur nach gezielter Auswahl übernehmen; Übernahme ist wiederholbar ohne Dubletten.
+- Logoänderung nach Bestellung: bestehender Datenstand und vorhandene PDF bleiben unverändert.
+- Vorschau und lesende Auflösung schreiben weder Bestellungen noch Kennzeichen.
+- Bestehende Bestell- und Logistikabläufe einschließlich PDF-Anhängen bleiben funktionsfähig.
+
+Automatisierte Regressionstests für den Resolver und die Integration ergänzen; PDF zusätzlich visuell prüfen. Laravel-Tests ausschließlich in der vorgesehenen Testumgebung ausführen.
+
+## 6. Konkrete Korrektur für Bestellung 2050 und gleichartige Fälle
+
+Als separat ausführbare Datenkorrektur über den Befehl aus WL-00:
+
+```bash
+php artisan whitelabel:transfer-assignments 37 180 --user=207 --dry-run   # Vorschau
+php artisan whitelabel:transfer-assignments 37 180 --user=207             # 40 ml
+php artisan whitelabel:transfer-assignments 84 183 --user=207             # 15 ml
+```
+
+1. Der Befehl kopiert die Kundenzuordnung samt Logo-Dateien und Variantenzuordnung (Attribut 6 für 40 ml, Attribut 3 für 15 ml) auf das Zielprodukt. Vorhandene Zuordnungen auf dem Zielprodukt werden übersprungen, der Befehl ist wiederholbar.
+2. Ohne `--user` werden alle Kundenzuordnungen des Quellprodukts übertragen; das ist der Weg, wenn eine ganze Produktkopie nachträglich versorgt werden soll.
+3. Neu erzeugten Lieferschein auf Logo, schwarze Tiegelfarbe und alle Mengen prüfen. Die Neuerstellung über „Rechnung erstellen“ (Bestelldetail) versendet keine Mail, solange „Rechnung per Mail senden“ nicht angehakt ist.
+4. Das vorhandene Dokument vor der Neuerstellung sichern.
+
+**Migration für alle Partner (GOLD/Farb-Konflikt):**
+
+```bash
+php artisan whitelabel:migrate-colors               # Vorschau: 223 geplante Übertragungen, 0 unauflösbar
+php artisan whitelabel:migrate-colors --user=207    # Vorschau für einen Partner
+php artisan whitelabel:migrate-colors --execute     # ausführen
+```
+
+Der Befehl leitet für jede Kundenzuordnung die Bildfarbe aus der Variante ab, sucht das Produkt mit gleichem Basisnamen und dieser Farbe („Bio Tattoocreme 40 ml (Tiegel SCHWARZ)“) und kopiert die Zuordnung dorthin. Die Quellzuordnung bleibt erhalten (der alte Artikel ist weiterhin bestellbar und Bestellungen vor dem 27.07. referenzieren ihn). Zuordnungen mit mehreren Bildfarben oder ohne passendes Zielprodukt werden nur gemeldet. Vor `--execute` auf Live: Datenbank-Backup, danach `whitelabel:report` erneut ausführen; Abschnitt B muss dann leer sein bis auf bewusst akzeptierte Fälle.
+
+Für die weiteren Partner mit Bestellungen ohne Zuordnung (Abschnitt 1) ist im Einzelfall zu klären, ob das Standardetikett gewollt war; bei den Tattoobalm/Tattooseife-Fällen (Produkte 118, 130, 154) gibt es keine Farbkopien, dort greift die Migration nicht.
+
+Diese Korrektur löst die konkreten Fälle, ersetzt aber nicht die Bereinigung der Verwaltung und Zuordnungslogik.
+
+## 7. Relevante Stellen im bestehenden Code
+
+- [InvoiceRepository](../../app/Repositories/InvoiceRepository.php): `prepairForDelivery()` wählt Etiketten und Varianten; `update()` erzeugt vorhandene Dokumente neu; `ensureFilesOnDisk()` regeneriert fehlende Dateien.
+- [ProductRepository](../../app/Repositories/ProductRepository.php): `copy()`, `copyImages()`, `updateWLVariants()` und `updateWLImageAttributs()`.
+- [Produktmodell](../../app/Models/Product.php): Variantenbeziehungen und `getWhiteLableName()`.
+- [Kundenzuordnung](../../app/Models/UserWhitelabelProduct.php) und [Bildmodell](../../app/Models/ProductImage.php): bestehende Beziehungen und Bildpfade.
+- [Produktformular](../../resources/views/admin/product/form.blade.php): mögliche Varianten und Standardetiketten.
+- [Kundenformular](../../resources/views/admin/lead/m_white_label.blade.php) und [LeadController](../../app/Http/Controllers/LeadController.php): Anlage und Pflege der Kundenlogos.
+- [Lieferscheinvorlage](../../resources/views/pdf/delivery.blade.php): Bild-, Produkt- und Tiegelanzeige.
+- [Bestellposition](../../app/Models/ShoppingOrderItem.php): Ansatzpunkt für den historischen Datenstand.
+- [OrderFulfillmentController](../../app/Http/Controllers/Admin/Inventory/OrderFulfillmentController.php): zweiter Auslösepfad für Rechnung und Lieferschein aus der WaWi (`create()` und `ensureFilesOnDisk()`).
+- [MailLogistic](../../app/Mail/MailLogistic.php): wertet `user_white_label` für den Lieferschein-Anhang aus; bei geänderter Ableitung mitprüfen.
+- [Bestelldetail](../../resources/views/admin/sales/_detail.blade.php): zeigt `user_white_label`; Ort für den Hinweis „keine Kundenzuordnung“.
+
+## 8. Umsetzung WL-00 und WL-01 (17.09.2026)
+
+- `InvoiceRepository::prepairForDelivery()`: Abmessung und Volumen über `reFormatNumber()` geparst; `40#3,5` ergibt jetzt 3,5 cm.
+- `ProductRepository::copyWhitelabelAssignments($source, $target)`: kopiert `user_whitelabel_products` samt `uwllogo`-Bildern (Datei und Variantenzuordnung) auf das Zielprodukt, überspringt vorhandene Kombinationen `(user_id, product_id)`, liefert Anzahl übernommen/übersprungen.
+- Produktliste: bei White-Label-Produkten mit Kundenzuordnungen ein zweiter Kopier-Link „Kopieren inkl. Kundenlogos (n)“; der normale Kopier-Link übernimmt weiterhin keine Zuordnungen.
+- `php artisan whitelabel:transfer-assignments {quelle} {ziel} [--user=] [--dry-run]`: gezielte Übertragung.
+- `php artisan whitelabel:migrate-colors [--user=] [--execute]`: automatische Übertragung anhand der Bildfarbe (Dry-Run ohne `--execute`).
+- `php artisan whitelabel:report [--since=2026-07-27]`: rein lesende Bestandsprüfung (WL-01), Abschnitte A–F.
+- Migration `2026_09_17_100000_add_value_to_attributes_table`: legt `attributes.value` nur an, wenn die Spalte fehlt (Schema-Drift; auf Live vorhanden, in den Migrationen bisher nicht).
+- Tests: `tests/Feature/WhitelabelAssignmentTest.php` (Übertragung, Kopie, Dublettenschutz, Befehle, Etikettgröße).
+
+**Lokal durchgeführt (Dev-Datenbank):** Übertragung 37→180 und 84→183 für Partner 207, Lieferschein 2050 neu erzeugt (Backup vorher). Ergebnis: alle drei Positionen mit Kundenlogo, „Tiegel: Schwarz 40 ml“ bzw. „Schwarz 15 ml“, Etikett 3,5 cm bzw. 2 cm, `user_white_label` = true.
+
+**Auf Live noch auszuführen:** `php artisan migrate`, `whitelabel:migrate-colors --execute` nach Backup und Freigabe, danach Lieferschein 2050 über „Rechnung erstellen“ neu erzeugen (ohne Mailversand).