Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg hedder Emma, og jeg har Alex med. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag ser vi på to ændringer i Business Central niogtyve, som gør det lettere at undersøge oplysninger: spor af oprettelser og ændringer på listerne, og AI-hjælp til at indsamle grundlaget, når noget fejler. Derudover har vi tre nyttige muligheder fra tidligere på året. Blandt andet forskellige salgsagenter til forskelligt indgående arbejde. Den røde tråd er enkel: Hvad kan den, der sidder med opgaven, nu se eller tage stilling til på et bedre grundlag? Lad os komme i gang.

• Brug flere Sales Order Agent-instanser pr. virksomhed
• Opret købstilbud til kontakter
• Definer vareattributter for varevarianter
• Opdatering 29.0 til Business Central 2026 release wave 2
• Nyt og ændret i Business Central 2026 release wave 2 – opdatering 29.0

Vi begynder med en lille oktobernyhed, som måske kan spare en noget upræcis samtale. I Business Central niogtyve kan systemets revisionsfelter bruges på analysefaner og tilføjes på sider gennem profiler. Det bliver altså lettere at få vist, hvem der oprettede eller senest ændrede en post. Alex, hvilket nyttigt spørgsmål kan vi få svar på her, før vi gør det til et stort revisionsprojekt?

• Opdatering 29.0 til Business Central 2026 release wave 2
• Funktionsdetaljer for Business Central 2026 release wave 2

Ofte er det så enkelt som: Hvem skal jeg spørge om den her post? Forestil dig et team, der gennemgår en liste, før arbejdet går videre til den næste. Noget ser anderledes ud end i går. Tidspunktet for den seneste ændring og navnet på brugeren kan give dem et sted at begynde, uden at de skal spørge alle i lokalet. Forbedringen er den lettere adgang til oplysningerne. Business Central er ikke først nu begyndt at gemme, hvem der oprettede og ændrede posterne. De felter fandtes allerede.

• Funktionsdetaljer for Business Central 2026 release wave 2
• Arbejd med tabellers systemfelter

Et sted at begynde lyder mere nyttigt end en skyldig. Hvis der står Alex, kan jeg godt forestille mig, at nogen straks siger, at Alex ændrede prisen. Men posten kan jo være blevet ændret igen af en helt anden grund. Hvor meget kan jeg egentlig lægge i oplysningen om, hvem der senest ændrede den?

• Arbejd med tabellers systemfelter

Kun at det var den seneste ændring af posten. Ikke at Alex ændrede netop den pris. De her felter indeholder ikke alle ændringerne undervejs eller den gamle og nye værdi i hvert enkelt felt. Navnet kan altså hjælpe dig med at finde et fornuftigt sted at begynde. Men det giver dig ikke den historik, der mangler.

• Arbejd med tabellers systemfelter

Så vil jeg hellere spørge: Hvilke poster er der sket noget med, siden vi sidst gennemgik dem? Det anklager ikke nogen, og det hjælper mig med at vælge, hvor jeg skal kigge. Kan teamet bruge den nye adgang i analysefunktionen til sådan en første gennemgang, uden at ændre posterne, mens de undersøger dem?

• Funktionsdetaljer for Business Central 2026 release wave 2
• Analyser liste- og forespørgselsdata med dataanalyse

Ja. Analysefunktionen redigerer ikke de underliggende poster. Forestil dig, at teamet har hundrede poster at gennemgå. Men det nyttige spørgsmål er, hvilke der er ændret siden overleveringen i går. Datoen for den seneste ændring giver et langt bedre udgangspunkt end at åbne alle hundrede. Så kan de undersøge de relevante poster og stille et mere præcist spørgsmål. De skal have rettighed til analysefunktionen, og den kan være slået fra på enkelte sider. Begynd derfor med en side, de faktisk kan bruge.

• Funktionsdetaljer for Business Central 2026 release wave 2
• Arbejd med tabellers systemfelter
• Analyser liste- og forespørgselsdata med dataanalyse

Det ændrer jo samtalen, når arbejdet skal gives videre. I stedet for at alle skal huske, hvad de har rørt ved, har vi et mindre udvalg af poster foran os. Jeg vil stadig gerne kunne skelne mellem noget helt nyoprettet og en eksisterende post, der er blevet ændret. Ellers kan en travl formiddag med nye opgaver komme til at ligne en formiddag, hvor man bare rettede i gamle.

• Arbejd med tabellers systemfelter

Og der hjælper det netop, at oplysningerne om oprettelse og ændring er adskilt. Oplysningerne om oprettelsen bliver hos posten. Ændringsoplysningerne følger med, når den bliver opdateret. Teamet kan derfor stille to forskellige spørgsmål: Hvad er kommet til, og hvad er der efterfølgende blevet arbejdet på? Ingen af tallene er et mål for produktivitet. Men tilsammen kan de hjælpe med at gennemgå arbejdet, så en kollega ikke skal forsøge at genskabe hele formiddagen efter hukommelsen.

