Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg er Emma, og her er også Alex. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag undersøger vi nogle muligheder, der kan spare virksomheden for unødigt arbejde: at finde en forbindelse, man måske allerede har, at fordele en fælles omkostning og at få øje på en ændring, nogen bør reagere på. Noget er nyt, andet er eksisterende funktioner med en nyttig pointe. Den forskel holder vi fast i. Lad os komme i gang.

Vi begynder med et spørgsmål, der kan dukke op, før en integration overhovedet er blevet et projekt: Kan vores andet system hente den her oplysning fra Business Central? Med version 29 kommer API Overview, et overblik over de publicerede grænseflader i det aktuelle miljø, også dem fra installerede udvidelser. Hvad gør det ved den første samtale, Alex? Jeg vil gerne have, at virksomheden kommer lidt længere end til, at nogen nok skal bygge noget.

• Discover APIs with the API Overview page

Det giver samtalen et konkret sted at begynde. Et API er en grænseflade, et andet program kan bruge, i stedet for at en person åbner en side og kopierer en oplysning. Forestil dig, at virksomheden vil vise en bestemt status i et andet system. Før vi tegner en ny forbindelse, kan vi undersøge, hvad netop dette miljø allerede stiller til rådighed. Ikke bare hvad standardproduktet generelt kan. Så bliver spørgsmålet mindre: Findes der allerede en grænseflade, som giver os den oplysning, vi faktisk har brug for?

• Discover APIs with the API Overview page
• REST API web services

Det mindre spørgsmål kan jeg godt lide. Men en lang liste kan stadig være en lidt omstændelig måde at sende medarbejderen videre til en udvikler på. Man kan filtrere efter udgiver, gruppe og version. Hvad skal kollegaen have med til samtalen, så det bliver opgaven, der styrer søgningen, og ikke bare det første tekniske navn, der ser lovende ud?

• Discover APIs with the API Overview page

Et konkret eksempel på oplysningen og på, hvad den skal bruges til. I vores tænkte virksomhed kan status betyde, at et bilag er oprettet, eller at selve arbejdet er færdigt. Det er ikke nødvendigvis det samme. Jeg ville bede kollegaen vise den relevante post og forklare, hvilken beslutning det andet system skal træffe. Så kan udvikleren undersøge grænseflader og felter i forhold til det eksempel. Udgiver og gruppe gør søgningen mere overskuelig. Men det er betydningen i virksomhedens arbejde, der afgør, om vi har fundet et brugbart svar.

• Discover APIs with the API Overview page
• REST API web services

Så vil jeg gøre eksemplet en lille smule mere besværligt. Først skal det andet system bare vise den status. Så siger nogen: Når vi nu alligevel forbinder det, kan vi så ikke også ændre posten derfra? Det er en enkelt ekstra sætning i ønskelisten. Er det også en enkelt ekstra sætning i arbejdet?

Den sætning kan ændre, hvilken grænseflade der passer. Overblikket skelner mellem API-sider, forespørgsler og codeunits. En forespørgsel er kun til læsning. API-sider understøtter læsning og skrivning, mens codeunits kan udstille bestemte procedurer som selvstændige handlinger. Hvis vi har fundet en forespørgsel, der løser visningen fint, bliver den altså ikke til en skrivefunktion, fordi ønsket vokser. Og en API-side garanterer heller ikke, at netop den ønskede ændring er mulig. Jeg ville holde det oprindelige behov for at læse adskilt fra det nye behov for at skrive.

• Discover APIs with the API Overview page

Det forklarer også en detalje i Microsofts vejledning, som ellers kunne ligne en fejl: For codeunits er API-adressen med vilje tom i overblikket. Hvis nogen sender et skærmbillede og siger, at der mangler et link i rækken, skal vi altså ikke straks gøre det til en sag om en integration, der er gået i stykker.

• Discover APIs with the API Overview page

Nej, rækken peger på en anden type mulighed. Det tomme felt er ikke dokumentation for en fejl. Udvikleren skal undersøge, hvilken handling der bliver stillet til rådighed, og om den svarer til det, virksomheden vil gøre. Det er mere nyttigt end at prøve tilfældige adresser. Overordnet er siden et katalog, ikke en guide, der opretter integrationen for os. Den konfigurerer ikke API'et og giver ikke adgang. Vi kan godt have fundet en lovende grænseflade og stadig mangle opsætning af autentifikation og rettigheder, før et andet system kan bruge den.

