WooCommerce-integrasjoner med ERP- og grossist-API-er

#WooCommerce-integrasjoner med ERP- og grossist-API-er

Trenger du generell hjelp til å bygge og utvikle en butikk, start med siden WooCommerce-utvikler. Denne siden handler om et smalere, mer teknisk problem: datautveksling mellom WooCommerce og eksterne systemer.

#Hva en WooCommerce-integrasjon egentlig er

I de fleste butikker bor ikke sannheten om produktene i WooCommerce. Den bor i ERP-et, i lagersystemet eller i et grossist-API. WooCommerce er salgsfronten, men lager, priser og deler av produktdataene kommer fra andre steder. En integrasjon er laget som holder disse to verdenene i overensstemmelse.

I praksis besvarer en integrasjon tre spørsmål:

• Hva vi synkroniserer - katalog, attributter, lagernivåer, priser, ordrer, kundedata.
• Hvilken retning - enveis (kildesystemet dikterer til butikken) eller toveis (for eksempel at ordrer flyter tilbake til ERP-et).
• Hvor ofte - fra planlagt polling hvert par minutter til hendelsesstyrte oppdateringer via webhooks.

#Hva du kan integrere med WooCommerce

Du trenger ikke å gjøre alt på én gang. Det vanligste første steget er synkronisering av lager og pris, fordi det lønner seg raskest i form av spart supporttid og unngåtte refusjoner.

#Hvordan datasynkronisering fungerer

Mekanikken er lik overalt, enten kilden er et ERP eller et grossist-API. Kilden er forskjellig, ikke prinsippet.

#Datamapping

Kildesystemet beskriver produkter med sin egen feltstruktur. Den første oppgaven til en integrasjon er å oversette dette til WooCommerces produkt- og attributtmodell: EAN og indeks som nøklene som knytter poster sammen, tekniske attributter til attributter og variasjoner, media og beskrivelser til produktsider. Vi holder feltkartet deklarativt, slik at det å legge til en ny parameter betyr å utvide mappingen, ikke å skrive om logikken.

#Synkronisering av lager og priser

Kjernen i de fleste integrasjoner er planlagt polling av to ting: lagernivå og pris. Varer som ikke er tilgjengelige i kildesystemet, blir automatisk skjult eller merket som utilgjengelige, noe som fjerner den dyreste feilen en butikk kan gjøre - å selge noe som ikke kan leveres. En prisendring i kildesystemet forplanter seg til butikken ved neste syklus.

#Marginlogikk

Priser fra et ERP eller en grossist er vanligvis kostpris, ikke salgsprisen. Over datainnhentingslaget ligger marginlogikk: systemet legger en definert margin på kildeprisen, og bare resultatet når WooCommerce. Eieren styrer lønnsomheten med regler, ikke ved å redigere priser for hånd.

#En ekte integrasjon

Den samme mekanikken ligger bak prosjektet vårt for en bildelsbutikk koblet direkte til et grossist-REST-API: WooCommerce-integrasjon med grossist-API. Der holder katalogen, lageret og prisene seg oppdatert av seg selv, og marginen beskytter lønnsomheten mot en leverandørliste i stadig endring.

#Hvilke ERP-systemer vi integrerer med

En viktig distinksjon: vi integrerer WooCommerce med API-et til disse systemene, vi implementerer ikke selve ERP-et. Dette er WordPress-, PHP- og datautvekslingsarbeid, ikke ERP-rådgivning.

• Sky-ERP: Microsoft Dynamics 365 Business Central, SAP Business One, Oracle NetSuite, Odoo. Disse eksponerer REST-API-er, noe som holder butikkoblingen ryddig.
• Norske regnskaps- og ERP-systemer: systemer som Tripletex, Visma eller PowerOffice Go, vanligvis integrert via API-et deres eller et mellomvarelag.

Er ikke systemet ditt på listen, men har et API eller en dataeksport, kan det som regel integreres.

#Hvordan vi arkitekturerer integrasjoner for spesifikke ERP-er

