Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg er Emma, og Alex er med. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag kommer fragtfakturaen, efter at varerne er solgt. Og et baggrundsjob melder fejl, selv om noget af arbejdet allerede er lykkedes. Vi følger de løse ender og undersøger, hvad en økonomirapports kontroltal egentlig kan bevise. Til sidst har vi to nyttige skel om integrationer og dokumentsprog. Noget er etablerede muligheder, der er værd at kende; andet kom tidligere i år. Lad os komme i gang.

Lad os begynde med en virksomhed, der køber en sending varer, modtager dem og sælger nogle af dem videre. Bagefter kommer fragtfakturaen. Salgsafdelingen har allerede set på dækningsbidraget, så den sene regning er mere end lidt ekstra papirarbejde. Microsofts vejledning om varegebyrer beskriver, hvordan en særskilt faktura kan knyttes til bogførte købsmodtagelser. Alex, hvad får virksomheden ud af den forbindelse, som den ikke får ved bare at registrere en fragtudgift?

• Brug varegebyrer til ekstra handelsomkostninger
• Designdetaljer: kostregulering

Omkostningen får en vej tilbage til de varer, den hører til. Et varegebyr knytter en ekstra omkostning til den oprindelige varepost; der bliver ikke modtaget flere varer. Det er vigtigt, fordi noget af omkostningen kan høre til varer, der stadig ligger på lager, mens andet vedrører varer, som allerede er solgt. Kostreguleringen kan føre ændringen i den indgående kostpris videre til de tilknyttede afgange. Så spørgsmålet er ikke kun, om leverandørens regning er bogført. Det er også, om vi har placeret den på de rigtige varer, og om den ændrede omkostning er nået frem til de relevante salg.

• Brug varegebyrer til ekstra handelsomkostninger
• Designdetaljer: kostregulering
• Designdetaljer: vareudligning

Så lad os gøre sendingen lidt besværlig. Den indeholder små, dyre komponenter og store, billige beholdere. Fragten dækker begge dele. Fordeler vi efter indkøbsbeløbet, får komponenterne det meste af regningen, selv om beholderne fylder mest på bilen. Standardforslagene omfatter beløb, vægt og rumfang, ud over en ligelig fordeling. Jeg kan allerede se flere tal, man kan argumentere for. Hvordan vælger vi uden bare at få dækningsbidraget til at fortælle den historie, vi helst vil høre?

• Brug varegebyrer til ekstra handelsomkostninger

Jeg ville begynde med, hvad transportøren tager betaling for, frem for hvilket forslag der er nemmest at vælge. Hvis pladsen er afgørende, kan rumfang være mere relevant end indkøbsbeløbet. Men det hjælper kun, hvis varekortene har brugbare oplysninger om rumfang. En flot beregning på manglende eller misvisende mål er ikke en forbedring. Og indeholder fakturaen både et fast håndteringsgebyr og transport, beskriver ét enkelt grundlag måske ikke hele regningen. Virksomheden skal have en fordeling, den kan begrunde. Business Central giver muligheder for at udføre den, ikke et universelt facit på, hvad der er rimeligt.

• Brug varegebyrer til ekstra handelsomkostninger

Så rumfang er altså ikke en magisk knap. Hvis virksomheden aldrig har vedligeholdt de mål, fordi indkøb ikke brugte dem, vil jeg nødig have nogen til at opfinde dimensioner fredag eftermiddag for at få en faktura væk fra bordet. Er en uperfekt fordeling, man forstår, bedre end en tilsyneladende præcis fordeling, som ingen kan forklare?

• Brug varegebyrer til ekstra handelsomkostninger

Ja, hvis de ansvarlige for omkostningerne er enige om, hvad det valgte grundlag udtrykker. Jeg vil hellere have en synlig vurdering, der kan efterprøves, end falsk præcision. På vores blandede sending ville jeg sammenligne forslagene før bogføring og se, hvad de betyder for de to varegrupper. Flytter et andet grundlag en væsentlig del af dækningsbidraget mellem dem, fortjener valget opmærksomhed. Er forskellen uvæsentlig, kan en enklere, konsekvent metode være et rimeligt valg. Det er en forretningsmæssig vurdering, der skal dokumenteres, ikke i sig selv en grund til at bygge et nyt fragtsystem, før man bruger standardtildelingen.

• Brug varegebyrer til ekstra handelsomkostninger

Lad os holde fast i personen, der skal registrere regningen. Fordelingsgrundlaget er aftalt, men fragtfakturaen er jo ikke den oprindelige købsfaktura. Modtagelsen er allerede bogført. Handlingen, vi taler om, er Hent modtagelseslinjer inde i varegebyrtildelingen, så udgangspunktet er gebyret og de varer, det vedrører. Hvad skal personen se efter, inden fordelingen bliver accepteret?

