Data fra flere systemer i Power BI er dér, hvor ledelsesspørgsmålene bliver interessante. Business Central ved, hvad der er faktureret, og hvad det kostede. Det ved ikke, hvor mange salgsmuligheder der blev tabt, hvor mange gange teknikeren kørte ud, eller hvad planen sagde for tre måneder siden. Det kræver fælles nøgler og en model, der kan samle kilderne.
Resumé og konklusion
- Seks typiske ledelsesspørgsmål kan ikke besvares fra ERP’et alene. Pipeline til faktura, servicemargin pr. kontrakt, førstegangsløsning, kapacitet mod ordrebog, forecast-præcision og kundens samlede værdi kræver to eller flere systemer.
- Fem fælles dimensioner bærer det hele. Kunde, vare, ressource eller medarbejder, dato og sag. Hver skal have én nøgle, der virker på tværs af kilderne.
- Power Query blokerer kombinationer, der ikke er sat op. Privacy levels afgør, om to kilder må mødes. Står de forkert, får I en Formula.Firewall-fejl eller en opdatering, der fejler i Power BI-tjenesten.
- Nøglerne er et datakvalitetsspørgsmål. En konto i CRM uden kobling til en debitor i Business Central lander på unknown member, og tallet forsvinder fra kundens samlede værdi.
- Kombinationen hører til i Curated-laget. Hver kilde hentes og renses for sig, og først i Curated samles de fælles dimensioner.
Seks spørgsmål, der kræver data fra flere systemer i Power BI
Spørgsmålene herunder går igen i SMV’er med Business Central og et CRM-, service- eller planlægningssystem ved siden af. For hvert spørgsmål står, hvilke kilder der indgår, og hvilken nøgle der binder dem.
1. Hvor meget af pipelinen bliver til faktura?
Salgsmulighederne og deres estimerede værdi ligger i Dynamics 365 Sales. Fakturaerne ligger i Business Central. Nøglen er kunden, og hvis salgsordren oprettes fra salgsmuligheden, også ordrenummeret. Uden begge kilder kan I se hitraten eller omsætningen, men ikke hvor lang tid der går fra vundet salgsmulighed til første faktura. Tabellerne i Dataverse gennemgår vi i CRM-data i Power BI.
2. Hvad er servicemarginen pr. kontrakt?
Kontrakten og arbejdsordrerne ligger i Dynamics 365 Field Service. Faktureringen og kostprisen på reservedele ligger i Business Central. Nøglen er kontrakten og kunden. Bruger I Service Management i Business Central, ligger det hele ét sted, og spørgsmålet kan besvares uden en ekstra kilde. Se også Servicemargin og kontraktfornyelse: 3 tal der gør service til et forretningsområde.
3. Løser teknikeren det ved første besøg, og med hvilke dele?
Besøgene og status på arbejdsordren ligger i Field Service. Reservedelene trækkes fra lageret i Business Central. Nøglen er arbejdsordren og varen. Førstegangsløsning uden reservedelsforbrug fortæller kun halvdelen af historien.
4. Kan kapaciteten bære ordrebogen?
Kapaciteten pr. ressource og uge ligger i et planlægningssystem eller i et regneark. Åbne salgsordrer og produktionsordrer ligger i Business Central. Nøglen er ressourcen og ugen. Dato-dimensionen skal kunne rulle dage op til uger, fordi planen ofte ikke findes på dagsniveau.
5. Hvor præcist rammer forecastet?
Planen ligger i planlægningssystemet, gerne i flere versioner. Den faktiske afsætning ligger i Business Central. Nøglen er vare, periode og planversion. Uden gemte planversioner kan I kun sammenligne faktisk med den seneste plan, og så måler I ikke forecastet, men justeringen af det.
6. Hvad er kundens samlede værdi?
Omsætning og dækningsbidrag fra Business Central, åben pipeline fra CRM og serviceomkostninger fra Field Service. Nøglen er kunden, og det er her, manglende koblinger gør mest skade.
Grafikken herunder viser, hvilke kilder og nøgler hvert spørgsmål kræver.
Fælles dimensioner og nøgler til data fra flere systemer i Power BI
De seks spørgsmål bruger kun fem dimensioner: kunde, vare, ressource eller medarbejder, dato og sag. Det er dem, der skal virke på tværs. For hver dimension skal I beslutte to ting: hvilket system der ejer stamdata, og hvordan de andre systemer peger på den. Det er også dem, AI-agenter på tværs af systemer filtrerer på.
For kunden er Business Central typisk ejeren. Bruger I Business Centrals integration med Dynamics 365 Sales, kobles debitorer og konti, og koblingen kan bruges som nøgle i modellen. For varen er det varenummeret. For ressourcen er det sjældent så enkelt, fordi teknikeren i Field Service, medarbejderen i løn og ressourcen i Business Central kan have tre forskellige id’er.
I en lagdelt model får hver dimension en surrogatnøgle i Enriched-laget og en unknown-member-række med nøglen -1. Curated-laget laver opslaget på tværs og fører den fælles nøgle ud på faktatabellerne. Vi har beskrevet lagene i Semantisk lag i Power BI: 4 lag med samme struktur som en dataplatform, og dimensionerne i Business Central i Dimensioner i Business Central.
Privacy levels og Formula.Firewall, når data fra flere systemer mødes
Power Query har en indbygget Data Privacy Firewall, der skal forhindre, at data fra én kilde utilsigtet sendes til en anden. Hver kilde har et privacy level: Private, Organizational eller Public. Ifølge Microsofts dokumentation af firewallen er det kun kombinationerne Public med Public og Organizational med Organizational, der tillader deling begge veje.
Står Business Central som Organizational og Dataverse som Private, bliver en fletning mellem dem blokeret med en fejl som: “Formula.Firewall: Query ‘Query1’ (step ‘Source’) is accessing data sources that have privacy levels which cannot be used together. Please rebuild this data combination.” Løsningen er at sætte begge kilder til Organizational under Data source settings, når de begge er virksomhedens egne systemer.
Den anden klassiske fejl lyder “references other queries or steps, so it may not directly access a data source”. Den opstod, når én forespørgsel både hentede fra en kilde og brugte resultatet af en anden forespørgsel. Fra juli 2026-versionen af Power BI Desktop er en indstilling slået til som standard, der tillader mønstret, når privacy levels er kompatible. Power BI-tjenesten understøttede det i forvejen, jf. Microsoft Learn.
To ting skal I vide. Indstillingen “Ignore the Privacy Levels” virker ikke for semantiske modeller i Power BI-tjenesten, så en model, der kun kører med den slået til i Desktop, fejler efter publicering. Og når data krydser fra én partition til en anden, kan firewallen buffere dem i hukommelsen, så en join ikke længere kan skubbes ned til kilden.
Grafikken herunder viser, hvor kilderne hentes, og hvor de må mødes.
Datakvalitet i nøglerne afgør svaret
Tag en virksomhed med 1.200 debitorer i Business Central og 1.400 konti i Dynamics 365 Sales. 150 af de aktive debitorer er ikke koblet til en konto. Deres pipeline lander på unknown member i kundedimensionen. Summen er rigtig, men kundens samlede værdi er for lav for netop de 150 kunder, og ingen ser det i rapporten.
Derfor skal modellen måle sine egne nøgler. Et mål for andelen af pipeline og omsætning på nøglen -1 hører hjemme på en datakvalitetsside, og det skal være tæt på nul. Vi har beskrevet flere kontroller i Datakvalitet målt i Power BI: 8 kontroller der virker. Oprydningen sker i kildesystemet, ikke i Power Query.
Sådan sætter du det op i Power BI
- Hent hver kilde i sine egne Base-forespørgsler. Én forespørgsel pr. tabel eller endpoint, uden joins og uden forretningslogik.
- Sæt privacy levels bevidst. Åbn File, Options and settings, Data source settings, vælg kilden og Edit Permissions. Virksomhedens egne systemer sættes normalt til Organizational.
- Byg surrogatnøgler og -1-rækker i Enriched. Gør det for hver kilde, før de mødes.
- Kombinér i Curated. Lav opslaget mellem debitor og konto, ressource og tekniker, vare og planlinje her, og før den fælles nøgle ud på faktatabellerne.
- Publicér og test opdateringen i tjenesten. Se efter firewall-fejl og for dynamiske datakilder, som tjenesten ikke kan opdatere.
Hvad en samlet model ikke løser
Dataverse-connectoren kræver, at TDS-endpointet er slået til i miljøet, og hver forespørgsel har en fast timeout på fem minutter. Microsoft angiver i dokumentationen for connectoren, at den er beregnet til relativt små datamængder, og anbefaler Azure Synapse Link til udtræk i stor skala.
Kilderne er heller ikke nødvendigvis i takt. Synkroniseringen mellem Business Central og Dynamics 365 Sales kører med et interval, så en ny debitor kan findes i det ene system, før koblingen er på plads. Det giver unknown members i en periode, uden at noget er galt.
Og lofterne fra Power BI Pro gælder stadig: 1 GB pr. model og otte planlagte opdateringer om dagen, uanset hvor mange kilder der indgår.
Antallet af kilder har også en grænse. Eksemplerne i serien samler Business Central med op til tre systemer: CRM, Field Service og planlægning. Skal I kombinere mere end 5-8 datakilder, eller bygger flere afdelinger hver deres model på de samme grundtal, er det tegn på, at en dataplatform bør overvejes, jf. Hvornår er Power BI nok?.
Sådan understøtter oneBC365 det
oneBC365 er i dag bygget på Business Central-data: finans, salg, indkøb, lager, projekt, service, lagersted, produktion og medarbejder. CRM-delen er Business Centrals egne salgsmuligheder i tabellen Opportunity Entries. Modellen har de fælles dimensioner, surrogatnøgler og unknown-member-rækker, som en ekstra kilde skal kobles på, og alle hentninger fra Business Central sker gennem én datakilde, så firewallen ikke blokerer dem.
Strukturen med Base, Enriched, Curated og Model er lavet, så en kilde som Dynamics 365 Sales eller Field Service kan få sin egen kæde og mødes med Business Central i Curated-laget. Den udvidelse kan oneBC365 levere som en del af services. Den aftales og estimeres pr. kilde, og målet er, at de rapporter, der findes, virker uændret. Fordi kunden ejer koden, kan BC-partneren eller jeres egen Power BI-udvikler også gøre det.
Sådan kommer du i gang
- Vælg ét af de seks spørgsmål. Tag det, ledelsen oftest spørger om, og skriv ned, hvilke systemer det kræver.
- Tæl de manglende koblinger. Hvor mange aktive debitorer har ingen konto i CRM, og hvor mange teknikere har ingen ressource i Business Central?
- Tjek privacy levels i jeres nuværende filer. Står nogen kilder til None eller Private uden grund, så ret dem, før I tilføjer en ny kilde.
- Byg den nye kilde som et lag for sig. Hent, rens og nøglesæt den, før den kombineres med Business Central.
Relaterede artikler
- CRM-data i Power BI: Dynamics 365 Sales og Business Central i én model
- Field Service i Power BI: servicemargin på tværs af to systemer
- Planlægningsdata i Power BI: plan mod faktisk på tværs af systemer
- Stamdata der bærer analysen
- Salgschefens uge: 5 salgsledelse nøgletal før tallene står i regnskabet
Vil I se, hvordan data fra Business Central ser ud samlet i én model på jeres egne tal? Book en demo, og se det live på 30 minutter.
