Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg er Emma, og sammen med Alex ser jeg på de muligheder, der er værd at kende. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag følger vi arbejdet fra en samlet leverandørfaktura til godkendelse af lagerkladder og løbende fakturering. Vi ser også på en kommende ændring for rapportintegrationer og en lille skærmfunktion, der kan være nyttig, når andre kigger med. Noget af det er kommet tidligere i år, så det hele er ikke oktobernyheder. Lad os komme i gang.

Vi begynder med en ganske almindelig faktura. Forestil dig, at virksomheden har lagt tre indkøbsordrer hos samme leverandør, som sender én samlet regning. Nu sidder bogholderen med ét bilag og flere ordrer, der skal hænge sammen. Jeg ville nødig bede leverandøren lave sit bilag om, bare fordi det er nemmere på vores skærm. Hvor ville du begynde i standard Business Central, Alex?

På købsfakturaen. Så kan medarbejderen tage udgangspunkt i den regning, der faktisk skal behandles. Er varerne modtaget, kan Hent modtagelseslinjer samle modtagne, endnu ikke fakturerede linjer fra samme leverandør og i samme valuta. Med Hent ordrelinjer kan fakturalinjer knyttes til egnede ordre- eller modtagelseslinjer, også flere kildelinjer. Dermed behøver bogholderen ikke opfinde en ny, løs beskrivelse, fordi leverandøren har samlet sine leverancer. Forbindelsen til det, virksomheden bestilte, kan stadig følges.

• Combine receipts or purchase order lines on a single invoice

Hent ordrelinjer kom i april, så det er ikke en helt ny oktoberfunktion. Og flere kildelinjer er vigtigt her. Hvis leverandøren samler emballage, vi bestilte både mandag og torsdag, kan medarbejderen så se de to forbindelser bagved? Jeg ville helst ikke nøjes med, at den samlede mængde ser rigtig ud.

• Combine receipts or purchase order lines on a single invoice
• Match purchase invoices to multiple order and receipt lines

Ja, i Matchede ordrelinjer kan sammenhængene både gennemgås og justeres, enten fra en fakturalinje eller fra fakturahovedet. Dine to bestillingsdage er en god grund til at åbne den visning. Et plausibelt samlet antal fortæller jo ikke, hvilke bestillinger der er med. Jeg ville følge linjen tilbage til de tiltænkte ordrer og mængder. Så kan fakturaen passe til leverandørens måde at samle regningen på, uden at vi mister detaljerne fra virksomhedens egne indkøb.

• Combine receipts or purchase order lines on a single invoice

Det er et rart sted at spare arbejde: færre linjer at genskabe, men stadig noget ordentligt at kontrollere. Lad os gøre situationen lidt vanskeligere. Kasserne er kommet, men modtagelsen er ikke bogført endnu. Bogholderen har fakturaen, indkøberen siger, at leveringen er i orden, og lageret har travlt. Man kan næsten høre tanken: Vi er jo så tæt på, kan vi ikke bare afslutte? Er det her, matchning og modtagelse let bliver blandet sammen?

Ja, og der findes faktisk en mulighed, som kan være nyttig. Hent ordrelinjer kan matche en ordre uden modtagelse. Separat kan Modtagelse ved fakturering oprette modtagelsen for den matchede mængde før faktureringen. Men at forbinde fakturaen med ordren er noget andet end at registrere varerne som modtaget. I dit eksempel ville jeg afklare, om bogholderen skal tage det skridt på lagerets vegne. Funktionen kan understøtte en aftalt arbejdsgang. Det bør ikke være et tilfældigt klik, der afgør, hvem der overtager ansvaret.

• Combine receipts or purchase order lines on a single invoice

Jeg ville være tryg ved det, hvis samme person tager imod varerne og behandler fakturaen. Mindre tryg, hvis bogholderen kun har en mail med: Det ser fint ud. Kan alle lageropsætninger overhovedet bruge den modtagelsesmulighed?

Nej. Modtagelse ved fakturering kan ikke bruges ved styret læg-på-lager og pluk, ved varesporing eller på linjer med en eksisterende bogført modtagelse. De grænser skal med, før man bygger en ny rutine omkring indstillingen. Dit eksempel med én person kan være egnet, men en vare med sporing eller en anden lokation kan ændre svaret. Samtidig kan matchningen stadig være nyttig, selv om automatisk modtagelse ikke passer. Vi skal ikke afvise den gode sammenhæng mellem faktura og ordre, fordi netop modtagelsesgenvejen ikke er egnet.

