BMEcat: Aufbau, Versionen und Praxis im Katalogmanagement

Was ist BMEcat?

BMEcat ist ein XML-Standard für den Austausch elektronischer Produktkataloge zwischen Lieferanten und einkaufenden Unternehmen. Herausgeber ist der Bundesverband Materialwirtschaft, Einkauf und Logistik (BME).

Ein Lieferant beschreibt in einer BMEcat-Datei sein Sortiment: Artikelnummern, Texte, Preise, Bestelleinheiten, Merkmale und Verweise auf Bilder. Das einkaufende Unternehmen liest die Datei in sein Katalogsystem ein. Beide Seiten müssen sich so nicht auf ein eigenes Format einigen. Im Katalogmanagement ist BMEcat deshalb das übliche Austauschformat, wenn Katalogdaten als Datei geliefert werden.

BMEcat regelt nur die Katalogdaten. Bestellung, Auftragsbestätigung und Rechnung sind nicht Teil des Standards. Dafür gibt es andere Formate und Schnittstellen.

BMEcat 1.2 und BMEcat 2005 im Vergleich

In der Praxis treffen Sie auf zwei Versionen: BMEcat 1.2 aus dem Jahr 2001 und BMEcat 2005. Beide sind im Umlauf. Viele Lieferanten liefern weiterhin 1.2, weil ihre Exportwerkzeuge darauf eingestellt sind. Ein Katalogsystem sollte deshalb beide Versionen lesen können.

Die beiden Versionen sind nicht kompatibel. Der wichtigste Unterschied für den Import: Aus dem Artikel wurde das Produkt. Die Elemente heißen in BMEcat 2005 anders, die Struktur ist aber ähnlich geblieben.

Merkmal	BMEcat 1.2	BMEcat 2005
Schema	DTD	XML Schema (XSD) mit Namensraum
Katalogposition	`ARTICLE`	`PRODUCT`
Artikelnummer des Lieferanten	`SUPPLIER_AID`	`SUPPLIER_PID`
Preis	`ARTICLE_PRICE`	`PRODUCT_PRICE`, zusätzlich Preisformeln
Sprachen	Eine Sprache je Katalogdatei	Mehrere Sprachen in einer Datei
Konfigurierbare Produkte	Nicht vorgesehen	Vorgesehen
Logistikdaten	Kein eigener Bereich	Eigener Bereich für Logistikangaben
Transaktionen	`T_NEW_CATALOG`, `T_UPDATE_PRODUCTS`, `T_UPDATE_PRICES` in beiden Versionen

Welche Version sollten Sie verlangen? Wenn Sie mehrsprachige Kataloge oder ETIM-Daten nach der Richtlinie von ETIM International brauchen, führt der Weg zu BMEcat 2005. Für einfache Sortimente mit einer Sprache reicht 1.2 oft aus. Legen Sie die Version in Ihrer Lieferantenrichtlinie fest und nennen Sie dort auch die Pflichtfelder.

Aufbau einer BMEcat-Katalogdatei

Eine BMEcat-Datei besteht aus zwei Teilen: dem Kopf (HEADER) und genau einer Transaktion. Die Transaktion bestimmt, was das Zielsystem mit den Daten tun soll.

HEADER: Wer liefert was an wen

Der Kopf enthält die Angaben zum Katalog: Katalog-ID, Version, Sprache und Standardwährung. Dazu kommen der Lieferant und das einkaufende Unternehmen. Katalog-ID und Version sind für den Import wichtig. An ihnen erkennt das Zielsystem, ob eine Datei einen bestehenden Katalog ersetzt oder aktualisiert.

Die drei Transaktionen

T_NEW_CATALOG: überträgt den vollständigen Katalog. Das Zielsystem ersetzt den bisherigen Stand.
T_UPDATE_PRODUCTS: überträgt nur geänderte Positionen. Jede Position ist als neu, geändert oder gelöscht gekennzeichnet.
T_UPDATE_PRICES: überträgt nur neue Preise zu vorhandenen Positionen.

ARTICLE bzw. PRODUCT: die Katalogposition

