Webshop og ERP-integration: sådan får I ordrer, lager og priser til at stemme

En god integration mellem webshop og ERP bygger på et enkelt princip: Hvert felt har én ejer og én skriveretning. Det betyder ikke, at data kun bevæger sig én vej. Ordren går fra webshop til ERP, mens ordrestatus og track-and-trace går den anden vej. Det enkelte felt rettes dog kun ét sted. Typisk ejer ERP- eller økonomisystemet varer, lager, priser, kundestamdata og fakturaer, mens webshoppen ejer selve ordren og betalingen, indtil ordren er overført. Når den fordeling er på plads, og integrationen håndterer fejl, dubletter og afvigelser kontrolleret, holder I op med at taste ordrer manuelt, og lagertal, kundepriser og moms begynder at stemme.

Nedenfor gennemgår vi, hvordan koblingen typisk bygges, hvordan dataobjekterne fordeles, og hvor det oftest går galt. Til sidst ser vi på, hvor AI giver mening som en ekstra kontrol, uden at den overtager beslutningerne. Artiklen handler specifikt om webshop og ERP. Koblingen mellem CRM og ERP, med tilbud, salgspipeline og kundestamdata, har andre problemstillinger og er behandlet i vores artikel om CRM- og ERP-integration. Den generelle side af sagen, hvordan AI-modeller kobles på jeres systemer via API, kan I læse om under AI-integrationer.

Hvad en integration mellem webshop og økonomisystem skal løse

De fleste SMV'er starter ikke med en integration. De starter med en webshop, et økonomisystem og en medarbejder, der kopierer ordrer fra det ene til det andet. Det fungerer ved ti ordrer om dagen. Ved halvtreds begynder det at knirke, og ved hundrede er det en fuldtidsopgave med indbyggede fejl.

Symptomerne er velkendte for både e-handelsansvarlige, lager og økonomiafdelinger:

• Oversalg: Webshoppen viser varer på lager, som allerede er solgt via telefon, forhandlere eller en anden kanal.
• Dobbeltbookede ordrer: Samme ordre oprettes to gange i ERP, fordi en overførsel blev gentaget efter en timeout.
• Forkerte B2B-priser: En erhvervskunde ser listepris i stedet for sin aftalte pris, eller en rabat gælder længere end aftalt.
• Momsfejl: Ordrer til EU-virksomheder med gyldigt momsnummer bogføres med dansk moms, eller fragt får en forkert momskode.
• Returer, der ikke lukkes: Varen er kommet retur på lageret, men kreditnotaen er aldrig lavet, eller pengene er refunderet i betalingsløsningen uden at blive bogført.

En integration skal fjerne de manuelle overførsler. Men den skal også gøre noget, som manuel tastning aldrig gør godt: give et samlet overblik over, hvad der er overført, hvad der fejlede, og hvorfor.

Hvem ejer hvad? Fordel dataobjekterne først

Den vigtigste beslutning tages, før der skrives en linje kode. For hvert dataobjekt, og i nogle tilfælde for hvert felt, skal I afgøre, hvilket system der er master, altså det sted, hvor data oprettes og rettes. Det andet system modtager en kopi og må ikke ændre den. Når to systemer begge må redigere samme felt, overskriver de hinanden, og ingen kan svare på, hvilket tal der er det rigtige.

En typisk fordeling for en B2B-virksomhed med webshop og ERP kunne se sådan ud:

Bemærk, at data om kunder og ordrer bevæger sig begge veje, men at hvert enkelt felt stadig kun har én ejer. Fordelingen er heller ikke den eneste rigtige. Pointen er, at den skal være skrevet ned og aftalt mellem e-handel, lager og økonomi, før integrationen bygges. Ellers bliver det udviklerens antagelser, der afgør, hvordan jeres data hænger sammen.

Ordreflow fra webshop til ERP – trin for trin

Ordreflowet er rygraden i integrationen. Et typisk forløb kunne være:

1. Ordren afgives i webshoppen, og betalingen autoriseres eller registreres som køb på konto for B2B-kunder.
2. Webshoppen sender en hændelse, typisk et webhook, om at der er en ny ordre. Alternativt henter integrationen nye ordrer med faste intervaller.
3. Integrationen validerer ordren: Findes alle varenumre i ERP? Er kunden kendt, eller skal der oprettes en debitor? Passer momskoden til leveringsland og kundetype?
4. Ordren oprettes i ERP med webshoppens ordrenummer som ekstern reference. Fragt, gebyrer og rabatter oversættes til de varelinjer og konti, som økonomiafdelingen har aftalt.
5. ERP bekræfter, og integrationen skriver ERP-ordrenummeret tilbage til webshoppen.
6. Plukning, pakning og afsendelse sker ud fra ERP eller lagersystemet, og status plus track-and-trace sendes tilbage til webshoppen.
7. Faktura dannes i ERP, og betalingen hæves og afstemmes.

Det tekniske greb, der forhindrer dobbeltbookede ordrer, hedder idempotens: Integrationen tjekker altid, om en ordre med samme eksterne reference allerede findes, før den opretter en ny. Hvis netværket hikker, og overførslen gentages, sker der intet, fordi ordren allerede er registreret. Det lyder banalt, men det er en af de hyppigste mangler i hurtigt opsatte koblinger.

Lige så vigtigt er det, hvad der sker, når en ordre fejler. Den må ikke bare forsvinde i en logfil. Den skal havne i en fejlkø, hvor en navngiven medarbejder kan se ordren og årsagen og rette den. Vil I læse mere om hele kæden fra ordre til faktura, har vi samlet erfaringerne om automatiseret ordrehåndtering.

Lagersynkronisering på webshoppen uden oversalg

Lagersynkronisering virker simpel: Send lagertallet fra ERP til webshoppen. I praksis er der fire forhold, der afgør, om det holder.

Disponibelt, ikke fysisk lager

Webshoppen skal vise det, der kan sælges, ikke det, der står på hylden. Disponibelt lager er fysisk beholdning minus varer, der er reserveret til åbne ordrer, eventuelt plus varer i bestilling med kendt leveringsdato, hvis I tillader restordrer. Forskellen mellem de to tal er ofte årsagen til oversalg.

Hyppighed og hændelser

Synkroniserer I lager én gang i timen, er der en time, hvor webshoppen kan sælge varer, der allerede er solgt i en anden kanal. Det er bedre at sende lagerændringer, når de sker, eller med korte intervaller for de varer, der har bevægelse. Mange virksomheder kombinerer løbende opdatering af ændringer med en fuld afstemning om natten, der retter eventuelle huller.

Sikkerhedsbuffer

For varer med få styk på lager kan det give mening at vise lidt mindre, end der reelt er, eller skifte til "få på lager" under en tærskel. Det er en forretningsbeslutning, ikke en teknisk, og den bør træffes af dem, der ejer kundeoplevelsen.

Sæt, varianter og flere lagre

Sælger I produktsæt, skal lagertallet for sættet beregnes ud fra komponenterne. Har I flere lagre eller et eksternt fulfillment-lager, skal integrationen vide, hvilke lagre der tæller med. Varianter som størrelse og farve skal mappes én til én mellem webshoppens variant-id og ERP's varenummer.

B2B-webshop med kundespecifikke priser og korrekt moms

For B2B-virksomheder er priser ofte det sværeste. En erhvervskunde forventer at se netop sin pris, ikke listeprisen med en generel rabat. I ERP ligger prisen typisk som en kombination af listepris, kunderabatgruppe, varerabatgruppe, aftalepriser og mængderabatter.

Der er overordnet to måder at få priserne ud på webshoppen:

• Synkroniserede prislister: Integrationen beregner og sender prislister pr. kunde eller kundegruppe til webshoppen. Det er hurtigt for kunden, men kræver, at alle prisændringer i ERP udløser en opdatering.
• Prisopslag i realtid: Webshoppen spørger ERP om prisen, når kunden er logget ind. Det giver altid den aktuelle pris, men stiller krav til ERP's svartider og til, hvad der sker, hvis ERP ikke svarer.

Uanset model bør ordren, der kommer tilbage til ERP, valideres mod den pris, ERP selv ville have beregnet. Er der en afvigelse, skal ordren stoppes til kontrol frem for at blive bogført med forkert pris.

Moms følger samme logik. Integrationen skal kende reglerne for danske kunder, EU-erhvervskunder med gyldigt momsnummer, EU-forbrugere og kunder uden for EU. Ved ordrer med blandede momssatser eller momsfrie varer skal momsbehandlingen af fragt og gebyrer afklares med jeres revisor, før den bygges ind. Afrunding skal ske ét sted, ellers ender I med ørediffer mellem ordre og faktura. Momskoderne sættes op af økonomiafdelingen eller revisor; integrationens opgave er at håndhæve dem konsekvent.

