med hjälp av APPS
GLOBAL
VERKSAMHET

Business Central expert
Detta är #6 av 8 artiklar om hur du kan täcka hela ditt företag med BUSINESS CENTRAL
– utan kundtillägg
– använder endast APPS
Uppfyll alla dina behov för att hantera GLOBAL BUSINESS i BUSINESS CENTRAL.
I den här artikeln förklarar vi vad du bör kräva, hur du undviker anpassningar och vilka APPS du ska använda.
När vi hanterar flera bolag med Business Central uppstår en del extra behov. Ofta handlar det om att vi har bolag i flera länder, men det kan också helt enkelt handla om flera bolag i samma land.
Företagen har typiskt sett olika roller i försörjningskedjan, t.ex. logistikföretag, produktionsföretag och försäljningsföretag med ett antal processer däremellan.
Intercompany
Vi har ett säljbolag som har försäljningsorder eftersom de tar emot beställningar från slutkunder. Försäljningsbolaget tillhandahåller prognoser till huvudkontoret, som planerar produktbehovet, och de anlitar lager-/logistikföretaget för att leverera, eller från ett tredjepartslogistikföretag, och vissa order kan logistikföretaget leverera direkt till slutkunden.
Huvudkontoret köper också in varor från produktionsbolaget, som använder sig av ett antal externa leverantörer, producerar varorna och levererar dem i en container till logistik-/lagerbolaget.

Det är bara ett exempel. Oavsett hur vår företagsstruktur ser ut måste vi kunna hantera den i Business Central, och processerna måste stödjas så att vi inte behöver hantera all data och redovisning manuellt.
Som standard kan Business Central hantera intercompany-transaktioner bra, särskilt med oktober 2023-versionen, men vi behöver snabbt mer struktur och automatisering så att vi kan bokföra automatiskt i flera företag samtidigt.
När säljbolaget skapar en inköpsorder måste det automatiskt skapas en försäljningsorder i det bolag som ska leverera – och så vidare genom bolagsstrukturen. Vi vill också kunna se lagernivåerna i andra bolag, så att vi redan när vi tar emot ordern från kunden kan se om artikeln finns i lager hos ett annat bolag.
» Intercompany transaktioner

Vi behöver också hantera prissättningen mellan bolagen. Det är också en utmaning om vi har olika valutakurser i olika bolag.
Vi måste använda samma källa för priser och valutakurser så att elimineringar blir enklare och så att vi får samma värden på samma poster i koncernredovisningen.

Global hantering av masterdata
Master Data Management är ett viktigt ämne i ett företag med många bolag (juridiska personer). Vi måste ha en global struktur för masterdata och kunna synkronisera masterdata mellan företag, och vi måste inkludera masterdata i de dokument som används för försäljnings-, inköps- och överföringsorder mellan alla företag. Vi går på djupet med masterdata i ett separat kapitel.
Vi kanske har fem olika företag som i praktiken kommer att ha samma kunder, artiklar, masterdata osv. När vi skapar en ny artikel på huvudkontoret vill vi att den ska replikeras till de andra bolagen så att vi inte behöver skapa den flera gånger – och underhålla den i flera bolag. Vi behöver masterdata som är organiserade i en master- och abonnenthierarki.

Behållare
Containrar är ett viktigt ämne om vi transporterar gods över långa avstånd, både om vi skickar eller tar emot gods i containrar.
Som inköpare kan det vara så att vi har en container stående hos leverantören som vi successivt fyller med inköpsorder och när den är tillräckligt full får vi den skickad till oss. Då skulle vi vilja hantera alla inköpsorder i containern tillsammans. Om containern försenas med 4 dagar på vägen vill vi uppdatera alla inköpsrader på en gång och hitta de konflikter som det skapar.
På samma sätt, om vi är säljaren, så är det vi som skickar containern, och vi vill planera containerns kapacitet så bra som möjligt innan vi skickar iväg den.