• Discover APIs with the API Overview page

Den resterende opsætning må bare ikke få lov til at sluge den gode nyhed. Det er stadig værdifuldt at opdage, at virksomheden allerede har en brugbar grænseflade. Især hvis den fulgte med en udvidelse og derfor ikke var det første, man ledte efter i standardproduktet. Men så ændrer det vel også, hvem jeg skal spørge, hvis betydningen af et felt er uklar?

• Discover APIs with the API Overview page

Ja, her bliver oplysningen om udgiveren nyttig. Den hjælper os med at finde dokumentationen og den, der ejer grænsefladen. Jeg ville ikke gå ud fra, at et felt fra en udvidelse betyder det samme som et standardfelt med et lignende navn. Men du har ret i værdien: Vi undersøger noget, der allerede eksisterer. Hvis det opfylder behovet, kan resultatet være en forbindelse og en omhyggelig afprøvning, frem for ny kode, som virksomheden bagefter skal vedligeholde. Det er et godt resultat, også selv om der ikke kommer et stort udviklingsprojekt ud af det.

• Discover APIs with the API Overview page
• REST API web services

Og så er der en lille navnefælde i listen. Version 29 af Business Central betyder ikke, at grænsefladen også skal hedde version 29. Overblikket viser API-versioner, og adresserne indeholder også versionsoplysninger. Jeg kan godt forestille mig, at nogen sorterer en ellers relevant mulighed fra, fordi der står version to, og den derfor ser gammel ud.

• Discover APIs with the API Overview page
• API endpoint structure

Tallene beskriver forskellige ting. Produktversionen og API-adressen følger ikke én fælles tæller. Jeg ville se på den dokumenterede grænsefladeversion, det miljø, vi vil forbinde til, og normalt også det regnskab, vi skal læse fra. Det sidste er vigtigt i vores eksempel med status. Det hjælper ikke meget at finde den rigtige type oplysning, hvis det andet system henter den fra det forkerte regnskab. Den præcise opbygning af adresserne tager vi i afsnitsnoterne. Men hvilket regnskab oplysningen skal komme fra, kan medarbejderen sagtens hjælpe med at afklare.

• API endpoint structure

Så ville jeg tage to eksempler med, ikke kun det nemme. Én post, hvor arbejdet faktisk er færdigt, og én, hvor bilaget er oprettet, men arbejdet stadig mangler. Hvis det andet system behandler dem ens, kan forbindelsen jo være teknisk vellykket og stadig give medarbejderen det forkerte svar.

De to eksempler ville jeg bruge i afprøvningen. Lad det andet system vise forskellen, og sammenhold svaret med de underliggende poster og det, medarbejderen skal afgøre. Det siger mere end, at et kald gav data tilbage. Hvis grænsefladen understøtter forskellen, har vi en god kandidat. Hvis den ikke gør, har vi fundet et konkret hul i funktionaliteten, frem for at antage, at alt skal bygges om. API Overview har ikke lavet integrationen. Det har gjort det lettere at begynde med viden om, hvad der findes, i stedet for et tomt udviklingsoplæg.

• Discover APIs with the API Overview page
• REST API web services

Her er en beslutning, hvor jeg ikke er sikker på, at mere automatik nødvendigvis er bedre. Virksomheden skal fordele en fælles omkostning mellem afdelinger. Fordelingskonti kan fordele beløb fra bilag og finanskladdelinjer efter en fast eller variabel nøgle. Det er en eksisterende funktion, ikke en nyhed fra oktober. Min første tanke ville være en klar, aftalt fordeling, som alle forstår. Hvorfor skulle jeg vælge en, der ændrer sig?

• Allocate revenue and costs to multiple general ledger accounts

Det er heller ikke sikkert, du skal. Hvis aftalen er, at to afdelinger tager henholdsvis tres og fyrre procent, og det stadig giver mening, er en fast fordeling en enkel måde at udtrykke det på. Den bliver ved med at bruge den nøgle, indtil nogen ændrer opsætningen. En variabel fordeling bliver interessant, når virksomheden vil lade andelen følge noget, der faktisk ændrer sig. For eksempel kan en fælles medarbejderrelateret omkostning følge antallet af ansatte i afdelingerne. Spørgsmålet er ikke, om variabel lyder mere avanceret, men om medarbejderantal er det grundlag, virksomheden ønsker.

