What is ETIM in BMEcat? A Technical Guide for Product Data Teams

ETIM: the short version

ETIM (European Technical Information Model) is a standardized product classification system used primarily in the electrical, HVAC, and plumbing industries. It assigns every product a class, then defines the technical features that describe products in that class.

A miniature circuit breaker belongs to class EC001049. That class defines features like rated current (EF000007), number of poles (EF000006), and breaking capacity (EF000008). Each feature has a defined data type: numeric, boolean, enumeration, or text. Enumeration features use value codes (EV######) from a controlled list.

If you are working on catalog data exchange in Europe, ETIM is the classification system your trading partners expect. Before you send a BMEcat file, you should validate your ETIM BMEcat XML to confirm the structure is correct.

How ETIM fits inside BMEcat XML

BMEcat is the container format. ETIM is the classification payload. The two work together but serve different purposes. BMEcat handles commercial data (prices, order units, logistics). ETIM handles technical classification (what the product is and what it can do).

Inside a BMEcat file, ETIM data lives in the PRODUCT_FEATURES element for each product. Here is the structure:

<PRODUCT_FEATURES>
  <REFERENCE_FEATURE_SYSTEM_NAME>ETIM-9.0</REFERENCE_FEATURE_SYSTEM_NAME>
  <REFERENCE_FEATURE_GROUP_ID>EC001049</REFERENCE_FEATURE_GROUP_ID>
  <FEATURE>
    <FNAME>EF000007</FNAME>
    <FVALUE>16</FVALUE>
    <FUNIT>AMP</FUNIT>
  </FEATURE>
  <FEATURE>
    <FNAME>EF000006</FNAME>
    <FVALUE>EV000052</FVALUE>
  </FEATURE>
</PRODUCT_FEATURES>

Three elements define the classification context:

REFERENCE_FEATURE_SYSTEM_NAME declares the ETIM version. The format is ETIM-X.0 where X is the major version number. Most European data pools currently expect ETIM 8.0 or 9.0. The German VEG/EDXF guidelines penalize files using versions below 8.0.

REFERENCE_FEATURE_GROUP_ID is the ETIM class code. It follows the pattern EC followed by six digits. EC001049 is miniature circuit breakers. EC000101 is cable trays. The class determines which features are valid for the product.

FEATURE elements carry the actual technical data. Each has an FNAME (feature code), one or more FVALUE elements, and optionally an FUNIT.

The code system: EC, EF, EV

ETIM uses a consistent coding scheme:

• EC###### identifies a class (product category). There are roughly 5,500 classes in ETIM 9.0.
• EF###### identifies a feature (technical attribute). Around 5,000 features exist across all classes.
• EV###### identifies a value from a controlled list. Used for enumeration-type features like "number of poles" where only specific values are valid.
• EU###### identifies a unit. Although in BMEcat, units are typically expressed as Rec 20 codes rather than ETIM unit codes.

When a feature is numeric, the FVALUE contains the raw number and FUNIT carries the unit. When a feature is an enumeration, the FVALUE contains an EV code. When a feature is boolean, the FVALUE is true or false (not "yes" or "no", not "Yes" or "No", and definitely not 1 or 0).

Worked example: classifying a 16A MCB

Say you have a Schneider Electric iC60N, a 16A single-pole miniature circuit breaker with a C-curve and 6kA breaking capacity. Here is how the ETIM classification maps:

Each feature code is defined by the ETIM class. You cannot use EF codes that are not assigned to the product's class. This is a common source of validation errors: mapping a feature from the wrong class.

After building your classification, validate your ETIM BMEcat XML to confirm every feature code is valid for the assigned class and every value matches the expected data type.

Where things go wrong

The most common errors when building ETIM data in BMEcat fall into three categories.

Format errors. The class code doesn't match EC######. The feature code doesn't match EF######. Boolean values are written as "yes" instead of "true". Range values are stuffed into a single FVALUE instead of using two separate elements.

Version mismatches. The file declares ETIM-7.0 but the receiving system expects ETIM-9.0. Classes and features change between versions. An EC code that exists in version 7 might have been split, merged, or renumbered in version 9.

Missing or empty values. The ETIM guideline requires certain features to be populated. When a value is unknown, the correct approach is to set FVALUE to "-" and FVALUE_DETAILS to "NA" (not applicable), "MV" (missing value), or "UN" (unknown). Simply omitting the feature or leaving FVALUE empty will fail validation.

For a detailed list of these errors and how to fix them, see common ETIM namespace and mandatory field errors.

ETIM versions and data pool requirements

Different data pools and trading partners mandate different ETIM versions. The German VEG (Verband Elektro-Grosshandel) requires ETIM 8.0 or later and enforces additional rules through their Open Datacheck scorecard. Norwegian distributors using Nelfo expect ETIM-based BMEcat with specific country-level mandatory fields. The Dutch Technische Unie and French Sonepar groups each have their own version and field requirements.

Before building your ETIM export, confirm the version and any country-specific requirements with your trading partner. Then test the file with a schema validator before sending it over. A round of ETIM BMEcat validation before submission saves the back-and-forth that otherwise eats up weeks.

Summary

ETIM in BMEcat means structured technical classification inside an XML product catalog. Every product gets a class, every class defines features, every feature carries a typed value. The XML elements that carry this are PRODUCT_FEATURES, REFERENCE_FEATURE_SYSTEM_NAME, REFERENCE_FEATURE_GROUP_ID, and FEATURE. Get the codes right, match the version your trading partner expects, and validate before you send.