• Combine receipts or purchase order lines on a single invoice

Så vi holder de to ting adskilt. Der er også en leverandørpolitik med valgene Manuel og Automatisk. Det sidste lyder næsten som en knap til at få ryddet alle de gamle ordrer af bordet. Men vejledningen er tydelig: Den gælder nye, egnede ordrer, ikke dem, der allerede findes. Ændrer medarbejderen indstillingen i dag, har gårsdagens ordrer altså ikke pludselig fået en ny politik. Hvad ville du aftale, før den standardværdi tages i brug?

• Combine receipts or purchase order lines on a single invoice

Hvem der bekræfter modtagelsen. Derefter ville jeg undersøge en nyoprettet ordre i stedet for at bruge bunken af gamle som prøve. Manuel lader muligheden være slået fra, og Automatisk slår den til på egnede nye hoveder og linjer. Det er stadig ikke dokumentation for, at varerne er ankommet. Din skelnen mellem en standardværdi og en oprydning er vigtig. Ellers vurderer den første medarbejder måske funktionen ud fra en ordre, som aldrig blev ændret. Et velvalgt eksempel er mere oplysende end at slå indstillingen frem og tilbage.

• Combine receipts or purchase order lines on a single invoice

Og inden nogen tager den mest besværlige faktura frem først: Hent ordrelinjer dækker ikke forudbetalinger eller varegebyrer. Ordrer knyttet til projekter, underleverandørarbejde, rammeordrer eller intercompany er også undtaget. Det er nogle ret konkrete grænser, ikke en ny universalknap til alle indkøb. Men en virksomhed, der allerede bruger Hent modtagelseslinjer og er tilfreds, skal den overhovedet gøre noget anderledes? Eller er det nok at vide, at der findes en anden vej, hvis behovet opstår?

• Combine receipts or purchase order lines on a single invoice

Det er nok at kende muligheden. Hvis modtagelserne registreres sikkert og bagefter samles på fakturaen, ville jeg ikke lave processen om for at få en nyere handling ind. Hent ordrelinjer bliver interessant, når leverandørens samlede linje er besværlig at forbinde med flere bestillinger. Uanset vejen skal kontrollen ske før bogføring. En bogført faktura med samlede modtagelser kræver en kreditnota ved korrektion, og de færdigmodtagne, færdigfakturerede kildeordrer slettes ikke automatisk. Den samlede faktura er en hjælp til arbejdet, ikke en automatisk oprydning i alle dokumenterne.

• Combine receipts or purchase order lines on a single invoice

Lad os flytte kontrollen lidt længere frem i arbejdet. Fra en faktura til en ændring, der endnu kun er foreslået på lageret. En anden mulighed fra april er godkendelse af varekladder og indkøbs- eller planlægningsforslag. Det interessante er, at indholdet beskyttes mod ændringer, mens beslutningen afventes. Forestil dig en lageroptælling, hvor kladden er sendt til godkendelse, og medarbejderen så opdager en tællefejl. Jeg kan godt se værdien af et fast grundlag. Jeg kan også godt forstå den, der bare gerne vil rette fejlen.

• Approve requisition worksheets and item journals

Den irritation kan være reel, men låsningen har et formål. Godkenderen skal tage stilling til den kladde, der blev sendt, ikke til et indhold, som flytter sig undervejs. Mens kladdegodkendelsen afventes, er redigering, sletning og bogføring blokeret, indtil godkendelsen er afsluttet eller annulleret. På forslagene blokeres indsættelse, ændring og sletning af linjer. Hvis tællefejlen ændrer beslutningsgrundlaget, ville jeg føre kladden tilbage til forberedelsen, rette den og sende det tilsigtede indhold igen. Ikke finde en smutvej rundt om godkendelsen.

• Approve requisition worksheets and item journals

Så tidspunktet for at sende den bliver også vigtigt. Hvis de sidste reoler stadig bliver talt, kan en tidlig godkendelsesanmodning skabe flere afbrydelser end overblik. Medarbejderen skal vide, hvornår materialet er klart. Men klart må ikke betyde, at alle usædvanlige resultater er pyntet væk. En stor regulering kan jo være præcis det, godkenderen skal se. Hvilken beslutning skal vedkommende faktisk træffe, frem for bare at trykke på en grøn knap?

