Magento B2B og Business Central: Når priser, kunder og ordrer skal spille sammen

En B2B-webshop er sjældent bare en almindelig webshop med login.

For B2B-kunden handler det ikke kun om at finde en vare og trykke “køb”. Kunden forventer at kunne se de rigtige priser, bestille på vegne af virksomheden, bruge aftalte betalingsvilkår og vide, om varen faktisk kan leveres.

Det stiller nogle lidt større krav til dataflowet.

Når Magento eller Adobe Commerce skal spille sammen med Dynamics 365 Business Central, er det derfor vigtigt, at integrationen understøtter den måde, jeres kunder og medarbejdere arbejder på i virkeligheden.

Ikke bare den måde, det ser pænt ud på i et flowchart.

[Indsæt diagrammet her]

B2B starter med at kende kunden

I en B2C-webshop er prisen ofte den samme for alle. I B2B er det sjældent tilfældet.

Én kunde kan have en helt særlig prisaftale. En anden handler efter volumenrabatter. En tredje må kun se et bestemt sortiment. Og nogle virksomheder har flere brugere, der alle bestiller på vegne af samme debitor.

Det betyder, at webshoppen skal vide, hvem kunden er, før den kan vise den rigtige oplevelse.

Business Central vil ofte være sandhedskilden for:

• Debitorer og kontaktpersoner
• Kundespecifikke priser
• Rabatgrupper
• Betalingsbetingelser
• Kreditgrænser
• Leveringsadresser
• Tilgængelige varer og sortiment

Magento sørger så for, at oplysningerne bliver præsenteret, så kunden faktisk kan bruge dem.

Kundespecifikke priser uden hovedpine

Priser er ofte kernen i en B2B-integration.

Hvis en kunde logger ind og ser en forkert pris, skaber det ekstra arbejde for salgsteamet. Hvis kunden kan købe til en pris, der ikke matcher aftalen i Business Central, kan det blive dyrt.

Derfor skal I få afklaret:

• Skal priser styres direkte fra Business Central?
• Skal Magento kunne køre kampagner oven på en aftalt pris?
• Hvordan håndteres mængderabatter?
• Hvad skal kunden se før og efter login?
• Skal priser vises inklusive eller eksklusive moms?
• Hvad sker der, hvis en aftale ændres?

Business Central har standardfunktionalitet til blandt andet salgspriser, debitorpriser og rabatter. Se Microsofts gennemgang af specialsalgspriser og rabatter i Business Central.

Det betyder ikke, at standardopsætningen automatisk passer til webshoppen. Prislogikken skal stadig mappes og testes, så Magento viser den samme virkelighed, som salg og økonomi arbejder med.

Sådan bør dataflowet se ud

En god B2B-integration kan opdeles i fire tydelige dataflow.

Kunde og konto: Business Central til Magento

Kundeoplysninger, kontaktpersoner, leveringsadresser, kreditregler og rettigheder skal være tilgængelige, når den rigtige bruger logger ind.

Her skal I især afklare, om kunder selv må oprette brugere, eller om det skal godkendes af jeres team.

Pris og sortiment: Business Central til Magento

Webshoppen skal kunne vise kundens egne priser og kun de varer, kunden må købe.

Undgå at bygge de samme prisregler to gange. Hvis Business Central er sandhedskilden, skal Magento modtage og vise resultatet — ikke forsøge at gætte det igen.

Ordre: Magento til Business Central

Når kunden bestiller, skal ordren indeholde de informationer, der er nødvendige for, at den kan behandles uden manuel oprydning.

Det kan være kundenummer, rekvisitionsnummer, leveringsadresse, ordrelinjer, fragt, betalingsmetode og kommentarer. Har I særlige krav til del-leverancer eller godkendelse, skal de med i designet fra begyndelsen.

Levering og faktura: Business Central til Magento

Kunden forventer at kunne følge sin ordre.

Derfor bør levering, restordrestatus, tracking, faktura og eventuel kreditnota kunne sendes tilbage til Magento. Det giver kunden bedre selvbetjening og fjerner en del spørgsmål fra kundeservice.

Selvbetjening, der faktisk sparer tid

En B2B-webshop skal ikke nødvendigvis erstatte jeres sælgere.

Men den kan gøre det lettere for kunderne at klare de mest almindelige ting selv:

• Genbestille tidligere køb
• Se egne priser
• Hente fakturaer
• Følge ordrestatus
• Administrere brugere og leveringsadresser
• Bestille, når det passer dem

Det frigiver tid hos både kunden, kundeservice og salgsteamet. Sælgerne kan bruge energien på rådgivning, større aftaler og de kunder, der har brug for mere end en genbestilling.

Win-win, som man siger.

Test mere end den pæne standardordre

B2B-løsninger fejler sjældent på den helt almindelige ordre.

Derfor skal I teste scenarier som:

• En kunde med en særpris
• En mængderabat
• Flere brugere på samme debitor
• Flere leveringsadresser
• En ordre med restordre
• En kunde, der ikke må købe hele sortimentet
• En retur eller kreditnota

Det er i de situationer, I opdager, om integrationen understøtter jeres forretning — eller kun en forenklet version af den.

Læs også vores guide til dataflow mellem Magento og Business Central, hvis I vil have overblik over produkt-, lager-, ordre- og kundedata på tværs af systemerne.

Er Magento og Business Central den rigtige kombination?

Hvis I har komplekse B2B-priser, mange kunder, store varekataloger eller behov for et stærkt dataflow mellem webshop og ERP, kan Magento og Business Central være en stærk kombination.

Men den virker kun for alvor, når integrationen er bygget efter jeres forretning.

Har I brug for bedre styr på kundespecifikke priser, debitorer, ordreflow og lager mellem Magento og Business Central? Læs mere om Connectifys Magento-integration og få en afklaring af, hvad der giver mening i netop jeres setup.

Fra NAV til Business Central: Hvad sker der med Magento-integrationen?

