Een migratie naar Shopify is pas geslaagd wanneer niet alleen de webshop werkt, maar ook de systemen erachter betrouwbaar blijven samenwerken. Productinformatie moet op tijd worden bijgewerkt, prijzen moeten kloppen, voorraad mag niet dubbel worden verkocht en orders moeten zonder handmatige omwegen in ERP, magazijn en financiële administratie terechtkomen.
Een bestaande ERP- of PIM-koppeling kan meestal niet één-op-één naar Shopify worden gekopieerd. Shopify gebruikt een eigen datamodel, API’s, locaties, orderstatussen en gebeurtenissen. Daardoor moeten gegevensstromen, verantwoordelijkheden en foutafhandeling opnieuw worden ontworpen.
In deze gids leggen we uit hoe je ERP- en PIM-koppelingen voor Shopify opnieuw inricht, welke architectuurkeuzes er zijn, hoe je bronhouderschap bepaalt, welke processen extra aandacht vragen en wat een professioneel integratietraject ongeveer kost.
Waarom kun je een bestaande koppeling niet gewoon overzetten?
Een koppeling verbindt niet alleen twee technische systemen. Zij vertaalt ook processen en datamodellen. Een product, voorraadpositie of order kan in het huidige e-commerceplatform anders zijn opgebouwd dan in Shopify.
Denk bijvoorbeeld aan verschillen in:
- product- en variantstructuren;
- categorieën, collecties en attributen;
- interne en externe identificatienummers;
- voorraden per magazijn of locatie;
- prijzen, kortingen en valuta;
- B2B-bedrijven, contactpersonen en vestigingen;
- order-, betaal- en fulfilmentstatussen;
- deelzendingen, retouren en terugbetalingen;
- talen en marktgebonden content;
- API’s, webhooks en authenticatie;
- snelheids- en capaciteitslimieten.
Wanneer een bestaande connector ooit voor Magento, WooCommerce, Shopware, PrestaShop, Lightspeed of maatwerksoftware is gebouwd, spreekt deze de taal van dat platform. Shopify vereist een nieuwe vertaling.
Soms kan dezelfde middleware of integratiepartner worden behouden. De mapping, processen en endpoints moeten vrijwel altijd worden aangepast. Bij verouderde of slecht gedocumenteerde koppelingen kan volledige herbouw verstandiger zijn.
Wat is de rol van een ERP-systeem?
Een ERP-systeem ondersteunt de operationele en financiële processen van de organisatie. Afhankelijk van de inrichting kan het ERP onder meer verantwoordelijk zijn voor:
- artikelnummers en basisproductgegevens;
- inkoop en leveranciers;
- kostprijzen en verkoopprijzen;
- voorraad en magazijnen;
- klant- en debiteurgegevens;
- verkooporders;
- facturatie en creditnota’s;
- belasting en financiële verwerking;
- fulfilment en verzending;
- retouren;
- rapportage en boekhouding.
Niet ieder ERP beheert al deze onderdelen. Sommige organisaties gebruiken het ERP uitsluitend voor finance en voorraad, terwijl productinformatie in een PIM en fulfilment in een WMS wordt beheerd.
Daarom is “we koppelen het ERP” geen volledige functionele omschrijving. Per gegevensdomein moet duidelijk zijn wat het ERP werkelijk doet en welke informatie Shopify nodig heeft.
Wat is de rol van een PIM-systeem?
Een Product Information Management-systeem beheert productinformatie die voor verkoop, presentatie en distributie nodig is. Een PIM kan onder meer bevatten:
- productnamen en commerciële omschrijvingen;
- kenmerken en specificaties;
- categorieën en classificaties;
- merken en productfamilies;
- afbeeldingen, video’s en documenten;
- vertalingen;
- kanaalspecifieke content;
- SEO-titels en meta descriptions;
- data voor filters en zoekfuncties;
- informatie voor marketplaces en productfeeds;
- volledigheidsscores en kwaliteitsregels.
Een PIM is doorgaans niet de beste bron voor actuele voorraad, betaalstatussen of financiële orderverwerking. Omgekeerd is een ERP vaak geen prettige omgeving voor rijke commerciële productcontent en meerdere talen.
De kracht ontstaat wanneer ieder systeem een duidelijke verantwoordelijkheid krijgt. Een koppeling moet die verantwoordelijkheden ondersteunen in plaats van ze door elkaar te laten lopen.
Shopify, ERP en PIM: welk systeem doet wat?
Een veelgebruikte verdeling ziet er als volgt uit:
| Gegevensdomein | Mogelijke leidende bron | Rol van Shopify |
|---|---|---|
| Artikelnummer en basiseenheid | ERP | Ontvangen en gebruiken voor verkoop |
| Producttitel en omschrijving | PIM | Tonen in storefront en verkoopkanalen |
| Productkenmerken | PIM | Opslaan in metafields en gebruiken voor filters |
| Afbeeldingen en documenten | PIM of DAM | Tonen op product- en contentpagina’s |
| Inkoop- en kostprijs | ERP | Meestal niet publiek tonen |
| Consumentenprijs | ERP, pricing engine of Shopify | Tonen en gebruiken in checkout |
| B2B-contractprijs | ERP of Shopify B2B | Tonen volgens klant- en catalogusregels |
| Voorraad | ERP of WMS | Tonen en reserveren per Shopify-locatie |
| Productpublicatie | PIM, ERP of Shopify | Beschikbaar maken per kanaal en markt |
| Klantaccount | Shopify of CRM | Account- en checkoutproces verzorgen |
| B2B-bedrijf en locatie | ERP, CRM of Shopify | Kopen binnen toegewezen voorwaarden |
| Order | Shopify | Aanmaken en doorsturen naar ERP of OMS |
| Betaling | Shopify en betaalprovider | Status doorgeven aan ERP |
| Fulfilment | ERP, WMS of 3PL | Status en tracking terugontvangen |
| Retour en refund | Shopify, ERP of retourplatform | Statussen uitwisselen en klant informeren |
Dit is geen universele waarheid. De juiste verdeling hangt af van processen, systemen, B2C of B2B, internationale structuur en interne organisatie.
Het belangrijkste is dat per veld en proces één gezaghebbende bron wordt aangewezen. Zonder die afspraak kunnen gebruikers een producttitel in Shopify wijzigen terwijl het PIM deze een uur later overschrijft. Technisch werkt de koppeling dan keurig, alleen het resultaat is verrassend onhandig.
Begin met een bronhouderschapsmatrix
Voordat een regel code wordt geschreven, moet duidelijk zijn welk systeem eigenaar is van ieder gegeven.
Een bronhouderschapsmatrix bevat bijvoorbeeld:
| Gegeven | Bron | Bestemming | Richting | Frequentie | Handmatig wijzigen in Shopify? |
|---|---|---|---|---|---|
| SKU | ERP | PIM en Shopify | ERP naar buiten | Bij wijziging | Nee |
| Producttekst NL | PIM | Shopify | PIM naar Shopify | Bij publicatie | Nee |
| Marktprijs DE | ERP | Shopify | ERP naar Shopify | Ieder uur | Nee |
| Webvoorraad | WMS | Shopify | WMS naar Shopify | Realtime of kort interval | Nee |
| Online order | Shopify | ERP | Shopify naar ERP | Direct | Niet na verzending |
| Trackingcode | WMS | Shopify | WMS naar Shopify | Bij fulfilment | Nee |
| SEO-description | PIM of Shopify | Shopify | Eén richting | Bij publicatie | Volgens afspraak |
Leg per stroom ook vast:
- veldformaat en validatie;
- interne en externe identifiers;
- transformatie of berekening;
- terugkoppeling na verwerking;
- foutscenario;
- proceseigenaar;
- bewaartermijn;
- testscenario.
De matrix voorkomt discussie tijdens incidenten. Als voorraad in Shopify afwijkt, moet direct duidelijk zijn welk systeem de waarheid bevat en welk team moet handelen.
Breng eerst het volledige e-commerce-ecosysteem in kaart
ERP en PIM zijn zelden de enige gekoppelde systemen. Een professionele Shopify-omgeving kan ook samenwerken met:
- WMS of magazijnsoftware;
- ordermanagementsysteem;
- CRM;
- boekhoudsoftware;
- kassa en Shopify POS;
- betaalproviders;
- vervoerders en verzendplatformen;
- 3PL- en fulfilmentpartners;
- marketplaces;
- productfeedsoftware;
- Google Merchant Center;
- marketing automation en e-mail;
- review- en loyaliteitsplatformen;
- klantenservice;
- datawarehouse en BI;
- configuratoren en pricing engines.
Maak een systeemlandschap met alle datastromen. Geef aan welke verbinding realtime is, welke periodiek draait en waar bestanden handmatig worden verwerkt.
Zo wordt zichtbaar of ERP en PIM rechtstreeks aan Shopify moeten koppelen, of dat een centrale integratielaag beter past. Ook komen dubbele stromen aan het licht. Soms stuurt het ERP voorraad naar de webshop, terwijl het WMS dezelfde voorraad via een tweede route bijwerkt. Twee waarheden op één voorraadveld is een uitstekende manier om drie afdelingen bezig te houden.
Welke integratiearchitectuur past bij Shopify?
Er zijn grofweg vier modellen.
Een standaardconnector
Een bestaande connector koppelt Shopify aan een specifiek ERP- of PIM-systeem. Dit kan snel en kostenefficiënt zijn wanneer processen grotendeels standaard zijn.
Beoordeel wel:
- ondersteunde objecten en velden;
- B2B- en internationale mogelijkheden;
- variant- en bundelondersteuning;
- synchronisatiefrequentie;
- foutafhandeling en logging;
- aanpasbaarheid van mappings;
- roadmap en support;
- structurele licentiekosten;
- eigenaarschap en exportmogelijkheden.
Een connector die “producten en orders ondersteunt” kan alsnog onvoldoende zijn wanneer klantspecifieke prijzen, deelzendingen of meerdere magazijnen essentieel zijn.
Rechtstreekse maatwerkkoppeling
Shopify communiceert direct met ERP of PIM via een custom app of integratieservice. Dit geeft veel controle en kan logisch zijn bij een beperkt aantal stabiele datastromen.
Het nadeel is dat beide systemen direct van elkaar afhankelijk worden. Wijzigingen in één API kunnen aanpassingen aan de koppeling vereisen. Logging, retries en monitoring moeten professioneel worden gebouwd.
Middleware of iPaaS
Een integratielaag ontvangt, vertaalt en routeert berichten tussen systemen. Dit kan voordelen bieden wanneer veel systemen, landen of kanalen samenwerken.
Mogelijke voordelen:
- centrale mapping;
- herbruikbare datastromen;
- monitoring en dashboards;
- queues en gecontroleerde retries;
- minder rechtstreekse afhankelijkheden;
- eenvoudiger toevoegen van nieuwe kanalen;
- centrale beveiliging en toegangscontrole.
Middleware voegt ook een extra systeem, licentie en beheerlaag toe. Bij een eenvoudige koppeling kan dat zwaarder zijn dan nodig.
Hybride architectuur
Veel organisaties combineren oplossingen. Productcontent kan via een PIM-connector lopen, terwijl orders via maatwerk naar ERP gaan en voorraad via middleware uit WMS komt.
Dat is niet per definitie rommelig. Een hybride architectuur kan juist efficiënt zijn wanneer verantwoordelijkheden helder blijven en alle stromen centraal worden gemonitord.
API’s, webhooks en geplande synchronisaties
Shopify-integraties gebruiken meestal een combinatie van API-aanroepen, webhooks en periodieke controles.
API’s
De GraphQL Admin API wordt gebruikt om Shopify-data te lezen en te wijzigen. Shopify adviseert nieuwe apps en integraties met deze API te bouwen; de REST Admin API geldt als legacy.1
API’s zijn geschikt voor bijvoorbeeld:
- producten en varianten aanmaken;
- metafields en metaobjects bijwerken;
- voorraad aanpassen;
- orders ophalen;
- fulfilments registreren;
- bedrijven en catalogi beheren;
- vertalingen registreren.
Webhooks
Webhooks melden dat een gebeurtenis heeft plaatsgevonden, bijvoorbeeld dat een order is aangemaakt of een product is gewijzigd. Shopify beschrijft webhooks als middel om apps met Shopify-data te synchroniseren of aanvullende acties te starten.2
Een webhook is een signaal, geen compleet integratieplan. De ontvangende applicatie moet het bericht controleren, opslaan en betrouwbaar verwerken.
Periodieke synchronisatie
Niet iedere stroom hoeft realtime te zijn. Productcontent kan iedere paar minuten of uren worden bijgewerkt. Een dagelijkse reconciliatie kan controleren of realtime berichten niet zijn gemist.
Een robuuste integratie combineert vaak:
- webhooks voor snelheid;
- queues voor gecontroleerde verwerking;
- API’s voor actuele details;
- periodieke synchronisatie voor herstel;
- volledige reconciliatie voor zekerheid.
Realtime klinkt commercieel aantrekkelijk, maar is alleen zinvol wanneer het proces die snelheid nodig heeft. Een productomschrijving die na vijf minuten verschijnt is meestal geen crisis. Een voorraad die een dag achterloopt mogelijk wel.
Houd rekening met API-limieten en capaciteit
De GraphQL Admin API gebruikt een puntensysteem waarbij querykosten, store en app gezamenlijk de beschikbare capaciteit bepalen. Shopify hanteert verschillende restore rates per abonnement en beperkt een afzonderlijke query tot een maximale kostprijs.3
Een integratie moet daarom:
- querykosten meten;
- kleine en gerichte queries gebruiken;
- rate-limitresponses opvangen;
- verwerking gecontroleerd vertragen;
- retrylogica toepassen;
- pieken spreiden;
- grote datasets via bulkoperaties behandelen;
- rekening houden met meerdere apps op dezelfde store.
Voor grote hoeveelheden data ondersteunt Shopify asynchrone bulkoperaties voor lezen en importeren. Resultaten worden als JSONL verwerkt, waardoor grote product- of migratiesets niet als duizenden losse synchrone verzoeken hoeven te worden afgehandeld.4
Ontwerp capaciteit op piekmomenten. Black Friday, seizoenswissels en grote prijsupdates zijn precies de momenten waarop koppelingen niet plotseling filosofisch over wachtrijen moeten gaan nadenken.
Producten en varianten vanuit ERP of PIM
De productstructuur moet vóór de koppeling worden ontworpen. Bepaal hoe het bronmodel wordt vertaald naar:
- Shopify-producten;
- varianten;
- opties;
- SKU’s en barcodes;
- collecties;
- productcategorieën;
- metafields;
- metaobjects;
- media;
- verkoopkanalen;
- markten en publicatiestatus.
Shopify ondersteunt maximaal drie opties en maximaal 2.048 varianten per product. Voor complexere producten zijn een andere productstructuur, een app, line item properties of maatwerk nodig.5
Controleer bij grote assortimenten:
- unieke SKU’s;
- stabiele bron-ID’s;
- parent-childrelaties;
- ontbrekende varianten;
- ongeldige combinaties;
- bundels en samengestelde producten;
- eenheden en verpakkingsgroottes;
- minimale afnames;
- digitale en fysieke producten;
- publicatie per land en kanaal.
Een product hoeft niet opnieuw te worden aangemaakt wanneer alleen de titel verandert. Koppel daarom bron-ID’s duurzaam aan Shopify global IDs en voorkom dat updates duplicaten veroorzaken.
Metafields en metaobjects voor rijke productdata
Niet alle PIM-data past in Shopify-standaardvelden. Metafields voegen gestructureerde velden toe aan producten, varianten, collecties, klanten en andere resources. Metaobjects zijn bruikbaar voor herbruikbare structuren met meerdere velden, zoals maattabellen, materiaalinformatie, merken, ingrediënten of technische documenten.6
Ontwerp deze structuur vóór de import:
- namespace en key;
- veldtype;
- toegestane waarden;
- referenties naar metaobjects;
- vertaalbaarheid;
- gebruik in filters;
- gebruik in thema en feeds;
- beheerrechten;
- fallback wanneer brondata ontbreekt.
Stop niet ieder vrij veld uit het PIM in Shopify. Migreer data die nodig is voor verkoop, presentatie, filtering, SEO, feeds, integraties of klantenservice. Shopify hoeft geen schaduwkopie van het volledige PIM te worden.
Categorieën, collecties en merchandising
Een PIM-categorieboom heeft vaak een andere functie dan de navigatiestructuur van de webshop. PIM-categorieën kunnen voor leveranciers, datakwaliteit of meerdere kanalen zijn ingericht. Shopify-collecties moeten vooral logisch zijn voor klanten, zoekmachines en commerciële merchandising.
Maak daarom onderscheid tussen:
- classificatie in het PIM;
- Shopify-productcategorie;
- automatische of handmatige collectie;
- navigatiemenu;
- filterwaarden;
- SEO-landingspagina;
- campagne- of marktcollectie.
De koppeling kan kenmerken en classificaties aanleveren, waarna Shopify automatische collecties op basis van regels vult. Controleer wel wat er gebeurt bij ontbrekende of gewijzigde waarden. Een typefout in een bronattribuut kan anders ongemerkt een belangrijke collectie leegmaken.
Prijzen en kortingslogica
Prijzen behoren tot de meest risicovolle integratiestromen. Bepaal eerst welke prijssoorten bestaan:
- standaardverkoopprijs;
- aanbiedingsprijs;
- marktprijs;
- staffelprijs;
- B2B-contractprijs;
- klantgroepprijs;
- tijdelijke campagneprijs;
- adviesprijs;
- prijs inclusief of exclusief btw;
- prijs in verschillende valuta.
Leg per prijs vast:
- leidend systeem;
- valuta en belastingbasis;
- geldigheidsperiode;
- afronding;
- prioriteit;
- combinatie met kortingen;
- frequentie van synchronisatie;
- gedrag bij ontbrekende prijs;
- goedkeuringsproces.
Voorkom dat ERP-prijzen, Shopify-kortingen en een externe pricing engine onafhankelijk dezelfde order proberen te verbeteren. De klant waardeert korting, maar finance houdt meestal minder van creatieve dubbeltellingen.
Shopify B2B gebruikt catalogi om producten en prijzen aan bedrijven of locaties toe te wijzen. De precieze mogelijkheden verschillen per abonnement. Basic, Grow en Advanced ondersteunen een beperkt aantal actieve B2B-marktcatalogi, terwijl Plus onbeperkte catalogi en directe toewijzing aan bedrijven en locaties biedt.7
Voorraad en meerdere locaties
Voorraad lijkt eenvoudig, maar het verschil tussen fysieke, beschikbare en verkoopbare voorraad is groot.
Mogelijke voorraaddimensies zijn:
- fysieke voorraad;
- gereserveerde voorraad;
- beschikbare voorraad;
- safety stock;
- inkomende voorraad;
- backorders;
- dropshipvoorraad;
- voorraad per land of magazijn;
- verkoopbare voorraad per kanaal.
Shopify kan voorraad per locatie volgen. Locaties kunnen magazijnen, winkels, pop-ups, dropshippers of fulfilmentapps zijn. Voorraad wordt per locatie afzonderlijk beheerd en orderrouting bepaalt mede vanuit welke locatie wordt geleverd.8
Ontwerp de mapping tussen ERP- of WMS-magazijnen en Shopify-locaties. Bepaal ook:
- welke locaties online mogen uitleveren;
- of voorraad wordt samengevoegd of afzonderlijk getoond;
- hoe safety stock wordt toegepast;
- wanneer voorraad wordt gereserveerd;
- hoe annuleringen voorraad terugboeken;
- hoe deelzendingen worden verwerkt;
- hoe dropshipproducten werken;
- wat gebeurt bij vertraagde synchronisatie.
Voor snelverkopende producten is een korte synchronisatietijd belangrijk. Toch moet de koppeling ook bij tijdelijk uitval veilig blijven. Soms is een conservatieve voorraadbuffer verstandiger dan optimistisch doorverkopen.
Orders van Shopify naar ERP
Een order bevat meer dan een ordernummer en totaalbedrag. Map onder meer:
- Shopify-order-ID en ordernummer;
- klant en adressen;
- bedrijf en B2B-locatie;
- orderregels en SKU’s;
- variant- en bron-ID’s;
- prijzen en kortingen;
- belasting;
- verzendkosten;
- valuta;
- betaalstatus en transacties;
- fulfilmentstatus;
- verkoopkanaal en markt;
- kortingscodes;
- cadeaubonnen en store credit;
- opmerkingen en referenties;
- toestemming en fraudedata waar toegestaan.
Het ERP moet na verwerking een technische bevestiging teruggeven. Een webhook die correct is ontvangen, betekent nog niet dat de order succesvol in het ERP is aangemaakt.
Gebruik statussen zoals:
- ontvangen;
- gevalideerd;
- in wachtrij;
- verwerkt in ERP;
- functionele fout;
- technische fout;
- opnieuw aangeboden;
- handmatige opvolging nodig.
Zo kan klantenservice zien of een order werkelijk operationeel is verwerkt.
Fulfilment, verzending en tracking terug naar Shopify
Wanneer ERP, WMS of 3PL een order verwerkt, moet Shopify correcte fulfilmentinformatie ontvangen. Denk aan:
- verzonden aantallen;
- deelzendingen;
- trackingnummer;
- vervoerder;
- tracking-URL;
- locatie;
- fulfilmentstatus;
- leveringsupdates;
- geannuleerde regels.
Test meerdere scenario’s:
- volledige verzending;
- order in twee pakketten;
- één order vanuit twee magazijnen;
- gedeeltelijk geannuleerde order;
- wijziging van trackingcode;
- fulfilment zonder tracking;
- dropshiplevering;
- afhalen in winkel.
Voorkom dat een update de volledige order als verzonden markeert terwijl slechts één regel is geleverd. Dit is technisch een statusfout, maar voor de klant vooral een reden om klantenservice te bellen.
Retouren, refunds en creditnota’s
Retouren zijn vaak de minst goed uitgewerkte koppeling. De verkooporder gaat soepel naar ERP, maar een retour wordt daarna per e-mail, spreadsheet en menselijke herinnering verwerkt.
Leg vast:
- waar de retour wordt aangevraagd;
- welk systeem de retour autoriseert;
- wie het artikel ontvangt en beoordeelt;
- wanneer voorraad wordt teruggeboekt;
- waar de refund wordt gestart;
- welk systeem de creditnota maakt;
- hoe gedeeltelijke refunds werken;
- hoe retourkosten worden verwerkt;
- welke status de klant ziet;
- hoe fraude en uitzonderingen worden behandeld.
Een refund in Shopify en een creditnota in ERP zijn verwante maar verschillende gebeurtenissen. Zorg dat beide processen elkaar volgen zonder dubbel geld terug te boeken.
Klanten, CRM en B2B-bedrijven
Bij B2C is Shopify vaak de bron voor nieuwe online klantaccounts, terwijl CRM of ERP relevante gegevens ontvangt. Bij B2B kan het ERP of CRM juist bepalen welke bedrijven en contactpersonen mogen bestellen.
Inventariseer:
- consument of zakelijk account;
- e-mailadres en unieke identiteit;
- marketingtoestemming;
- factuur- en afleveradressen;
- bedrijfsnummer en btw-nummer;
- bedrijven en vestigingen;
- contactpersonen en rollen;
- kredietlimiet;
- betaaltermijn;
- prijs- en productcatalogus;
- ordergoedkeuring;
- vertegenwoordiger of accountmanager.
Shopify B2B biedt bedrijven, bedrijfslocaties, catalogi, betaalvoorwaarden en andere zakelijke functies. Veel B2B-mogelijkheden zijn inmiddels op meerdere plannen beschikbaar, maar geavanceerde catalogustoewijzing en bepaalde functies verschillen per abonnement.9
Ontwerp de synchronisatie zo dat het verwijderen of blokkeren van een contactpersoon niet per ongeluk het gehele bedrijf uitschakelt. Test ook wijzigingen in vestiging, rol, catalogus en betaalvoorwaarden.
Internationale productdata, prijzen en vertalingen
Internationale verkoop voegt markten, talen, valuta en lokale beschikbaarheid toe. Shopify Markets kan ervaringen per doelgroep aanpassen met onder meer taal, valuta, prijs, domein, productbeschikbaarheid en content.10
Het PIM kan vertalingen beheren, maar de koppeling moet rekening houden met Shopify’s vertaalbare resources en marktcontext. De GraphQL Admin API biedt translatable resources en digestwaarden waarmee vertalingen kunnen worden geregistreerd en bijgewerkt.11
Leg per markt vast:
- beschikbare producten en varianten;
- lokale titel en omschrijving;
- specificaties en eenheden;
- prijs en valuta;
- belasting en duties;
- afbeeldingen en documenten;
- levertijd;
- juridische tekst;
- SEO-metadata;
- fallbacktaal;
- publicatiestatus.
Een vertaling in het PIM is niet automatisch commercieel geschikt. Zoekgedrag en terminologie verschillen per land. Combineer geautomatiseerde distributie daarom met SEO-onderzoek en menselijke controle door native speakers waar de markt dat rechtvaardigt.
Productfeeds, marketplaces en Google Shopping
Een PIM voedt vaak meer kanalen dan alleen Shopify. Bepaal of productfeeds rechtstreeks uit het PIM, via Shopify of via gespecialiseerde feedsoftware worden opgebouwd.
Controleer:
- product-ID en variant-ID;
- titel en omschrijving;
- merk en GTIN;
- Google-productcategorie;
- prijs en aanbieding;
- voorraad;
- product-URL;
- afbeelding;
- kleur, maat, materiaal en geslacht;
- custom labels;
- lokale beschikbaarheid;
- markt en taal.
Dezelfde data kan voor de webshop, Shopping en marketplaces anders worden gepresenteerd. Een commerciële webshoptitel hoeft niet automatisch de beste Shopping-titel te zijn. Zorg daarom voor kanaalspecifieke velden of transformaties.
Bij een migratie kunnen Shopify-product- en variant-ID’s veranderen. Houd rekening met gevolgen voor feeds, campagnerapportage, reviews, marketplaces en BI.
Realtime, batch of hybride synchronisatie?
Niet iedere datastroom heeft dezelfde snelheid nodig.
| Gegevensstroom | Gebruikelijke aanpak | Waarom |
|---|---|---|
| Nieuwe order | Realtime webhook + queue | Snelle operationele verwerking |
| Betaalstatus | Realtime of eventgestuurd | Voorkomt onterechte fulfilment |
| Voorraad | Realtime of kort interval | Beperkt overselling |
| Fulfilment en tracking | Eventgestuurd | Klant snel informeren |
| Productcontent | Periodiek of bij publicatie | Meestal minder tijdkritisch |
| Volledige prijsupdate | Batch of bulk | Grote hoeveelheid gegevens |
| Vertalingen | Bij publicatie of batch | Redactionele workflow |
| Reconciliatie | Dagelijks of vaker | Herstelt gemiste gebeurtenissen |
Gebruik realtime alleen waar de bedrijfswaarde dit vraagt. Iedere realtimeverbinding verhoogt eisen aan beschikbaarheid, monitoring en herstel.
Bouw voor fouten, niet alleen voor succes
Een koppeling die in een demo één order verwerkt is nog geen productie-integratie. Externe systemen zijn soms traag, tijdelijk onbereikbaar of leveren ongeldige data.
Een betrouwbare integratie bevat:
- queues;
- time-outs;
- gecontroleerde retries;
- exponential backoff;
- idempotentie;
- deduplicatie;
- validatie;
- dead-letter queue of foutenwachtrij;
- technische en functionele logging;
- dashboards;
- waarschuwingen;
- handmatige herverwerking;
- reconciliatie.
Shopify kan webhooks opnieuw aanbieden en adviseert HMAC-verificatie en deduplicatie. Bij herhaalde mislukte leveringen kan de webhookregistratie uiteindelijk worden verwijderd.12 Ontvang webhooks daarom snel, plaats het werk in een queue en verwerk het asynchroon.
Idempotentie voorkomt dat dezelfde order, betaling of voorraadmutatie dubbel wordt verwerkt wanneer een request wordt herhaald. Shopify ondersteunt hiervoor idempotencymechanismen bij daarvoor geschikte API-operaties.13
Verschil tussen technische en functionele fouten
Niet iedere fout moet automatisch opnieuw worden geprobeerd.
Technische fout
Voorbeelden:
- time-out;
- tijdelijk onbereikbare API;
- rate limit;
- netwerkstoring;
- serverfout.
Deze fouten kunnen vaak gecontroleerd opnieuw worden aangeboden.
Functionele fout
Voorbeelden:
- onbekende SKU;
- ontbrekende prijs;
- ongeldige valuta;
- klant heeft geen debiteur-ID;
- adres voldoet niet aan ERP-validatie;
- productvariant bestaat niet;
- ordertotaal wijkt af.
Een functionele fout blijft waarschijnlijk bestaan bij een automatische retry. Deze vraagt om datacorrectie, mapping of menselijke beoordeling.
Maak meldingen begrijpelijk. “HTTP 422” is nuttig voor een developer, maar operations wil weten dat order 10482 niet kan worden verwerkt omdat SKU ABC-123 in ERP ontbreekt.
Beveiliging en toegangsbeheer
Een integratie verwerkt bedrijfs- en persoonsgegevens. Beperk toegang tot wat technisch noodzakelijk is.
Regel minimaal:
- afzonderlijke productie- en testcredentials;
- minimale API-scopes;
- veilige opslag van secrets;
- encryptie tijdens transport en waar nodig opslag;
- periodieke sleutelrotatie;
- HMAC-controle van webhooks;
- logging zonder onnodige persoonsgegevens;
- toegangsbeheer en audittrail;
- incidentprocedure;
- afspraken over subverwerkers en dataretentie.
Shopify adviseert officiële appbibliotheken en veilige ontwikkelpraktijken te gebruiken.14 Beveiliging hoort daarnaast in de volledige keten te worden beoordeeld, inclusief middleware, cloudomgeving en ERP- of PIM-endpoints.
Houd rekening met Shopify API-versies
Een koppeling is geen eenmalig project. Shopify publiceert API-versies volgens een voorspelbare kwartaalcyclus en oudere versies worden na verloop van tijd uitgefaseerd.15
Plan daarom structureel:
- versiebeheer van de integratie;
- controle van release notes en deprecations;
- geautomatiseerde tests;
- acceptatietest bij wijzigingen;
- periodieke updates;
- monitoring van API-fouten;
- eigenaarschap en onderhoudsbudget.
Leg in het contract vast wie verantwoordelijk is voor aanpassingen aan Shopify, ERP, PIM, middleware en externe connectors. Zonder eigenaar wordt onderhoud vanzelf het probleem van degene die als eerste een foutmelding ziet.
Datamigratie en integratieontwikkeling moeten samenwerken
De initiële migratie en de structurele koppeling gebruiken vaak dezelfde mapping, maar hebben verschillende doelen.
De migratie moet een bestaande dataset gecontroleerd overzetten. De structurele integratie verwerkt daarna nieuwe en gewijzigde gegevens.
Werk daarom met:
- analyse van brondata;
- nieuw Shopify-datamodel;
- datacleaning;
- proefmigratie;
- ontwikkeling van structurele synchronisatie;
- volledige testimport;
- activering van incrementele updates;
- delta-import vlak voor livegang;
- reconciliatie na livegang.
Voorkom dat de migratie velden op een andere manier vult dan de koppeling. Anders ziet de webshop er bij livegang goed uit en wordt zij bij de eerste synchronisatie alsnog herschikt.
Test met echte bedrijfsscenario’s
Testcases moeten verder gaan dan één standaardproduct en één betaalde order.
Neem onder meer mee:
- eenvoudig product;
- product met veel varianten;
- bundel of samengesteld artikel;
- product zonder voorraad;
- meerdere magazijnen;
- prijswijziging tijdens campagne;
- B2B-klant met contractprijs;
- order in verschillende valuta;
- gedeeltelijke betaling;
- mislukte betaling;
- deelzending;
- retour van één orderregel;
- gedeeltelijke refund;
- geannuleerde order;
- ontbrekende SKU;
- ongeldige productdata;
- dubbel webhookbericht;
- tijdelijke ERP-uitval;
- rate limit;
- grote batchupdate.
Laat proceseigenaren uit e-commerce, logistiek, finance, klantenservice en IT accepteren. Een koppeling kan technisch correct zijn terwijl de werkvloer er onmogelijk mee kan werken.
Reconciliatie: aantonen dat systemen gelijk lopen
Monitoring vertelt of processen technisch draaien. Reconciliatie controleert of de uitkomst inhoudelijk klopt.
Vergelijk periodiek:
- aantallen producten en varianten;
- SKU’s zonder match;
- prijzen per markt;
- voorraad per locatie;
- gepubliceerde producten;
- orders per periode;
- ordertotalen en belasting;
- betaalstatussen;
- fulfilments en tracking;
- refunds en creditnota’s;
- B2B-bedrijven en catalogi;
- vertalingen en publicatiestatus.
Maak afwijkingen zichtbaar in een dashboard en wijs eigenaren toe. Een dagelijkse melding “12 records verschillen” is pas nuttig wanneer iemand weet welke twaalf, waarom en wat ermee moet gebeuren.
Gefaseerd live gaan of alles tegelijk?
Een big-banglivegang is soms onvermijdelijk, maar verhoogt risico. Waar mogelijk kan een gefaseerde aanpak helpen:
- eerst producten en content synchroniseren;
- daarna prijzen en voorraad;
- vervolgens testorders naar ERP;
- fulfilment terugkoppelen;
- een beperkte markt of klantgroep laten testen;
- pas daarna alle verkoop activeren.
Bij een parallelle periode moet duidelijk zijn welk systeem orders mag aannemen en waar wijzigingen worden uitgevoerd. Twee actieve verkoopplatformen met gedeelde voorraad vragen extra reserverings- en reconciliatielogica.
Maak voor livegang een draaiboek met:
- databevriezing of beheerrestricties;
- laatste volledige synchronisatie;
- delta-import;
- activering van productiecredentials;
- omschakelen van webhooks;
- testorder per proces;
- monitoring;
- verantwoordelijken en escalatie;
- terugvalscenario;
- criteria voor definitieve acceptatie.
Wie moet eigenaar zijn van de koppeling?
Technisch eigenaarschap en proceseigenaarschap zijn verschillende zaken.
De technische eigenaar is verantwoordelijk voor code, infrastructuur, monitoring, updates en incidenten. De proceseigenaar bepaalt zakelijke regels, accepteert wijzigingen en beoordeelt functionele fouten.
Leg vast:
- wie brondata corrigeert;
- wie foutmeldingen beoordeelt;
- wie mappingwijzigingen goedkeurt;
- wie contact onderhoudt met ERP- en PIM-leveranciers;
- wie API-updates uitvoert;
- wie buiten kantooruren bereikbaar is;
- welke responstijden gelden;
- welke documentatie wordt onderhouden;
- wie eigenaar is van code en accounts.
Een integratie zonder operationeel eigenaar veroudert sneller dan verwacht, ook wanneer de code bij oplevering uitstekend is.
Wat kost een ERP- of PIM-koppeling met Shopify?
De investering hangt af van het aantal systemen, gegevensstromen, uitzonderingen, volumes en vereiste beschikbaarheid. Een productexport via een bestaande connector is niet vergelijkbaar met een realtime internationale B2B-integratie met ERP, PIM en WMS.
Onderstaande bedragen zijn indicatieve bandbreedtes van Shopcommerce. Het zijn geen officiële Shopify-tarieven en geen offerte. Bedragen zijn exclusief btw, Shopify-abonnement, apps, middlewarelicenties, ERP- of PIM-licenties en support van externe leveranciers.
| Onderdeel | Indicatieve investering |
|---|---|
| Procesanalyse en bronhouderschapsmatrix | € 4.000 tot € 12.500 |
| Architectuur en technisch ontwerp | € 5.000 tot € 17.500 |
| Standaardconnector configureren | € 5.000 tot € 20.000 |
| Maatwerk ERP-koppeling | € 15.000 tot € 75.000+ |
| Maatwerk PIM-koppeling | € 12.500 tot € 60.000+ |
| Middleware- of iPaaS-inrichting | € 10.000 tot € 60.000+ |
| B2B-prijzen, bedrijven en catalogi | € 10.000 tot € 50.000+ |
| Internationale data en vertalingen | € 7.500 tot € 35.000+ |
| Migratie, reconciliatie en delta-import | € 7.500 tot € 30.000 |
| Testen, livegang en nazorg | € 7.500 tot € 25.000 |
Een overzichtelijke koppeling met standaardprocessen kan ongeveer € 15.000 tot € 35.000 kosten. Een professionele ERP- en PIM-integratie met meerdere stromen ligt vaak tussen € 35.000 en € 90.000. Complexe internationale, B2B- of realtime omgevingen met ERP, PIM, WMS en middleware kunnen € 90.000 tot € 175.000 of meer vragen.
Voor een volledig Shopify-project inclusief strategie, UX, development, migratie en meerdere integraties kan de totale investering richting € 125.000 tot € 250.000 of meer gaan.
Vergelijk offertes op inbegrepen datastromen, foutafhandeling, dashboards, testscenario’s, documentatie en onderhoud. De laagste offerte is zelden de laagste totale kosten wanneer logging en retries als optionele luxe zijn behandeld.
Hoe lang duurt het integratietraject?
Een eenvoudige bestaande connector kan in vier tot acht weken worden ingericht en getest. Een maatwerk ERP- of PIM-koppeling vraagt vaak drie tot vijf maanden. Complexe omgevingen met meerdere systemen, landen en B2B-processen kunnen zes tot twaalf maanden of langer duren.
De planning wordt beïnvloed door:
- beschikbaarheid van documentatie en testomgevingen;
- kwaliteit van brondata;
- snelheid van externe leveranciers;
- aantal datastromen;
- realtimevereisten;
- B2B- en internationale complexiteit;
- interne besluitvorming;
- testcapaciteit van proceseigenaren;
- bestaande technische schuld;
- gewenste livegangsdatum.
Plan externe ERP- en PIM-leveranciers vroeg. Een Shopify-team kan een integratie niet zelfstandig afronden wanneer de andere kant van de verbinding pas over drie maanden tijd heeft.
Wanneer past Shopify minder goed?
Shopify kan uitstekend samenwerken met ERP- en PIM-systemen. Toch is het niet voor iedere architectuur automatisch de beste commercebasis.
Onderzoek alternatieven wanneer:
- het productmodel structureel buiten Shopify’s grenzen valt;
- vrijwel iedere prijs en checkoutstap extern moet worden berekend;
- extreme backendvrijheid noodzakelijk is;
- complexe B2B-processen onvoldoende in Shopify en apps passen;
- de organisatie volledige controle over database en runtime nodig heeft;
- integratiebeperkingen cruciale processen onnodig ingewikkeld maken;
- de bestaande Magento- of maatwerkoplossing stabiel en economisch gezond is.
Magento kan bijvoorbeeld beter passen bij vergaand backendmaatwerk en organisaties die veel technische controle willen behouden. Een hybride oplossing kan logisch zijn wanneer Shopify de storefront en checkout verzorgt, terwijl specialistische processen buiten Shopify blijven.
De platformkeuze moet volgen uit processen en totale eigendomskosten, niet uit de wens om een bepaalde technologie koste wat kost te gebruiken.
Welke vragen stel je aan een integratiepartner?
- Welke Shopify-koppelingen met ERP, PIM en WMS hebben jullie gerealiseerd?
- Hebben jullie ervaring met ons specifieke ERP- of PIM-systeem?
- Hoe bepalen jullie per gegeven het leidende systeem?
- Hoe leggen jullie mappings en bedrijfsregels vast?
- Wanneer adviseren jullie een connector, middleware of maatwerk?
- Wie ontwikkelt en beheert de koppeling daadwerkelijk?
- Hoe gaan jullie om met Shopify GraphQL API-limieten?
- Hoe verwerken jullie webhooks, queues en retries?
- Hoe voorkomen jullie dubbele orders en mutaties?
- Hoe worden technische en functionele fouten onderscheiden?
- Welke dashboards en meldingen krijgt onze organisatie?
- Kunnen foutieve records handmatig opnieuw worden aangeboden?
- Hoe controleren jullie prijs en voorraad per locatie?
- Hoe worden deelzendingen, retouren en refunds verwerkt?
- Hoe ondersteunen jullie B2B-bedrijven en klantspecifieke prijzen?
- Hoe worden internationale markten en vertalingen gekoppeld?
- Hoe ziet een volledige reconciliatie eruit?
- Wie is eigenaar van code, documentatie, accounts en data?
- Welke SLA en onderhoudsafspraken gelden na livegang?
- Durven jullie ook te adviseren dat Shopify niet de beste keuze is?
Vraag om concrete architectuur, foutscenario’s en verantwoordelijkheden. Een blokje met twee pijlen tussen “ERP” en “Shopify” is een prima begin van een presentatie, maar nog geen integratieontwerp.
ERP- en PIM-koppelingen met Shopify via Shopcommerce
Shopcommerce bekijkt Shopify als onderdeel van het volledige e-commerce-ecosysteem. We starten bij processen, data en verantwoordelijkheden en kiezen daarna de techniek.
Onze in-house specialisten voor strategie, UX-design, Shopify-development, integraties, datamigratie, SEO, SEA, productdata en content werken binnen één projectteam. Daardoor wordt de koppeling niet los ontwikkeld van de webshop. Een productmodel beïnvloedt UX, filters, SEO en Shopping. Marktprijzen raken checkout en finance. Voorraadlogica bepaalt wat klanten kunnen bestellen en wat logistiek kan leveren.
We begeleiden het traject van bronhouderschapsmatrix en architectuur tot ontwikkeling, testen, livegang, monitoring en doorontwikkeling. Daarbij werken we samen met interne IT, ERP- en PIM-leveranciers en andere betrokken partners.
Shopcommerce werkt zowel met Shopify als Magento en kan daardoor platformkeuzes vanuit de organisatie beoordelen. Het doel is niet om ieder proces in Shopify te duwen, maar om een beheersbaar landschap te ontwerpen waarin ieder systeem doet waar het goed in is.
Conclusie
ERP- en PIM-koppelingen opnieuw inrichten voor Shopify begint niet bij een API-endpoint. Het begint bij de vraag welk systeem eigenaar is van producten, prijzen, voorraad, klanten, orders en fulfilment.
Met een duidelijke bronhouderschapsmatrix kan vervolgens worden gekozen voor een connector, rechtstreekse koppeling, middleware of hybride architectuur. De technische oplossing moet rekening houden met API-limieten, webhooks, bulkoperaties, retries, idempotentie, monitoring en periodieke reconciliatie.
Een goede koppeling is grotendeels onzichtbaar. Productinformatie verschijnt correct, voorraad klopt, orders worden verwerkt en medewerkers hoeven geen spreadsheets tussen systemen te dragen. Juist die rustige voorspelbaarheid is het resultaat van veel zorgvuldige keuzes achter de schermen.
Veelgestelde vragen over ERP- en PIM-koppelingen met Shopify
Kan een bestaande ERP-koppeling worden hergebruikt bij Shopify?
Soms kan dezelfde connector, middleware of integratiepartner worden behouden. De datamapping en processen moeten vrijwel altijd worden aangepast, omdat Shopify producten, voorraad, orders, fulfilments en klanten anders modelleert dan het vorige platform.
Kan Shopify rechtstreeks aan een ERP worden gekoppeld?
Ja. Dat kan met een standaardconnector, custom app of maatwerkintegratie via de GraphQL Admin API. Bij meerdere systemen kan middleware of een iPaaS-platform beter passen doordat mapping, monitoring en foutafhandeling centraal worden geregeld.
Heb je naast een ERP ook een PIM nodig?
Niet iedere organisatie heeft een PIM nodig. Een PIM wordt vooral waardevol bij grote assortimenten, veel kenmerken, meerdere talen, verschillende verkoopkanalen en een redactionele productworkflow. Bij een eenvoudig assortiment kan Shopify of ERP voldoende zijn.
Welk systeem moet leidend zijn voor productdata?
Dat verschilt per veld. ERP beheert vaak artikelnummers, prijzen en voorraad. PIM beheert commerciële teksten, kenmerken, media en vertalingen. Shopify presenteert en verkoopt. Leg per gegeven één gezaghebbende bron vast.
Hoe snel kan voorraad worden gesynchroniseerd?
Voorraad kan realtime of met korte intervallen worden bijgewerkt. De juiste snelheid hangt af van ordervolume, schaarste, magazijnen en broncapaciteit. Combineer snelle updates met safety stock, retries en periodieke reconciliatie.
Hoe voorkom je dubbele orders in het ERP?
Gebruik stabiele Shopify-ID’s, idempotente verwerking, deduplicatie en een verwerkingsstatus per order. Wanneer hetzelfde webhookbericht of request opnieuw binnenkomt, moet de integratie herkennen dat de order al is verwerkt.
Kan Shopify meerdere magazijnen ondersteunen?
Ja. Shopify kan voorraad per locatie beheren. Maak een expliciete mapping tussen ERP- of WMS-magazijnen en Shopify-locaties en bepaal welke locaties online mogen uitleveren en hoe orderrouting werkt.
Kunnen klantspecifieke B2B-prijzen vanuit ERP worden gebruikt?
Ja, maar de architectuur hangt af van het aantal klanten, prijsregels en het Shopify-abonnement. Mogelijkheden zijn Shopify B2B-catalogi, imports, API-synchronisatie, apps of een externe pricingservice.
Hoe worden productvertalingen uit een PIM naar Shopify gestuurd?
Vertalingen kunnen via Shopify’s vertaalbare resources en GraphQL Admin API worden geregistreerd. De koppeling moet locale, markt, broncontent en digestwaarden correct verwerken. Menselijke taal- en SEO-controle blijft belangrijk.
Wat gebeurt er wanneer het ERP tijdelijk niet bereikbaar is?
De integratie plaatst berichten in een queue en probeert technische fouten gecontroleerd opnieuw. Monitoring waarschuwt beheerders. Na herstel worden wachtrijen verwerkt en controleert reconciliatie of alle gegevens alsnog zijn bijgewerkt.
Moet iedere koppeling realtime zijn?
Nee. Orders, betalingen en schaarse voorraad vragen vaak snelle verwerking. Productteksten, afbeeldingen en vertalingen kunnen meestal periodiek of bij publicatie worden bijgewerkt. Realtime voegt complexiteit toe en moet functioneel nodig zijn.
Hoe test je een ERP- of PIM-koppeling?
Test met echte bedrijfsscenario’s, waaronder varianten, B2B-prijzen, meerdere magazijnen, deelzendingen, refunds, ongeldige data, dubbele berichten en systeemuitval. Vergelijk daarna aantallen en financiële totalen tussen de systemen.
Wat kost een Shopify-koppeling met ERP of PIM?
Een overzichtelijke koppeling begint indicatief rond € 15.000 tot € 35.000. Een professionele ERP- en PIM-integratie ligt vaak tussen € 35.000 en € 90.000. Complexe internationale of B2B-omgevingen kunnen € 90.000 tot € 175.000 of meer kosten.
Hoe lang duurt het ontwikkelen van de koppeling?
Een standaardconnector kan vier tot acht weken vragen. Maatwerk kost vaak drie tot vijf maanden. Een omgeving met meerdere systemen, landen en complexe B2B-processen kan zes tot twaalf maanden of langer duren.
Wie onderhoudt de koppeling na livegang?
Leg technisch en functioneel eigenaarschap vast. De technische partner beheert code, API-versies, monitoring en incidenten. Proceseigenaren binnen de organisatie beoordelen data, bedrijfsregels en functionele fouten. Een SLA maakt responstijden en verantwoordelijkheden concreet.
Bronnen en verantwoording
De technische Shopify-claims in deze blog zijn gecontroleerd aan de hand van officiële documentatie van Shopify. De kosten en doorlooptijden zijn indicatieve inschattingen van Shopcommerce. Werkelijke prijzen en planningen hangen af van systemen, datastromen, volumes, uitzonderingen, licenties, leveranciers en beschikbare capaciteit.


