En Business Central-podcast fra ITrators
Et nyhedsshow om Business Central. Emma og Alex gennemgår, hvad der er ændret, og hvad det betyder i praksis.
Lyt på dansk eller engelsk, og find afsnitsnoter og direkte kilder til hvert afsnit.
Værter, manuskripter og stemmer er AI-genererede.
Ingen afsnit matcher disse filtre. Prøv et andet emne, eller ryd filtrene.
Det afsnit, du lytter til, forbliver synligt nedenfor, selv når det ikke matcher filtrene.
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Adgang til revisionsfelter og AI-hjælp til fejloptagelse i BC29 samt nyttige ændringer fra tidligere i 2026 inden for salgsagenter, produktvarianter og indkøbstilbud.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Forbedret kvalitetskontrol, udledningsformler på indkøb og planlægning uden lagervarekort, fulgt af EDI-prøveversion og AL-tests fra kommandolinjen.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Emma og Alex følger sen fragt ind i vareomkostningerne, skelner mellem fejl i opgaver og ufærdigt arbejde, kontrollerer finansrapporter, undersøger udgående kald og finder et nyttigt standardsprog til dokumenter.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Eksisterende API'er, omkostningsfordeling, produktionskalendere, fortrydelse af direkte leveringer og overvågning af vigtige felter—med tydelig forskel på nyt i BC29 og nyttige eksisterende muligheder.
Topics & notes
Business Central-nyheder om rapportlayouts, overgangen til .NET 10, gennemgang af agentændringer og rykkertekster. Emma og Alex undersøger også en forhåndsversion af nummerering ved selvfakturering og beslutningerne bag opsætningen.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Business Central-nyheder og nyttige ændringer med udgangspunkt i arbejdet: match leverandørfakturaer på tværs af ordrer, godkend lager- og planlægningskladder, og vælg hvor langt fakturering af kundekontrakter skal køre. Emma og Alex ser også frem mod udfasningen af en rapporterings-API og undersøger en lille funktion til at skjule skærmfelter. Med klar skelnen mellem forårets funktioner, oktobers ændringer og det kommende.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Praktiske Business Central-nyheder og nyttige funktioner: det nye Copilot-panel i preview, valgene bag forslag til bankafstemning, bogføringsperioder der følger arbejdsdatoen, og instruktioner der skal nå frem til underleverandøren. Til sidst en lille opdagelse blandt senest brugte værdier i opslag. Tydelige forbehold om tilgængelighed og spørgsmål, der er værd at afprøve i virksomhedens egen opsætning.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Emma og Alex undersøger, hvornår strukturerede udlægsrapporter er nok uden en agent, hvad gentagen brug af Åbn i Excel fortæller om en opgave, og hvad en Fabric-spejling ikke løser alene. Desuden ser de på bevidst kopiering af Outlook-kontakter og billedvisning, der gør det lettere at blive i arbejdet.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Ekstern lagring af vedhæftninger, enklere felttilknytning til Dataverse, direkte vareoverflytninger, overblik over rettigheder og genveje til analyser. Der er også en kort besked om licensnøgler til on-premises.
Topics & notes
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Planlagte appudrulninger, nyttig fakturaautomatisering, genbrugeligt rapportdesign, MCP-adgang, indeksafvejninger og praktiske opgraderingskontroller.
Topics & notes
Emner fra Central Perspectives
Find et emne, og læs videre i afsnitsnoterne.
52 emner
Ingen emner matcher. Prøv en anden søgning eller kategori.
En fælles liste hjælper teamet med at finde den relevante person og det relevante tidspunkt BC29 gør systemets revisionsfelter tilgængelige på analysefaner og ved tilpasning af sider i profiler.
Rutinehenvendelser og kommercielle undtagelser behøver ikke følge samme vej Flere Sales Order Agent-instanser pr. virksomhed blev generelt tilgængelige i juli 2026; det er ikke en oktoberlancering.
Forskellen hører til ved det valg, brugeren faktisk foretager Attributter og billeder på varevarianter blev generelt tilgængelige i april 2026.
En tidlig leverandørhenvendelse kan begynde med en kontakt Siden april 2026 kan et købstilbud bruge en kontakt, som endnu ikke er knyttet til en leverandør.
En fælles liste hjælper teamet med at finde den relevante person og det relevante tidspunkt BC29 gør systemets revisionsfelter tilgængelige på analysefaner og ved tilpasning af sider i profiler.
Et modtaget parti kræver en registreret kontrolbeslutning. Kvalitetsstyring er ikke i sig selv en oktoberlancering. Grundudvidelsen blev generelt tilgængelig i april 2026.
Indkøb ønsker ensartede udledningsberegninger på dokumenterne. BC29-nyheden er formelberegning på købsdokumenter, ikke den første bæredygtighedskladde.
En vare har planlægningsparametre, men intet lagervarekort på lokationen. Et eksisterende lagervarekort leverer planlægningsparametrene. Uden et kort vælger lokationens politik mellem Minimal, Item Card og Don’t Plan.
Virksomheden ønsker ordreudveksling gennem sin opsætning af elektroniske dokumenter. EDI-udveksling er offentlig prøveversion i BC29, ikke generelt tilgængelig.
Teknisk uddybning — Et hosted job melder, at testkommandoen blev kørt. AL-kommandolinjeværktøjet kan køre serverens testcodeunits med al runtests uden en MCP-server.
En særskilt fragtfaktura kommer efter den oprindelige købsmodtagelse. Brug et varegebyr, der knyttes til den relevante bogførte modtagelse.
En baggrundsopgave med bogføring og udskrivning viser Fejl. Microsoft beskriver en printerdialog, som kræver en person: bilaget kan blive bogført, udskrivningen forbliver ufærdig, og opgaven ender efter timeout i Fejl.
Den rapportansvarlige skal forklare en forskel til finansbogholderiet. Undersøg manglende eller dobbelte konti, formelreferencer, fortegn og udeladte rækker. En ny finanskonto kan eksistere uden at være med i en tilpasset rapport.
En udvidelse forsøger at kalde en ekstern tjeneste. Udgående HttpClient-kald kræver tilladelse for hver udvidelse, også biblioteksapps. Fejlen kan opstå, før den eksterne tjeneste modtager kaldet.
Kollegaer bruger forskellige sprog i brugerfladen, men betjener de samme lokale kunder. Standardsprogkode i Firmaoplysninger angiver et fælles standardsprog for kundevendte dokumenter, uafhængigt af brugerens sprog i brugerfladen.
Virksomheden vil bruge en bestemt oplysning eller handling fra Business Central i et andet system. API Overview viser publicerede API-sider, forespørgsler og codeunits i det aktuelle miljø, også fra installerede udvidelser.
En fælles omkostning skal fordeles mellem dele af virksomheden. Fordelingskonti fordeler beløb fra dokumenter og finanskladdelinjer. En fast fordeling består, indtil opsætningen ændres.
Planlæggeren skal kunne se, om kapaciteten er beregnet langt nok frem. Calendar Entries Available Until viser den senest beregnede dato på arbejds- og maskincentre.
En leverandør sender direkte til kunden, mens købs- og salgsdokumenterne er knyttet sammen.
Virksomheden vil opdage udvalgte vigtige ændringer uden ukritisk at registrere alt. Monitor Field Change Setup kan logge udvalgte ændringer eller sende e-mail.
Business Central 29 udvider livscyklusstyringen til layouts fra Business Central, kundespecifikke udvidelser og AppSource-apps. Selve statusfunktionen er ældre. Kun layouts med status Approved kan vælges på rapportens anmodningsside.
Microsoft annoncerede 19. oktober 2026 overgangen fra .NET 8 til .NET 10 for understøttede Business Central-versioner. Microsoft står for overgangen online. Den kan indebære intern migrering i det konfigurerede vedligeholdelsesvindue.
Gennemgangslinjen i BC29 viser agentens ændringer på understøttede dokument- og kortsider. Tallet i Review (N) angiver felter, som agenter har ændret. Feltdetaljerne viser ophav, begrundelse og sikkerhed.
Den nye tekstfunktion til rykkerbetingelser bliver obligatorisk i BC29 og kan ikke længere deaktiveres via Funktionsstyring. Gennemgå både mailen og den vedhæftede rykker for det relevante rykkerniveau.
Selvfakturering er en aftalt proces, hvor køberen opretter fakturaen på leverandørens vegne. Udvidelsen med leverandørspecifik nummerering er public preview i BC29.
Match bilagene uden at forveksle en faktura med dokumentation for modtagelse. Hent ordrelinjer kan knytte en fakturalinje til flere egnede indkøbsordre- eller modtagelseslinjer.
Et fastholdt sæt lager- eller planlægningsforslag giver godkenderen noget konkret at tage stilling til. Konfigurerede godkendelser gælder kladder i vare-, lageroptællings-, afgangs- og forbrugskladder samt planlægnings- og indkøbskladder.
Forslag, kladdedokumenter og bogføring er separate valg ved fakturering af kundekontrakter. Fakturering af kundekontrakter kan automatiseres i trin: opret forslag, opret dokumenter til kontrol, eller tilføj et særskilt bogføringstrin.
Find brug af betaudgaven af Finance reports API før den planlagte fjernelse i version 30.
Nyttig skjulning under skærmdeling er ikke en ny adgangsbegrænsning. MaskType kan skjule værdien i et understøttet felt, indtil brugeren vælger at vise den.
Det nye panel inde i Business Central kan hjælpe med at forstå den post, man allerede arbejder med. Den nyttige forskel er mellem at forklare og at udføre en handling.
Det interessante er den post, der bliver tilbage efter den almindelige matchning. Pointen er ikke at overlade hele bankafstemningen til AI. Den almindelige automatiske matchning kører først.
Datoformler kan spare de tilbagevendende ændringer i tilladte bogføringsperioder. Men den dato, formlerne følger, er afgørende for den kontrol, virksomheden ønsker.
For en produktionsvirksomhed handler overdragelsen om instruktionerne til den konkrete operation. Det er mere præcist end blot at lægge en fil et sted, andre kan finde den.
Når næste indtastning skal bruge en post, man lige har valgt, kan en personlig liste med seneste værdier være mere direkte end en ny søgning. Nogle opslagsfelter har visningerne Recent og Search.
Udlægshåndtering er en produktionsklar previewfunktion med supplerende previewvilkår. Generel tilgængelighed er ikke bekræftet. Afklar først, om virksomheden har brug for strukturerede manuelle rapporter eller indlæsning af kvitteringer.
Overvågning af brugen af Åbn i Excel er generelt tilgængelig i BC29. Arbejdsgangene til eksport og redigering nedenfor fandtes allerede og er ikke nye oktoberhandlinger. Begynd med at spørge, hvad medarbejderen skal bruge regnearket til.
Privat preview ved kontrollen den 18. oktober 2026. Offentlig preview forventes, men har ingen bekræftet dato eller åben adgang. Start med analysespørgsmålet og de BC-regnskaber og tabeller, der skal bruges.
Den opdaterede arbejdsgang gælder fra BC28 og har en udgivelsesdato i april 2026. Den er ikke lanceret i oktober. Hver bruger starter selv kopieringen til sine egne Microsoft 365-kontakter. Vælg omfanget med Choose contacts i guiden.
Direkte billedvisning er generelt tilgængelig i BC29 fra oktober 2026. Billedvisning er tilføjelsen i BC29; PDF-visning fandtes allerede. Åbn en understøttet vedhæftning i BC’s fremviser, og hent kun en kopi, hvis der er behov for det.
Standardfunktion, generelt tilgængelig fra 1. april 2026, ikke først udgivet i oktober.
Nye felter er generelt tilgængelige fra april og omtales også i BC29. Den bredere guide er fortsat markeret som preview. Et nyt Dataverse-felt kan føjes til en eksisterende integrationstilknytning uden at ændre proxyudvidelsen.
Direkte overflytninger fra lokationer med lagerstyring er generelt tilgængelige i BC29 fra oktober 2026. Oktoberændringen udvider direkte overførsler til understøttede afsenderlokationer med lagerhåndtering.
Permissions Overview er en nyttig funktion fra udgivelsesbølge 1 i 2026, ikke en helt ny oktoberfunktion. Permissions Overview samler rettighedssæt fra apps og udvidelser i én oversigt.
Målrettet besked til on-premises og Dual Use Rights, gældende fra 1. oktober 2026. Fra 1. oktober bruger nye on-premises-udgivelser licensnøgleversionen 28+ til Business Central 28 og nyere.
En ny mulighed i BC29 og udgivelsesbølge 2 i 2026. Et bogmærke til en analysevisning åbner siden eller forespørgslen direkte i analysetilstand med den valgte visning. Bookmark view kræver, at personalisering er aktiveret.
En tænkt opdatering af en udvidelse uden for arbejdstiden indleder samtalen. I Business Central online kan en eksisterende per-tenant-udvidelse målrettes det næste opdateringsvindue eller en kommende mindre eller større miljøopdatering.
Fakturaeksemplerne og de foreslåede evalueringsmål er tænkte, ikke afprøvede kunderesultater. Afprøvningen er kun tilgængelig i produktion, når agenten ikke tidligere har været aktiveret, og omfatter op til 50 fakturaer.
En fælles sidefod er et eksempel på dokumentvedligeholdelse, ikke et løfte om at konvertere alle layouts. Den nye dokumentoplevelse kombinerer et Word-layout med undertypen Body med genbrugelige temaer og sidehoved/sidefod.
Det foreslåede spørgsmål om saldi eller forfaldne fakturaer er en tænkt evaluering, ikke en udført forespørgsel. Start med understøttet API-dækning, en snæver konfiguration og en bruger med passende rettigheder.
En tænkt stille uge er ikke bevis for, at et indeks til månedsafslutning er værdiløst. Indeks kan forbedre læsning, men kræver lagerplads og vedligeholdelse ved skrivning.
En fungerende skærm er ikke bevis for, at en ekstern integrationskontrakt stadig fungerer. BC29 fjerner publicering af Microsofts UI-sider som SOAP-endpoints, ikke alle SOAP-tjenester.
Business Central-nyheder om rapportlayouts, overgangen til .NET 10, gennemgang af agentændringer og rykkertekster. Emma og Alex undersøger også en forhåndsversion af nummerering ved selvfakturering og beslutningerne bag opsætningen.
En Business Central-podcast fra ITrators med AI-genererede samtaler mellem Emma og Alex.
Lyden kunne ikke afspilles. Prøv at hente afsnittet.
Samtalen i korte træk
Styr tilgængeligheden uden at forveksle en status med en godkendelsesproces.
Læs afsnitsnoterSkeln mellem Microsofts onlinemigrering og de afhængigheder, virksomhedens egne opdateringstests skal dække.
Læs afsnitsnoterBrug gennemgang på dokumentet til at undersøge agentens ændringer, og vælg derefter den handling, der passer til opgaven.
Læs afsnitsnoterKontrollér tekster og sprog på rykkerniveauerne, før I vælger, hvor langt automatiseringen skal gå.
Læs afsnitsnoterUndersøg forhåndsversionen af leverandørens nummerserie uden at forveksle den med den bogførte købsfakturas eget nummer.
Læs afsnitsnoterTransskription
Transskriptionen følger det godkendte manuskript. Tidskoderne angiver målte scenestarter, ikke præcise tidspunkter for de enkelte replikker eller emneskift.
Styr tilgængeligheden uden at forveksle en status med en godkendelsesproces.
Læs samtalen 7:51ScenestartSkeln mellem Microsofts onlinemigrering og de afhængigheder, virksomhedens egne opdateringstests skal dække.
Læs samtalen 12:02ScenestartBrug gennemgang på dokumentet til at undersøge agentens ændringer, og vælg derefter den handling, der passer til opgaven.
Læs samtalen 18:19ScenestartKontrollér tekster og sprog på rykkerniveauerne, før I vælger, hvor langt automatiseringen skal gå.
Læs samtalen 25:55ScenestartUndersøg forhåndsversionen af leverandørens nummerserie uden at forveksle den med den bogførte købsfakturas eget nummer.
Læs samtalenScenestart 0:03
Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg hedder Emma, og med mig er Alex. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dette afsnit ser vi på forandringer, der kan være lette at overse: det tekniske fundament under systemet, valgene på en rapport og de små beskeder, som skal hjælpe et menneske med at gøre arbejdet færdigt. Vi skelner undervejs mellem det, Microsoft har leveret, og det, der stadig er på vej. Lad os komme i gang.
Hvilket fakturalayout skal medarbejderen vælge? Det er vores første spørgsmål. Forestil dig tre næsten ens muligheder, hvor virksomheden ikke længere vil bruge den ene. I Business Central 29 kan virksomheden også styre status for layout, der følger med systemet eller en udvidelse. Selve statusfunktionen fandtes allerede. Alex, kan vi nu tage den uønskede mulighed ud af valget uden at ændre den udvidelse, den kom fra?
Det kan gøre selve valget enklere. På rapportens anmodningsside er det kun layout med status Approved, altså godkendt, der kan vælges. Kladder, layout til godkendelse og udfasede layout er ikke med i valget. Virksomheden kan derfor udfase den gamle variant i stedet for at bede alle huske, at den med det næsten rigtige navn er forkert. Kommer layoutet fra en udvidelse, gemmes statusændringen som en tilsidesættelse. Den oprindelige layoutfil i udvidelsen bliver ikke ændret.
Så slipper navnet måske også for at ende med tre udråbstegn og et BRUG IKKE. Men lad os tage den modsatte situation. Det nye layout er færdigt, og kollegaen kan stadig ikke vælge det. Nye brugerdefinerede layout starter jo som kladder. Kan vi altså stå med et helt velfungerende design, hvor det blot er status, der holder det ude af listen?
Ja, og der ville jeg begynde med status, før nogen bruger tid på at bygge filen om. At et layout findes, er ikke det samme som, at det er frigivet til almindeligt valg. Overleveringen bør derfor rumme to ting: Vi har kontrolleret designet, og vi har besluttet at gøre det tilgængeligt. I dit eksempel kan godkendelsen løse problemet med tilgængelighed. Den reparerer ikke nødvendigvis noget, for vi har endnu ikke fundet en fejl i selve designet.
Ordet godkendelse kan godt få forventningerne til at vokse. En økonomiansvarlig kunne høre status afventer godkendelse og forestille sig en opgave i indbakken, som en anden person skal behandle. Dokumentationen beskriver statusvalgene, ikke hele sådan et godkendelsesforløb. Hvad ville du aftale omkring funktionen, uden at en nyttig lille forbedring bliver til et stort projekt om arbejdsprocesser?
En tydelig ansvarlig og en aftalt kontrol kan være rigeligt. Forestil dig, at den, der laver fakturalayoutet, afleverer et eksempel til den kollega, som har ansvar for kundedokumenterne. Først efter kontrollen skifter status. Det er vores forslag til en arbejdsgang, ikke en automatisk proces, som feltet lover. Har virksomheden krav om adskilte godkendere, fast routing eller en bestemt dokumentation af beslutningen, skal det undersøges særskilt. Jeg ville hverken tage de funktioner for givet eller gøre dem til et krav hos alle.
Hvis vi vender tilbage til medarbejderens valg, er færre muligheder jo ikke altid bedre. Virksomheden kan have brug for to fakturalayout til forskellige modtagere, selv om kun det ene lige er redesignet. Jeg vil ikke have, at oprydningen fjerner et nyttigt layout, bare fordi det er ældre. Hvad afgør, hvilke muligheder medarbejderen skal beholde?
Det arbejde, layoutet stadig skal løse. I din situation ville jeg lade begge relevante varianter være godkendt og gøre formålet tydeligt for den, der vælger. Det er den overflødige mulighed, vi skal udfase, ikke automatisk den ældste. Kommer den fra en udvidelse, kan virksomheden bruge statusændringen uden at ændre den leverede fil. Målet er et valg, der er til at forstå, ikke færrest mulige layout. Din anden modtager er netop en grund til ikke at rydde for hårdt op.
Der er også mærkningen Obsolete, som nogle allerede kender. Den kan lyde som endnu en måde at sige udfaset på. Men Microsoft beskriver den som et signal om, at layoutet muligvis bliver fjernet senere. Hvis jeg sidder og skal vælge en rapport her og nu, hvad skal jeg så især holde adskilt?
Retired er den status, der tager layoutet ud af valget på anmodningssiden. Obsolete fortæller noget andet om dets fremtid, og for layout fra udvidelser sættes den mærkning i AL-koden. Derfor ville jeg bruge forskellige ord i overleveringen. At virksomheden ikke længere vil have medarbejderne til at vælge et layout, er en driftsbeslutning. At udgiveren varsler mulig fjernelse senere, er information om produktets levetid. Det ene kan give anledning til det andet, men indstillingerne er ikke ens.
Lad os beholde de to relevante layout og ændre behovet lidt. Den ene modtager har nu brug for en anden instruktion på fakturaen. Økonomiafdelingen er ellers tilfreds med det layout, der fulgte med udvidelsen. De vil bare have den ene tekst ændret, ikke bestille et helt nyt design. Det hjælper jo ikke at ændre, om layoutet kan vælges, når det er selve indholdet, der skal være anderledes. Skal de så tilbage til udgiveren, eller kan de tage udgangspunkt i den fil, de allerede har?
De kan bruge det leverede layout som udgangspunkt for en brugerdefineret kopi. Vejledningen siger udtrykkeligt, at man ikke kan ændre eller erstatte et layout fra en udvidelse direkte. Vælger man at redigere det, får man i stedet tilbudt at arbejde på en kopi. Den kan tilpasses. Det er en eksisterende mulighed, ikke endnu en nyhed i version 29. I dit eksempel løser kopien behovet for andet indhold. Statusændringen løser derimod spørgsmålet om, hvorvidt det leverede layout skal være tilgængeligt i valget. Den skriver ikke den nye instruktion ind på fakturaen.
Så ville jeg give kopien et navn, der fortæller, hvilken modtager den er til. Ikke bare ny faktura. Ellers har vi genskabt problemet med flere næsten rigtige muligheder. Jeg ville også efterlade en kort forklaring på den ændrede instruktion til den næste, der får ansvar for dokumenterne. Vedkommende skal kunne se, at forskellen er tilsigtet, og hvorfor den er vigtig. Især hvis nogen om et halvt år foreslår at gå tilbage til det leverede layout for at gøre opsætningen enklere.
Den forklaring gør det muligt at forenkle med åbne øjne. Jeg ville aftale, hvem der har ansvar for instruktionen til modtageren, og hvem der vedligeholder kopien. Vi skal ikke regne med, at udgiveren overtager ansvaret for vores ændring, eller love, at kopien automatisk følger med, når udvidelsen ændres. Og når kopien er klar, gælder status stadig: Et nyt brugerdefineret layout starter som kladde og skal godkendes, før det kan vælges. Medarbejderen skal ende med en tydelig, tilsigtet mulighed, ikke et ufærdigt forsøg ved siden af originalen.
Jeg synes især, det er en god afgrænsning, at virksomheden ikke skal vedligeholde et ændret design bare for at skjule en uønsket valgmulighed. Men hvad sker der, næste gang udvidelsen bliver opdateret? Kan vi ud fra dokumentationen love, at statusændringen følger uændret med, eller er det noget, virksomhedens egen opdateringstest skal afklare?
Vi ved, at layoutfilen er uændret, og at status gemmes som en tilsidesættelse. Vejledningen lover ikke, hvordan enhver udvidelsesopdatering opfører sig, så jeg ville kontrollere valgmulighederne efter en opdatering. Og vi taler om rapportens anmodningsside, ikke om at blokere alle automatiske eller specialbyggede rapportkørsler. For medarbejderen bør resultatet være enkelt: De nødvendige layout er med på listen, og den uønskede mulighed er ikke længere med.
Scenestart 7:51
Næste spørgsmål er, hvem der skal forberede sig på en ændring under motorhjelmen. Den 19. oktober meddelte Microsoft, at understøttede Business Central-versioner går fra .NET 8 til .NET 10, både online og ved lokal installation. De fleste kunder forventes ikke at skulle ændre deres applikationer alene af den grund. Hvem har så en opgave her, Alex, og hvem kan fortsætte arbejdet som hidtil?
Begynd hos dem, der har ansvar for miljøet og de tekniske afhængigheder, frem for at bede alle forberede en omskrivning. Runtime er en del af det softwarefundament, applikationen kører på. Medarbejderen, der opretter en ordre, får ikke af den grund en ny måde at oprette ordrer på. Den, der vedligeholder egne .NET-komponenter, udviklingsværktøjer eller automatiske test, får derimod et konkret spørgsmål om kompatibilitet. Opgaven bør følge de afhængigheder, virksomheden faktisk har, ikke fordeles til alle afdelinger.
For onlinekunderne står Microsoft for overgangen. Det tager jo en væsentlig del af arbejdet væk. Meddelelsen siger dog også, at der kan indgå en intern flytning af miljøet i det konfigurerede vedligeholdelsesvindue. Så her er spørgsmålet vel ikke, hvem der skal installere .NET, men om det valgte tidsrum stadig passer til virksomhedens hverdag?
Ja, især hvis arbejdstiderne har ændret sig, siden vinduet blev valgt. Microsoft anbefaler at begrænse den potentielle påvirkning. Men det er forberedelse, ikke en varsling af et bestemt nedbrud. Meddelelsen fortæller heller ikke, om netop jeres miljø allerede er flyttet. Jeg ville bekræfte miljøets faktiske status frem for at udlede afslutning eller driftsforstyrrelser af overskriften.
For lokale installationer bliver versionsnummeret mere præcist. Microsoft nævner kumulativ opdatering 27.12 til Business Central 27 og 28.6 til Business Central 28. Det er altså ikke helt nok at svare, at vi kører version 28. Hvad vil du have afklaret, før du kan sige, at grundlaget for opdateringen er på plads?
Den præcise kumulative opdatering, der kører nu, og kravene til den opdatering, man vil installere. Hovedversionen bliver for grov en oplysning, når runtime-understøttelsen ændres inden for samme versionsfamilie. Den miljøansvarlige skal forbinde de to oplysninger, før afhængighederne ændres. Kører testmiljøet en anden opdatering end produktionen, ville jeg også notere det. Ellers kan en vellykket test se betryggende ud uden at besvare netop det kompatibilitetsspørgsmål, som opdateringen stiller.
Lad os tage et tænkt udviklingsteam, hvor brugerne er på onlineversionen. Microsoft håndterer altså produktionsmiljøets overgang, men udviklerne bygger og tester en udvidelse i containere. Hører det team stadig til blandt dem, der skal gennemgå deres egne værktøjer? De kan jo med god grund sige, at de ikke driver nogen produktionsserver.
Ja. Onlineproduktion gør ikke deres eget udviklingsmiljø til Microsofts opgave. Vejledningen nævner netop containerimages, AL-værktøjer og automatiske forløb til at bygge og teste. For det team ville jeg først finde ud af, hvilken runtime det valgte image forventer, og om værktøjer og afhængigheder passer til den. Derefter køre det normale build og de relevante test. Det er mere nyttigt end at opdatere alt på én gang, og det giver et konkret udgangspunkt, hvis noget fejler.
Hvis virksomheden så spørger, hvad der bliver hurtigere mandag morgen, har vi ikke et tal at give dem. Meddelelsen indeholder ikke en målt hastighedsgevinst. Jeg synes stadig, den er nyttig, fordi den retter opmærksomheden mod dem, der ejer de tekniske afhængigheder, uden samtidig at bede alle andre forberede sig på en anderledes applikation.
Jeg ville bede den teknisk ansvarlige vise, hvilken relevant handling der blev testet, ikke blot om login virkede. Ellers kan en sjældent brugt komponent blive overset. Fejler kontrollen, så gem fejloplysningerne og undersøg den afhængighed. Tidspunktet alene beviser ikke, at .NET er årsagen. Det giver teamet et konkret næste skridt uden at gøre runtime til forklaring på alle problemer.
Scenestart 12:02
Forestil dig nu en købsfaktura, som en agent har hjulpet med at udfylde. Medarbejderen skal vurdere de foreslåede værdier, før gennemgangen afsluttes. I Business Central 29 er det generelt tilgængeligt at gøre det direkte på dokumentsiden, hvor en bjælke viser agentens ændringer. Hvor skal vores medarbejder begynde på den faktura, Alex?
Med de værdier, agenten har ændret. Listen over forslag fører hen til felterne, hvor medarbejderen kan se agentens begrundelse, og hvor sikker den var. Lad os sige, at én værdi virker uvant. Så kan hun åbne detaljerne og holde forslaget op mod det køb, fakturaen vedrører, mens dokumentet stadig er foran hende. Det er den nyttige forskel: Hun kan undersøge den enkelte værdi i sin sammenhæng frem for at behandle hele fakturaen som ét uforklaret resultat.
På den samme faktura fortæller tallet ved Review, hvor mange felter agenten har ændret. Står der seks, er det seks felter, ikke seks fakturaer eller seks opgaver. Det hjælper os med at finde ændringerne, men ikke med at sætte tid på kontrollen. Én af de seks værdier kan jo have langt større betydning end resten.
Så lad os blive ved den uvante værdi frem for at skynde os gennem alle seks. Jeg ville spørge: Hvorfor foreslog agenten den, og passer den begrundelse til denne faktura? Forslagets detaljer hjælper med det første spørgsmål. Selve købet skal besvare det andet. En forklaring, der lyder rimelig, er nyttig at have, men den er ikke i sig selv bevis for, at værdien er rigtig.
Orange betyder lavere sikkerhed og kalder ret tydeligt på ekstra opmærksomhed. Jeg tænker mere på den diskrete hvide markering ved siden af. På en travl dag kan hvid hurtigt komme til at betyde allerede kontrolleret i hovedet. Hvis begrundelsen for en værdi eksempelvis er leverandørens historik, hvad vil du så spørge om, før den accepteres på dagens dokument?
Om dagens køb faktisk ligner den historik, forslaget bygger på. Forestil dig, at leverandøren normalt leverer én slags ydelse, men denne faktura vedrører noget andet. Så ville jeg holde forslaget op mod bilaget. Begrundelsen gør antagelsen synlig, og det er nyttigt, også når vi ender med at afvise værdien. Jeg ville rette den, hvis det er nødvendigt, frem for at lade en hvid markering overbevise mig om, at netop denne undtagelse ikke kan forekomme.
Lad os sige, at medarbejderen nu har kontrolleret værdierne og rettet den, som ikke passede til købet. Nu skal hun afslutte gennemgangen. Både Done og Dismiss kan få siden til at se mere ryddelig ud, men de betyder ikke det samme. Hvad siger hun til systemet, når hun vælger Done frem for bare at lukke bjælken?
Done afslutter gennemgangen, registrerer navn og dato, rydder forslagsmarkeringerne og lader agentens opgave fortsætte. Dismiss skjuler bjælken og opdaterer siden, så markeringerne forsvinder. Det er ikke den dokumenterede handling til at afslutte gennemgangen. Jeg ville derfor begynde oplæringen med beslutningen: Er jeg færdig med kontrollen, eller fjerner jeg blot visningen? Og ingen af de to knapper skal forklares som en generel besked om, at en faktura nu er bogført. Det videre forløb afhænger af opgaven.
Senere åbner en kollega den samme faktura. Markeringerne er væk, men kollegaen ved ikke, om medarbejderen valgte Done eller Dismiss. Hun har brug for at vide, hvor arbejdet står, ikke bare se en ryddelig side. Hvor kan hun finde historikken for agentens arbejde med netop den faktura?
I den relevante agents opgave i opgaveruden. Tidslinjen viser de trin, agenten har gennemført, og hvor den har brug for input. Dér kan kollegaen undersøge, hvor langt arbejdet er, frem for at gætte ud fra de manglende markeringer. Vi har altså to indgange til den samme faktura: Dokumentet hjælper med at vurdere værdierne, mens opgaven viser forløbet i agentens arbejde.
Den overlevering afhænger så af kollegaens adgang. Microsoft siger, at bjælken kan vise, at en agent har påvirket data, selv om personen ikke har tilladelse til at bruge agenten. Knapperne til at åbne dens opgave er i så fald skjult. Kollegaen kan altså se, hvem der har påvirket fakturaen, uden at kunne åbne den historik, hun har brug for.
Så ville jeg inddrage en person med den nødvendige agentadgang til at undersøge opgaven. Kollegaens spørgsmål er, om noget på denne faktura stadig kræver opmærksomhed. Det er ikke i sig selv en grund til at give alle flere rettigheder. At kunne se agentpåvirkede værdier på dokumentet og at kunne åbne opgaven er forskellige muligheder. Den forskel skal overleveringen tage højde for.
Tilbage hos den medarbejder, der gennemgår fakturaen, er der en sidste kontrol, før hun vælger Done. Agentens ændringer er ikke det eneste, hun kan have brug for at se. De almindelige sidemeddelelser er skjult, mens gennemgangsbjælken vises, men kan åbnes via Show other notifications. Hun kan derfor være færdig med de seks felter og stadig have en særskilt advarsel om dokumentet, som bør læses.
Du kan åbne meddelelserne uden at forlade gennemgangen. At lukke en af dem afslutter ikke agentkontrollen, og Done eller Confirm kræver ikke, at alle meddelelser er håndteret. En forretningsvalidering kan dog stadig blokere en handling. Derfor ville jeg læse den relevante advarsel nu, ikke gå ud fra, at den afsluttede feltgennemgang også har taget sig af den.
På den faktura, vi begyndte med, er resultatet altså ret konkret. Medarbejderen kan forklare, hvorfor den uvante værdi ikke passede til købet, rette den og bevidst afslutte gennemgangen. Hun har ikke bare ryddet op på skærmen. Er det den forskel, gennemgangen direkte på siden skal gøre for hende?
Ja. Værdien, begrundelsen og oplysningerne om købet kan vurderes sammen. Når medarbejderen er tilfreds, bruger hun Done til at registrere, at gennemgangen er afsluttet, så opgaven kan fortsætte. Skal kollegaen senere forstå agentens forløb, ved hun, at hun skal se på opgaven frem for at slutte noget ud fra sidens udseende. Fordelen er mindre søgen efter sammenhængen, ikke at medarbejderens vurdering er blevet overflødig.
Scenestart 18:19
Nu til noget, kunderne uden for virksomheden læser: rykkere. Nyheden i Business Central 29 er ikke, at man pludselig kan sende en rykker på mail. Det er, at de nye kommunikationstekster til rykkerbetingelser er obligatoriske og ikke længere kan slås fra i funktionsstyringen. Hvad bør økonomiafdelingen se på, før den næste rykkerkørsel, Alex?
På det, kunden faktisk modtager: både mailens tekst og den vedhæftede rykker. Jeg ville begynde med de rykkerbetingelser, virksomheden bruger, og derefter se på teksterne for de relevante niveauer og sprog. Obligatorisk betyder her, at tekstfunktionen indgår i version 29 uden en slukknap. Det betyder ikke, at Business Central har valgt virksomhedens rykkerpolitik eller er begyndt at sende mails. Forberedelsen er først og fremmest at sikre, at den tilsigtede kommunikation kommer med ud i dokumenterne.
Opsætningen giver mulighed for fælles tekster på tværs af niveauer eller særlige tekster til det enkelte niveau. Forestil dig en virksomhed, hvor den første rykker skal være en venlig påmindelse, mens den næste skal være tydeligere om, hvad kunden skal gøre. Jeg ville ikke have en kontant rykker i bilaget og en mail, der lyder, som om det er første henvendelse.
Derfor ville jeg læse dem sammen. For hvert niveau: Hvad skal kunden forstå, og hvad skal kunden gøre nu? Så kan vi se, om både mail og bilag understøtter det. De behøver ikke gentage hinanden ordret. Mailen kan være den korte indledning, mens bilaget rummer detaljerne. Men peger de på forskellige trin i dialogen, bliver kunden nødt til at fortolke en modsigelse, som virksomheden kunne have fjernet, før noget blev sendt.
Men før vi skriver den mere kontante tekst til niveau to, skal vi vel vide, om det faktisk er niveau to, kunden er nået til? Lad os tage én kunde med én forfalden faktura. En medarbejder i økonomiafdelingen siger, at hun allerede har mailet kunden to gange, og nu må beskeden gerne være tydeligere. Det siger noget om deres kontakt. Men er antallet af mails nok til at fortælle os, hvilket rykkerniveau Business Central vælger, næste gang der oprettes en rykker?
Nej, ikke i sig selv. Den relevante historik i systemet opstår, når en rykker bliver udstedt. Niveauet registreres på rykkerposter, som er knyttet til kundens debitorposter. Ved en ny rykker undersøger Business Central historikken på de åbne debitorposter, finder det højeste niveau og bruger betingelserne fra det næste. Det er eksisterende rykkerfunktionalitet, ikke en ny måde at optrappe rykkere på i version 29. For fakturaen i dit eksempel ville jeg derfor se på de udstedte rykkere. To mails og en ny tekst med overskriften anden rykker fortæller os ikke alene, hvilken tekst næste dokument kommer til at bruge.
Lad os sige, at vi har undersøgt historikken, og kunden nu er nået til det højeste niveau, virksomheden har sat op. Økonomiafdelingen har kaldt beskeden sidste påmindelse. Det læser jeg som et løfte om forløbet, ikke bare som en overskrift med lidt mere alvor. Hvis fakturaen stadig ikke bliver betalt, betyder det sidste opsatte niveau så, at kunden ikke kan få den samme sidste påmindelse en gang til?
Nej. Opretter man flere rykkere, end der er defineret niveauer, bruges betingelserne fra det højeste niveau igen. Hvor mange der kan oprettes, begrænses af feltet Max. No. of Reminders i rykkerbetingelserne. Det højeste opsatte niveau er altså ikke nødvendigvis den sidste rykker, virksomheden kan oprette. Har det niveau sin egen tekst, ville jeg læse den med gentagelsen i baghovedet. Er beskeden stadig sand, hvis kunden får den igen? En opsætning med tre niveauer og en overskrift, der siger sidste påmindelse, er ikke i sig selv en aftale om, hvad virksomheden gør derefter.
Jeg ville nødig være kunden, der får en sidste påmindelse og så endnu en sidste påmindelse ugen efter. Beløbet kan være helt rigtigt, men ordene mister troværdighed. Hellere en tydelig anmodning og en måde at få afklaret spørgsmål på end en dramatisk overskrift, som bare blev stående i skabelonen. Hvis sidste virkelig er det, virksomheden mener, skal de ansvarlige også være enige om, hvad der skal ske bagefter.
Og den beslutning ligger hos den økonomiansvarlige, ikke i overskriften. For vores kunde ville jeg lægge historikken over udstedte rykkere sammen med det næste niveau og den mail og det bilag, der hører til. Kan det højeste niveau blive brugt igen, skal teksten kunne holde til det, eller forløbet skal afklares. Derefter skal anmodningen hænge sammen begge steder. Vi undersøger ikke længere kun, om beskeden lyder venlig eller bestemt. Vi undersøger, om kunden får en retvisende besked om, hvor i forløbet virksomheden er.
Sprogene handler også om mere end korrektur. Microsoft siger, at mailtekster og bilagstekster skal have samme sprog repræsenteret. Hvis betingelserne har flere rykkerniveauer, kan manglende overensstemmelse forhindre automatikken i at tilpasse beskeden korrekt. En engelsk mailtekst sammen med kun danske bilagstekster er altså ikke en færdig engelsksproget kundekommunikation, selv om den ene opsætningsside ser fin ud.
Jeg ville sammenligne sprogene i oversigten over kommunikation og derefter kontrollere den kombination, kunden skal modtage. I dit eksempel betyder det engelsk begge steder, ikke blot en engelsk oversættelse et sted i systemet. Og jeg ville tage et senere rykkerniveau med. En korrekt første påmindelse viser ikke, at teksten til den næste er koblet rigtigt på. Vi behøver ikke afprøve alle tænkelige kombinationer, men de sprog og niveauer, virksomheden faktisk sender, skal være dækket.
Hvis teksterne ser rigtige ud i opsætningen, men prøvemailen stadig viser noget andet, hjælper det næppe at skrive dem om. Vejledningen nævner også rapportvalget og det valgte layout til mailens indhold. Er det dér, du ville følge sporet videre?
Ja. Den gemte tekst er én del, og det valgte outputlayout er en anden. Vejledningen beskriver, at mailteksten indsættes i den rapport, der er valgt til mailens indhold. Den forbindelse ville jeg undersøge, før nogen retter en tekst, som allerede er rigtig. Og bilaget skal med i kontrollen. At mailen ser korrekt ud, fortæller ikke i sig selv, om den vedhæftede rykker også gør det.
Jeg ville altså bede om kundens udgave, ikke et skærmbillede af indstillingerne. Åbn mailen, læs bilaget, og spørg: Ville jeg forstå, hvad virksomheden vil have mig til at gøre?
Og hvis jeg mener, at saldoen er forkert, ved jeg så, hvordan jeg kan få det afklaret? Beskeden behøver ikke være lang, men den skal være gennemtænkt. I en tænkt gennemgang ville jeg lade den ansvarlige for kundekommunikation læse outputtet sammen med den økonomiansvarlige. Den ene ser efter, om anmodningen er forståelig; den anden efter, om indhold og trin er de tilsigtede. En teknisk korrekt udfyldt skabelon kan stadig være en dårlig henvendelse til en kunde.
Hvis virksomheden allerede bruger kommunikationsteksterne, og beskederne fungerer, skal den så gøre mere? Obligatorisk kan lyde som en deadline for nyt arbejde. Men vi behøver vel ikke omskrive en god rykkertekst bare for at markere versionsskiftet?
Nej. Kontrollér outputtet i forbindelse med opdateringen, og behold det, der virker. Obligatoriske tekster kræver ikke en ny rykkerproces. De eksisterende handlinger opret, udsted og send er stadig forskellige: Udstedelse har konsekvenser for debitorposterne, og afsendelse kræver opsat mail. Men vores spørgsmål her er beskeden, ikke hvor meget der skal automatiseres. Får kunden den tilsigtede anmodning i både mail og bilag, på de rykkerniveauer og sprog virksomheden bruger?
Scenestart 25:55
Den sidste opdagelse er smallere, men løser et konkret spørgsmål i regnskabet. Business Central 29 har leverandørspecifikke nummerserier til selvfakturering som offentlig preview, ikke som generelt tilgængelig funktion. Selve grundfunktionen til selvfakturering var allerede generelt tilgængelig i opdatering 28.2 fra juni. Før vi taler om numrene: Hvem er det, der laver fakturaen ved selvfakturering?
Køberen opretter en købsfaktura på leverandørens vegne under en aftale om selvfakturering. Det er ikke bare køberen, der beslutter, at det er besværligt at vente på en faktura. Med udvidelsen i preview kan leverandøren få sin egen nummerserie til den proces. Bruger virksomheden allerede en aftalt ordning, kan adskilte serier gøre dokumenterne lettere at skelne mellem leverandørerne. Men først bør man spørge, om den opdeling hjælper ordningen, ikke blot om der er kommet et nyt felt at udfylde.
Og hvilket nummer taler vi så om? Fakturanummer kan dække over mere end ét felt. Vejledningen siger, at serien udfylder leverandørfakturanummeret, mens den bogførte købsfaktura stadig har sit normale nummer. To kolleger kan altså pege på samme dokument og alligevel mene noget forskelligt, når de siger nummeret.
Ja, feltet er afgørende. Forestil dig, at den selvfakturerede faktura får leverandørens reference fra den særlige serie. Business Central tildeler stadig den bogførte købsfaktura sit eget nummer fra den normale serie til bogførte fakturaer. Man erstatter altså ikke hele virksomhedens interne fakturanummerering med leverandørvise serier. I en afprøvning ville jeg se på begge identifikatorer bagefter. Ellers kan teamet kigge på det uændrede interne nummer og tro, at den leverandørspecifikke opsætning slet ikke virkede.
Skal hver leverandør med selvfakturering så have sin egen serie? Eller kan virksomheden beholde en fælles, hvor det stadig giver bedst mening?
Virksomheden kan bruge en fælles nummerserie, når leverandørens eget felt er tomt. Den særlige selvfaktureringsserie på leverandøren har forrang; ellers bruges serien til bogført selvfakturering fra købsopsætningen. Er begge felter tomme, kan den selvfakturerede faktura ikke bogføres. Den fælles serie er derfor en reel mulighed, ikke nødvendigvis mangelfuld opsætning. Jeg ville vælge efter den aftalte proces og afprøve den forventede reference både for en leverandør med egen serie og, hvis det er relevant, en der bruger den fælles.
Hvornår ville du se efter den reference? Hvis jeg åbner en købsfaktura, der endnu ikke er bogført, og ser, at den er markeret som selvfaktureret, kunne jeg let tro, at kontrollen var klaret. Men det er vel to forskellige spørgsmål, om dokumentet er genkendt som selvfakturering, og om det endelige nummer er tildelt. Hvilket tidspunkt beskriver vejledningen?
Det sker ved bogføring. Opretter man købsfakturaen til den opsatte leverandør, enten direkte eller fra en købsordre, markeres den som selvfaktureret. Vejledningen placerer selve tildelingen af leverandørfakturanummeret fra den særlige serie ved bogføringen. Et kig på kladden er derfor ikke nok til at konkludere, at den endelige nummerering er rigtig. I den afgrænsede afprøvning ville jeg kontrollere referencen på det bogførte dokument sammen med virksomhedens særskilte interne fakturanummer. Markeringen i kladden og nummeret bagefter dokumenterer ikke det samme.
Forestil dig så, at køberen og den samme leverandør senere aftaler at stoppe selvfaktureringen. Fremover skal leverandøren igen sende fakturaerne. Den kollega, der passer leverandørkortet, fjerner den særlige nummerserie og tror, at opsætningen til selvfakturering dermed er væk. Men vi har lige sagt, at et tomt felt kan betyde, at den fælles serie bliver brugt i stedet. Så den lille oprydning kan ende med at betyde noget helt andet end det, kollegaen havde til hensigt.
Ja. At tømme nummerseriefeltet slår ikke aftaleindstillingen fra. Er selvfakturering stadig aktiveret, kan den fælles serie fortsat levere nummeret. Microsoft beskriver rækkefølgen sådan: Ryd Self-Billing Invoice Nos., før Self-Billing Agreement slås fra på leverandøren. Det er to forskellige ændringer i opsætningen. Og ingen af dem erstatter køberens og leverandørens aftale om det nye forløb. Jeg ville derfor beskrive hensigten, før kortet bliver ændret: Skal leverandøren bare over på den fælles serie, eller skal virksomheden holde op med at fakturere på leverandørens vegne?
Jeg ville også spørge, om der allerede ligger fakturaer under udarbejdelse, når ordningen ændres. Ellers kan indkøb sidde og vente på en faktura fra leverandøren, mens økonomiafdelingen stadig er i gang med at lave den på leverandørens vegne. Det hjælper at kende den aftalte skæringsdato, men nogen skal stadig finde det arbejde, som ikke er afsluttet, og tage stilling til det.
Det er den overlevering, jeg ville have de to afdelinger til at aftale. Vejledningen angiver rækkefølgen for ændringerne på leverandøren, men ikke hvad der sker med enhver faktura, som allerede er undervejs. Jeg ville hverken antage, at et flueben annullerer de dokumenter, eller at bogførte referencer bliver skrevet om. Find de uafsluttede fakturaer, og afklar, hvem der skal udstede hver af dem. Så understøtter opsætningen en kendt aftale, i stedet for at indkøb og økonomi hver især gætter på, hvem der laver den næste faktura.
Så længe aftalen om selvfakturering er aktiv, gælder der også en vigtig begrænsning for dokumentforløbet. Microsoft skriver, at virksomheden ikke kan modtage indgående e-dokumenter til kreditorprocessen for leverandører med en selvfaktureringsaftale. Hvis virksomheden allerede modtager elektroniske leverandørfakturaer, skal det undersøges, før selvfakturering bliver behandlet som en uskyldig præference for nummerering.
Så kommer dokumentforløbet før testen af nummereringen. Forventer virksomheden fortsat e-dokumenter til kreditorprocessen fra den leverandør, skal konflikten i arbejdsgangen afklares først. De ansvarlige for aftalen og indkøbet må beslutte, hvordan forløbet skal være. En pæn nummerserie kan ikke løse det for dem, og en ændring i opsætningen bør ikke ubemærket træffe beslutningen.
En dansk detalje i vejledningen er, at bogføring kan oprette digitale bilag, når selvfakturering er aktiveret. Det gælder den danske version og er ikke et løfte på tværs af lande. Og selv om opsætningen er beskrevet grundigt, står den leverandørspecifikke nummerering stadig som offentlig preview. En vejledning gør ikke i sig selv en previewfunktion generelt tilgængelig.
Har virksomheden behovet, er næste nyttige skridt en afgrænset afprøvning i den relevante version og landeversion, efter at aftalen og dokumentforløbet er forstået. Kontrollér leverandørreferencen, det interne bogførte nummer og det færdige dokument. Et flueben eller et rapportlayout dokumenterer ikke i sig selv, at alle juridiske krav er opfyldt. Bruger virksomheden slet ikke selvfakturering, ligger der heller ikke et skjult projekt her. Det er en bestemt mulighed at kende, når behovet opstår, ikke en ny standard alle skal indføre.
I dag har vi set på nogle små, men vigtige forskelle: at styre et udvidelseslayouts tilgængelighed uden at ændre filen, at afslutte en agentgennemgang bevidst og at kontrollere den besked, kunden faktisk modtager. Vi har også skilt Microsofts runtimeovergang fra det kompatibilitetsarbejde, et teknisk team stadig kan have. Ikke alt kræver et nyt projekt, og de leverandørspecifikke selvfaktureringsnumre er fortsat i preview. Det bedste næste skridt er det, der besvarer et reelt spørgsmål i jeres egen opsætning. Tak, fordi du lyttede til Central Perspectives fra ITrators.
Afsnitsnoter
Business Central 29 udvider livscyklusstyringen til layouts fra Business Central, kundespecifikke udvidelser og AppSource-apps. Selve statusfunktionen er ældre.
Kun layouts med status Approved kan vælges på rapportens anmodningsside. Draft, Pending Approval og Retired kan ikke vælges. Nye brugerdefinerede layouts starter som Draft. Design og kontrol skal derfor følges af en bevidst beslutning om, hvornår layoutet bliver tilgængeligt. Kontrollér gerne anmodningssiden med den relevante bruger og en repræsentativ rapport. En ændret status er ikke i sig selv bevis for, at alle måder at sende rapporten på er testet.
BC29: udvidelsen er generelt tilgængelig. Den grundlæggende livscyklusfunktion findes i BC28.1 fra maj 2026.
Styring af tilgængelighed er noget andet end at redigere en layoutfil fra en udvidelse.
En ændring af status på et layout fra en udvidelse gemmes som en overstyring, mens det oprindelige layout forbliver uændret. Administratorer kan ændre status på ét eller flere layouts. Retired er desuden noget andet end at markere et layout som forældet. Sidstnævnte signalerer mulig senere fjernelse og defineres i AL for udvidelsers layouts. Dokumentationen fastslår ikke en automatisk godkendelsesrute med flere personer, en komplet ændringshistorik eller en garanti for overstyringer ved enhver opdatering af udvidelsen. Kun brugerdefinerede layouts kan ændres eller erstattes direkte. Ved redigering af et layout fra en udvidelse tilbydes en kopi, som kan tilpasses. Det er eksisterende funktionalitet, ikke en ny redigeringsfunktion i BC29. Brug statusoverstyring, når behovet er tilgængelighed, og en brugerdefineret kopi, når behovet er et andet indhold. Vejledningen lover ikke, at en tilpasset kopi automatisk følger fremtidige ændringer i udvidelsen.
Driftsvejledningen er kontrolleret 20. oktober 2026; omfanget gælder BC29.
Microsoft annoncerede 19. oktober 2026 overgangen fra .NET 8 til .NET 10 for understøttede Business Central-versioner.
Microsoft står for overgangen online. Den kan indebære intern migrering i det konfigurerede vedligeholdelsesvindue. Annonceringen beviser ikke, at et bestemt miljø allerede er flyttet. For de fleste kunder forventes der ikke applikationsændringer alene på grund af det nye runtime. Undersøg virksomhedens faktiske afhængigheder og almindelige opdateringstests frem for at starte en omskrivning ud fra overskriften. Placér ansvaret for vedligeholdelsesvinduet tydeligt uden at kalde det en ny funktion til udrulning af apps.
Annonceret 19. oktober 2026. On-premises indføres .NET 10 i BC27 og BC28 med henholdsvis CU27.12 og CU28.6.
Kravet til runtime afhænger af den præcise Business Central-version og kumulative opdatering.
Kontrollér .NET-interoperabilitet og egne komponenter, AL-værktøjer, automatiske bygge- og testforløb samt container-images mod miljøets krav. Et vellykket build viser ikke alene, at den konkrete integration eller testvej stadig fungerer korrekt. Brug almindelig opdateringsvalidering med et repræsentativt forretningsresultat. Der er ikke udført en kundespecifik kompatibilitetstest eller målt en ydelsesforbedring som led i denne gennemgang.
Versions- og CU-afhængig vejledning kontrolleret 20. oktober 2026.
Gennemgangslinjen i BC29 viser agentens ændringer på understøttede dokument- og kortsider.
Tallet i Review (N) angiver felter, som agenter har ændret. Feltdetaljerne viser ophav, begrundelse og sikkerhed. Orange fortjener omhyggelig kontrol, men hvid er ikke et kvalitetsstempel. Done afslutter gennemgangen, registrerer hvem der gennemgik dokumentet og hvornår, fjerner forslagsmarkeringerne og lader opgaven fortsætte. Dismiss skjuler gennemgangslinjen og fjerner markeringerne efter opdatering af siden. Det er ikke den dokumenterede afslutningshandling. Ingen af betegnelserne betyder generelt, at et økonomidokument er bogført.
Gennemgang direkte på siden er generelt tilgængelig i BC29. Driftsvejledningen er opdateret 2. oktober 2026.
Adgang til agentens handlinger er ikke det samme som at kunne se dens indflydelse på data.
Gennemgangslinjen kan vises uden rettighed til at bruge agenten. Knapper til at åbne opgaven er så skjult. Almindelige sidemeddelelser og agentgennemgang er adskilt: en vist eller afvist meddelelse afslutter ikke gennemgangen. Forretningsvalidering kan stadig blokere en senere handling. Brug den valgte agents opgaverude til tidslinjen eller et blokeret trin. Instruktioner til et trin gemmes ikke til senere opgaver. Stop er endnu en særskilt handling, og stoppede opgaver kan ikke genstartes. De dokumenterede hovedsidetyper er Card, Document, List Plus og Worksheet, ikke enhver indlejret visning.
Driftsvejledningen er kontrolleret 20. oktober 2026. Agentens konkrete adgangs- og proceskrav gælder fortsat.
Den nye tekstfunktion til rykkerbetingelser bliver obligatorisk i BC29 og kan ikke længere deaktiveres via Funktionsstyring.
Gennemgå både mailen og den vedhæftede rykker for det relevante rykkerniveau. Tekster kan være fælles for niveauerne eller tilpasses hvert niveau. Sprogene for vedhæftningstekster og mailtekster skal passe sammen. Forskellige sprogopsætninger kan forhindre den ønskede tilpasning. Overview communications hjælper med at sammenligne dem. At funktionen bliver obligatorisk, opretter ikke en mailkonto, beslutter ikke virksomhedens rykkerpolitik og slår ikke automatisk afsendelse til.
Obligatorisk i BC29. Selve kommunikationsfunktionen er ældre; vejledningen er dateret 10. juni 2025.
Create, Issue og Send er forskellige rykkerhandlinger, der kan køres samlet eller hver for sig.
Udstedelse har konsekvenser i debitorposterne og er ikke det samme som afsendelse. Afsendelse kræver mailopsætning. Opgavekøer styrer gentagelsen. Manual kører én gang ved start, mens ikke-manuelle planer fortsætter, indtil de sættes på pause. Se på log, stop ved fejl, gentagen afsendelse, fakturavedhæftninger, rapportvalg og Email Body Layout Name. En foreslået test bør sammenligne den faktiske mail og vedhæftning med det ønskede budskab og kontrollere, hvilke senere handlinger der stopper efter en fejl. Automatiseringsværktøjerne er eksisterende funktioner, ikke nye oktoberfunktioner. Rykkerniveauer følger også eksisterende regler: Ved udstedelse registreres niveauet på rykkerposter, der er knyttet til debitorposter. En senere rykker undersøger historikken for åbne poster og bruger niveauet efter det højeste fundne. Oprettes der flere rykkere, end der er defineret niveauer, genbruges betingelserne fra det højeste niveau inden for grænsen i Max. No of Reminders. Endnu en mail er derfor ikke i sig selv bevis på et nyt niveau. Kontrollér, at en formulering som sidste rykker passer til det faktiske forløb. Det er en driftsmæssig kontrol af kommunikationen, ikke juridisk rådgivning eller en ny eskaleringsfunktion i BC29.
Eksisterende automatiseringsvejledning: 7. april 2026; vejledning om rykkerniveauer: 10. juni 2025. Begge kontrolleret 20. oktober 2026; ingen af funktionerne er nye i BC29.
Selvfakturering er en aftalt proces, hvor køberen opretter fakturaen på leverandørens vegne.
Udvidelsen med leverandørspecifik nummerering er public preview i BC29. Serien udfylder Vendor Invoice No., mens den bogførte købsfakturas eget No. stadig kommer fra den normale Posted Invoice Nos. Konfigurér aftalen og de relevante serier bevidst. Leverandørens serie har forrang for den fælles Posted Self-Billing Inv. Nos. Er begge tomme, blokeres bogføring. At udvidelsen står i en aktuel brugervejledning, gør den ikke generelt tilgængelig.
Grundlæggende selvfakturering: BC28.2 / juni 2026 GA. Leverandørspecifik serie: BC29 public preview.
Nummerering skal vurderes sammen med den aftalte leverandørproces og lokaliseringen.
Ryd leverandørens nummerserie, før Self-Billing Agreement deaktiveres. Det dokumenterede layout indeholder køber-, leverandør-, moms- og fakturaoplysninger. I den danske version kan bogføring oprette digitale bilag, når selvfakturering er aktiveret. Den lokale detalje er ikke en global garanti for lovmedholdelighed. Virksomheden kan ikke modtage indgående e-dokumenter til kreditorprocessen for leverandører med en selvfaktureringsaftale. Kontrollér det, før de to indgående dokumentforløb kombineres. Der hævdes hverken juridisk tilstrækkelighed eller en testet virksomhedsopsætning. Det er ikke nok blot at rydde leverandørens serie for at deaktivere aftalen. Mens aftalen er aktiveret, kan den fælles selvfaktureringsserie stadig bruges. Er begge serier tomme, blokeres bogføring. Nye købsfakturaer til den konfigurerede leverandør markeres som selvfakturerede, uanset om de oprettes direkte eller fra en købsordre. Vejledningen tildeler Vendor Invoice No. fra leverandørens serie ved bogføring, så en ikke-bogført kladde alene beviser ikke den endelige nummerering. Det fastslår ikke, hvad der sker med eksisterende åbne dokumenter, eller at historiske, bogførte referencer kan ændres.
Leverandørvejledningens metadatadato: 26. august 2026; kontrolleret 20. oktober 2026. Leverandørspecifik nummerering er fortsat public preview i BC29.
Her finder I kilderne bag samtalen. Afsnitsnoterne uddyber forbehold og betydningen i praksis.
Business Central is transitioning to .NET 10 (19 October 2026)
Get started creating report layouts
Supervise Agent Activities in Business Central
Optional Features Now Mandatory
Set Up Reminder Terms and Levels
Automate reminders in collections
What's New or Changed in Business Central 2026 release wave 2 - Update 29.0