Ved optællingen ville jeg give godkenderen grundlag for at skelne en troværdig korrektion fra et antal på den forkerte vare eller lokation. Det er vores valg af kontrol, ikke noget en godkendelsesstatus beviser. Godkendelsen gælder kladden samlet, ikke en særskilt afstemning om hver linje. En stor difference med en god forklaring kan være rimelig. En lille difference på den forkerte vare er stadig forkert. Så din pointe om de usædvanlige resultater ændrer faktisk, hvad vi bør efterspørge: Forklaringen skal med, ikke et mere beroligende tal.

• Approve requisition worksheets and item journals

Så må vi også tænke over, hvad vi samler i samme kladde. Hvis fem mennesker lægger reguleringer fra vidt forskellige områder i den, er én godkender måske dårligt placeret til at vurdere det hele. Omvendt kan en masse bittesmå kladder betyde, at godkenderen bruger eftermiddagen på at åbne anmodninger. Der må findes noget mellem én kæmpe godkendelse og en notifikation for hver løs skrue.

• Approve requisition worksheets and item journals

Jeg ville samle arbejdet omkring en beslutning, som nogen med rimelighed kan tage ansvar for. Måske et sammenhængende optællingsområde eller et bestemt planlægningsansvar. Opsætningen kan bruge betingelser på kladdeskabelon og kladdenavn, så inddelingen har betydning for godkendelsesvejen. Men flere kladder giver ikke automatisk bedre kontrol. Hvis den samme person skal se helheden for at opdage en skævhed, kan opdelingen gøre vurderingen vanskeligere. Find først den, der kan forklare og bedømme arbejdet. Lad så strukturen hjælpe den beslutning.

• Approve requisition worksheets and item journals
• Use approval workflows

Det kalder på, at den lager- eller planlægningsansvarlige er med til at forme det, ikke bare får en ny opsætning udleveret. Microsoft nævner vare-, lageroptællings-, afgangs- og forbrugskladder samt indkøbs- og planlægningsforslag. Det ville jeg ikke læse som et løfte om samtlige kladdetyper i Business Central. Men når vi går over til et planlægningsforslag, er det en anden slags vurdering. Hvad er det så, personen godkender?

• Approve requisition worksheets and item journals

Et forslag til en plan, før det bliver til næste handling i driften. I en tænkt indkøbsfunktion kunne spørgsmålet være, om de foreslåede mængder og datoer stadig passer til det behov, man kender, eller om en usædvanlig anbefaling kræver en forklaring. Låsningen holder grundlaget fast, mens den vurdering sker. Jeg ville ikke bede godkenderen gentage alle beregninger i hånden. Hellere aftale, hvilke afvigelser der kræver faglig stillingtagen, og gøre dem synlige sammen med forslaget. Ellers har vi bare lavet en ekstra omgang tastearbejde.

• Approve requisition worksheets and item journals

Nu er godkenderen så væk, og kladden er låst. Vi kan kalde det god kontrol, mens virksomheden kalder det tirsdagens problem. Er der en almindelig vej til at få beslutningen videre til en, der er til stede?

Der er delegering blandt handlingerne, sammen med godkendelse, afvisning og kommentarer. Derfor bør fravær tænkes med i opsætningen, før det bliver et argument for at fjerne kontrollen. Brugere og notifikationer skal passe, og Godkendelsesposter giver et sted at se status. Jeg ville afprøve situationen med en fraværende godkender, før et tidskritisk arbejde bliver afhængigt af den. Kræver et trin flere godkendere, erstatter ét svar ikke alle de andre. Ruten skal svare til den beslutning, virksomheden faktisk har brug for.

• Approve requisition worksheets and item journals
• Use approval workflows

Og når godkendelsen kommer, bliver kladden så bogført automatisk? Jeg ville gerne have, at lederen ved, om klikket giver arbejdet videre eller faktisk udfører det.

• Use approval workflows

Ikke nødvendigvis. Automatisk bogføring kan være et konfigureret workflowtrin, men er ikke en indbygget konsekvens af enhver godkendelse. Jeg ville vise medarbejderne den faktiske vej, også det, der fortsat er manuelt. En god afprøvning er at sende en repræsentativ kladde, kontrollere de forventede begrænsninger undervejs og følge beslutningen frem til den aftalte handling. Tag en korrektion og en delegering med. Hvis de almindelige situationer ikke fungerer, hjælper endnu en notifikation næppe. Opsæt den kontrol, der gør arbejdet bedre, ikke det største workflow skabelonen kan rumme.

• Approve requisition worksheets and item journals
• Use approval workflows

