Units and Option Lists: Mapping Supplier Values to a PIM

The short answer. Map every supplier value to the unit and the option code your PIM attribute expects, not to the text the supplier wrote. Write down one conversion rule per unit and one synonym list per option attribute. Convert automatically only when the unit is explicit and the rule is exact. Let a person decide approximate values, ranges, missing options and features your model has no attribute for, with the supplier’s original value shown next to the result.

Why the same feature arrives in many forms

Take one attribute, the weight of a small part. Across a handful of supplier files it can arrive as:

• 0.09 kg in a PDF data sheet;
• 90 g in a price list;
• 90g in an update file, with no space;
• 0,09 in a column called “Weight (kg)”, with a decimal comma;
• “approx. 90 grams” in an email.

These examples are made up for illustration, and most catalogue teams will recognise them. All five mean roughly the same thing, and none of them can go into a grams attribute as it stands.

Materials behave the same way. “Stainless steel”, “INOX”, “SS304” and “rostfrei” can all describe one option in your material list, or two different ones, depending on how detailed your model is.

Suppliers write for their own catalogue, their own country and their own system. Your PIM expects one form. The mapping between the two is the work this guide is about. For where this step sits in a full onboarding flow, see our guides for Pimcore and Ergonode, and for reading values out of PDFs, supplier PDF data sheets.

Units: store what the attribute expects

Know how your PIM holds units

Each PIM models units a little differently, and the mapping rules follow from that:

• Akeneo groups units into measurement families, such as Weight. Each family has a standard unit used to convert the others (kilogram for Weight). A measurement attribute holds a value and a unit, and values are converted to the units set for a channel when you export products for it.
• Pimcore keeps a global list of units for Quantity Value fields, and each field can be limited to a set of valid units. A factor and an offset define how a unit converts to its base unit, so 2 m becomes 2000 when the field is switched to mm. An Input Quantity Value field accepts text instead of a strict number.
• Ergonode has a Unit attribute type: you choose the unit when you create the attribute, from the units in the system settings. In an Ergonode Transfer products file, a unit attribute takes a plain number.

Whatever the system, decide per attribute which unit you store, and convert every supplier value to it before or during import. In an Ergonode Transfer file, that number has to be in the attribute’s unit already. In Akeneo and Pimcore the unit travels with the value, but a catalogue that mixes grams and kilograms on one attribute is harder to filter, compare and check.

Write down the conversion rules

Keep one rule per unit you accept: kg to g multiplies by 1,000, inches to mm by 25.4, pounds to grams by 453.59237. Temperature needs an offset as well as a factor, which is why Pimcore’s units carry both. Keep the list where the whole team can see it, and add to it only when a new unit appears in a real file.

Treat the decimal separator as part of the rule. A supplier from a decimal-comma country writes 0,09, and 1.000 can mean one thousand. Decide per supplier, not per value.

Rounding and precision

Set the precision per attribute (whole grams, one decimal for millimetres) and round once, after conversion. 0.09 kg is exactly 90 g. 3.5 inches is 88.9 mm; rounding it to 89 changes the value, and a reviewer should see that. Never round the source value before converting, and never round twice.

Ranges and tolerances

“100 to 240 V”, “operating temperature -10 to 40 °C” and “12 V ±10%” are not single numbers. Do not keep one end of the range and drop the other. If your model has minimum and maximum attributes, fill both. If it has a nominal value and a tolerance, fill those. If it has neither, the value belongs on the list of features without a place in the model (see below), not in a numeric field.

When not to convert automatically

Automatic conversion is safe when the unit is written next to the value and the rule is exact. Hold the value for a person when:

• the value is approximate (“approx.”, “about”, “max.”);
• the unit is missing, or implied only by a column header that may be wrong;
• the unit is ambiguous: “oz” for weight or volume, “t” for a metric or a short ton;
• the value could refer to something else: net or gross weight, per piece or per pack;
• rounding would change the value beyond your precision.

Option lists and codes

Label and code

An option has a label, the text people read, and a code, the identifier the system stores. “Stainless steel” is a label; stainless_steel is a code. Labels can be translated; codes stay the same in every language.

The three PIMs make this split explicit:

• Akeneo attribute options have a code and labels per locale.
• Pimcore select options have a value and a display value, and the configured value, not the display value, is stored in the database.
• Ergonode Transfer files take option codes for select and multi-select attributes. Its XLS Product Importer can match file values by code or by translation, and a setting decides whether an unmatched value creates a new option.

Map supplier values to codes. Matching on labels is one way to find the code, and it works when the supplier happens to use your wording.

Synonyms

For each option attribute, keep a synonym list: “INOX”, “Stainless”, “stainless steel” and “rostfrei” all point to stainless_steel. Normalise case and spacing before matching, so “Stainless Steel ” and “stainless steel” count as one.

