ved hjelp av APPS
GLOBAL
VIRKSOMHET

Business Central ekspert
Dette er #6 av 8 artikler om hvordan du kan dekke hele virksomheten din med BUSINESS CENTRAL
– uten kundeutvidelser
– bruker bare APPS
Oppfyll alle dine behov for å administrere GLOBAL BUSINESS i BUSINESS CENTRAL.
I denne artikkelen forklarer vi hva du bør kreve, hvordan du unngår tilpasninger, og hvilke APPS du bør bruke.
Når vi administrerer flere selskaper med Business Central, oppstår det noen ekstra behov. Dette skyldes ofte at vi har selskaper i flere land, men det kan også rett og slett være flere selskaper i samme land.
Bedriftene har typisk ulike roller i forsyningskjeden, for eksempel logistikkselskaper, produksjonsselskaper og salgsselskaper med en rekke prosesser mellom seg.
Intercompany
Vi har et salgsselskap som har salgsordrer fordi de mottar bestillinger fra sluttkunder. Salgsselskapet gir prognoser til hovedkontoret, som planlegger produktbehovet, og de bruker lageret/logistikkfirmaet til å levere, eller fra et tredjeparts logistikkfirma, og noen ordrer kan logistikkfirmaet levere direkte til sluttkunden.
Hovedkontoret kjøper også inn varer fra produksjonsselskapet, som benytter seg av en rekke eksterne leverandører, produserer varene og leverer dem i en container til logistikk-/lagerselskapet.

Det er bare et eksempel. Uansett hvilken selskapsstruktur vi har, må vi kunne håndtere den i Business Central, og prosessene må støttes slik at vi slipper å håndtere alle data og regnskap manuelt.
Som standard kan Business Central håndtere konserninterne transaksjoner godt, spesielt med oktober 2023-versjonen, men vi trenger raskt mer struktur og automatisering slik at vi kan bokføre automatisk i flere selskaper samtidig.
Når salgsselskapet oppretter en innkjøpsordre, må det automatisk opprettes en salgsordre i det selskapet som skal levere – og så videre gjennom selskapsstrukturen. Vi ønsker også å kunne se lagerbeholdningen i andre selskaper, slik at vi allerede når vi tar imot ordren fra kunden, kan se om varen finnes på lager i et annet selskap.
» Intercompany transaksjoner

Vi må også håndtere prissettingen mellom selskapene. Det er også en utfordring hvis vi har ulike valutakurser i ulike selskaper.
Vi må bruke samme kilde for priser og valutakurser slik at elimineringer blir enklere, og slik at vi får de samme verdiene på de samme postene i konsernregnskapet.

Global forvaltning av masterdata
Master Data Management er et viktig tema i et konsern med mange selskaper (juridiske enheter). Vi må ha en global struktur for masterdata og kunne synkronisere masterdata mellom selskapene, og vi må inkludere masterdata på dokumentene som brukes på salgs-, innkjøps- og overføringsordrer mellom alle selskapene. Vi går i dybden med masterdata i et eget kapittel.
Kanskje har vi fem forskjellige selskaper som i praksis vil ha de samme kundene, varene, masterdataene osv. Når vi oppretter en ny vare på hovedkontoret, ønsker vi at den skal replikeres til de andre selskapene, slik at vi ikke trenger å opprette den flere ganger – og vedlikeholde den i flere selskaper. Vi trenger masterdata organisert i et master- og abonnenthierarki.

Beholdere
Containere er et viktig tema hvis vi sender varer over lange avstander, både hvis vi sender eller mottar varer i containere.
Som innkjøper kan det være at vi har en container stående hos leverandøren, som vi etter hvert fyller med innkjøpsordrer, og når den er full nok, får vi den sendt til oss. Da vil vi gjerne administrere alle innkjøpsordrene i containeren samlet. Hvis containeren blir forsinket med 4 dager underveis, vil vi gjerne oppdatere alle innkjøpslinjene samtidig og finne konfliktene det skaper.
På samme måte er det vi som selger containeren, og det er vi som sender den, og vi ønsker å planlegge kapasiteten på containeren best mulig før vi sender den av gårde.