Det passer meget godt til næste emne: løbende fakturering. Apriludgaven gav flere muligheder for at automatisere faktureringen af kundekontrakter i Subscription Billing. Mindre månedligt forarbejde er tiltalende. Men hører man ordet automatisering, kan man straks forestille sig fakturaer, ingen har set på. Dokumentationen beskriver faktisk flere niveauer: forslag, dokumenter til gennemgang og bogføring af de mere forudsigelige kontrakter. Hvor ville du begynde i en virksomhed, der er træt af at bygge den samme fakturakørsel op hver måned?

• Billing automation overview
• Reduce time spent on recurring invoicing in Subscription Billing

Jeg ville først fjerne det gentagne forarbejde uden nødvendigvis at fjerne gennemgangen. Hvis det svære er at samle det, der skal faktureres, kan automatiske forslag allerede hjælpe. Er forslagene pålidelige, men dokumentoprettelsen tager tid, kan næste skridt være kladder, der ligger klar til kontrol. Fuldautomatisk bogføring er endnu et valg, ikke adgangsbilletten til at få nogen glæde af funktionen. Og vi taler om kundekontrakter. Den dokumenterede automatisering omfatter ikke fakturering af leverandørkontrakter. Det skal være klart, før nogen planlægger begge sider af virksomheden ud fra samme mulighed.

• Billing automation overview
• Recurring billing

I vores tænkte virksomhed ville jeg begynde med fakturaer klar til gennemgang. Lad os sige, at den har en række enkle månedlige servicekontrakter, men også nogle kunder med ændringer, som kræver opmærksomhed. De få usikre skal helst ikke tvinge alle ind i en manuel rutine. Samtidig vil jeg gerne kunne se, hvilke kontrakter der faktisk kom med. Hvad afgør, hvad der hører til i den enkelte kørsel?

Forslaget vælger egnede kontraktlinjer ud fra deres næste faktureringsdato. Automatiseringsskabelonerne definerer kontrakttyper og gruppering, eksempelvis efter kontrakt, partner eller modtager. Jeg ville derfor give dine forudsigelige servicekontrakter en bevidst afgrænset skabelon og gennemgå det forslag, den laver. Grupperingen fortjener også en forretningsmæssig beslutning. Forventer kunden én samlet faktura, eller har kunden brug for adskilte dokumenter til forskellige ansvarlige? Færre fakturaer hos os er ikke nødvendigvis lettere arbejde hos den, der skal betale dem.

• Billing automation overview
• Recurring billing

Nu ødelagde du lige mit flotte, lave fakturaantal. På en rimelig måde, synes jeg. Hvis kundens to afdelinger skal bruge hver sin forklaring, har vi måske bare sendt sorteringsarbejdet over på den anden side af bordet. Jeg vil hellere måle på, om modtageren kan forstå regningen. Kan medarbejderen, som gennemgår den, finde beregningen bag beløbet, også når der er flere kontrakter i samme faktura?

Ja. Faktureringslinjerne viser beregningsdetaljerne, og efter bogføring findes de arkiverede faktureringslinjer. En bogført post, der omfatter flere kontrakter, er markeret som flere kontrakter, ikke som om der kun var én bagved. Jeg ville bruge den detalje i gennemgangen, især ved de beløb, kunden kunne spørge til. Det giver også en bedre målestok for en samlet faktura: Kan medarbejderen forklare opkrævningen uden at rekonstruere den fra hukommelsen? Sporbarheden kan gøre den samlede regning nyttig, ikke bare kortere.

• Posting documents

Så tager vi en af de besværlige situationer. Forslaget er klart om morgenen, men nogen ændrer kontrakten, før fakturaen oprettes. Måske er en servicemængde blevet rettet efter en samtale med kunden. Gårsdagens forståelse af aftalen skal helst ikke ubemærket blive til dagens faktura. Opdager forslaget, at grundlaget har ændret sig, eller skal den, der gennemgår det, også huske alle de samtaler, kollegerne har haft?

Ændrede kildelinjer kan blive markeret med, at opdatering er påkrævet, og dokumentoprettelsen bliver blokeret, indtil forslaget er opdateret. Det er en nyttig afbrydelse. Medarbejderen skal ikke gætte sig til den nye beregning ud fra gamle linjer. I dit eksempel ville jeg opdatere forslaget og gennemgå den ændrede beregning, før dokumentet oprettes. Forslaget er et arbejdsstadie, ikke en uforanderlig faktura. At forberede det tidligt kan spare tid, men det fastlåser ikke forretningens virkelighed for resten af dagen.

• Recurring billing