Hvor det typisk går galt – og hvor AI kan hjælpe

De fleste problemer skyldes ikke dårlig kode, men uafklarede regler og manglende overvågning. De klassiske faldgruber er:

• Varenumre, der ikke er ens i de to systemer, eller som er genbrugt til nye produkter.
• Rabatkoder og gavekort i webshoppen, som ERP ikke har en måde at bogføre på.
• Delleveringer og annulleringer efter overførsel, hvor kun det ene system bliver opdateret.
• Returer, hvor varen modtages, men kreditnota og refusion ikke hænger sammen.
• Fejl, der logges, men som ingen ser, før en kunde ringer.

Her kan AI gøre en konkret forskel, ikke som erstatning for integrationen, men som et ekstra lag af kontrol. En AI-model kan gennemgå fejlkøen og foreslå årsag og rettelse, fx: "Varenummer 4711-B findes ikke i ERP, men 4711B gør – skal ordrelinjen mappes dertil?" Den kan sammenligne ordrens priser med kundens prisaftale og markere afvigelser. Og den kan opdage mønstre, som faste regler ikke fanger, fx at en bestemt variant gentagne gange sælges i større antal, end lageret tillader.

Indsigt: AI er bedst til at finde og forklare afvigelser, ikke til at rette dem selv. Lad modellen foreslå rettelsen, lad en medarbejder godkende den, og log både forslaget, beslutningen og hvem der tog den. Så får I hastigheden uden at miste sporbarheden.

Det kræver et par klare rammer. AI'en skal kun have adgang til de data, den har brug for. Ordre- og kundedata indeholder personoplysninger, så der skal være styr på databehandleraftaler, hvor data behandles, og hvor længe logs gemmes. Rettelser, der påvirker bogføring eller kundens pris, skal altid godkendes af et menneske, og alle handlinger skal kunne spores bagefter, så økonomiafdelingen kan se, hvorfor en ordre blev ændret.

Sådan kommer I i gang med webshop og ERP-integration

Et godt forløb tager udgangspunkt i jeres arbejdsgange, ikke i teknologien. Vi anbefaler denne rækkefølge:

1. Kortlæg de manuelle opgaver i dag. Hvem taster hvad, hvor ofte, og hvor opstår fejlene? Tal med lager, kundeservice og økonomi, ikke kun med den, der ejer webshoppen.
2. Beslut ejerskab pr. dataobjekt og felt. Brug tabellen ovenfor som udgangspunkt, og skriv jeres egen version ned.
3. Ryd op i stamdata. Entydige varenumre, korrekte momskoder og opdaterede kundekort sparer mange fejl, uanset løsning.
4. Byg ordreflowet først. Det er typisk der, den største manuelle tid ligger. Lager og priser følger efter.
5. Indbyg fejlkø og overvågning fra start. Beslut, hvem der ejer fejlkøen, og hvor hurtigt fejl skal håndteres.
6. Test med rigtige ordrer. Tag de skæve med: en B2B-kunde i Tyskland, en ordre med rabatkode og produktsæt, en delvis retur.
7. Tilføj AI-kontrol, når grundflowet kører stabilt. Start med at lade AI foreslå rettelser i fejlkøen, og udvid derfra.

Om integrationen skal bygges med en standardconnector, en integrationsplatform eller som specialudvikling, afhænger af jeres systemer og af, hvor mange særregler I har. Standardløsninger dækker ofte det simple ordreflow godt, men kommer til kort ved kundespecifikke priser, flere lagre eller særlige returregler. Hver platform har desuden sine egne forhold omkring varianter, kundegrupper og API'er. Vi har samlet de praktiske detaljer på webshopsiden for Shopify-integration, WooCommerce-integration og Magento og Adobe Commerce og på ERP-siden for Business Central-integration, Uniconta-integration og e-conomic webshop integration.

Er I i tvivl om, hvor I skal starte, eller vil I have et kvalificeret bud på, hvor AI kan aflaste ordre- og fejlhåndteringen, kan I booke en AI-afklaring. Den tager udgangspunkt i jeres konkrete systemer og arbejdsgange, ikke i en standardpakke.