{"id":147,"date":"2026-10-26T09:00:00","date_gmt":"2026-10-26T08:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=147"},"modified":"2026-09-20T21:40:42","modified_gmt":"2026-09-20T19:40:42","slug":"configuratoropties-echte-woocommerce-producten","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/modelling-configurator-options-as-actual-woocommerce-products\/","title":{"rendered":"Modelling configurator options as actual WooCommerce products"},"content":{"rendered":"

Model a configurator option as an actual WooCommerce product when that choice has its own stock, price, tax, SKU or order handling.<\/strong> Store simple preferences as metadata, but add physical or separately managed components as their own cart lines. This keeps the catalogue and order chain authoritative.<\/p>\n

A configurator may visually look like a single product while the actual configuration consists of several items. If every choice disappears into one text field, stock cannot be reserved per component and the warehouse cannot see what to pick. Conversely, turning every colour or text label into a product makes the catalogue unnecessarily complex. The boundary follows the operational meaning.<\/p>\n

Use a decision rule for each option<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Does the option have\u2026<\/th>\nModel as<\/th>\nExample<\/th>\n<\/tr>\n<\/thead>\n
Its own SKU and stock<\/td>\nSeparate product line<\/td>\nMounting kit or extra panel<\/td>\n<\/tr>\n
Its own tax or shipping behaviour<\/td>\nSeparate product line<\/td>\nInstallation service or heavy component<\/td>\n<\/tr>\n
Only a customer preference<\/td>\nValidated metadata<\/td>\nHandle position<\/td>\n<\/tr>\n
Free-form personalisation text<\/td>\nBounded metadata<\/td>\nShort engraving<\/td>\n<\/tr>\n
A choice that determines the main variant<\/td>\nProduct variation<\/td>\nStandard size and base colour<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Also ask who manages the option. If operations must be able to change its price or stock in WooCommerce without changing the configurator, that points towards an actual product. If the choice only helps display production instructions and is never sold separately, metadata may be more logical.<\/p>\n

Keep the customer-facing view as one whole<\/h2>\n

Separate cart lines do not have to look like disconnected, confusing products. Link them to a main line, group them visually and make clear that they belong to the configuration. Prevent customers from removing a required component separately or changing its quantity independently when that is technically not allowed.<\/p>\n

Calculate totals using the current products' WooCommerce prices. Do not copy an old price from the browser. Check on the server that a selected product is actually permitted in this configurator and the requested quantity is within the limits. For more on the order chain that follows, see reliably integrating an online store and ERP<\/a>.<\/p>\n

Test discount and tax rules against the chosen structure. A coupon for the main product need not automatically apply to an installation service; a free add-on may still need to remain an actual zero-price line so the warehouse can see it. Have the responsible specialists determine the commercial and tax setup, and ensure the technology consistently applies their chosen rules.<\/p>\n

Fictional example: a modular workbench<\/h2>\n

Workshop supplier Staal & Vorm sells a workbench with optional drawers, wheels and an engraved nameplate. The drawer cabinet and wheel set have their own SKUs, stock and picking locations. They are therefore added as linked product lines. The engraving text remains bounded metadata attached to the nameplate.<\/p>\n

In the basket, customers see one configuration block containing the main product and components. When they increase the number of workbenches from one to two, the required wheel sets scale with them. A one-off engraving instruction is not simply doubled; the interface asks whether both nameplates should have the same text. In the warehouse, all actual items appear as separate picking lines.<\/p>\n

When transferred to the ERP, SKUs and quantities remain recognisable, while the configuration group can be included as a relationship. An integration such as Yindle Connect<\/a> can translate that final structure into the back-end systems in a controlled way.<\/p>\n

Staal & Vorm also stores a readable configuration summary on the order. That summary helps customer service and the customer, but does not replace structured SKUs. A product label changed later can otherwise make a historical order difficult to understand. Keep both stable identification and the label displayed at the time of ordering.<\/p>\n

Data model checklist<\/h2>\n