Så får ni Business Central och Magento att hålla ihop i drift

Ni står ofta mitt i samma läge. Webbplatsen tar emot order, affärssystemet uppdateras, och ändå stämmer lagret fel någonstans mellan systemen. Det är där många integrationsprojekt mellan Business Central och Magento tappar fart, eftersom problemet handlar om ansvar, återhämtning och ordning i flödet.

År 2024 tog 30 procent av svenska företag med minst 10 anställda emot beställningar via egen webbplats, app eller e-handelsplattform, men andelen var bara 21 procent i tillverkningsindustrin och 54 procent i handel och service av motorfordon, enligt SCB. Det säger två saker samtidigt. Digital ordermottagning är etablerad, men kraven varierar kraftigt mellan verksamheter.

Skillnaden mellan en skör och en stabil koppling

En skör koppling märks sällan på en vanlig tisdag. Den märks när kampanjen går live, när ordervolymerna sticker iväg eller när någon skickar om samma order efter ett timeout-fel. Då visar det sig om integrationen tål upprepade meddelanden, fördröjningar och felköer.

Direkta databasanrop och täta synkrona API-anrop vid varje sidvisning ser enkla ut på ritbordet. I produktion blir de ofta dyra att bära, eftersom varje belastningstopp samtidigt slår mot katalog, lager och kassa. Microsoft beskriver också att Business Central-API:er har tids- och kapacitetsbegränsningar, och att en begäran som kör längre än 10 minuter kan avslutas med HTTP 504 i den officiella API-dokumentationen.

En välbyggd integration mellan Business Central och Magento bygger därför på köer, återförsök och idempotens. Idempotens är skyddet mot dubbelbokningar, och den måste finnas med redan från början. Samma meddelande kan tas emot flera gånger utan att systemet bokför ordern dubbelt eller skriver över rätt data med gammal data.

Felhantering väger tyngre än själva dataflytten. Lösningen behöver återhämta sig vid avbrott. En bra integration ska kunna pausa, fortsätta och avstämmas, utan att någon behöver jaga manuella korrigeringar i efterhand.

Systemägarskap och kanoniska fältkontrakt

Ni behöver bestämma vilket system som äger varje del av sanningen innan en enda synk körs. Om båda systemen får rätt att uppdatera samma uppgift uppstår konflikt förr eller senare. Då spelar det mindre roll hur fint gränssnittet ser ut.

Affärssystemet bör vara styrande källa för lager, bokföringsrelevanta priser och orderstatus. E-handelsplattformen bör äga presentation, kundvagn och kanalunika attribut. Den uppdelningen minskar risken för att en prisändring på webben råkar skriva över ekonomiska uppgifter som redan ska styra bokföringen.

Ett kanoniskt fältkontrakt gör resten av arbetet möjlig. Det behöver omfatta artikelnummer, variantstruktur, enheter, momskoder, prislistor, kundsegment, lagerställen, orderstatus och leveransvillkor. När kontraktet är tydligt kan ni avgöra om ett fält ska skickas, beräknas eller bara läsas.

I praktiken handlar det om att dokumentera vad som styrs av affären och vad som visas mot kund. För produktdata kan det vara fullt rimligt att Magento visar kanalunika texter eller attribut medan affärssystemet fortsätter bära de ekonomiska uppgifterna. Den gränsen måste vara uttalad, annars blir varje fel senare ett diskussionsärende.

Ni kan läsa mer om hur vi brukar resonera kring integrationer mot affärssystem när ansvaret måste ritas upp innan implementationen börjar.

Selektiv realtid ger högre driftsäkerhet

Lagerstatus, orderbekräftelser och leveransstatus behöver ofta snabb uppdatering. Kataloger, prislistor och fulla lagerladdningar mår bättre av schemaläggning och kontrollerade batchflöden.

Ni vinner på att skapa en enkel beslutsmatris. Fråga först hur kritiskt objektet är för köpupplevelse eller bokföring. Fråga sedan hur dyrt det är att göra en extra körning och vad som händer om den körningen försenas.

Den här uppdelningen är särskilt viktig när katalogen är stor eller när orderflödet är känsligt. Om tung produktberikning delar resurser med orderöverföring kan kassan bli långsam precis när den borde vara snabb. Då känns hela lösningen opålitlig, trots att problemet egentligen sitter i fel prioritering.

En lösning måste därför tåla både låg och hög intensitet både låg och hög intensitet utan att tappa kontrollen över status och lager. Där passar en köbaserad arkitektur bättre än en modell som försöker vara helt omedelbar överallt.

För den som vill fördjupa sig i en plattformsneutral syn på ansvar och gränsdragning finns vår whitepaper om ERP-first integrationsstrategi.

