JTL-Wawi Lieferantenartikel importieren: warum wir 259 neue Artikel nicht blind automatisiert haben

Lieferantenartikel wirken auf den ersten Blick wie ein klassischer Importfall: Artikelnummer, EAN, Preis, Bild und Kategorie kommen aus einer strukturierten Quelle, also muss man die Daten nur nach JTL-Wawi schreiben.

Im echten Sortimentaufbau ist genau das der riskante Teil. Der Import ist nicht schwer, weil eine Schnittstelle fehlt. Er ist schwer, weil vor dem Schreiben fachliche Entscheidungen getroffen werden müssen.

In einem aktuellen JTL-Projekt haben wir deshalb keinen vollautomatischen Import gebaut, sondern einen agentisch geführten Vorbereitungsprozess. Der Agent hat Lieferantendaten gelesen, bestehende JTL-Strukturen geprüft, Variantenfamilien erkannt, Konflikte isoliert und erst danach einen freigabefähigen Write-Plan vorbereitet.

Was manuell passieren müsste

Ohne geführten Prozess ist so ein Lauf kein einzelner Import, sondern eine lange Abstimmungskette zwischen Sortimentspflege, Einkauf, Shopverantwortlichen und Geschäftsführung.

Vom Schnittstellen-Onboarding zum Import-Skill

Im ersten Schritt ging es nicht darum, möglichst schnell eine einzelne Kategorie zu importieren. Aus dem Lieferanten- und Schnittstellen-Onboarding sollte ein wiederholbarer Prozess entstehen.

Am Beispiel der Fahrradtaschen wurde dieser Ablauf einmal fachlich und technisch durchoptimiert: Lieferantendaten lesen, bestehende JTL-Strukturen prüfen, Variantenlogik verstehen, Kategorien und Merkmale vorbereiten, SEO-Daten erzeugen, Risiken isolieren, Review ermöglichen und Ergebnisse per Readback absichern.

Nach dem Review war daraus ein konkreter Import-Skill entstanden: ein geführter Ablauf für komplett konfigurierte Artikelimporte in JTL-Wawi. Dieser Skill beschreibt nicht nur, welche Felder geschrieben werden, sondern auch, welche Prüfungen, Freigaben und Readbacks vor und nach dem Schreiben erforderlich sind.

Die Kategorie Fahrradschlösser und Sicherheit wurde danach nicht wieder bei null begonnen. Sie war der nächste Einsatz dieses optimierten Import-Skills. Dadurch konnte eine neue Produktwelt in einem Bruchteil der Zeit vorbereitet werden, ohne die Kontrolle über Varianten, Kategorien und Schreiboperationen zu verlieren.

Wichtig bleibt: Die echte Shopware-/SalesChannel-Aktivierung wurde daraus bewusst nicht als automatisch erledigt abgeleitet. Ein technischer Test meldete Erfolg, aber der Readback war nicht belastbar. Genau deshalb bleibt dieser letzte Schritt ein separater Proof, bevor solche Schreiboperationen skaliert werden.

Nächster Lauf: 424 Artikel aus einer Lieferantenquelle

Die konkrete Quelle war eine Lieferantenschnittstelle aus dem Fahrradhandel. VeloConnect ist in dieser Branche ein bekanntes Format für Lieferantendaten und deshalb ein naheliegendes Beispiel. Der Ansatz ist aber nicht auf VeloConnect beschränkt. Dasselbe Muster funktioniert grundsätzlich auch mit XML, CSV, Hersteller-APIs, PIM-Exporten oder individuellen Lieferantenschnittstellen.

Im Projekt ging es um die Produktwelt Fahrradschlösser und Sicherheit. Der Agent fand mehrere relevante Lieferantengruppen, statt nur eine einzelne Kategorie blind zu übernehmen:

In Summe wurden 424 aktuelle Lieferantenartikel geprüft. Davon waren 165 bereits in JTL vorhanden. 259 SKUs waren potenziell neu.

Warum die JTL-Kategoriestruktur entscheidend ist

Ein wichtiger Punkt im Projekt war die Trennung zwischen Lieferantenstruktur und Shopstruktur.

In JTL existiert eine technische Struktur für Import, Abgleich und Herkunftsnachweis:

Lieferanten > VeloConnect > Lieferantenkategorie

Diese Struktur bleibt erhalten. Artikel werden nicht daraus entfernt, nur weil sie später im Shop verkauft werden sollen.

Die echte Shopstruktur entsteht separat, zum Beispiel unter:

Onlineshop > Home > Teile & Zubehör

Artikel bleiben also in der Lieferantenstruktur und bekommen später zusätzlich eine Shop-Kategoriezuordnung. Genau diese Trennung verhindert, dass Importlogik, Sortimentspflege und Shop-Navigation miteinander vermischt werden.

Der Agentenprozess

Der Prozess war bewusst mehrstufig und zuerst read-only. Entscheidend ist die Reihenfolge: Erst verstehen, dann entscheiden, dann schreiben.

Der wichtigste Unterschied zu einem klassischen Workflow: Der Agent transportiert nicht nur Daten von A nach B. Er führt einen fachlichen Prüf- und Entscheidungsprozess.

Die Zahlen aus dem Lauf