Flyt nu kundens opkald ét skridt frem. Fakturakladden findes, men er ikke bogført. Kan jeg stadig rette kontrakten og opdatere, eller har dokumentet ændret vejen til at få rettelsen med?

Dokumentet ændrer situationen. Den ikke-bogførte faktura blokerer de relevante ændringer i kildelinjerne. Ved en rettelse, der påvirker faktureringen, beskriver vejledningen derfor denne rækkefølge: Slet det ikke-bogførte dokument, ret grundlaget, og opret dokumentet igen. Din tanke om at rette kontrakten er altså god, men rækkefølgen betyder noget. Det ville jeg gøre tydeligt for medarbejderne. Et forslag, der skal opdateres, er én situation. Et dokument, der skal fjernes og genskabes, er en anden. Ellers leder man efter en opdateringsknap, som ikke løser problemet på det stadie.

• Recurring billing

Der er også en detalje, man let kan fejlfortolke: Når forslaget oprettes, flytter næste faktureringsdato sig frem. En fremrykket dato fortæller altså ikke alene, at kunden har fået en bogført faktura. I vores morgenkontrol ville jeg lede efter det resultat, vi ville opnå, frem for at lade datoen berolige mig. Men hvad forhindrer, at den samme kontraktperiode bliver foreslået igen og igen, mens vi får rettelserne på plads?

• Recurring billing

En kontraktlinje kan ikke foreslås to gange for samme periode. Når et forslag slettes, eller perioden ændres, bliver den næste dato tilpasset tilsvarende. Opret dokumenter arbejder på faktureringslinjer, som ikke allerede har dokumenter. Men jeg er enig i din kontrol: Skeln mellem forslaget, det oprettede dokument og den bogførte faktura. Spørger en kollega, om månedens fakturering er færdig, skal svaret fortælle, hvilket trin der faktisk er færdigt. En planlægningsdato er ikke et særligt godt svar på, hvor fakturaen blev af.

• Recurring billing

Lad os gøre månedens fakturering lidt mindre regelmæssig. Forestil dig, at en kontrakt ikke kom med i sidste kørsel, og medarbejderen vil indhente det nu. Man kunne let forvente én linje, fordi man laver én fakturakørsel. Men kørslen skal måske dække flere perioder. Hvilken dato fortæller Business Central, hvad der skal vælges, og hvilken afgør, hvor langt frem regningen skal dække?

Det er to forskellige indstillinger. Faktureringsdatoen bruges til at vælge egnede kontraktlinjer ud fra næste faktureringsdato. Fakturer til-datoen angiver slutningen af den periode, der skal faktureres, og kan forkorte eller forlænge perioden. Passer kontraktens faktureringsrytme flere gange mellem næste faktureringsdato og slutdatoen, kan forslaget indeholde flere linjer. I dit eksempel med det forsømte betyder én kørsel altså ikke nødvendigvis én periode eller én linje i forslaget.

• Recurring billing

Så to linjer for kontrakten kan være lige det, vi ønskede, ikke en dublet, der skal ryddes væk. Jeg ville gerne se perioderne, før nogen begynder at gøre forslaget pænere. Når vi indhenter en manglende fakturering, er det vel kundens aftale, vi skal holde resultatet op imod, frem for bare at sammenligne antal linjer med sidste måneds faktura?

Jo. Jeg ville først fastlægge den periode, vi vil opkræve for, og sammenholde faktureringsdetaljerne med den. Sidste måneds linjeantal er ikke en sikker definition af denne måneds opkrævning, især når en manglende periode skal med. Det giver også medarbejderen noget konkret at forklare, hvis beløbet afviger fra den sædvanlige månedsregning. Vi lover ikke et bestemt afrundings- eller fordelingsresultat her. Det nyttige er at undersøge beregningen for den faktiske kontrakt og den periode, der skal dækkes.

• Recurring billing
• Posting documents

Der ligger en mindre opdagelse til et fælles faktureringsteam her. Visningen Kun mine forslag kan skjule et forslag, som en kollega allerede har oprettet. En kontrakt, der ser ud til at mangle hos mig, mangler altså ikke nødvendigvis i processen. Jeg kunne godt blive fristet til at køre forslaget igen. Men ville det hjælpe?

• Recurring billing

Ikke hvis der allerede findes et forslag for samme kontraktlinje og periode. Den regel gælder stadig, selv om dit filter skjuler kollegaens forslag. Jeg ville kontrollere filteret og det eksisterende forslag, før nogen ændrer datoer eller forsøger at oprette noget igen. Derefter aftale, hvem der fører arbejdet videre. Ellers kan to personer hver især tro, at den anden har overset kontrakten. Det umiddelbare problem er måske bare, hvad de kan se, og hvem der har ansvaret, ikke om linjen kan faktureres.

