Lieferantendaten importieren und normalisieren

Warum ein Lieferantenimport ein Normalisierungsproblem ist, kein Datei-Upload: Feldmapping, Werttransformation, Einheiten, Kategorien-Mapping, Variantengruppierung, geplante Synchronisation - und wie PIMSuite das umsetzt.

Ein Lieferantenimport ist selten nur ein Dateiimport. Zwei Lieferanten können dasselbe Produkt mit unterschiedlichen SKUs, Feldnamen, Einheiten, Kategorien, Währungen und Datenqualität liefern. Die eigentliche Aufgabe besteht darin, externe Daten wiederholbar in ein stabiles internes Produktmodell zu übersetzen, ohne bei jeder Aktualisierung erneut manuell aufzuräumen.

PIMSuite bildet diesen Prozess als wiederverwendbare Importpipeline ab. Für Standard-Dateien und -Feeds reicht das direkt; wenn ein Lieferant oder ein ERP eine ungewöhnliche Authentifizierung, Vorverarbeitung oder Abstimmungslogik braucht, erweitert Applosive die Ingestion-Schicht individuell darum herum.

Quellschema vs. kanonisches Modell

Lieferant A
ArtikelNr | Farbe | VK_EK | Gewicht

Lieferant B
SKU | Colour | CostPrice | NetWeight
          ↓
kanonisches PIM-Modell
sku | color | cost | weight

Lieferantenschemata sollten als Quellformate behandelt werden, nicht als euer internes Datenmodell. Das ist derselbe Grundsatz wie beim Produktkatalog: PIMSuite schreibt kein festes Format vor - das Format eures Lieferanten ist der Ausgangspunkt, nicht das Ziel.

Ein typischer Onboarding-Ablauf

  1. Beispiel-Feed vom Lieferanten besorgen
  2. Schema sichten
  3. stabile Identifikatoren festlegen
  4. Felder zuordnen
  5. Werte und Einheiten normalisieren
  6. Kategorien zuordnen
  7. an einer Teilmenge testen
  8. Fehler prüfen
  9. Aktualisierungsverhalten festlegen
  10. wiederkehrende Synchronisation einrichten

Die meisten Probleme entstehen nicht beim ersten Import, sondern beim zweiten und dritten - wenn sich das Schema leicht ändert oder ein Randfall auftaucht, der im Testlauf nicht vorkam.

Jedes Format, jede Struktur

Importiert CSV, XML, JSON und XLSX. PIMSuite liest die Datei, zeigt eine Vorschau der Spalten mit Beispielwerten und führt euch durch das Mapping.

Identifikatoren: die wichtigste Entscheidung im ganzen Prozess

Welches Feld erkennt bei jedem künftigen Import dasselbe Produkt wieder? Mögliche Kandidaten sind die Lieferanten-SKU, eine Hersteller-Teilenummer, GTIN/EAN oder eine interne Zuordnungs-ID. Die falsche Wahl ist einer der schnellsten Wege zu Dubletten oder dazu, versehentlich den falschen Datensatz zu überschreiben.

PIMSuites Duplikatbehandlung (siehe unten) arbeitet auf Basis der SKU als Übereinstimmungsschlüssel. Eine konfigurierbare Auswahl zwischen mehreren möglichen Identifikatoren - etwa GTIN statt SKU, oder eine Kombination aus beiden - ist darüber hinaus heute kein eigener Konfigurationsschritt; welches Feld als Schlüssel dient, sollte vor dem ersten produktiven Import bewusst festgelegt werden.

Vier unterschiedliche Mapping-Probleme

Was oft als ein Problem behandelt wird, sind eigentlich vier:

1. Feldmapping - ArtikelNr → sku

2. Wertnormalisierung - navy, Navy Blue, Dunkelblau → einheitlich navy_blue

3. Einheitenumrechnung - 1250 g1.25 kg

4. abgeleitete Werte - cost * 1.35 → berechnete Preisbasis

Spaltenmapping mit Formel-Transformationen

Ordnet jede Lieferantenspalte dem richtigen Feld in eurem Schema zu. Für Spalten, die Transformation erfordern, schreibt eine Formel in JavaScript-ähnlicher Syntax. Ein Beispiel:

Lieferantenwert: "1.250 g"

Transformation: parse_decimal(value) / 1000

Ergebnis: 1.25 kg

PIMSuite wertet die Formel gegen reale Beispielwerte aus, damit ihr vor dem vollständigen Import prüfen könnt. Das ist mehr als Komfort: Ein Transformationsfehler, der bei einer einzelnen Beispielzeile harmlos aussieht, kann 50.000 Produkte beschädigen, wenn er ungeprüft auf den ganzen Feed läuft.

KI-gestütztes Mapping

Lieferantenspalte:
"Net_Weight"

