Set up languages and classifications

Map attributes to a classification

Your attributes → eCl@ss features.

The mapping is what turns your data model into something a customer's procurement system can read. It is declared once per attribute and applied on every export, every time — which is why an hour spent here is worth a week of manual spreadsheet work later.

Before you begin. You need the standard's data file — the eCl@ss or ETIM release your customer asked for — and you need to know which version. eCl@ss 12.0 and 14.0 are different trees with different feature codes. Ask; do not assume the newest. See Classification standards.

Load a classification version

  1. Open the classification screen and add a classification: the standard (eCl@ss, ETIM, UNSPSC), the version, and the languages you need its labels in.
  2. Import the standard's release file. This loads the class tree, the feature definitions and the fixed value lists.
  3. Mark one version as active for export. You can hold several — a customer on eCl@ss 12.0 and another on 14.0 — but each export profile names exactly one.

The import is large and it is reference data, not your data. It does not touch your products.

Assign classes per family

Class assignment is the fast half of the job.

  1. Open a family and find the classification section.
  2. Assign the class for this family. Every product in the family inherits it.
  3. Override on individual products only where a family genuinely spans two classes — for example a family of seals covering both O-rings and flat gaskets, which are different eCl@ss classes.

Two pieces of advice from catalogs that have done this:

  • Start with your top 20 families by revenue. They usually cover most of what your large customers buy, and a partially classified catalog is deliverable while an unstarted one is not.
  • If assignment is hard, the family is wrong. A family that maps to four classes is a family that groups four kinds of product, and it is probably causing you trouble elsewhere too.

Map features

This is the slow half, and it is per attribute.

For each class, the standard lists the features it may or must carry. For each of those features, decide which of your attributes supplies it.

SituationWhat you do
Your attribute matches the feature directlyMap it, done
The feature expects a different unitMap it, and declare the conversion
The feature expects a value from a fixed listMap the values as well as the field
The feature is mandatory and you have no attributeCreate the attribute, then fill it
You have an attribute the standard has no feature forLeave it unmapped; it stays in your own data

Map at the attribute level wherever you can, not per class. thread_size means the same thing in every class that has a thread-size feature, and mapping it once covers all of them. Only map per class where the standard genuinely uses the same property differently.

Map values and units

Two mappings, both declared once.

Units. Your measurement attribute stores a value and a unit from its family. The feature specifies a unit from the standard's own unit list. Declare which of your units corresponds to the standard's, and the export converts. 10 bar becomes 1000 kPa if the feature says kPa, without anyone editing a product.

Values. For features with a fixed value list, map your option codes to the standard's value codes:

your option code   →   standard value
v4a                →   (the standard's code for stainless 1.4571)
v2a                →   (the standard's code for stainless 1.4301)
messing            →   (the standard's code for brass)
Map codes, never labels. A label mapping breaks the moment the catalog is translated, because the French label is not the German one. Option codes do not change with language, which is why they exist and why the attributes article insists on meaningful ones. This is the single most common reason a classification mapping stops working after a new market is added.

What is mandatory, and what happens when it is empty

The standard marks some features as mandatory for a class. An article missing a mandatory feature will fail your customer's import — not yours.

Decide the policy per export profile:

PolicyEffectUse when
BlockThe article is excluded from the exportThe customer rejects whole files on any error
WarnThe article is exported, listed in the validation reportMost cases
IgnoreExported silentlyNever, in practice

Warn is right for most customers, because a catalog that is 94% classified and delivered beats one that is 100% classified and three months late. But read the validation report — see Export a catalog for a customer.

What to check

  1. Pick three products from three different families. For each, view its classification and confirm the class, the features and the values are what you would write by hand.
  2. Check a product whose attribute is in a non-standard unit. The exported value must be converted, not just relabelled.
  3. Check a product in a second language. The class, the feature codes and the value codes must be identical to the first language; only labels change.
  4. Run the classification completeness report and note the percentage per family. That is your work list for Classify products.

Next