Business Central og Shopify Integration: Sådan får du overblik

Shopify Connector for Business Central virker fint i teorien, men ikke så godt når man rammer virkeligheden.

Når man kaster sig ud i at koble Shopify sammen med Business Central, kan man gå én af to veje. Enten går man med Microsoft standard Shopify Connector eller også bygger man sin egen app til formålet. Vi har prøvet begge dele. I praksis kan man også forsøge at kaste sig ud i en version, hvor man starter med standard og hacker sig til resten, men det vil jeg ikke anbefale at forsøge.

Det handler ikke om at teknologien er dårlig eller umoden. Shopify Connector er gratis, solidt udstyret og vedligeholdt løbende af Microsoft selv. Problemet ligger i afstanden mellem hvad connectoren kan på overfladen, og hvad den reelt leverer i virksomheder med multivaluta, komplekse returflows og produktkataloger på flere tusinde varianter.

Hvad connectoren kan, og hvad den ikke kan

Shopify Connector er en gratis applikation der leveres med BC. Den forbinder de vigtigste datastrømme. Produkter med billeder, varianter, stregkoder og leverandørvarenumre synkroniseres kontinuerligt. Ordrer synkroniseres inklusive forsendelsesomkostninger, gavekort og betalingsinformation. Lagerbeholdningen opdateres tovejs. Kunder og virksomheder matches og oprettes ud fra telefonnummer og emailadresse.¹

For en virksomhed med én Shopify-butik, et struktureret produktsortiment og standardiseret ordrehåndtering er connectoren ofte fuldstændig tilstrækkelig. Jeg vil endda gå så langt og sige at det er en fremragende og robust løsning. Det er bare ikke altid sådan det sker i praksis.

Hvor virkeligheden viser sig

Multivaluta og internationale butikker er det første problem. Ordrer der skal behandles i valutaer der afviger fra butikkens basisvaluta, det synkroniseres ikke uden problemer. Valutakonverteringer og valutakursdifferencer kræver manuel justering bagefter. For virksomheder der sælger internationalt bliver det en kontinuerlig kilde til afstemningsarbejde.

Varianter, produktmapping og enheder er det næste, men så alligevel ikke. Shopify kan håndtere op til 2.048 varianter per produkt, men en variant er ikke det samme i Shopify, som det er i BC. BC adskiller i virkeligheden et produkt på to niveauer, enhedstype (fx styk, kolli eller palle) og typer/dimensioner (fx farve og størrelse). Shopify ser en variant som værende samme vare i forskellige typer/dimensioner (farver og størrelser). Enheder er altid kun i én dimension fx styk. Det er formegentlig ikke det store problem, hvis man arbejder B2C, men arbejder man med fx mængderabatter på kolli, så kan det godt skabe problemer.

Returneringer og refunderinger behandles ikke problemfrit. Delvis refundering håndteres ikke automatisk. Når en refundering håndteres i Shopify, spores den ikke automatisk i BC. Manuelt registrerede returneringer via email bryder synkroniseringen og skaber inkonsistens i regnskabet. Det er en proces hvor vi næsten altid ender med at skulle bygge en logik.

Opfyldelse på tværs af lokationer er en anden barriere. Når en Shopify-ordrelinje skal opdeles på grund af flere BC-lagre, vises den i Shopify som én linje med ét lager. Det kræver manuel opsplitning og separat bogføring. For virksomheder med flere lagersteder betyder det daglig friktion.

Ydeevne ved høj transaktionsvolumen kommer fra connectorens afhængighed af BC’s Job Queue med planlagte intervaller, ikke realtidsopdateringer. I perioder med høje volumener (kampagner, salgsevents) kan connectoren møde udfordringer. Det kan medføre forsinkelser i lageropdateringer og øge risikoen for at sælge ud af lager.

Sådan arbejder vi i praksis

Vi starter med at undersøge om jeres nuværende data matcher den struktur Shopify understøtter og om det data der ikke passer ind, kan tilpasses i stedet for at bygge udenom.

Helt konkret, går vi igennem varekortene og kigger enheder og varianter pr. vare. Vi kigger på fejl i Varenr., beskrivelser, inkonsistens i enhedskoder, vekslende formater mellem gamle og nye varegrupper. Vi kigger på valutaopsætningen og afdækker om butikken kan undgå at køre multivaluta i Shopify, eller om alle ordrer kommer ind i én valuta. Og vi kigger på kundekartoteket: hvordan I matcher mellem B2C og B2B, og om der ligger gamle dubletter der vil støje på email-matching.

Det her giver to outputs. Det første er en liste over de steder hvor connectoren kan løse problemet som det er. Det andet er en liste over de steder hvor BC-dataene skal renses eller restruktureres for at passe ind. Vores erfaring er, at hvis listen over tilpasninger på BC-siden er kortere end listen over tilpasninger på connector-siden, så er datatilpasning vejen frem. Det er som regel billigere, hurtigere og giver et bedre regnskabsgrundlag bagud, fordi dårlig datakvalitet i forvejen koster jer noget I ikke har sat tal på.

De fleste virksomheder har et datakvalitetsproblem maskeret som et integrationsproblem.

