Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg er Emma, og Alex er med mig. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag ser vi på tre ændringer i Business Central 29, der hjælper med at få ufærdigt arbejde, rettelser og rapporter det rigtige sted hen. Vi tager også en søgefunktion, der ikke er helt så ny, som den kan lyde, og en nyttig måde at sende leveringsoplysninger på uden at vente på fakturaen. Det gennemgående spørgsmål er egentlig enkelt: Hvad sker der bagefter, og hvem kan bruge resultatet? Lad os komme i gang.

• Update 29.0 for Business Central 2026 release wave 2
• Adgang til Report Inbox-poster gennem API

Vi begynder i produktionen. Business Central 29 tilføjer inventory picks og put-aways til underleverandørprocessen. Microsoft angiver forbedringen som generelt tilgængelig. Selve underleverandørproduktionen er ældre: En virksomhed kan få en anden virksomhed til at udføre en del af produktionen. Men det ufærdige produkt skal stadig transporteres derhen og nogle gange tilbage igen, før det er færdigt. Alex, hvad tilfører den nye lagerhåndtering til den fysiske rejse?

• Update 29.0 for Business Central 2026 release wave 2
• Opsætning af underleverandørarbejde

Den knytter den fysiske håndtering tættere til det produktionsforløb, man allerede registrerer. Forestil dig en virksomhed, der fremstiller en metalkonstruktion. Den udfører selv første operation, sender den halvfærdige konstruktion ud til en specialbehandling og får den tilbage til den sidste operation. Den, der står for flytningen, har brug for mere end at vide, at der findes et underleverandørkøb. Hvad bliver sendt? Hvor skal det hen? Og hvad kommer tilbage? Lageraktiviteterne giver den håndtering et dokumenteret forløb. Den afgørende forskel er, at det, vi flytter, stadig kan være arbejde under udførelse og ikke en færdig vare på lager.

• Update 29.0 for Business Central 2026 release wave 2
• Overfør igangværende arbejde mellem underleverandører

Den sidste forskel vil jeg gerne holde fast i. Man kan pege på konstruktionen ude på en palle. Den findes jo i høj grad. Alligevel siger vi, at det ikke er en almindelig vareflytning. Hvad registrerer Business Central så i stedet? Den, der leder efter den, skal helst have andet end et filosofisk svar.

• Overfør igangværende arbejde mellem underleverandører

Flytningen får sine egne poster for arbejde under udførelse, altså WIP. Transferdokumenterne følger det ufærdige hovedprodukt og dets placering, men bevægelsen opretter ikke almindelige vareposter, værdiposter eller lagerstedsposter. Svaret på, hvor konstruktionen er, findes derfor i underleverandørprocessens WIP-poster og ikke i en lagerbeholdning, der lader som om produktionen er afsluttet. Ellers kunne nogen tolke en manglende almindelig varebevægelse som en levering, ingen har registreret. Her kan det netop være den tilsigtede bogføringsgrænse. Den fysiske rejse er registreret; den bliver bare ikke behandlet som færdigt output.

• Overfør igangværende arbejde mellem underleverandører

Så hjemkomsten fra specialbehandlingen giver ikke automatisk flere færdigvarer på lager. I vores eksempel mangler virksomhedens egen sidste operation jo stadig. Men lad os ændre én ting: Hvad hvis underleverandøren udfører den sidste operation? Samme lastbil, samme varemodtagelse, men et ret andet resultat?

• Lagerlægninger og pluk ved underleverandørarbejde

Ja, og den ændring skal være tydelig, når man tilrettelægger forløbet. Ved sidste operation kan læg-på-lager-aktiviteten bogføre fysisk produktionsoutput og kapacitet. En mellemliggende operation giver ikke den fysiske lagerbogføring. Lagerhandlingen hænger altså sammen med operationens placering i ruten, ikke bare med om en palle er kommet ind ad døren. Jeg ville gennemgå begge situationer med dem, der har ansvar for produktion og varemodtagelse. Forventer modtagelsen flere færdigvarer ved hver hjemkomst, vil mellemtrinnet overraske dem, selv om systemet gør præcis det rigtige.

• Lagerlægninger og pluk ved underleverandørarbejde

Og så gemmer der sig en lille fælde i navnene. Business Central har både inventory picks og put-aways og warehouse picks og put-aways. De navne ligger tæt nok på hinanden til hurtigt at blive til bare pluk og læg-på-lager i et møde. Betyder forbedringen, at alle de dokumenttyper nu kan bruges til arbejdet under udførelse?

• Overfør igangværende arbejde mellem underleverandører