At flytte fra Dynamics NAV til Business Central er ikke bare et ERP-projekt.

Hvis Magento eller Adobe Commerce er en vigtig del af jeres forretning, er det også et e-commerce-projekt. For når ERP-systemet flytter, skal data stadig finde vej mellem webshop, lager, økonomi, kunder og måske en hel flok andre systemer.

Det kan lyde som en stor mundfuld.

Og det er det også lidt.

Men med den rigtige plan behøver det ikke blive en omgang systemgymnastik, hvor alle holder vejret, indtil den første ordre går igennem.

[Indsæt diagrammet her]

Magento-integrationen skal med fra starten

En klassisk fejl er at behandle Magento-integrationen som noget, man lige tager efter ERP-migreringen.

Det kan blive dyrt.

Webshoppen er ofte afhængig af data fra NAV: produkter, lager, priser, kunder, ordrer og leveringsstatus. Hvis den logik ikke er afklaret, før I går live med Business Central, risikerer I fejl i driften på det tidspunkt, hvor I mindst har lyst til det.

Derfor bør Magento-integrationen være en del af foranalysen fra dag ét.

Læs mere om NAV-webshop integration hos Connectify.

Start med at kortlægge det, der virker i dag

Før I bygger noget nyt, skal I vide, hvad der allerede er i spil.

Lav en oversigt over jeres nuværende dataflow:

• Hvordan kommer ordrer fra Magento til NAV?
• Hvor kommer lagerstatus fra?
• Hvem styrer priser og rabatter?
• Hvordan oprettes kunder og debitorer?
• Hvordan sendes leveringsstatus og tracking tilbage til webshoppen?
• Er PIM, WMS, 3PL, betalingsløsninger eller markedspladser en del af arkitekturen?

Det er fristende bare at kigge på den gamle integration og sige: “Sådan gør vi igen.”

Men flytningen til Business Central er også en oplagt mulighed for at rydde op. Måske findes der manuelle arbejdsgange, som kan automatiseres. Måske bliver data opdateret to steder i dag. Måske er der integrationer, I slet ikke behøver længere.

Ikke alt gammelt skal flyttes med videre. Heldigvis.

Vælg migrationsvejen med åbne øjne

Det er ikke alle NAV-løsninger, der kan flyttes på samme måde. Tilpasninger, datakvalitet og versionen af NAV har betydning for projektet.

Microsoft beskriver både en fuld migration og en reimplementering med de vigtigste data som mulige veje, afhængigt af udgangspunktet. Se Microsofts aktuelle vejledning om migrering fra NAV til Business Central.

Uanset hvilken vej I vælger, bør Magento-dataflowet have sin egen plan. Der skal være styr på, hvad der flyttes, hvad der bygges på ny, og hvilke funktioner webshoppen skal kunne på den anden side.

De fem trin, der bør være med i planen

1. Kortlæg data og tilpasninger

Find ud af, hvor jeres data lever i dag, og hvilke NAV-tilpasninger der påvirker Magento.

Det gælder især varedata, priser, kunder, lager, ordrer, fakturering og levering. Hvis en proces i dag afhænger af en særlig NAV-tilpasning, skal I have afklaret, om den findes, skal bygges eller kan undværes i Business Central.

2. Ryd op før flytningen

En migration er et godt tidspunkt at tage fat i dubletter, gamle varer, inaktive kunder og processer, ingen længere bruger.

Det er ikke altid sjovt. Men det er markant bedre at rydde op før data flyttes end at tage rod med over i den nye løsning.

3. Definér det nye dataflow

Her skal I beslutte, hvilket system der ejer hvilke data.

Business Central vil ofte være sandhedskilden for varer, lager, debitorer og prislogik, mens Magento ejer kundeoplevelsen, indholdet og checkout-processen. Men det afhænger af jeres setup.

Læs vores guide om dataflow mellem Magento og Business Central for en mere detaljeret gennemgang.

4. Test rigtige hverdagsscenarier

Test ikke kun én helt almindelig ordre.

Test også en B2B-kunde med særpris, en ordre med rabat, en restordre, en refundering, en ordre med flere leveringsadresser og en vare, der netop er gået ud af lager.

Det er i hjørnerne, fejlene gemmer sig.

En god test bør følge hele rejsen: fra Magento til Business Central og tilbage igen med ordrestatus, levering og faktura.

5. Planlæg go-live og tiden efter

På selve flyttedagen skal det være klart:

• Hvornår gamle integrationer stopper.
• Hvornår nye dataflow aktiveres.
• Hvem der godkender lager, priser og ordrer.
• Hvem der håndterer fejl.
• Hvordan I afstemmer, at data faktisk matcher.

Lav gerne en enkel afstemningsrapport de første dage: antal ordrer, ordrebeløb, lagerbevægelser og fejl i integrationskøen. Det er ikke glamourøst, men det giver ro i maven.

De klassiske faldgruber

Kundedata, der ikke matcher. Priser, der kommer fra flere steder. Lager, der ser rigtigt ud, indtil det ikke gør. Eller ordrer, der stopper uden varsel.

Det er ikke problemer, der løses med flere møder. De løses med tydelige dataejere, test og en integrationsløsning, der kan vise, når noget kræver handling.

Og én vigtig ting mere: Undgå at lade begge systemer skrive i de samme felter i overgangsperioden. Det er sjældent en god idé at lade NAV, Business Central og Magento konkurrere om, hvem der har ret.

Flytningen er også en chance for at gøre det bedre

Når NAV bliver til Business Central, behøver I ikke bare kopiere den gamle måde at arbejde på.

I kan bruge processen til at:

• Fjerne dobbeltarbejde
• Automatisere manuelle opgaver
• Skabe bedre lager- og ordreoverblik
• Gøre det lettere at håndtere flere ordrer
• Give kunderne bedre information om priser og levering
• Bygge et stærkere grundlag for vækst

Har I en Magento-webshop og planer om at gå fra NAV til Business Central? Læs mere om Magento og Business Central hos Connectify eller tag fat i os, hvis I vil have overblik over dataflow, faldgruber og næste skridt.

