Configuratoropties als echte WooCommerce-producten modelleren

Modelleer een configuratoroptie als echt WooCommerce-product wanneer die keuze eigen voorraad, prijs, belasting, SKU of orderafhandeling heeft. Bewaar eenvoudige voorkeuren als metadata, maar voeg fysieke of afzonderlijk beheerde onderdelen als eigen cartregel toe. Zo blijven catalogus en orderketen de waarheid.

Een configurator kan visueel één product lijken terwijl de uitvoering uit meerdere artikelen bestaat. Als alle keuzes in één tekstveld verdwijnen, kan voorraad niet per onderdeel worden gereserveerd en ziet het magazijn niet wat moet worden gepickt. Omgekeerd maakt ieder kleur- of tekstlabel als product de catalogus onnodig complex. De grens volgt de operationele betekenis.

Gebruik een beslisregel per optie

Heeft de optie… Modelleer als Voorbeeld
Eigen SKU en voorraad Aparte productregel Montageset of extra paneel
Eigen belasting- of verzendgedrag Aparte productregel Installatieservice of zwaar onderdeel
Alleen een klantvoorkeur Gevalideerde metadata Positie van een handgreep
Vrije personalisatietekst Begrensde metadata Korte gravure
Keuze die hoofdvariant bepaalt Productvariatie Standaardmaat en basiskleur

Vraag ook wie de optie beheert. Als operations de prijs of voorraad in WooCommerce moet kunnen aanpassen zonder de configurator te wijzigen, wijst dat naar een echt product. Als de keuze uitsluitend helpt om productie-instructies te tonen en nooit afzonderlijk wordt verkocht, kan metadata logischer zijn.

Houd de klantweergave als één geheel

Aparte cartregels hoeven niet als losse, verwarrende producten te ogen. Koppel ze aan een hoofdregel, groepeer ze visueel en maak duidelijk dat zij onderdeel zijn van de configuratie. Voorkom dat een klant een verplicht onderdeel los verwijdert of het aantal onafhankelijk verandert wanneer dat technisch niet mag.

Bereken totalen met WooCommerce-prijzen van de actuele producten. Kopieer geen oude prijs uit de browser. Controleer server-side dat een gekozen product daadwerkelijk aan deze configurator is toegestaan en dat het gevraagde aantal binnen de grenzen valt. Meer over de orderketen daarna staat bij webshop en ERP betrouwbaar koppelen.

Test kortings- en belastingregels op de gekozen structuur. Een coupon voor het hoofdproduct hoeft niet automatisch voor een installatieservice te gelden; een gratis add-on kan wel een echte regel met nulprijs moeten blijven zodat het magazijn hem ziet. Laat commerciële en fiscale inrichting door de verantwoordelijke specialisten bepalen en zorg dat de techniek hun gekozen regels consequent uitvoert.

Fictief voorbeeld: een modulaire werkbank

Werkplaatsleverancier Staal & Vorm verkoopt een werkbank met optionele lades, wielen en een gegraveerd naamplaatje. De ladekast en wielenset hebben eigen SKU’s, voorraad en picklocaties. Zij worden daarom als gekoppelde productregels toegevoegd. De gravuretekst blijft begrensde metadata bij het naamplaatje.

De klant ziet in de winkelwagen één configuratieblok met hoofdproduct en onderdelen. Wanneer hij het aantal werkbanken van één naar twee verhoogt, schalen de verplichte wielensets mee. Een eenmalige gravure-instructie wordt niet zomaar verdubbeld; de interface vraagt of beide naamplaatjes dezelfde tekst krijgen. In het magazijn verschijnen alle echte artikelen als afzonderlijke pickregels.

Bij overdracht naar ERP blijven SKU’s en aantallen herkenbaar, terwijl de configuratiegroep als relatie kan worden meegestuurd. Een integratie zoals Yindle Connect kan die definitieve structuur gecontroleerd naar de achterliggende systemen vertalen.

Staal & Vorm bewaart ook een leesbare configuratiesamenvatting op de order. Die samenvatting helpt klantenservice en klant, maar vervangt de gestructureerde SKU’s niet. Een later gewijzigd productlabel maakt de historische order anders moeilijk te begrijpen. Bewaar daarom zowel stabiele identificatie als het label dat tijdens bestellen zichtbaar was.

Controlelijst voor het datamodel

  • Bepaal per keuze of voorraad, prijs, belasting of fulfilment zelfstandig is.
  • Gebruik stabiele product- en variatie-ID’s, geen alleen zichtbare labels.
  • Sta uitsluitend vooraf toegestane add-onproducten toe.
  • Valideer aantallen en beschikbaarheid opnieuw op de server.
  • Bewaar de relatie tussen hoofdproduct en onderdelen in cart én order.
  • Definieer verwijderen, aantallen wijzigen en sessieherstel als groep.
  • Toon een begrijpelijke configuratiesamenvatting aan klant en magazijn.
  • Test prijswijziging, uitverkocht onderdeel en een verwijderde optie.

Maak eerst een klein domeinmodel op papier voordat je de interface tekent. Daarmee ontdek je welke keuze werkelijk product, variant, service of instructie is. Als standaardplugins dit model niet betrouwbaar ondersteunen, helpt de afweging maatwerksoftware of standaardsoftware om de juiste grens te kiezen.

Neem retouren en annuleringen in die schets mee, ook al vallen zij buiten de eerste configuratorschermen. Als één onderdeel wordt teruggestuurd, moet duidelijk blijven bij welke hoofdconfiguratie het hoorde en of andere onderdelen daardoor nog bruikbaar zijn. Ontwerp die relatie vóór orders ontstaan; achteraf reconstrueren uit beschrijvingen is foutgevoelig.

Laat Yindle het datamodel voor jouw productconfigurator uitwerken.

De beschreven modellering is beschikbaar in Yindle Kit Configurator. Lees ook hoe een configurator met echte producten wordt opgebouwd voordat je opties aan je catalogus koppelt.

Vorig inzicht
Volgend inzicht

Begin met je vraag

Waar loopt jouw team op vast?

Een eerste vraag hoeft geen technische briefing te zijn. Vertel welke systemen je gebruikt en waar het werk nu blijft liggen. Samen bespreken we wat mogelijk is en welke stap je daarna kunt zetten.

Bespreek mijn vraag