Sortimenter
Det er ofte forskjell på hvilke varer og varianter som kan kjøpes og selges i ulike selskaper.
I lagerselskapet har vi 8 farger av en vare, og ett salgsselskap må kjøpe alle 8, mens et annet bare kan kjøpe 2 av fargene fordi de bare markedsfører de 2 fargene.
I nettbutikken må det også være alle 8 fargene for kunder i det første landet, men bare 2 for kunder i det andre landet. Og hovedkontoret har bestemt at en av fargene skal utgå, og derfor må bare 7 av fargene etterbestilles fra leverandøren.
Den internasjonale strukturen må kunne håndtere alt dette på Business Central.
Pakker og etiketter
Når du tilbyr varer til mange land, blir emballasje og etiketter en spesiell utfordring. En ingrediensetikett kan inneholde tre språk: Engelsk, spansk og portugisisk, og dette avgjør i hvilke land produktet kan selges.
Vi har den samme varen på lager med andre språkkombinasjoner, f.eks. engelsk, italiensk og gresk. Det kan være at vi har 1000 av varen på lager og kan levere alle 1000 til engelskspråklige land, men vi kan bare levere 80 til Italia fordi de resterende 920 ikke har italiensk språk på ingrediensetiketten.
Mange varianter av pakker og etiketter er en ekstra utfordring på Business Central.
Rapportering og oppfølging
Rapportering handler om Business Intelligence. I et globalt oppsett vil vi gjerne kunne rapportere på tvers av hele selskapsstrukturen. Hva selger vi i hvilke deler av verden? Hvor lange er leveringstidene våre?
Hvis Business Intelligence viser at leveringstiden for en vare i realiteten er tre måneder, men masterdataene på varen i ERP sier to måneder, bør vi korrigere masterdataene slik at vi ikke lover kundene noe vi ikke kan innfri.

Konsolidering
Finansiell konsolidering er et annet tema som ofte håndteres med et rapporteringsverktøy.
Vi ønsker å kunne analysere enhetene i selskapsstrukturen på en sammenlignbar måte. Det er ikke noe poeng i å måtte kartlegge data fra bunnen av hver gang for å få sammenlignbare tall. Vi må kunne administrere strukturen sentralt for hele konsernet.
Typisk utarbeider vi en konsernkonto, hvor vi konsoliderer alle data fra underliggende selskaper opp til konsernkontoen og eliminerer transaksjonen. Med mindre alle selskapene bruker Business Central, er det smart å gjennomføre konsolideringen med en Business Intelligence -løsning, men det krever at vi har harmoniserte kontoplaner og dimensjonskoder i alle selskapene.

KONSERNINTERNE TRANSAKSJONER
Hvis selskapet vårt opererer internasjonalt – eller hvis vi har mange selskaper i ERP-systemet vårt som må integreres – er “intercompany” et viktig tema.
I et salgsselskap oppretter vi en salgsordre for en kunde. Når vi frigir den, må det opprettes en innkjøpsordre for å kjøpe varen fra et annet selskap i konsernet, og det må (automatisk) opprettes en salgsordre i vårt konserns produksjons- eller lagerselskap.
Nå har vi tre ordredokumenter som er koblet sammen på tvers av to selskaper, og vi må kunne administrere dem sammen og endre dem som ett.
Endringsledelse
Håndtering av endringer er den vanskelige delen. I produksjonsselskapet må vi kunne endre mengder eller priser, og få endringen til å forplante seg til både innkjøpsordren og salgsordren i salgsselskapet.
Vi må kunne gjøre en endring i hvilken som helst av de tre postene, og endringen bør gjenspeiles i de andre. Det nytter ikke om løsningen vår er for fastlåst til å støtte den verden vi lever i.
Det er flere områder der vi trenger fleksibilitet i det daglige.
Én salgsordre
Salgsselskapet vårt har behov for å kunne opprette en salgsordre som inneholder linjer fra flere selskaper, f.eks. to varer fra det lokale salgsselskapet selv, fire varer fra lagerselskapet i Tyskland og tre varer som skal produseres av selskapet i Polen.
Direkte forsendelse
Vi må kunne angi om det er en direkte forsendelse – det vil si om alle selskapene skal sende varene direkte til sluttkunden – eller om de tyske og polske selskapene skal sende varene til vårt lokale salgsselskap, som deretter sender dem til kunden.
Dette er faktisk et av de vanskeligste aspektene ved konserninterne transaksjoner. Hvis de tyske og polske selskapene sender direkte til kunden, må de kunne legge ved en fraktseddel eller faktura som er skrevet ut i henhold til logikken til det opprinnelige lokale salgsselskapet, som tross alt er det kunden har handlet med. Dette blir komplisert når ulike selskaper og regnskapsenheter er involvert.
Når det lokale selskapet selger til en lokal kunde med lokale priser og lokale rabatter, må dokumentene kunne komme ut av printeren i Tyskland og Polen.
Vareoppfølging
Vi ønsker også å kunne spore varer på tvers av selskaper.
Når lagerarbeideren i Tyskland plukker varer med serienummer, må han skanne serienummeret, og deretter må det flyte hele veien til vårt lokale salgsselskap, slik at vi lokalt kan se hvilke serienumre som er plukket til ordren.
Konfigurasjon
Med varekonfigurasjon må dataene flyte den andre veien. Vi registrerer spesifikasjonene for den konfigurerte varen, og kanskje også det faktum at det skal trykkes en firmalogo på lokket, på den lokale salgsordren. Disse opplysningene må deretter flyte til det polske produksjonsselskapet, som skal produsere varene og trykke logoen på lokket.
Feilhåndtering
Til slutt, hvordan håndterer intercompany-løsningen feil? Hvis noe går galt mellom selskapene (f.eks. hvis varenummeret ikke finnes i det andre selskapet), havner ordren da i en feillogg som noen må følge opp før ordren kan gå videre?
Vi anbefaler absolutt at løsningen er nettbasert, og at feil returneres til brukeren i sanntid. Det betyr at hvis vi i vårt lokale salgsselskap legger inn en ordre som skal ta ut varer fra de tyske og polske selskapene, vil vi se eventuelle feil på skjermen med en gang vi skriver, slik at vi ikke kan komme videre i prosessen før feilen er håndtert.
Vi merker en tydelig økning i etterspørselen etter konserninterne løsninger. Det blir mer og mer vanlig at transaksjoner går på tvers av landegrenser og selskaper.
Det grunnleggende er rimelig enkelt, men fleksibilitet i de daglige utfordringene er det som virkelig kjennetegner en god intercompany-løsning.