Nej. Lige dér er de fulde navne faktisk besværet værd. WIP-processen understøtter inventory picks og put-aways samt lagerleverancer og lagermodtagelser. Men den opretter ikke warehouse pick- eller warehouse put-away-dokumenter. Det er forskellige arbejdsgange, ikke udskiftelige betegnelser. Hvis virksomheden bruger mere detaljerede lagerprocesser, skal det dokumenterede WIP-forløb holdes op mod den faktiske arbejdsgang. Det er en nyttig ny mulighed, men man skal ikke love varemodtagelsen, at samtlige kendte lagertrin nu bare kan bruges på ufærdig produktion.

• Overfør igangværende arbejde mellem underleverandører

Lad os blive hos varemodtagelsen. Konstruktionen sendes ud, er nogle dage hos specialisten og kommer hjem til sidste operation. Jeg ville gerne kunne skelne mellem, om den er undervejs, eller om den faktisk er nået frem. Er det her, en transitlokation gør nytte, frem for bare at være endnu en kode, nogen skal vedligeholde?

• Overfør igangværende arbejde mellem underleverandører

Ja, og valget påvirker også, hvilken håndtering af hjemkomsten der understøttes. Ruter med transitlokation understøtter lagerhåndtering i begge retninger. Ved direkte afsendelse og modtagelse understøttes indgående lagerhåndtering ikke på returen. Den særskilte bogføringsmetode Direct Transfer understøttes heller ikke til WIP. Jeg ville derfor ikke vælge den løsning, der ser kortest ud, alene for at fjerne et bogføringstrin. Begynd med den faktiske transport og kravene til modtagelsen, og vælg så en understøttet rute. Modtagelsens behov kan afgøre opsætningen, før vi overhovedet begynder at tælle klik.

• Overfør igangværende arbejde mellem underleverandører

Det ændrer min første indskydelse. Færre trin lyder godt, indtil det fjernede trin var det, varemodtagelsen havde brug for. Hvad så hvis virksomheden skal kunne kende hver enkelt konstruktion, mens den er ude? En placering og et antal fortæller jo ikke, hvilken serienummermærket enhed der er kommet tilbage.

• Overfør igangværende arbejde mellem underleverandører

Det krav skal undersøges særskilt, for WIP-transferlinjer understøtter ikke serie- eller lotnumre. De giver heller ikke reservationer eller udbud og efterspørgsel i planlægningen. Registreringen af WIP-bevægelsen er nyttig, men erstatter ikke alle lagerkontroller. Sporing af det færdige produktionsoutput er noget andet; begrænsningen for WIP må ikke overføres til alt det, der bliver produceret. For din individuelt identificerede konstruktion ville jeg beskrive præcis, hvor identiteten skal bevares under den eksterne operation, og afklare hvordan det sikres, før forløbet tages i brug. At det rigtige antal ankommer, er ikke tilstrækkeligt til netop det behov.

• Lagerlægninger og pluk ved underleverandørarbejde
• Overfør igangværende arbejde mellem underleverandører

I nogle virksomheder ligger der også andet på lastbilen: Komponenter, som specialisten skal bruge til arbejdet med konstruktionen. Indtil nu har vi fulgt det halvfærdige hovedprodukt. Jeg vil ikke have, at nogen hører begrænsningerne for WIP og tror, at de også gælder alle komponenter, der sendes til underleverandøren. Har de to bevægelser forskellige opgaver i systemet?

• Håndtér komponenter ved underleverandørproduktion

Ja. Hovedproduktet er det produkt, der er på vej gennem produktionen. Komponenterne er materialer, som bruges i den produktion, og forsyningen af dem har sine egne valgmuligheder. Underleverandøren kan levere en komponent, virksomheden kan have egne materialer liggende hos underleverandøren til forbrug, eller den kan overføre komponenter til en bestemt ordre. De valg svarer på, hvem der leverer materialerne, og hvordan de når frem til operationen. WIP-flytningen svarer på, hvor det ufærdige produkt er. De kan godt følges fysisk uden at blive samme bogføringsproces. Begrænsningen på reservationer gælder altså WIP-flytningen. Den beskriver ikke hele komponentforsyningen.

• Overfør igangværende arbejde mellem underleverandører
• Håndtér komponenter ved underleverandørproduktion

Så en enkelt instruktion om at sende til underleverandøren kan gemme på to spørgsmål. Er den ufærdige konstruktion nået frem, og har de materialerne til at arbejde på den? Hvis virksomheden allerede har komponenter liggende hos specialisten, behøver man måske ikke sende en ny kasse med hver konstruktion. Men nogen skal stadig sørge for, at den beholdning ikke slipper op.

• Håndtér komponenter ved underleverandørproduktion