Be careful with values that are more specific than your option. “SS304” is a steel grade. Mapping it to stainless_steel is right if your model does not track grades; it loses information if it does, or if a grade attribute is planned. That is a model decision, not a matching one.

Multi-select values need a split rule too. “Black/White” may be two colours, or one colour name in the supplier’s range. Check a few products before you set the rule.

When no option matches: add, map or skip

A value with no matching option has three possible answers:

1. Add a new option to the list, when the value is a real new choice your customers will filter by.
2. Map it to an existing option, and add it to the synonym list so the next file is handled the same way.
3. Skip it, when the value is noise or too detailed for your catalogue.

The person who decides should own the attribute, usually the catalogue manager or data steward, not whoever happens to run the import that day. An importer setting that creates options automatically is convenient, but every unmatched spelling then becomes a new option, and the list grows duplicates that someone cleans up later.

Here is how the examples above could be handled with a weight attribute in grams and a material list that has stainless_steel:

Values with no place in the model

Suppliers send features your model does not have: a new certification, a cable length on a product family that never had one, an IP rating for a range you only just started selling.

Do not force these values into the nearest attribute or a free-text description. A cable length in a description field cannot be filtered or checked. Instead:

• List them with the product and the file they came from.
• Decide later. Deciding on them need not hold up the rest of the product.
• Look for patterns. When several suppliers send the same feature, it is a candidate for a new attribute. The list makes that visible.

Keep the source next to the converted value

A reviewer who sees only “90” cannot tell whether it was “90 g”, “0.09 kg” or “approx. 90 grams”. Keep the value as the supplier wrote it, the converted value and the place in the file it came from (page, table, row) together, at least until the data is saved. Then the review takes seconds: compare the two, open the source if something looks wrong, approve or correct.

The same record helps months later, when someone asks why a product’s weight changed.

How openProd handles this

openProd is an onboarding layer in front of your PIM. It reads supplier PDFs, spreadsheets and pasted text and matches each value to an attribute of your own catalogue, not a generic template. Values land on your attributes, units and dictionary codes: a weight read as 0.09 kg is saved as 90 when the attribute expects grams, and “Stainless steel” becomes stainless_steel, the code your dictionary uses.

Clear values go straight through. Conversions and values without an attribute wait for a decision in Data review, with the source one click away (Show in source opens the file at the place the value was read). In Decide, you compare the value as read with the value after conversion, then save or skip it, and you can step back one decision. Values your model has no attribute for are listed separately, and deciding on them is optional. Nothing is written until someone clicks Save to catalog.

With the openProd connector for Ergonode, features your suppliers send that Ergonode does not know yet are listed with the products they come from. Your team adds them to Ergonode, maps them to an existing option or skips them. For Pimcore, a connector job reads your Pimcore classes and fields and prepares matching families, attributes, units and dictionaries in openProd; when a mapping needs a business decision, the job ends with a question instead of creating it. For Akeneo and other systems, the connection is agreed with your team and tested in a pilot. More on reading and mapping: AI import.

Checklist

Before the next supplier file arrives:

• Each numeric attribute has one stored unit and a set precision.
• Conversion rules are written down, including temperature offsets.
• The decimal separator is known per supplier.
• Ranges and tolerances have attributes, or a rule to hold them.
• Each option attribute has a synonym list, mapped to codes.
• Someone owns each option list and decides add, map or skip.
• Automatic option creation in your importer is a deliberate choice.
• Values with no attribute are listed, not forced into a field.
• Reviewers see the supplier’s value, the converted value and the source.
• Decisions are recorded, so the next file is handled the same way.

To see this on your own data, a demo takes one of your supplier files through reading, mapping and review. Step-by-step guides are in the tutorials.

Sources and updates

• Akeneo help, measurements and measurement families: help.akeneo.com/serenity-discover-akeneo-concepts/serenity-what-about-measurements
• Akeneo API docs, catalog structure and attribute options: api.akeneo.com/concepts/catalog-structure.html
• Pimcore docs, number types and Quantity Value: docs.pimcore.com/platform/Pimcore/Objects/Object_Classes/Data_Types/Number_Types/
• Pimcore docs, select types: docs.pimcore.com/platform/Pimcore/Objects/Object_Classes/Data_Types/Select_Types/
• Ergonode user manual, creating attributes and the Unit type: usermanual.ergonode.com/product-design/attributes/create-a-new-attribute
• Ergonode user manual, Product importer profiles and mapping: usermanual.ergonode.com/data-exchange/product-importer/profiles
• Ergonode docs, products.csv: docs.ergonode.com/ergonode-transfer/overview/files-format/products.csv

Checked on 13 October 2026. If something has changed, tell us and we will update this page.