• Allocate revenue and costs to multiple general ledger accounts

Lad os blive ved de to afdelinger. Den ene vokser kraftigt, mens den anden beholder samme størrelse. Aftalen om tres og fyrre procent er stadig nem at forstå, men nu spørger den ene leder, hvorfor regningen ikke følger med. Der kan jeg godt se ideen i medarbejderantal. Jeg er bare mindre begejstret, hvis løsningen er endnu et regneark, som nogen skal huske at kopiere ind i systemet.

Den vedligeholdelse ville jeg ikke få til at forsvinde i forklaringen. Business Central kan bruge statistiske konti til tal som medarbejderantal og kombinere dem med dimensioner i den variable fordeling. De statistiske poster er ikke finansielle debet- og kreditposter og indgår ikke i saldobalancen. Men nogen skal stadig levere de relevante tal. Når vi skifter fra en aftalt procentsats til medarbejderantal, vælger vi derfor også en måde at holde det antal aktuelt på. Beregningen kan godt være matematisk korrekt på et forældet grundlag. Så er regnestykket rigtigt, uden at fordelingen nødvendigvis er nyttig.

• Allocate revenue and costs to multiple general ledger accounts
• Analyze Data with Statistical Accounts

Så vil jeg ændre mit forslag. Jeg ville ikke begynde med at slå variabel fordeling til. Først ville jeg spørge lederne, hvilket medarbejderantal de mener. Er det antallet ved månedens slutning, eller det, der passer til den periode, regningen dækker? En afdeling i vækst kan jo have en god grund til at interessere sig for den forskel, ikke kun for om totalen stemmer.

Det ville ændre den opsætning, jeg ville undersøge. Variabel fordeling har en beregningsperiode, og grundlaget kan afgrænses med filtre. Jeg ville få perioden til at passe med aftalen og så kontrollere de registrerede statistiske tal for den. Det nyeste tal, vi tilfældigvis har, må ikke ubemærket erstatte det mål, lederne har aftalt. Og de kan sagtens ende med at vælge en fast nøgle, som bliver vurderet med mellemrum. Hvis det variable grundlag kræver mere vedligeholdelse, end præcisionen er værd, er den enklere løsning ikke blevet dårlig, bare fordi der findes en mere avanceret.

• Allocate revenue and costs to multiple general ledger accounts
• Analyze Data with Statistical Accounts

Der er heldigvis en måde at gøre den diskussion mindre abstrakt på: Med Test Allocation kan man angive et prøvebeløb. Hvis jeg skulle forklare forskellen til de to ledere, ville jeg hellere vise en genkendelig regning end en skærm fuld af opsætningsfelter. Hvad ville du kigge efter i sådan en prøve?

• Allocate revenue and costs to multiple general ledger accounts

Jeg ville vælge et beløb, der er let at gennemskue. Med en tænkt omkostning på ti tusind kroner giver tres og fyrre procent seks tusind og fire tusind. Så har alle en forventning, før vi prøver noget. Med medarbejderantal ville vi i stedet regne de forventede andele ud fra den aftalte periodes tal. Bagefter skal vi se, hvor beløbene lander, også på konti og dimensioner, ikke kun om summen stadig er ti tusind. En korrekt total kan skjule en forkert destination. Prøven gør det muligt at tale om resultatet, før det er bogført.

• Allocate revenue and costs to multiple general ledger accounts

Den forkerte destination kan godt give et meget langt møde. Lad mig føje en undtagelse til regningen: Det meste er fælles, men en mindre del vedrører kun den ene afdeling. Den forskel skal jo ikke forsvinde, fordi vi har fået en bekvem fordelingsfunktion. Binder fordelingskontoen os til at acceptere dens første resultat?

Nej. Redistribute Account Allocations giver mulighed for at justere før bogføring, og i finanskladden kan man få en forhåndsvisning af den foreslåede bogføring. Med din undtagelse ville jeg først skille denne regning fra den generelle regel. En enkelt udgift til én afdeling betyder ikke nødvendigvis, at alle fremtidige regninger skal have en anden fordeling end tres og fyrre. Vi ville gennemgå bilaget og fordelingen, så undtagelsen lander det rigtige sted, og derefter kontrollere bogføringen. Det er noget andet end at ændre den genbrugelige opsætning alene for at få dagens regning til at passe.

