BMEcat Explained: Structure, Versions and Catalog Management

What is BMEcat?

BMEcat is an XML standard for exchanging electronic product catalogs between suppliers and buying organizations. It is published by BME, the German Association for Supply Chain Management, Procurement and Logistics.

A supplier uses a BMEcat file to describe its product range: item numbers, texts, prices, order units, attributes and references to images. The buying organization loads that file into its catalog system. Neither side has to agree on a custom format first.

BMEcat is used mainly in Germany, Austria and Switzerland, and to a lesser extent across the rest of Europe. If you buy from German suppliers or run procurement for a European subsidiary, you will run into it. In North America, catalog files in cXML or plain spreadsheets are more common. The job is the same: get supplier content into the buyer's catalog in a predictable structure.

BMEcat covers catalog data only. Purchase orders, order confirmations and invoices are outside its scope and are handled by other formats and interfaces.

BMEcat 1.2 vs. BMEcat 2005

Two versions are in use: BMEcat 1.2, released in 2001, and BMEcat 2005. Many suppliers still deliver 1.2 because their export tools were built for it. A catalog system should be able to read both.

The two versions are not compatible. The main difference for anyone building an import: the article became a product. Element names changed in BMEcat 2005, while the overall structure stayed similar.

Aspect	BMEcat 1.2	BMEcat 2005
Schema	DTD	XML Schema (XSD) with a namespace
Catalog item	`ARTICLE`	`PRODUCT`
Supplier item number	`SUPPLIER_AID`	`SUPPLIER_PID`
Price	`ARTICLE_PRICE`	`PRODUCT_PRICE`, plus price formulas
Languages	One language per catalog file	Several languages in one file
Configurable products	Not supported	Supported
Logistics data	No dedicated section	Dedicated section for logistics details
Transactions	`T_NEW_CATALOG`, `T_UPDATE_PRODUCTS`, `T_UPDATE_PRICES` in both versions

Which version should you ask for? If you need multilingual catalogs, or ETIM data that follows the guideline published by ETIM International, you need BMEcat 2005. For a simple range in one language, 1.2 is often enough. Put the version in your supplier guideline, along with the fields you treat as mandatory.

Structure of a BMEcat catalog file

A BMEcat file has two parts: the HEADER and exactly one transaction. The transaction tells the receiving system what to do with the data.

HEADER: who sends what to whom

The header holds the catalog ID, version, language and default currency, plus the supplier and the buyer. Catalog ID and version matter for the import. They tell the receiving system whether a file replaces an existing catalog or updates it.

The three transactions

T_NEW_CATALOG: transfers the complete catalog. The receiving system replaces what it had before.
T_UPDATE_PRODUCTS: transfers changed items only. Each item is flagged as new, updated or deleted.
T_UPDATE_PRICES: transfers new prices for items that already exist.

ARTICLE or PRODUCT: the catalog item

The example below is a shortened BMEcat 1.2 file with one article. All values are made up.

<?xml version="1.0" encoding="UTF-8"?>
<BMECAT version="1.2">
  <HEADER>
    <CATALOG>
      <LANGUAGE>eng</LANGUAGE>
      <CATALOG_ID>SAMPLE-CATALOG</CATALOG_ID>
      <CATALOG_VERSION>001.000</CATALOG_VERSION>
      <CATALOG_NAME>Sample catalog, plant supplies</CATALOG_NAME>
      <CURRENCY>EUR</CURRENCY>
    </CATALOG>
    <BUYER>
      <BUYER_NAME>Sample Buyer Inc.</BUYER_NAME>
    </BUYER>
    <SUPPLIER>
      <SUPPLIER_NAME>Sample Supplier GmbH</SUPPLIER_NAME>
    </SUPPLIER>
  </HEADER>
  <T_NEW_CATALOG>
    <ARTICLE>
      <SUPPLIER_AID>4711-A</SUPPLIER_AID>
      <ARTICLE_DETAILS>
        <DESCRIPTION_SHORT>Nitrile safety glove, size 9</DESCRIPTION_SHORT>
        <DESCRIPTION_LONG>Chemical-resistant nitrile glove, length 33 cm.</DESCRIPTION_LONG>
        <MANUFACTURER_AID>NH-33-9</MANUFACTURER_AID>
        <MANUFACTURER_NAME>Sample Manufacturer</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>

The elements that matter most for each item:

SUPPLIER_AID: the supplier's item number. It is the key of the item and must be unique within the catalog. In BMEcat 2005 the element is called SUPPLIER_PID.
DESCRIPTION_SHORT: the short text. It shows up in search results and later on the purchase order. The long text goes into DESCRIPTION_LONG.
ORDER_UNIT: the order unit as a code, for example C62 for piece or PR for pair. CONTENT_UNIT and NO_CU_PER_OU describe what one order unit contains.
ARTICLE_PRICE: the price with its type, amount, currency and tax rate. The type is set in the price_type attribute, such as net_customer for the customer-specific net price. Volume pricing is expressed as several prices with different LOWER_BOUND values.
MIME: references to images, data sheets and other files. The file itself is not embedded in the XML. MIME_SOURCE only names the file or its address.