Netop. Har virksomheden sit eget konsignationslager hos underleverandøren, er genopfyldningen stadig virksomhedens ansvar. Det er noget andet end, at leverandøren leverer komponenten, og noget andet end at overføre mængden til en bestemt ordre. For vores konstruktion ville jeg gøre de to ansvarsområder tydelige: Hvem bekræfter, at det ufærdige produkt er ankommet, og hvem sikrer, at komponenterne er til rådighed? Modtagelsesregistreringen for konstruktionen besvarer kun det første spørgsmål. Derfor ville jeg tegne den faktiske materialestrøm, før opsætningen vælges. To kasser på samme palle kan godt være udtryk for to forskellige ansvarsområder.

• Håndtér komponenter ved underleverandørproduktion

Der er altså en god anvendelse uden at kalde det et komplet sporbarhedssystem. Inden vi slipper konstruktionen: Hvad skal være på plads i forvejen? Jeg ville nødig have, at nogen hører ny plukfunktion og forventer en knap, som selv har styr på underleverandør, produktionsrute og lager.

• Opsætning af underleverandørarbejde

Microsofts Subcontracting-udvidelse og produktionsopsætningen er nødvendige. Underleverandøren skal være knyttet korrekt til leverandør, arbejdscenter og lokation, og produktionsruten skal beskrive den eksterne operation rigtigt. Der findes assisteret opsætning, men det er hjælp til konfiguration, ikke dokumentation for, at virksomhedens arbejdsgang er klar. Jeg ville gennemgå én almindelig tur og én besværlig hjemkomst før ibrugtagning. Åbne WIP-transferordrer forhindrer desuden, at produktionsordren afsluttes. De ufærdige flytninger får dermed en konsekvens: Nogen skal afklare dem, i stedet for at lukke produktionen og glemme den del af rejsen, der stadig står åben.

• Overfør igangværende arbejde mellem underleverandører
• Opsætning af underleverandørarbejde

Så har produktionsholdet en konkret grund til at se på de ufærdige flytninger før afslutning. Hvor kan de faktisk se dem? Jeg vil gerne have kontrollen ind i afslutningen af ordren, frem for i et særskilt regneark, der tilfældigvis ved, hvor konstruktionen tog hen. Og hvis registreringen stadig viser noget ude, kan en oprydning så bare nulstille det?

• Overfør igangværende arbejde mellem underleverandører

De kan åbne underleverandørproduktionens WIP-poster fra produktionsordren, og rutelinjerne viser mængder hos underleverandøren og under transport. Spørgsmålet bliver dermed placeret ved det arbejde, der skal afsluttes. Der findes også valgfri oprydning i WIP-mængder ved afslutning af produktionen; den opretter udlignende reguleringer af resterende mængder. Jeg ville først bruge den, når det fysiske forløb er afklaret. En udligningspost fortæller ikke, om konstruktionen kom hjem, blev kasseret eller stadig kræver handling. Rækkefølgen er at få rede på arbejdet, afklare bevægelsesregistreringerne og derefter afslutte med de passende reguleringer. En nulsaldo skal afspejle et udfald, man faktisk forstår.

• Overfør igangværende arbejde mellem underleverandører

Så får forbedringen en helt praktisk form. Varemodtagelsen kan arbejde med den ufærdige konstruktion, produktionen kan følge dens placering, og afslutningen af ordren bygger på en ordentlig fysisk afklaring. Jeg ville begynde med den fælles rejse: Vis begge hold det samme eksempel, og aftal hvad hver overlevering betyder. Gevinsten er størst, når de kan svare på, hvor arbejdet er, uden at skulle genskabe hele turen fra beskeder.

• Update 29.0 for Business Central 2026 release wave 2
• Overfør igangværende arbejde mellem underleverandører

Så til en anden slags uafsluttet arbejde: Et bogført tal, som viser sig at være forkert. Business Central 29 introducerer en tilbageførselshandling til bæredygtighedsposter. Det handler om at rette registrerede bæredygtighedsdata, ikke om endnu en måde at beregne udledning på. Og postens oprindelse betyder noget. Alex, hvorfor skal en kladdepost rettes ad en anden vej end en post, der kommer fra et købsdokument?

• Update 29.0 for Business Central 2026 release wave 2
• Bæredygtighedskonti, poster og tilbageførsel

Fordi rettelsen skal respektere den transaktion, der skabte posten. Den nye handling kan tilbageføre egnede poster fra en bæredygtighedskladde eller en finanskladde. Kommer posten fra et dokument, er den dokumenterede vej i stedet et korrektionsdokument. Det kan være at annullere eller korrigere købsfakturaen eller oprette en korrigerende kreditnota. Forestil dig, at den samme måling er blevet bogført to gange i en kladde. Tilbageførsel af dubletten modvirker den konkrete post. Men er problemet en købsfaktura, kan man ikke behandle dens bæredygtighedspost som en løs kladdefejl og overse dokumentet bagved.

• Bæredygtighedskonti, poster og tilbageførsel

