ETIM and BMEcat: what technical wholesale expects

Your data went out as BMEcat last week and came back with a list: forty products missing a required feature, three classes on the wrong ETIM version, one unit the recipient's importer rejected. Somewhere in your team there is a spreadsheet that maps your attributes to ETIM features, one colleague understands it, and everyone else waits for them.

This is the normal state of affairs for manufacturers supplying electrical and building-services wholesale in DACH. It is worth being precise about what the other side actually needs, because the requirements are more specific — and more mechanical — than "send us BMEcat".

Wholesale does not read your descriptions. It filters your features.

A wholesaler's shop, printed catalog and ordering system are built on classification. A fitter looking for a pressure gauge does not search prose; they filter: nominal size, measuring range, connection type, accuracy class. Those filters are ETIM features, and they only work if your products are in the right class with the right features filled.

The practical consequence: a product with a beautiful marketing text and an empty feature set is, in the wholesaler's system, nearly invisible. It can be ordered by article number by someone who already knows it exists. It cannot be found by someone comparing options. Unclassified is not "slightly worse" — for the discovery path that generates new demand, it is close to absent.

Four expectations, stated plainly

1. The right class, consistently

Class assignment is the foundation and the place where inconsistency hides longest. Products from the same family end up in different classes because two people classified them two years apart. The fix is to assign by rule — per category, product type or attribute — and keep manual overrides as explicit exceptions rather than the default mode. A rule you can inspect is also a rule you can re-run when ETIM publishes a new version.

2. Units and value lists in ETIM's terms, not yours

This is where most rejections originate. ETIM defines a unit for each numeric feature and, for many alphanumeric ones, a closed list of permitted values. Your PIM almost certainly does not store data that way.

• Units. You store 6.3 cm, ETIM wants millimetres with the unit code MMT. You store 1000 mbar, the feature is defined in BAR.
• Ranges. "0…10 bar" is one string in your PIM and two values — minimum and maximum — in the feature.
• Value lists. "Edelstahl", "Edelstahl 1.4301", "V2A" and "stainless steel" are four spellings of one ETIM value code. A free-text field cannot be delivered into a value-list feature; it has to be mapped through a value table you maintain once and reuse across classes.
• Not applicable vs. missing. A feature that does not apply to a product should be delivered as not applicable, not left empty. An empty field reads as incomplete data; an explicit "not applicable" reads as a complete answer. Recipients score these differently.

The mapping work here is real, but it is finite and it is reusable. "Edelstahl → EV0000Z1" is mapped once and applies to every class that uses that value list.

3. Completeness measured against their profile, not a general average

Every wholesaler works from the same standard and expects something slightly different: which features are mandatory beyond the ETIM minimum, which ETIM version, which languages, which price and packaging data, which file format, which delivery rhythm and naming convention.

That means "our data is 91 % complete" is not an answer to anyone's question. The useful metric is completeness per class per recipient profile: for wholesaler A on ETIM 9.0, 294 pressure gauges are ready and 3 features are missing on 11 of them. Then you can set a threshold per profile and decide, deliberately, whether incomplete products are delivered with a warning or held back.

Holding products back is often the better choice. A product delivered incomplete occupies a catalog slot and shows up badly in filters; a product held back can be fixed and delivered next week.

4. Delta, not the whole catalog for every change

Sending 12,000 products because one price and two features changed is expensive on both sides — your export window, their import window, their validation, their support queue when something in the untouched 11,997 shifts unexpectedly.

BMEcat has the transactions for this: T_NEW_CATALOG for the full catalog, T_UPDATE_PRODUCTS and T_UPDATE_PRICES for changes. Using them requires knowing, reliably, what changed since the last delivery to that recipient — which means tracking change at field level and versioning each delivery, so you can compare delivery 37 with delivery 38 and answer "what did we actually send you on the 20th".

Three wholesalers, three ETIM profiles, one spreadsheet that only one colleague understands.

The version problem nobody schedules for

Wholesalers do not switch ETIM versions on the same day. At any time you will likely be delivering one version to one recipient and another to the next, and a class you use may have gained a feature, renamed a value or dropped something in between.

Handling this by keeping two spreadsheets is how mappings drift. What works is keeping the mapping per ETIM version, generating a change report per class when a new version appears — this class gained one feature, one value was renamed, none were removed — and setting the delivery version per recipient profile. Then migrating is a decision you make per class at your own pace rather than a deadline someone else sets.

What to do this week

Three things that are useful regardless of which tooling you end up with:

1. Count completeness per class, not per catalog. Take your top ten classes by product count and list, for each, how many products have every required feature filled. The distribution is almost never even; two or three classes usually carry most of the deficit.
2. Find the free-text fields feeding value-list features. These are your silent rejection source. Every distinct spelling in those fields is a value-table entry waiting to be written.
3. Write down each recipient's profile. ETIM version, mandatory features beyond the standard, format, languages, schedule, naming. Most teams have this knowledge distributed across email threads. On one page, it becomes configuration instead of folklore.

Once those three exist, the mapping stops being a spreadsheet and becomes maintainable. That is what the ETIM and BMEcat module does: it holds class rules, feature mappings, unit conversions and value tables per ETIM version, checks completeness against each recipient profile, and builds BMEcat full catalogs or update transactions from the same classified data — versioned, so any two deliveries can be compared. It runs next to your PIM; your PIM keeps its own data model and the translation into ETIM happens on the way out.

If you are on the receiving end — a wholesaler taking supplier data in — the same mechanism runs in reverse, with validation on submission through the supplier portal so field-level errors go back to the supplier instead of into your import log.

See how the mapping works, or book a completeness check against one of your recipient profiles.

Key takeaways

• Wholesale discovery runs on ETIM features; unclassified products are effectively invisible to filtered search.
• Most rejections come from units, ranges and free-text values that need mapping into ETIM value codes — map once, reuse across classes.
• Deliver "not applicable" explicitly; an empty field is read as incomplete data.
• Completeness is only meaningful per class and per recipient profile, with a threshold that decides deliver, warn or hold.
• Use BMEcat update transactions and field-level change tracking instead of full catalogs for every change.
• Keep mappings per ETIM version so you can serve two versions at once and migrate class by class.