Das folgende Beispiel zeigt eine gekürzte Datei in BMEcat 1.2 mit einem Artikel. Die Werte sind frei gewählt.

<?xml version="1.0" encoding="UTF-8"?>
<BMECAT version="1.2">
  <HEADER>
    <CATALOG>
      <LANGUAGE>deu</LANGUAGE>
      <CATALOG_ID>BEISPIEL-KATALOG</CATALOG_ID>
      <CATALOG_VERSION>001.000</CATALOG_VERSION>
      <CATALOG_NAME>Beispielkatalog Betriebsbedarf</CATALOG_NAME>
      <CURRENCY>EUR</CURRENCY>
    </CATALOG>
    <BUYER>
      <BUYER_NAME>Beispiel Einkauf GmbH</BUYER_NAME>
    </BUYER>
    <SUPPLIER>
      <SUPPLIER_NAME>Beispiel Lieferant GmbH</SUPPLIER_NAME>
    </SUPPLIER>
  </HEADER>
  <T_NEW_CATALOG>
    <ARTICLE>
      <SUPPLIER_AID>4711-A</SUPPLIER_AID>
      <ARTICLE_DETAILS>
        <DESCRIPTION_SHORT>Schutzhandschuh Nitril, Größe 9</DESCRIPTION_SHORT>
        <DESCRIPTION_LONG>Chemikalienschutzhandschuh aus Nitril, Länge 33 cm.</DESCRIPTION_LONG>
        <MANUFACTURER_AID>NH-33-9</MANUFACTURER_AID>
        <MANUFACTURER_NAME>Beispiel Hersteller</MANUFACTURER_NAME>
      </ARTICLE_DETAILS>
      <ARTICLE_ORDER_DETAILS>
        <ORDER_UNIT>PR</ORDER_UNIT>
        <CONTENT_UNIT>PR</CONTENT_UNIT>
        <NO_CU_PER_OU>1</NO_CU_PER_OU>
        <PRICE_QUANTITY>1</PRICE_QUANTITY>
        <QUANTITY_MIN>12</QUANTITY_MIN>
      </ARTICLE_ORDER_DETAILS>
      <ARTICLE_PRICE_DETAILS>
        <ARTICLE_PRICE price_type="net_customer">
          <PRICE_AMOUNT>2.40</PRICE_AMOUNT>
          <PRICE_CURRENCY>EUR</PRICE_CURRENCY>
          <TAX>0.19</TAX>
          <LOWER_BOUND>1</LOWER_BOUND>
        </ARTICLE_PRICE>
      </ARTICLE_PRICE_DETAILS>
      <MIME_INFO>
        <MIME>
          <MIME_TYPE>image/jpeg</MIME_TYPE>
          <MIME_SOURCE>4711-a.jpg</MIME_SOURCE>
          <MIME_PURPOSE>normal</MIME_PURPOSE>
        </MIME>
      </MIME_INFO>
    </ARTICLE>
  </T_NEW_CATALOG>
</BMECAT>

Die wichtigsten Elemente einer Position:

SUPPLIER_AID: die Artikelnummer des Lieferanten. Sie ist der Schlüssel der Position und muss im Katalog eindeutig sein. In BMEcat 2005 heißt das Element SUPPLIER_PID.
DESCRIPTION_SHORT: der Kurztext. Er erscheint in Trefferlisten und später in der Bestellung. Der Langtext steht in DESCRIPTION_LONG.
ORDER_UNIT: die Bestelleinheit als Code, zum Beispiel C62 für Stück oder PR für Paar. CONTENT_UNIT und NO_CU_PER_OU beschreiben, was in einer Bestelleinheit enthalten ist.
ARTICLE_PRICE: der Preis mit Preisart, Betrag, Währung und Steuersatz. Die Preisart steht im Attribut price_type, etwa net_customer für den kundenspezifischen Nettopreis. Staffelpreise entstehen durch mehrere Preise mit unterschiedlichem LOWER_BOUND.
MIME: Verweise auf Bilder, Datenblätter und andere Dateien. Die Datei selbst liegt nicht im XML. MIME_SOURCE nennt nur den Dateinamen oder die Adresse.