• Brug varegebyrer til ekstra handelsomkostninger

Først, om det faktisk er de modtagelser, netop den fragtregning dækker. Et velkendt leverandørnavn eller varenummer er ikke nok, hvis flere leverancer ligner hinanden. Derefter mængderne i tildelingen og de beløb, der kommer ud af den. Kom kun en del af købsordren med denne sending, skal fordelingen afspejle den levering, regningen vedrører, ikke automatisk alt det, virksomheden bestilte. Og så selve fordelingsforslaget. Det sparer regnearbejde, men personen skal stadig kunne genkende varerne og situationen. Ellers kan en korrekt total godt skjule, at pengene er fordelt på de forkerte modtagelser.

• Brug varegebyrer til ekstra handelsomkostninger

Så kommer den lidt ubehagelige del for salgsafdelingen. Varerne blev solgt i sidste uge, og nogen brugte dækningsbidraget til at vurdere, om prisen var god nok. Hvis den sene fragt hører til sendingen, vil en uændret salgsomkostning få salget til at se bedre ud, end det var. Forhindrer den bogførte salgsfaktura, at den ekstra omkostning kan nå frem til salget?

• Designdetaljer: kostregulering

Nej. At opdatere omkostningen ved historiske salg er netop en del af kostreguleringens opgave. Den følger de relevante omkostningsforbindelser efter varens kostmetode og opretter regulerende værdiposter. Det er ikke et nyt fysisk salg, og kunden har ikke pludselig købt varen to gange. I et eksempel med faktisk kostpris kan det øge omkostningen på de allerede solgte varer. De varer, der er tilbage, har deres egne omkostningsvirkninger. Men at fragtfakturaen er bogført, og at den nødvendige regulering er afsluttet, er to forskellige observationer. Vi skal ikke love, at enhver sen fragt allerede er ført videre, bare fordi fakturaen gik igennem.

• Designdetaljer: kostregulering

Den forskel må bare ikke blive til endnu en obligatorisk manuel opgave. Microsofts beskrivelse omtaler jo også automatisk kostregulering. Hvis virksomheden allerede bruger den, risikerer vi så at bede nogen om at køre en proces, som måske var færdig, før de overhovedet åbnede siden?

• Designdetaljer: kostregulering

Det er præcis den gentagelse, vi skal undgå. Se på opsætningen og resultatet, inden en manuel kørsel bliver en fast rutine. Automatisk regulering har indstillinger, blandt andet et tidsvindue, og tilstrækkeligt sene omkostninger kan falde udenfor. To virksomheder kan derfor bogføre samme slags fragtfaktura og have brug for forskellig opfølgning. Jeg ville undersøge, om de berørte omkostningsposter er reguleret, frem for at antage enten, at automatikken klarer alt, eller at et menneske altid skal gribe ind. Når virksomheden ved, hvilke sene omkostninger opsætningen fanger, kan den gøre undtagelsen synlig i stedet for at få alle til at gentage hele processen.

• Designdetaljer: kostregulering

Der hænger også en kalender på det her. Hvis fragtfakturaen kommer, efter at økonomiafdelingen har lukket lagerperioden, peger forklaringen stadig tilbage på sidste måneds sending. Men det betyder jo ikke, at sidste måneds regnskab frit kan ændres. Hvor efterlader det reguleringen?

• Designdetaljer: kostregulering
• Reguler vareomkostninger

Bogføringsbegrænsningerne gælder stadig. Reguleringen kan få startdatoen i den næste åbne lagerperiode. Bruger virksomheden ikke lagerperioder, er de tilladte bogføringsdatoer relevante. At omkostningen er knyttet til en ældre varepost, er altså ikke et løfte om, at reguleringen dateres i den gamle periode. Det er vigtigt, hvis nogen sammenligner en aktuel rapport med den, de gemte ved månedsluk. Jeg ville sammen med økonomi følge både de berørte poster og deres bogføringsdatoer. Så kan man forklare, hvorfor sammenhængen med en bestemt sending og perioden, hvor reguleringen optræder, ikke nødvendigvis er det samme.

• Designdetaljer: kostregulering
• Reguler vareomkostninger

Der er endnu et skel i dokumentationen, som vores eksempel ikke må udviske: standardkost. Vi har forestillet os omkostninger, der følger det faktiske køb og fragten. Hvis en virksomhed bevidst bruger standardkost, skal den så forvente, at en sen fragtfaktura skriver selve standardbeløbet om?

• Designdetaljer: afvigelser