Hvilke data skal synkroniseres mellem Magento og Business Central?

Når Magento skal snakke med Business Central, er det fristende at sige: “Vi synkroniserer bare det hele.”

Men hov.

Det er ofte dér, en ellers god integrationsidé bliver unødigt kompliceret. Målet er ikke, at to systemer skal kunne præcis det samme på præcis samme tid. Målet er, at de rigtige data lander det rigtige sted, uden at nogen skal taste dem ind to gange.

En god Magento Business Central-integration gør det lettere at styre webshop, lager og økonomi. Men den kræver, at I først bliver enige om, hvilke data der er vigtigst, og hvilket system der ejer dem.

Se hvordan Connectify arbejder med Magento og Business Central-integrationer.

[Indsæt diagrammet her]

Start med at vælge, hvor data bor

Det vigtigste spørgsmål i projektet er ikke teknisk:

Hvilket system er sandhedskilden for de enkelte data?

For mange virksomheder er Business Central stedet, hvor varedata, lager, priser, debitorer og økonomi holdes samlet. Magento eller Adobe Commerce er derimod dér, kunden møder produkterne, handler og får sin oplevelse af virksomheden.

Det betyder ikke, at alt skal styres fra Business Central. Magento kan sagtens være stedet, hvor e-commerce-teamet arbejder med kampagner, kategorier, produkttekster og indhold.

Pointen er bare, at I skal træffe valget bevidst. Ellers kan to systemer hurtigt begynde at overskrive hinanden. Og så er der pludselig ikke meget automatisering tilbage i automatiseringen.

Microsoft beskriver selv Business Centrals integrationer som webservice- og API-baserede løsninger. Læs den tekniske oversigt hos Microsoft Learn, hvis I vil dykke længere ned.

Produkter og varianter

Produkter er ofte et af de første steder, hvor integrationen skal på arbejde.

Typisk skal varenummer, navn, stregkode, dimensioner, varianter og salgsenheder være tilgængelige i Business Central. På Magento-siden er der samtidig behov for billeder, beskrivelser, kategorier, SEO-tekster og relaterede produkter.

Afklar derfor blandt andet:

• Oprettes nye varer i Business Central, Magento eller et PIM-system?
• Hvilke felter må webshoppen redigere?
• Hvordan håndteres størrelse, farve og andre varianter?
• Hvad sker der, når en vare udgår?
• Skal alle varer vises i webshoppen, eller kun et bestemt sortiment?

Har I mange produkter eller flere markeder, kan et PIM-system være et godt næste skridt. Så kan hvert system fokusere på det, det er bedst til. Se Connectifys integrationsplatform for et overblik over de systemer, der kan indgå i arkitekturen.

Lagerstatus

Lagerdata er en af de ting, kunder hurtigt opdager, hvis den ikke spiller.

Ingen gider bestille en vare, som viser sig at være udsolgt. Og jeres kundeservice gider heller ikke bruge mandag morgen på at forklare, hvorfor lagerstatus ikke passer.

Integrationens lagerlogik bør tage højde for:

• Fysisk lager
• Reserveret lager
• Flere lagre eller butikker
• Varer på vej hjem
• Bundles og pakkeløsninger
• Eventuel lagerstyring hos en 3PL-partner

Lager behøver ikke at opdateres på samme måde som produkttekster. Et nyt produkt kan måske overføres med faste intervaller, mens lagerstatus skal opdateres langt oftere.

Det afhænger af jeres forretning. Sælger I få, dyre produkter, er behovet ét. Sælger I tusindvis af varer i døgnet, er behovet et helt andet.

Priser og kundespecifikke aftaler

Priser lyder simpelt. Det er de sjældent.

I B2C handler det ofte om almindelige salgspriser, kampagnepriser og forskellige valutaer. I B2B bliver det mere interessant med kundespecifikke priser, rabataftaler, mængderabatter og forskellige sortimenter.

Her skal integrationen kunne svare på:

• Hvilken pris skal kunden se?
• Hvilken kundegruppe tilhører kunden?
• Skal kampagnepriser komme fra Magento eller Business Central?
• Hvordan håndteres moms, valuta og afrunding?
• Hvad sker der, hvis en prisaftale ændres?

Det er sjældent prisen i sig selv, der skaber problemer. Det er reglerne bag den.

Læs også vores guide til Magento B2B og Business Central, hvis I arbejder med kundespecifikke priser og flere brugere pr. kunde.

Ordrer, kunder og leveringer

Når kunden har lagt en ordre, skal den selvfølgelig videre til Business Central. Men en ordre er mere end et ordrenummer.

En god ordreintegration tager som minimum højde for kundeoplysninger, leveringsadresse, ordrelinjer, rabatter, fragt, moms, betalingsstatus og eventuelle kommentarer.

Det samme gælder kunder. Skal en ny kunde i Magento automatisk oprettes som debitor i Business Central? Eller skal en B2B-kunde først godkendes og have tilknyttet en prisaftale?

Og integrationen slutter ikke, fordi ordren er landet i ERP-systemet. Kunden vil også gerne vide, om ordren er afsendt, hvilket trackingnummer den har, om noget er i restordre, og om en refundering er gennemført.

De lidt mere tekniske ting, der holder driften sund

Det skal helst ikke være nødvendigt at forstå integrationskode for at drive en webshop. Men der er nogle principper, der er værd at få på plads:

• En ordre må ikke oprettes to gange, hvis et system svarer langsomt.
• Fejlede overførsler skal kunne findes og genkøres.
• Datafelter skal dokumenteres, så alle ved, hvor informationen kommer fra.
• Der skal være overvågning af fejl, køer og manglende synkronisering.
• I bør kunne afstemme, om eksempelvis antal ordrer og lagerbeholdning faktisk matcher på tværs af systemerne.

Det lyder måske som små detaljer. Men det er dem, der afgør, om integrationen fungerer, når der er travlt.

