En kund ser en produkt som finns i lager, lägger sin order och får rätt pris. Samtidigt ska lagersaldot uppdateras, ordern hamna hos rätt person och bokföringen få underlag som går att lita på. Det är precis där en API-integration mellan affärssystem och webbutik gör verklig skillnad. När den är rätt planerad slipper ni inte bara dubbelregistrering – ni minskar också risken att sälja slut produkter, missa beställningar eller fatta beslut på fel data.
Men en integration är sällan bara en teknisk koppling mellan två system. Den påverkar hur order, lager, kunder, priser och returer hanteras i vardagen. Därför börjar ett bra integrationsprojekt med verksamheten, inte med en API-nyckel.
Vad ska synkas mellan systemen?
En webbutik och ett affärssystem har olika huvuduppgifter. Webbutiken ska hjälpa kunden att hitta, förstå och köpa rätt produkt. Affärssystemet är ofta källan för artikeldata, saldo, inköp, fakturering och ekonomi. Integrationen ska se till att systemen delar rätt information vid rätt tillfälle.
Det vanligaste är att produkter, lagersaldon och priser hämtas från affärssystemet till webbutiken. I andra riktningen skickas nya order, kunduppgifter och ibland betalstatus tillbaka. Men exakt vilka fält som ska följa med beror på hur ni arbetar.
Ett företag med ett enda lager kan ofta börja enkelt: artikelnummer, namn, pris, saldo och order. Har ni flera lager, olika kundgrupper, återförsäljare eller försäljning i flera länder behövs fler regler. Då kan det till exempel vara avgörande om kunden ska se totalt saldo, saldo i ett visst lager eller bara produkter som kan skickas samma dag.
Här är en viktig princip: synka inte allt bara för att det går. Varje extra fält innebär fler beroenden, fler undantag och mer att testa. Jag brukar i stället börja med att reda ut vilken information som faktiskt behöver vara korrekt för att kunden och teamet ska kunna göra sitt jobb.
API-integration mellan affärssystem och webbutik börjar med ansvar
Den vanligaste frågan är inte vilket system som är bäst, utan vilket system som äger informationen. Om samma pris kan ändras både i webbutiken och i affärssystemet uppstår förr eller senare en konflikt. Detsamma gäller produkttexter, lagersaldo och kunddata.
I många projekt är affärssystemet huvudkälla för artikelnummer, inköpsrelaterad data och lager. Webbutiken ansvarar för produktpresentation, bilder, kategorier och innehåll som hjälper kunden att köpa. Ordern skapas i webbutiken men blir sedan ett underlag i affärssystemet för leverans, faktura eller bokföring.
Det finns undantag. Vissa företag arbetar aktivt med kampanjpriser och produktinformation direkt i sin webbutik. Andra har ett PIM-system för produktdata och låter affärssystemet fokusera på ekonomi och lager. Det viktiga är inte att följa en mall, utan att bestämma ansvar tydligt innan utvecklingen börjar.
Om två system får ändra samma uppgift behöver ni också en regel för vad som händer vid krockar. Ska senaste ändringen vinna? Ska en ändring stoppas och granskas? Eller ska vissa fält aldrig kunna ändras i ett av systemen? Tydliga svar här sparar mycket felsökning senare.
Välj rätt rytm för synkningen
Många tänker att allt måste ske i realtid. Ibland stämmer det, men inte alltid. Realtid kan vara rimligt för lager på populära produkter där ett fåtal enheter kan sälja slut snabbt. För produktbeskrivningar eller kategorier kan en synkning varje timme eller natt vara fullt tillräcklig.
Det finns tre vanliga sätt att uppdatera data. Antingen hämtar webbutiken information med jämna mellanrum, eller så skickar affärssystemet en signal när något ändras. Det går också att kombinera metoderna: snabba händelser för order och lager, plus en nattlig kontroll som fångar upp sådant som eventuellt missats.
Realtid ger snabbare data, men ställer högre krav på tillgänglighet och felhantering. Om affärssystemets API tillfälligt ligger nere ska inte en kundorder försvinna. Den ska kunna läggas i kö, sparas säkert och skickas igen när tjänsten fungerar. En synkning som fungerar när allt är normalt är bara halva jobbet.
Det som ofta glöms bort: fel, ändringar och undantag
En integration behöver hantera mer än nya produkter och perfekta order. Vad händer när en produkt utgår? När en order makuleras efter betalning? När en kund anger en ny leveransadress, eller när frakten behöver delas upp i två sändningar?
Det är också vanligt att artikelnummer saknas, att ett prisformat skiljer sig mellan systemen eller att momsen beräknas på olika sätt. Sådana detaljer kan verka små, men de påverkar både kundupplevelsen och ekonomin. Därför behöver data valideras innan den skickas vidare.
Jag brukar planera för att integrationen ska kunna svara på tre praktiska frågor: Vad har hänt? Vad gick fel? Vad behöver någon göra nu? Det innebär bland annat tydliga loggar, felmeddelanden som går att förstå och en möjlighet att köra om en enskild order utan att skapa dubbletter.
Dubbletter är en klassiker. Om webbutiken skickar en order, inte får något svar och försöker igen, får affärssystemet inte skapa två order av samma köp. Lösningen är ofta att använda unika externa order-ID:n och låta systemet känna igen en order som redan har tagits emot.
Så planerar du integrationsprojektet utan onödiga överraskningar
Innan kod skrivs behöver ni få en bild av dagens flöde. Inte bara hur det borde fungera, utan hur personalen faktiskt arbetar när en order kommer in, en vara tar slut eller en kund ringer med en fråga. Ofta finns manuella steg som är viktiga och som inte får försvinna av misstag.
En bra förstudie brukar landa i ett konkret flöde: vilken data som går åt varje håll, vilket system som äger respektive uppgift och när uppdateringen ska ske. Därefter går det att bedöma om affärssystemets API räcker för behovet, om det finns begränsningar i antal anrop och om en mellanliggande integrationslösning behövs.
Det här är också rätt läge att kontrollera behörigheter. Ibland finns API-stöd, men kontot saknar åtkomst till lager, orderstatus eller kundinformation. I andra fall kräver leverantören en särskild tilläggstjänst. Ju tidigare detta kontrolleras, desto säkrare blir både tidsplan och kostnad.
När omfattningen är tydlig delar jag helst upp arbetet i hanterbara delar. Börja exempelvis med produkter och lager, följt av orderflödet. Då går det att testa med verkliga artiklar och riktiga arbetsrutiner innan fler delar kopplas på. En mindre första version kan vara betydligt bättre än ett stort projekt som blir svårt att överblicka.
Testa med situationer från verkligheten
Att en produkt kan importeras är inte samma sak som att integrationen är klar. Testningen behöver spegla vardagen. Det kan handla om en vara med nollsaldo, en rabattkod, flera momssatser, ett köp från en företagskund eller en order som återbetalas.
Före lansering bör ni minst kontrollera följande:
- att artikelnummer, priser och moms blir rätt i båda systemen
- att lager uppdateras vid köp, makulering och återbetalning
- att order inte skapas dubbelt om kommunikationen avbryts
- att ansvarig person får veta när synkningen kräver manuell åtgärd
Det är klokt att låta den som arbetar med order och ekonomi vara med i testet. En teknisk testmiljö kan visa att API-anropen fungerar, men det är verksamheten som ser om resultatet faktiskt går att använda.
Bygg för drift, inte bara för lansering
Affärssystem uppdateras, produkter förändras och webbutiken får nya funktioner. En integration behöver därför vara tydligt dokumenterad och byggd så att den går att följa upp. Det betyder inte att lösningen måste bli stor eller komplicerad. Det betyder att någon ska kunna förstå vilka data som skickas, var fel syns och hur ändringar kan göras utan att påverka orderflödet.
För mindre företag är en enkel, genomtänkt integration ofta rätt väg. För en växande webbutik med flera försäljningskanaler kan det vara värt att investera mer i köhantering, övervakning och tydliga administrationsvyer. Rätt nivå beror på ordervolym, systemens begränsningar och hur dyrt ett fel blir för er.
När du planerar en API-integration, utgå från den order eller lagerändring som måste fungera även en stressig måndag. Får den ett tydligt flöde, rätt ansvar och en plan B när något går fel, har du en lösning som hjälper verksamheten på riktigt.