Webshop koppeling laten maken met de systemen die je al hebt

Waarmee je een webshop koppelt

Een webshop heeft zes kanten waar gegevens vandaan komen of naartoe gaan. Welke je koppelt hangt af van waar nu het overtypen zit.

Business Central is de opvolger van Navision (Dynamics NAV). Alle systemen, ook de pakketten die hier niet genoemd zijn, staan op het overzicht van koppelingen.

Eén artikel, vier codes

De kolom "waarop gematcht wordt" is waar het in de praktijk op vastloopt. Hetzelfde koppelstuk heeft in elk systeem een andere code:

Vier codes voor één artikel, en geen systeem kent ze alle vier. De koppeling houdt een kruistabel bij waarin ze naast elkaar staan. Een artikel zonder regel in die tabel gaat naar de controlelijst. Het wordt niet stil overgeslagen. Wat je als sleutel kiest en waarom staat in koppelen op SKU of op EAN.

Wat er heen en terug gaat

Eén order raakt op een dag vijf systemen. Een voorbeeld met order 20418, 12 stuks van KS-22-MS:

Zes overdrachten, en bij elke overdracht verandert de vorm van de gegevens. Het bericht van 14:11 ziet er zo uit:

{
  "order": "20418",
  "status": "verzonden",
  "zendingen": [
    {
      "vervoerder": "PostNL",
      "trackcode": "3SABCD0123456",
      "regels": [ { "sku": "KS-22-MS", "aantal": 12 } ]
    }
  ]
}

zendingen is een lijst. Bij een deellevering staan er twee in, elk met een eigen trackcode en eigen regels, en de webshop toont de status per zending. Een koppeling die één trackcode per order doorgeeft, overschrijft bij de tweede zending de eerste.

Achter die ene order zitten vijf stromen, elk met een eigen richting en een eigen tempo:

• Productdata: van PIM, ERP of leverancier naar de webshop, bij wijziging of één keer per nacht.
• Voorraad en beschikbaarheid: naar de webshop, bij elke mutatie of om de paar minuten.
• Prijzen en klantafspraken: naar de webshop, meestal één keer per nacht.
• Orders, klanten en verzending: uit de webshop, direct na de bestelling, met de status terug.
• OCI en PunchOut: een sessie vanuit het inkoopsysteem van je klant.

Welke stroom direct moet en welke 's nachts kan, staat in realtime of batch.

Welk webshopplatform je ook draait

Elk platform geeft zijn gegevens op een eigen manier vrij en stelt eigen grenzen. Die grenzen bepalen hoe de koppeling wordt opgezet.

De getallen zijn op 3 oktober 2026 nagelezen in de documentatie van elk platform, waaronder die van Shopify, Lightspeed en WooCommerce.

8.000 artikelen bijwerken, op drie platformen

Dezelfde taak, de voorraad van 8.000 artikelen in de webshop zetten, kost per platform een ander aantal aanroepen:

• Lightspeed, 100 varianten per bulkaanroep (PUT /variants/bulk.json). 8.000 gedeeld door 100 is 80 aanroepen. Per artikel apart zijn het er 8.000: 2 uur en 40 minuten bij de grens van 3.000 per uur, en 8.000 van de 12.000 aanroepen van die dag.
• WooCommerce, 100 artikelen per batch. 8.000 gedeeld door 100 is 80 aanroepen.
• Shopify, 250 voorraadregels per aanroep. 8.000 gedeeld door 250 is 32 aanroepen.

Het verschil zit dus in hoe de koppeling schrijft, niet alleen in het platform. Op Lightspeed gaat ook de bulkaanroep in porties van 100, en bij 400 gewijzigde artikelen zijn dat 4 aanroepen. Is de webshop gekoppeld aan de Lightspeed-kassa (R-Series), dan zijn artikelen en varianten via de webshop-API alleen te lezen en loopt het schrijven via de kassa-API. De som voor je eigen aantallen maak je met doorvoer berekenen.

De grens bij webhooks werkt de andere kant op. Shopify wacht 5 seconden op een antwoord en probeert het bij een fout nog 8 keer in 4 uur. WooCommerce schakelt een webhook na 5 mislukte afleveringen op rij uit, en daarna komt er geen order meer binnen zonder dat iets een fout meldt. De koppeling beantwoordt een webhook daarom direct en verwerkt de order daarna vanuit de wachtrij. Elke nacht vergelijkt hij de orders in de webshop met wat er is aangekomen. Meer hierover in wat is een webhook.