• Allocate revenue and costs to multiple general ledger accounts

Inden nogen prøver det i den faste månedsrutine, er der en grænse, vi skal have med. Microsoft siger udtrykkeligt, at fordelingskonti ikke understøttes i gentagelseskladder, selv om valget vises som kontotype. Det er en lidt uheldig invitation. Hvis virksomheden allerede fordeler en tilbagevendende omkostning i en gentagelseskladde, hvad skal den så bruge?

• Allocate recurring costs and income

Den kladdes egen handling til fordelinger. Her kan fordelingsnøglen bygge på antal, procenter eller beløb. Så virksomheden kan allerede være det rigtige sted til sin tilbagevendende proces og behøver ikke flytte den, bare fordi fordelingskonti også findes. Der er desuden en konkret begrænsning for fordelingskonti i kladdenavne med en godkendelsesarbejdsgang for oprettelse af kladdelinjer. Derfor skal vi kontrollere den faktiske kladde og arbejdsgang, før vi foreslår en ændring. Det er ikke det samme som at sige, at fordelinger og godkendelser aldrig kan fungere sammen noget sted i Business Central.

• Allocate recurring costs and income
• Work with general journals

Det gør mig mindre interesseret i at erstatte en månedsrutine, der virker, og mere interesseret i de regninger, som stadig bliver fordelt i hånden. Der er også et valg, Inherit from parent, hvor fordelingen kan bruge finanskontoen fra selve linjen. Jeg kan se fordelen, hvis samme afdelingsfordeling gælder flere slags udgifter. Bliver resultatet så sværere at gennemskue?

• Allocate revenue and costs to multiple general ledger accounts

Det kan det, og Microsoft peger selv på, at det er mindre gennemsigtigt. Har fordelingen en fast destinationskonto, kan du se kontoen direkte i opsætningen. Når den arver fra linjen, skal du også kende den finanskonto, der er valgt på bilaget eller i kladden. Det kan være nyttigt, hvis den samme afdelingsnøgle skal bruges på forskellige omkostningskonti. Men den, der kun ser fordelingsopsætningen, mangler en del af billedet. Derfor ville jeg lade den konkrete linje og bogføringsvisningen indgå i kontrollen. Genbrug fjerner ikke behovet for at forstå, hvor beløbet ender.

• Allocate revenue and costs to multiple general ledger accounts

Jeg begyndte med at foretrække den enkleste aftalte procent, og den kan jeg stadig godt lide, når aftalen er stabil. Men nu har jeg en bedre grund til at vælge variabel fordeling end bare mindre manuelt arbejde: Omkostningen kan følge et mål, som virksomheden faktisk mener er mere rimeligt. Arbejdet forsvinder ikke. Noget af det flytter til at aftale og vedligeholde grundlaget. Det vil jeg hellere gøre tydeligt end love økonomiafdelingen en månedslukning uden besvær.

Nu en mindre opdagelse til dem, der planlægger produktion. I Business Central 29 bliver det tydeligere, hvor langt de beregnede kapacitetskalendere rækker. Arbejds- og maskincentre har feltet Calendar Entries Available Until. Forestil dig en planlægger, der ser på arbejde efter årsskiftet. Før diskussionen om, hvorvidt produktionen kan nå det, kommer et mere grundlæggende spørgsmål: Har vi overhovedet beregnet kalenderen så langt frem? Hvad fortæller datoen, Alex?

• Set up shop calendars
• Update 29.0 for Business Central 2026 release wave 2

Den viser den seneste dato, der er beregnet kalenderposter for. Det er grænsen for de beregnede oplysninger, ikke et løfte om ledig kapacitet alle dage frem til datoen. Beregningen bygger på arbejdstiderne og centrets kapacitetsopsætning. Hvis planlæggeren kigger ind i januar, men posterne stopper i december, er det altså en anden situation, end hvis januar er fuldt optaget eller har færre arbejdsdage. Når grænsen bliver synlig, er det lettere at stille det rigtige spørgsmål, før man fortolker planen.

• Set up shop calendars

Advarslen har også en bestemt grænse: En dato før arbejdsdatoen får en advarselsmarkering. Det er nyttigt, når noget allerede er udløbet. Men vores planlægger ser fremad. December kan jo stadig ligge i fremtiden og samtidig være for kort en horisont til det arbejde, der skal planlægges i januar.

• Set up shop calendars