Variantenfamilien sind kein reines Datenproblem

Bei Lieferantenartikeln ist eine Variante nicht immer eindeutig. Ein Rahmenschloss mit Einsteckkette kann je nach Produktlogik eine Variante, ein Set oder ein eigenständiger Artikel sein.

Der Agent erkannte 20 neue Variantenfamilien mit 44 potenziellen Kindartikeln. 19 Familien wurden als fachlich grün bewertet. Eine gelbe Setfamilie blieb zurückgestellt.

Dadurch entstand ein freigabefähiger Vater-Kind-Plan mit 19 Vaterartikeln und 42 Kindartikeln. Zwei erkannte Kind-SKUs wurden bewusst nicht in den ersten Batch aufgenommen.

Warum diese Trennung vor dem Import so wichtig ist, haben wir im Folgeartikel JTL Vater-Kind-Artikel importieren: Varianten, Sets und Zubehör sauber trennen genauer aufgeschlüsselt.

Der kritische Moment: Serienkonflikte statt Blindimport

Der Agent fand keine direkten SKU-Konflikte bei den neuen Lieferantenartikelnummern. Gleichzeitig erkannte er aber bestehende JTL-Einzelartikel aus denselben Produktserien.

Solche Fälle sind riskant. Ein starrer Importworkflow würde vermutlich neue Variantenfamilien anlegen und bestehende Einzelartikel ignorieren. Danach lägen im ERP alte Einzelartikel und neue Variantenfamilien nebeneinander.

Der agentische Prozess markierte diese Serienkonflikte stattdessen als eigene Entscheidung:

• bestehende Einzelartikel zuerst migrieren
• neue SKUs vorerst als Einzelartikel importieren
• neue Vater-Kind-Familie separat anlegen
• oder die betroffene Serie aus dem ersten Batch herausnehmen

Das ist der Kern des Cases: Nicht alles, was technisch geschrieben werden kann, sollte automatisch geschrieben werden.

Was zurückgestellt wurde

Zehn Artikel wurden bewusst nicht in die erste Importwelle aufgenommen:

• sechs Halter- oder Zubehörartikel mit auffälligen technischen Maßen oder Merkmalen
• zwei Diebstahlschutzartikel für separate Bewertung
• zwei gelbe Setfamilien-Kinder

Das ist kein Fehler des Prozesses. Es ist ein Qualitätsmerkmal. Der Agent hat unsichere Fälle isoliert, statt sie in einem großen Importbatch zu verstecken.

Warum das für JTL-Händler relevant ist

Viele Händler haben nicht Angst vor zu wenig Automatisierung. Sie haben Angst vor schlechten Stammdaten:

• falsche Artikel im System
• kaputte Vater-Kind-Strukturen
• doppelte Serien
• falsche Kategorien
• fehlende Pflichtdaten
• Shopartikel, die ungeprüft live gehen
• undurchsichtige Middleware, die produktiv schreibt

Ein guter ERP-Copilot gibt nicht weniger Kontrolle, sondern mehr. Er macht sichtbar, was geprüft wurde, welche Risiken bestehen, welche Entscheidung offen ist und was später wirklich geschrieben würde.

Vollautomation ist nicht das Ziel

Klassische Workflow-Automation ist stark, wenn Regeln eindeutig sind:

• Wenn ein Bestand sich ändert, aktualisiere den Lieferantenlink.
• Wenn ein Auftrag bezahlt ist, setze den Status.
• Wenn ein Dokument fehlt, erzeuge eine Aufgabe.

Sortiment-Onboarding ist anders. Es enthält fachliche Graubereiche, alte Stammdaten, Variantenlogik, Kategorieentscheidungen und Shop-Freigaben.

Deshalb war der richtige Modus nicht:

Feed lesen -> Artikel schreiben

Sondern:

lesen -> prüfen -> Risiken markieren -> Rückfragen stellen -> Freigabe einholen -> Write-Plan erzeugen -> kontrolliert schreiben -> per Readback prüfen

Was daraus als Produktmuster entsteht

Der Case zeigt ein generisches Muster für JTL-Wawi-Händler:

Das ist genau der Bereich, in dem ein ERP-Copilot für JTL-Wawi mehr leistet als ein Dashboard. Ein Dashboard zeigt Daten. Ein agentischer Prozess begleitet die Arbeit bis zur nächsten sicheren Entscheidung.

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

Nicht jeder Lieferantenimport braucht sofort einen großen Spezialagenten. Der sinnvolle Einstieg ist ein klar begrenzter Pilot:

• Welche Lieferantenquelle soll vorbereitet werden?
• Welche JTL-Struktur ist führend?
• Welche Artikel dürfen nur read-only geprüft werden?
• Welche Schreibaktionen brauchen Freigabe?
• Welche Readbacks beweisen, dass der Import sauber war?

Im JTL-/ERP-Pilot-Check prüfen wir, welcher Prozess sich zuerst lohnt, welche Datenquellen sauber erreichbar sind und wie ein kontrollierter Freigabeprozess aussehen sollte.

Der wichtigste Punkt bleibt: KI macht JTL-Arbeit nicht unsichtbar. KI macht komplexe JTL-Arbeit nachvollziehbar, skalierbar und kontrollierbar.