Velden die het platform niet heeft

Een product in WooCommerce heeft een voorraadaantal (stock_quantity) en een voorraadstatus (stock_status), en geen veld voor de verwachte leverdatum van je leverancier. Een artikel met voorraad 0 dat morgen binnenkomt en een artikel met voorraad 0 dat over zes weken komt, zien er in de webshop hetzelfde uit. De datum staat wel in het bestand van de leverancier of in de inkooporder in het ERP.

De koppeling zet zo'n waarde in een eigen veld van het platform: een metafield bij Shopify, meta_data bij WooCommerce, een eigen attribuut bij Magento. Voor WooCommerce ziet de update van één artikel er zo uit:

{
  "sku": "KS-22-MS",
  "stock_quantity": 0,
  "meta_data": [
    { "key": "verwachte_leverdatum", "value": "2026-10-14" }
  ]
}

Het thema van de webshop toont het veld daarna als "verwacht op 14 oktober". Hetzelfde geldt voor elke waarde waar het platform geen standaardveld voor heeft, zoals het bestelnummer 44-1082 van de leverancier: de koppeling vult een eigen veld. Hoe dat voor levertijden werkt staat bij levertijd synchroniseren.

Plugin, koppelplatform of maatwerk

Een plugin leest één bron in één formaat. Dat gaat goed tot de tweede leverancier. Dit zijn de eerste regels uit de bestanden van twee leveranciers voor hetzelfde artikel:

leverancier A (puntkomma, eigen bestelnummer, levertijd als duur)
artikelnr;voorraad;levertijd
44-1082;14;2 werkdagen

leverancier B (komma, EAN, levertijd als datum)
"ean","stock","eta"
"8712345678906","9","14-10-2026"

Drie verschillen in twee regels: het scheidingsteken, de sleutel en de vorm van de levertijd. "2 werkdagen" en "14-10-2026" zijn pas te vergelijken met een kalender van werkdagen erbij. Daarbovenop komt de vraag wat er geldt als beide leveranciers het artikel voeren: 14 plus 9 is 23 stuks, of alleen de 14 van de leverancier met de kortste levertijd. Een plugin met één mapping heeft voor die keuze geen instelling.

Maatwerk is aan de orde zodra een regel van jouw bedrijf niet in een instelling past. Wat dat inhoudt staat op maatwerk koppeling laten maken. De technische vergelijkingen staan in maatwerk of plugin en koppeling of koppelplatform.

Meerdere kanalen op één voorraad

Naast de webshop verkoop je via bol, een tweede shop of een B2B-portaal. Alle kanalen verkopen uit dezelfde voorraad en ze weten niet van elkaar wat er net is verkocht.

Twee regels houden dat kloppend. De eerste is een buffer per kanaal: van artikel 10482 liggen 14 stuks vrij, de webshop toont 14 en bol krijgt 12. De 2 stuks verschil vangen de minuten op tussen een verkoop op het ene kanaal en de update op het andere. De tweede is een voorvoegsel per kanaal op het ordernummer: WS-10482 en BOL-10482 zijn in het ERP twee orders, ook al gaf elk kanaal zelf het nummer 10482 uit.

Hoe groot de buffer moet zijn staat bij veiligheidsvoorraad. Wat er gebeurt als het toch misgaat, staat in twee klanten, het laatste exemplaar.

Wat je krijgt

Wij bouwen de koppeling voor een vaste prijs en hosten, draaien en bewaken hem daarna voor een vast bedrag per maand. De opbouw daarvan staat op koppeling laten bouwen.

De koppeling draait eerst als dry run: hij verwerkt de echte gegevens en schrijft niets, zodat je per artikel ziet wat er zou veranderen. Daarna kies je per stroom of wijzigingen op jouw akkoord wachten of direct doorgaan. In het dashboard staat per run wat er is gewijzigd, bijvoorbeeld artikel 10482, voorraad, van 14 naar 8, en wat er op de controlelijst staat met de reden erbij. Past een platform zijn API aan, dan passen wij de koppeling aan.

Vertel welk platform je draait en welke systemen erachter staan. Je hoort welke stromen er zijn en waar de grenzen van jouw platform liggen.