• Arbejd med tabellers systemfelter

Nu giver muligheden med profiler bedre mening for mig. Hvis det spørgsmål bliver ved med at dukke op, kan en administrator få de relevante felter ind på teamets side. Så behøver alle ikke hver især at opdage den samme nyttige visning. Det handler ikke om flere oplysninger bare for at have dem. Det handler om at bruge mindre tid på at finde det, der får den rigtige samtale i gang.

• Funktionsdetaljer for Business Central 2026 release wave 2

Det er den gevinst, jeg ville kigge efter: Kan den næste kollega lettere tage over? Prøv visningen med et konkret spørgsmål fra overleveringen, og behold de felter, der hjælper med svaret. Det er en forholdsvis lille nyhed i en udgivelse. Men den kan passe lige ind i en opgave, folk allerede løser, i stedet for at kræve, at de lærer en helt ny proces.

• Funktionsdetaljer for Business Central 2026 release wave 2

Lad os gå fra at se, hvem der har arbejdet med en post, til at vælge, hvor det indgående arbejde skal hen. Allerede i juli fik Business Central mulighed for flere Sales Order Agent-instanser i samme regnskab. Altså ikke først nu i oktober. Hver instans kan have sin egen mailovervågning og sine egne behandlingsregler, med separate målinger. Det interesserer mig mere end bare at have flere agenter. Hvorfor skulle en virksomhed faktisk have brug for mere end én?

• Brug flere Sales Order Agent-instanser pr. virksomhed
• Opsætning af Sales Order Agent

Fordi forskellige henvendelser kan kræve forskellige næste skridt, også inden for samme virksomhed. Én kundegruppe vil måske se og bekræfte et tilbud, før der bliver oprettet en ordre. Andre henvendelser skal måske ende som tilbud, salgsteamet selv tager videre. Med separate instanser kan de to grupper få hver deres behandlingsregler, og resultaterne kan følges hver for sig. Gevinsten er ikke bare at gøre mere på én gang. Det er, at opsætningen passer til den slags arbejde, der kommer ind.

• Opsætning af Sales Order Agent

Jeg kan godt lide forskellen mellem at gøre et tilbud klar og at beslutte, at det skal blive til en ordre. Lad os sige, at den ene gruppe henvendelser er ret rutinepræget, mens den anden ofte fører til en snak om prisen. Dem kan vi vel behandle forskelligt uden at forvente, at agent nummer to pludselig bliver en dreven forhandler?

• Opsætning af Sales Order Agent
• Ofte stillede spørgsmål om Sales Order Agent

Præcis. Ændringer i pris og rabat kræver stadig mennesker. Den begrænsning forsvinder ikke med en ekstra instans. Men det kan i sig selv være værdifuldt at adskille de rutineopgaver, agenten understøtter, fra de kommercielle beslutninger. Jeg ville lade en person tage forhandlingerne og bygge agentens forløb op omkring de valg mellem tilbud og ordre, som den faktisk understøtter. Så ved salgsteamet, hvilket resultat de kan forvente. De skal ikke vurdere hver eneste opgave op imod et lidt løst løfte om automatisering.

• Opsætning af Sales Order Agent
• Ofte stillede spørgsmål om Sales Order Agent

Så lad os gøre valget omkring tilbuddet helt konkret. Jeg kan forestille mig at sige: Send kunden et tilbud, men opret ikke ordren endnu. Eller: Behold tilbuddet internt, så en kollega kan gøre det færdigt. Er det særskilte valg i opsætningen, i stedet for én stor knap, hvor man bare slår automatisering til?

• Opsætning af Sales Order Agent

Se på, hvad der skal ske med tilbuddet. Agenten begynder med at oprette et salgstilbud. Men at sende det til kunden til bekræftelse og at konvertere det til en ordre er to forskellige indstillinger. Ét forløb kan sende tilbuddet og vente på kundens bekræftelse før konverteringen. Et andet kan lade tilbuddet ligge, så en person selv konverterer det. Der findes også en opsætning, som konverterer uden først at sende tilbuddet. Det er forskellige salgsprocesser, ikke bare forskellige hastigheder.

• Opsætning af Sales Order Agent

Jeg ville passe på med at kalde den sidste mulighed den avancerede indstilling. Det kan jo være helt fornuftigt at vente på kundens bekræftelse. Det er ikke nødvendigvis et tegn på, at virksomheden mangler at automatisere noget. Hvis kunden stadig sammenligner muligheder, kan en hurtigt oprettet ordre være præcis det forkerte resultat.

