Wat is BMEcat?

Waar BMEcat vandaan komt

BMEcat ontstond in 1999 op initiatief van de Duitse inkoopvereniging BME (Bundesverband Materialwirtschaft, Einkauf und Logistik), samen met bedrijven als Bayer, BMW, SAP en Siemens. Het werd uitgewerkt door het Fraunhofer IAO en de universiteit van Essen, tegenwoordig Duisburg-Essen. De gedachte erachter: een inkoper die catalogi van honderd leveranciers ontvangt, zou niet met honderd verschillende bestandsformaten te maken moeten krijgen. BMEcat legt daarom vast hoe een catalogus er als XML uitziet — welke elementen er zijn, in welke volgorde ze staan en welke waarden zijn toegestaan. In de Duitstalige B2B-handel is het nog altijd een van de meest gebruikte formaten voor catalogusgegevens, vooral in de technische groothandel: elektro, installatietechniek, gereedschap en industriële benodigdheden. Ook de Nederlandse datapool 2BA accepteert BMEcat met ETIM.

Zo is een BMEcat-bestand opgebouwd

Elk bestand heeft twee delen: een kop met gegevens over de hele catalogus en een transactie met de artikelen. Het geraamte van een bestand volgens BMEcat 2005 ziet er zo uit:

<?xml version="1.0" encoding="UTF-8"?>
<BMECAT version="2005" xmlns="http://www.bmecat.org/bmecat/2005">
  <HEADER>
    <!-- taal, catalogusnummer, versie, valuta -->
    <CATALOG>…</CATALOG>
    <!-- koper, optioneel -->
    <BUYER>…</BUYER>
    <!-- leverancier -->
    <SUPPLIER>…</SUPPLIER>
  </HEADER>
  <T_NEW_CATALOG>
    <PRODUCT mode="new">
      <!-- artikelnummer -->
      <SUPPLIER_PID>…</SUPPLIER_PID>
      <!-- teksten, GTIN, fabrikant -->
      <PRODUCT_DETAILS>…</PRODUCT_DETAILS>
      <!-- classificatie, kenmerken -->
      <PRODUCT_FEATURES>…</PRODUCT_FEATURES>
      <!-- eenheden, aantallen -->
      <PRODUCT_ORDER_DETAILS>…</PRODUCT_ORDER_DETAILS>
      <!-- prijzen -->
      <PRODUCT_PRICE_DETAILS>…</PRODUCT_PRICE_DETAILS>
      <!-- afbeeldingen, datasheets -->
      <MIME_INFO>…</MIME_INFO>
      <!-- uitbreidingen -->
      <USER_DEFINED_EXTENSIONS>…</USER_DEFINED_EXTENSIONS>
      <!-- toebehoren, opvolgers -->
      <PRODUCT_REFERENCE>…</PRODUCT_REFERENCE>
      <!-- douane, herkomst, maten -->
      <PRODUCT_LOGISTIC_DETAILS>…</PRODUCT_LOGISTIC_DETAILS>
    </PRODUCT>
    <!-- … willekeurig veel andere artikelen … -->
  </T_NEW_CATALOG>
</BMECAT>

Drie eigenaardigheden moet u kennen. De volgorde ligt vast: wie PRODUCT_PRICE_DETAILS vóór PRODUCT_ORDER_DETAILS zet, heeft een ongeldig bestand, ook als elke waarde klopt. Elk artikel staat grotendeels op zichzelf: anders dan in een database zijn de gegevens niet over gekoppelde tabellen verdeeld, bijna alles staat in het element PRODUCT. Veel mag meermaals voorkomen: meerdere prijzen met staffels, meerdere kenmerkblokken, meerdere afbeeldingen. Juist daardoor is BMEcat lastig in een tabel met één regel per artikel te krijgen. Een volledig, geldig voorbeeld met alle gangbare gegevens staat op de pagina BMEcat-voorbeeldbestand.

Wat verplicht is en wat niet

Het schema eist verrassend weinig. Per artikel zijn maar vier gegevens voorgeschreven:

In de kop zijn taal (LANGUAGE), catalogusnummer (CATALOG_ID), catalogusversie (CATALOG_VERSION) en de leverancier verplicht. Al het andere legt niet BMEcat vast, maar de ontvanger. Precies daarvoor bestaan brancheregels zoals de ETIM-guideline: die maakt van veel optionele velden verplichte velden.

De drie transacties

Onder de kop staat precies één van drie transacties. Die vertelt de ontvanger wat hij met de artikelen moet doen:

• T_NEW_CATALOG — een volledige catalogus. Die vervangt bij de ontvanger de vorige versie.
• T_UPDATE_PRODUCTS — wijzigingen in een bestaande catalogus. Elk artikel krijgt dan mode="new", "update" of "delete", en het attribuut prev_version geeft aan op welke eerdere versie de wijziging voortbouwt.
• T_UPDATE_PRICES — alleen nieuwe prijzen. Een artikel bestaat dan in de kern uit artikelnummer en prijsblokken.

Veel leveranciers sturen gewoon op vaste momenten de volledige catalogus. Dat is robuuster: raakt een wijzigingspakket zoek, dan merkt alleen een ontvanger die prev_version controleert dat meteen. Anderen merken het pas wanneer prijzen niet kloppen of artikelen ontbreken.

De versies: 1.2, 2005, 2005.1 en 2005.2

In de praktijk is BMEcat 2005 de norm: de ETIM-guideline bouwt erop voort, en de meeste ontvangers verwachten deze versie. Toch duiken er nog catalogi in het 1.2-formaat op, vooral uit oudere ERP-systemen. Welke versie een bestand heeft, staat in het attribuut version van het hoofdelement.

1.2 en 2005 vergeleken

Wie een oude catalogus leest of een import voor beide versies bouwt, heeft vooral deze vertaaltabel nodig:

Alleen hernoemen maakt van een 1.2-catalogus nog geen goede 2005-catalogus, want 2005 bracht heel wat nieuws. Overigens laat het schema 2005 de oude ARTICLE-elementen omwille van de neerwaartse compatibiliteit nog steeds toe.

Classificatie: ETIM en eCl@ss

BMEcat zelf is brancheneutraal en kent geen eigen productklassen. Wat voor product een artikel is en welke technische kenmerken het heeft, komt uit een classificatiesysteem. In het bestand staat daarvan in het blok PRODUCT_FEATURES alleen de verwijzing:

<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>

Dat betekent: klasse EC000042 (installatieautomaat) volgens ETIM 9.0, kenmerk EF000227 (nominale stroom) met de waarde 16. De eenheid ampère volgt uit het kenmerk zelf. De namen van de codes staan niet in het bestand, die horen bij het classificatiemodel.

ETIM is het classificatiemodel van de groothandel in elektro en installatietechniek, inmiddels ook voor gereedschap, bouwmaterialen en scheepsbouw. ETIM International geeft daarvoor de ETIM BMEcat Guideline uit, op dit moment versie 5.0. Die legt vast welke velden boven op het schema verplicht zijn, per land verschillend in 23 landkolommen, en voegt het uitbreidingsblok UDX.EDXF toe voor verpakkingseenheden, kortingsgroepen, REACH-gegevens en productafbeeldingen. eCl@ss, tegenwoordig ECLASS geschreven, is de branche-overstijgende tegenhanger, veel gebruikt in industrie en inkoop, met eigen regels voor BMEcat. Een catalogus mag beide bevatten, met één PRODUCT_FEATURES-blok per systeem.

Naast BMEcat biedt ETIM inmiddels een eigen uitwisselingsformaat op basis van JSON aan, ETIM xChange. BMEcat is daarmee niet vervangen: ETIM onderhoudt beide formaten naast elkaar.

Een BMEcat-bestand openen en controleren

Een BMEcat-bestand is platte tekst, elke editor opent het. Leesbaar is het daarmee nog niet, want een leverancierscatalogus telt al snel tienduizenden artikelen en enkele honderden megabytes. Voor een overzicht opent u het bestand in dit hulpmiddel: het toont kerngetallen en alle velden die voorkomen, toetst aan het officiële schema en de ETIM-guideline en zet om naar Excel of CSV. Het bestand blijft daarbij op uw computer.