Først når den vurdering er lavet, beslutter vi om standard connectoren er det rigtige sted at starte, eller om I har et reelt arkitekturproblem der peger mod tilpasset AL eller en hybrid. Det er værd at lave den skelnen før der bygges noget som helst.

Med den vurdering på plads følger den tekniske implementering. Vi starter altid i et sandbox-miljø. Aldrig direkte i produktion. BC tilbyder sandbox-miljøer og Shopify har gratis development stores. Vi bruger dem til at teste hele integrationsflowet før vi nærmer os produktionsdata.

Derefter mapper vi produkterne. Vi sikrer at varenumre, varianter og måleenheder er konsistente mellem systemerne. En vare der hedder “SKU-001” i BC og “sku-001” i Shopify er to forskellige varer ifølge connectoren.

Næste trin er ordresynkroniseringen. Vi definerer kundematching baseret på email. Job Queue-intervallerne sættes til 15-30 minutter. Ikke hvert femte minut (skaber unødvendig belastning) og ikke hver time (kunderne tolererer det ikke). Vi aktiverer lagerbeholdningssynkronisering med lokationsfiltre. Det sikrer at kun lager fra relevante lagre vises i Shopify.

Hvornår I skal gå ud over standard

Tre hovedscenarier hvor standard connectoren ikke holder.

Multikanal salg. Connectoren understøtter kun én salgskanal. Hvis I sælger via Shopify, Amazon og fysiske butikker, har I behov for en bredere integrationsplatform der kan håndtere lager på tværs af alle kanaler.

Komplekse returflows. Hvis virksomheden håndterer mange returneringer med delvis refundering, byttehandler og kreditnotaer, er standard connectoren utilstrækkelig. Vi bygger typisk tilpasset AL-kode der håndterer returlogikken centralt i BC og returnerer resultaterne til Shopify via API.

Realtidskrav. Standard connectoren bygger på planlagte synkroniseringer. Hvis I skal have lageropdateringer i Shopify inden for sekunder efter en lagerændring i BC, skal I have en webhook-baseret løsning.

Tilpasset AL-udvikling er en anden vej. Shopify tilbyder GraphQL-API’er der kan tilgås direkte fra BC. Det giver fuld kontrol over hvad og hvornår der synkroniseres. Vi vælger den tilgang når kundens krav er for specifikke til standard connectoren.

Vores anbefaling

Hvis man har styr på sine data og vurderer man godt kan klare sig med Microsofts egne Shopify Connector, så start der. Den er gratis, vedligeholdt af Microsoft, og dækker typisk 70-80 procent af almindelige integrationsscenarier. Investér tiden i at sætte den rigtigt op i stedet for at hoppe til en kompleks løsning fra start.

Start med at definere de forskellige brugsscenarier (eller brug dem jeg har beskrevet nederst).

Test grundigt i sandbox. Ikke kun teknisk, men hele forretningsflowet fra kundebestilling til forsendelse til returnering.

Etabler en navngivningskonvention. Varenumre og kundeidentifikatorer skal matche præcist mellem systemerne. Ret eksisterende data inden synkronisering starter. Det er væsentligt billigere at rette data end at debugge synkroniseringsfejl bagefter.

Planlæg for vækst. Hvis I forventer stigning i ordreantal, så test med realistiske volumener. En integration der virker med 10 ordrer dagligt kan kollapse ved 200.

Vores erfaring peger på at den vigtigste investering ikke ligger i selve connectoren men i grundig forberedelse. Rens jeres varer. Standardiser jeres varianter og enhedskoder. Definér matchingregler klart. Test i sandbox med rigtige data, ikke fem testprodukter. De virksomheder der investerer en hel uge i forberedelse får en integration der kører stabilt fra dag ét. Dem der springer forberedelsen over bruger en måned på at rette fejl i produktion.

Aktivér BC’s ændringslog for alle Shopify-relaterede tabeller. Det giver et audit trail der er uundværligt ved fejlsøgning. Etabler kontinuerlig overvågning af synkroniseringsfejl. Dokumentér integrationsarkitekturen grundigt fra start.

Når I møder connectorens grænser (og det sker), så evaluer om jeres behov bedre imødekommes af tilpasning af løsningen eller om I skal over på en custom AL-extension. Det afhænger af jeres transaktionsvolumen, returflows og tekniske modenhed.

Sæt tid af til at teste, planlæg konkret hvornår der testes og hvem der er ansvarlig for det. Bestem ansvaret ned på personniveau, så der ingen tvivl er om hvem der bør gøre det.

Testscenarier inden go-live

De 20 funktionelle scenarier nedenfor er den minimumsliste vi typisk kører igennem i sandbox før vi går live med en Shopify Connector-integration. Listen er tænkt som forberedelse, ikke som komplet QA-suite. Brug den som udgangspunkt og udvid med scenarier der matcher jeres forretningsflow.

Kilde: Sekvens, interne testscenarier baseret på Shopify Connector for Business Central. Marts 2026.

Kilder

1. Microsoft Learn, Shopify Connector for Business Central. ↩︎
2. Microsoft Learn, Set Up Shopify Connector. ↩︎
3. Microsoft Learn, Synchronize Inventory and Pricing. ↩︎