Hvad skal synkroniseres i jeres setup?

Det korte svar er: Det, der gør jeres hverdag lettere og kundeoplevelsen bedre.

Før I starter, bør I få styr på:

1. Hvilke systemer I har i dag.
2. Hvilke data der er vigtigst for driften.
3. Hvilket system der ejer hvilke data.
4. Hvad der skal ske, når noget fejler.
5. Hvilke processer I vil automatisere først.

Når de ting er på plads, bliver integrationen ikke bare en teknisk øvelse. Den bliver et værktøj, der giver mindre manuelt arbejde, færre fejl og bedre mulighed for at vækste.

Har I Magento eller Adobe Commerce og Dynamics 365 Business Central? Læs mere om Connectifys Magento-integration eller tag fat i os til en afklaring af jeres dataflow.

Amazon SP-API integration til Business Central: Hvad sker der teknisk bag integrationen?

En Amazon-integration bliver ofte beskrevet meget enkelt:

“Vi forbinder Amazon med Business Central.”

Teknisk sker der væsentligt mere.

Amazon stiller sin Selling Partner API — SP-API — til rådighed som en REST-baseret API-platform til integration med Amazon selling partner-data. Amazon Developer Docs

Microsoft Dynamics 365 Business Central tilbyder samtidig standard REST API’er og mulighed for at udvikle egne API’er gennem AL. Microsoft Learn

Det er fundamentet.

Men en driftssikker integration kræver også arkitektur omkring det.

Orders API

Amazons Orders API bruges til at hente ordreinformation og kan danne grundlag for ordresynkronisering. Amazon Developer Docs

Integrationen skal derefter:

• hente relevante ordrer
• sikre, at samme ordre ikke behandles dobbelt
• mappe data
• validere SKU’er
• anvende Business Central-regler
• oprette de relevante ERP-data

Det er derfor integrationslaget, der omsætter Amazon-data til forretningslogik.

Listings Items API

Listings Items API giver adgang til at arbejde programmatisk med seller listings og oplysninger såsom salgsbetingelser, pris og inventory. Amazon Developer Docs

Det kan være relevant, hvis integrationen også skal arbejde med produkt- eller lagerdata.

Reports API

Reports API kan hente og administrere forskellige rapporttyper og bruges blandt andet til lager, ordrer, tax-data og returns. Amazon Developer Docs

Rapporter er især interessante, når virksomheden har brug for datamængder eller processer, der ikke kun handler om enkelte events.

Finances API

Finances API giver adgang til finansielle events for Amazonsælgerens forretning. Amazon Developer Docs

Det er relevant i forbindelse med:

• afstemning
• fees
• refunds
• økonomirapportering

Læs mere i [Afstemning af Amazon-salg i Business Central](/amazon-afstemning-business-central/).

Business Central på den anden side

Business Central har et sæt standard-API’er.

Hvis de relevante data ikke er eksponeret på den måde, integrationen kræver, kan der udvikles custom API pages i AL. Microsoft dokumenterer, at API page-typen er beregnet til versionerede REST web services og understøtter webhooks. Microsoft Learn

Det betyder, at integrationsprojektet nogle gange også indebærer arbejde i Business Central.

API-forbindelsen er kun én komponent

Et produktionsklart setup har typisk også behov for:

Queueing
Så midlertidige problemer ikke nødvendigvis stopper hele processen.

Retries
Så relevante fejl kan forsøges igen.

Logging
Så man kan se, hvad der faktisk skete.

Mapping
Så Amazon og Business Central forstår hinandens identifikatorer.

Validering
Så forkerte data ikke blindt bliver sendt videre.

Monitorering
Så fejl bliver opdaget.

Idempotency og dubletter

Hvis en proces fejler efter, at Business Central faktisk har oprettet ordren, må et retry ikke skabe en ordre nummer to.

Derfor er håndtering af unikke nøgler og processtatus en vigtig del af integrationsdesignet.

API-kald er én ting.

Pålidelig databehandling er noget andet.

API-versioner ændrer sig

Amazon vedligeholder både release notes og en deprecation schedule for SP-API. Amazon Developer Docs

Det er en vigtig pointe for virksomheder:

Integrationer er ikke engangsinstallationer.

De er software, der skal vedligeholdes.

Det vigtigste at tage med

En Amazon SP-API integration til Business Central er ikke kun:

API A kalder API B.

Den består af både:

Amazon API
Business Central API
mapping
forretningsregler
fejlhåndtering
monitorering
sikkerhed
vedligeholdelse

Det er kombinationen, der afgør, om integrationen fungerer stabilt efter go-live.

Har I en teknisk Amazon-integration, der skal passe til jeres Business Central-arkitektur?

Tal med Connectify om Amazon integration

Amazon connector til Business Central: Skal du vælge standard eller fleksibel integration?

Hvis du søger efter en Amazon connector til Business Central, er det fristende at stille ét spørgsmål:

“Hvilken connector kan forbinde de to systemer?”

Et bedre spørgsmål er:

“Hvilke processer skal forbindelsen faktisk kunne håndtere?”

For en standardconnector kan være den helt rigtige løsning.

Men den kan også være den forkerte, hvis virksomhedens setup ligger langt fra standarden.

Hvornår giver en standardconnector mening?

Et simpelt setup kan eksempelvis være:

Ét Amazon-marketplace.

Ens SKU’er.

Business Central som centralt ERP.

En simpel lagerstruktur.

Et klart ordreflow.

Her kan standardfunktionalitet give mening, fordi virksomheden får en hurtigere og mere forudsigelig implementering.

Hvornår begynder standarden at stramme?

Kompleksiteten vokser typisk, hvis virksomheden har:

• både FBA og FBM
• flere marketplaces
• WMS
• 3PL
• flere lagerlokationer
• bundles og produktmapping
• særlige Business Central-felter
• specifikke bogføringsregler
• egne fejl- og godkendelsesflows