Jeg skal altså spørge, hvor tallet kommer fra, før jeg leder efter knappen, der fjerner det. Og fjerner er nok det forkerte ord. Hvis jeg tilbagefører den dobbelte kladdemåling, forsvinder originalen så fra posterne? Eller kan vi stadig se, at der faktisk blev lavet en fejl?

• Bæredygtighedskonti, poster og tilbageførsel

Originalen bliver. Business Central opretter en forbundet tilbageførselspost med modsatte værdier. De to poster hænger fortsat sammen, og tilbageførslen registrerer, hvem der udførte den. Den bevarer også den oprindelige bogføringsdato og det oprindelige dokumentnummer. Når nogen senere spørger, hvorfor totalen ændrede sig, kan man følge rettelsen i stedet for at forklare en forsvunden linje. Man skal stadig udpege den rigtige dublet. Handlingen leverer mekanismen; den kan ikke afgøre, hvilken af to tilsyneladende ens målinger der beskriver den virkelige hændelse.

• Bæredygtighedskonti, poster og tilbageførsel

Men en total kan se forkert ud af en anden grund. Målingen kan være korrekt, mens virksomheden nu bruger en anden emissionsfaktor. Det kunne friste at tilbageføre og regne med, at systemet beregner efter den nye opsætning. Genbesøger handlingen beregningen, eller modvirker den det, der faktisk blev bogført?

Den modvirker de registrerede værdier. CO2-ækvivalenter eller CO2-afgift bliver ikke genberegnet med dagens opsætning. Og netop det er hensigten, når virkningen af en bestemt post skal ophæves: Tilbageførslen skal udligne den post, ikke en ny beregnet tilnærmelse. Har virksomheden brug for en erstatning med rettede input eller en ændret faktor, er det en yderligere regnskabsmæssig beslutning og bogføring. Den beslutning må vi ikke gemme i ordet tilbagefør. Dit eksempel ændrer spørgsmålet fra, hvordan vi fjerner en dublet, til hvilken korrekt registrering der skal træde i stedet.

• Bæredygtighedskonti, poster og tilbageførsel

Den forskel ville jeg skrive ind i arbejdsgangen. Ellers kan den beroligende besked om, at originalen er tilbageført, dække over, at ingen endnu har bogført de rigtige oplysninger. Hvad hvis posten også har en økonomisk side? Er tilbageførsel af bæredygtighedsposten nok til at få begge sæt registreringer rettet?

Nej. Handlingen tilbagefører kun bæredygtighedsposter. Den tilbagefører ikke finansposter, bæredygtighedsværdiposter eller de bagvedliggende dokumenter. Grænsen gælder også den anden vej: En tilbageført finanstransaktion tilbagefører ikke automatisk bæredygtighedsposterne. Den, der retter fejlen, skal derfor vide, hvilke registreringer der blev berørt. Det betyder ikke, at enhver rettelse skal gøres kompliceret. En enkel kladdedublet kan stadig være enkel. Men har samme hændelse både økonomiske og bæredygtighedsmæssige konsekvenser, skal nogen eje den samlede rettelse frem for at antage, at én vellykket handling ordnede det hele.

• Bæredygtighedskonti, poster og tilbageførsel

Lad os gøre det ansvar lidt konkret. En medarbejder markerer flere forkerte kladdeposter til tilbageførsel. Jeg vil helst opdage en ugyldig konto, inden halvdelen er rettet, og resten står tilbage. Kontrollerer handlingen hele udvalget først?

Ja. Den dokumenterede handling validerer alle markerede poster, før den tilbagefører noget. Allerede tilbageførte poster kan ikke tilbageføres igen, og konto og dimensioner skal stadig være gyldige. Brugeren skal også have Sustainability–Edit eller tilsvarende rettigheder. En ugyldig markering skal derfor føre til, at valideringsproblemet bliver undersøgt, ikke til en antagelse om, at en del af kørslen lykkedes. Kontoopsætningen omfatter en passende, ikke-spærret konto med direkte bogføring og gyldig kategori og underkategori. Detaljerne hører til i proceduren. Den nyttige adfærd er, at hele udvalget bliver kontrolleret, før tilbageførslen begynder.

• Bæredygtighedskonti, poster og tilbageførsel

Jeg ville begynde med posten og det, der skabte den. Når det er afklaret, bliver vejen til rettelsen meget tydeligere: En egnet kladdepost tilbageføres her, et dokument korrigeres dér, og nye, korrekte oplysninger kræver deres egen bogføringsbeslutning. Gevinsten er, at man kan få registreringen rettet og samtidig efterlade en forklaring, som den næste person kan følge. Det er en god grund til at genbesøge rettelsesproceduren, når version 29 tages i brug.

• Update 29.0 for Business Central 2026 release wave 2
• Bæredygtighedskonti, poster og tilbageførsel