• Recurring billing

Det ville jeg tage med, når kolleger overdrager arbejdet: Hvad er allerede foreslået, for hvilken periode, og hvem afslutter det? Det er noget mere brugbart end: Jeg kunne ikke finde det, så jeg prøvede igen.

Og så undgår vi, at et nyttigt personligt filter bliver læst som et overblik over hele teamets arbejde. Jeg ville beholde filteret, hvis det gør den daglige opgaveliste overskuelig, men se bredere, når en kontrakt tilsyneladende mangler. Vi behøver ikke fjerne en bekvemmelighed for at forstå dens grænse.

• Recurring billing

Lad os sige, at virksomheden bliver tryg ved de stabile kontrakter og også vil automatisere bogføringen. Det kan jeg godt se som en særskilt beslutning. Jeg gætter på, at det bekymrende for dig ikke er automatikken, men en alt for bred bogføringskørsel. Der kan jo ligge helt almindelige salgsfakturaer og vente af andre grunde i samme regnskab. Hvordan undgår vi, at kontraktrutinen også tager dem med?

Med de konkrete filtre på bogføringsjobbet. Den dokumenterede opsætning bruger både Recurring Billing og Auto Contract Billing, så jobbet rammer de tilsigtede dokumenter frem for uvedkommende fakturaer. Forberedelse og bogføring er adskilte jobs. Automatiseringen håndterer forslag og dokumenter, mens en separat massebogføringsrapport kan bogføre dem. Jeg ville bede administratoren vise præcis, hvad bogføringsjobbet kan vælge. Det nyttige spørgsmål er ikke kun, om det kører hver nat, men hvilke dokumenter det kan gøre til bogførte fakturaer, når det kører.

• Billing automation overview

Så en almindelig faktura, som bevidst skal blive liggende, er faktisk et godt kontrolpunkt i prøveregnskabet. Vi skal kunne se, at den bliver ladt i fred. Jeg ville også lægge en problematisk kontrakt ved siden af de korrekte. Hvis alt er perfekt i demonstrationen, ved vi jo ikke, hvad bogholderen møder næste morgen, når noget fejler. Standser én dårlig linje hele faktureringen, eller kan resten fortsætte?

Behandlingen kan springe problematiske poster over, og fejl bliver registreret i fejlloggen til kontraktfakturering. Men fejler en linje, bliver hele det berørte dokument forkastet. Derfor bliver vores beslutning om gruppering mere interessant. Flere kontrakter i samme dokument deler også dokumentets fejl. Resten af kørslen kan komme videre, mens netop den samlede faktura ikke bliver oprettet korrekt.

• Billing automation overview

Så den kundevenlige gruppering kan stadig være rigtig. Men den, der håndterer fejlene, skal nu få hele det manglende dokument på plads. Hvem ville du give ansvaret for morgenkontrollen?

En, der kan vurdere faktureringsresultatet, med en administrator til rådighed ved tekniske jobfejl. Gennemgangen bør sammenholde det forventede med de dokumenter, der faktisk blev oprettet eller bogført, og derefter bruge fejlloggen til at undersøge manglerne. Ser man kun efter, om jobbet har kørt, kan en oversprunget kontrakt forsvinde i overblikket. Efter en rettelse skal man også bekræfte, at dokumentet nu er kommet med, ikke bare at fejlbeskeden er væk. Det er mindre arbejde end at forberede alle fakturaer manuelt, men stadig en reel opgave.

• Billing automation overview
• Posting documents

Det er også en mere meningsfuld opgave end at holde øje med en fremdriftsbjælke. En praktisk detalje, inden vi går videre: Brugeren skal have rettighed til at redigere automatiseringsskabelonerne og Auto Contract Billing i brugeropsætningen. Vi skal altså ikke bare bede nogen finde en knap og forvente, at de kan sætte det hele i gang. Ville du stadig vælge fakturakladder som første niveau for vores virksomhed?

• Billing automation overview

Det ville jeg. Vi har fundet noget vigtigt at lære om gruppering, kontraktrettelser og fejl, før bogføringen bliver automatisk. Fakturakladderne fjerner arbejde, men holder de beslutninger synlige. Når den forudsigelige gruppe virkelig er forudsigelig, kan virksomheden overveje bogføringen med de rigtige filtre og en ansvarlig for undtagelserne. Den kan også vælge at blive ved kladderne. Det er ikke nødvendigvis et halvt automatiseringsprojekt. Det kan være det rigtige sted at stoppe, fordi resten af vurderingen stadig gavner arbejdet.