• Opsætning af Sales Order Agent

Bestemt. Jeg ville vælge ud fra aftalen med kunden, ikke efter hvor selvkørende indstillingen lyder. Og der er to slags bekræftelse, som let bliver blandet sammen. Kundens bekræftelse af tilbuddet er én ting. Den menneskelige gennemgang af dokumenterne, som man har sat op, er noget andet. At slå kundebekræftelsen fra betyder derfor ikke i sig selv, at al menneskelig kontrol forsvinder. Før man ændrer et forløb, ville jeg tegne vejen fra henvendelse til tilbud til ordre. Og få placeret hver beslutning hos den, der skal tage den.

• Opsætning af Sales Order Agent

Og selve opdelingen af de indgående henvendelser skal give mening. Microsoft beskriver nu overvågning af en valgt mappe i enten en brugers postkasse eller en delt postkasse i Microsoft tre seks fem. Jeg kan godt forstå, hvis teamet foretrækker en tydeligt afgrænset mappe frem for at give agenten alle beskeder i virksomhedens hovedpostkasse. Men nogen skal stadig beslutte, hvilke opgaver der hører hjemme i den mappe.

• Opsætning af Sales Order Agent

Ja, mappen er en afgrænsning, man selv laver. Den tager ikke beslutningen om, hvad der hører til. Og man behøver faktisk slet ikke at tilslutte en postkasse for at undersøge forløbet. Microsoft understøtter også, at man starter en opgave manuelt. Så kan teamet tage en kendt henvendelse og det forventede resultat, før man åbner for løbende behandling af mails. Det er dog stadig en agentopgave med de nødvendige rettigheder og forbrugsafregning. Ikke en gratis simulering.

• Opsætning af Sales Order Agent
• Administrer forbrugsbaseret afregning af agentfunktioner

Det virker som et mere overskueligt første skridt end at omlægge hele indbakken. Vælg en henvendelse, hvor vi kender det ønskede resultat, og se, om tilbuddet faktisk bringer os derhen. Hvad ville du så kigge efter, når man overvejer en ekstra instans? Separate målinger lyder nyttige. Men jeg vil ikke have, at den travleste agent vinder, bare fordi den har skabt mest aktivitet.

• Opsætning af Sales Order Agent

Jeg ville sammenligne resultaterne for de forskellige typer henvendelser og lade teamet gennemgå dokumenterne. Var tilbuddet brugbart? Passede den valgte bekræftelse til kunden? Hvor meget skulle medarbejderne stadig følge op på? Det er spørgsmål til evalueringen, ikke et løfte om bestemte felter på et indbygget dashboard. Målinger pr. instans hjælper med at holde forløbene adskilt, og forbruget af Copilot Credits giver omkostningssiden. Mere aktivitet er ikke nødvendigvis mere nyttigt arbejde. Slet ikke hvis nogen bagefter skal bruge tid på at rede trådene ud.

• Opsætning af Sales Order Agent
• Administrer forbrugsbaseret afregning af agentfunktioner

Der er en meget praktisk detalje i dokumentationen: Når man stopper en opgave, forsvinder det tilbud, agenten allerede har oprettet, ikke nødvendigvis. Det er værd at vide, før teamet begynder at afprøve forskellige forløb. Ellers kan stop jo lyde som en betryggende fortryd-knap. Og det er det ikke.

• Behandl salgstilbud og ordrer med Sales Order Agent

Nej, stop er ikke fortryd, og en stoppet opgave kan ikke genstartes. Tilbuddet kan stadig være åbent og kræve, at en person følger op. Tag derfor også den situation med, når teamet afprøver processen. Ikke kun den henvendelse, der går glat igennem. Stop bevidst en opgave, og undersøg bagefter, hvad der er tilbage. Agenten bogfører heller ikke dokumenter. Dens arbejde er en del af salgsprocessen, hvor der stadig er efterfølgende trin. Det giver en mere præcis afslutning på agentens opgave end at behandle en oprettet ordre som hele handlen.

• Ofte stillede spørgsmål om Sales Order Agent
• Behandl salgstilbud og ordrer med Sales Order Agent

Inden vi kalder en strøm af henvendelser for rutinearbejde, er der lige et spørgsmål mere. Rutine for hvem? En mail kan se helt velkendt ud, men komme fra en virksomhed, der endnu ikke er kunde i Business Central. Eller handle om en vare, der ikke er oprettet. Opretter agenten de manglende oplysninger, mens den behandler henvendelsen?

• Ofte stillede spørgsmål om Sales Order Agent