Så bliver spørgsmålet, om connectoren kan tilpasses forretningen, eller om forretningen skal tilpasses connectoren.

Kig længere end feature-listen

En connector kan måske annoncere:

“Order sync”.

Men hvad betyder det?

Kan den håndtere jeres customer setup?

Dimensioner?

FBA/FBM?

Annulleringer?

Ukendte SKU’er?

Dubletter?

Det er detaljerne, der afgør, om integrationen fungerer i den daglige drift.

Overvågning er en funktion

En af de mest undervurderede funktioner i integrationer er muligheden for at se, når noget ikke virker.

En ordre, der aldrig kommer ind, er langt værre end en ordre, der fejler synligt.

Derfor bør I vurdere:

Hvordan logges fejl?

Kan data genbehandles?

Hvem får besked?

Kan man se historikken?

Hvad sker der, når Amazon eller Business Central ændrer sig?

Amazon SP-API har løbende release notes og ændringer, og Microsoft vedligeholder tilsvarende Business Central API’er. Amazon Developer Docs

Derfor bør connectorens vedligeholdelsesmodel være en del af beslutningen.

Hvem ejer opgraderingerne?

Hvordan testes ændringer?

Hvad sker der med custom logik?

Totalomkostning er mere end licensen

En billig connector er ikke nødvendigvis billig, hvis medarbejderne stadig:

• retter ordrer manuelt
• afstemmer med Excel
• overvåger lager selv
• løser fejl hver uge

Omvendt skal man heller ikke bygge en kompleks specialløsning til et problem, som standardsoftware allerede løser godt.

Hvornår passer en integrationsplatform bedre?

Hvis Amazon kun er ét system blandt mange, kan det være mere relevant at tænke i en samlet integrationsarkitektur.

Amazon → Business Central
Webshop → Business Central
WMS → Business Central
3PL → Business Central

I stedet for at have en separat integrationsmekanisme for hver forbindelse kan virksomheden samle logik og overvågning.

Læs mere om Connectifys Integrationsplatform. Connectify beskriver selv platformen som en måde at samle integrationer og datastrømme på tværs af ERP, e-commerce, PIM og andre systemer.

Den bedste connector er den, der passer til kompleksiteten

Standard er ikke dårligt.

Custom er ikke automatisk bedre.

Det relevante er fit.

Hvis 90 % af behovet er standard, bør man være forsigtig med at bygge 100 % special.

Hvis kun 40 % passer til standardconnectoren, kan den til gengæld blive dyr gennem manuelle workarounds.

Er I i tvivl om en standardconnector er nok?

Få vurderet jeres Amazon- og Business Central-setup

Vi kan gennemgå de konkrete flows, før I vælger integrationsmodel.

Amazon SKU, ASIN og Business Central-varenumre: Den mapping der afgør, om integrationen virker

En Amazon-ordre siger:

SKU: DK-BLUE-XL-2

Business Central siger:

Varenr.: 105433

Er det samme produkt?

For et menneske med produktkendskab er svaret måske indlysende.

For en integration er svaret nej, indtil relationen er defineret.

Det er grunden til, at SKU-mapping mellem Amazon og Business Central er en af de vigtigste dele af en Amazon-integration.

ASIN og seller SKU har forskellige roller

Amazon arbejder blandt andet med Amazon-kataloget og sælgerens egne listings.

Seller SKU’en bruges til at identificere sælgerens listing, mens ASIN identificerer et produkt i Amazons katalog.

Business Central har samtidig virksomhedens egne varenumre.

Derfor bør en integration ikke antage, at én identifikator automatisk kan erstatte en anden.

Amazon Listings Items API giver programmatisk adgang til seller listings og SKU-relaterede listing-oplysninger. Amazon Developer Docs

Hvorfor bruger virksomheder forskellige SKU’er?

Der kan være gode forretningsmæssige grunde.

En vare kan eksempelvis sælges som:

• én enhed i Business Central
• en 2-pack på Amazon
• en 6-pack på et andet marketplace

Så er relationen ikke 1:1.

Det samme gælder bundles.

Amazon-SKU:

STARTER-KIT-01

kan eksempelvis bestå af tre separate Business Central-varenumre.

Integrationens opgave bliver derfor mere end mapping.

Den skal forstå produktlogikken.

Varianter gør det endnu vigtigere

Farve og størrelse er klassiske eksempler.

Business Central kan have ét bestemt variantsetup, mens Amazon-listingen er struktureret anderledes.

Derfor bør mappingen dokumenteres og administreres systematisk.

Ikke i hovedet på én medarbejder.

Ikke i et Excel-ark, som ingen tør ændre.

Men som en defineret del af datamodellen.

Hvilket system er master?

Et af de første spørgsmål bør være:

Hvor bliver produktidentiteten skabt?

Business Central?

PIM?

Amazon?

Et andet masterdata-system?

Amazon tilbyder også Product Type Definitions API til at hente de aktuelle data- og attributkrav for produkttyper i Amazons katalog. Amazon Developer Docs

Det understreger, at produktdata på Amazon kan have sin egen struktur og egne krav, som ikke nødvendigvis matcher ERP’et direkte.

Hvad sker der ved forkert mapping?

Konsekvenserne kan være alvorlige.

En forkert mapping kan medføre:

• forkert vare på salgsordren
• forkert lagernedskrivning
• forkert kostpris
• forkert genopfyldning
• forkert rapportering

Derfor bør ukendte SKU’er ikke bare falde tilbage til en tilfældig vare.

Integrationen bør stoppe, logge og gøre problemet synligt.

Mapping skal kunne vedligeholdes

Nye produkter bliver lanceret.

Gamle udgår.

Amazon-SKU’er ændres.

Nye marketplaces kommer til.

Derfor er mapping ikke et engangsprojekt.

Det er en vedligeholdelsesproces.

En stærk integration gør det tydeligt:

• hvilke SKU’er der er mappet
• hvilke der mangler
• hvad de matcher
• hvornår mappingen sidst er ændret

Sammenhæng med ordre og lager

