JTL Vater-Kind-Artikel importieren: Varianten, Sets und Zubehör sauber trennen

Vater-Kind-Artikel klingen im Import einfach: Ein Vaterartikel beschreibt die Produktfamilie, die Kindartikel tragen Farbe, Größe, Länge oder eine andere Ausprägung. In der Praxis ist genau diese Entscheidung einer der häufigsten Fehlerpunkte bei JTL-Produktdaten.

Der Grund ist simpel: Lieferantendaten liefern selten eine fertige JTL-Logik. Sie liefern Artikelnummern, EANs, Namen, Kategorien, Preise und technische Merkmale. Ob daraus eine echte Variante, ein Set, ein Zubehörartikel oder ein eigenständiger Einzelartikel wird, ist eine fachliche Entscheidung.

Wer diese Entscheidung zu früh automatisiert, schreibt nicht nur Daten. Er schreibt Struktur ins ERP.

Was ein Vater-Kind-Import wirklich entscheidet

Ein Vater-Kind-Aufbau ist mehr als ein optischer Shop-Komfort. Er beeinflusst, wie Artikel gefunden, gepflegt, verkauft und später automatisiert werden.

Vor einem Import müssen deshalb mindestens diese Fragen beantwortet werden:

• Gehören die SKUs wirklich zur gleichen Produktfamilie?
• Ist die Unterscheidung eine echte Variante oder ein separates Produkt?
• Welche Eigenschaft wird zur Variantenauswahl: Farbe, Größe, Länge, Schließsystem, Material?
• Welche Bezeichnung trägt der Vaterartikel?
• Welche Namen behalten die Kindartikel?
• Gibt es bereits Einzelartikel in JTL, die zur Serie gehören?
• Werden Kategorien, Merkmale, Bilder, SEO-Daten und Shopaktivierung auf Vater- oder Kindebene gepflegt?

Ein klassischer Tabellenimport kann diese Fragen nicht beantworten. Er kann nur ausführen, was vorher entschieden wurde.

Vier Fälle, die oft verwechselt werden

Das größte Risiko entsteht, wenn unterschiedliche Produkttypen in eine gemeinsame Variantenlogik gezwungen werden.

Diese Trennung wirkt klein, ist aber kaufmännisch relevant. Ein Zubehörartikel als Kindartikel kann im Shop falsch erscheinen. Ein Set als Variante kann Lager- und Erwartungslogik verfälschen. Ein echter Variantenartikel als Einzelartikel erzeugt dagegen unnötige Dubletten und schlechtere Pflegebarkeit.

Bestehende Einzelartikel sind der kritische Punkt

Viele JTL-Systeme sind gewachsen. Eine Serie wurde vor Jahren als Einzelartikel angelegt, später kamen neue Lieferanten-SKUs hinzu, dann wurden Produktnamen geändert und irgendwann ist unklar, ob ein neuer Import eine bestehende Struktur erweitern oder eine neue Struktur anlegen soll.

Genau hier entstehen Serienkonflikte:

• Der Lieferant liefert neue SKUs aus derselben Produktfamilie.
• In JTL existieren bereits einzelne Artikel mit ähnlichem Namen, Hersteller oder EAN.
• Der Import erkennt keine direkte Artikelnummern-Dublette.
• Fachlich gehört der Artikel trotzdem zu einer bestehenden Serie.

Wenn jetzt blind eine neue Vater-Kind-Familie importiert wird, liegen danach alte Einzelartikel und neue Variantenfamilien nebeneinander. Das ist später deutlich schwerer zu bereinigen als vor dem Import.

Welche Daten vor dem Schreiben geprüft werden sollten

Ein belastbarer Vater-Kind-Import braucht zuerst einen Read-only-Lauf. Dabei geht es nicht um Perfektion, sondern um eine saubere Entscheidungsgrundlage.

Erst danach sollte entschieden werden, welche Artikel produktiv geschrieben werden.

Was ein ERP-Copilot hier anders macht

Ein ERP-Copilot ersetzt nicht die fachliche Verantwortung. Er beschleunigt die Vorarbeit, macht Konflikte sichtbar und bereitet Entscheidungen so auf, dass sie überprüfbar bleiben.

Der sinnvolle Modus ist:

Lieferantendaten lesen
-> JTL-Bestand abgleichen
-> Variantenfamilien vorschlagen
-> Sets und Zubehör isolieren
-> bestehende Einzelartikel markieren
-> Freigabeliste erzeugen
-> Write-Plan vorbereiten
-> kontrolliert schreiben
-> Readback prüfen

Der Unterschied zu einem normalen Workflow ist die fachliche Zwischenstufe. Der Agent soll nicht nur Datensätze transportieren. Er soll erklären, warum eine SKU als Kindartikel, Einzelartikel, Zubehör oder Prüffall bewertet wurde.

Ein gutes Ergebnis ist nicht immer ein vollständiger Import

Bei Produktdaten ist ein zurückgestellter Artikel oft ein gutes Zeichen. Er zeigt, dass der Prozess unsichere Fälle nicht versteckt.

Typische Gründe für eine Zurückstellung:

• Zubehörartikel wirkt wie eine Variante, ist aber funktional ein eigener Artikel.
• Setbestandteile sind in den Lieferantendaten nicht eindeutig beschrieben.
• Maße, Farben oder Schließsysteme widersprechen sich.
• Eine Serie existiert bereits als Einzelartikel in JTL.
• Pflichtdaten für Shop, Marktplatz oder GPSR fehlen.
• Der Artikel darf noch nicht automatisch shopaktiv gesetzt werden.

Ein sauberer Importprozess trennt deshalb grüne Fälle von gelben Prüffällen. Das ist langsamer als ein Blindimport, aber deutlich schneller als eine spätere Stammdatenbereinigung.

Verbindung zum Lieferantenartikel-Case

Im Praxiscase zum agentischen Onboarding von JTL-Lieferantenartikeln war genau diese Trennung entscheidend. Der Prozess hat nicht nur neue SKUs erkannt, sondern Variantenfamilien, Serienkonflikte und manuelle Prüffälle vor dem Schreiben sichtbar gemacht.

Dadurch entstand kein ungeprüfter Import, sondern ein freigabefähiger Plan: Welche Artikel sind direkt importfähig, welche gehören in eine Vater-Kind-Struktur und welche bleiben vorerst im Review?

Nächster Schritt für JTL-Händler

Wenn Lieferantenartikel, VeloConnect-Daten, CSV-Listen oder Herstellerfeeds regelmäßig in JTL vorbereitet werden, lohnt sich zuerst ein begrenzter Check:

• Welche Lieferantenquelle ist fachlich am relevantesten?
• Welche Produktgruppen enthalten echte Varianten?
• Welche bestehenden Einzelartikel müssen vorab berücksichtigt werden?
• Welche Felder dürfen automatisch geschrieben werden?
• Welche Entscheidungen brauchen Freigabe?
• Wie wird der Readback nach dem Schreiben geprüft?

Im Lieferanten-/Produktdaten-Check prüfen wir genau diese Fragen, bevor ein Importprozess produktive Schreibrechte bekommt.