Ikke på den enkle måde. Ved standardkost er forskellen mellem faktisk kostpris og standardkost en afvigelse. Et senere varegebyr ændrer den forskel. Det betyder ikke, at gebyret bare erstatter standardkostprisen med et nyt faktisk beløb. Derfor ville jeg ikke vurdere resultatet alene ud fra, om et bestemt tal på varekortet flyttede sig. Hvilket spor man skal lede efter, afhænger af kostmetoden. Fragten kan godt være registreret korrekt, selv om virkningen ligger i afvigelsen og ikke opfører sig som i vores eksempel med faktisk kostpris.

• Designdetaljer: afvigelser

Så en brugbar kontrol kunne følge en lille sending fra modtagelse til salg og derefter lægge et tydeligt identificeret, sent gebyr på. Jeg ville lade nogle af varerne blive på lageret, så vi ikke kun undersøger den nemme halvdel. Og på forhånd aftale, hvilke poster vi forventer at finde med virksomhedens faktiske kostmetode. Det virker mere oplysende end at åbne en dækningsbidragsrapport og spørge, om den ser nogenlunde rigtig ud.

• Brug varegebyrer til ekstra handelsomkostninger
• Designdetaljer: kostregulering
• Designdetaljer: afvigelser

Det gør eksemplet væsentligt bedre, at der er varer tilbage. I et egnet testregnskab kan man følge gebyrtildelingen, reguleringsposterne knyttet til salget og den omkostning, der bliver hos lageret. Derefter datoerne, og om automatikken håndterede tilfældet. Bogføringen af de tilsvarende lageromkostninger i finans er et særskilt trin. Regulerede værdiposter beviser derfor ikke alene, at afstemningen er færdig. Aftal også, hvilket grundlag økonomiafdelingen vil bruge til at bekræfte dét. Formålet er at forstå virksomhedens eksisterende kostopsætning, ikke at antage, at alle varer følger ét eksempel.

• Designdetaljer: kostregulering
• Reguler vareomkostninger
• Designdetaljer: afstemning med finansbogholderiet

Det næste skel vender næsten situationen om: En rød status kan skjule arbejde, som faktisk blev færdigt. Microsofts vejledning om baggrundsbogføring beskriver et dokument, der bliver bogført, men ikke udskrevet, fordi processen støder på en printerdialog uden nogen til at svare. Til sidst får jobbet timeout og status Fejl. Det er etableret funktionalitet, ikke en ny oktoberændring. Men hvis jeg sidder og venter på dokumentet, fortæller ordet Fejl mig jo ikke, om jeg mangler bogføring, udskrift eller begge dele.

• Bogfør flere bilag samtidig

Og det ændrer det første spørgsmål ved genopretningen. Inden man starter forretningshandlingen igen, skal man fastslå, hvad der skete med dokumentet. I det beskrevne printertilfælde er bogføringen gennemført; det manglende resultat er udskriften. Men det svar gælder ikke automatisk alle job med status Fejl. En anden fejl kan opstå tidligere. Jobstatus fortæller om kørslen, mens det bogførte dokument og de tilhørende poster fortæller om forretningsresultatet. Begge dele er nødvendige. Ellers kan et velment forsøg på at få noget grønt på skærmen rette sig mod den forkerte ufærdige opgave.

• Bogfør flere bilag samtidig

Forestil dig, at en ordrebehandler melder fejlen til support og får svaret, at jobbet er startet igen. Begge har gjort noget fornuftigt set fra deres egen skærm. Men ordrebehandleren ved stadig ikke, om kunden kan få dokumentet. Jeg ville gerne have overleveringen til at sige, hvad der allerede lykkedes, og hvad der stadig mangler, i stedet for bare at fortælle, at endnu et forsøg er sat i gang.

• Bogfør flere bilag samtidig

Det ville også hjælpe support. Tag regnskabet, dokumentet og det relevante job med, sammen med fejltidspunktet og selve fejlbeskeden. Tilføj så observationen fra arbejdet: For eksempel at det bogførte dokument findes, men den forventede udskrift mangler. Det indsnævrer undersøgelsen betydeligt. Jeg ville også skelne mellem den, der undersøger jobbet, og den, der bekræfter forretningsresultatet. I en lille virksomhed kan det være samme person, men der er stadig to opgaver. En vellykket teknisk genstart erstatter ikke ordrebehandlerens kontrol af, at det manglende dokument nu er til rådighed.

• Bogfør flere bilag samtidig
• Brug opgavekøer til at planlægge opgaver

Printerdialogen er en overraskende jordnær årsag. Man kunne jo med god grund sige: Det virkede, da jeg selv kørte det, så hvorfor skulle baggrundsjobbet ikke kunne gøre det samme? Dokumentet er det samme. Hvad ændrer sig i processen, når der ikke sidder et menneske foran den?

