Een webshop en ERP-systeem wisselen gegevens uit die elk op een ander moment nodig zijn: van productinformatie en voorraad tot orders en facturen. Je leest hoe die stromen werken, welke keuzes invloed hebben op actualiteit en betrouwbaarheid, en waar het misgaat als niet duidelijk is welk systeem een gegeven beheert.
Bepaal per gegeven welk systeem de bron van waarheid is
Een koppeling begint niet bij de techniek, maar bij de vraag welk systeem een gegeven mag aanpassen. Een ERP bevat vaak de administratieve productcode, inkoopprijs en voorraad. De webshop beheert mogelijk de commerciële producttekst, afbeeldingen en filters. Als beide systemen dezelfde velden mogen wijzigen, kan een synchronisatie een waarde telkens overschrijven. Een medewerker past bijvoorbeeld de productomschrijving aan in de webshop, waarna de volgende ERP-export de oude tekst terugzet.
Leg daarom per gegeven vast waar het ontstaat, waar het gewijzigd mag worden en in welke richting het wordt verstuurd. Dat hoeft niet voor ieder veld hetzelfde te zijn. Een product kan vanuit het ERP komen, terwijl een marketeer de online beschrijving in het CMS beheert. De koppeling moet dan alleen de afgesproken productvelden bijwerken en de redactionele velden ongemoeid laten.
Maak eigenaarschap concreet
Een bruikbare afspraak noemt niet alleen het systeem, maar ook het moment waarop een wijziging geldig wordt. Is een prijs pas actief na goedkeuring? Geldt een klantadres direct, of pas na verwerking in de administratie? Zulke regels bepalen of de koppeling gegevens meteen doorstuurt of eerst op een status wacht. Zonder deze afspraken ontstaan stille conflicten: de data lijkt technisch gesynchroniseerd, maar de webshop toont niet de waarde die de organisatie bedoelde.
Productgegevens van ERP naar webshop vertalen
Productgegevens lijken eenvoudig, maar de systemen gebruiken vaak verschillende structuren. Een ERP kan werken met een artikelnummer, basiseenheid en administratieve omschrijving. De webshop heeft daarnaast een URL, categorietoewijzing, kenmerken, afbeeldingen en teksten voor productpagina’s nodig. Een koppeling moet daarom niet alleen velden kopiëren, maar ook bepalen hoe waarden worden vertaald. Zo kan een ERP-eenheid als doos overeenkomen met een webshopverpakking van twaalf stuks, terwijl de voorraadadministratie in losse eenheden rekent.
Varianten vragen extra aandacht. Kleur en maat kunnen in het ERP aparte artikelen zijn, terwijl de webshop ze als keuzes onder één hoofdproduct presenteert. De koppeling moet dan weten welke artikelen bij elkaar horen en welke kenmerken zichtbaar worden. Ontbreekt een variantcode of is een attribuut anders gespeld, dan kan een product dubbel verschijnen of niet bestelbaar zijn. Ook ontbrekende afbeeldingen of categorieën kunnen ervoor zorgen dat een technisch correct artikel online niet vindbaar is.
Werk met expliciete veldregels
Maak per veld duidelijk of de waarde verplicht is, hoe die wordt opgemaakt en wat er gebeurt bij een lege waarde. Een lege ERP-omschrijving kan bijvoorbeeld betekenen dat een bestaande webshoptekst behouden blijft, of juist dat die tekst gewist moet worden. Dat verschil moet in de integratie zijn vastgelegd. Gebruik daarnaast een stabiele sleutel, zoals een uniek artikelnummer, om producten terug te vinden. Een naam is daarvoor ongeschikt: die kan veranderen en is zelden uniek. Test vertalingen, varianten en eenheden met echte artikelen voordat de volledige catalogus wordt gesynchroniseerd.
Voorraad synchroniseren zonder onbedoelde overselling
Voorraad is een veranderlijk gegeven dat vaak op meerdere plekken wordt bijgewerkt. Een bestelling verlaagt de beschikbare voorraad in de webshop, terwijl reserveringen, retouren en winkelverkopen in het ERP kunnen worden verwerkt. De koppeling moet daarom onderscheid maken tussen fysieke voorraad, gereserveerde voorraad en voorraad die daadwerkelijk online verkoopbaar is. Een ERP kan bijvoorbeeld honderd stuks registreren, waarvan er twintig al zijn gereserveerd. Als de webshop de fysieke voorraad ontvangt, kunnen er meer bestellingen binnenkomen dan er geleverd kunnen worden.
Ook de synchronisatiefrequentie beïnvloedt het risico. Een nachtelijke voorraadimport is eenvoudig, maar ongeschikt voor artikelen die snel uitverkopen. Een voorraadupdate per wijziging is actueler, maar vraagt om een betrouwbare verwerking van veel berichten. Sommige organisaties tonen bovendien een veiligheidsmarge: bij een voorraad van vijf wordt online bijvoorbeeld maar vier als beschikbaar gemeld. Dat beperkt de kans op overselling als er vertraging of een gelijktijdige verkoop via een ander kanaal is.
Leg vast wat er gebeurt bij nulvoorraad
Bij nul voorraad kan een product verdwijnen, bestelbaar blijven met een langere levertijd of een melding tonen. Die keuze is commercieel en operationeel, niet alleen technisch. Controleer ook hoe de koppeling omgaat met negatieve voorraad, meerdere magazijnen en deelbare voorraad. Als online orders uit verschillende magazijnen mogen komen, moet duidelijk zijn welke locatie wordt aangesproken en wanneer voorraad wordt gereserveerd. Zonder die regels toont de webshop soms een voorraad die administratief klopt, maar niet op tijd beschikbaar is voor verzending.
Prijzen, assortiment en beschikbaarheid consistent houden
Een ERP kan verkoopprijzen beheren, maar in de webshop spelen vaak aanvullende regels. Denk aan tijdelijke acties, klantgroepen, staffelkortingen, valuta en prijzen inclusief of exclusief btw. Als het ERP een prijs exclusief btw aanlevert en de webshop die als consumentenprijs behandelt, ontstaat een zichtbaar prijsverschil. Leg daarom vast welke prijssoort wordt uitgewisseld, hoe belasting wordt berekend en welk systeem kortingen bepaalt. Vermijd dat dezelfde korting zowel in het ERP als in de webshop wordt toegepast.
Assortiment is eveneens meer dan een lijst artikelen. Een artikel kan administratief actief zijn, maar nog niet klaarstaan voor online verkoop. Andersom kan een product tijdelijk niet leverbaar zijn, zonder dat het uit de webshop moet verdwijnen. Een apart publicatiekenmerk of verkoopkanaalstatus helpt om die situaties te onderscheiden. Daarmee voorkom je dat conceptartikelen, interne onderdelen of producten met onvolledige informatie automatisch zichtbaar worden.
Let op geldigheid en volgorde
Actieprijzen hebben meestal een begin- en eindtijd. De systemen moeten dezelfde tijdzone en inclusieve of exclusieve einddatum hanteren; anders kan een aanbieding te vroeg stoppen of te lang actief blijven. Ook is de volgorde van updates belangrijk. Als eerst een nieuwe prijs binnenkomt en pas later de status die het product publiceert, kan de webshop kort een onbedoelde combinatie tonen. Spreek daarom af welke velden samen worden bijgewerkt en of een product pas online mag zodra alle verplichte prijs- en assortimentsgegevens aanwezig zijn. Controleer uitzonderingen zoals gratis artikelen, afgeronde bedragen en prijzen voor zakelijke klantgroepen afzonderlijk.
API-synchronisatie, wachtrijen en vertraging begrijpen
Een API laat systemen gegevens opvragen of wijzigingen aan elkaar doorgeven. Bij periodiek ophalen controleert de webshop of het ERP nieuwe gegevens heeft; bij een gebeurtenisgestuurde koppeling verstuurt een systeem een bericht zodra iets verandert. Periodieke synchronisatie is vaak overzichtelijk en kan storingen opvangen bij een volgende ronde, maar gegevens lopen achter tussen twee controles. Gebeurtenisgestuurde verwerking kan sneller zijn, maar vraagt om een aanpak voor berichten die te laat, dubbel of in een andere volgorde aankomen.
Een wachtrij helpt om werk tijdelijk op te slaan wanneer het ontvangende systeem niet bereikbaar is. Een orderbericht kan bijvoorbeeld wachten tot het ERP weer beschikbaar is, in plaats van verloren te gaan. Dat betekent niet dat alles meteen is bijgewerkt: er ontstaat een verschil tussen het moment van bestellen en het moment waarop het ERP de order kent. Dat verschil moet passen bij het proces. Bij beperkte voorraad kan een snelle bevestiging nodig zijn; voor een niet-kritieke productomschrijving is enige vertraging meestal minder problematisch.
Ontwerp voor herhaling en herstel
API-aanroepen kunnen mislukken door time-outs, limieten of tijdelijk onderhoud. Een koppeling probeert zulke berichten doorgaans later opnieuw. Dat is veilig als dezelfde order niet bij elke poging opnieuw wordt aangemaakt. Gebruik daarom een unieke bericht- of orderreferentie en maak verwerking idempotent: herhaling van hetzelfde bericht leidt dan niet tot een tweede order. Stel ook grenzen in aan herhaalpogingen en zet berichten die blijven falen apart voor onderzoek. Zo voorkom je zowel dataverlies als eindeloze automatische pogingen die een storing verergeren.
Webshoporders veilig doorzetten naar het ERP
Een order ontstaat meestal in de webshop, maar wordt in het ERP verder verwerkt voor betaling, voorraad, picking, verzending en administratie. De koppeling moet meer overdragen dan alleen artikelen en aantallen. Denk aan ordernummer, gekozen verzendmethode, kortingsregels, btw-bedragen, valuta, afleveradres en eventuele opmerkingen. Een ontbrekend veld kan de verwerking blokkeren; een verkeerd omgerekend bedrag kan juist ongemerkt tot een administratief verschil leiden.
Een belangrijk ontwerpbesluit is wanneer de webshop een order als bevestigd toont. Dat kan direct na afronding van de checkout zijn, of pas nadat het ERP de order heeft geaccepteerd. Direct bevestigen geeft een vlotte ervaring, maar als het ERP tijdelijk onbereikbaar is, bestaat de order daar nog niet. Wachten op ERP-bevestiging voorkomt dat verschil, maar kan de checkout vertragen. Een wachtrij met een duidelijke status kan een tussenweg zijn: de order is ontvangen, maar nog niet definitief verwerkt.
Behandel orderstatussen als een proces
Stel vast welke status uit welk systeem komt. De webshop kan betaling volgen, terwijl het ERP de magazijn- en factuurstatus beheert. Vertaal statussen expliciet; een ERP-status als vrijgegeven betekent niet automatisch hetzelfde als verzonden. Houd rekening met wijzigingen en annuleringen na het plaatsen van een order. Is annuleren nog toegestaan nadat voorraad is gereserveerd? En hoe worden een gedeeltelijke levering of een terugbetaling vastgelegd? Als statusovergangen niet zijn afgestemd, kan de klant een verzendmelding krijgen terwijl de order nog niet is ingepakt, of kan een annulering niet doorkomen in de administratie.
Klantgegevens, facturen en retouren op elkaar afstemmen
Klantgegevens kunnen bij een consumentenbestelling pas tijdens de checkout ontstaan, terwijl zakelijke klanten vaak al in het ERP bestaan. Om een bestaande relatie terug te vinden, zijn e-mailadres of bedrijfsnaam niet altijd betrouwbaar genoeg: adressen kunnen wijzigen en namen zijn niet uniek. Een klantnummer of een gecontroleerde combinatie van gegevens is meestal geschikter. Leg ook vast of de webshop een nieuw klantrecord mag aanmaken, of dat een medewerker de relatie eerst moet controleren. Anders ontstaan dubbele klantkaarten met verspreide bestel- en factuurhistorie.
Een bestelling kan zowel een factuuradres als een afwijkend afleveradres bevatten. Behandel die als verschillende gegevens, niet als één algemeen klantadres. Voor zakelijke orders kunnen btw-identificatienummer, betalingsconditie en inkoopreferentie nodig zijn. Bepaal bovendien welke gegevens na plaatsing nog aangepast mogen worden en in welk systeem dat gebeurt. Een wijziging van het afleveradres na vrijgave voor verzending vraagt bijvoorbeeld om een ander proces dan een correctie vóór verwerking.
Facturen en retouren volgen hun eigen stroom
Het ERP maakt vaak de formele factuur en kent het factuurnummer, terwijl de webshop de klant de voortgang toont. De koppeling kan dat nummer en de documentstatus terugsturen, maar moet voorkomen dat de webshop zelf een tweede, afwijkende factuur aanmaakt. Bij retouren ontstaan aanvullende gebeurtenissen: ontvangst, kwaliteitscontrole, voorraadmutatie en terugbetaling. Die stappen vallen niet altijd op hetzelfde moment. Spreek af wanneer een retour de verkoopbare voorraad verhoogt en wanneer een creditnota of terugbetaling wordt verwerkt. Zo wordt voorkomen dat een klant al geld terugkrijgt terwijl de retour nog niet is beoordeeld, of dat een artikel direct weer als beschikbaar verschijnt.
Synchronisatiefouten opsporen met controles en logging
Een koppeling kan technisch bereikbaar zijn en toch inhoudelijk verkeerde gegevens verwerken. Voorbeelden zijn een artikel dat aan het verkeerde product is gekoppeld, een order met een afwijkend btw-bedrag of een voorraadbericht dat door een verouderde waarde wordt ingehaald. Alleen controleren of API-aanroepen een succesvolle statuscode teruggeven is daarom onvoldoende. Leg vast welke entiteit is verwerkt, wanneer dat gebeurde, welke referentie is gebruikt en of de bestemming de wijziging accepteerde. Sla geen onnodige gevoelige klantinformatie op in logs; gebruik waar mogelijk interne identificaties en beperkte foutdetails.
Maak fouten zichtbaar voor de mensen die ze kunnen oplossen. Een bericht dat na meerdere pogingen niet verwerkt wordt, hoort in een overzicht met de oorzaak, betrokken order of artikel en mogelijkheid tot gecontroleerde herverwerking. Een generieke melding zoals synchronisatie mislukt maakt onderzoek lastig. Tegelijk is automatische herverwerking niet altijd veilig: als het ERP de order al heeft aangemaakt maar de bevestiging verloren ging, kan opnieuw versturen een duplicaat veroorzaken. Controleer daarom eerst de referentie in het ontvangende systeem.
Vergelijk systemen op betekenisvolle momenten
Periodieke controles kunnen verschillen opsporen die niet direct een foutmelding opleverden. Vergelijk bijvoorbeeld aantallen orders per dag, totale orderbedragen, openstaande berichten en beschikbare voorraad voor hardlopers. Een controle op aantallen is snel, maar toont niet welk record afwijkt; detailcontroles kosten meer verwerkingstijd. Kies de diepgang op basis van het risico en de hoeveelheid data. Leg ook vast wie verschillen onderzoekt en hoe correcties worden teruggeschreven. Een handmatige aanpassing zonder registratie kan het probleem tijdelijk verbergen en bij de volgende synchronisatie opnieuw laten ontstaan.