Ein Punkt führt regelmäßig zu falschen Preisen: PRICE_QUANTITY. Das Element gibt an, für wie viele Bestelleinheiten der Preis gilt. Steht dort 100, kostet nicht das Stück 2,40 Euro, sondern hundert Stück.

Klassifikation mit ETIM und ECLASS

BMEcat beschreibt, wie Daten übertragen werden. Welche Warengruppen und Merkmale es gibt, legt der Standard nicht fest. Dafür verweist eine Katalogposition auf ein Klassifikationssystem. Im deutschsprachigen Raum sind das vor allem ECLASS und ETIM.

ECLASS ist branchenübergreifend und ordnet Produkte und Dienstleistungen in eine vierstufige Hierarchie ein. Im Einkauf dient die Klasse oft dazu, eine Position einer Warengruppe zuzuordnen. ETIM stammt aus der Elektrobranche und wird inzwischen auch in benachbarten Branchen genutzt. ETIM beschreibt Produktklassen mit festen Merkmalen und Wertelisten. Das ermöglicht eine Suche über technische Eigenschaften.

In der Katalogdatei steht die Klassifikation im Bereich ARTICLE_FEATURES (in BMEcat 2005 PRODUCT_FEATURES). Dort nennen Sie das System mit seiner Version, die Klasse und die Merkmale mit ihren Werten. Eine Position kann mehreren Systemen zugeordnet sein.

Achten Sie auf die Version des Klassifikationssystems. Klassen und Merkmale ändern sich von Version zu Version. Liefert ein Lieferant eine andere Version als Ihr System erwartet, lassen sich Teile der Daten nicht zuordnen.

Validierung und typische Fehler beim Import

Ein Katalog sollte in zwei Stufen geprüft werden. Zuerst die formale Prüfung gegen DTD oder XSD: Ist die Datei wohlgeformt und entspricht sie dem Standard? Danach die fachliche Prüfung gegen Ihre eigenen Regeln: Sind die Daten für Ihren Einkauf brauchbar? Eine formal gültige Datei kann fachlich unbrauchbar sein.

Diese Fehler treten beim Import häufig auf:

Falsche Zeichenkodierung: Die Datei gibt UTF-8 an, ist aber in einer anderen Kodierung gespeichert. Umlaute erscheinen dann als Zeichensalat oder der Parser bricht ab.
Falsche Reihenfolge der Elemente: BMEcat schreibt die Reihenfolge vor. Vertauschte Elemente machen die Datei ungültig, auch wenn alle Inhalte vorhanden sind.
Nicht maskierte Sonderzeichen: Ein kaufmännisches Und oder spitze Klammern im Text zerstören die XML-Struktur.
Dezimalkomma im Preis: Preise brauchen einen Punkt als Dezimaltrennzeichen und keine Tausendertrennzeichen.
Einheiten als Freitext: „Stück“ oder „Pack“ statt eines Einheitencodes. Das Zielsystem kann die Einheit dann nicht auf eine SAP-Mengeneinheit abbilden.
Doppelte Artikelnummern: Dieselbe SUPPLIER_AID kommt mehrfach vor. Welche Position gilt, ist dann unklar.
Fehlende Bilddateien: Die Datei verweist auf Bilder, die nicht mitgeliefert wurden oder anders geschrieben sind.
Aktualisierung ohne passenden Vorgänger: Eine Update-Transaktion bezieht sich auf einen Katalogstand, den das Zielsystem nicht hat.

Wichtig ist die Rückmeldung an den Lieferanten. Ein Prüfprotokoll mit Position, Element und Fehlerursache spart Rückfragen. Ohne verständliches Protokoll liefert der Lieferant dieselbe Datei mehrfach ein.

Große Kataloge in der Praxis

Bei wenigen tausend Positionen ist der Import unkritisch. Bei Millionen von Artikeln ändern sich die Anforderungen. Eine Katalogdatei lässt sich dann nicht mehr vollständig in den Arbeitsspeicher laden. Sie muss als Datenstrom gelesen werden. Vollkataloge werden gegen den vorhandenen Stand abgeglichen, damit nur geänderte Positionen neu indexiert werden. Der neue Stand wird erst freigeschaltet, wenn Prüfung und Import abgeschlossen sind.