Her er en ændring, der kan fjerne en lille, tilbagevendende overlevering. Business Central 29 tilføjer API'er til rapportindbakkens output. Helt enkelt kan et andet system hente oplysninger om rapporter, der allerede ligger i indbakken, og hente deres genererede indhold. Indbakken er ikke ny. Det interessante er, at det færdige output kan hentes via en integration. Alex, hvornår er det mere nyttigt end bare at køre rapporten igen i det andet system?

• Adgang til Report Inbox-poster gennem API
• Hent rapportindhold gennem API
• Del og eksportér rapporter fra Report Inbox

Når man skal bruge den rapport, Business Central allerede har produceret, og ikke en ny beregning af lignende data. Forestil dig, at virksomheden planlægger en afvigelsesrapport og vil have filen ind i en fælles gennemgang. Ellers kunne en medarbejder åbne indbakken, finde resultatet og flytte det videre. De nye API'er giver en integration adgang til at hente den eksisterende fil. Det er noget andet end at forespørge på aktuelle poster og bygge rapporten igen, og også noget andet end at bede Business Central udføre en rapport. Forskellen betyder noget, når gennemgangen skal bruge netop resultatet fra den bestemte kørsel.

• Hent rapportindhold gennem API
• Del og eksportér rapporter fra Report Inbox

Jeg kan godt lide at fjerne den uofficielle opgave, der hedder flyt rapporten, inden de andre møder ind. Men medarbejderen kan også foretage en stille vurdering: Er det rigtige regnskab, rigtige periode og rigtige kørsel? Automatiserer vi kun kopieringen, kan den forkerte rapport jo komme frem utrolig effektivt. Hvad kan integrationen faktisk undersøge?

Items-grænsefladen viser metadata som regnskab, rapportens identitet og navn, oprettelsestidspunkt, outputtype, filnavn og læst-status. Content-grænsefladen giver det genererede indhold og oplysninger om blandt andet navn, type og størrelse. Det hjælper integrationen med at finde og hente filen, men virksomheden skal stadig definere, hvilken rapportkørsel den forventer. Oprettelsestidspunktet siger, hvornår posten blev oprettet. Det beviser ikke i sig selv, hvilken regnskabsperiode tallene dækker. Den stille vurdering, du nævnte, skal derfor blive en udtrykkelig udvælgelsesregel, ikke forsvinde, fordi kopieringen bliver automatisk.

• Adgang til Report Inbox-poster gennem API
• Hent rapportindhold gennem API

Så ville jeg være ret præcis om det forventede output. Ikke send det nyeste regneark, men den aftalte rapport for det aftalte regnskab og formål. Metadataene har også en markering for læst. Det er fristende at bruge ulæste som en arbejdskø og markere læst, når integrationen har hentet filen. Er den markering nok til at sige, at overleveringen er færdig?

• Adgang til Report Inbox-poster gennem API

Det er en status, API'et kan ændre, ikke en fuldstændig leveringskvittering. Markeringen beviser hverken, at et menneske har læst rapporten, at et arkiv har gemt den, eller at en mail er nået frem. Jeg ville give integrationen sin egen definition af færdig. For et arkiv kunne det være, at destinationen faktisk har modtaget den rigtige fil, og integrationen har registreret, hvilken indbakkepost den behandlede. Først derefter ville jeg overveje at opdatere kildens status, hvis det passer til arbejdsgangen. Det er en anbefaling til designet, ikke en transaktionsgaranti fra rapportindbakkens API.

• Adgang til Report Inbox-poster gennem API

Og hvis filen bliver gemt, men statusopdateringen fejler, kan næste kørsel møde den igen. Det lyder som den slags lille afbrydelse, der gør en pæn demonstration til dobbeltbeskeder hos alle modtagerne. Jeg vil hellere have, at anden kørsel kan genkende det færdige arbejde, end at publikum skal opdage fejlen for os.

Den afbrydelse ville jeg tage med i en foreslået test. Gem filen, afbryd før statusændringen, og se så, om integrationen sikkert genkender det samme arbejde. Endepunktet giver adgang til rapporten; integrationen har stadig ansvar for dubletter og genoptagelse hos modtageren. Jeg ville også tage det modsatte tilfælde med, hvor den forventede fil aldrig dukker op. At hente en indbakkepost kan ikke reparere en rapport, som ikke blev kørt eller ikke gav output. Ved først at lede efter filen kan man skelne mellem fremstilling og distribution, i stedet for at sende begge hold efter den samme upræcise besked om en manglende rapport.

• Hent rapportindhold gennem API