Nej. Den dokumenterede agent arbejder med eksisterende kunder, kontakter og varer. Den opretter ikke de manglende stamdata. Den understøtter salgslinjer af typen Vare og op til femten varelinjer inden for det dokumenterede funktionsomfang. Det giver os en mere konkret beskrivelse af den første strøm af henvendelser, man kan prøve med. Kendte varer, kendte forretningsforbindelser og dokumenter, der holder sig inden for de understøttede rammer. En henvendelse kan være nem for en erfaren medarbejder, netop fordi vedkommende ved, hvordan de manglende oplysninger skal skaffes. Det betyder ikke, at den samme henvendelse er klar til agenten.

• Ofte stillede spørgsmål om Sales Order Agent

Det er et langt mere rimeligt udgangspunkt end at bede agenten klare hele indbakken og så bedømme den på, hvad der tilfældigvis lander. Jeg ville vælge en håndfuld repræsentative henvendelser fra den kendte strøm. Både en, der skal blive ved med at være et tilbud, og en, der er tænkt som en ordre. Så kan teamet sammenligne det faktiske resultat med den beslutning, de ønskede. I stedet for bare at glæde sig over, at der skete noget.

• Opsætning af Sales Order Agent
• Ofte stillede spørgsmål om Sales Order Agent

Til jer, der tænker, at det her kunne være relevant: Dansk er blandt de sprog, som er understøttet og valideret. Men sproget er ikke det eneste, der skal være på plads. Der er rettigheder til at konfigurere agenter, adgang til postkassen, hvis man bruger mail, og afregning af forbruget. Hvad skal man ellers undersøge, før man regner med, at det er klar til brug i ens eget miljø?

• Opsætning af Sales Order Agent
• Ofte stillede spørgsmål om Sales Order Agent

Se også på tilgængeligheden i miljøet og indstillingerne for behandling af data på tværs af geografiske områder. Hvis den nødvendige Azure OpenAI-tjeneste ikke er tilgængelig lokalt, kræver dokumentationen, at en administrator tillader behandling i et andet geografisk område. Det er en reel beslutning for virksomheden. Den bliver ikke løst ved at vælge et sprog. Når forudsætningerne er på plads, ville jeg stadig begynde med ét klart beskrevet forløb. Tilføj et mere, når reglerne eller de indgående opgaver er reelt forskellige. Flere instanser er nyttige, fordi de bevarer de forskelle. Ikke fordi virksomheden bør samle på agenter.

• Opsætning af Sales Order Agent
• Ofte stillede spørgsmål om Sales Order Agent
• Administrer forbrugsbaseret afregning af agentfunktioner

Lad os lægge agenterne til side et øjeblik. Jeg vil gerne se på noget, som personen, der vælger en vare, faktisk kan få øje på. Siden april har Business Central understøttet attributter på de enkelte varevarianter og billeder af varianterne. Altså ikke kun én beskrivelse og ét billede på selve varen. Alex, hvornår er det mere end bare et pænere varekort?

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Definer vareattributter for varevarianter

Når forskellen mellem varianterne betyder noget for at vælge den rigtige. Forestil dig, at virksomheden sælger samme design med to forskellige overflader. Beskrivelsen på varen forklarer, hvad produktet er. Men overfladen og billedet fortæller personen, hvilken udgave de står med. En variantkode kan identificere valget helt præcist. En attribut og et billede kan gøre valget forståeligt. Det er især nyttigt, når to koder er fuldstændig entydige for systemet, men ikke særlig nemme at huske for den, der skal vælge.

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Definer vareattributter for varevarianter

Koden kan altså være helt rigtig og stadig få en medarbejder til at standse op og tænke sig om. Jeg ser for mig to overflader med næsten ens navne, hvor et lille billede straks ville afklare forskellen. Men hvis alle fælles attributter skal tastes ind igen på hver variant, er forbedringen noget mindre tillokkende for den, der vedligeholder oplysningerne.

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Definer vareattributter for varevarianter
• Administrer produktvarianter

Heldigvis får en ny variant attributterne med fra varen. Man begynder med de fælles oplysninger og ændrer eller fjerner så værdier, hvor varianten har brug for noget andet. I vores eksempel kan oplysningerne om det fælles design komme fra varen, mens overfladen beskriver den bestemte udgave. Det interessante arbejde er at beslutte, hvad der faktisk er fælles. Hvis alt bliver en undtagelse, sparer nedarvningen ikke ret meget. Og hvis intet må være forskelligt, hjælper variantoplysningerne ikke den, der skal vælge.

• Definer vareattributter for varevarianter
• Administrer produktvarianter

Jeg vil lige hæfte mig ved ordet får. Vi tilføjer varianten i dag. Næste måned retter en kollega en attribut på hovedvaren. Betyder får så, at varianterne altid følger med fremover? Eller har vi kun beskrevet udgangspunktet? Det er sådan et lille ord, der ret ubemærket kan vokse til en ret stor antagelse.