• Opgavekø

Når du selv kører det, kan du svare på et spørgsmål, vælge en printer eller reagere på en dialog. En baggrundssession kan ikke regne med den mulighed. Udvikleren skal indrette forløbet derefter, og Business Central giver koden mulighed for at undersøge, om brugerinteraktion er tilladt. Men først kommer behovet: Hvilken beslutning traf personen, og hvor får den automatiske proces nu sit svar fra? Det er ikke et færdigt design blot at skjule spørgsmålet, hvis svaret var nødvendigt. Printereksemplet minder os om at afprøve den ubemandede vej, ikke bare samme handling med nogen siddende ved skærmen.

• Bogfør flere bilag samtidig
• Opgavekø

Personen spiller også ind på en anden måde. Dokumentationen siger, at baggrundssessionen bruger den bruger, der sætter jobbet til Klar, med de rettigheder arbejdet kræver. Så det virkede hos mig kan både skjule en anden bruger og en anden form for interaktion. Det ville gøre mig forsigtig med, at en hjælpsom kollega lige ændrer jobstatus uden at vide, hvem der egentlig skal stå for kørslen.

• Opgavekø

Det hører hjemme i aftalen om driften. Beslut, hvem der må sætte jobbet klar, og kontrollér, at den bruger har rettigheder til de objekter og data, jobbet faktisk har brug for. Dukker en rettighedsfejl op, skal løsningen ikke automatisk være ubegrænset adgang. Find først den manglende handling, og vurder, om den hører til opgaven. Så bliver rettelsen proportional. Det gør også senere fejlsøgning mindre mystisk: Afprøvningen skal bruge den tiltænkte bruger og baggrundskørslen, ikke låne en stærkere brugers interaktive session og derfra erklære problemet løst.

• Opgavekø

Hvad så, hvis der slet ikke er en fejl? Jobbet venter, og nogen vil have fakturaerne færdige, inden det næste hold møder ind. Den beskrevne kategoristyring kan få et job til at vente på et andet i samme kategori. Fra brugerens stol sker der bare ingenting. Ville det sætte gang i arbejdet at dele kategorierne op, eller risikerer vi at fjerne noget nyttigt?

• Bogfør flere bilag samtidig
• Brug opgavekøer til at planlægge opgaver

Det kan være noget nyttigt. Kategorien kan forhindre, at beslægtede job ændrer de samme data samtidig. Ventetiden kan være den tilsigtede beskyttelse, ikke en fejl, man skal udenom. Jeg ville først finde det kørende job og undersøge, hvad jobbene deler. Er de reelt uafhængige, kan man gennemgå designet. Men at ændre kategorier for at tømme køen viser ikke, at parallel kørsel er sikker. Og tidligste startdato og klokkeslæt er netop tidligste mulighed, ikke en garanteret aftale. Belastning og driftsgrænser kan påvirke starten. En forretningsfrist kræver mere omtanke end at skrive fristen ind som starttidspunkt.

• Bogfør flere bilag samtidig
• Brug opgavekøer til at planlægge opgaver

Så ville jeg flytte samtalen fra start klokken otte til disse bestemte dokumenter skal være klar til holdet klokken otte. Det giver plads til at tage højde for ventetid og aftale, hvornår en forsinkelse skal have opmærksomhed. Og vi slipper for, at en kø med alle mulige andre job bliver målestokken. Ordrebehandleren har brug for sine dokumenter, ikke et billede af en tom jobliste.

• Brug opgavekøer til at planlægge opgaver

Det er et langt mere brugbart mål at drive efter. Definér de relevante dokumenter, og hvad klar betyder for dem: bogført og med det nødvendige output til rådighed. Vælg derefter et tidspunkt, hvor nogen stadig kan nå at undersøge et manglende resultat. Venter jobbet stadig dér, skal man se på afhængigheden og det resterende arbejde, ikke straks stemple det som defekt. Er det fejlet, skal dokumentets tilstand og fejlbeskeden ses sammen. Den samme frist kan føre til forskellige handlinger, fordi ventetid, en fejlet kørsel og manglende output ikke er den samme tilstand.

• Bogfør flere bilag samtidig
• Brug opgavekøer til at planlægge opgaver

Der er endnu en status, man skal læse med omtanke: On Hold, altså at sætte jobbet i venteposition. Hvis nogen opdager et uventet job i gang, lyder det som den oplagte måde at standse det på, mens man undersøger sagen. Men administrationsvejledningen siger direkte, at det ikke påvirker et job, der allerede kører. Så det handler om en kommende start, ikke om en pauseknap til det igangværende arbejde?

• Brug opgavekøer til at planlægge opgaver