Orderlivscykeln med kundunika villkor

Många projekt blir tekniskt korrekta och affärsmässigt för tunna. De synkar produkter och order, men lämnar resten av livscykeln orörd. Då fungerar startpunkten medan flödet efteråt fallerar.

En order kan behöva gå genom kreditprövning, godkännande, delleverans, faktura, reklamation och retur innan den är färdig. Om kundunika prislistor och kreditgränser inte följer med i samma struktur får kundportalen en egen verklighet, medan affärssystemet fortsätter på sin egen. Det är där handpåläggningarna brukar börja.

Orderhistorik från andra kanaler bör också visas i kundkontot efter inloggning. Då får kunden en samlad bild av det som skapats i webben och det som redan ligger i affärssystemet från andra säljvägar. För många etablerade bolag är den här sammanhållningen central.

En bra modell skiljer därför mellan orderinitiering, orderstatus, fakturering och efterköpsflöden. Det gör det möjligt att spåra vad som hänt utan att hela kedjan blir beroende av manuell support. Fördjupning kring produktdata och strukturerad publicering finns i vårt whitepaper om PIM i praktiken, eftersom svag produktstyrning ofta blir första orsaken till svaga orderflöden.

Gränsöverskridande handel och europeisk moms

När försäljning går över EU-gränser blir momslogiken en del av integrationens kärna. Skatteverket anger att företag som säljer varor för minst 99 680 kronor per år till privatpersoner i andra EU-länder ska ta ut moms enligt köparens lands regler, och att unionsordningen inom OSS kan användas i stället för separata registreringar. Uppgifterna finns hos Skatteverket.

Land, momssats, nettoförsäljning och utgående moms måste följa med på ett spårbart sätt från order till redovisning. För den som använder OSS ska försäljningen dessutom redovisas per EU-land, med belopp i euro och uppdelning per momssats.

Det här styr också hur ni modellerar ordermeddelandet. Om ni saknar landkod, skattesats eller tydlig uppdelning av belopp riskerar ekonomiteamet att behöva lägga tid på efterhandskorrigeringar. Det skapar manuellt arbete och försvagar spårbarheten mellan kassan och bokföringen.

En stabil integration behöver därför bära juridiska och ekonomiska uppgifter lika noggrant som produkt- och lagerdata. När det görs rätt blir redovisningen enklare att stämma av och kundkommunikationen tydligare. När det görs slarvigt blir varje land en speciallösning.

Teststrategi och parallell drift

En integration behöver bevisas i verkliga flöden, felhantering och avstämning mot verkliga dokument. Därför behöver testfasen likna produktion så mycket som möjligt.

Dubbla ordermeddelanden måste testas, eftersom samma order kan skickas om efter en timeout. Partiella leveranser måste testas, eftersom inte alla flöden är fulla leveranser. Och återställning från felkö måste testas, eftersom det är där driftteamet annars hamnar när något redan gått fel.

Ni bör också köra parallell drift ett tag innan den gamla lösningen stängs av. Då kan ni stämma av ordervärde, antal order, lagerkvantitet och momsbelopp dag för dag. Det är ett tråkigt steg, men det är ofta här ni hittar de avvikelser som aldrig syntes i utvecklingsmiljön.

Timeout under hög belastning ska ingå i testplanen, liksom borttagna artiklar och omskrivna priser. När dessa fall fungerar vet ni att lösningen tål verklig drift. När de fallerar vet ni också var ansvarslinjen behöver skärpas innan go-live.

Frågorna som avslöjar leverantörens ansvar

Hur hanteras dubbla meddelanden när samma order kommer in två gånger och hamnar i felkön? Svaret visar hur väl lösningen klarar återförsök, idempotens och drift utan dubbelbokningar.

Vad ingår i löpande förvaltning när systemen uppgraderas, och hur hanteras kostnaden för uppgraderingar och löpande förvaltning? Svaret visar om leverantören har en tydlig modell för versionsuppföljning, kompatibilitet och ansvar över tid.

Hur återställs lösningen efter ett avbrott? Svaret visar hur väl lösningen är byggd för drift och hur snabbt verksamheten kan komma tillbaka utan manuella nödlösningar.

Integrationen måste fortsätta fungera när verksamheten ändras, växer och uppgraderas. Därför arbetar vi med färdigutvecklade funktioner och avtalat ansvar över tid i Glanser Care.

Ni får bäst utväxling om ni börjar med en genomlysning av nuläget, systemägarskapet och de flöden som faktiskt bär intäkter och redovisning. Vår 72h-analys ger er en inventering av funktionalitet och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan inom 72 timmar, kostnadsfritt och med underlaget på  ert bord.