Hoe een koppeling werkt

Welke gegevens tussen je systemen bewegen

Tussen een webshop en de systemen erachter lopen vijf stromen. Vier daarvan verplaatsen gegevens: productdata, voorraad, prijzen en orders. De vijfde, OCI en PunchOut, is een sessie: de inkoper van je klant komt vanuit zijn eigen inkoopsysteem je webshop binnen en neemt zijn winkelmand mee terug.

Bij elke stroom begint het werk met dezelfde drie vragen. Uit welk systeem komt het gegeven? Wanneer moet het in het andere systeem staan? En welk systeem is leidend als de twee iets anders zeggen?

Eén eigenaar per gegeven

Onder alle vijf ligt dezelfde regel: elk gegeven heeft precies één systeem dat erover beslist. Dat leg je vast per veld, niet per systeem. De voorraad komt uit het WMS, de prijs uit het ERP en de productomschrijving uit het PIM, ook als alle drie de systemen een veld voor voorraad, prijs en omschrijving hebben.

Zonder die afspraak overschrijven systemen elkaar. Het ERP heeft voor artikel 10482 een verkoopprijs van € 12,50. Iemand zet de prijs in de webshop voor een actie op € 9,95. De prijsronde van die nacht zet er weer € 12,50 neer, en de actie die morgen in de nieuwsbrief staat klopt niet meer.

Met een eigenaar per veld staat de uitkomst vooraf vast. Het ERP is leidend voor de prijs, en artikel 10482 staat tot het einde van de actie op de lijst met uitzonderingen die de koppeling overslaat.

Waar de koppeling draait

Een koppeling van ons draait op onze servers, tussen je systemen. Je webshop, je ERP en je WMS blijven zoals ze zijn. De koppeling praat met elk systeem langs de weg die dat systeem aanbiedt: een API, een webhook, een bestand op SFTP. Elk systeem krijgt zijn eigen toegang, die je in dat systeem kunt intrekken.

De koppeling is gebouwd op jouw systemen en jouw regels: welk systeem leidend is voor welk gegeven, welke voorraad meetelt, welke klant welke prijs krijgt. Die regels zitten in de koppeling en niet in een instellingenscherm met vaste keuzes. Waar standaardkoppelingen technisch ophouden staat op maatwerk koppeling laten maken.

Per stroom: per wijziging of in rondes

Niet elke stroom hoeft even snel. Een order hoort binnen een minuut in het ERP, een prijslijst die eens per week verandert niet. Per stroom ligt vast wat hem start:

Elke ronde kost verzoeken, en een API heeft een limiet. Een rekenvoorbeeld met Exact Online, dat 60 verzoeken per minuut en 5.000 per dag toestaat. 400 orders per dag à 3 verzoeken is 1.200. Een voorraadronde elke 5 minuten met 1 verzoek is 288 per dag. Een prijsronde elk uur is 24. Samen 1.512, en er blijven er 3.488 over voor herhaalde pogingen en een volledige inlees na een storing. Diezelfde voorraad per artikel opvragen zou bij 8.000 artikelen elke ronde 8.000 verzoeken kosten, meer dan het hele dagbudget. De som voor je eigen aantallen maak je met doorvoer berekenen; de afweging staat in realtime of batch.

Als een systeem niet antwoordt

Systemen zijn soms traag, in onderhoud of over hun limiet. Een koppeling die dan een bericht laat vallen, verliest een order. Daarom gaat alles via een wachtrij.

De koppeling neemt een webhook direct aan en verwerkt hem daarna. Dat is nodig, want de afzender wacht niet lang: Shopify geeft 5 seconden, Picqer 10. Wie te laat antwoordt, krijgt het bericht opnieuw. Bij herhaald falen zet de afzender de webhook uit: WooCommerce na 5 mislukte meldingen op rij, Picqer na 5 volledig mislukte meldingen binnen 24 uur.

Weigert het ERP een verzoek, dan volgt een nieuwe poging met een pauze die steeds langer wordt, bijvoorbeeld na 1, 2, 4 en 8 minuten. Elke poging draagt dezelfde sleutel, het ordernummer uit de webshop, zodat order 20418 één keer in het ERP komt, ook na drie pogingen. Wat na de laatste poging niet is aangekomen, gaat naar een lijst met mislukte berichten, met de oorspronkelijke inhoud en de foutmelding. Er verdwijnt niets zonder dat het ergens staat. Hoe wij een afwijking zien voordat je klant hem ziet, staat bij monitoring.

Wat je ziet in je login

Bij de koppeling hoort een dashboard met een eigen login. Per run staat er wat er is gelezen, wat er is gewijzigd en wat niet is gelukt:

run 03-10-2026 10:15   orders   Shopify naar Exact Online
gelezen 37   aangemaakt 35   overgeslagen 1   mislukt 1
20418   SalesOrder 7731 aangemaakt
20419   overgeslagen   staat op de uitsluitingslijst: proefzending
20420   mislukt        debiteur niet gevonden, btw-nummer NL001234567B01

Vier dingen houden de koppeling in jouw hand. Een dry run rekent alles door en schrijft niets: je ziet per order en per artikel wat er zou gebeuren. Goedkeuring laat een stroom wachten op jouw akkoord, of een run die meer dan een ingesteld percentage wijzigt. Uitsluitingen laten artikelen of klanten met een handmatige afspraak met rust. Overrides zetten een eigen waarde vast, zoals een levertijd. Na elke run staat per wijziging van welke waarde naar welke, en waardoor. De onderdelen staan bij dry run en goedkeuring en audit trail.