SKU-mapping er fundamentet under både.

Hvis produktnøglen er forkert, bliver alt downstream-data forkert.

Derfor bør produktmapping være en af de første ting, der gennemgås i et Amazon-projekt.

Det vigtigste at tage med

Integration handler meget om API’er.

Men nogle gange er den vigtigste opgave så banal som:

“Er vi enige om, hvilken vare vi taler om?”

Hvis svaret ikke er entydigt på tværs af Amazon og Business Central, bør det løses før resten af integrationen.

Få gennemgået jeres Amazon- og Business Central-produktmapping

Amazon-returvarer og refunds i Business Central: Når salget går den anden vej

Integrationer bliver ofte designet omkring den glade sti:

Ordre → lager → levering → betaling.

Men e-commerce stopper ikke ved leveringen.

Nogle varer kommer retur. Nogle kunder får refunds. Nogle varer kan sælges igen. Andre kan ikke.

Derfor bør Amazon-returvarer og refunds i Business Central være en del af integrationsdesignet fra starten.

Amazons Reports API kan blandt andet bruges til rapportdata om returns, lager og ordrer, mens Amazon også har separate processer for seller-fulfilled returns. Amazon Developer Docs

Returneret og refunderet er ikke det samme

Det er vigtigt at skelne mellem to hændelser.

Refund: Den økonomiske hændelse.

Return: Den fysiske varebevægelse.

De kan hænge sammen, men de bør ikke behandles som den samme datatype.

En kunde kan eksempelvis få en refund, før den fysiske vare er modtaget.

Derfor bør økonomi og lager ikke blindt opdateres efter samme event.

Ved FBA håndterer Amazon meget af den fysiske proces

Ved FBA overtager Amazon en stor del af fulfillment- og returhåndteringen.

Det betyder ikke, at virksomheden kan ignorere returdata.

Business Central kan stadig have behov for at vide:

• hvilken oprindelig ordre returneringen vedrører
• hvilken SKU der er involveret
• hvilket beløb der er refunderet
• hvordan lagerstatus påvirkes
• om varen igen kan indgå i beholdningen
• hvordan den finansielle hændelse skal håndteres

Læs mere om [Amazon FBA integration til Business Central](/amazon-fba-integration-business-central/).

Ved FBM bliver virksomhedens eget lager en del af processen

Ved FBM modtager virksomheden eller dens 3PL ofte varen fysisk.

Så opstår der et nyt spørgsmål:

Hvad er varens tilstand?

En returneret vare kan være:

• salgbar
• beskadiget
• mangelfuld
• til inspektion
• til kassation

Det er ikke nødvendigvis korrekt straks at lægge den tilbage i disponibelt lager.

Læs også [Amazon FBM integration til Business Central](/amazon-fbm-integration-business-central/).

Returårsager er værdifulde data

Hvis en bestemt SKU har markant flere returneringer end andre, er det ikke kun et kundeserviceproblem.

Det kan pege på:

• produktkvalitet
• forkert produktbeskrivelse
• størrelsesproblemer
• emballage
• transportskader

Når returdata bliver struktureret og koblet til produkt- og salgsdata, kan virksomheden bruge dem aktivt.

Returflowet bør defineres

Et eksempel på et FBM-flow:

Amazon return request → Business Central → lager/3PL → fysisk kontrol → lagerstatus → refund/kredit → rapportering

Et FBA-flow kan have en anden fysisk proces, men Business Central har stadig brug for de relevante ERP- og økonomidata.

Undgå at bygge returns som en eftertanke

Det er meget nemmere at designe returhåndtering sammen med ordreflowet end at tilføje den efterfølgende.

Fra starten bør I definere:

Hvilken nøgle forbinder returneringen med den oprindelige ordre?

Hvornår ændres lagerstatus?

Hvornår sker økonomisk postering?

Hvordan håndteres delvise refunds?

Hvordan håndteres varer, der ikke kan sælges igen?

Det vigtigste at tage med

Et godt Amazon-flow går ikke kun fra Business Central til kunden.

Det skal også kunne håndtere data, der bevæger sig tilbage.

Når returns og refunds er en integreret del af systemarkitekturen, slipper lager, kundeservice og økonomi for hver især at opfinde deres egen manuelle proces.

Få vurderet jeres Amazon-returflow

Amazon FBA lager i Business Central: Fra eget lager til Amazons fulfillment-netværk

Når varer sendes til Amazon FBA, forsvinder de ikke ud af virksomhedens supply chain.

De skifter bare placering og ansvar.

Det gør FBA-lager i Business Central til et interessant område, fordi ERP-systemet stadig skal kunne give virksomheden et brugbart billede af beholdning, lagerbinding og behovet for genopfyldning.

Amazon FBA betyder, at Amazon håndterer blandt andet lager, pluk, pak, forsendelse, kundeservice og returhåndtering for de relevante FBA-ordrer. Sell on Amazon

Men Business Central skal stadig understøtte virksomhedens eget overblik.

FBA som separat lagerlokation

En oplagt model kan være at repræsentere FBA-beholdningen som en særskilt lokation eller lagerlogik i Business Central.

Eksempelvis:

EGET LAGER
AMAZON FBA DE
AMAZON FBA SE

Det er ikke nødvendigvis den rigtige model for alle virksomheder, men princippet er vigtigt:

Man skal kunne se forskel på en vare, der står på eget lager, og en vare, der befinder sig i Amazons fulfillment-netværk.

Varer på vej til Amazon

En af de interessante faser er tiden mellem:

“varen forlader vores lager”

og

“Amazon har modtaget og registreret varen”.

Hvis virksomheden blot trækker varen fra eget lager og øjeblikkeligt lægger den på FBA-lager, kan systemet vise et billede, der ikke svarer til virkeligheden.

Derfor kan det være relevant at arbejde med en transit- eller inbound-status.

Det giver mulighed for at skelne mellem:

• varer på eget lager
• varer sendt
• varer under transport
• varer modtaget af Amazon
• varer tilgængelige til salg