GLOBAL SYNKRONISERING
Vi kan ha fem forskjellige selskaper (juridiske enheter) som i praksis vil ha de samme kundene, varene, masterdataene osv. Når vi oppretter en ny vare på hovedkontoret, ønsker vi at den skal replikeres til de andre selskapene, slik at vi ikke trenger å sette den opp flere ganger.
Vi kan også ha et annet ERP-system i et av datterselskapene. Vi trenger at masterdata synkroniseres på tvers av alle plattformer, Business Central samt andre ERP-systemer i konsernet. Dette gjelder også for masterdata som vi har opprettet selv, f.eks. farge, størrelse, materiale eller mange andre typer masterdata om varer, kunder og leverandører.

Utfordringen er å få de ulike ERP-systemene, med ulike datastrukturer, til å snakke sammen. Når vi utvikler en datastruktur, må vi tenke nøye gjennom at nøklene skal samsvare i alle selskapene – på tvers av de ulike ERP-systemene.
Strategier for datasynkronisering
Det finnes ulike strategier vi kan velge.
En sentralisert strategi betyr at vi har et hovedselskap der vi setter opp alle masterdata i en konsolidert form, og samler alle debitorer, alle varer og alt annet vi ønsker å administrere av det sentrale teamet. Systemet “skyver” data ut fra hovedselskapet til de perifere selskapene.
Sentral styring har visse fordeler, men ulempen er at det blir vanskeligere å vedlikeholde data når færre medarbeidere har tilgang.
Kanskje er det en lokal bruker i Frankrike som oppdager at en bestemt opplysning om en vare er feil, men han får det ikke rettet fordi det er for mye bry med å rapportere det til hovedkontoret. Hvis han korrigerer sine lokale data, vil de bare bli overskrevet av hovedkontorets data når neste synkroniseringsjobb kjøres.
Vi heller derfor mot en hybridstrategi der data kan synkroniseres begge veier.
Det er greit at data samles inn i et sentralt hovedselskap, men vi ser det som avgjørende at lokale brukere kan oppdatere dataene, slik at franskmannen kan oppdatere de lokale varedataene, og endringen vil bli synkronisert tilbake til det sentrale selskapet, og neste synkroniseringsjobb vil replikere endringen hans til alle selskapene.
Vi må naturligvis ha oversikt over hvilke redigeringsrettigheter han trenger, dvs. hvilke felter han kan oppdatere og hvilke han ikke har lov til å gjøre noe med.
Han trenger også tilgang til inndata på fransk uten at det overskriver andre språkvarianter.
Han trenger også muligheten til å opprette et element som bare er relevant i Frankrike, og som ikke skal spres til andre selskaper.
Jo større selskapet er, og jo færre varer vi har eller jo mindre dynamisk en varestruktur vi har, desto mer relevant mener vi en sentralisert strategi med et hovedselskap er.
Dette gjelder også hvis vi har strenge kvalitetskontroller på varene våre, og utviklings- eller kvalitetsavdelingen vår sikrer og renser dataene svært grundig. I disse tilfellene er det fornuftig å klare seg uten desentralisert oppdatering og innovasjon.
Abonnere på data
Vi må kunne bygge opp en stamdatastruktur med en eier av data og abonnenter på data. I hvert datterselskap velger vi hvilke data vi ønsker å abonnere på.
Hvis det for eksempel finnes et fransk datterselskap i et tysk konsern, kan det franske datterselskapet abonnere på felles varer, kunder og andre masterdata – men det kan også opprette lokale varer som bare er relevante i Frankrike.
Hvis det franske datterselskapet kjøper en vare som bare finnes i Frankrike, gir det ingen mening å replikere dette varenummeret til 20 andre datterselskaper rundt om i verden.
