Ein Lieferant schickt eine Katalogdatei. Sie ist gültiges XML, sie öffnet sich, sie enthält Preise – und trotzdem steht nach dem Import ein Teil der Produkte ohne ein einziges technisches Merkmal im Shop, weil ihre Klassifikation nicht zu den eigenen Filtern passt. An dieser Stelle trennen sich zwei Fragen, die im Alltag ständig vermischt werden: Wie kommen Katalogdaten von einem Haus ins andere – und was bedeuten sie dort. Für die erste Frage gibt es BMEcat, ein XML-basiertes Austauschformat für Katalogdaten im B2B-Bereich (BME e. V.). Für die zweite gibt es Klassifikationen wie ETIM. Dieser Beitrag zeigt, was die beiden Standards jeweils leisten, wie eine Katalogdatei aufgebaut ist, woran der Import erfahrungsgemäß scheitert und in welcher Reihenfolge sich der Aufbau im eigenen B2B-Shop lohnt.
Zwei Standards, zwei verschiedene Aufgaben
BMEcat beschreibt, wie eine Katalogdatei aufgebaut ist: welche Elemente es gibt, in welcher Reihenfolge sie stehen, welche davon Pflicht sind und wie ein Zielsystem sie zu verarbeiten hat. ETIM beschreibt etwas anderes, nämlich was ein Produkt ist: zu welcher Klasse es gehört und welche Merkmale diese Klasse verlangt. Die beiden Standards konkurrieren nicht, sie liegen übereinander. Der BMEcat-Standard ist ausdrücklich nicht auf ein bestimmtes Klassifikationssystem festgelegt und schlägt auch keine eigenen Klassifikationen vor (BMEcat 2005.2, Kapitel 1.3); er transportiert die Klassifikation, auf die sich zwei Partner geeinigt haben. Wer diese Trennung im Kopf hat, spart sich eine wiederkehrende Diskussion in Katalogprojekten – die Frage nämlich, warum ein sauber eingelesener Katalog die Filterseiten trotzdem leer lässt.
BMEcat ist ein XML basiertes standardisiertes Austauschformat für Katalogdaten im B2B-Bereich.
BME e. V., Bundesverband Materialwirtschaft, Einkauf und Logistik
Der Standard ist alles andere als neu. Version 1.0 wurde im November 1999 in Frankfurt verabschiedet, die fachliche Entwicklung lag beim Fraunhofer-Institut für Arbeitswirtschaft und Organisation sowie den Universitäten Duisburg-Essen und Linz (BME e. V.). Mit Version 1.2, vorgestellt zur CeBIT 2001 in Hannover, setzte sich BMEcat als De-facto-Standard für den Austausch elektronischer Produktkataloge durch (BME e. V.). Version 2005 wurde am 4. November 2005 freigegeben (BME e. V.). Die heute aktuelle Fassung trägt die Nummer 2005.2 (BME e. V.) und in der Versionshistorie der Spezifikation das Datum 1. Oktober 2022 (BMEcat 2005.2). Praktisch heißt das: Ein Importer bekommt Dateien aus mehr als zwei Jahrzehnten Standardgeschichte auf den Tisch, und wer nur eine Fassung liest, scheitert an der ersten Lieferung eines Hauses, das die andere nutzt.
Ein Katalog heißt „export_2026.xml“ und ist trotzdem BMEcat 1.2. Die verbindliche Angabe steht im Wurzelelement der Datei, zusammen mit der Angabe der Transaktion. Beides gehört in die erste Prüfung vor dem Import – vor Zeichensatz, vor Feldlängen, vor allem anderen. Ein Importer, der die Version rät, verarbeitet im Zweifel Felder, die es in dieser Fassung gar nicht gibt, und übergeht welche, die verbindlich sind.
Die drei Transaktionen: was eine Katalogdatei überhaupt tut
Eine BMEcat-Datei ist kein Datenhaufen, sondern eine Ansage. In BMEcat stehen drei Transaktionen zur Verfügung (BMEcat 2005.2, Kapitel 3.1): T_NEW_CATALOG überträgt einen neuen Katalog, T_UPDATE_PRODUCTS aktualisiert Produktdaten, T_UPDATE_PRICES aktualisiert Preisdaten. Die Transaktion steht im Katalogdokument direkt unterhalb des Wurzelelements und bestimmt, welche Datenbereiche überhaupt enthalten sein dürfen; bei einer Preisaktualisierung sind es nur die preisbestimmenden Angaben. Die Anwendung der Aktualisierungs-Transaktionen erlaubt es, das Volumen der zu übertragenden Dokumente zu reduzieren, da bei Änderungen nicht der vollständige Katalog erneut zu übertragen ist (BMEcat 2005.2, Kapitel 3.1).
| Transaktion | Was übertragen wird | Beispieltakt aus der Spezifikation | Fallstrick im Import |
|---|---|---|---|
| T_NEW_CATALOG | Der vollständige Katalog | einmal pro Jahr | Artikel, die fehlen, sind entfallen – das muss der Import als Aussage werten |
| T_UPDATE_PRODUCTS | Geänderte und neue Produkte | alle drei Monate | Der Modus je Produkt entscheidet über Anlegen, Ändern, Löschen |
| T_UPDATE_PRICES | Nur preisbestimmende Angaben | wenn Preisänderungen eintreten | Produktdaten bleiben unberührt; ein Vollimport an dieser Stelle löscht Pflege |
| Ohne Angabe | Nicht vorgesehen | entfällt | Datei zurückweisen statt raten – die Transaktion ist keine Kann-Angabe |
Der Katalogkopfbereich ist für alle drei Transaktionen gleich strukturiert (BMEcat 2005.2, Kapitel 3.2.1). Er trägt die Angaben zur Identifikation und Gültigkeit des Katalogs, zum Ersteller und zum Nutzer sowie Standardwerte, die für alle enthaltenen Produkte gelten – etwa Sprache und Währung. Genau diese Standardwerte werden beim Import gern übersehen. Ein Katalog ohne Währungsangabe je Produkt ist nicht zwangsläufig fehlerhaft; er verlässt sich auf die Angabe aus dem Kopf. Wer den Kopf überspringt und direkt in die Produktschleife einsteigt, erzeugt stille Fehler, die erst in der Rechnung auffallen. Wie eng Katalogpflege und Bestellabwicklung zusammenhängen, zeigt der Beitrag zur EDI-Integration in der Bestellabwicklung.
<?xml version="1.0" encoding="UTF-8"?>
<BMECAT version="2005">
<HEADER>
<CATALOG>
<LANGUAGE default="true">deu</LANGUAGE>
<CATALOG_ID>KAT-2026-01</CATALOG_ID>
<CATALOG_VERSION>004.012</CATALOG_VERSION>
<CURRENCY>EUR</CURRENCY>
</CATALOG>
<SUPPLIER>
<SUPPLIER_ID type="supplier_specific">L-88</SUPPLIER_ID>
<SUPPLIER_NAME>Beispiel Elektrogroßhandel</SUPPLIER_NAME>
</SUPPLIER>
</HEADER>
<!-- Nur Preise: Produktdaten bleiben unberührt -->
<T_UPDATE_PRICES prev_version="004.011">
<PRODUCT mode="update">
<SUPPLIER_PID type="supplier_specific">4711-16A</SUPPLIER_PID>
<PRODUCT_PRICE_DETAILS>
<DATETIME type="valid_start_date"><DATE>2026-10-01</DATE></DATETIME>
<PRODUCT_PRICE price_type="net_customer">
<PRICE_AMOUNT>4.90</PRICE_AMOUNT>
<PRICE_QUANTITY>1</PRICE_QUANTITY>
<LOWER_BOUND>10</LOWER_BOUND>
</PRODUCT_PRICE>
</PRODUCT_PRICE_DETAILS>
</PRODUCT>
</T_UPDATE_PRICES>
</BMECAT>Was ETIM beschreibt: Klasse, Merkmal, Wert, Einheit
Das ETIM-Modell ist ein zweistufiges Klassifikationsmodell (ETIM International). Oben stehen Produktgruppen, darunter Produktklassen, und jede Klasse gehört zu genau einer Gruppe. Die Gruppenebene existiert vor allem zur Verwaltung; die eigentliche Arbeit steckt in der Klasse. Eine Klasse bündelt ähnliche Produkte verschiedener Hersteller und legt fest, welche Merkmale zur Beschreibung gehören. Ein Merkmal wiederum ist durch Bezeichnung, Merkmalstyp, Einheit und Wert beschrieben. Dieser Aufbau ist der Grund, warum eine Filterleiste über ETIM-Daten ohne Sonderlogik funktioniert: Die Werte kommen nicht aus Freitext, sondern aus einer vorgegebenen Liste.
- A – alphanumerisch: eine feste Liste möglicher Werte, etwa Farben oder Bauformen (ETIM International). Im Shop wird daraus eine Auswahlliste, keine Texteingabe.
- L – logisch: eine Ja-Nein-Angabe (ETIM International). Im Shop ein Schalter, der sich sauber filtern lässt.
- N – numerisch: ein einzelner Zahlenwert (ETIM International), der eine Maßeinheit braucht – außer bei Merkmalen der Bauart „Anzahl von …“.
- R – Bereich: zwei Zahlenwerte, die eine Spanne begrenzen (ETIM International). Im Shop der Fall, an dem einfache Importer regelmäßig scheitern, weil sie nur ein Zahlenfeld vorgesehen haben.
Der Umfang ist der Grund, warum eine vollständige Merkmalspflege Projektcharakter hat. Über alle Sektoren zählt das Release ETIM 10.0 159 Produktgruppen, 5.640 Klassen, 17.377 Merkmale, 16.163 Werte und 188 Einheiten (ETIM International). Diese Zahlen beschreiben das Modell, nicht das eigene Sortiment: Ein Elektrogroßhändler berührt davon nur einen Ausschnitt, ein Spezialist noch weniger. Die Aufgabe besteht deshalb nicht darin, ETIM vollständig abzubilden, sondern darin, die Klassen des eigenen Sortiments sauber zu besetzen – und zu wissen, welche Merkmale in diesen Klassen erwartet werden.
Offizielle internationale ETIM-Releases erscheinen etwa alle drei Jahre (ETIM International). Die aktuelle Fassung ETIM 10.0 wurde im Dezember 2024 veröffentlicht (ETIM International) und ist das Ergebnis von insgesamt 5.264 Änderungsanträgen; 119 Klassen kamen neu hinzu (ETIM International). Für ETIM 11.0 lief die Frist zur Einreichung von Änderungsanträgen bis zum 30. Juni 2026, das finale Release ist für den 1. Dezember 2026 geplant (ETIM International). Zwischen den offiziellen Releases gibt es dynamische Zwischenreleases, die bereits veröffentlichte und zur Veröffentlichung freigegebene Klassen enthalten und Unterschiede zum offiziellen Stand über Änderungscodes kennzeichnen (ETIM International).
Zwischen zwei ETIM-Releases entfallen Klassen, entstehen neue und wandern Merkmale. Wer die Klassenkennung am Produkt speichert, ohne das zugehörige Release mitzuführen, kann später nicht mehr sagen, was ein Wert bedeutet hat. Die belastbare Struktur speichert je Produkt drei Angaben: Klassenkennung, Release und Zeitpunkt der Zuordnung. Diese drei Felder kosten beim Aufbau eine Stunde und ersparen beim nächsten Wechsel erfahrungsgemäß Tage an Rekonstruktion.
Das Releaseformat des Modells selbst heißt ETIM IXF und beruht auf XML; es kann mehrere Sprachfassungen in einer einzigen Datei enthalten (ETIM International). Frei verfügbar sind die Kodierungsstruktur und die Systemsprache ETIM English sowie mehrere lokale Sprachfassungen, darunter Deutsch (ETIM International). Für die Praxis ist das wichtig, weil sich die Merkmalsbezeichnungen damit ohne eigene Übersetzung in beiden Sprachfassungen eines Shops ausgeben lassen – die Kennungen sind sprachunabhängig, die Beschriftungen kommen aus dem Modell.
Neben dem Kernmodell gibt es die ETIM Modelling Classes, eine Erweiterung für die Darstellung von Produkten als dreidimensionale Objekte. Bislang umfasst ETIM MC 360 Klassen für häufig modellierte Produkte (ETIM International). Für Händler mit Planungsbezug ist das der Anschluss an die Bauplanung; für alle anderen eine Ebene, die man kennen, aber vorerst nicht besetzen muss.
Die Zuordnung: wo aus Lieferantendaten Shopdaten werden
Die eigentliche Arbeit eines Katalogprojekts ist die Zuordnung, und sie hat zwei Schichten. Die erste ist die Feldzuordnung: Welches Element der Datei füllt welches Feld im Shop. Die zweite ist die Merkmalszuordnung: Welches Merkmal des Lieferanten entspricht welchem Merkmal der Klasse. Die erste Schicht ist in der Regel an einem Tag beschrieben, die zweite braucht Fachwissen aus dem Sortiment. Die Abbildung oben zeigt beide Ausfälle, die dabei entstehen: ein Quellfeld, für das es kein Ziel gibt, und ein Pflichtmerkmal der Klasse, für das kein Wert geliefert wurde. Beides sind keine Fehler der Datei – es sind Ergebnisse, die jemand entscheiden muss.
Identifikation
Lieferantenartikelnummer, Herstellernummer und GTIN sind drei verschiedene Angaben. Der Schlüssel für den Abgleich ist die Nummer des Lieferanten in Verbindung mit dessen Kennung – eine GTIN kann fehlen oder von mehreren Händlern geführt werden.
Klassifikation
Je Produkt wird die Klasse gespeichert, dazu der Name des Klassifikationssystems und dessen Version. Ohne die Version ist die Klassenkennung später nicht mehr eindeutig deutbar.
Merkmale
Merkmalskennung, Wert und Einheit gehören zusammen in eine Zeile. Ein Wert ohne Einheit ist bei numerischen Merkmalen unbrauchbar, eine Einheit ohne Umrechnungsregel ebenso.
Medien und Anlagen
Bilder, Datenblätter und Zeichnungen kommen als Verweise. Ob die Ziele erreichbar sind, sagt die Datei nicht – das muss der Import selbst prüfen, und zwar auf den Inhaltstyp, nicht nur auf den Statuscode.
Version 2005.2 hat an dieser Stelle nachgebessert. Merkmalsnamen eines Produkts dürfen nun bis zu 80 Zeichen lang sein, was eine genauere Bezeichnung von Produktmerkmalen erlaubt (BME e. V.). Außerdem lassen sich Merkmalswerte sowohl als eigene Ausprägung als auch als Referenz auf eine Ausprägung im Klassifikationssystem angeben, in beliebiger Kombination (BME e. V.). Das ist genau die Beweglichkeit, die man braucht, wenn ein Lieferant den größeren Teil seiner Merkmale klassifiziert liefert und den Rest als Freitext. Wo diese Daten dauerhaft gepflegt werden, ist eine eigene Entscheidung: im Shop, in der Warenwirtschaft oder in einem PIM-System. Der Beitrag zur Produktdatenhoheit beschreibt die Abwägung im Detail.
Woran der Import erfahrungsgemäß scheitert
Katalogimporte scheitern selten am XML. Sie scheitern an Annahmen, die in der Datei nicht stehen und die deshalb niemand überprüft hat. Die folgenden sechs Punkte tauchen in Projekten so regelmäßig auf, dass sie in jede Prüfroutine gehören, bevor der erste Datensatz in die Datenbank geschrieben wird.
- Einheiten ohne Umrechnung: Ein Lieferant liefert Millimeter, der nächste Zentimeter. Beide sind korrekt. Ohne Normalisierung auf eine Zieleinheit je Merkmal filtert der Shop zwei Größenordnungen gemeinsam – und liefert Treffer, die niemand nachvollzieht.
- Dezimaltrennzeichen: Ein Komma statt eines Punktes verwandelt 1,5 Meter still in 15 oder in null. Die Prüfung gehört vor die Umwandlung, nicht danach.
- Preisangaben ohne Bezug: Ein Preis ohne Preiseinheit und Mengeneinheit ist keine Zahl, sondern eine Vermutung. Kabel je Meter und Kabel je 100 Meter unterscheiden sich um zwei Nullen.
- Verweise ins Leere: Bild- und Dokumentadressen aus dem Katalog sind oft nur während eines Zeitfensters erreichbar. Ein Statuscode 200 belegt noch kein Bild – erst der Inhaltstyp der Antwort tut das.
- Mehrsprachigkeit: In BMEcat 2005 lassen sich mehrsprachige Kataloge mit einem einzigen Katalogdokument übertragen (BME e. V.). Ein Importer, der die Sprachangabe übergeht, schreibt die zuletzt gelesene Sprachfassung über die erste.
- Entfallene Artikel: Eine Produktaktualisierung löscht nichts von selbst. Wer ausgelistete Ware nicht aktiv stilllegt, verkauft sie weiter – der Beitrag zum Umgang mit nicht lieferbaren Artikeln zeigt die Folgen im Shop.
Die Gegenmaßnahme ist unspektakulär und wirksam: Jeder Katalog läuft zuerst gegen eine Prüfung, die nicht in die Datenbank schreibt, sondern zählt. Wie viele Produkte, wie viele mit Klasse, wie viele mit vollständigem Merkmalssatz, wie viele mit erreichbaren Bildern. Erst wenn diese Zahlen zum Vorlauf passen, folgt der Schreiblauf – und zwar auf einer Testinstanz mit realistischen, aber unkritischen Testdaten. Wer diese Trennung nicht einzieht, lernt den Unterschied zwischen Warnung und Fehler am Produktivsystem.
ETIM xChange: das Format wechselt, das Modell bleibt
Wo ETIM International früher den BMEcat-Standard empfohlen hat, gibt es inzwischen ein eigenes Format: ETIM xChange, einen auf JSON beruhenden Austauschstandard für Produktstammdaten (ETIM International). Version 2.0 wurde am 27. November 2025 offiziell veröffentlicht (ETIM International). Sie bringt unter anderem erweiterte Umweltdatenfelder für Ökobilanzen und Umweltproduktdeklarationen, ein Element für Angaben zu Verpackungsmaterialien und Unterstützung für die Verwaltung von Seriennummern (ETIM International). Das Modell dahinter ändert sich nicht: Klassen, Merkmale, Werte und Einheiten bleiben dieselben.
Für die Planung heißt das nicht, dass BMEcat kurzfristig verschwindet. In einigen Ländern sind nationale Formate weiterhin Branchenstandard, teils neben ETIM xChange und ETIM BMEcat (ETIM International). Parallel dazu ist ETIM seit dem 27. Mai 2024 Teil des GDSN-Stammdatenaustauschstandards von GS1 (ETIM International), sodass sich Klassen, Merkmale, Werte und Einheiten auch über diesen Weg übertragen lassen. Ein Händler, der heute baut, sollte deshalb nicht auf ein Format setzen, sondern die Zuordnung von der Datei trennen: Die Merkmalslogik gehört in den eigenen Datenbestand, das Einlesen in einen austauschbaren Adapter. Wer Kataloge über Ländergrenzen austauscht, trifft im Shop zusätzlich auf die Vorgaben der Geoblocking-Verordnung.
Wer Kataloge von zwanzig Lieferanten bezieht, wird über Jahre beide Wege bedienen. Das ist kein Ausrutscher, sondern der Normalfall im Übergang. Wichtig ist nur, dass beide Wege in dieselbe interne Struktur münden und dass die Prüfung dieselbe bleibt. Zwei getrennte Importstrecken mit je eigener Merkmalslogik sind die Konstruktion, die sich später nur mit hohem Aufwand zurückbauen lässt.
Der Shop als Katalogsender
Bisher ging es um den Import. Die Gegenrichtung wird häufig vergessen, obwohl sie im B2B regelmäßig verlangt wird: Ein gewerblicher Kunde möchte den Katalog seines Lieferanten in seinem eigenen Beschaffungssystem sehen. Dafür gibt es zwei Wege, und sie werden oft verwechselt. Der eine ist die Katalogdatei, die der Einkauf einliest. Der andere ist die Sitzung im fremden System, bei der ein Einkäufer aus seiner Beschaffungsanwendung heraus in den Shop springt und den Warenkorb zurückgibt – beschrieben im Beitrag zu Punchout-Katalogen mit OCI und cXML. Punchout ist die Sitzung, BMEcat die Datei davor. Zu den externen Katalogen zählt BMEcat 2005 diese Wege ausdrücklich mit (BME e. V.).
Für den Export gelten dieselben Anforderungen wie für den Import, nur mit vertauschten Rollen. Der Shop muss je Kunde entscheiden können, welches Sortiment und welche Preise in die Datei gehen, er muss Klassifikation und Merkmale mitliefern, und er muss den Katalog versionieren. Wer dabei einen Ersatzteil- oder Zubehörbezug führt, sollte die Produktreferenzen mitgeben, weil sie im Zielsystem sonst verloren gehen – wie eine solche Struktur aussieht, zeigt der Beitrag zum Ersatzteilkatalog mit Baugruppensuche. Ein Katalogexport, der nur Nummer, Text und Preis enthält, erfüllt den Buchstaben und verfehlt den Zweck: Im Zielsystem findet dann niemand das Produkt, weil dort keine Merkmale zum Filtern ankommen.
Reihenfolge einer Einführung
Katalogprojekte scheitern selten an der Technik und oft an der Reihenfolge. Wer mit dem Importer anfängt, baut gegen eine Datenlage, die er noch nicht kennt. Die folgende Abfolge hat sich in Projekten bewährt, weil jeder Schritt eine Entscheidung abschließt, bevor der nächste Aufwand entsteht.
- Bestand aufnehmen: Welche Lieferanten liefern in welchem Format und in welcher Fassung. Drei echte Dateien sagen mehr als jede Zusage am Telefon.
- Klassen abgrenzen: Welche Klassen des Klassifikationssystems berührt das eigene Sortiment. Diese Liste ist der Umfang des Projekts, nicht der Gesamtumfang des Modells.
- Zielstruktur festlegen: Klasse, Release, Merkmal, Wert, Einheit als eigene Felder – nicht als Freitext und nicht als zusammengesetzter Block in einer einzigen Spalte.
- Zuordnung schreiben: Je Lieferant eine nachvollziehbare Zuordnungsdatei, die im Betrieb ohne Programmierung gepflegt werden kann.
- Prüfung vor dem Schreiben: Zählen statt schreiben, mit festen Schwellen. Ein Lauf, der unter die Schwelle fällt, wird abgebrochen und gemeldet.
- Turnus vereinbaren: Wer liefert wann, in welcher Transaktion, und wer entscheidet über offene Zuordnungen. Ohne benannte Zuständigkeit bleibt die Pflege liegen.
Der Aufwand verteilt sich dabei anders, als viele erwarten. Die Programmierung des Einlesens ist der kleinere Teil; die Abstimmung der Merkmale mit dem Einkauf ist der größere. Genau deshalb lohnt es sich, früh mit einem Lieferanten und dreißig Klassen zu beginnen statt mit zwanzig Lieferanten und dem gesamten Sortiment. Wir begleiten diesen Aufbau in Shopware-Projekten genauso wie in gewachsenen Eigenentwicklungen; die Reihenfolge bleibt dieselbe.
Was der Betrieb danach verlangt
Ein Katalogimport ist kein Projekt mit Enddatum, sondern ein Verfahren. Danach fällt regelmäßige Arbeit an: neue Lieferdateien, wechselnde Klassenzuordnungen, ein Releasewechsel des Klassifikationssystems alle paar Jahre. Die Frage, wer die offenen Zuordnungen entscheidet, ist deshalb wichtiger als die Frage, welche Bibliothek das XML liest. In der Praxis bewährt sich eine kurze Liste offener Punkte je Lauf, die an eine benannte Person geht – nicht in ein Protokoll, das niemand öffnet.
Für die Lücken, die auch nach einer sorgfältigen Zuordnung bleiben, gibt es zwei Wege. Der erste ist die Rückfrage beim Lieferanten; sie ist der sauberere, dauert aber. Der zweite ist die Anreicherung im eigenen Haus, bei der fehlende Merkmale aus Datenblättern und Beschreibungen abgeleitet und anschließend geprüft werden. Wie das kontrolliert abläuft, beschreiben der Beitrag zur automatisierten Datenanreicherung und unsere Leistungsseite zur Anreicherung von Produktdaten. Wichtig ist in beiden Fällen die Herkunftsangabe je Wert: geliefert, abgeleitet oder manuell gesetzt. Wer diese Unterscheidung nicht führt, kann bei der nächsten Lieferung nicht entscheiden, welcher Wert gewinnt.
Der wirtschaftliche Kern ist nüchtern. Ein sauberer Katalogaustausch erhöht keinen Umsatz auf Knopfdruck; er senkt den Aufwand je gepflegtem Artikel und macht Sortimente überhaupt erst filterbar. In Häusern mit fünfstelliger Artikelzahl ist das der Unterschied zwischen einem Shop, in dem Kunden ein Produkt über Merkmale finden, und einem Katalog, den man nur mit der Artikelnummer bedienen kann. Wer den B2B-Bereich ernsthaft ausbaut, kommt an dieser Grundlage in der Regel nicht vorbei.
Dieser Beitrag stützt sich auf die Spezifikation BMEcat 2005.2 des BME e. V. sowie auf die BMEcat-Seiten des Verbandes zu Entstehung, Versionen und Downloads, und auf die Veröffentlichungen von ETIM International zu Modellaufbau, Releasepolitik, Austauschformat und den Releasemeldungen zu ETIM 10.0, ETIM 11.0, ETIM xChange 2.0 und der Aufnahme von ETIM in das GDSN-Netzwerk von GS1. Die Zahlen zum Umfang von ETIM 10.0 stammen aus der Statistiktabelle, die ETIM International zur Releasemeldung veröffentlicht hat, und beziehen sich auf die Spalte über alle Sektoren. Zur Marktverbreitung der beiden Standards liegen überwiegend Angaben von Beteiligten vor; belastbare Erhebungen sind uns nicht bekannt, weshalb hier bewusst keine Verbreitungsquote genannt wird.
In der Regel ja, sobald mehr als zwei oder drei Lieferanten im Spiel sind. Eine Tabelle ist ein Ergebnis, kein Format: Spaltenreihenfolge, Kopfzeilen und Trennzeichen ändern sich von Lauf zu Lauf, und niemand schuldet Ihnen Beständigkeit. BMEcat legt Struktur, Pflichtangaben und die Bedeutung der Übertragung fest (BME e. V.), sodass ein Importer über Jahre gegen dieselbe Erwartung arbeiten kann. Bei einem einzigen Lieferanten mit stabiler Tabelle kann der Aufwand dagegen erfahrungsgemäß größer sein als der Nutzen.
BMEcat ist das Transportformat, ETIM die Klassifikation. BMEcat legt fest, wie die Datei aufgebaut ist; ETIM legt fest, welche Klasse ein Produkt hat und welche Merkmale dazugehören. Der BMEcat-Standard ist dabei nicht auf ein bestimmtes Klassifikationssystem festgelegt (BMEcat 2005.2, Kapitel 1.3), sondern transportiert das System, auf das sich zwei Partner geeinigt haben. Praktisch heißt das: Eine BMEcat-Datei kann ETIM-Merkmale enthalten, muss es aber nicht – und genau das ist die Angabe, die vor jedem Projekt geklärt gehört.
Offizielle internationale Releases erscheinen etwa alle drei Jahre (ETIM International); ETIM 10.0 stammt aus dem Dezember 2024, ETIM 11.0 ist für den 1. Dezember 2026 geplant (ETIM International). Dazwischen gibt es dynamische Zwischenreleases (ETIM International). Für den Shop bedeutet das vor allem eine Konstruktionsanforderung: Speichern Sie zur Klassenkennung auch das Release und den Zeitpunkt der Zuordnung. Dann ist ein Wechsel eine Migration mit bekanntem Umfang statt einer Suche im Dunkeln.
Das Einlesen lässt sich automatisieren, die Entscheidung über offene Zuordnungen typischerweise nicht vollständig. Ein Lauf endet erfahrungsgemäß mit einer Restmenge: Quellfelder ohne Ziel und Pflichtmerkmale ohne Wert. Diese Restmenge sollte klein, sichtbar und einer Person zugeordnet sein. Ein Verfahren, das sie verschweigt, erzeugt keine Automatisierung, sondern stille Lücken im Sortiment, die erst beim ausbleibenden Suchtreffer auffallen.
Das hängt an der Zahl der Ausgabekanäle, nicht allein an der Artikelzahl. Solange der Shop das einzige Ziel ist, kann die Pflege dort liegen. Sobald Kataloge exportiert, weitere Vertriebswege bedient oder Druckdaten erzeugt werden, wandert die Pflege in der Regel in ein eigenes System, weil sonst der Shop zur Quelle für alles wird. Die Abwägung samt Übergangsweg steht in unserer Übersicht zu Schnittstellen und Systemanbindung.
Mit drei echten Lieferantendateien und einer Liste der Klassen, die Ihr Sortiment berührt. Daraus ergibt sich der Umfang, und daraus ergibt sich, ob der erste Schritt ein Importer, eine Merkmalsstruktur oder ein Exportweg ist. Diese Vorklärung kostet wenige Stunden und verhindert die kostspielige Variante: einen fertigen Importer für ein Datenmodell, das die Merkmale gar nicht aufnehmen kann. Wenn Sie das gemeinsam durchgehen möchten, sprechen Sie uns an – wir sehen uns die Dateien an und ordnen den Aufwand ein.