Der findes også et nyttigt overblik ved siden af API'erne til poster og indhold. Det viser oplysninger om indbakken pr. regnskab, blandt andet antal poster, antal ulæste og seneste ændring. Hvis man understøtter en overlevering på tværs af flere regnskaber, lyder det som et bedre udgangspunkt end at åbne tilfældige filer. Hvor meget fortæller overblikket faktisk om den manglende rapport?

• Virksomhedsoplysninger i Report Inbox API

Det giver et billede af indbakken på regnskabsniveau: Hvor mange poster der er, hvor mange der er ulæste, og hvornår oplysningerne sidst ændrede sig. Det kan afgrænse, hvor man skal lede. Men fem poster identificerer ikke den bestemte afvigelsesrapport, som holdet forventer til gennemgangen. Næste skridt er stadig at undersøge de relevante poster og hente det tilsigtede indhold. Jeg ville bruge overblikket til at gøre supporten mere målrettet, ikke som erstatning for at vælge rapporten. Det svarer lidt til at vide, at der er post i bygningen: Nyttig viden, men man skal stadig finde den rigtige kuvert.

• Adgang til Report Inbox-poster gennem API
• Hent rapportindhold gennem API
• Virksomhedsoplysninger i Report Inbox API

Men før vi bygger noget: Indeholder indbakken alle de rapporter, nogen har udskrevet eller downloadet? Det er jo et andet løfte end planlagt output. Man kunne som lytter godt høre rapportindbakke-API og tænke, at man får en historik over alle rapporter, medarbejderne har produceret.

Det er ikke det, den giver. Den eksisterende indbakke er til genererede, planlagte rapporter, ikke en komplet historik over tidligere udskrifter eller rapporter hentet fra rapportmenuen. Begynd med at kontrollere, om det ønskede output faktisk ligger der. De dokumenterede outputtyper omfatter PDF, Word, Excel og ZIP, men ikke alle rapporter kan nødvendigvis levere alle formater. Modtagersystemet skal kunne arbejde med det output, rapporten faktisk giver. Netop genbrug af det eksisterende resultat gør det nye API nyttigt; det er ikke en universel rapportkonverter.

• Hent rapportindhold gennem API
• Del og eksportér rapporter fra Report Inbox

Nu kan jeg se to gode muligheder. Til en fast rapportpakke kan en integration overtage den gentagne overlevering med tydelige regler for udvælgelse og færdiggørelse. Til en fil en gang imellem har indbakken allerede deling, blandt andet via OneDrive. Jeg ville vælge ud fra, hvor tit overleveringen sker, og hvad modtageren har brug for, frem for at antage, at automatisering altid er det mere voksne svar.

• Adgang til Report Inbox-poster gennem API
• Hent rapportindhold gennem API
• Del og eksportér rapporter fra Report Inbox

Hyppigheden og modtagerens behov er gode udgangspunkter. Ved lejlighedsvis deling skal man huske, at OneDrive-filen er en særskilt kopi. Den opretter ikke en indbakkepost hos modtageren, og udløb af posten i Business Central sletter ikke automatisk den delte fil. Ved en tilbagevendende integration skal man aftale, hvem der må tilgå rapporten, og hvad der sker med kopierne efter hentning. Login og de nødvendige rettigheder er stadig påkrævet. Med ansvaret afklaret kan det nye API gøre den faste overlevering til en pålidelig arbejdsgang, mens den enkle deling fortsat er nyttig til en forespørgsel en gang imellem.

• Adgang til Report Inbox-poster gennem API
• Del og eksportér rapporter fra Report Inbox

Man behøver ikke et integrationsprojekt for at møde vores næste emne. Det er nok at søge i en liste og undre sig over, at en post, man ved findes, ikke dukker op. Den moderne listesøgning er en eksisterende, produktionsklar preview-funktion, ikke en ny søgemaskine i Business Central 29. Det ændrede er tidsplanen for obligatorisk brug: Microsoft har flyttet den fra version 29 til version 30. Det giver en god anledning til at forstå adfærden nu. Alex, hvad er anderledes ved den måde, søgningen finder sine resultater på?

• Sortér, søg og filtrér data
• Valgfrie funktioner, der bliver obligatoriske
• Aktivér optimeret tekstsøgning på felter

Moderne søgning arbejder med ord og begyndelsen af ord, og ordene behøver ikke stå i samme rækkefølge. Forestil dig et beskrivelsesfelt, som er med i søgningen, med den engelske tekst blue office chair. Søger man efter chair blue, kan varen stadig blive fundet. Det er praktisk, når man husker de vigtige ord, men ikke hvordan beskrivelsen blev formuleret. Søgningen leder altså ikke bare efter en vilkårlig række bogstaver hvor som helst i feltet. Den forskel kan forklare, hvorfor en velkendt genvej ikke længere giver det forventede resultat. Søgereglerne kan have ændret sig, uden at selve posten er blevet væk.

• Sortér, søg og filtrér data