One element regularly causes wrong prices: PRICE_QUANTITY. It states how many order units the price applies to. If it says 100, then 2.40 euros is the price for one hundred units, not for one.

Classification with ETIM and ECLASS

BMEcat defines how data is transferred. It does not define which product categories and attributes exist. For that, a catalog item points to a classification system. In the BMEcat world, the two that matter most are ECLASS and ETIM. If you are used to UNSPSC, they play a comparable role, with far more detail at the attribute level.

ECLASS is cross-industry and sorts products and services into a four-level hierarchy. Procurement teams often use the class to assign an item to a material group. ETIM originated in the electrical industry and is now used in neighboring sectors as well. It describes product classes with fixed features and value lists, which makes it possible to search by technical properties.

In the catalog file, classification lives in ARTICLE_FEATURES (PRODUCT_FEATURES in BMEcat 2005). That section names the system and its version, the class, and the features with their values. One item can be assigned to more than one system.

Validation and common import errors

Check a catalog in two stages. First, formal validation against the DTD or XSD: is the file well-formed and does it conform to the standard? Second, validation against your own business rules: is the data usable for your buyers? A file can be formally valid and still be useless.

These errors come up again and again:

Wrong character encoding: the file declares UTF-8 but was saved in a different encoding. Accented characters and German umlauts turn into garbage, or the parser stops.
Wrong element order: BMEcat prescribes the sequence of elements. Swapped elements make the file invalid even when all the content is there.
Unescaped special characters: an ampersand or angle bracket in a text breaks the XML structure.
Decimal comma in prices: European suppliers often write 2,40. Prices need a period as the decimal separator and no thousands separators.
Units as free text: "piece" or "pack" instead of a unit code. The receiving system cannot map the unit to an SAP unit of measure.
Duplicate item numbers: the same SUPPLIER_AID appears more than once, so it is unclear which item is valid.

Large catalogs in practice

With a few thousand items, the import is not a concern. With millions of items, the requirements change. A catalog file can no longer be loaded into memory as a whole and has to be read as a stream. Full catalogs are compared against the existing data so that only changed items are re-indexed. The new version goes live only after validation and import have finished.

Our project for LANXESS, a specialty chemicals group, shows what this looks like in operation. The LANXESS catalog system holds more than 5 million items and is connected to SAP. Two requirements stood out. The catalog has to know the contracts and material numbers from SAP. And search has to find the right item quickly in a range of that size.

The lesson for catalog management: the import is only the first step. The quality of short texts, units and classification decides whether requesters find an item and whether the order arrives in SAP without rework. You can read how we build these systems under Portals and Catalogs.

BMEcat and OCI: how they work together

BMEcat and OCI are often confused. They solve different problems. BMEcat gets catalog data into the catalog system, ahead of time and as a file. OCI, the Open Catalog Interface from SAP, transfers the shopping cart from the catalog back into the SAP system at runtime. If you know punchout from cXML, OCI is SAP's counterpart.

The process in procurement looks like this:

The supplier delivers its catalog as a BMEcat file.
The catalog system validates and imports the file.
The requester jumps from SAP into the catalog, searches and fills the cart.
The catalog hands the cart to SAP via OCI, where it becomes a purchase requisition.

The fields from the BMEcat import end up in the OCI fields. SUPPLIER_AID becomes the vendor material number, DESCRIPTION_SHORT the item description, ORDER_UNIT the unit of measure, and the price the item price. Errors in the catalog therefore travel straight into the order. One example: OCI limits the length of the description. A short text that puts the distinguishing detail at the end gets cut off in SAP.

Frequently asked questions about BMEcat

Is BMEcat 1.2 obsolete?

BMEcat 1.2 is the older version, but many suppliers still deliver it. A catalog system should handle both 1.2 and 2005.

Is BMEcat used outside Germany?

Yes, mainly in Europe and most heavily in German-speaking countries. US companies usually meet it through European suppliers or subsidiaries.

Are images included in the BMEcat file?

No. The file only contains references. Images and data sheets are delivered separately, for example in an archive, or made available at a URL.

What is the difference between BMEcat and OCI?

BMEcat is a file format for catalog data. OCI is an interface through which a catalog returns the shopping cart to SAP. A catalog system connected to SAP usually needs both.

Catalogs in indirect procurement

The catalog system we built for LANXESS became Ovenca Procure, our software for indirect procurement with SAP integration. If you want to import supplier catalogs, validate them and make them orderable in SAP, talk to us.