Velkommen til Business Central Podcast fra ITrators. Jeg hedder Emma og er her sammen med Alex. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag undersøger vi nyttige standardmuligheder og udvalgte ændringer fra oktober. Kan vedhæftninger flyttes ud af databasen, mens medarbejderne arbejder videre samme sted? Hvornår fjerner en enklere vareoverflytning dobbeltarbejde, og hvornår fjerner den oplysninger, man har brug for? Vi ser også på, hvor adgang kommer fra, og en kortere vej tilbage til dine analyser. Lad os komme i gang.

Vi starter med en praktisk mulighed, der kom allerede i april. Business Central kan som standard gemme dokumentvedhæftninger eksternt. Forestil dig en grossist, hvor medarbejderne hver dag vedhæfter PDF-filer fra leverandører og anden dokumentation. Filerne hober sig op, men folk vil stadig finde dem dér, hvor de arbejder. Alex, hvis virksomheden vælger ekstern lagring, hvad ændrer det så for den medarbejder, der vedhæfter et dokument eller åbner det igen senere?

• Gem dokumentvedhæftninger i eksternt fillager
• Ekstern lagring af dokumentvedhæftninger

For medarbejderen foregår det velkendte arbejde med vedhæftninger stadig i Business Central. Man skal ikke begynde at arkivere leverandørernes PDF-filer i et andet program, bare fordi lagringsstedet ændrer sig. Bagved opretter en administrator en ekstern filkonto i Business Central, forbinder den med lagerudbyderen og knytter den til scenariet for dokumentvedhæftninger. Når det er aktiveret, bliver nye vedhæftninger gemt dér i stedet for at ligge som filer i Business Central-databasen. De understøttede muligheder er SharePoint, Azure Blob Storage og Azure Files. Så hos din grossist er den nyttige forskel, at medarbejderne stadig vedhæfter og finder dokumenterne dér, hvor de arbejder, mens virksomheden kan vælge et andet sted til selve filerne. Det er den fordel, jeg ville begynde med, frem for at love et billigere eller hurtigere system.

• Gem dokumentvedhæftninger i eksternt fillager

Du siger nye vedhæftninger. Vores grossist har jo allerede flere års dokumenter liggende i Business Central. Hvad sker der med den bunke, når de slår det her til?

• Gem dokumentvedhæftninger i eksternt fillager

Den bunke bliver, hvor den er. Når man slår scenariet til, ændrer man, hvor nye vedhæftninger bliver gemt. Man flytter ikke de gamle. Til dem er der en særskilt handling, Storage Sync, hvor man vælger, hvilken vej filerne skal flyttes. Den kan flytte eksisterende vedhæftninger ud, og den kan hente filerne tilbage i databasen, hvis man vil stoppe med ekstern lagring. Den mulighed er værd at bemærke: valget går ikke kun én vej. Mit praktiske forslag ville være først at prøve arbejdsgangen i en testopsætning med et dokument, man straks kan genkende. Vedhæft det, åbn det, og tjek indholdet. Planlæg så flytningen af de eksisterende filer som et særskilt trin i stedet for at samle det hele i aktiveringen.

• Gem dokumentvedhæftninger i eksternt fillager

Det gør valget lettere at overveje, at man kan hente filerne tilbage. Men hvis jeg driver den grossistvirksomhed, ser dokumenterne jo stadig ud til at være en del af Business Central. Når nogen siger: “Vi kan gendanne vores Business Central-backup,” hvad betyder det så for mine vedhæftninger?

• Gem dokumentvedhæftninger i eksternt fillager

Det betyder, at du skal skelne mellem registreringen af vedhæftningen og selve filen. Business Centrals backup omfatter ikke de eksterne filer, og de bliver heller ikke administreret som en del af den. En gendannet database er altså ikke et løfte om, at dokumenterne også er gendannet. Jeg ville gøre testen helt jordnær: Find et leverandørdokument i det gendannede system, og åbn det så. Det er ikke nok at kunne se navnet. Den eksterne fil skal stadig findes og være tilgængelig. Den, der passer det eksterne lager, skal have filerne med i planen for gendannelse. Det er et særskilt ansvar, ikke en grund til at afvise muligheden.

• Gem dokumentvedhæftninger i eksternt fillager

Et filnavn kan godt se betryggende ud, ikke? Det bringer mig tilbage til din testopsætning. Hvis vi kopierer regnskabet for at prøve det her af, får vi så også en selvstændig kopi af de vedhæftede filer?

Ikke bare ved at kopiere regnskabet. Registreringerne af vedhæftningerne kan følge med og stadig pege på de oprindelige eksterne filer. Så poster i to regnskaber kan føre dig til den samme fil, ikke til to selvstændige kopier. Handlingen Migrate Files kan flytte vedhæftninger fra det tidligere regnskabs eller miljøs mappe til den aktuelle. Men det er en flytning. Det er ikke dokumentation for, at du har lavet en isoleret sikkerhedskopi.