At rækkefølgen er fri, giver god mening. Jeg kan huske farven og genstanden uden at kunne beskrivelsen udenad. Men lad os tage det engelske ord chair. Hvis man plejer at skrive de sidste fire bogstaver, altså hair, fordi det tidligere var nok, så fortolker den moderne søgning ikke det som begyndelsen af chair?

• Sortér, søg og filtrér data

Korrekt. Hair er ikke begyndelsen af chair, så det er ikke det resultat, man skal forvente. Et ordpræfiks begynder helt forrest i ordet. Er rækkefølgen vigtig, kan man bruge anførselstegn til at afgrænse søgningen til en præcis frase. De forskelle er gode at vise med virksomhedens egne, velkendte beskrivelser. Medarbejderne har ikke brug for en forelæsning om søgeteknologi for at ændre vanen. De skal se, hvorfor én søgetekst finder varen, mens en anden ikke gør, især hvis deres gamle tastevane byggede på nogle bogstaver midt i et ord.

• Sortér, søg og filtrér data

Jeg vil også vide, om det felt, jeg sidder og kigger på, overhovedet er med i søgningen. Hvis nummeret eller referencen er synlig i en kolonne, er det nærliggende at tro, at man kan skrive den i listesøgningen og finde rækken. Betyder synlig også søgbar her?

Ikke automatisk. Moderne søgning bruger de kolonner, udviklerne har udpeget til formålet. At et felt vises på siden, beviser ikke i sig selv, at det deltager. Det er især værd at kontrollere for tilpassede felter, som virksomheden bruger meget i hverdagen. Finder et hold altid ordrer ud fra sit eget referencefelt, skal netop det felt med i overvejelserne om ibrugtagning. Ellers kan man demonstrere søgningen på en standardbeskrivelse, erklære det hele vellykket og overse den reference, som medarbejderne faktisk bruger dagen igennem.

• Sortér, søg og filtrér data

Så bliver den bedste demonstration lidt mindre prangende: Spørg en medarbejder, hvad vedkommende normalt skriver, og brug det. Her er en anden helt almindelig situation. En kollega ændrer beskrivelsen, fortæller mig den nye ordlyd, og jeg søger med det samme. Hvis posten ikke dukker op, har vi så fundet en fejl i opsætningen?

Ikke nødvendigvis. Søgeindekset bliver opdateret i baggrunden, normalt inden for få sekunder, så en helt ny ændring kan være lidt forsinket. Det beviser ikke, at netop dit manglende resultat skyldes indeksering. Men det giver en fornuftig første skelnen: Blev data lige ændret, eller har de stået der længe? Se derefter på, om feltet er med, og om søgeteksten passer til ordsøgningen. Microsoft anbefaler også at prøve den ældre søgning, når kendte data ikke bliver fundet. Sammenligningen kan hjælpe undersøgelsen, uden at man straks behandler selve posten som forsvundet.

• Sortér, søg og filtrér data

Godt, at du siger hjælpe undersøgelsen. Finder vi rækken på en anden måde, ved vi, at den findes, men ikke hvilken indstilling der eventuelt er forkert. Hvad hvis muligheden for moderne søgning slet ikke vises? Nogen kunne høre os og tænke, at funktionen mangler, fordi deres miljø endnu ikke er på version 29.

• Sortér, søg og filtrér data

Det kan man ikke slutte alene ud fra den manglende mulighed. Funktionen fandtes før version 29. Den er måske ikke aktiveret, eller den pågældende liste har måske ingen felter udpeget til moderne søgning. Når funktionen aktiveres, bliver moderne søgning standarden. Det relevante er altså at kontrollere funktionen og den konkrete liste, ikke kun versionsnummeret. Og vi taler om at finde data i lister, ikke den separate Fortæl mig-funktion, der finder sider og handlinger. Kalder vi det hele den nye søgning, bliver supportsamtalen sværere end nødvendigt.

• Sortér, søg og filtrér data
• Aktivér optimeret tekstsøgning på felter

At obligatorisk brug er flyttet til version 30, giver altså luft, men ikke grund til at lægge emnet i skuffen. Jeg ville bruge tiden på at samle nogle virkelige søgevaner: Navne, referencer og beskrivelser, også de besværlige. Er det en bedre forberedelse end at spørge, om den nye søgning altid er hurtigere?

• Valgfrie funktioner, der bliver obligatoriske

Meget bedre. En generel påstand om hastighed fortæller ikke ordrekontoret, om deres reference kan findes. Jeg ville sammenligne de repræsentative søgninger på de lister, holdet faktisk bruger, notere de involverede felter og forklare eventuelle ændrede tastevaner. Der findes dybere administrative valg, blandt andet indekseringssprog. En ændring dér starter genindeksering i baggrunden på tværs af miljøet og fortjener sin egen planlægning. For medarbejderne er målet enklere: De kan finde deres sædvanlige poster og forstår de få vaner, der skal ændres. Det er et konkret resultat at sigte efter, før version 30 gør overgangen obligatorisk.