Præcis. Det kan forhindre en automatisk start, før behandlingen begynder, men det fryser ikke en aktiv kørsel. Kører jobbet allerede, må den ansvarlige administrator fastslå den faktiske tilstand og de understøttede muligheder for netop den handling. Jeg ville ikke gøre det til et generelt råd om at afbryde en session, for konsekvenserne afhænger af arbejdet. En ændret status beviser heller ikke, at der ikke skete mere. Derfor kommer vi tilbage til dokumentet: Fastslå det faktiske resultat, inden man beslutter, hvad der sikkert kan genoptages, rettes eller bare stå urørt.

• Bogfør flere bilag samtidig
• Brug opgavekøer til at planlægge opgaver

Ved en afprøvning af baggrundsbogføring ville jeg nu bede om mere end en demonstration, hvor alt går godt. Brug et repræsentativt dokument og det tiltænkte automatiske output, og aftal, hvordan nogen genkender et delvist resultat. Ikke ved at fremkalde en driftsfejl, men ved at fastslå, hvilke spor holdet vil bruge, hvis bogføring og output ikke afsluttes sammen. Det er et mere nyttigt acceptkriterium end, om knappen satte et job i gang.

• Bogfør flere bilag samtidig
• Opgavekø

Og tag den, der skal bruge resultatet, med i den kontrol. En udvikler kan undersøge baggrundsforløbet og brugeren, det kører under. Ordrebehandleren kan afgøre, om dokumentet faktisk gør den næste arbejdsopgave mulig. Ingen af de to vurderinger erstatter den anden. Når normalforløbet virker, og holdet kan genkende et delvist resultat, kan baggrundsbogføring fjerne en reel afbrydelse i hverdagen. Vi behøver ikke få automatik til at lyde skrøbelig for at insistere på, at det skal være klart, hvornår den er færdig.

• Bogfør flere bilag samtidig
• Opgavekø

Lad os tage et andet resultat, der kan se overbevisende ud: en flot ledelsesrapport. Overskrifterne passer, kolonnerne står pænt, og totalen ser bekendt ud. Så opretter økonomi en ny finanskonto, som rapportdefinitionen ikke får med. Microsofts fejlfindingsvejledning nævner både udeladte konti, konti der tælles flere gange, og formelfejl som årsager til forkerte tal. Det er en eksisterende kontrolopgave, ikke en ny layoutfunktion. Hvor ville du begynde, når udseendet ikke giver os nogen advarsel?

• Fejlfinding i finansrapportering

Med en sammenligning, der ikke bygger på den samme rapportdefinition. En saldobalance eller en analyse af finansposterne giver en anden vej til den relevante total. Men først skal afgrænsningen passe: samme periode og relevante filtre. Dækker ledelsesrapporten én del af virksomheden, mens sammenligningen omfatter det hele, er forskellen ikke i sig selv bevis på en ødelagt formel. Når afgrænsningen passer, har man et brugbart spørgsmål: Hvilke konti eller beregninger forklarer forskellen? Det er mere konkret end at vurdere en hel rapport ud fra, om tallene virker sandsynlige.

• Fejlfinding i finansrapportering

Selv samme periode kræver lidt omtanke. Spørgsmål og svar om finansrapporter skelner mellem bevægelse og saldo til dato. Spørger jeg, hvordan virksomheden klarede sig i september, er det noget andet end at spørge, hvad en saldo var ved udgangen af september. Begge rapporter kan godt have september i overskriften uden at svare på det samme spørgsmål.

• Fejlfinding i finansrapportering
• Ofte stillede spørgsmål om finansrapportering

Tag en bankkonto som et enkelt eksempel. Bevægelsen i september er ikke det samme tal som saldoen ved månedens slutning, for saldoen ved begyndelsen spiller også ind. Bevægelse passer typisk til aktivitet i en periode, mens saldo til dato viser saldoen på en bestemt dato. Rapportens formål afgør, hvad vi ønsker. Så inden jeg sporer formler, ville jeg skrive spørgsmålet i almindeligt sprog. Dit skel kan spare os for at rette et helt gyldigt tal, bare for at få det til at stemme med en sammenligning, der måler noget andet.

• Fejlfinding i finansrapportering
• Ofte stillede spørgsmål om finansrapportering

Lad os gå tilbage til den manglende konto, nu hvor periode og filtre passer sammen. Rapportansvarlige skal helst ikke genopdage samme udeladelse fra bunden hver måned. Hvis der kommer en ny omkostningskonto uden for de rækker, rapporten summerer, hvordan gør vi så hullet synligt uden at forvandle rapporten til en hel væg af kontroltal?

• Fejlfinding i finansrapportering