Hvert ERP har sitt eget API, dataformat og sine egne feller. Nedenfor er hvordan vi tilnærmer oss de vanligste systemene. Dette er arkitekturmønstre, ikke en plugin kjøpt for noen få kroner.

#SAP Business One - skala og wp_postmeta-problemet

Industriell distribusjon: titusenvis av aktive produkter, hyppige prisoppdateringer (flere ganger om dagen når valutakursene beveger seg), hundrevis av attributter. WordPress’ standard EAV-struktur lagrer hver attributt i wp_postmeta, som i den skalaen svulmer opp til millioner av rader; prisoppdateringer i sanntid gir da MySQL-deadlocks og 504-timeouter for kundene.

• HPOS og egendefinerte tabeller: vi slutter å skrive attributter til wp_postmeta og bruker en dedikert flat MySQL-tabell bygget for SAP B1-spørringer.
• Elasticsearch som søkelag: SAP oppdaterer data i Elasticsearch via API, og fronten henter resultater og filtre derfra, utenom MySQL. Dette laget kan kutte TTFB fra sekunder til rundt 150 ms.
• Kø (RabbitMQ): SAP-oppdateringer havner i en meldingskø, og en bakgrunnsarbeider henter grupper på noen hundre produkter om gangen, slik at butikken holder seg responsiv 24/7.

#Microsoft Dynamics 365 (med BaseLinker og POS)

En stor forhandler som selger gjennom WooCommerce, markedsplasser (via BaseLinker) og fysiske butikker med et POS på Dynamics 365. Uten et strengt hierarki får du synkroniseringssløyfer og race conditions (den siste enheten solgt i butikk og et sekund senere på en markedsplass), noe som gir negativt lager.

• Én kilde til sannhet: vi håndhever et hierarki der Dynamics er den absolutte master, og WooCommerce og BaseLinker er slaver.
• Redis-lag: i stedet for å polle det trege Dynamics-API-et konstant kjører vi Redis i minnet. Et salg i butikk utløser en webhook som oppdaterer Redis, og WooCommerce og BaseLinker sjekker tilgjengelighet i Redis (responstid på ensifret antall millisekunder) før de fullfører en handlekurv, noe som eliminerer oversalg.

#Odoo (åpen kildekode) - konfiguratorer for ordreproduksjon

Produsenter konfigurerer produkter i Odoo (en stykkliste) der prisen på en komponent avhenger av andre valg. WooCommerce-variasjoner kan ikke modellere dette, og å porte produksjonslogikken over i PHP gir kode som ikke lar seg vedlikeholde.

• Frakoblet / headless-tilnærming: WooCommerce er handlekurv- og transaksjonssystemet (betaling, e-poster), mens frontenden (Astro/Vue) snakker direkte med Odoo-API-et og spør om prising og produksjonsgjennomførbarhet i sanntid. Ved «legg i handlekurv» sendes et egendefinert produkt med en Odoo-beregnet pris og en generert spesifikasjons-PDF til WooCommerce, uten å duplisere forretningslogikken.

#Comarch Optima, InsERT Subiekt, enova365 (det polske og sentraleuropeiske markedet)

• Comarch Optima: Optima eksponerer data via en WebService/API, så vi bygger dedikert PHP-mellomvare og bruker differensiell (delta) synkronisering - en CRON-jobb spør bare etter indekser som er endret i det siste tidsvinduet, noe som kutter MySQL-belastningen med en størrelsesorden sammenlignet med en full import. B2B-priser beregnes i sanntid ut fra kundens rabattgruppe i stedet for å lagres som tusenvis av prisvariasjoner i wp_postmeta.
• InsERT Subiekt GT / nexo: datautveksling via EPP og API; en hard reservasjon låser lager i Subiekt i noen minutter ved kassen for å hindre oversalg under topper, og et korrigeringsdokument utløser en webhook som setter WooCommerce-ordren til returnert og legger varen tilbake på lager.
• enova365: for produkter med mange varianter (farger x størrelser, hver med sin egen EAN) bruker vi flate varianter mappet til JSON og lastet asynkront via REST, i stedet for å generere hundretusenvis av product_variation-poster.