Genopfyldning bør ikke baseres på mavefornemmelse

Når FBA-lageret bliver lavt, skal virksomheden beslutte, hvor meget der skal sendes ind.

For lidt lager kan føre til mistede salg.

For meget lager binder kapital og kan medføre yderligere lagerrelaterede omkostninger. Amazon arbejder blandt andet med månedlige storage costs og potentielle omkostninger for ældre lagerbeholdning. Sell on Amazon

Et bedre beslutningsgrundlag kan tage højde for:

• salgshistorik
• nuværende FBA-beholdning
• varer på vej
• lead time
• sæson
• forecast
• lageromkostning

Hvad gør man, når tallene ikke stemmer?

Der vil kunne opstå forskelle mellem virksomhedens forventede FBA-lager og Amazons registrerede data.

Det interessante er derfor ikke kun synkronisering.

Det er også reconciliation af lagerdata.

Hvis Business Central forventer 300 varer hos Amazon, men Amazon viser 294, skal virksomheden kunne identificere afvigelsen og afgøre, hvordan den skal håndteres.

Ét FBA-lager eller flere?

Hvis virksomheden opererer på flere markeder, bør lagerstrukturen gennemtænkes.

Behøver virksomheden et detaljeret landebaseret ERP-overblik?

Eller er en mere samlet model tilstrækkelig?

Svaret afhænger af jeres fulfillment-setup, rapporteringsbehov og regnskabsmodel.

Derfor bør lagerstrukturen ikke designes ud fra “sådan gør andre”, men ud fra de spørgsmål, I faktisk skal kunne besvare i Business Central.

FBA-lager og økonomi hænger sammen

Lager er ikke bare antal.

Det er kapital.

Hvis varer ligger for længe hos Amazon, påvirker det både cashflow og potentielle lageromkostninger.

Derfor er FBA-lagerdata relevante for både supply chain og økonomi.

Se også [Hvad koster Amazon FBA reelt?](/amazon-fba-omkostninger-business-central/).

Det nye perspektiv

Den største fejl er at betragte Amazon FBA som et sort hul:

“Vi sender varerne til Amazon, og så klarer de resten.”

Amazon klarer fulfillment.

Men virksomheden har stadig brug for styring.

Business Central bør derfor kunne hjælpe med at svare på:

Hvor er vores varer?

Hvor meget kan sælges?

Hvad er på vej?

Hvornår skal vi genopfylde?

Hvor meget kapital har vi bundet hos Amazon?

Det er dér, integrationen bliver interessant.

Få gennemgået jeres FBA-lagerflow mellem Amazon og Business Central

Læs også: Amazon FBA integration til Business Central

Afstem Amazon salg direkte i Business Central

Amazon har solgt varer for 100.000 kr.

Derfor forventer økonomiafdelingen ikke nødvendigvis en bankoverførsel på 100.000 kr.

Mellem salget og udbetalingen kan der blandt andet ligge fees, refunds, andre finansielle hændelser og forskellige transaktioner.

Det er netop derfor, Amazon-afstemning i Business Central hurtigt kan udvikle sig til en tidskrævende proces.

Amazon stiller finansielle informationer til rådighed gennem sin Finances API, hvor finansielle events blandt andet kan hentes for ordrer eller tidsperioder. Amazon Developer Docs

Men ligesom med ordreintegrationen er adgang til data ikke i sig selv løsningen.

Dataene skal kunne bruges økonomisk.

Salg og udbetaling er to forskellige ting

En Amazon-ordre fortæller, hvad kunden har købt.

En Amazon-udbetaling fortæller, hvad Amazon faktisk udbetaler.

De to størrelser skal forbindes.

Hvis økonomiafdelingen kun bogfører bankbeløbet, kan det blive svært at få indblik i:

• bruttoomsætning
• Amazon-gebyrer
• refunds
• fulfillment-omkostninger
• forskelle og justeringer

Derfor bør Amazon-flowet designes med afstemning for øje fra begyndelsen.

Skal hver Amazon-ordre bogføres individuelt?

Ikke nødvendigvis.

Nogle virksomheder ønsker fuld ordredetalje i Business Central.

Andre har behov for en mere aggregeret finansiel model.

Det rigtige valg afhænger blandt andet af:

• rapporteringsbehov
• antal transaktioner
• moms- og regnskabssetup
• behov for ordresporbarhed
• hvordan bankudbetalinger skal udlignes

Det er derfor vigtigt at involvere økonomiafdelingen, før integrationen bestemmes.

Refunds gør afstemningen mere interessant

En refund kan betyde, at et tidligere salg helt eller delvist bliver tilbageført.

Samtidig kan der være en fysisk returvare, men det behøver ikke altid være samme proces.

Derfor er det vigtigt at skelne mellem:

økonomisk hændelse og fysisk varebevægelse.

Det er også grunden til, at vi anbefaler en separat proces for [Amazon-returvarer og refunds i Business Central](/amazon-returvarer-business-central/).

FBA tilføjer flere omkostningstyper

Ved FBA kan der indgå fulfillment- og lagerrelaterede omkostninger ud over standard Amazon selling fees. Amazon beskriver blandt andet fulfillment costs, storage costs og andre potentielle FBA-omkostninger såsom aged inventory, returns processing og inbound placement. Sell on Amazon

Det gør det endnu vigtigere at kunne koble Amazon-data sammen med kostpriser og produktdata i ERP-systemet.

Læs også: Amazon FBA integration til Business Central

Sådan bør afstemningsflowet tænkes

Et robust setup bør kunne besvare tre spørgsmål:

Hvad solgte vi?

Hvilke omkostninger og justeringer blev knyttet til salget?

Hvad modtog vi faktisk på bankkontoen?

Når de tre dele kan forbindes, bliver Amazon væsentligt nemmere at kontrollere økonomisk.

Automatisering bør ikke fjerne kontrollen

Målet med integration er ikke, at økonomiafdelingen aldrig ser tallene.