• Billing automation overview
• Recurring billing

Nu til en ændring, som faktisk handler om den kommende releasekalender. Microsoft har markeret betaudgaven af Finance reports API til udfasning i den aktuelle bølge. Den fjernes i første bølge af 2027, version tredive. Hele navnet er vigtigt her. Det betyder ikke, at finansrapporter forsvinder fra Business Central. Alex, hvem skal konkret være opmærksom på det?

• Deprecated features in the application

De ansvarlige for integrationer, som bruger netop den API-familie. Virksomheden kan godt have en ekstern rapport eller tjeneste koblet på den, uden at økonomiafdelingen kender navnet på forbindelsen. Men alle med et dashboard er ikke automatisk berørt. Første skridt er at finde den faktiske forbindelse bag resultatet og se, om den bruger denne betaudgave. Microsoft viser også varslet på betaressourcen subscriptions. Det er et konkret spor for udvikleren, ikke en grund til at bygge alle rapporter om, bare fordi økonomi indgår i titlen.

• Deprecated features in the application
• subscriptions resource type (Beta)

Jeg ville begynde med den rapport, nogen faktisk skal bruge på et møde, og så finde den ansvarlige for forbindelsen. Ellers kan en bred besked om, at et finans-API forsvinder, sende alle i hver sin retning. Hvis vi nu finder en forbindelse, der er berørt, er der så en anbefalet vej videre? Eller står virksomheden pludselig med et valg af helt ny rapportarkitektur?

Microsoft anbefaler Analytics API til rapportering og analyse. Det giver en retning, men ikke et løfte om, at man kan udskifte adressen i et gammelt kald og være færdig. Analytics API stiller datasæt til rådighed til læsning. Vi skal finde de entiteter, som løsningen behøver, sammenligne felterne og forstå, hvordan rapporten bruger dem. Dit mødeeksempel hjælper. Det giver omlægningen et konkret resultat at bevare, i stedet for at en forbindelse, som svarer uden fejl, bliver hele succeskriteriet.

• Analytics API overview

Hvad ville du sammenligne først? En samlet total kan godt passe, selv om fordelingen på afdelingerne er forkert.

Et afgrænset sæt kendte resultater på det niveau, hvor folk bruger tallene til at træffe beslutninger. Med dine afdelinger betyder det samme regnskab, periode og fordeling, med en aftalt behandling af reguleringer. Forskelle skal undersøges, ikke gemmes bag en total, der tilfældigvis passer. Jeg ville også vælge en periode med en usædvanlig postering, som økonomifolkene forstår. Den kan afsløre en antagelse i feltkoblingen, som almindelige totaler skjuler. Det er et forslag til en kontrol, ikke en udført omlægning eller dokumentation for, at de to grænseflader leverer samme struktur.

Og bagefter vil jeg gerne se rapporten blive opdateret, uden at udvikleren sidder ved siden af. En vellykket demonstration er nyttig, men vores tænkte rapport skal være klar til mødet hver uge. Hvad skal på plads, når vi går fra ét kald, der lykkes, til en rutine, virksomheden regner med?

Adgang, rettigheder og driftsansvar skal fungere i den tilsigtede rutine, ikke kun i en persons interaktive session. Analytics API bruger OAuth med et Entra-token og rettighed til regnskabets data. Jeg ville kontrollere den faktiske identitet, som henter data, og den planlagte kørsel. Fejl skal blive synlige for nogen, der kan reagere, og økonomiafdelingen skal kunne se, hvornår rapporten sidst blev opdateret korrekt. Det kræver ikke et nyt udseende på rapporten. Det handler om at bevare dens anvendelighed, mens forbindelsen nedenunder skiftes.

• Analytics API overview

Én grænse skal ikke gemmes langt nede i en teknisk note: Analytics API er til læsning. Det opretter, ændrer eller sletter ikke transaktioner. Opdager man, at en integration laver mere end at levere data til en rapport, dækker anbefalingen altså ikke automatisk det øvrige arbejde. Vi skal se på, hvad løsningen faktisk gør, før vi kalder hele opgaven en omlægning af rapportering.

• Analytics API overview