En kontrolrække kan sammenligne en bredere kontroltotal med summen af de rækker, man viser. Skal de være ens, skal forskellen være nul. Det giver den ansvarlige et konkret signal at undersøge. Standardopsætningen lader kontrolrækken have Vis sat til Nej, så den ikke kommer med i PDF-filen, mens Vis alle linjer gør den tilgængelig ved kontrollen. Ledelsespakken kan altså forblive læsbar. Det vigtige er, hvilken sammenhæng kontrollen undersøger. Kontroltotalen skal kunne fange den udeladelse, vi er bekymrede for, ikke gentage det samme ufuldstændige kontoudvalg to steder.

• Fejlfinding i finansrapportering

Det var netop den fælde, jeg tænkte på. Bruger kontrolformlen præcis det samme ufuldstændige kontointerval, kan den jo stemme nydeligt med rapporten. Og selv en fornuftig total kan skjule to fejl, der ophæver hinanden. En forskel på nul lyder betryggende, men jeg ville tøve med at kalde rapporten kontrolleret uden at sige, hvad vi faktisk undersøgte.

• Fejlfinding i finansrapportering

Jeg ville navngive kontrollen efter formålet, ikke kalde den et certifikat. Den kan for eksempel vise, at de viste omkostningsrækker summerer til det tilsigtede udvalg af omkostningskonti. Det beviser stadig ikke, at hver post ligger på den rigtige konto, eller at en udeladelse og en dobbelt optælling ikke kan ophæve hinanden. Dit modeksempel giver en god test: Udelad eller gentag bevidst en konto i en sikker kopi af definitionen. Kommer den forventede forskel frem? En kontrol, der kan påvise den fejl, den skal fange, er mere nyttig end en, der tilfældigvis viser nul i dag.

• Fejlfinding i finansrapportering

Der følger noget praktisk med at skjule rækken i PDF-filen. Modtageren kan ikke se, om nogen har kigget på den. Jeg kan godt lide en enkel rapport, men det er kun nyttigt at skjule kontrollen, hvis nogen stadig har ansvaret for at udføre den. Ellers har vi gjort advarslen så diskret, at den forsvinder fra arbejdsgangen.

• Fejlfinding i finansrapportering

Så lad kontrollen være en del af klargøringen, med en navngiven ansvarlig og en aftale om, hvad en forskel udløser. Den skjulte række blokerer ikke automatisk udsendelsen eller beviser, at nogen har set den. Ved en vigtig ledelsesrapport kan den ansvarlige gemme sammenligningen og afklare uventede forskelle før udsendelse. Omfanget skal passe til brugen. En foreløbig arbejdsoversigt og en rapport til en stor beslutning kræver ikke nødvendigvis samme procedure, men ingen af dem har glæde af et tal, som ingen forstår. Standardfunktionen giver plads til kontrollen; virksomheden skal stadig give den mening.

• Fejlfinding i finansrapportering

Vejledningen har også en nyttig detalje om vedligeholdelse. Finansrapporternes definitioner gemmes som data, og en opgradering overskriver ikke de eksisterende definitioner med nye standarder. Det beskytter virksomhedens arbejde. Men det betyder også, at vi ikke skal vente på næste Business Central-opdatering for at få repareret vores manglende konto eller en gammel tilpasset formel.

• Ofte stillede spørgsmål om finansrapportering

Ja, normalt vil man netop bevare definitionen. Anledningen til vedligeholdelse er ofte en ændring i virksomheden: en ny konto, en anden rapporteringsstruktur eller et nyt spørgsmål, rapporten skal besvare. Gennemgå den berørte definition dér, og behold de nyttige kontroller sammen med den. Det er mere målrettet end at bygge rapporten om efter hver softwareopdatering. I vores eksempel er rettelsen at få det tilsigtede kontoudvalg med og kontrollere beregningen, ikke at udskifte en velkendt rapport, bare fordi der findes en nyere standard et andet sted.

• Fejlfinding i finansrapportering
• Ofte stillede spørgsmål om finansrapportering

Det næste er til alle, der har ansvar for en integration, også uden selv at skrive koden. Business Central kan kalde en ekstern tjeneste, og beskyttelsen af de udgående kald kan stoppe en forespørgsel, før tjenesten behandler den. Microsofts standardbeskyttelse af udgående kald blev generelt tilgængelig i april, ikke her i oktober. Det praktiske spørgsmål er, hvordan man finder årsagen til en fejlet forbindelse uden at behandle enhver sikkerhedskontrol som noget, der bare skal slås fra.

• Kald eksterne tjenester med datatypen HttpClient
• Få sikrere udgående HTTP-kald som standard