• Gem dokumentvedhæftninger i eksternt fillager

Så det at rydde op i en vedhæftning i testregnskabet er måske ikke helt så afgrænset, som det ser ud. Når jeg trykker slet i Business Central, hvad er det så egentlig, jeg sletter?

Det afhænger af en indstilling: Delete External File on Attachment Delete. Er den slået til, sender Business Central også en anmodning om at slette den eksterne fil, når du sletter vedhæftningen. Er den slået fra, fjerner Business Central forbindelsen, men filen bliver liggende i det eksterne lager. Det er to ret forskellige betydninger af at rydde op. Jeg ville vælge den adfærd bevidst sammen med den ansvarlige for dokumenterne, frem for at lade medarbejderne opdage den undervejs. At beholde en fil uden tilknytning er heller ikke i sig selv en opbevaringspolitik. Man skal stadig beslutte, hvad der skal ske med den, og hvornår.

• Gem dokumentvedhæftninger i eksternt fillager

Det får mig til at tænke på selve forbindelsens rækkevidde. Hvis vores grossist allerede bruger SharePoint i flere afdelinger, kræver forbindelsen til Business Central så adgang til alle de websteder, eller kan man begrænse den til et bestemt sted til vedhæftningerne?

De kan begrænse forbindelsen til udvalgte SharePoint-websteder. Med standardforbindelsen via Microsoft Graph vælger man den afgrænsede adgang og giver derudover applikationen særskilt skriveadgang til hvert websted, den skal bruge. Den begrænsede adgangstype giver ikke i sig selv adgang. Så grossisten kan vælge et bestemt sted til vedhæftningerne uden at inddrage alle afdelingernes SharePoint-websteder i forbindelsen. Der skal en appregistrering og den rette godkendelsesopsætning til. Det er ikke bare et mappenavn, man indsætter i Business Central. Men det er en afgrænset opsætningsopgave, ikke et krav om at gøre forbindelsen til administrator for alle deres websteder.

• Gem dokumentvedhæftninger i eksternt fillager

Nu har vi brugt lidt tid ved slet-knappen, men muligheden skal ikke drukne i den detalje. Jeg hører et valg om, hvem der tager sig af filerne, ikke en grund til at være bange for ekstern lagring. Hvornår ville du for alvor overveje den her standardmulighed i en virksomhed, hvor den nuværende løsning fungerer?

Jeg ville især se på en virksomhed, der tilføjer store mængder vedhæftninger, og som allerede har nogen med ansvar for en af de understøttede lagertjenester. Der er et reelt valg om, hvor den voksende samling hører hjemme, og en ansvarlig, der kan vurdere det. Hvis virksomheden kun vedhæfter nogle få små dokumenter og ikke har et lagerproblem, ville jeg ikke opfinde et migreringsprojekt. Og i ingen af tilfældene ville jeg begynde med: Hvilken tilkøbsapp skal vi have? Muligheden findes allerede i standardproduktet. Der skal en ordentlig kontoopsætning og godkendelse på plads, så det er ikke bare en knap, alle brugere slår til. Men at undersøge standardmuligheden er et fornuftigt første skridt. Det forpligter ikke virksomheden til at flytte samtlige filer.

• Gem dokumentvedhæftninger i eksternt fillager

Der er en anden standardmulighed, som er værd at kende, denne gang for virksomheder, der forbinder Business Central med Dataverse. Siden april har man kunnet føje et nyt Dataverse-felt til en eksisterende tilknytning uden at ændre en proxy-extension. Forestil dig, at salgsteamet har tilføjet en kundeklassifikation i Dataverse, og at det tilsvarende felt allerede findes i Business Central. Nu vil de have værdien overført mellem systemerne. Alex, hvilket arbejde slipper de faktisk for med den her ændring?

• Tilknyt nye Dataverse-felter i Business Central

De kan slippe for at ændre en extension alene for at få integrationen til at genkende det nye felt. Tænk på proxyen som integrationslagets beskrivelse af de felter, der findes i Dataverse. Før kunne et nyt brugerdefineret felt kræve, at man opdaterede den beskrivelse gennem en extension. Nu kan en administrator opdatere feltlisten fra Dataverse, føje et understøttet felt til den eksisterende tilknytning, matche det med feltet i Business Central, vælge synkroniseringsretningen og aktivere det. Så har kundeklassifikationen en vej mellem systemerne uden netop den kodeændring eller en ny tilknytning fra bunden. Funktionen opretter dog ikke Business Central-feltet for dig. I dit eksempel findes destinationen allerede, og det er en vigtig del af, hvorfor arbejdet bliver enklere.

• Tilknyt tabeller og felter til synkronisering
• Tilknyt nye Dataverse-felter i Business Central

