Classify products
Once the mapping exists, classifying the catalog is mostly bulk work plus a short tail of judgement calls. This article is the routine.
Bulk assignment by family
Class assignment inherits from the family, so most of the catalog classifies itself.
- Open the classification overview and read the per-family coverage. Families with no class are your work list.
- Assign a class to each unclassified family, largest by product count first.
- Handle the exceptions: families that genuinely span two classes. Filter the
products inside the family by the attribute that distinguishes them —
product_type,form, whatever splits them — and bulk-edit the class on the subset. - Re-read the coverage. Anything still unclassified after this is usually a family that should be two families.
Twenty families typically cover most of a mid-sized catalog. Do those, deliver something, then work the tail.
Feature completeness
Class assignment says what kind of thing this is. Features say what it is like, and that is where the gaps are.
The completeness report for a classification tells you, per class:
- How many products carry the class.
- Which mandatory features are empty, on how many products.
- Which optional features are empty — useful, because customers' search inside their procurement system uses them.
Work it the same way as
catalog completeness: by attribute, not
by product. "Fill thread_size on the 340 products missing it" is one bulk edit
or one import. "Complete these 340 products" is 340 separate decisions.
| Gap | Fix |
|---|---|
| The attribute exists and is empty | Bulk edit or import |
| The attribute does not exist | Create it in PIM › Data model › Attributes, add it to the family, map it, then fill |
| The value exists as free text in the description | Extract it into the attribute. Tedious once, permanent afterwards |
| The feature is not something you know | Ask the manufacturer. This is a real and normal outcome |
0, - and n/a pass your completeness check, pass format
validation, and arrive in your customer's system as facts. A buyer then filters
on that feature and either finds your article when they should not, or does not
when they should. An honest gap is better than a wrong value.Validation against the standard
Validation checks more than presence. It checks the value is legal for the feature:
| Check | Example failure |
|---|---|
| Value is in the standard's list | Your option maps to a value code that does not exist in this version |
| Unit is the one the feature expects | Value in bar, feature expects kPa, no conversion declared |
| Data type matches | A text value against a numeric feature |
| Mandatory feature present | Empty |
| Class exists in this version | The class was deprecated in the release you are exporting against |
Run validation before you run an export, not after. The export's own validation report will catch the same problems, but at that point you are usually against a delivery deadline.
The last row is the one that arrives without warning: eCl@ss releases twice a year, and a class that was fine last year can be deprecated in the version your customer has moved to. See Classification version updates.
Steps for a delivery-driven push
The realistic scenario is not "classify the catalog". It is "this customer needs these 900 articles classified by the 15th".
- Filter to the articles in that customer's assortment.
- Check class coverage on that subset only. Assign what is missing.
- Run validation on the subset against the version that customer requires.
- Fix mandatory feature gaps by attribute, in bulk.
- Re-validate. Accept the remaining warnings explicitly, article by article, and record which ones you accepted.
- Run the export profile and send a 20-article test file.
What to check
- Pick three classified products and read their classification as a customer's system would: class code, feature codes, value codes, units. It should be possible to understand the article from that alone.
- Check the same three products in a second language. Codes identical, labels translated.
- Confirm the validation report for the target export is clean, or that every remaining warning is one you consciously accepted.