Sortiment
Det finns ofta en skillnad i vilka varor och varianter som får köpas och säljas i olika bolag.
I lagerbolaget har vi 8 färger av en artikel, och ett säljbolag måste köpa alla 8, medan ett annat bara kan köpa 2 av färgerna eftersom de bara marknadsför de 2 färgerna.
I webbshopen måste det också finnas alla 8 färgerna för kunder i det första landet, men bara 2 för kunder i det andra landet. Och huvudkontoret har beslutat att en av färgerna måste tas bort, och därför måste endast 7 av färgerna beställas om från leverantören.
Den internationella strukturen måste kunna hantera allt detta på Business Central.
Förpackningar och etiketter
När du erbjuder varor till många länder blir förpackningar och etiketter en särskild utmaning. En ingrediensetikett kan innehålla 3 språk: Engelska, spanska och portugisiska, och det avgör i vilka länder produkten kan säljas.
Vi har samma vara i lager med andra språkkombinationer, t.ex. engelska, italienska och grekiska. Det kan hända att vi har 1000 exemplar av artikeln i lager och kan leverera alla 1000 till engelsktalande länder, men vi kan bara leverera 80 till Italien eftersom de övriga 920 inte har italienska på innehållsförteckningen.
Många varianter av förpackningar och etiketter är ytterligare en utmaning på Business Central.
Rapportering och uppföljning
Rapportering handlar om Business Intelligence. I en global organisation skulle vi vilja kunna rapportera över hela företagsstrukturen. Vad säljer vi i vilka delar av världen? Hur långa är våra leveranstider?
Om Business Intelligence visar att ledtiden för en artikel i själva verket är 3 månader, men masterdata för artikeln i ERP säger 2 månader, bör vi korrigera masterdata så att vi inte lovar kunderna något som vi inte kan uppfylla.

Konsolidering
Finansiell konsolidering är ett annat ämne som ofta hanteras med ett rapporteringsverktyg.
Vi skulle vilja kunna analysera enheterna i företagsstrukturen på ett jämförbart sätt. Det finns ingen poäng med att behöva mappa data från grunden varje gång för att få jämförbara siffror. Vi måste kunna hantera strukturen centralt för hela koncernen.
Vanligtvis upprättar vi ett koncernkonto, där vi konsoliderar all data från underliggande bolag upp till koncernkontot och eliminerar transaktionen. Om inte alla bolag använder Business Central är det smart att genomföra konsolideringen med en Business Intelligence lösning, men det kräver att vi har harmoniserade kontoplaner och dimensionskoder i alla bolag.

TRANSAKTIONER MELLAN KONCERNFÖRETAG
Om vårt företag är internationellt verksamt – eller om vi har många företag i vårt ERP-system som behöver integreras – är “intercompany” ett viktigt ämne.
I ett försäljningsbolag skapar vi en försäljningsorder för en kund; när vi släpper den måste en inköpsorder skapas för att köpa artikeln från ett annat företag i koncernen, och en försäljningsorder måste (automatiskt) skapas i vår koncerns produktions- eller lagerbolag.
Nu har vi tre orderdokument som är kopplade till varandra i två företag, och vi måste kunna hantera dem tillsammans och ändra dem som ett.
Förändringshantering
Hanteringen av förändringar är den svåra delen. I produktionsbolaget måste vi kunna ändra kvantiteter eller priser och få ändringen att fortplanta sig till både inköpsordern och försäljningsordern i säljbolaget.
Vi måste kunna göra en ändring i någon av de tre posterna, och ändringen bör återspeglas i de andra. Det är inte bra om vår lösning är för hårt styrd för att stödja den värld vi lever i.
Det finns flera områden där vi behöver flexibilitet i det dagliga arbetet.
En försäljningsorder
Vårt säljbolag behöver kunna skapa en försäljningsorder som innehåller rader från flera företag, t.ex. två artiklar från det lokala säljbolaget, fyra artiklar från lagerföretaget i Tyskland och tre artiklar som ska tillverkas av företaget i Polen.
Direkt leverans
Vi måste kunna ange om det är en direktleverans – dvs. om alla företag ska skicka varorna direkt till slutkunden – eller om de tyska och polska företagen ska skicka varorna till vårt lokala försäljningsbolag, som sedan skickar dem till kunden.
Detta är i själva verket en av de svåraste aspekterna av transaktioner mellan företag. Om de tyska och polska företagen skickar direkt till kunden måste de kunna bifoga en fraktsedel eller faktura som är utskriven enligt det ursprungliga lokala försäljningsföretagets logik, eftersom det trots allt är dem som kunden har haft att göra med. Detta blir komplicerat när olika företag och redovisningsenheter är inblandade.
När det lokala företaget säljer till en lokal kund till lokala priser och lokala rabatter, måste dokumenten kunna komma ut från skrivaren i Tyskland och Polen.
Spårning av objekt
Vi vill också kunna spåra artiklar mellan olika företag.
När lagerarbetaren i Tyskland plockar artiklar med serienummer måste han skanna serienumret, och sedan måste det flöda hela vägen till vårt lokala säljbolag så att vi lokalt kan se vilka serienummer som har plockats för ordern.
Konfiguration
När det gäller konfigurering av artiklar måste data flöda åt andra hållet. Vi registrerar specifikationerna för den konfigurerade artikeln, och kanske det faktum att en företagslogotyp måste tryckas på locket, på den lokala försäljningsordern. Dessa uppgifter måste sedan flöda till det polska produktionsbolaget, som ska producera artiklarna och trycka logotypen på locket.
Felhantering
Slutligen, hur hanterar intercompany-lösningen fel? Om något går fel mellan bolagen (t.ex. om artikelnumret inte finns hos det andra bolaget), hamnar då ordern i en fellogg som någon måste följa upp innan ordern kan gå vidare?
Vi rekommenderar definitivt att lösningen ska vara online och att fel ska returneras till användaren i realtid. Det innebär att om vi i vårt lokala säljbolag lägger en order som innebär att vi ska ta ut varor från de tyska och polska bolagen, så kommer vi att se eventuella fel på skärmen direkt när vi skriver, så att vi inte kan komma längre i processen förrän felet har hanterats.
Vi märker en tydlig ökning av efterfrågan på intercompany-lösningar. Det blir onekligen allt vanligare att transaktioner går över gränser och bolag.
Grundprinciperna är ganska enkla, men flexibilitet i de dagliga utmaningarna är det som verkligen utmärker en bra koncernintern lösning.