Kodeændringen slipper vi for, men retningen skal vi stadig tage stilling til. Lad os sige, at salg ejer kundeklassifikationen i Dataverse, og økonomiafdelingen læser den i Business Central. “Begge retninger” lyder bekvemt. Er det stadig et fornuftigt valg, hvis medarbejdere på begge sider kan finde på at ændre værdien?

• Tilknyt tabeller og felter til synkronisering
• Tilknyt nye Dataverse-felter i Business Central

Med den arbejdsdeling, du beskriver, ville jeg begynde med én retning: fra Dataverse til Business Central. Lad os sige, at salg ændrer en kunde fra standardkunde til strategisk kunde. Økonomiafdelingen skal have den nye værdi, ikke et ekstra sted at vedligeholde en konkurrerende klassifikation. Synkronisering begge veje kan give mening, når begge teams faktisk har brug for at redigere feltet. Men valget af begge retninger beskriver kun, hvordan værdierne kan flyttes. Det afgør ikke, hvis vurdering der skal veje tungest, når afdelingerne er uenige. Jeg ville afklare ansvaret først. Ellers står forretningsbeslutningen stadig ubesvaret bag en bekvem indstilling.

• Tilknyt tabeller og felter til synkronisering

Lad os så følge den strategiske kunde over i det andet system. Vi har matchet felterne til kundeklassifikationen, men hvert system har sin egen kundepost. Hvad fortæller integrationen, hvilken kunde i Business Central der skal have den nye værdi?

Det er koblingen: forbindelsen, der siger, at denne post i Dataverse svarer til denne kunde i Business Central. Som standard arbejder synkroniseringsjobbene kun med koblede poster. Tilknytningen af klassifikationsfeltet fortæller integrationen, hvor værdien hører til på den koblede kunde. Den matcher ikke automatisk alle kunder i de to systemer. Så en kunde, der allerede er med i integrationen, kan få endnu en nyttig oplysning overført. At forbinde kundeposter, som endnu ikke er koblet, er et særskilt spørgsmål.

• Tilknyt tabeller og felter til synkronisering
• Tilknyt nye Dataverse-felter i Business Central

Lad os sige, at den eksisterende kunde bliver opdateret fint, men en helt ny kunde fra salg aldrig dukker op i Business Central. Så kan “kun koblede poster” godt ligne forhindringen. Løser man det ved at fjerne fluebenet, eller ændrer man mere end det?

• Tilknyt tabeller og felter til synkronisering

Du ændrer mere. Når du fjerner den indstilling, kan synkroniseringen oprette poster i destinationssystemet for kildeposter, der endnu ikke er koblet. Det kan være præcis det, virksomheden ønsker, men det er en anden opgave end at opdatere klassifikationen på en eksisterende kunde. Forestil dig, at salgssystemet indeholder både godkendte kunder og kundeemner, som endnu ikke skal være kunder i Business Central. Så skal man beslutte, hvilke der skal overføres. Tabelfilteret kan afgrænse posterne i Business Central, og integrationstabelfilteret kan afgrænse posterne i Dataverse. Med den ønskede retning og afgrænsning kan oprettelsen være nyttig. Men ét fjernet flueben er ikke et løfte om, at alle manglende kunder dukker op.

• Tilknyt tabeller og felter til synkronisering

Det forklarer, hvilke poster vi tager med over. Hvad så i den anden ende af deres levetid? Forestil dig, at en koblet post bliver slettet i det ene system, men stadig findes i det andet. Hvad kan den ansvarlige vælge, der skal ske, så de to teams ikke skal gætte sig frem?

Tabeltilknytningen har en strategi til sletningskonflikter. Man kan vælge at gendanne den slettede post, fjerne koblingen mellem posterne eller lade være med at gøre noget automatisk og løse konflikten manuelt. Valgene udtrykker forskellige hensigter. Hvis en post blev slettet ved en fejl, kan det være præcis det rigtige at gendanne den. Hvis hensigten er at afslutte forbindelsen mellem de to poster, er det selve koblingen, man fjerner. Og hvis nogen skal forstå omstændighederne bag sletningen, lader manuel håndtering beslutningen blive hos dem. Jeg ville ikke vælge en mulighed, bare fordi den lyder mest automatisk. Det nyttige er, at man kan fastlægge, hvad en sletning skal betyde i netop denne integration.

• Tilknyt tabeller og felter til synkronisering

En post, der dukker op igen, kan altså være den aftalte adfærd og ikke en fejl. Hvad med en mindre endelig uenighed: Begge teams ændrer kundeklassifikationen inden næste synkronisering? Vi har allerede valgt, hvilken vej feltet må overføres. Hvordan hænger strategien for opdateringskonflikter sammen med den retningsindstilling?

• Tilknyt tabeller og felter til synkronisering