• Definer vareattributter for varevarianter
• Administrer produktvarianter

Vi har beskrevet udgangspunktet, ikke lovet en løbende synkronisering. På varekortet findes handlingen Update Variant Attributes, som man bevidst kan bruge til at gennemtvinge en synkronisering. Før jeg brugte den på en vare med tilsigtede forskelle, ville jeg kontrollere resultatet på nogle repræsentative varianter. Især én, der stadig følger varen, og én, hvor værdien med vilje er ændret. Dokumentationen fortæller os, at handlingen findes. Den giver os ikke grundlag for at gætte på enhver konsekvens af overskrivning i en bestemt opsætning.

• Definer vareattributter for varevarianter
• Administrer produktvarianter

Så ville jeg tage den tilsigtede forskel med i testen. Ikke kun den nemme variant, hvor alt er ens. Ellers kan vi jo klappe os selv på skulderen over at have opdateret de fælles værdier og overse netop den detalje, der gjorde varianten nyttig. Med vores to overflader er opgaven at holde den fælles beskrivelse korrekt, uden at valgmulighederne igen bliver umulige at skelne fra hinanden.

• Definer vareattributter for varevarianter

Og billedet skal have et lige så klart formål. På variantkortet kan man importere et billede, tage et med kameraet, eksportere det eller slette det. Flisevisninger kan så gøre det lettere at skelne mellem varianter, der ligner hinanden. Jeg ville vælge billeder, der viser den faktiske forskel. Overfladen, formen, eller hvad personen nu skal genkende. Et flot billede af hele produktet, gentaget på hver variant, kan være mindre nyttigt end et ganske enkelt billede, hvor forskellen er tydelig.

• Tilføj billeder til varevarianter for at skelne mellem produktvalg

Det er befriende lidt glamourøst. Det bedste billede er det, der forhindrer mig i at vælge den forkerte overflade. Ikke nødvendigvis det, der skal på forsiden af brochuren. Ville du bruge forbedringen som anledning til at lægge et helt varekatalog om til varianter? Eller bliver vi så lidt for begejstrede for en nyttig mulighed?

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Definer vareattributter for varevarianter

Jeg ville begynde med produkter, hvor det allerede giver mening at bruge varianter. Ændringen forbedrer oplysningerne, der beskriver dem. Den bestemmer ikke hele virksomhedens varestruktur. Vælg et produkt, hvor medarbejderne faktisk tøver mellem mulighederne. Vedligehold de attributter og billeder, der gør en forskel, og undersøg, om valget bliver tydeligere. Så har man et grundlag for at brede det ud. Man undgår at gøre en brugervenlighedsforbedring fra april til en omlægning af hele kataloget, før man ved, om den løser det oprindelige problem.

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Definer vareattributter for varevarianter

Der findes også allerede en indstilling, som kan kræve, at man angiver en variant, når varen har varianter. Den er ikke en del af aprilnyheden, men den er relevant for vores eksempel. Tydelige billeder hjælper personen med at vælge. De sikrer ikke nødvendigvis, at personen overhovedet vælger noget.

• Administrer produktvarianter

Netop. Den eksisterende opsætning kan kræve en variant ved bogføring, når varen har varianter. Og man kan overstyre valget på den enkelte vare. Det er en anden opgave end den, billederne og attributterne løser. Det ene gør valget forståeligt. Det andet kan kræve, at valget faktisk bliver foretaget i det relevante bogføringsforløb. Hvis virksomheden allerede bruger varianter, hænger de to spørgsmål godt sammen: Kan folk genkende den rigtige udgave, og hvor skal udgaven være angivet? Mulighederne behøver ikke være samme funktion for at være nyttige sammen.

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Definer vareattributter for varevarianter
• Administrer produktvarianter

Her kommer endnu en forbedring fra tidligere på året, denne gang på indkøbssiden. Siden april kan man oprette et købstilbud til en kontakt, der endnu ikke er knyttet til en kreditor. Virksomheden kan altså bede en mulig leverandør om en pris, før den opretter kreditoren. Det lyder dejligt ligetil. Alex, hvornår slutter den foreløbige fase, hvor man bare undersøger mulighederne?

• Opret købstilbud til kontakter
• Anmod om tilbud

Ved én af to handlinger: Når man frigiver tilbuddet, eller når man konverterer det til en ordre. Begge handlinger opretter kreditoren ud fra en skabelon. Mens man forbereder forespørgslen, kan kontakten derfor godt forblive en kontakt. Men Frigiv er ikke bare en måde at få styr på tilbuddets status. Den handling passerer grænsen til kreditoroprettelse. Det er den vigtige detalje, før man fortæller indkøbsteamet, at kreditoren altid først bliver oprettet, når de har besluttet at bestille.