Derfor ville jeg sammenligne selve datoen med den periode, vi vil planlægge, i stedet for at vente på en advarsel. Et tomt felt bliver heller ikke markeret som udløbet. At der ikke er en markering, beviser altså ikke, at kalenderen dækker perioden. Til januars arbejde skal vi undersøge, om de relevante centre har beregnede poster frem til de nødvendige datoer. Hvis ikke, angiver man start- og slutdato i kalenderberegningen. Det nye felt gør manglen lettere at opdage; det forlænger ikke kalenderen af sig selv.

• Set up shop calendars

Lad os sige, at de forlænger kalenderen, men januar stadig ser tyndere ud end forventet. Så skal de vel ikke bare blive ved med at beregne længere og længere frem, fordi det var det første, vi undersøgte. Nu må spørgsmålet være, hvad de enkelte dage i januar faktisk indeholder?

Ja. Den tilknyttede produktionskalender leverer arbejdsdage og skift, og centrets kapacitet og effektivitet spiller også ind. Ugedage uden opsætning og definerede helligdage har ingen tilgængelig kapacitet. Registreret fravær kan også reducere en dags kapacitet. Jeg ville se på de beregnede dage i kalenderen eller matrixen og sammenligne med den arbejdstid, der er meningen. Er dagen bevidst arbejdsfri, eller passer opsætningen ikke til centret? Det giver forskellige beslutninger. At forlænge de samme forudsætninger ind i endnu en måned fortæller os ikke, hvilken forudsætning der eventuelt er forkert.

• Set up shop calendars

Det er en nyttig forskel at få frem: Vi har ikke beregnet så langt, er noget andet end, at vi ikke arbejder den dag. Jeg kan godt lide det som en lille hjælp til planlæggeren, ikke som et løfte om, at planlægningen nu klarer sig selv. Slutdatoen peger på, hvor man skal kigge, og kalenderen hjælper med at forstå, hvad der er beregnet.

• Set up shop calendars

Der er en anden forskel, som også kan spare en del forvirring: at rette det, systemet viser, er ikke det samme som at ændre det, der er sket uden for systemet. Hvis en levering er bogført forkert, skal virksomheden kunne rette registreringen. Men en fortrydknap får ikke varerne til at rejse baglæns. Det er især værd at huske, når leverandøren sender direkte til kunden.

• Make drop shipments

Og netop den proces har fået en nyttig forbedring. Siden april kan Business Central tilbageføre en bogført direkte levering, når både salgsleverancen og den tilknyttede købsmodtagelse stadig er ufakturerede. Direkte levering betyder her, at leverandøren sender til kunden, mens købs- og salgsbilagene hænger sammen i systemet. Det er altså ikke en intern overførsel mellem virksomhedens lokationer. Hvorfor er det så vigtigt, at betingelsen gælder begge sider, Alex?

• Make drop shipments
• Reverse drop shipments when sales and purchase documents aren't invoiced

Fordi vi ikke kun retter en løs salgspostering. Handlingen Fortryd levering starter på den bogførte salgsleverance, og Business Central tilbagefører også den tilknyttede købsmodtagelse. Der bliver oprettet korrektionsposter, og salgs- og købsposterne bliver udlignet med deres tilbageførsler. Derfor skal begge sider stadig være ufakturerede for at bruge den dokumenterede mulighed. Det er ikke nok at se, at kunden endnu ikke er faktureret. Den, der undersøger fejlen, må også finde købsmodtagelsen og kontrollere dens status, ikke slutte sig til den ud fra salgsbilaget.

• Make drop shipments

Så lad os skille to fejl ad. I den ene situation har virksomheden registreret en levering, som endnu ikke er sket. I den anden har kunden faktisk fået varerne, men nogen vil nu ændre ordren. En tilgængelig fortrydknap kan se fristende ud i begge situationer. Men det er jo to meget forskellige samtaler med kunden og leverandøren.

Ja, og din anden situation er netop grunden til at få de fysiske forhold på plads, før vi vælger rettelsen. Funktionen giver en vej til at tilbageføre posteringer, der opfylder betingelserne. Den afgør ikke, om kunden har varerne, om kunden skal beholde dem, eller hvad parterne har aftalt. I første situation kan det være registreringen, vi skal rette. I den anden skal virksomheden også håndtere den faktiske levering og den kommercielle aftale. At en teknisk mulighed er tilgængelig, fortæller ikke i sig selv, at den beskriver det rigtige forløb.