Spørg først, om kaldet nåede den anden tjeneste og gav et svar. Det deler undersøgelsen på en nyttig måde. Kaldet kan fejle lokalt, fordi udvidelsen ikke må lave udgående HTTP-kald, eller fordi platformens beskyttelse afviser destinationen. Hvis tjenesten svarede, kan svaret stadig beskrive en fejl. At modtage et HTTP-svar er ikke det samme som at få et vellykket forretningsresultat. En supportbesked, der bevarer det skel, giver den næste person et sted at begynde. Integrationen er nede fortæller endnu ikke, hvilken side vi skal undersøge.

• Kald eksterne tjenester med datatypen HttpClient

Der er en detalje ved tilladelsen, som er værd at beholde. Dokumentationen siger, at udgående kald skal tillades for hver udvidelse, også biblioteksapps. Man kan altså se tilladelsen slået til på hovedudvidelsen uden dermed at have fastslået, at den komponent, der faktisk laver kaldet, har lov. Det er en mere præcis undersøgelse end straks at give den eksterne tjeneste skylden.

• Kald eksterne tjenester med datatypen HttpClient

Ja, find komponenten, der laver kaldet, i stedet for at ændre tilladelser på må og få. Og hold tilladelsen adskilt fra destinationsbeskyttelsen. Beskyttelsen mod SSRF skal forhindre, at serveren bliver lokket til at kalde begrænsede interne adresser. Lov til at lave HTTP-kald betyder ikke, at enhver tænkelig destination skal kunne nås. I Business Central online er den kontrol altid aktiveret og kan ikke slås fra. Hvis integrationens design afhænger af en adresse, platformen afviser, er løsningen derfor ikke at lede efter en skjult slukknap. Designet og den tiltænkte destination skal gennemgås.

• Kald eksterne tjenester med datatypen HttpClient

Driftsvejledningen omfatter også lokale installationer, med understøttede builds fra ældre versionsserier. Udgivelsesdatoen i april betyder altså ikke, at vi kan beskrive adfærden bare ved at sige version otteogtyve eller nyere. På understøttede lokale builds findes der en målrettet indstilling for tilladte adresser. Det lyder som noget andet end at fjerne beskyttelsen for det hele.

• Kald eksterne tjenester med datatypen HttpClient
• Få sikrere udgående HTTP-kald som standard

Det er det også. En administrator kan vurdere en destination, som integrationen faktisk har brug for, ud fra den understøttede indstilling og det installerede build. Det er en afgrænset beslutning, ikke en anbefaling om at slå beskyttelsen fra overalt. Og den løser ikke en anden fejl, som et ugyldigt servercertifikat. Certifikatkontrollen spørger, om man kan have tillid til serverens certifikat. Destinationsbeskyttelsen handler om, hvor kaldet sendes hen. Peger fejlen på certifikatet, skal certifikatet og tjenestens opsætning undersøges. At tillade destinationen gør ikke på magisk vis dens certifikat gyldigt.

• Kald eksterne tjenester med datatypen HttpClient

Lad os sige, at de kontroller er i orden, og tjenesten sender et svar, men den forventede handling stadig ikke er sket. Integrationsansvarlige skal helst ikke høre, at HTTP-kaldet lykkedes, og dermed antage, at kundeoplysningerne blev accepteret. Hvad skal udvikleren skelne mellem i den besked?

• Kald eksterne tjenester med datatypen HttpClient

Om kaldet kunne sendes, hvilken HTTP-status der kom tilbage, og hvad svaret betyder for handlingen. En tjeneste kan svare med en status, der angiver fejl. Selv en successtatus skal forstås ud fra tjenestens dokumenterede aftale; den lover ikke universelt, at alle efterfølgende forretningstrin er afsluttet. Den nyttige besked kan derfor være, at tjenesten afviste forespørgslen, ikke at Business Central ikke kunne oprette forbindelse. Det ændrer både, hvem der skal handle, og hvad næste skridt er. Og det hindrer, at holdet bliver ved med at ændre lokale sikkerhedsindstillinger, når den eksterne tjeneste allerede har forklaret problemet.

• Kald eksterne tjenester med datatypen HttpClient

Så ville jeg ønske, at supportsagen sagde, hvilket lag oplysningerne peger på: udvidelsen, der kalder, en afvist destination eller certifikatkontrol, eller et faktisk svar fra tjenesten. Detaljer nok til at undersøge sagen, uden at kopiere adgangsoplysninger eller kundedata ind i den. De præcise lokale buildnumre og indstillinger kan stå i afsnitsnoterne. Den nyttige vane er at holde op med at behandle alle fejlede kald som den samme fejl.

• Kald eksterne tjenester med datatypen HttpClient