Retningen siger, hvor værdien kan flyttes hen. Konfliktstrategien siger, hvordan integrationen skal håndtere modstridende opdateringer, når de opstår. På tabeltilknytningen kan man vælge at sende en opdatering til integrationstabellen, når man synkroniserer mod Dataverse, eller hente en opdatering derfra, når man synkroniserer mod Business Central. Man kan også lade konflikten blive løst manuelt. Sagt mere enkelt vælger man, om den pågældende synkroniseringsretning skal afgøre konflikten, eller om nogen skal tage stilling. Det er strategier på tabeltilknytningen, ikke en ny konfliktpolitik, der opstår, fordi man tilføjer klassifikationsfeltet. Derfor er den eksisterende strategi relevant, når det nye felt bliver en del af udvekslingen mellem systemerne.

• Tilknyt tabeller og felter til synkronisering

Her er der en nyttig detalje i dokumentationen: Nye felttilknytninger, som føjes til en eksisterende tabeltilknytning, starter som deaktiverede. Den adskillelse kan jeg godt lide. Man kan forberede tilknytningen af klassifikationsfeltet, uden at den straks indgår i synkroniseringen. At oprette den og beslutte at tage den i brug er to forskellige trin.

• Tilknyt tabeller og felter til synkronisering

Og så kan man gøre kontrollen konkret: Aktivér tilknytningen i en testopsætning, ændr klassifikationen på en kendt, koblet kunde, og kontrollér værdien i det andet system. Ikke bare: Kunden blev synkroniseret. Men: Netop det her felt gjorde det, vi ville. Der er også en detalje at fange tidligere: Hvis feltet ikke findes i opslaget, hjælper det ikke nødvendigvis at opdatere listen igen. Guiden understøtter bestemte felttyper, og FlowFields og FlowFilters kan ikke vælges. Et manglende felt kan skyldes en begrænsning, ikke en forældet liste.

• Tilknyt tabeller og felter til synkronisering

Inden vi taber nogen ved ordet “FlowField”: Hvad betyder den begrænsning for et konkret ønske fra virksomheden? Kan du give et eksempel på forskellen uden kun at bruge feltets tekniske betegnelse?

• Tilknyt tabeller og felter til synkronisering

Tag vores kundeklassifikation: Det er en gemt værdi, som nogen vedligeholder. Forestil dig nu, at ønsket i stedet er: Send denne beregnede total til salgsteamet. Hvis totalen er et FlowField, beregner Business Central resultatet i stedet for at gemme det som en almindelig feltværdi. Begge dele kan ligne et tal eller en tekst på en side, men for integrationen er der forskel. Tilknytningsguiden understøtter ikke FlowFields. Det beviser ikke, at virksomhedens ønske er umuligt. Det betyder, at denne opsætningsvej ikke dækker det. En udvikler kan være nødt til at vurdere en anden tilgang, blandt andet hvornår totalen skal beregnes, og hvor aktuel den skal være hos salg.

• Tilknyt tabeller og felter til synkronisering
• Oversigt over FlowFields

Der er også en forskel i udgivelsesstatus, som er værd at holde fast i. Muligheden for nye felter blev generelt tilgængelig i april. Den bredere assisterede opsætning, New Table Mapping, er stadig markeret som preview i vejledningen. Det er ikke det samme. Vores eksempel med kundeklassifikationen handler om den mere afgrænsede mulighed: at føje et understøttet felt til en eksisterende tilknytning uden den ændring af proxy-extensionen.

• Tilknyt tabeller og felter til synkronisering
• Tilknyt nye Dataverse-felter i Business Central

Den mere afgrænsede forbedring er bestemt værd at få. Et team med en eksisterende integration behøver ikke længere behandle hvert nyt tilgængeligt felt som en opgave med at vedligeholde en extension. Det kan jeg bedre lide end et stort løfte om integration uden kode. Der er stadig forskel på at få en værdi over og at få en brugbar værdi over. To klassifikationsfelter kan bruge forskellige koder for samme betydning. At aktivere tilknytningen afgør ikke, hvordan værdien skal omformes. Og modstridende opdateringer kræver stadig en valgt strategi. Når det gentagne tekniske arbejde fylder mindre, er der mere plads til de beslutninger, som faktisk betyder noget for virksomheden.

• Tilknyt tabeller og felter til synkronisering
• Tilknyt nye Dataverse-felter i Business Central

Nu går vi fra at flytte kundeoplysninger til at flytte varer. Med Business Central 29 her i oktober kan man bogføre direkte overflytningsordrer fra lokationer med lagerstyring. Direkte overflytninger er ikke i sig selv nye. Forestil dig, at et centrallager med lagerstyring fylder op i et reservedelsrum til vedligeholdelse. Rummet er en selvstændig lokation i Business Central uden en lagerproces til varemodtagelse. Alex, hvilket praktisk trin kan ændringen spare dem for, når de flytter forsyningerne?

• Opdatering 29.0 til Business Central, udgivelsesbølge 2 i 2026
• Overflyt varer mellem lokationer