• Sortér, søg og filtrér data
• Valgfrie funktioner, der bliver obligatoriske
• Konfigurér sproget for tekstsøgning

En mindre opdagelse til sidst. Siden april, i Business Central 28, har bogførte salgsleverancer og returvaremodtagelser haft mailhandlinger, blandt andet Send via mail og Vedhæft som PDF. Det er altså ikke en oktoberlancering. Den er værd at bemærke, fordi den, der skal bruge leveringsoplysningerne, ikke altid er den, der modtager fakturaen. Alex, hvor gør det en forskel på en almindelig arbejdsdag?

• Send bogførte salgsleveringer og returvaremodtagelser på mail
• Nyheder i Business Central 28.0

Forestil dig, at virksomheden har bogført en levering, og kundens varemodtagelse skal bruge dokumentet til at forberede sig på varerne. Økonomiafdelingen fakturerer måske senere eller sender fakturaen til en anden kontakt. Den bogførte salgsleverance giver den praktiske samtale sit eget dokument og sin egen modtager. Ved retur kan den bogførte returvaremodtagelse tilsvarende bruges til at kommunikere, hvad virksomheden har modtaget. Faktureringen behøver ikke bære alle beskeder. Gevinsten er beskeden, men den kan fjerne omvejen med at eksportere et dokument og skrive en løs mail bare for at sende de samme oplysninger.

• Send bogførte salgsleveringer og returvaremodtagelser på mail

Det er sådan en forbedring, der godt må være nyttig uden at få et stort navn. Men jeg vil ikke have, at lagerdokumentet ubemærket ryger til kreditorbogholderiet, bare fordi det er kundens normale mailadresse. Finder den nye handling selv ud af, hvem der er den rigtige praktiske kontakt?

Den rigtige modtager skal stadig vælges. Standardforløbet til dokumentmail kan bruge standardvalg eller lade brugeren gennemse modtagere og indstillinger, og mailopsætningen og det ønskede rapportlayout skal være på plads. Jeg ville gennemgå et konkret dokumentlayout med dem, der skal modtage det: Viser det de leveringsoplysninger, de har brug for, i en form, de kan bruge? Aftal derefter rutinen med den, der sender det. En understøttet handling, det rigtige layout og en tydelig modtager kan være nok til at gøre den daglige kommunikation lettere.

• Send bogførte salgsleveringer og returvaremodtagelser på mail
• Send dokumenter og mails

Og en tilgængelig handling betyder ikke, at mailen automatisk bliver sendt, hver gang en levering bogføres. Den forskel skal være tydelig. Nogen skal stadig kunne se, om beskeden er sendt, fejlet eller ligger som kladde. Ellers har vi bare flyttet usikkerheden fra, hvor PDF'en er, til om nogen har modtaget den.

• Send bogførte salgsleveringer og returvaremodtagelser på mail
• Send dokumenter og mails

Ja. Se på mailens resultat i stedet for at slutte det ud fra dokumenthandlingen. Udbakken indeholder kladder og fejlbehæftede beskeder, mens sendte beskeder har deres egen visning. Selv en sendt mail beviser ikke, at den rette person har læst den, og leveringsdokumentet beviser ikke, at varerne fysisk er afleveret hos kunden. En almindelig overlevering kan stadig holdes enkel: Aftal hvilket bogført dokument der skal sendes, til hvem, og hvem der følger op ved en afsendelsesfejl. Forbedringen er, at Business Central nu har de relevante mailhandlinger direkte på netop de bogførte dokumenter.

• Send bogførte salgsleveringer og returvaremodtagelser på mail
• Send dokumenter og mails

Det er et godt sted at slutte. Vi har udforsket Business Central 29s nye lageraktiviteter til underleverandørproduktion, vejen til at rette egnede bæredygtighedsposter og adgangen til færdige rapporter. Vi har også set, hvorfor søgevaner fortjener en praktisk gennemgang før overgangen i version 30, og hvordan en ældre mailforbedring til leveringsdokumenter måske allerede kan spare en omvej. Det nyttige spørgsmål er ikke bare, om funktionen findes, men om resultatet når den rigtige person i den rigtige form. Direkte kilder og de dybere detaljer ligger i afsnitsnoterne. Tak, fordi du lyttede til Central Perspectives fra ITrators.

• Update 29.0 for Business Central 2026 release wave 2
• Adgang til Report Inbox-poster gennem API
• Valgfrie funktioner, der bliver obligatoriske
• Send bogførte salgsleveringer og returvaremodtagelser på mail