Als een bron verandert

Een koppeling die vandaag werkt, heeft over een jaar onderhoud nodig. De systemen eromheen veranderen, op aangekondigde data:

Daarnaast veranderen leveranciers hun bestanden zonder aankondiging: een kolom heet stock in plaats van voorraad, een tabblad schuift op. Een run die zo'n verandering tegenkomt, stopt en meldt welk veld ontbreekt. Wij passen de koppeling aan, op de nieuwe versie of het nieuwe bestand, voordat de oude stopt.

De bouw heeft een vaste prijs, afgesproken voordat het werk begint. Het hosten, draaien, bewaken en het dashboard vallen onder een vast bedrag per maand. Welke systemen we koppelen staat op koppelingen. Vertel welke systemen je hebt en waar het vastloopt.

Gegevensuitwisseling bij verkoop aan bedrijven

Van alle software koppelingen rond een webshop komen deze vijf het vaakst voor:

• Webshop en ERP. Orders gaan het ERP in. Voorraad, prijzen en verzendstatus komen terug.
• ERP en boekhouding. Facturen, betalingen en grootboekregels lopen door, met per verkoopkanaal een eigen grootboekrekening en dagboek.
• CRM en ERP. De verkoper ziet in het CRM wat een klant heeft afgenomen en welke facturen openstaan.
• WMS en vervoerder. De zending wordt aangemeld, het label komt terug en de track-and-tracecode gaat naar de klant.
• PIM en verkoopkanalen. Een nieuw artikel of een gewijzigde omschrijving gaat in één keer naar de webshop en de marktplaatsen.

De rekensom achter de eerste: vijftig orders per dag die elk drie minuten overtypen kosten, zijn 150 minuten. Dat is tweeënhalf uur per dag, en elke overgetypte order is een kans op een fout in een adres of een aantal.

Voor een webshop lopen de gegevens in drie richtingen:

De B2B-laag erbovenop

Verkoop je zakelijk, dan komen er drie dingen bij: prijsafspraken per klant, staffels en bestellen op rekening. Hier houden standaardkoppelingen en koppelplatformen meestal op: ze zetten prijzen door op het niveau van een klantgroep, niet per klant.

De omvang bepaalt de aanpak. Vijftig klanten met een eigen prijs houd je met de hand bij. Vijfhonderd klanten op een assortiment van 2.000 artikelen zijn 1.000.000 mogelijke combinaties van klant en artikel. Die zet je niet een voor een over. De koppeling neemt de regels over waaruit het ERP de prijs opbouwt: prijslijst, klantkorting en staffel. Hoe dat per onderdeel werkt staat bij klantspecifieke prijzen, staffelprijzen en bestellen op rekening.

Veldmapping, wachtrijen, toegang en bewaking

Gegevens van A naar B brengen is het kleinste deel. Wat een koppeling betrouwbaar maakt, staat eromheen:

Als een systeem onbereikbaar is

Het ERP is van 14:00 tot 14:40 onbereikbaar door een update. Order 10482 komt om 14:00 binnen. De koppeling probeert het direct, dan na 30 seconden, na 2 minuten en na 8 minuten: elke pauze is vier keer zo lang als de vorige. De vijfde poging, 32 minuten later om 14:42:30, lukt. De order heeft 42 minuten en 30 seconden in de wachtrij gestaan en staat één keer in het ERP.

Elke poging stuurt dezelfde sleutel voor de order mee, zodat een herhaling geen tweede order aanmaakt. Een bericht dat na de laatste poging nog niet is aangekomen, gaat met de oorspronkelijke inhoud naar een foutenlijst en wordt na herstel opnieuw verwerkt. Er verdwijnt niets ongemerkt. De kant van de binnenkomende berichten staat in wat is een webhook; het hele verloop van een storing in wat gebeurt er als een koppeling uitvalt.

Rechten en sleutels

Een koppeling krijgt alleen de rechten die hij gebruikt. Leest hij artikelen en schrijft hij orders, dan heeft hij geen toegang tot de salarisadministratie nodig. Een koppeling onder een beheerdersaccount is bij de bouw sneller en komt daardoor veel voor. Elk lek in zo'n koppeling is dan een lek in het hele pakket.

Verbindingen lopen over TLS. Sleutels horen in een kluis voor geheimen en niet in code, in een configuratiebestand of in een spreadsheet, zodat een sleutel vervangen kan worden zonder de koppeling opnieuw te bouwen.

Jij houdt de controle

Een nieuwe koppeling draait eerst droog. Een dry run verwerkt de echte gegevens zonder iets naar de webshop of het ERP te schrijven en laat zien wat er zou veranderen. Daarna bepaal je per stroom of wijzigingen op goedkeuring wachten of direct doorgaan. Artikelen met een handmatige afspraak, zoals een vaste actieprijs, zet je op een uitsluitingslijst. Een eigen levertijd leg je vast met een override.

Na elke run staat er een overzicht van wat er is gewijzigd, per artikel en per veld: artikel 10482, voorraad, van 14 naar 8. Belt een klant over een verkeerde levertijd, dan zie je terug wanneer die waarde binnenkwam en uit welke bron. De onderdelen hebben elk een eigen pagina: dry run en goedkeuring, monitoring en audit trail.

Wij bouwen de koppeling voor een vaste prijs op jouw systemen en jouw regels. Daarna hosten, draaien en bewaken we hem voor een vast bedrag per maand, en passen we hem aan als een bron verandert. Je krijgt een dashboard met logs en een eigen login. Meer over die opzet staat op maatwerk koppeling laten maken.