• Make drop shipments

Og hvis bare den ene side allerede er faktureret, skal vi holde op med at kalde det den samme hurtige fortrydelse. Den grænse vil jeg gerne opdage tidligt, før nogen har planlagt hele rettelsen omkring en knap, de ikke kan bruge til formålet. Hvad ville du bede den, der melder fejlen, om at finde frem?

• Make drop shipments

Den bogførte salgsleverance, den tilknyttede købsmodtagelse, begge siders fakturastatus og en enkel beskrivelse af, hvad der er registreret forkert. Samt hvad der faktisk er sket med varerne. Så undgår vi, at sagen vandrer mellem salg, indkøb og økonomi, mens alle kun ser deres eget bilag. Hvis begge sider er ufakturerede, og Fortryd levering er den rette rettelse, kan vi bruge den understøttede vej. Bagefter ville jeg kontrollere korrektionsposterne og begge sammenhængende sider. Er én side faktureret, må den passende korrektionsproces vurderes i stedet for at strække denne funktion ud over dens betingelse.

• Make drop shipments

Jeg er glad for, at du siger korrektionsposter. Fortryd kan lyde, som om den oprindelige bogføring bare forsvinder. For den kollega, der senere skal forklare historikken, er det jo noget andet, om der ligger en rettelse, eller om en tidligere registrering tilsyneladende er væk.

• Make drop shipments

Det er det. Den beskrevne proces opretter rettelser og udligner posterne med deres tilbageførsler. Det er ikke en beskrivelse af, at den oprindelige historik bliver slettet. Man har et oprindeligt forløb og en korrektion, som kan undersøges sammen. Forbedringen er, at en fejlagtigt bogført direkte levering, som opfylder betingelserne, har en understøttet vej tilbage på både salgs- og købssiden. Det kan fjerne en reel forhindring for at få registreringen på plads. Vi skal stadig forstå, hvorfor den var forkert.

• Make drop shipments

Den sidste funktion handler om at opdage en ændring, mens nogen stadig kan bruge oplysningen til noget. Business Central har allerede feltovervågning: Udvalgte felter kan logges, og udvalgte ændringer kan udløse en mail. Registreringen kan vise den gamle og den nye værdi, hvem der ændrede feltet, og hvornår. Det er ikke en ny oktoberfunktion. Men den er let at overse, hvis samtalen hopper direkte fra, at vi gerne vil kende ændringerne, til, at vi må anskaffe et nyt overvågningssystem.

• Audit changes

Og det vigtige ord er udvalgte. Man kan vælge, hvilke væsentlige felter der skal følges, og om en ændring kun skal logges eller også give besked. Jeg ville begynde med noget, der har en klar konsekvens for virksomheden, ikke med at overvåge alt, fordi muligheden findes. En ændring af en vigtig betalingsoplysning er et tænkt eksempel. Men før jeg vælger mail, vil jeg vide, hvad modtageren skal gøre. Skal personen kontrollere ændringen, eller håber vi, at selve beskeden forhindrer et problem?

• Audit changes

Jeg vil have personen til at kontrollere den. En helt legitim rettelse skal ikke behandles som en hændelse, hver gang nogen skriver noget nyt. Hvis betalingsoplysningen er ændret med god grund, er det nyttigt, at den rette person hurtigt kan få det afklaret. Men en afsendt mail skal heller ikke blive hele kontrollen. At noget er landet i en indbakke, er en meget lille del af at få et svar.

Så ville jeg beskrive opsætningen som et signal til en aftalt kontrol, ikke som en automatisk dom. Den gamle og nye værdi, brugeren og tidspunktet hjælper med at finde ændringen og stille et konkret spørgsmål. De beviser ikke, om ændringen var godkendt, eller om nogen har handlet forkert. Feltovervågning er heller ikke et godkendelsestrin, der stopper redigeringen. Derfor skal en person vide, hvordan ændringen undersøges, og hvad næste skridt er, hvis den ikke kan bekræftes. Funktionen gør ændringen synlig. Virksomheden står stadig for vurderingen.

• Audit changes

Det gør valget om kun at logge ret interessant. Der kan være ændringer, jeg gerne vil kunne undersøge senere, uden at nogen skal afbrydes hver gang. Hvis alle de ændringer sender mails sammen med betalingsoplysningerne, kan det blive sværere at få øje på det vigtige. Hvordan ville du vælge, hvad der fortjener en afbrydelse?