Målet er, at de ikke skal bruge tiden på at samle dem manuelt.

Afvigelser bør stadig kunne ses og undersøges.

Automatiseringen skal gøre undtagelserne tydelige, ikke skjule dem.

Fra Excel-proces til kontrolleret dataflow

En klassisk manuel proces kan indebære eksport af rapporter, pivottabeller, bankkontrol og manuelle posteringer.

Et integreret setup kan i stedet hente de relevante data, kategorisere dem og gøre dem tilgængelige for den valgte bogførings- og afstemningsmodel.

Connectifys eksisterende Amazon side beskriver allerede settlement- og betalingsflow som en del af integrationen mellem Amazon og Business Central.

Denne artikel skal derfor være jeres dybe økonomi-side, mens landingssiden kun introducerer emnet.

Det vigtigste at tage med

Hvis Amazon fylder mere i omsætningen, bør Amazon-afstemning ikke være en personafhængig Excel-proces.

Det bør være et defineret dataflow.

Det giver bedre mulighed for kontrol, skalering og forståelse af, hvad Amazon-forretningen reelt tjener.

Bruger økonomi for meget tid på Amazon settlements, fees og refunds?

Få gennemgået jeres Amazon-afstemningsflow

Amazon lagerintegration til Business Central: Hvilket lager må Amazon egentlig sælge?

At sende lagerstatus fra Business Central til Amazon lyder simpelt.

Business Central siger 100.

Amazon får 100.

Færdig.

I praksis er det sjældent så enkelt.

For betyder “100 på lager” faktisk, at Amazon må sælge 100?

Måske er 20 allerede reserveret. Måske vil I holde 10 enheder tilbage til andre salgskanaler. Måske ligger 40 på en lokation, som ikke kan bruges til Amazon-ordrer.

Det vigtigste spørgsmål i en Amazon lagerintegration er derfor ikke, hvordan man sender et antal.

Det er, hvordan det korrekte antal beregnes.

Fysisk lager og disponibelt lager er ikke det samme

Forestil dig denne situation:

Fysisk lager: 100
Reserveret til eksisterende ordrer: 25
Sikkerhedslager: 10

Så bør Amazon måske kun få 65.

Har virksomheden også flere lagerlokationer, kan beregningen blive endnu mere kompleks.

Det er derfor vigtigt at definere en klar lagerregel, før integrationen bygges.

Hvilket system ejer lageret?

For nogle virksomheder er Business Central det naturlige lagermaster-system.

For andre er det WMS.

Hvis virksomhedens WMS har det mest præcise billede af varer, reservationer og pluk, kan det være nødvendigt at bruge lagerdata derfra.

Connectify arbejder allerede med supply-chain- og WMS-relaterede integrationer, hvor formålet blandt andet er at automatisere lagerbevægelser og ordreudførelse. Connectify

Det centrale er at undgå to systemer, der begge mener, de bestemmer sandheden.

Lager ved FBM

Ved FBM håndterer virksomheden selv fulfillment.

Derfor bliver lagerstatus kritisk.

Amazon beskriver selv lager- og ordresynkronisering som en del af FBM-værktøjerne. Sell on Amazon

Hvis Amazon fortsætter med at vise fem enheder, efter de fem sidste er blevet solgt gennem en anden kanal, risikerer virksomheden at modtage en ordre, den ikke kan levere.

Det er netop den situation, lagerintegration skal reducere.

Læs også [Amazon FBM integration til Business Central](/amazon-fbm-integration-business-central/).

Lager ved FBA

Ved FBA ligger en del af lageret fysisk hos Amazon.

Derfor skal virksomheden kunne skelne mellem eksempelvis:

• eget lager
• varer på vej til Amazon
• varer modtaget af Amazon
• FBA-lager
• varer reserveret eller utilgængelige

Det kræver en anden lagerlogik end FBM.

Vi går dybere ned i dette i [Amazon FBA-lager i Business Central](/amazon-fba-lager-business-central/).

Flere salgskanaler gør problemet større

Forestil dig, at samme SKU bliver solgt via Amazon og egen webshop.

Begge kanaler viser 10 på lager.

En kunde køber otte på webshoppen.

Hvis Amazon først bliver opdateret flere timer senere, kan en anden kunde nå at købe fem dér.

Nu har virksomheden solgt 13 varer, men kun haft 10.

Det er ikke nødvendigvis Amazons eller webshoppens fejl.

Det er et spørgsmål om lagerarkitektur.

Hvor ofte skal lager opdateres?

Der findes ikke ét rigtigt svar.

Nogle virksomheder kan arbejde med periodiske opdateringer. Andre har behov for hyppigere synkronisering.

Det afhænger blandt andet af:

• ordrevolumen
• lagerbeholdning
• antal salgskanaler
• produkternes omsætningshastighed
• risikoen ved overselling

Amazon har både API’er og rapporter, der kan bruges til lagerrelaterede processer, herunder inventory reports og listing-data med pris og lager. Amazon Developer Docs

Et godt Amazon-lagerflow starter med forretningsregler

Før den tekniske integration bygges, bør virksomheden kunne svare på:

Hvilke lagre må Amazon sælge fra?

Skal Amazon have adgang til hele den disponible beholdning?

Skal der være sikkerhedslager?

Hvordan håndteres reservationer?

Hvad sker der, hvis lagerdata mellem WMS og Business Central er uenige?

Først når disse spørgsmål er besvaret, giver det mening at bygge integrationen.

Det vigtigste at tage med

En Amazon lagerintegration handler ikke om at sende et tal fra system A til system B.

Den handler om at sikre, at Amazon får det rigtige tal.

Det kan være forskellen mellem en velfungerende multichannel-forretning og et lagerteam, der konstant skal forklare, hvorfor der er solgt varer, som ikke findes.

Få vurderet jeres lagerflow mellem Amazon og Business Central

Relevante interne links: Business Central integration  Supply Chain integration  Integrationsplatform