Wie das im Betrieb aussieht, zeigt unser Projekt beim Spezialchemiekonzern LANXESS. Das Katalogsystem von LANXESS umfasst über 5 Millionen Artikel und ist an SAP angebunden. Zwei Anforderungen standen dort im Vordergrund. Der Katalog muss die Kontrakte und Materialnummern aus SAP kennen. Und die Suche muss in einem Sortiment dieser Größe schnell das Richtige finden.

Für das Katalogmanagement folgt daraus: Der Import ist nur der erste Schritt. Die Qualität der Kurztexte, Einheiten und Klassifikation entscheidet, ob Besteller einen Artikel finden und ob die Bestellung in SAP ohne Nacharbeit ankommt. Wie wir solche Systeme bauen, lesen Sie unter Portale und Kataloge.

BMEcat und OCI: wie beides zusammenspielt

BMEcat und OCI werden oft verwechselt. Sie lösen unterschiedliche Aufgaben. BMEcat bringt die Katalogdaten in das Katalogsystem. Das geschieht vorab und als Datei. OCI, das Open Catalog Interface von SAP, überträgt zur Laufzeit den Warenkorb aus dem Katalog zurück in das SAP-System.

Der Ablauf im Einkauf sieht so aus:

Der Lieferant liefert seinen Katalog als BMEcat-Datei.
Das Katalogsystem prüft und importiert die Datei.
Der Besteller springt aus SAP in den Katalog, sucht und füllt den Warenkorb.
Der Katalog übergibt den Warenkorb per OCI an SAP. Dort entsteht die Bestellanforderung.

Die Felder aus dem BMEcat-Import landen dabei in den OCI-Feldern. Aus SUPPLIER_AID wird die Lieferantenartikelnummer, aus DESCRIPTION_SHORT die Bezeichnung der Position, aus ORDER_UNIT die Mengeneinheit, aus dem Preis der Positionspreis. Fehler im Katalog wandern so direkt in die Bestellung. Ein Beispiel: OCI begrenzt die Länge der Bezeichnung. Ein Kurztext, der erst am Ende das unterscheidende Merkmal nennt, wird in SAP abgeschnitten.

Häufige Fragen zu BMEcat

Ist BMEcat 1.2 veraltet?

BMEcat 1.2 ist die ältere Version, wird aber weiterhin von vielen Lieferanten geliefert. Ein Katalogsystem sollte 1.2 und 2005 verarbeiten können.

Kann ich eine BMEcat-Datei aus Excel erzeugen?

Nicht direkt. Sie brauchen ein Werkzeug, das die Tabelle in die vorgeschriebene XML-Struktur überführt. Viele PIM- und Shopsysteme bieten einen BMEcat-Export. Prüfen Sie das Ergebnis vor dem Versand gegen DTD oder XSD.

Sind die Bilder in der BMEcat-Datei enthalten?

Nein. Die Datei enthält nur Verweise. Bilder und Datenblätter werden getrennt geliefert, zum Beispiel in einem Archiv, oder über eine Adresse bereitgestellt.

Brauche ich ETIM oder ECLASS, um BMEcat zu nutzen?

Nein. Eine Klassifikation ist für eine gültige Datei nicht zwingend. Ohne sie fehlen aber die Zuordnung zu Warengruppen und die Suche über Merkmale.

Was ist der Unterschied zwischen BMEcat und OCI?

BMEcat ist ein Dateiformat für Katalogdaten. OCI ist eine Schnittstelle, über die ein Katalog den Warenkorb an SAP zurückgibt. In einem Katalogsystem mit SAP-Anbindung brauchen Sie in der Regel beides.

Kataloge im indirekten Einkauf

Aus dem Katalogsystem für LANXESS ist Ovenca Procure entstanden, unsere Software für den indirekten Einkauf mit SAP-Anbindung. Wenn Sie Lieferantenkataloge importieren, prüfen und in SAP bestellbar machen wollen, sprechen Sie mit uns.