Netop. Navnerummet hedder microsoft, skråstreg analytics, skråstreg v ét punkt nul. Den præcise reference ligger i afsnitsnoterne til den, der skal undersøge forbindelsen. Standard Power BI-apps bruger disse API’er, men det beviser ikke, at enhver gammel løsning kan flyttes direkte. Det nyttige nu er en målrettet kortlægning og en ansvarlig for omlægningen inden version tredive. Bruger virksomheden ikke den Finance reports API, som forsvinder, giver lige netop dette varsel den ikke en ny opgave. Et system, der ikke er berørt, må gerne få lov at fortsætte.

• Deprecated features in the application
• Analytics API overview

Den sidste opdagelse er mere synlig. Eller bevidst mindre synlig. Business Central understøtter maskering af felter i brugerfladen, og fra version niogtyve er selve funktionen slået til som standard. Forestil dig en skærmdeling, hvor du viser et debitorkort, og en værdi, som mødet ikke handler om, står lige ved siden af. Det er rart at kunne holde den skjult, indtil den skal bruges. Men slået til som standard betyder vel ikke, at alle følsomme felter pludselig skjuler sig selv?

• Introduce UI support for masking sensitive data feature key

Nej, en udvikler skal stadig anvende egenskaben MaskType på det relevante felt. At funktionen er aktiveret, gør muligheden tilgængelig. Det afgør ikke, hvilke oplysninger virksomheden betragter som følsomme. På et understøttet felt kan brugeren skjule og vise værdien efter behov. Din skærmdeling er en god anvendelse: færre oplysninger bliver vist tilfældigt, mens personen arbejder. Men brugeren mister ikke selv muligheden for at se værdien. Det er netop derfor, funktionen kan være praktisk uden at ændre hele arbejdsopgaven.

• MaskType property
• Introduce UI support for masking sensitive data feature key

Så hjælpen gælder den, der tilfældigt kan kigge med på skærmen. Det er ikke en ny rettighedsmodel for den, der sidder og bruger systemet?

Det er den vigtige forskel. Microsoft skriver direkte, at den umaskerede værdi stadig bliver sendt til browseren. Vi beskytter visningen, ikke adgangen til oplysningen. Det er hverken kryptering, en eksportbegrænsning eller en garanti for at overholde regler. Hvis kravet er, at en person slet ikke må have adgang, løser maskering det ikke. Men hvis personen med rette skal kunne bruge værdien og blot ikke vil vise den under en demonstration eller ved et fælles skrivebord, kan den mindre tilfældige eksponering stadig have værdi.

• MaskType property

Jeg ville ikke afvise det, bare fordi det ikke er en sikkerhedsmur. Nogle gange er formålet netop, at noget ikke står unødvendigt fremme. Men jeg ville bede den, der ønsker funktionen, vise den konkrete side. Et skjult felt på et kort hjælper ikke meget, hvis den sædvanlige præsentation foregår et andet sted. Kan man bruge den samme egenskab på rækkerne i en liste?

Ikke i en repeater, og det er den vigtige begrænsning for netop listerækkerne. Den understøttes heller ikke i en konfigurationsdialog. Flere felttyper kan bruges, blandt andet tekst og tal, men udvikleren skal kontrollere det konkrete felt og dets opsætning. Jeg ville begynde på din faktiske præsentationsside, vælge feltet og afprøve både skjult og synlig tilstand dér. Derefter se på de andre steder, hvor medarbejderne bruger oplysningen. Det er en lille, målrettet forbedring, ikke et løfte om, at værdien er skjult alle steder.

• MaskType property
• Introduce UI support for masking sensitive data feature key

Det er en passende størrelse på idéen. Vis siden, forklar hvem der kan kigge med, og vurder, om et skjult felt løser det konkrete problem. Vi behøver ikke gøre en forbedring af skærmdeling til et løfte om alt, hvad virksomheden foretager sig med sine data. Og vi behøver heller ikke forkaste forbedringen, fordi den aldrig var tænkt til at kunne det hele.

Det var dagens afsnit. Vi fandt muligheder for at gøre fakturamatchning og løbende fakturering lettere, uden at alle næste skridt behøver ske automatisk. Vi så også på at holde et godkendelsesgrundlag fast, finde netop de rapportforbindelser, der kræver opmærksomhed, og gøre delte skærme lidt mere diskrete. Det gennemgående spørgsmål var, hvad personen med opgaven faktisk har brug for, at der sker nu. På hjemmesiden finder du afsnitsnoter og direkte Microsoft-kilder, også med de opsætningsdetaljer og begrænsninger, vi har berørt. Tak fordi du lyttede til Central Perspectives. Vi høres ved.