Det kan fjerne en særskilt modtagelsesbogføring i reservedelsrummet. Med en understøttet opsætning kan den udgående lagerproces afslutte den direkte overflytning, så afsendelse og modtagelse bliver bogført sammen. Lageret skal stadig udføre sit arbejde. Hvis der kræves pluk, skal plukket oprettes og registreres, før lagerleverancen bogføres. Vi har ikke fået varerne til at flytte sig ved at trykke på en knap. For reservedelsrummet ville jeg se muligheden dér, hvor den fysiske overdragelse er enkel, og bogføringen retvisende kan vise, at varerne er nået frem. Man beholder den nødvendige håndtering på det afsendende lager uden at bede nogen i den anden ende om en særskilt modtagelsesbogføring bare for at afslutte overflytningen.

• Overflyt varer mellem lokationer

“Bogført sammen” får mig lige til at stoppe op. Hvad nu, hvis det enkle reservedelsrum ligger på en anden adresse, og varerne stadig skal bruge tid på at nå frem? Er det nok, at der ikke er en lagerproces til modtagelse, til at vælge direkte bogføring?

Nej, tiden mellem afgang og ankomst betyder stadig noget. Hvis I skal kunne se, at varerne har forladt lageret, men endnu ikke er nået frem til den anden adresse, har en almindelig overflytning med transit en reel funktion. Den holder styr på antallet undervejs, og afsendelse og modtagelse bogføres hver for sig. Modtagelsen registrerer så noget, der faktisk er sket. Den er ikke bare gentaget administration. Direkte bogføring er ikke i sig selv et dårligt valg. Den passer til en anden proces. Jeg ville ikke lade fraværet af lagermodtagelse på destinationen afgøre, hvordan vi viser transporten.

• Overflyt varer mellem lokationer

Der er en detalje i dokumentationen, som gør den forskel lidt mindre klar. Med direkte overflytning slået til og bogføringsmetoden sat til Shipment and Receipt kan man stadig vælge en transitkode. Hvorfor giver det os ikke den særskilte afsendelse og modtagelse, du lige har beskrevet?

• Overflyt varer mellem lokationer

Fordi koden ændrer den lokation, vareposterne bruger, ikke tidspunktet for de to bogføringer. I den direkte tilstand med Shipment and Receipt bruger posterne den valgte transitlokation i stedet for en blank lokation. Men afsendelse og modtagelse bliver stadig bogført sammen. Navnet lægger godt nok op til den anden fortolkning. Du har ikke skabt en åben periode, hvor varerne venter på at blive modtaget. Til det skal du bruge processen med særskilt afsendelse og modtagelse, som vi talte om. Det er ikke nok at udfylde en transitkode på en direkte overflytning.

• Overflyt varer mellem lokationer

Det feltnavn hjælper os ikke ligefrem. Men hvis begge direkte metoder bogfører de to sider sammen, hvorfor skulle en virksomhed så vælge Shipment and Receipt frem for Direct Transfer? Hvilken forskel ville de faktisk mærke bagefter?

De bogførte dokumenter er forskellige, og det kan have betydning for økonomiafdelingen. Direct Transfer opretter et bogført direkte overflytningsdokument. Shipment and Receipt opretter en bogført overflytningsafsendelse og en bogført overflytningsmodtagelse, selv om de bogføres sammen. Den modtagelse giver dig mulighed for at tildele et varegebyr. Det kan du ikke med metoden Direct Transfer. Forestil dig en transportomkostning, som virksomheden skal fordele på de overflyttede varer. Så er modtagelsen mere end bare endnu et dokument. Jeg ville tage det regnskabsmæssige behov med i valget i stedet for at antage, at metoden med færrest dokumenter altid passer bedst.

• Overflyt varer mellem lokationer

Så har det ekstra dokument faktisk en opgave. Tilbage på lageret: Forestil dig, at kun en del af de forsyninger, vedligeholdelsesteamet har bestilt, er til rådighed nu. Resten kommer senere. Kan en direkte overflytning håndtere den første del uden at behandle hele bestillingen som afsluttet?

Med metoden Shipment and Receipt kan man, men der er en vigtig forskel at holde fast i. Man kan bogføre en del af ordren, men antallet, der skal afsendes, skal være lig med antallet, der skal modtages. Den del, der er klar, kan altså afsendes og modtages samlet, mens resten venter til senere. Det er ikke det samme som at sige: Vi sendte så meget, men kun noget af det nåede frem. Den samlede direkte bogføring giver ikke den særskilte beslutning ved modtagelsen. Metoden, der faktisk hedder Direct Transfer, tillader ikke delvis bogføring. Så vedligeholdelsesteamets helt almindelige ønske har betydning for, hvilken metode der passer.

• Overflyt varer mellem lokationer

Nu vi taler om antal: Forestil dig, at lageret opdager et forkert antal lige efter bogføringen. Når begge sider er afsluttet samlet, har de så stadig den samme mulighed for at fortryde afsendelsen, som hvis den endnu ikke var modtaget?

