Classification version updates
eCl@ss publishes a new release roughly twice a year. ETIM moves about annually. Your customers move on their own schedule, which is neither of those. This article is how to stay current without a rebuild every six months.
What a new release actually changes
| Change | Effect on you | How often |
|---|---|---|
| New classes | Products you could not classify precisely now can be | Every release |
| Deprecated classes | Your assigned class no longer exists in the new version | Every release, a handful |
| Split classes | One old class becomes two or three; your products must be redistributed | Occasionally, and it is the painful one |
| Merged classes | Two become one; mechanical | Occasionally |
| New features on existing classes | New gaps in your completeness, possibly mandatory | Every release |
| Changed value lists | Your value mapping points at a code that moved | Every release |
| Changed units | A feature now expects a different unit | Rare, and missed most often |
The last row is the quiet one. A unit change validates cleanly if you never declared a conversion — the number goes out unchanged, meaning something different. Check unit changes explicitly against your mapping.
Running two versions at once
This is normal, not a workaround. One customer is on eCl@ss 12.0 and will be for two more years; another has moved to 14.0. Both need a correct file.
Hold both versions loaded, and let each
export profile name the version it
exports against. Products carry their class per version, so an article can be
23-11-01-01 in one and something else in the other.
The cost is that gaps double: a product complete in 12.0 can be incomplete in 14.0 because 14.0 added a mandatory feature. That is why the completeness report is read per version, and why you do not load a version nobody has asked for.
The migration, step by step
- Load the new version alongside the current one. Do not activate it for any export yet.
- Run the difference report. It tells you which of your assigned classes are deprecated, split, merged or unchanged. Most will be unchanged; that is the good news.
- Handle unchanged classes. Nothing to do, but re-validate — features and value lists may have moved underneath a class that kept its code.
- Handle merged and renamed classes. Mechanical. Reassign at the family level and the products follow.
- Handle split classes. This is the work. One old class is now two, and deciding which of your products goes where usually needs an attribute that distinguishes them. If you have it, filter and bulk-edit. If you do not, you are creating an attribute and filling it before you can migrate — plan for that, it is the part that turns a two-day job into a two-week one.
- Handle deprecated classes with no successor. Rare and awkward. Find the nearest surviving class and record the decision; someone will ask in a year.
- Re-map features and values where the new version changed them. Pay particular attention to units.
- Re-validate the whole catalog against the new version and work the new mandatory-feature gaps by attribute, as in Classify products.
- Export a 20-article test file in the new version and have the customer confirm it loads.
- Switch the export profile to the new version. Keep the old version loaded for the customers still on it.
Re-validation is not optional
The most common way a classification quietly breaks is a version upgrade where the classes were remapped and nothing else was checked. A class code can survive a release while its feature list, its mandatory flags and its value lists all change.
After every migration, and before every first delivery in a new version:
- Full validation against the new version, catalog-wide.
- Manual read of three products per major family — class, features, values, units — as a customer's system would see them.
- Comparison of the exported article count against the previous version's export. A large drop means articles are being excluded on a new mandatory feature.
Keeping it from becoming a project
Twice a year, when a release is published:
- Read the release notes for the classes you actually use, not the whole release. This is a short list.
- Note anything that affects you in a ticket, even if you are not migrating.
- Ask your three largest catalog customers which version they are on and when they plan to move. This one question, asked yearly, removes most surprise from the whole area.