• Anmod om tilbud

Det sker altså tidligere, end den pæne overskrift lægger op til. Lad os sige, at jeg sammenligner en mulig ny leverandør med en, vi allerede bruger. Fordelen er, at jeg kan begynde forespørgslen uden at gøre enhver mulighed til en kreditor. Men hvis vi normalt frigiver tilbud med det samme, så påvirker den vane, hvor meget vi faktisk får ud af forbedringen.

• Anmod om tilbud

Præcis. Se derfor på, hvordan forespørgslerne faktisk bliver håndteret, ikke kun på det nye valg af kontakt. Hvornår har indkøberen brug for en kladde? Hvornår bliver den frigivet, og hvorfor? Forbedringen fjerner behovet for en kreditor helt i begyndelsen. Men teamet skal kende det punkt, hvor systemet opretter en. Der er stadig en nyttig besparelse, hvis mange mulige leverandører aldrig kommer så langt. Og når en af dem gør, kan skabelonen give et ensartet udgangspunkt for kreditoren.

• Anmod om tilbud

Så skabelonen løser faktisk en del af arbejdet. Skal indkøberen vælge den hver gang, eller kan Business Central finde frem til, hvilken der passer? Jeg tænker på den person, der bare vil spørge til en leveringsdato. Ikke pludselig overtage ansvaret for, hvordan kreditorerne bliver sat op.

• Anmod om tilbud

Valget bygger på kontaktens oplysninger, blandt andet distrikt, land eller område og kontakttype. Hvis én skabelon passer, kan den anvendes automatisk. Ellers bliver brugeren bedt om at vælge. Derfor skal valgmulighederne være forståelige, og skabelonerne bør gennemgås, før man tager processen i brug. Et tydeligt match kan spare indkøberen for en beslutning, som vedkommende ikke burde improvisere sig frem til. Men at kreditoren bliver oprettet på den måde, beviser ikke, at leverandøren har været igennem virksomhedens godkendelsesproces.

• Anmod om tilbud

Så indkøberens første spørgsmål kan stadig være: Er det her en leverandør, vi måske vil handle med? Opsætningen skal hjælpe med det spørgsmål. Ikke tvinge os til at træffe alle beslutninger om kreditoren, før vi overhovedet har en forespørgsel. Og når vi så vælger at købe, hvad sker der med selve tilbuddet? Jeg vil gerne bevare forbindelsen på ordren, så vi ikke skal gætte os til, hvilken dialog den udsprang af.

• Anmod om tilbud

Handlingen Opret ordre opretter købsordren og fjerner tilbuddet. Tilbudsnummeret følger med over på ordren og fakturaen. Så forbindelsen er dokumenteret, men man skal ikke forvente, at tilbuddet bliver liggende som et uændret, åbent arbejdsdokument ved siden af ordren. Og det er ikke en direkte konvertering fra købstilbud til købsfaktura. Hvis virksomheden har brug for et andet indkøbsforløb, skal det undersøges for sig. Man kan ikke regne med, at alle de næste dokumenttyper kan bruges i stedet for hinanden.

• Anmod om tilbud

Jeg ville begynde med at afprøve én mulig leverandørkontakt, der passer til en skabelon, og én, hvor valget ikke er oplagt. Så får indkøberen set begge veje, før det skal gå stærkt. Det er en lille ændring med en meget genkendelig fordel: Man kan begynde at undersøge et muligt indkøb uden først at lade, som om samarbejdet allerede er længere fremme, end det er.

• Anmod om tilbud

Vi har talt en del om, hvordan mennesker får arbejdet videre. Men hvad sker der, når arbejdet går i stå med en fejl? Den sidste oktobernyhed er AI-hjælp til at optage et snapshot i Business Central niogtyve. Man kan beskrive den situation, der fejler, få en agent til at klargøre optagelsen, genskabe problemet og hente optagelsen til nærmere undersøgelse. Alex, hvad er det nye her? Og hvorfor er sådan et snapshot mere nyttigt end endnu et skærmbillede af fejlen?

• Snapshot-debugging i Business Central
• Nyt og ændret i Business Central 2026 release wave 2 – opdatering 29.0

Det nye er den AI-understøttede måde at få optagelsen på. Ikke selve snapshot-fejlsøgningen. Den underliggende optagemekanisme har eksisteret i flere år. Et skærmbillede viser, hvad brugeren så. Et snapshot kan gemme det optagede kodeforløb og udvalgte variabelværdier, så de kan undersøges bagefter. Udvikleren får dermed noget, der kommer tættere på, hvad der faktisk skete inde i systemet, mens problemet blev genskabt. Og optagelsen behøver ikke standse brugerens arbejde ved hvert optagepunkt, sådan som et almindeligt stoppunkt under fejlsøgning ville gøre.