Ikke den samme mulighed. Ved en almindelig overflytning kan man fortryde afsendelsen, så længe den endnu ikke er modtaget. Sammenligningen angiver udtrykkeligt, at den mulighed ikke findes ved nogen af de to direkte bogføringsmetoder. I praksis har man afsluttet begge sider i stedet for at have en afsendelse, der venter på modtagelse. Det betyder ikke, at en fejl aldrig kan rettes. Det betyder, at vi ikke skal love netop denne fortrydelsesmulighed. I lagerprocessen ville jeg lægge bekræftelsen af antallet ind, når den direkte flytning afsluttes. Det nyttige spørgsmål er, om teamet kender det korrekte antal dér, frem for at lade en senere modtagelse fastslå det.

• Overflyt varer mellem lokationer

Jeg ville stadig gerne af med dobbeltregistreringen, hvis teamet allerede bekræfter antallet ordentligt. Hvordan ville du afprøve det med lagerets faktiske arbejdsgang, så de kan vise, at den enklere bogføring passer, og ikke bare at knappen virker?

Jeg ville lade dem gennemføre en helt almindelig opfyldning i et testmiljø i den rækkefølge, de faktisk arbejder. Hvem bekræfter, hvad der er plukket? Hvem registrerer, at varerne er overdraget? Placér den foreslåede bogføring på det tidspunkt, hvor den skal ske, og se derefter på antallet på begge lokationer og de dokumenter, den valgte metode har dannet. Spørg dem, der udfører arbejdet, om resultatet beskriver det, der er sket. Så kan man se, om man har fjernet dobbeltregistrering eller bare gjort en vigtig bekræftelse usynlig. Det er teamet, der demonstrerer sin arbejdsgang, ikke bare nogen, der demonstrerer en bogføringsknap.

• Overflyt varer mellem lokationer

Vi har dog bevidst holdt modtagelsen enkel. Overskriften siger lokationer med lagerstyring, og det lyder ret bredt. Hvis reservedelsrummet vokser og begynder at kræve lagermodtagelser eller indfører lagerlæg på det enklere niveau, inventory put-away, hvad betyder det så for de muligheder, vi har talt om?

• Opdatering 29.0 til Business Central, udgivelsesbølge 2 i 2026

De to ændringer giver forskellige svar. Hvis destinationen kræver lagermodtagelser, understøtter ingen af de direkte metoder det. Det samme gælder en destination med styret læg-på-lager og pluk, altså den mere avancerede lageropsætning. Det enklere lagerlæg, inventory put-away, er anderledes. Den direkte metode Shipment and Receipt understøtter ikke den destination, men metoden Direct Transfer understøtter kombinationer, der gør. Microsoft giver et eksempel med lagerpluk på den afsendende lokation og lagerlæg på den modtagende. Her kan man bogføre lagerlægget og oprette begge overflytningsposteringer. Håndtering på modtagersiden er altså ikke udelukket i alle tilfælde. Men eksemplet afslutter stadig begge sider. Det indfører ikke en særskilt ventetid under transporten. Den præcise kombination af de to lokationer og bogføringsmetoden er afgørende.

• Overflyt varer mellem lokationer

Der er flere brugbare veje her; den fulde sammenligning lægger vi i noterne. Hvis en lagerchef hører nyheden og tænker: “Kan vi slippe for at registrere den samme flytning to gange?”, hvad ville du så først spørge om i deres arbejdsgang?

Hvad fortæller den anden bogføring jer, som I ikke vidste ved den første? Hvis svaret er: Ingenting, varerne bliver overdraget i én arbejdsgang, og bagefter skriver nogen de samme oplysninger ind i en modtagelse, så kan der være en nyttig forenkling her. Hvis svaret er: Den bekræfter, hvad der kom frem, efter et andet team har kontrolleret det, så er det en særskilt oplysning, der er værd at bevare. Dér ville jeg begynde, før jeg ledte efter en indstilling. Gevinsten er at fjerne gentaget administration, ikke at fjerne det tidspunkt, hvor nogen fastslår, hvad der faktisk er sket.

Her er et andet spørgsmål til den, der har ansvar for Business Central: Hvorfor kan en medarbejder gøre noget, man ikke havde regnet med? Permissions Overview, som har været tilgængelig siden maj, er en nyttig mulighed i den undersøgelse. Forestil dig, at en kollega kan redigere kundeoplysninger, og den systemansvarlige vil forstå, hvor adgangen kommer fra. Ingen har endnu besluttet, at den er forkert. Alex, hvordan hjælper oversigten dig i gang, før du ændrer nogens rettigheder?

• Definér detaljerede rettigheder
• Gennemgå bruger- og grupperettigheder på tværs af apps

