Mapping ERP product variants cleanly in the shop

In the shop, the variant item is a presentation format. It carries the title, description, category and the selection fields; what can be bought is one of its versions. In the ERP this presentation format often does not exist at all. There you find twelve items with twelve numbers, twelve stock levels, twelve purchase prices and twelve storage bins, connected at best through a base number field or an item group. The allocation rule for article numbers is clear on this point: each different product is identified by a unique number, so each variant of a product is assigned a different one, and the text explicitly names every size and every colour of a garment as an example (GS1). Anyone who connects an inventory system to the shop therefore transfers items and has to derive the grouping from them, not the other way round.

This asymmetry is not a defect but a division of labour. The shop needs the grouping, because otherwise twelve nearly identical pages compete with one another and the customer has to hunt for the right size. The ERP needs the individual number, because stock, reservations, picking, stocktaking and contribution margin all hang on it. Trouble starts when the integration invents the grouping instead of deriving it. Whoever maintains the variant group in the shop by hand has two versions of the truth from the first new colour onwards: one in the item master and one in the shop database. How a durable transfer path is built instead is described in the article on the product data pipeline between PIM, ERP and shop.

Once the axes are fixed, the matrix is pure combinatorics at first: three colours times four sizes gives twelve cells. All twelve are rarely stocked. Red does not come in XL, blue has been discontinued, the special size arrives with the next season. An integration that merely forms the cartesian product creates twelve purchasable variants in the shop and leaves three of them permanently at zero stock. The customer sees an option they cannot buy, the search engine sees an offer without availability, and sales receives enquiries about items that do not exist. This shows up most sharply in ranges with many axes — in ERP integration for fashion and textiles, size, colour and cut are the normal case, and the matrix quickly has more gaps than filled cells.

The internal article number governs domestic use, the globally unique article number governs the exchange with trading partners. Its allocation rule is strict: each different product is identified by a unique number, so each variant is assigned a different one, and the text names size and colour of a garment as an explicit example (GS1). In practice that means anyone running variants in the shop and also publishing the items through a marketplace integration needs the globally unique number per variant in the item master rather than per product group. Without it, matching falls back on names and descriptions, and the assignment becomes guesswork — with returns that nobody can post cleanly to an item.

For differences that do not justify a globally unique number of their own, the standard offers two additional element strings. The internal product variant has two digits and thereby allows 100 versions to be created for one number (GS1); it is meant for distinctions that are none of the trading partner's business, and the standard states expressly that it must not be used where the variation would trigger the allocation of a different number under the allocation rule. The second element string, for consumer product variants, is alphanumeric and holds up to 20 characters (GS1); it covers differences that do not require a new number but do require communication between trading partners. Neither replaces the number per variant, they complement it. Where another traceability level sits below the variant, a third layer appears; how to organise that is shown in the article on batches and serial numbers between ERP and shop, and where proof of origin is attached to the item as well, the due diligence data from the ERP under the EUDR comes into play.

At this point the catalogue format makes a stipulation that many projects overlook: the item variants have no effect on the price of the item (BMEcat). Variants in that sense are versions that cost the same. As soon as one size carries a surcharge or a special colour is bought in at a higher price, the variant family is the wrong construct: these are then items in their own right with prices of their own, merely displayed together in the shop. That distinction decides whether price maintenance in the ERP reaches the shop or falls back to the family price on the way. Which building blocks work together here is shown in the overview of our ERP integration services.

Stock and images follow the same logic but at a different granularity. Stock hangs on the individual number, whereas the image usually hangs on a single feature value: one image set for black covers all four sizes, and one set per variant would be the same photograph three times over. A workable assignment therefore maps images per feature value and lets the variant refer to them. For prices that differ by customer group or scale, the separation between list price and negotiated price stays as it is; how that path is built is described in the article on price synchronisation in B2B. The same applies on the stock side as soon as several warehouses are involved — see inventory synchronisation across multiple warehouses.

Catalogue exchange brings up a condition that regularly causes rework in projects: a feature carries either a variant list or a fixed value, not both (BMEcat). Colour is therefore either an axis with three versions or a fixed value of black. The hybrid form, in which an item carries a colour value and additionally spans colour variants, is not provided for by the format. That is not bureaucratic ballast; it prevents exactly the state in which the head item claims a colour that its variants contradict. Anyone generating the catalogue out of the ERP should put this check into the interface and let the export fail rather than ship a catalogue the recipient rejects later.

On the output side, the structured data model for search engines has an expression of its own. The type for product groups describes a group of products that vary only in certain well-described ways, and it brings three properties of its own for that purpose (schema.org): the list of variants, the identifier of the group, and the statement of which features vary. It is worth checking the status before implementing: the vocabulary lists these terms in its area of new terms and expressly asks for feedback from practice there, because the definitions are still being sharpened. Anyone emitting them should keep the markup per variant complete — its own number, its own price, its own availability — so that the group stays usable even when a consumer does not recognise the group type. If you would like your variant structure reviewed across both systems, we will go through your item master in an initial call.