• Snapshot-debugging i Business Central

Så hvis nogen siger, at det fejlede i går, kan vi ikke på magisk vis hente gårsdagens manglende optagelse. Problemet skal opstå igen, mens optagelsen er klar. Jeg kan godt lide udsigten til en nemmere overlevering til support. Men lad os beholde brugeren i billedet. Hvad ville personen faktisk blive bedt om at gøre i et fornuftigt supportforløb?

• Snapshot-debugging i Business Central

Først aftaler man præcist, hvilken handling der fejler. Hvis vi forestiller os en bogføringsfejl, kan det være et bestemt dokument og den handling, der fremkalder beskeden. Personen med de nødvendige rettigheder klargør optagelsen til den relevante session eller det næste forløb, der passer. Når optagelsen er klar, gentager brugeren den aftalte handling. Bagefter stopper man optagelsen og henter den. Agenten hjælper med at koordinere de trin. Den fjerner ikke behovet for at vide, hvilken fejl man prøver at genskabe, eller om det er forsvarligt at gentage forretningshandlingen.

• Snapshot-debugging i Business Central

Den sidste pointe er vigtig. Det handler ikke bare om at trykke Bogfør igen, indtil computeren fortæller os noget interessant. Brugeren skal stadig vide, hvilken handling der bliver gentaget. Og supportpersonen skal være klar på det rigtige tidspunkt. Kan man lade optagelsen stå parat hele eftermiddagen, mens brugeren finder et ledigt øjeblik?

• Snapshot-debugging i Business Central

Nej. En ventende optagelse udløber, hvis den ikke er blevet knyttet til en session inden for tredive minutter. Når selve optagelsen er begyndt, skal den afsluttes inden for ti minutter. De grænser lægger op til et kort, aftalt forsøg på at genskabe fejlen. Ikke til at lade optagelsen køre som løbende overvågning. I vores eksempel ville jeg have brugeren klar ved det relevante dokument, sikre mig, at optagelsen venter, genskabe den aftalte fejl og hente resultatet. Status er vigtig. At vente, at optage og at have hentet et snapshot er tre forskellige trin. Ikke tre måder at sige, at opgaven er løst.

• Snapshot-debugging i Business Central

Venter, optager, hentet. Den rækkefølge er også god at kende, når man ikke er udvikler. At bede om en optagelse er ikke det samme som at have dokumentationen i hånden. Når filen er hentet, kan udvikleren så undersøge den senere, uden at brugeren skal sidde klar gennem hele fejlsøgningen?

• Snapshot-debugging i Business Central

Ja, og det er en af de nyttige gevinster. Det optagede snapshot kan åbnes til offline undersøgelse i Visual Studio Code. Udvikleren kan gennemgå det optagede forløb i stedet for at bede brugeren gentage det samme, mens alle mulige forklaringer bliver vendt. Optagelsen kan selvfølgelig vise, at der er brug for en ny og mere målrettet optagelse. Men allerede den første overlevering kan indeholde materiale fra selve fejlen. Ikke kun en beskrivelse af den. Det giver et bedre grundlag for det næste spørgsmål.

• Snapshot-debugging i Business Central

Du sagde før, at man får udvalgte variabelværdier med. Hvis optagelsen har en indstilling, der hedder Full, er det så ikke fristende at vælge den hver gang? Så slipper man måske for at bede brugeren prøve igen. Mere information lyder jo umiddelbart fornuftigt, når man endnu ikke ved, hvad fejlen skyldes.

• Snapshot-debugging i Business Central

Det er en rimelig tanke. Men vi skal lige have oversat, hvad Full betyder her. Den indstilling optager mere sammenhæng om metodekald og kildekode for den kode, der må medtages. Det betyder ikke, at alle variabelværdier bliver gemt i hvert eneste øjeblik. Værdier bliver stadig optaget ved snappoints og undtagelser. Snappoint er det lidt klodsede navn for et punkt, hvor optagelsen gemmer tilstanden uden at standse kørslen. Full kan også øge både ressourceforbruget og optagelsens størrelse mærkbart. Derfor er den beregnet til korte, målrettede forløb. Ikke som en standardindstilling, der bare tager det hele med.

• Snapshot-debugging i Business Central

Så mit ønske om at skåne brugeren for endnu en afbrydelse er ikke i sig selv en god grund til en meget større optagelse. Jeg ville hellere bede udvikleren forklare, hvilket ekstra spørgsmål Full skal hjælpe med at besvare. Og hvis en værdi ikke blev optaget på det relevante tidspunkt, gør en AI-forklaring den jo ikke til noget, vi faktisk har observeret.