• Audit changes

Jeg ville sammenholde konsekvensen af at vente med det, modtageren faktisk kan gøre. Hvis ændringen bør kontrolleres før næste vigtige skridt i arbejdet, kan en besked være nyttig. Hvis behovet mest er at rekonstruere et forløb senere, kan logning være tilstrækkelig. Så ville jeg se på, hvor ofte feltet normalt ændres med god grund. Mange daglige redigeringer kan give mange mails uden ret mange nye beslutninger. Det gør ikke oplysningerne uvigtige. Det betyder bare, at måden, vi retter opmærksomheden mod dem på, skal passe til arbejdet, i stedet for at gøre alle ændringer lige akutte.

• Audit changes

Der er en opsætningsdetalje, vi bør få med før den første nyttige mail. Afsenderkontoen skal være konfigureret, og funktionen bruger Microsoft 365 eller SMTP. Microsoft skriver, at kontotypen Current User ikke sender de her beskeder. Et kontovalg, man kender fra andre sammenhænge, er altså ikke nødvendigvis det rigtige til netop denne opgave.

• Audit changes

Det er netop derfor, jeg ville afprøve hele forløbet og ikke stoppe på opsætningssiden. I Monitor Field Change Setup vælger man felter, den bruger, der skal have besked, og afsenderkontoen. Når felterne er tilføjet, og overvågningen er startet, skal man logge ud og ind igen, så indstillingerne får virkning. Derefter ville jeg lave en kontrolleret ændring i en passende testsammenhæng sammen med den tiltænkte modtager. Kom ændringen i loggen? Kom mailen frem? Kan personen se, hvad der skal undersøges? Det er forskellige observationer, som en gemt opsætning ikke giver svar på.

• Audit changes

Jeg ville tilføje et lidt besværligt spørgsmål til den prøve: Hvad sker der, når den navngivne person er væk? Ikke for at gøre en lille funktion til et stort projekt. Men en vigtig besked kan jo blive leveret helt korrekt og alligevel ligge til mandag. Det ville ændre, hvilke arbejdsgange jeg turde basere på den.

Det ville jeg gøre til en del af aftalen om kontrollen, ikke antage, at denne funktion håndterer. Hvem overtager, hvor hurtigt skal der reageres, og hvad gør man, hvis ændringen ikke kan bekræftes? Dit mandagseksempel viser et hul, som en vellykket mailtest ikke afslører. Måske skal virksomheden ændre processen omkring det vigtige arbejdstrin, frem for at overvåge flere felter. Standardfunktionen kan stadig være nyttig. Vi skal bare være præcise om dens opgave: Den gør opmærksom på en ændring. Den garanterer ikke, at nogen reagerer i tide.

• Audit changes

Lad os så følge den person, der faktisk modtager beskeden. Monitored Fields Log Entries viser gammel og ny værdi, bruger og tidspunkt, og der er links tilbage mod den oprindelige side. Det er noget mere brugbart end en besked om, at et eller andet har ændret sig. Men jeg ville stadig bede personen undersøge hvorfor, i stedet for at læse forklaringen ind i et brugernavn.

• Audit changes

Ja. Registreringen afgrænser spørgsmålet: Den her værdi blev ændret til den her værdi, på det her tidspunkt, under den her bruger. Så kan man sammenholde det med den tilsigtede ændring og den forretningsmæssige sammenhæng. Loggen fortæller ikke hele historien bag beslutningen. I eksemplet med betalingsoplysninger kan både en legitim rettelse og en uventet ændring give en post. Værdien er, at der er noget konkret at undersøge. Man skal ikke først forsøge at huske den tidligere værdi eller spørge alle, om de har bemærket noget usædvanligt.

• Audit changes

En anden detalje kan spare administratoren for lidt forvirring: En tabel, der bruges til feltovervågning, kan ikke samtidig vælges i ændringsloggens opsætning. Det skal undgå dobbelt registrering. Hvis tabellen ikke dukker op begge steder, er det derfor ikke nødvendigvis en fejl. Og ændringer i selve overvågningsopsætningen giver også poster, som man kan vælge at vise eller skjule i oversigten.

• Audit changes