Den giver dig en vej fra det objekt, du undersøger, til de rettighedssæt, der indeholder rettigheder til det, på tværs af de installerede apps og extensions. I dit eksempel kunne jeg begynde med den relevante kundeside eller tabel i stedet for at gætte ud fra rettighedssættenes navne. Oversigten kan filtreres efter objekt, rettighedssæt eller extension. Derefter viser faktaboksene med brugere og sikkerhedsgrupper, hvor det valgte sæt er tildelt. Så bliver “nogen kan redigere det her” til en mere konkret undersøgelse: Hvilke sæt er involveret, og hvem har dem? En rettighed til en side forklarer ikke alene alle mulige ændringer. Men nu har du noget konkret at følge, frem for en liste med betryggende rollenavne.

• Definér detaljerede rettigheder

Et betryggende navn er en ret tynd forklaring, når man ser en uventet ændring. En konkret rettighed i et tildelt sæt giver os noget mere håndfast. Men fortæller det mig alt, hvad netop den kollega kan gøre, eller kun hvor en del af adgangen kommer fra?

Kun en del af billedet. Det er nyttigt at finde tildelingen, men for netop den kollega ville jeg også undersøge de effektive rettigheder, Effective Permissions, for at se, hvilke rettigheder vedkommende faktisk har. Det er et spørgsmål om brugeren, ikke kun om indholdet af ét sæt. Og der er et konkret adgangskrav til den undersøgelse: For at se andre brugeres effektive rettigheder skal man have SECURITY eller SUPER. Det gælder den, der undersøger sagen. Det er bestemt ikke et forslag om at give kollegaen SUPER for at finde ud af, hvilken adgang vedkommende har.

• Definér detaljerede rettigheder

Lad os sige, at undersøgelsen peger på et rettighedssæt, der er tildelt via en gruppe. Kollegaen har fået nye arbejdsopgaver, mens resten af teamet stadig laver det samme. Hvis den systemansvarlige ændrer sættet, løser det så kun den ene persons adgangsproblem?

Nej, så ændrer man det fælles rettighedssæt for alle, der har det. Hvis resten af teamet stadig skal redigere kunder, rammer man det forkerte problem ved at fjerne rettigheden fra deres fælles sæt. I dit eksempel ville jeg undersøge, hvordan kollegaens nye opgaver skal afspejles i tildelingerne eller gruppemedlemskabet, frem for straks at ændre, hvad hele teamets rolle tillader. Her er faktaboksene med brugere og sikkerhedsgrupper nyttige, fordi de viser, hvor sættet bliver brugt. Man kan se, hvem en foreslået ændring rækker ud til, før man forveksler én persons jobskifte med en ændring af alles arbejde.

• Definér detaljerede rettigheder

Du nævnte også, at man kan filtrere efter extension. Kan den systemansvarlige bruge det, før der sker noget uventet? De har måske installeret en app og vil forstå de rettighedssæt, den leverer, frem for at vente på spørgsmålet om, hvorfor en kollega kan redigere noget.

• Definér detaljerede rettigheder
• Gennemgå bruger- og grupperettigheder på tværs af apps

Ja, og det er en nyttig samtale at tage, mens appen bliver indført. Filtrér oversigten til extensionen, se på rettighederne i dens sæt, og undersøg derefter, hvor sættene er tildelt. Så har du noget konkret at tale med den ansvarlige for implementeringen om: Dette sæt omfatter disse objekter. Hvilke arbejdsopgaver skal det understøtte? Derefter kan du sammenholde hensigten med de tildelinger, du kan se. At en rettighed er defineret i en app, er ikke det samme som, at en bestemt kollega har den. Den skelnen gør samtalen klarere. Du lærer, hvordan appen passer ind i teamets arbejde, uden at ændre nogens adgang bare for at undersøge det.

• Definér detaljerede rettigheder

Den overraskede systemansvarlige kan jo opdage, at kollegaen har præcis den adgang, jobbet kræver. Der skal slet ikke fjernes noget. Ville du stadig kalde det et nyttigt resultat af oversigten, selv om ikke en eneste rettighed er blevet ændret?

Bestemt. “Vi ved, hvorfor adgangen findes, og den ansvarlige for rollen er enig i, at den er nødvendig” er et langt bedre svar end: “Det er nok fint.” Det nyttige resultat er en forklaring, man kan stå inde for, ikke en ændret indstilling for ændringens skyld. Det giver også et klarere udgangspunkt, hvis medarbejderens opgaver ændrer sig senere. Nogle gange er det mest værdifulde ved en undersøgelse, at man kan lade en velfungerende opsætning være, fordi man ved, hvorfor den ser sådan ud.

Nu en kort besked til administratorer af Business Central on-premises, også installationer med Dual Use Rights. Det er ikke en besked til dem, der blot bruger onlinetjenesten. Fra første oktober hedder licensnøgleversionen til Business Central 28 og senere “28 plus”. Tidligere versioner beholder deres versionsspecifikke nøgler. Det kan lyde som én nøgle til alle kommende opgraderinger. Alex, hvad ændrer det plustegn egentlig, når den næste opgradering skal gennemføres?