Beispielwerte:
"1.25 kg"
"750 g"
"2 kg"

KI schlägt vor:
→ weight
→ auf kg normalisieren

Mensch bestätigt

PIMSuite analysiert die Beispielwerte in jeder Spalte und schlägt das passende Feld sowie die passende Formel vor. Das reduziert den Einrichtungsaufwand für neue Lieferantenintegrationen von Stunden auf Minuten. Wichtig ist der Grundsatz dahinter: KI soll Mapping-Entscheidungen beschleunigen, nicht euer kanonisches Schema stillschweigend selbst festlegen - ihr bestätigt jeden Vorschlag, bevor er produktiv läuft.

Kategorien-Mapping

Lieferant:
Home > Kitchen > Coffee Machines

Intern:
Haushalt > Küchengeräte > Kaffeemaschinen

Wenn ein Lieferant eigene Kategorienamen verwendet, zeigt PIMSuite einen integrierten Mapping-Workflow: jede Lieferantenkategorie sehen, in eurer Taxonomie suchen und zuordnen. KI-Vorschläge beschleunigen das erheblich bei langen Kategorielisten, und einmal festgelegte Zuordnungen gelten für künftige Importe desselben Lieferanten weiter. Der Grundsatz ist derselbe wie beim Datenmodell insgesamt: Die Taxonomie des Lieferanten sollte nicht automatisch zu eurer eigenen werden.

Variantengruppenregeln

Lieferantendateien listen oft jede Größe und Farbe als separate Zeile:

TSHIRT-BLK-S
TSHIRT-BLK-M
TSHIRT-BLK-L

Ein Muster erkennt darin das Hauptprodukt TSHIRT-BLK mit der Achse Größe = S/M/L. Variantengruppenregeln lassen euch solche SKU-Muster definieren - PIMSuite gruppiert beim Import automatisch passende Zeilen in Variantengruppen, sodass euer Katalog ohne manuelle Arbeit organisiert bleibt. Ein SKU-Muster ist aber nicht immer zuverlässig: Manche Lieferanten mischen Farb- und Größenangaben unterschiedlich, oder ein Hauptattribut widerspricht sich zwischen Zeilen. Neue Variantengruppenregeln lohnt es sich deshalb an einer Teilmenge zu testen, bevor sie auf den vollständigen Feed laufen.

Ein Produkt, mehrere Lieferanten

kanonisches Produkt
  ├─ Lieferant A
  │    Kosten: 12,50 €
  │    Bestand: 80
  │    Lieferzeit: 2 Tage
  └─ Lieferant B
       Kosten: 11,90 €
       Bestand: 0
       Lieferzeit: 14 Tage

Jeder Lieferant ist ein eigener Datensatz in PIMSuite mit Kontaktdaten, Adresse, Rabattsätzen, Lieferzeiten und Mindestbestellmengen. Lieferantendaten sind mit Produktdatensätzen verknüpft: Pro-Produkt-Lieferantenzuordnungen erfassen Einkaufspreis, Währung, Lagerbestand und bevorzugten Lieferanten. Der wichtige Grundsatz: Nur weil zwei Lieferanten dasselbe Produkt führen, entstehen daraus keine zwei Produkte - welche Kosten dabei als Berechnungsgrundlage für die Preisgestaltungs-Engine dienen, legt ihr über eine Kostenquellen-Strategie fest.

Importmodi und Duplikatbehandlung

Wählt das Verhalten jedes Imports: nur neue Produkte anlegen, nur bestehende aktualisieren, oder beides. Konfiguriert, was bei einer doppelten SKU passiert - den bestehenden Datensatz aktualisieren, überspringen oder einen Fehler auslösen. Wann welcher Modus sinnvoll ist:

  • Erstmalige Katalogmigration → Anlegen + Aktualisieren
  • Täglicher Bestandsfeed → nur Aktualisieren
  • Feed für neues Sortiment → nur Anlegen
  • Strenger Stammdaten-Workflow → Duplikat = Fehler

Wenn ein Produkt aus dem Feed verschwindet

Ein oft übersehenes Problem: Ein Produkt, das gestern im Lieferanten-Feed stand, fehlt heute. Das kann viele Gründe haben - vorübergehend nicht verfügbar, eingestellt, der Lieferant führt es nicht mehr, oder der Feed ist schlicht unvollständig. Ein fehlendes Produkt sollte nie ohne bewusste Richtlinie automatisch gelöscht werden.