Så har vi to forskellige ting at undersøge: ændringen i virksomhedens data og ændringen i det, vi har sat til at overvåge dem. Hvis en forventet besked mangler, kan opsætningshistorikken være relevant. At de poster er skjult i en visning, betyder ikke, at opsætningen aldrig er ændret. Og jeg ville ikke forsøge at løse al usikkerhed ved at logge det samme flere gange. Først må vi forstå, hvad overvågningen dækker, og om den stadig passer til formålet. Ellers risikerer virksomheden at stole på en beskrivelse af kontrollen, som ikke længere svarer til opsætningen.

• Audit changes

De gamle og nye værdier er nyttige, når man har brug for dem. Men de er også oplysninger, virksomheden vælger at gemme. Jeg vil hellere tage stilling til, hvor længe historikken skal være der, end lade den vokse, fordi ingen har talt om slutningen. Er det nok at angive en opbevaringsperiode, eller er der et praktisk skridt mere?

• Audit changes
• Define retention policies

Politikken afgør, hvilke gamle data der skal slettes ud fra perioden og eventuelle filtre. Men den skal også anvendes. Business Central understøtter både planlagt behandling via opgavekøen og manuel anvendelse. Den, der sætter politikken op, skal have den relevante opsætningsrettighed. Brugeren, som afvikler det planlagte arbejde, skal kunne læse og slette de berørte data. Det er to forskellige ansvar. Jeg ville derfor kontrollere både den ønskede regel og, at behandlingen faktisk bliver kørt. En udfyldt periode på en opsætningsside fortæller ikke i sig selv, at gamle poster er blevet fjernet.

• Define retention policies

Der er en reel afvejning. Gemmer vi for lidt, kan den, der undersøger et forsinket spørgsmål, mangle den nødvendige historik. Gemmer vi alt for evigt, har vi i praksis opgivet at vælge. Jeg ville ikke løse det ved at kopiere et tal fra en anden virksomheds opsætning. Den kontrolproces, vi talte om før, må være med til at vise, hvilken historik der faktisk er nyttig.

Ja, sammen med de krav, der gælder for virksomheden. Vi kan ikke udlede én rigtig periode af funktionens beskrivelse. Det gode ved dit udgangspunkt er, at vi begynder med det spørgsmål, historikken skal kunne besvare. Ved en ændring, som skal kontrolleres hurtigt, kan vi undersøge selve kontrollen og det, der bagefter skal kunne dokumenteres. En log, der især skal bruges til senere undersøgelser, kan have et andet nyttigt tidsperspektiv. Opsætningen skal afspejle de valg. Opbevaring er ikke kun oprydning til sidst; den bestemmer også, hvad overvågningen kan fortælle os senere.

• Audit changes
• Define retention policies

Så ville jeg begynde med færre felter end på min første ønskeliste. Vælg en ændring, vi faktisk går op i, aftal hvem der kontrollerer den, og se, om oplysningerne hjælper personen til et svar. Hvis modtageren ikke ved, hvad næste skridt er, hjælper tyve ekstra beskeder ikke.

Og en legitim ændring, som hurtigt bliver bekræftet, ville jeg regne for en god anvendelse af funktionen. Ikke en skuffende alarm, fordi der ikke var noget galt. Formålet er at gøre kontrollen oplyst. Omvendt fortæller en stille indbakke ikke alene, om intet er ændret, eller om beskedforløbet kræver opmærksomhed. Derfor er den kontrollerede prøve og loggen nyttige sammen. Vi kan vælge et beskedent omfang, forstå signalet og vide, hvad der ville få os til at undersøge opsætningen igen. Det er mere solidt end at love, at enhver vigtig hændelse nok selv skal gøre opmærksom på sig.

• Audit changes

Det er et godt sted at slutte. Dagens muligheder handlede ikke alle om at bygge mere. Nogle gange var næste skridt at finde en grænseflade, der allerede findes, eller gøre grundlaget for en fordeling tydeligere. Andre gange ændrede en lille forskel beslutningen: En kalenderhorisont er ikke ledig kapacitet, og en korrektion eller en besked har stadig en bestemt opgave og en grænse. Direkte kilder og uddybende tekniske noter ligger i afsnitsnoterne. Tak, fordi du lyttede til Central Perspectives fra ITrators. Vi er tilbage med mere om Business Central, der er værd at forstå.

• Discover APIs with the API Overview page
• Allocate revenue and costs to multiple general ledger accounts
• Set up shop calendars
• Make drop shipments
• Audit changes