• Ændring af versionsbetegnelser for Business Central-licensnøgler

Versionsbetegnelsen kan genbruges. Den downloadede fil bliver ikke en licensfil, man kan beholde uændret til alle fremtidige opgraderinger. Microsoft siger, at downloaddatoen afgør, hvilke objekter 28-plus-filen låser op for. Når man opgraderer til en ny version udgivet fra første oktober og frem, skal man stadig hente en opdateret nøgle. Så jeg ville beholde det trin i forberedelsen til opgraderingen, frem for at se “28 plus” på en gammel fil og antage, at opgaven er løst. Den nyttige forskel er mellem betegnelsen og indholdet af den fil, man faktisk har hentet. Samme betegnelse betyder ikke nødvendigvis samme frigivne objekter.

• Ændring af versionsbetegnelser for Business Central-licensnøgler

Det kan en opgraderingstjekliste, der kun kontrollerer betegnelsen, overse. For lige at skille tingene ad: Ændrer det her forberedelsen af licensfilen, eller ændrer det også, hvornår administratorerne forventes at opgradere?

• Ændring af versionsbetegnelser for Business Central-licensnøgler

Meddelelsen siger udtrykkeligt, at udgivelsescyklussen for hovedversioner og mindre versioner ikke ændres. Så jeg ville ikke læse plustegnet som en ny tidsplan for opgraderinger. At vælge og planlægge opgraderingen er én beslutning. At klargøre en opdateret licensfil til den er en anden. For administratoren, der lytter med, er den nyttige handling ret lille: Sørg for, at forberedelsen kontrollerer nøglens downloaddato, og at den passer til målversionen, ikke kun om versionsbetegnelsen siger 28 plus.

• Ændring af versionsbetegnelser for Business Central-licensnøgler

Tilbage til en lille lettelse i hverdagen, og denne gang er den ny i oktoberudgivelsen: et bogmærke til en bestemt analysevisning på dit rollecenter. Forestil dig, at du har sat en analyse af vareposter op, så du kan se antal fordelt på lokationer. Du vil tilbage til netop den opstilling, ikke bare finde siden igen. Alex, hvad åbner der, når man bruger det nye bogmærke?

• Analysér data fra listesider og forespørgsler

Du lander på siden eller forespørgslen direkte i analysetilstand med netop den visning valgt. Så din opstilling med antal pr. lokation er selve destinationen, ikke noget du først skal finde frem til, når den almindelige side er åbnet. Det er en lille forskel, men hvis det er sådan, du starter en fast gennemgang af lageret, slipper du for den lille omvej hver gang. Og det er en genvej tilbage til analysen, ikke et gemt billede af tallene. Du vender tilbage til den visning, du vil arbejde i, ikke en rapport, der blev fastfrosset, da du lavede bogmærket.

• Analysér data fra listesider og forespørgsler

Hvis jeg har flere visninger af den samme side, vil jeg gerne kunne kende forskel på dem i menuen. Hvad kommer bogmærket til at hedde, og følger navnet med, hvis jeg omdøber visningen?

Det kombinerer navnet på siden eller forespørgslen med analysevisningens navn, så du kan skelne mellem de forskellige indgange til samme side. Og ja, omdøber du visningen, bliver bogmærkets tekst også opdateret. Sletter du visningen, forsvinder dens bogmærke. Det kan jeg godt lide: Du vedligeholder én visning og en genvej til den, ikke en ekstra selvstændig kopi, som langsomt kommer ud af trit. Et tydeligt navn på visningen hjælper altså både i menuen og inde i selve analysen.

• Analysér data fra listesider og forespørgsler

Lige en praktisk detalje, inden nogen prøver: De har deres analysevisning, men kan ikke se “Bookmark view” i menuen. Hvilken forudsætning skal de så kontrollere?

Kontrollér, om tilpasning er slået til. Handlingen Bookmark view er ikke tilgængelig, når den mulighed er deaktiveret. Så før du konkluderer, at funktionen mangler eller er defekt, så spørg administratoren, hvordan brugertilpasning er tænkt i jeres opsætning. Når muligheden er tilgængelig, er det en nem genvej til en visning, du bruger ofte.

• Analysér data fra listesider og forespørgsler

Det er et godt sted at slutte: mindre arbejde med at komme hen til det, man faktisk skal bruge. Dagens standardmuligheder kan fjerne en kodeopgave, en omvej i navigationen eller en bogføring, der reelt er dobbeltarbejde. Men beslutningerne bagved forsvinder ikke. Flytter man vedhæftninger, skal nogen stadig tage sig af filerne. Forenkler man en overflytning, skal man ikke samtidig fjerne en reel kontrol af, at varerne er ankommet. Spørgsmålet er, hvilket arbejde jeres team kan undvære uden at miste noget vigtigt. Tak, fordi du lyttede til Business Central Podcast fra ITrators. På genhør.