CRM-data i Power BI: Dynamics 365 Sales og Business Central i én model

Af /

CRM-data i Power BI giver først mening, når pipelinen og fakturaerne står i samme model. Dynamics 365 Sales ligger i Dataverse, Business Central har sine egne API’er, og nøglen mellem de to er koblingen af konti og debitorer. Her gennemgår vi, hvordan Sales-data lægges ind som sin egen kæde af Base, Enriched og Curated i Power Query, uden en dataplatform.

Resumé og konklusion

  • Dynamics 365 Sales læses gennem Dataverse-connectoren. Den kræver, at TDS-endpointet er slået til i miljøet, og hver forespørgsel må højst returnere 80 MB og køre i fem minutter.
  • Syv tabeller dækker det meste. account, contact, lead, opportunity, quote, salesorder og systemuser er nok til hitrate, pipeline og pipeline-til-faktura.
  • Nøglen er koblingen, ikke kundenavnet. Business Centrals integration kobler debitorer til konti i Dataverse. Den kobling skal gøres tilgængelig for modellen, før den kan bære en relation.
  • Sales får sin egen kæde, og kunden samles i Curated. Base og Enriched holdes adskilt pr. kilde. Først i Curated-laget mødes CRM og ERP på fælles dimensioner for kunde, sælger, vare og dato.
  • Det kører i Power BI uden Fabric-kapacitet. Grænserne ligger i datamængde og opdateringsfrekvens, og dem skal I kende, før I vælger.

Hvilke Dynamics 365 Sales-tabeller I skal bruge

Dynamics 365 Sales gemmer sine data i Dataverse, og tabellerne har logiske navne, som Power BI viser direkte. Til salgsanalyse på tværs af systemer er der syv, der bærer det meste:

  • account (konti): name, accountnumber, statecode. Det er her, kunden fra Business Central lander.
  • contact (kontaktpersoner): knyttet til en konto.
  • lead (kundeemner): statecode med Open, Qualified og Disqualified. Kolonnen qualifyingopportunityid peger på den salgsmulighed, emnet blev til.
  • opportunity (salgsmuligheder): estimatedvalue, actualvalue, estimatedclosedate, actualclosedate, closeprobability og statecode, hvor 0 er Open, 1 er Won og 2 er Lost.
  • quote (tilbud): statecode Draft, Active, Won og Closed, samt opportunityid og totalamount.
  • salesorder (ordrer): opportunityid, quoteid, customerid og totalamount.
  • systemuser (brugere): ejeren af salgsmuligheden, som i Business Central svarer til sælgeren.

Microsofts tabelreference for opportunity viser alle kolonner og værdier. Brug den, når I skal beslutte, hvilke kolonner der hentes. Jo færre kolonner, jo hurtigere refresh.

Dataverse-connectoren i Power BI: krav og grænser

Power BI læser Dataverse gennem Dataverse-connectoren, som bruger TDS-endpointet. Det er en read-only SQL-lignende adgang til tabellerne, og den respekterer Dataverse-sikkerheden for den konto, der logger på. Ifølge Microsofts vejledning til connectoren skal fire ting være på plads:

  • TDS-endpointet skal være slået til i miljøets indstillinger.
  • Kontoen, der opdaterer, skal have læserettigheder til tabellerne.
  • TCP-port 1433 eller 5558 skal være åben.
  • Miljøets adresse angives som orgname.crm.dynamics.com, uden https:// og uden skråstreg til sidst.

Grænserne er konkrete. Et forespørgselsresultat må højst fylde 80 MB, og hver forespørgsel har en fast timeout på fem minutter. Microsoft angiver hentehastigheden til omkring 500 rækker i sekundet. Valgkolonner kommer som to kolonner, fx statecode og statecodename, og opslagskolonner kommer som et id og et navn. Relationer bliver ikke oprettet automatisk, de skal bygges på GUID’erne.

For en SMV med nogle tusinde salgsmuligheder er det sjældent et problem. Det bliver et problem, hvis I også vil hente aktiviteter og e-mails for flere år. Så skal forespørgslerne filtreres på dato, eller datamængden skal flyttes et andet sted hen.

Nøglen: konti og debitorer i Business Centrals integration

Business Central integrerer med Dynamics 365 Sales gennem Dataverse. Integrationen arbejder med koblinger, der forbinder en post i Business Central med en række i Dataverse. Standardopsætningen, beskrevet i Microsofts oversigt over synkronisering, kobler Customer til Account i begge retninger, Contact til Contact, Currency til Transaction Currency og Salesperson/Purchaser til User. Med Sales-integrationen kan varer og ressourcer, salgsmuligheder, ordrer og bogførte salgsfakturaer også synkroniseres.