#JTL-Wawi (Tyskland) og Holded (Spania)

• JTL-Wawi: omnikanal med flere lagre. Logisk ruting analyserer kundens postnummer og velger algoritmisk lageret med raskest frakt; One Stop Shop-håndtering beregner mva. på nytt i sanntid etter destinasjonsland, slik at fakturaen i JTL bærer riktig sats. WooCommerce kjører parallelt med BaseLinker for Amazon og eBay.
• Holded: et sky-basert, API-first ERP - en helt filfri integrasjon på det native REST-API-et med token-autentisering og webhooks. Fakturalogikken gjenkjenner handlekurvbeløpet og signaliserer til Holded om å generere riktig dokumenttype (for eksempel en forenklet faktura for små beløp), og returnerer en PDF som skal legges ved WooCommerce-e-posten.

#Enterprise-arkitektur: ytelse og pålitelighet

Ved stor ERP-skala går vi forbi «installer en plugin». Dette er tung ingeniørkunst:

• Headless / frakoblet: WordPress er admin-motoren (backend), og butikken rendres i Astro eller Next.js, som treffer et GraphQL- eller REST-API og går utenom treg SQL, noe som gjør butikken raskere og mer robust. Mer i enterprise-løsninger.
• Asynkron prosessering (køer): å synkronisere titusenvis av produkter i et vanlig PHP-skript gir timeout. Vi baserer det på køer (RabbitMQ eller Redis) som prosesserer små biter i bakgrunnen.
• Feilhåndtering og logging: hvis ERP-API-et ikke svarer, blokkerer vi kassen med en melding i stedet for å ta imot ordrer ut i intet; full feillogging gir rask diagnose.

#Tekniske problemer vi løser

• API rate limiting (429): skysystemer setter tak på forespørsler. Vi implementerer eksponentiell backoff (ved en 429 venter skriptet og prøver på nytt) pluss chunking, der vi pakker data i bulk-update-JSON-forespørsler i stedet for tusenvis av enkeltkall.
• Feil datatype (avrunding): et ERP kan holde priser med fire desimaler mens WooCommerce forventer to. I mellomvaren bruker vi streng type-casting og avstemmer avrunding per fakturalinje, for å unngå ørefeil som hoper seg opp over hundrevis av ordrer.
• Bilder, båndbredde og inode-grensen: å importere fysiske bilder inn i WordPress’ mediebibliotek (og generere flere miniatyrer av hvert) tømmer serverens filgrense. I stedet serverer vi bilder fra ekstern lagring (Amazon S3 eller Cloudflare Image Resizing) via URL-er mappet fra ERP-et, noe som sparer plass og gjør selve synkroniseringen raskere.

#Kartlegging før utvikling

Før vi velger teknisk løsning, lager vi et eierskapskart for dataene. Det angir hvilket system som er master for produktnummer, lager, pris, avgift, kunde og ordrestatus. Dersom både WooCommerce og ERP-et kan overskrive samme felt uten en konfliktregel, vil en ellers stabil integrasjon før eller siden danne en sløyfe eller gjeninnføre gamle verdier.

Kartleggingen dekker API-dokumentasjon, autentisering, rate limits, webhook-støtte og tilgang til et testmiljø. Vi ber om faktiske eksempelposter, ikke bare en endpoint-liste. Det er i eksemplene vi finner avvik mellom EAN og intern SKU, tomme variantverdier, ulike måleenheter, landavhengig mva. og priser som er netto i ett system og brutto i et annet.

Leveransen fra denne fasen er en flyttabell med kilde, mål, postnøkkel, frekvens, konfliktregel og ønsket oppførsel ved feil. Lager, økonomi og nettbutikkansvarlig kan da godkjenne forretningslogikken før den blir kode. Det reduserer risikoen for å automatisere en prosess som teamene egentlig tolker forskjellig.

#Feilmoduser i lager-, pris- og ordreflyten