• Snapshot-debugging i Business Central

Præcis. Spørgsmålet er, hvad optagelsen faktisk giver belæg for. AI-hjælpen kan gøre det nemmere at samle materialet. Men i fejlsøgningen skal man stadig skelne mellem det, man har observeret, og en mulig forklaring. Et forslag til en rettelse er så endnu et skridt. I vores bogføringseksempel kan den optagede fejl måske indsnævre, hvilken del af koden der er relevant. Det hjælper undersøgelsen. Men det beviser ikke i sig selv, at en ændring af en bestemt linje vil løse virksomhedens problem på en sikker måde. Den foreslåede rettelse skal stadig efterprøves.

• Snapshot-debugging i Business Central

Hvem må egentlig klargøre sådan en optagelse? Når man siger, at man bare beskriver problemet for en agent, kan det lyde lige så uformelt som at stille et spørgsmål i et chatvindue. Men her går man jo ind i en Business Central-session og samler materiale fra den.

• Snapshot-debugging i Business Central

Miljøets MCP-funktion skal være slået til. Og den person, der starter forløbet, skal have de dokumenterede rettigheder til snapshot-fejlsøgning og til at tilknytte fejlsøgning. Den sidste rettighed er også nødvendig, når man bruger denne metode på sin egen session. Handlingerne bruger den indloggede persons identitet og rettigheder. Agenten er ikke en genvej uden om adgangskontrollen. For en systemansvarlig er forberedelsen derfor at aftale, hvilke autoriserede supportpersoner der må bruge arbejdsgangen. Og hvordan de koordinerer en gentagelse af fejlen med den person, der sidder med arbejdet.

• Snapshot-debugging i Business Central

Og resultatet skal opbevares et sted, der passer til indholdet. Et skærmbillede af en fejl og en optagelse med kundedata er ikke bare to vedhæftninger af samme slags. Jeg ville nødig have, at en nemmere vej til optagelsen blev til en vane med at lægge alle snapshots i den chat, man tilfældigvis har åben.

• Snapshot-debugging i Business Central

Microsoft advarer udtrykkeligt om, at snapshots kan indeholde private kundedata. De skal håndteres efter de relevante regler og politikker for databeskyttelse og compliance. Og slettes, når der ikke længere er brug for dem. Jeg ville gøre det til en del af selve overleveringen til support. Hvor skal filen ligge? Hvem må undersøge den? Og hvornår kan den fjernes? Så beholder man fordelen ved bedre dokumentation uden at behandle materialet som harmløst, bare fordi det kommer fra et udviklingsværktøj.

• Snapshot-debugging i Business Central

Hvis man allerede har brugt snapshot-fejlsøgning, er fordelen altså ikke et nyt optageformat eller et løfte om en øjeblikkelig rettelse. Det er mindre manuelt arbejde med at starte optagelsen, følge dens status og hente resultatet. For brugeren kan forbedringen være en mere præcis besked. Prøv at genskabe netop denne fejl nu, mens vi er klar til at lære noget af den.

• Snapshot-debugging i Business Central

Ja. Agenten kan klargøre optagelsen, kontrollere status, stoppe den og hente resultatet gennem de understøttede værktøjer. Udvikleren behøver ikke selv koordinere alle de kommandoer. Optagelsen kommer stadig fra den samme snapshot-mekanisme. Den sammenhæng er vigtig. Man forbedrer vejen til materiale, som kan undersøges. Man erstatter ikke materialet med en velformuleret fortælling om, hvad der måske er sket. Jeg ville bedømme funktionen på, om den får den rigtige fejl med i en optagelse, der kan undersøges. Og om det kræver mindre besvær for de mennesker, der er involveret.

• Snapshot-debugging i Business Central

Det bliver vores sidste pointe i dag. Det, jeg godt kan lide ved dagens forbedringer, er, hvor tæt de ligger på selve arbejdet. En kollega kan lettere tage over på en post. Det bliver tydeligere, hvilken variant man skal vælge. Og support får et bedre grundlag at undersøge. Med salgsagenterne er det interessante heller ikke, hvor mange man kan have. Det er, hvilken slags arbejde hver enkelt skal hjælpe videre. I afsnitsnoterne finder du de direkte kilder, udgivelsesdatoerne og de tekniske detaljer om det, du vil undersøge nærmere. Tak, fordi du lyttede til Central Perspectives fra ITrators. Vi høres ved.

• Tilføj billeder til varevarianter for at skelne mellem produktvalg
• Opsætning af Sales Order Agent
• Funktionsdetaljer for Business Central 2026 release wave 2
• Snapshot-debugging i Business Central