GLOBAL SYNKRONISERING
Vi kan ha fem olika företag (juridiska personer) som i praktiken kommer att ha samma kunder, artiklar, masterdata osv. När vi skapar en ny artikel på huvudkontoret vill vi att den ska replikeras till de andra företagen så att vi inte behöver konfigurera den flera gånger.
Vi kan också ha ett annat ERP-system i ett av dotterbolagen. Vi behöver synkronisera masterdata mellan alla plattformar, Business Central samt andra ERP-system inom koncernen. Detta gäller även för masterdata som vi själva har skapat, t.ex. färg, storlek, material eller många andra typer av masterdata om artiklar, kunder och leverantörer.

Utmaningen är att få de olika ERP-systemen, med olika datastrukturer, att prata med varandra. Vi måste tänka efter noga när vi utvecklar en datastruktur för att se till att nycklarna stämmer överens i alla företag – i de olika affärssystemen.
Strategier för datasynkronisering
Det finns olika strategier vi kan välja.
En centraliserad strategi innebär att vi har ett huvudbolag där vi skapar alla masterdata i en konsoliderad form, där vi samlar alla gäldenärer, alla artiklar och allt annat som vi vill ska hanteras av det centrala teamet. Systemet “pushar” data ut från huvudbolaget till de perifera bolagen.
Central hantering har vissa fördelar, men nackdelen är att data blir svårare att underhålla när färre medarbetare har tillgång.
Det kanske finns en lokal användare i Frankrike som märker att en viss information om en artikel är felaktig, men han låter bli att korrigera den eftersom det är mycket besvärligt att rapportera det till huvudkontoret. Om han korrigerar sina lokala data kommer de bara att skrivas över av huvudbolagets data när nästa synkroniseringsjobb körs.
Vi lutar därför åt en hybridstrategi där data kan synkroniseras i båda riktningarna.
Det är bra att data samlas in i ett centralt huvudbolag, men vi ser det som avgörande att lokala användare kan uppdatera data, så att fransmannen kan uppdatera de lokala artikeldata, och ändringen kommer att synkroniseras tillbaka till det centrala företaget, och nästa synkroniseringsjobb kommer att replikera hans ändring till alla företag.
Vi måste naturligtvis hålla koll på vilka redigeringsrättigheter han behöver, dvs. vilka fält han kan uppdatera och vilka han inte får röra.
Han behöver också ha tillgång till indata på franska utan att det skriver över andra språkvarianter.
Han behöver också ha möjlighet att skapa en artikel som bara är relevant i Frankrike och som inte ska spridas till andra företag.
Ju större bolaget är och ju färre artiklar vi har eller ju mindre dynamisk artikelstruktur vi har, desto mer relevant anser vi att en centraliserad strategi med ett huvudbolag är.
Detta gäller även om vi har strikta kvalitetskontroller på våra artiklar och vår utvecklings- eller kvalitetsavdelning säkrar och rensar data mycket noggrant. I dessa fall är det vettigt att avstå från decentraliserad uppdatering och innovation.
Prenumeration på data
Vi måste kunna bygga upp en masterdatastruktur med en ägare av data och prenumeranter av data. I varje dotterbolag väljer vi vilka data vi vill prenumerera på.
Om det t.ex. finns ett franskt dotterbolag i en tysk koncern kan det franska dotterbolaget prenumerera på delade artiklar, kunder och andra masterdata – men det kan också skapa lokala artiklar som bara är relevanta i Frankrike.
Om det franska dotterbolaget köper en vara som bara finns i Frankrike, är det inte meningsfullt att kopiera det artikelnumret till 20 andra dotterbolag runt om i världen.