Et lagertall kan være ferskt og likevel ikke være salgbart. ERP-et kan vise fysisk beholdning, mens nettbutikken må bruke tilgjengelig beholdning etter reservasjoner, sikkerhetsbuffer og salg i andre kanaler. Vi avklarer hvilken verdi som publiseres, hvordan negativ beholdning behandles og hvor lenge butikken kan stole på siste gyldige svar når kildesystemet er utilgjengelig.

Prisen kan endres mens kunden handler. Beslutningen er om handlekurven beholder prisen fra produktvalget, eller om den valideres igjen før betaling. B2B-rabatter, valuta, avrunding, kampanjer og avgift testes hver for seg. Synkroniseringen må verken overskrive en aktiv kampanje i stillhet eller sende en annen totalsum til ERP-et enn beløpet betalingsløsningen tok imot.

En ordre kan bli opprettet to ganger. Etter en timeout vet ikke WooCommerce nødvendigvis om ERP-et rakk å lagre ordren før forbindelsen brøt. Vi bruker derfor en idempotensnøkkel og et kontrollert retry-mønster. Ordrer som ikke kan behandles automatisk, går til en synlig feilkø med ansvarlig eier i stedet for å forsvinne i en generell serverlogg.

#Akseptanse med etterprøvbare bevis

Produksjonssetting bygger på avtalte scenarioer. Testlisten kan omfatte nytt produkt, endret variant, utsolgt og tilbake på lager, prisendring, ordre med flere varelinjer, kansellering, delretur og gjenoppretting etter API-avbrudd. Hvert scenario har definerte inndata, forventet tilstand i begge systemer og et bevis, som post-ID eller et personvernfiltrert loggutdrag.

Vi tester også ugyldige data, ukjent avgiftskode, utløpt token, 429-svar og payloads som bryter kontrakten. Godkjenning betyr ikke at normalflyten fungerte i én demo. Den betyr at teamet kan oppdage avviket, se om det er trygt å prøve igjen og vite når en person må ta en beslutning. Scenarioene blir en akseptanseprotokoll som kan brukes ved senere endringer.

#Operativ overlevering

Ved overlevering dokumenterer vi datamastere, tidsplaner, varsler, loggplassering og retry-prosedyre. Prosesseieren må vite hvem som reagerer når synkroniseringen stopper, hvem som godkjenner nye feltmappinger og når utsjekken bør stanses fordi lagergrunnlaget er usikkert. Hemmeligheter og API-nøkler legges i avtalt secret-lagring, ikke i driftsdokumentet.

Vi avtaler dessuten hvordan endringer skal innføres. Et nytt ERP-felt, en WooCommerce-oppdatering eller en endret statusflyt kan påvirke kontrakten selv om URL-en til API-et er uendret. Et testmiljø og en kort regresjonsliste gjør at en administrativ endring ikke uventet stanser ordrebehandlingen i produksjon.

#Dette bør stå i den skriftlige briefen

Send forutsetningene på e-post: ERP-navn og versjon, lenke til API-dokumentasjon, antall aktive produkter og varianter, salgskanaler, ønsket oppdateringsfrekvens og hvilke data som skal gå i hver retning. Legg ved et anonymisert produkt, en ordre og et priseksempel. Beskriv hvilket system som er dagens datamaster, og hvilke konkrete driftsfeil integrasjonen skal fjerne.

Da kan vi svare med kartleggingsomfang, avhengigheter og en trinnvis anbefaling uten å gjette. Hvis API-dokumentasjon ikke er tilgjengelig ennå, oppgi hvem som forvalter ERP-et og hvordan data eksporteres i dag. En skriftlig brief er nok til å avklare de viktigste risikoene før et tilbud, uten at et oppstartsmøte må være første steg.

#Når en integrasjon er verdt å vurdere

• Du oppdaterer lager og priser for hånd eller via filimport, og det skalerer ikke.
• Du får ordrer på produkter leverandøren egentlig ikke har på lager.
• Butikkprisene glir bort fra grossistens eller ERP-ets prisliste.
• Ordrer må tastes inn på nytt i regnskaps- eller lagersystemet for hånd.