Koblingen er den nøgle, der gør CRM-data brugbare i en fælles model. I Business Central ligger den i tabellen CRM Integration Record, som peger på postens SystemId. Den tabel er ikke en del af de API’er, en rapportmodel normalt læser, så den skal eksponeres på en API-side, før Power Query kan bruge den. Det er et lille stykke AL-udvikling, men det skal gøres.

Der er tre mulige nøgler, i prioriteret rækkefølge:

  1. Koblingen selv. SystemId i Business Central mod accountid i Dataverse. Den er entydig og følger integrationen.
  2. Et nummer, der findes begge steder. Hvis jeres feltmapping skriver debitornummeret i account.accountnumber, kan det bruges. Tjek siden Integration Field Mappings for CUSTOMER, før I regner med det.
  3. Kundenavnet. Brug det ikke. “Hansen VVS ApS” og “Hansen VVS” er to kunder for Power Query.

Har I flere selskaber i Business Central, er der en ekstra detalje. Har account-tabellen kolonnen bcbi_companyid, angiver den, hvilket selskab kontoen hører til, og den skal mappes til modellens selskabsdimension.

CRM-data i Power BI lagt i lagene: Base, Enriched og Curated

Den semantiske model i oneBC365 har fire lag i Power Query: Base (BC_), Enriched (ER_), Curated (CU_) og Model. Det er samme opdeling, som en dataplatform bruger med bronze, silver og gold. En ny kilde får sin egen kæde, og de to kæder mødes først i Curated.

Base: rå Dataverse-tabeller

Én forespørgsel pr. tabel med en erklæret kolonneliste og intet andet. Navngivningen kan fx være DV_Account og DV_Opportunity, så det er tydeligt, at kilden er Dataverse og ikke Business Central. Ændrer Microsoft en kolonne, er det kun her, der skal rettes.

Enriched: navne, typer og nøgler

Kolonner får forretningsnavne, typer sættes, og datoer får en CalendarDateID i formatet yyyyMMdd, så de passer til modellens kalender. Statuskoder oversættes til tekst. Hver tabel får en surrogatnøgle og en unknown-member-række med -1, præcis som Business Central-tabellerne.

Curated: fælles dimensioner

Her samles kunden. CU_Customer beriges med accountid fra koblingen, så en salgsmulighed kan slå sin CustomerID op. Konti uden kobling er typisk emner, der endnu ikke er kunder. De skal ikke ende på -1, men som et medlem af typen “Kun i CRM”, ellers forsvinder nye kunder ud af hitraten. Sælgeren samles på samme måde via systemuser og Salesperson, varen via product og Item, og datoen via kalenderen.

Grafikken herunder viser de to kæder og det sted, hvor de mødes.

CRM-data i Power BI: Dynamics 365 Sales og Business Central som to kæder, der mødes i Curated-laget
To kilder, to kæder, fælles dimensioner i Curated.

Hitrate og pipeline-til-faktura på tværs af to systemer

Når kunden er fælles, kan to nøgletal regnes, som ingen af systemerne kan levere alene. Det første er hitraten. Den regnes på lukkede salgsmuligheder i perioden, altså vundne divideret med vundne plus tabte, fordelt på actualclosedate.

Tag en tænkt virksomhed med 120 lukkede salgsmuligheder i et kvartal, hvoraf 42 er vundet. Hitraten er 35 % i antal. Er de vundne 6,3 mio. kr. ud af 19 mio. kr., er hitraten 33 % i værdi.

Det andet er pipeline-til-faktura. Hvor meget af den vundne værdi i Dynamics 365 Sales blev faktisk faktureret i Business Central inden for 90 dage? I eksemplet er der faktureret 5,1 mio. kr. på de samme kunder. Det er 81 %.

Forskellen på 1,2 mio. kr. er rabatter, delleveringer, aflyste ordrer eller vundne muligheder, der aldrig blev til en ordre. Det er præcis den samtale, salgschefen og økonomichefen skal have. Mere om selve nøgletallene står i salgsledelse: nøgletal for pipeline og hitrate.

Grafikken herunder viser kæden fra kundeemne til bogført faktura og nøglen mellem hvert led.

Pipeline-til-faktura med nøgler fra lead og opportunity i Dynamics 365 Sales til faktura i Business Central
Fem led og fire nøgler. Regnestykket er et eksempel.