Og når oplysningerne udpeger en årsag, så ret det relevante og bekræft den tilsigtede handling. Ikke en samling uvedkommende ændringer, hvor man bagefter har mistet forklaringen på, hvilken der gjorde forskellen. Det holder et lille tilladelses- eller tjenesteproblem lille, mens platformens beskyttelse fortsat passer sit arbejde. Vi har ikke testet nogens forbindelse her. Vi har fundet en måde at gøre den næste undersøgelse mere præcis på.

• Kald eksterne tjenester med datatypen HttpClient

Lad os slutte med noget mindre og dejligt praktisk. En kollega foretrækker at arbejde i Business Central på engelsk, men virksomheden sender normalt dokumenter på dansk. Siden april kan virksomhedens standardsprog for dokumenter sættes særskilt. Firmaoplysninger har feltet Standardsprogkode. Personens foretrukne arbejdssprog behøver altså ikke bestemme virksomhedens standardsprog på dokumenterne. Hvad skal vi forvente, at indstillingen ændrer?

• Skift sprog- og områdeindstillinger
• Angiv standardsprog for dokumenter på virksomhedsniveau
• Ændre dine indstillinger for sprog og område

Den adskiller dokumenternes standardsprog fra brugerens sprog i grænsefladen. Det kan fjerne et unødvendigt kompromis i et flersproget hold. Men et sprogvalg oversætter ikke automatisk de gemte forretningsdata. En varebeskrivelse eller kundekommentar skrevet på engelsk bliver ikke dansk, bare fordi dokumentets ledetekster er danske. Tænk på dokumentets sprog og de ord, nogen har gemt i dataene, som to forskellige ting. Begge kan stå på samme side, og begge har betydning for, om kunden får et sammenhængende dokument.

• Skift sprog- og områdeindstillinger

Så en dansk overskrift over en engelsk leveringskommentar ville være et nyttigt eksempel i kontrollen. Og holdet skal ikke antage, at virksomhedens standard tilsidesætter ethvert udtrykkeligt sprogvalg på kunder eller leverandører. Kilderne fastslår standardindstillingen, men ikke enhver prioritetsrækkefølge eller tilpasset rapport. Vi skal stadig se det dokument, virksomheden faktisk sender.

• Skift sprog- og områdeindstillinger

Ja. Brug et repræsentativt dokument med den faktiske rapport og de relevante modtagerindstillinger. Tag en beskrivelse eller kommentar med, i stedet for kun at se på titlen. Se derefter særskilt på formateringen. Områdeindstillinger handler blandt andet om visning af tal og datoer og er ikke det samme som sprog. Et sprogskift vælger heller ikke et andet lands lovbestemte funktioner. Det kræver ikke et stort flersproget projekt at vurdere funktionen. Det kræver nogle få dokumenter, som viser de forskelle, der betyder noget for virksomheden, og en klar forventning til hvert af dem.

• Skift sprog- og områdeindstillinger

Jeg kan godt lide, at kollegaen ikke behøver arbejde i en mindre behagelig grænseflade bare for at få standarden rigtig. Den lille forbedring er reel, selv om den ikke oversætter hver sætning. I vores eksempel er det ønskede resultat enkelt: Kollegaen beholder den engelske grænseflade, mens det forventede danske dokument stadig har de rigtige ledetekster, det rigtige indhold og den rigtige formatering til modtageren.

• Skift sprog- og områdeindstillinger

Og opfører de repræsentative dokumenter sig som forventet, kan standardindstillingen være alt, virksomheden behøver. Behold ansvaret for gemte beskrivelser og kommentarer dér, hvor det hører til, i stedet for at forvente, at et standardsprog vedligeholder dem. Så er funktionen lettere at forklare til holdet: Brug den grænseflade, der hjælper dig i arbejdet, og kontrollér dokumentvalgene for sig. Et beskedent skel, men et, der kan fjerne et unødvendigt dagligt kompromis.

• Skift sprog- og områdeindstillinger

Det bliver vores sidste pointe i dag. En bogført faktura, en jobstatus og en rapport, der stemmer, fortæller hver noget nyttigt, men ingen af dem besvarer alle spørgsmål om arbejdet. Følger vi de rigtige spor, kan vi finde en sen omkostning, et ufærdigt resultat eller en kontrol, der mangler et tydeligere formål. Og nogle gange er forbedringen blot, at en kollega kan arbejde på ét sprog, mens virksomheden sender dokumenter på et andet. Afsnitsnoterne har de direkte kilder, de praktiske begrænsninger og de dybere tekniske detaljer. Tak, fordi du lyttede til Central Perspectives fra ITrators. Vi høres ved.

• Designdetaljer: kostregulering
• Bogfør flere bilag samtidig
• Fejlfinding i finansrapportering
• Skift sprog- og områdeindstillinger