What is BMEcat?

Where BMEcat comes from

BMEcat was created in 1999 on the initiative of BME, the German association for materials management, purchasing and logistics (Bundesverband Materialwirtschaft, Einkauf und Logistik), together with companies such as Bayer, BMW, SAP and Siemens. It was developed by Fraunhofer IAO and the University of Essen (now the University of Duisburg-Essen). The idea behind it: a buyer who receives catalogues from a hundred suppliers should not have to read a hundred file formats. BMEcat therefore defines what a catalogue looks like as XML — which elements exist, in which order they appear and which values are allowed. In German-speaking B2B trade it is still one of the most widely used formats for catalogue data, above all in technical wholesale: electrical, plumbing and heating, tools, industrial supplies.

How a BMEcat file is structured

Every file has two parts: a header with information about the whole catalogue and a transaction containing the products. The skeleton of a BMEcat 2005 file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<BMECAT version="2005" xmlns="http://www.bmecat.org/bmecat/2005">
  <HEADER>
    <!-- language, catalogue ID, version, currency -->
    <CATALOG>…</CATALOG>
    <!-- buyer, optional -->
    <BUYER>…</BUYER>
    <!-- supplier -->
    <SUPPLIER>…</SUPPLIER>
  </HEADER>
  <T_NEW_CATALOG>
    <PRODUCT mode="new">
      <!-- product number -->
      <SUPPLIER_PID>…</SUPPLIER_PID>
      <!-- texts, GTIN, manufacturer -->
      <PRODUCT_DETAILS>…</PRODUCT_DETAILS>
      <!-- classification, features -->
      <PRODUCT_FEATURES>…</PRODUCT_FEATURES>
      <!-- units, quantities -->
      <PRODUCT_ORDER_DETAILS>…</PRODUCT_ORDER_DETAILS>
      <!-- prices -->
      <PRODUCT_PRICE_DETAILS>…</PRODUCT_PRICE_DETAILS>
      <!-- images, data sheets -->
      <MIME_INFO>…</MIME_INFO>
      <!-- extensions -->
      <USER_DEFINED_EXTENSIONS>…</USER_DEFINED_EXTENSIONS>
      <!-- accessories, successors -->
      <PRODUCT_REFERENCE>…</PRODUCT_REFERENCE>
      <!-- customs, origin, dimensions -->
      <PRODUCT_LOGISTIC_DETAILS>…</PRODUCT_LOGISTIC_DETAILS>
    </PRODUCT>
    <!-- … any number of further products … -->
  </T_NEW_CATALOG>
</BMECAT>

Three peculiarities are worth knowing. The order is prescribed: writing PRODUCT_PRICE_DETAILS before PRODUCT_ORDER_DETAILS makes the file invalid, even if every value is correct. Each product is largely self-contained: unlike in a database, its data is not spread across linked tables, and almost everything sits inside the PRODUCT element. Many things may repeat: several prices with quantity breaks, several feature blocks, several images. That is exactly what makes BMEcat hard to fit into a table with one row per product. A complete, valid example with all the usual details can be found on the BMEcat example file page.

What is mandatory and what is not

The schema demands surprisingly little. Per product, only four things are required:

In the header, language (LANGUAGE), catalogue ID (CATALOG_ID), catalogue version (CATALOG_VERSION) and the supplier are required. Everything else is decided not by BMEcat but by the recipient. That is exactly what industry rules such as the ETIM guideline are for: they turn many optional fields into mandatory ones.

The three transactions

Below the header there is exactly one of three transactions. It tells the recipient what to do with the products:

• T_NEW_CATALOG — a complete catalogue. It replaces the recipient's previous version.
• T_UPDATE_PRODUCTS — changes to an existing catalogue. Each product then carries mode="new", "update" or "delete", and the attribute prev_version names the catalogue version the change refers to.
• T_UPDATE_PRICES — new prices only. A product then consists essentially of its number and its price blocks.

Many suppliers simply send the complete catalogue at regular intervals. That is more robust: if an update package gets lost, only a recipient that checks prev_version notices straight away. Everyone else notices only when prices are wrong or products are missing.

The versions: 1.2, 2005, 2005.1 and 2005.2

In practice, BMEcat 2005 is the version that counts: the ETIM guideline builds on it, and most recipients expect it. Catalogues in the older 1.2 format still turn up, mostly from older ERP systems. Which version a file uses is stated in the version attribute of the root element.

1.2 and 2005 compared

If you read an old catalogue or build an import for both versions, this mapping is what you need most:

Renaming alone does not turn a 1.2 catalogue into a good 2005 catalogue, because BMEcat 2005 added a fair amount. Incidentally, the 2005 schema still accepts the old ARTICLE elements for backward compatibility.

Classification: ETIM and eCl@ss

BMEcat itself is industry-neutral and has no product classes of its own. What kind of product an item is and which technical features it has comes from a classification system. The file only holds the reference, in the PRODUCT_FEATURES block:

<PRODUCT_FEATURES>
  <REFERENCE_FEATURE_SYSTEM_NAME>ETIM-9.0</REFERENCE_FEATURE_SYSTEM_NAME>
  <REFERENCE_FEATURE_GROUP_ID>EC000042</REFERENCE_FEATURE_GROUP_ID>
  <FEATURE>
    <FNAME>EF000227</FNAME>
    <FVALUE>16</FVALUE>
  </FEATURE>
</PRODUCT_FEATURES>

That means: class EC000042 (miniature circuit breaker) under ETIM 9.0, feature EF000227 (rated current) with the value 16. The unit, ampere, follows from the feature itself. The plain-text names of the codes are not in the file. They belong to the classification model.

ETIM is the classification model of electrical, plumbing and heating wholesale, now also covering tools, building materials and shipbuilding. ETIM International publishes the ETIM BMEcat Guideline for it, currently version 5.0. It defines which fields are mandatory beyond the schema, differently per country in 23 country columns, and adds the extension block UDX.EDXF for packing units, discount groups, REACH data and product images. eCl@ss, now written ECLASS, is the cross-industry counterpart, widespread in manufacturing and procurement, with its own rules for BMEcat. A catalogue may carry both, with one PRODUCT_FEATURES block per system.

Alongside BMEcat, ETIM now also offers an exchange format of its own based on JSON, ETIM xChange. BMEcat has not been replaced by it: ETIM maintains both formats side by side.

Opening and validating a BMEcat file

A BMEcat file is plain text, and any editor will open it. That does not make it readable: a supplier catalogue quickly runs to tens of thousands of products and several hundred megabytes. For an overview, open the file in this tool: it shows key figures and every field that occurs, validates against the official schema and the ETIM guideline, and converts to Excel or CSV. The file stays on your computer.