Drei Lieferanten, drei XML-Formate, null Kompatibilität: Wer Produktdaten in Magento 2 importieren will, kennt das Problem. Der Standard-Importer von Magento Open Source und Adobe Commerce akzeptiert XML zwar prinzipiell, erwartet aber exakt die Magento-Tabellenstruktur mit den internen Attributnamen. Liefern Hersteller Dateien mit eigenen Knotennamen, abweichender Hierarchie oder kryptischen Feldbezeichnungen wie ART_NR statt sku, scheitert der Import schon beim Hochladen. Die Lösung heißt XSLT – und spart Händlern den teuren Umweg über eine Middleware.
Warum der native Magento 2 Import an Lieferanten-XML scheitert
Die hauseigene Import-Funktion unter System → Data Transfer → Import ist auf CSV und XML mit festem Schema ausgelegt. Jede Zeile braucht die Magento-Spaltenköpfe, jede Entität muss den bekannten Entity-Types entsprechen. Supplier-XMLs folgen dieser Logik selten: Produktattribute heißen anders, Kategorien stecken in verschachtelten Knoten, Preise liegen in Kundengruppen-Blöcken, die Magento nicht kennt. Dasselbe gilt in die andere Richtung – wer Daten an ERP, CRM oder Warenwirtschaft exportiert, muss oft fremde Formate bedienen.
XSLT (Extensible Stylesheet Language Transformations) schließt genau diese Lücke. Der Shopbetreiber definiert ein Template, das die eingehende XML-Struktur vor dem Import in das Magento-Format umbaut – oder beim Export aus Magento-Daten das Zielformat des Partnersystems erzeugt. Umbenennen, Umstrukturieren, Filtern: Alles läuft in einer Transformationsregel statt in einem externen Skript.
Wie funktioniert der XML-Import mit XSLT in der Praxis?
Die technische Basis ist simpel: XSLT ist eine W3C-standardisierte Sprache, die XML-Dokumente regelbasiert in andere XML-Strukturen überführt. Konkret ordnet das Template jedem Lieferanten-Knoten ein Magento-Attribut zu. Aus <Artikelnummer> wird sku, aus <VK_Brutto> wird price, verschachtelte Varianten-Knoten werden zu konfigurierbaren Produkten mit Simple-Children aufgelöst. Wer XSLT nicht selbst schreiben möchte, greift zu Extensions, die die Transformation visuell mappen – etwa die Improved Import & Export Extension von Firebear Studio, die für Adobe Commerce und Open Source gleichermaßen verfügbar ist und XML-Importjobs inklusive Cron-Scheduling und SFTP-Anbindung abdeckt.
Ein typischer Workflow für den Shop-Alltag sieht so aus: Der Lieferant legt die aktuelle XML-Datei per FTP auf einem Server ab. Der Importjob läuft nächtlich per Cron, wendet die XSLT-Vorlage an und aktualisiert Preise, Bestände und neue Artikel automatisch. Händler mit drei, vier Lieferanten legen pro Quelle ein eigenes Template an – danach läuft der Prozess ohne manuelle Eingriffe.
Was das für Shopbetreiber konkret bedeutet
Die Alternative zur XSLT-Route ist bislang meist eine Middleware wie ein PIM-System oder ein individuell programmierter Konverter – Kostenpunkt schnell vier- bis fünfstellig, plus laufende Wartung bei jeder Formatänderung des Lieferanten. Für Händler ab einer Million Jahresumsatz, die Sortimente mit mehreren tausend SKUs aus wechselnden Quellen befüllen, lohnt der direkte Weg: schnellere Time-to-Shelf bei neuen Lieferanten, keine Excel-Zwischenschritte, weniger Fehlerquellen durch Copy-Paste-Pflege.
Ehrlichkeit gehört dazu: XSLT hat eine Lernkurve. Wer noch nie XML-Stylesheets geschrieben hat, braucht für das erste Template ein bis zwei Tage Einarbeitung oder externe Hilfe. Und Extensions wie die von Firebear kosten je nach Lizenz einige hundert Euro jährlich. Gegenüber einer Middleware-Betreibergesellschaft bleibt das ein Bruchteil.
Der nächste Lieferant mit exotischem Datenformat ist nur eine Frage der Zeit. Händler, die ihren Importprozess jetzt auf XSLT-Basis aufsetzen, schalten künftig jede neue Quelle mit einem Template frei – statt bei jeder Onboarding-Anfrage erst einmal die IT-Abteilung zu bemühen. Wer heute noch CSV-Dateien von Hand umbaut, verliert pro Lieferantenwechsel Tage, die der Wettbewerb für die Sortimentspflege nutzt.