Kan I kun koble på kundeniveau, er pipeline-til-faktura en sammenligning pr. kunde og måned. Er ordrerne også koblet via indstillingen Bidirectional Synch of Sales Orders, kan den følges ordre for ordre, fordi den bogførte faktura bærer ordrenummeret. Begynd med kundeniveau.

Sådan sætter du det op i Power BI

  1. Opret parametre. Lav en parameter til miljøets adresse og en til den første dato, der skal hentes. Så kan samme model pege på et testmiljø.
  2. Byg Base-forespørgslerne. Vælg Dataverse i Hent data, vælg Import, og hent kun de kolonner, I har skrevet ned. Filtrér opportunity på modifiedon eller actualclosedate, så I ikke henter ti års historik.
  3. Sæt privatlivsniveauer. Når Curated-laget joiner Dataverse med Business Central-API’et, kombinerer Power Query to kilder. Sæt begge til Organizational, ellers stopper Formula.Firewall opdateringen. Baggrunden står i data fra flere systemer i Power BI.
  4. Byg relationerne på surrogatnøgler. Faktatabellen CRM Opportunity får CustomerID, SalespersonID og CalendarDateID fra Curated. Ingen relationer på GUID’er i Model-laget.
  5. Skriv beskrivelser. Hitrate, vundet værdi og pipeline-til-faktura skal have en beskrivelse i modellen. Copilot og andre agenter læser dem.

Hvad CRM-data i Power BI ikke løser

Import betyder, at data er så friske som seneste opdatering. På Power BI Pro er det op til otte planlagte opdateringer om dagen, og en opdatering skal være færdig inden for to timer. Det er fint til ledelsesrapportering, men ikke til en sælger, der vil se sin ændring med det samme.

Dataverse-sikkerheden følger heller ikke med. Data hentes med den konto, der opdaterer, og derefter er det modellens RLS, der styrer, hvem der ser hvad. Må sælgere kun se egne kunder i Dynamics 365 Sales, skal det bygges igen i modellen.

Og store mængder er en grænse. Skal I analysere aktiviteter, e-mails og historik i millionvis af rækker, er Link to Microsoft Fabric eller Azure Synapse Link de veje, Microsoft anviser. Link to Microsoft Fabric kræver en Premium- eller Fabric-kapacitet i samme geografi som Dataverse og øger forbruget af Dataverse-lagerplads. Så er vi dér, hvor en dataplatform giver mening, og det kan hvornår er Power BI nok hjælpe med at afgøre.

Sådan understøtter oneBC365 det

oneBC365 er en færdig semantisk model oven på Business Central med ni moduler og 400+ forretningsmål. CRM i modellen er i dag Business Centrals egne salgsmuligheder i tabellen Opportunity Entries. Dynamics 365 Sales er ikke med som standard, men oneBC365 kan lægge den ind som en udvidelse af modellen, aftalt og estimeret pr. kilde (se services). Modellen er bygget, så en kilde mere kan lægges ind som sin egen kæde, med de eksisterende lag som mønster og delte funktioner til surrogatnøgler og unknown members.

Det er seriens pointe. Dataplatform-leverandørerne bygger det samme mønster med lakehouse, pipelines og Fabric-kapacitet. I oneBC365 ligger det i Power BI’s semantiske lag på Pro-licenser, og hele løsningen ligger som PBIP i Git med kommenteret M-kode. I ejer koden, og jeres BC-partner kan udvide den. Den dag volumen eller realtid kræver mere, kan lagene flyttes til Dataflows Gen2 eller en Fabric Lakehouse, mens rapporterne bliver stående.

Sådan kommer du i gang

  1. Tæl jeres koblinger. Tjek, hvor mange aktive debitorer i Business Central der er koblet til en konto i Dataverse, og hvor mange der mangler. Mangler mange, er datakvalitet første opgave.
  2. Tjek adgangen til Dataverse. Få bekræftet, at TDS-endpointet er slået til, og at der findes en konto med læseret til de syv tabeller.
  3. Beslut nøglen. Koblingstabellen via en API-side, eller et nummer der synkroniseres. Skriv valget ned, så det ikke bliver kundenavnet.
  4. Definér to nøgletal. Skriv hitrate og pipeline-til-faktura ned i én sætning hver, inklusive hvilken dato der tæller. Først derefter bygges de i DAX.

Relaterede artikler

Vil I se, hvordan salgsdata fra Business Central ser ud i en færdig model på jeres egne tal? Book en demo, så viser vi det live på 30 minutter.

Scroll to Top