PIMSuites Importmodi bestimmen heute, was mit Zeilen passiert, die im Feed vorhanden sind (Anlegen/Aktualisieren/Duplikatbehandlung). Eine dedizierte, konfigurierbare Regel dafür, was mit zuvor importierten Produkten passiert, die im aktuellen Lauf fehlen - etwa automatisch auf Lagerbestand null setzen, erst nach mehreren aufeinanderfolgenden fehlenden Importen deaktivieren, oder grundsätzlich manuell prüfen - ist heute keine eigenständige Funktion. Bis es eine gibt, empfiehlt sich, das Verhalten bei Einrichtung des Imports bewusst zu entscheiden, statt sich auf ein implizites Standardverhalten zu verlassen.

Geplante Importe

Legt einen Cron-Zeitplan fest, und Lieferantendaten aktualisieren euren Katalog automatisch. PIMSuite ruft die aktuelle Datei von einer URL ab, führt den gemappten Import aus und meldet Fehler.

Eine zuverlässige Kette braucht darüber hinaus Antworten auf: Was, wenn die URL einen 404 zurückgibt? Was, wenn eine Datei plötzlich 10 statt 50.000 Zeilen enthält? Was, wenn sich die Spaltenüberschriften ändern? Sinnvolle Plausibilitätsprüfungen wie "Lauf abbrechen, wenn die Zeilenzahl gegenüber dem letzten erfolgreichen Import um mehr als 80 % einbricht" oder "Lauf nicht als erfolgreich markieren, wenn die Fehlerquote einen Schwellenwert überschreitet" sind heute keine eigenständige Funktion von PIMSuite - der bestehende Mechanismus ist die zeilengenaue Fehlerprotokollierung pro Lauf (siehe unten), nicht ein automatischer Vorab-Abbruch bei auffälligen Anomalien.

Medienimport

Ladet Produktbilder direkt von URLs in Lieferantendaten herunter. Konfiguriert Authentifizierungs-Header, wenn das CDN des Lieferanten diese erfordert. Bilder werden per Hash dedupliziert - ein erneuter Import eines Feeds fügt keine doppelten Dateien hinzu. Details zur Deduplizierung selbst - SHA-256 kombiniert mit Perceptual Hashing - stehen auf der Medien & DAM-Seite.

Zeilengenaue Fehlerprotokollierung

Zeile 2184
Feld: weight
Wert: "ca. 12kg"
Fehler: numerischer Wert erwartet

Zeile 429
Feld: color
Wert: "Blu"
Fehler: keiner erlaubten Option zugeordnet

Jeder Importlauf erzeugt ein detailliertes Fehlerprotokoll. Seht genau, welche Zeilen fehlgeschlagen sind, welches Feld das Problem verursacht hat und welcher Wert ungültig war. "Import fehlgeschlagen" allein ist nutzlos - handlungsfähige Fehler brauchen Zeile, Feld, Quellwert und Grund.

Die meisten Fehler, die dabei auftauchen, lassen sich in wenige Gruppen einteilen: strukturelle Probleme (fehlende Spalte, defekte CSV/XML-Datei), Validierungsfehler (ungültige GTIN, ungültige Zahl), Mapping-Fehler (unbekannte Kategorie, unbekannte Option) und Download-Fehler (Medien-URL nicht erreichbar). Diese Einteilung hilft beim Beheben, auch wenn sie im Fehlerprotokoll selbst nicht als eigenes Feld ausgewiesen ist - an der Quelle korrigieren und sauber re-importieren.

Herkunft nachvollziehen

PIMSuite protokolliert jede Feldänderung mit Nutzer, Zeitstempel sowie altem und neuem Wert - das gilt auch für Änderungen, die aus einem Import stammen. Damit lässt sich im Nachhinein grob nachvollziehen, wann und wodurch sich ein Wert zuletzt geändert hat. Eine vollständige Herkunftskette pro Feld - genau welcher Lieferant, welche Feed-Datei, welche Zeile und welcher ursprüngliche Rohwert einen gespeicherten Wert erzeugt haben - ist darüber hinaus heute keine eigenständige, durchgängig abrufbare Funktion.

Wie PIMSuite das umsetzt

PIMSuite importiert CSV-, XML-, JSON- und XLSX-Lieferantendateien mit flexiblem Spaltenmapping, formelbasierten Transformationen mit Live-Vorschau, KI-gestützten Mapping- und Kategorievorschlägen, konfigurierbaren Importmodi und Duplikatbehandlung, geplanter Synchronisation per Cron, Variantengruppierung nach SKU-Muster, Medienimport mit Hash-Deduplizierung und zeilengenauer Fehlerprotokollierung pro Lauf. Für Standard-Feeds ist das direkt einsatzbereit; für ungewöhnliche Quellen lässt sich die Pipeline individuell erweitern.

Kontakt aufnehmen

Ein Prozess, den Ihre aktuelle Software nicht abbilden kann?

Erzählen Sie uns, womit Sie arbeiten und wo es hakt. Wir sagen Ihnen ehrlich, ob individuelle Entwicklung sinnvoll ist.

PIMSuite entdecken