Velkommen til Central Perspectives, en Business Central-podcast fra ITrators. Jeg hedder Emma, og med mig er Alex. Vi er AI-værter, og vores manuskripter og stemmer er AI-genererede. I dag ser vi på, hvad der bliver lettere, når Business Central gør en vigtig forskel tydelig: fakturaer før bogføring, materialeforbrug over for pluk og software, der stadig kører, over for software, der gør det rigtige. Noget er aktuelt i den nye version. Andet er eksisterende muligheder, der fortjener at blive opdaget. Vi begynder i økonomiafdelingen med en funktion fra Business Central 27, efterårsversionen fra 2025: analyse af ikke-bogførte periodiseringsplaner på tværs af dokumenter. Lad os komme i gang.

• Periodiser indtægter og udgifter
• Forbedret rapportering om periodisering

Og det afgørende ord er ikke-bogførte. Med periodisering fordeler man indtægten eller omkostningen over flere perioder i stedet for at lade hele fakturabeløbet påvirke resultatet med det samme. Oversigten lader økonomiafdelingen se de planlagte fordelinger samlet, før dokumenterne bliver bogført. Forestil dig en virksomhed, der er ved at gøre flere fakturaer for årsabonnementer klar. På hver enkelt faktura ser beløbet måske rimeligt ud. Men når planerne ligger ved siden af hinanden, bliver det tydeligt, at den ene begynder at indtægtsføre en måned før de andre. Det var altså ikke fakturabeløbet, der skilte sig ud. Det var tidspunktet. Og netop den forskel er lettere at få øje på, når man ser planerne samlet.

• Forbedret rapportering om periodisering

Det er mere interessant end endnu en total, der skal stemmes af. Men lad os beholde den lidt besværlige faktura. Hvad nu, hvis kundens abonnement faktisk begynder tidligere? Jeg ville nødig have, at medarbejderen retter alle planerne til, bare fordi en ensartet kolonne ser betryggende ud. Hvornår er forskellen noget, man skal undersøge, frem for noget, man skal rette?

Det afgør aftalen bag fakturaen. I vores eksempel skal planen holdes op imod, hvornår netop denne ydelse bliver leveret, og virksomhedens regnskabsprincipper. Er der en god grund til den tidligere start, skal den blive stående. Den skæve linje har rejst et spørgsmål, ikke givet svaret. Jeg vil faktisk hellere have en gennemgang, hvor controlleren kan forklare to forskellige planer, end en, hvor alt er gjort ens. Systemet kan ordne datoer og beløb. Men ens fakturabeløb fortæller ikke i sig selv, at virksomheden skal levere det samme på samme tid. Og hvis ingen kender leveringsperioden endnu, kan det rigtige resultat af gennemgangen være at få den oplyst, før man bogfører.

Så man kan opdage en samtale, der mangler, og ikke bare en forkert dato. Jeg kan godt forestille mig salgskollegaen, der siger: Fakturaen er jo klar, hvad venter vi på? Mens økonomiafdelingen egentlig spørger, hvornår ydelsen begynder. Hvor finder medarbejderen den her oversigt uden at skulle åbne alle fakturaerne igen?

Find listen med periodiseringslinjer for salg, køb eller finans, og slå analysetilstanden til på den relevante liste. På engelsk hedder de Sales Deferral Lines, Purchasing Deferral Lines og G/L Deferral Lines. Man vælger altså den kilde, man vil gennemgå. Opsætningen bagved er stadig nødvendig: konti, skabeloner og de konkrete planer skal være på plads. Funktionen læser ikke alle fakturaerne og finder selv på den manglende regnskabsbehandling. Til vores abonnementsfakturaer ville jeg begynde på salgssiden med et afgrænset spørgsmål: Passer de planlagte indtægtsføringsdatoer med den leveringsperiode, vi har godkendt? Så ved medarbejderen, hvorfor hun åbner oversigten. Hun får ikke bare et stort gitter og besked på at finde et eller andet interessant.

• Periodiser indtægter og udgifter
• Forbedret rapportering om periodisering

Lad os sætte nogle enkle beløb på. I vores tænkte virksomhed har vi en faktura på tolv tusind kroner, der dækker tolv måneder, og den aftalte fordeling er tusind kroner om måneden. Den ene plan begynder i januar, den anden i februar. Begge summerer helt rigtigt. Hvis jeg kun kontrollerer det samlede beløb, har jeg slet ikke undersøgt den forskel, vi taler om.

Og resultatet for januar bliver forskelligt, selv om totalerne stemmer. Vi kan også ændre eksemplet lidt: En af fakturaerne på tolv tusind er fordelt over seks måneder. Så ændrer både månedsbeløbet og slutdatoen sig. Det kræver ikke en avanceret prognose at se, at den plan fortjener opmærksomhed. Men vores enkle regnestykke skal holdes adskilt fra, hvad produktet nødvendigvis beregner. Vi har valgt lige store månedsbeløb for at gøre eksemplet overskueligt. I praksis findes der forskellige beregningsmetoder til planerne, og den rigtige behandling afhænger af transaktionen. Begynd med, hvad fakturaen skal dække. Se derefter på, om planen faktisk afspejler det.

• Enumeration for beregning af periodisering

Den med de seks måneder får mig til at tænke på skabelonen. Hvis flere medarbejdere bliver ved med at rette det samme forslag, beder vi dem måske om at reparere opsætningen faktura for faktura. Men hvis det bare er én særlig aftale, risikerer en skabelonændring jo at gøre undtagelsen til alles udgangspunkt. Det er to ret forskellige opgaver.

Og den forskel bevarer Business Central: En rettelse i dokumentets periodiseringsplan ændrer ikke skabelonen bagved. Den særlige aftale kan altså få sin egen plan, uden at undtagelsen bliver den næste medarbejders standardforslag. Ved gentagne rettelser ville jeg undersøge skabelonen særskilt. Er den faktisk forkert, eller prøver vi at presse to forskellige typer ydelser ind i samme forslag? Det kalder på forskellige løsninger. Jeg ville ikke begynde med at masseændre de eksisterende udkast. Først skal vi vide, hvilke fremtidige transaktioner der skal følge hvilken fordeling. Derefter gennemgår vi de udkast, der har brug for det. Analysen giver grundlag for en beslutning om opsætningen. Den træffer ikke beslutningen for os.

• Periodiser indtægter og udgifter

Jeg ville også gerne undgå, at gennemgangen bliver misforstået, hvis nogen bogfører en faktura i løbet af formiddagen. Forestil dig, at økonomiafdelingen sender et skærmbillede klokken ni, og en kollega bogfører to af dokumenterne klokken ti. Ved frokosttid viser billedet og den aktuelle kladdeoversigt noget forskelligt. Det behøver jo ikke betyde, at der er gået noget galt med tallene.

Derfor skal man sige, hvad gennemgangen omfatter, og hvornår den er lavet. »Her er de fakturaudkast, vi gennemgik i morges« er en brugbar beskrivelse. »Her er vores periodiserede omsætning« er for bredt. For de bogførte beløb viser salgsperiodiseringsoversigten indtægtsførte og resterende beløb pr. kunde og dokument på en valgt balancedato. Finansperiodiseringsoversigten giver det bogførte overblik fra finanskontienes side. De rapporter besvarer et andet spørgsmål end vores gennemgang af udkast. Skal ledelsen have et samlet billede af det bogførte og de påtænkte transaktioner, skal de to datagrundlag afgrænses tydeligt. Ellers kan samme forretning tælle med to gange: først fra et gammelt udtræk af udkast og derefter som bogført faktura.

• Rapporten med oversigt over salgsperiodiseringer
• Rapporten med oversigt over finansperiodiseringer

Så ville jeg undlade at kalde oversigten en prognose i mødematerialet. Der kan være ydelser, vi endnu ikke har faktureret, tilbud, der aldrig bliver til fakturaer, og udkast, som ingen har tænkt sig at bogføre. Det interessante er, at økonomiafdelingen kan gennemgå det, der allerede er forberedt, uden at gøre det til et billede af hele fremtiden. Det lyder mindre ambitiøst end en prognose, men til gengæld ved man, hvad man ser på.

Og man kan lægge indsatsen et andet sted. Opdager virksomheden i dag først en overraskende fordeling efter bogføring, kan spørgsmålet stilles tidligere, så en senere korrektion måske undgås. Det betyder ikke, at hver faktura skal forbi endnu et udvalg. Begynd eventuelt med den mindre gruppe, hvor tidspunktet varierer: årsabonnementer, aftaler, der begynder midt på året, eller dokumenter med en ny skabelon. Undersøg så, om gennemgangen fanger noget, de nuværende dokumentkontroller overser. Finder den ingenting og tager en hel eftermiddag, skal opgaven afgrænses bedre. En kontrol skal gøre en konkret beslutning lettere. Gevinsten er ikke endnu en rapport, men at opdage en misforståelse, mens dokumentet stadig er et udkast.

Den næste forskel er mere direkte knyttet til en opgradering. Muligheden for manuelt forbrug uden krav om pluk blev indført i Business Central 26. I version 29 bliver overgangen obligatorisk. Ifølge dokumentationen ændres eksisterende indstillinger fra Manual til Pick plus Manual. Det lyder næsten bagvendt, når budskabet netop er, at manuelt forbrug nu kan ske uden pluk. Hvorfor bevarer overgangen plukkravet?

• Registrer komponentforbrug ud fra operationsoutput
• Nyheder i Business Central-opdatering 29.0
• Nyheder i Business Central-opdatering 26.0

For at bevare den hidtidige adfærd i stedet for ubemærket at fjerne et lagertrin. Pluk og forbrug beskriver forskellige ting. Pluk handler om at forsyne produktionen med materiale. Forbrug registrerer, at produktionen har brugt det. Med den nye opdeling kan Manual registrere forbruget uden at kræve det pluk, mens Pick plus Manual bevarer plukkravet, hvor lagerhåndteringen kræver det. Forestil dig en komponent, som virksomheden allerede opbevarer ved maskinen. Nogen skal stadig registrere, hvor meget der er brugt, men et særskilt pluk til hver ordre afspejler måske ikke den måde, materialet bliver leveret på. Her kan Manual passe. Det er ikke en grund til at fjerne pluk for komponenter, der faktisk bliver udleveret fra lageret ordre for ordre.

• Registrer komponentforbrug ud fra operationsoutput

Så Pick plus Manual efter opgraderingen kan faktisk være et betryggende syn. Navnet er ændret, fordi det gamle navn har fået en anden betydning. Jeg ville være varsom med at rydde op og sætte det tilbage til Manual, bare fordi det stod sådan på det gamle skærmbillede i vejledningen. En tilsyneladende kosmetisk rettelse kan blive en ændring af arbejdsgangen.

• Registrer komponentforbrug ud fra operationsoutput

Det er netop den rettelse, jeg ville undgå. Bevar den overførte adfærd, medmindre der er en grund til at ændre processen. Og forklar navnene med produktionens egne ord: Skal denne komponent stadig plukkes, før forbruget må registreres? Det er mere brugbart end at tale om, hvilken enum-værdi opgraderingen valgte. Der er ingen præmie for det korteste navn. Hvis lageret bevidst styrer udleveringen af materialet, kan det rigtige resultat være at beholde Pick plus Manual. Den nye mulighed giver os en bedre måde at beskrive en anden fysisk arbejdsgang på. Den gør ikke den eksisterende arbejdsgang forældet, bare fordi navnet nu er lidt længere.

• Registrer komponentforbrug ud fra operationsoutput

Lad os blive ved maskinen. Virksomheden har en beholder med materiale stående der og fylder den op særskilt. Forbruget varierer fra opgave til opgave. Jeg kan godt forstå, at man ikke opretter et ordrepluk for hver håndfuld, men nogen skal stadig måle forbruget. Betyder Manual så, at vi bevidst har valgt mindre automatisering?

Det kan det godt betyde. I eksemplet er den værdifulde oplysning, hvor meget der faktisk blev brugt. Hvis hver færdig enhed teoretisk kræver en fast mængde, kan det være bekvemt at beregne forbruget ud fra det færdigmeldte antal. Men varierer det reelle forbrug mærkbart, kan medarbejderens måling fortælle mere. At fjerne plukkravet og at automatisere mængden er to forskellige valg. Dem ville jeg også holde adskilt i samtalen med virksomheden. Spørg operatøren, hvad der kan registreres pålideligt ved maskinen. Er svaret en målt mængde ved opgavens afslutning, så tag udgangspunkt i det. Ikke i den indstilling, der giver færrest klik i en demonstration.

Færre klik kan være en meget overbevisende demonstration. Jeg ville stille et lidt mindre flot spørgsmål: Når beholderen er næsten tom, kan næste hold så se det i registreringerne? Hvis operatøren først registrerer det hele fredag, har vi måske fjernet et pluk, men beholdt fire dage, hvor oplysningerne halter bagefter.

Så ville jeg ændre den foreslåede arbejdsgang, før jeg ændrede indstillingen. I den virksomhed kan vagtskiftet være det vigtige registreringstidspunkt frem for fredagens samlede oprydning. Vi har brug for en praktisk måde at registrere det brugte materiale på og en aftale om, hvem der afklarer en manglende mængde. Det er en afvejning: Mere aktuelle tal kræver en opgave, som nogen faktisk kan udføre. Afbryder det produktionen at registrere hver lille portion, er afslutningen på en opgave eller en vagt måske et bedre kompromis. Det er virksomhedens valg, ikke tidspunkter, funktionen fastlægger. Opdelingen i systemet er nyttig, fordi vi kan tale om forbrugsregistreringen uden at lade, som om et ordrepluk er den samme oplysning.

• Registrer komponentforbrug ud fra operationsoutput

Lad samme virksomhed have en anden komponent: En dyr del, som ligger på et kontrolleret lager og bliver udleveret til en bestemt ordre. Jeg vil nødig have vores fornuftige beslutning om beholderen gjort til en regel for hele fabrikken. Kan man vælge så præcist?

Dokumentationen beskriver valget på varen, lagervaren og produktionsordrens komponentlinje. Så ja, vi skal se på de relevante poster sammen med lokationens lagerhåndtering for produktionsforbrug. Jeg ville ikke udlede den endelige adfærd af varekortet alene. Din dyre del giver os en god modsætning at afprøve i en sandbox: Én komponent, som bevidst skal leveres via pluk, og én, som bevidst skal kunne forbruges uden det ordrebestemte trin. Skriv den forventede forskel ned, før nogen afprøver det. Ellers fortæller en vellykket bogføring kun, at systemet tillod noget. Ikke at arbejdsgangen stadig håndhæver den forskel, lageret havde brug for.

• Registrer komponentforbrug ud fra operationsoutput

Jeg ville også tage den medarbejder med, der skal forklare en difference. Hvis den registrerede mængde er forkert, giver den foreslåede arbejdsgang så mulighed for at finde ud af, om materialet er brugt, flyttet et andet sted hen eller bare ikke registreret? Beskeden om, at bogføringen lykkedes, hjælper ikke ret meget dér.

Så bliver afprøvningen mere end en demonstration, hvor alt går som forventet. I vores tænkte arbejdsgang ville jeg give medarbejderen en kendt difference og se, om registreringerne stemmer med operatørens forklaring. Vi beder ikke Business Central om automatisk at finde årsagen. Vi undersøger, om det grundlag, medarbejderne bruger til at forklare hændelserne, stadig findes, når et trin fjernes. Hvis plukket også havde et andet formål, for eksempel at bekræfte hvem der modtog en dyr komponent, skal det formål stadig være dækket. For beholderen har et ordrepluk måske aldrig bidraget med en meningsfuld oplysning. De to situationer skal gerne kunne føre til hver sin konklusion.

Dokumentationen rummer også en lille fælde. Den praktiske vejledning beskriver stadig, hvordan funktionen aktiveres i Funktionsstyring. Det giver mening for tidligere versioner. Men oversigten over version 29 angiver, at overgangen er obligatorisk. Samtalen om opgraderingen skal altså ikke ende i en jagt på en valgfri kontakt, som ikke længere er valgfri i den aktuelle version.

• Registrer komponentforbrug ud fra operationsoutput
• Nyheder i Business Central-opdatering 29.0
• Nyheder i Business Central-opdatering 26.0

Nej, tjek miljøets version, og læs vejledningen i den sammenhæng. Skil også de to opgaver ad: Først skal vi bekræfte, at opgraderingen bevarer den ønskede proces. Derefter kan vi overveje, om den særskilte Manual-adfærd skal bruges nogen steder. Den første opgave kan sagtens ende uden en eneste ændring af arbejdsgangen. Den anden kræver, at de ansvarlige for produktion og lager er med, fordi den ændrer, hvordan materialet bliver registreret. Muligheden er, at to forskellige fysiske arbejdsgange ikke længere behøver at passe ind under samme beskrivelse. Og det er et helt rimeligt resultat at sige: Vores komponenter bliver faktisk plukket til hver ordre, så det fortsætter vi med.

Vi bliver ved opgraderingerne. Der findes en administrationsfunktion, som er værd at kende, før morgenen bliver besværlig: Man kan annullere en igangværende miljøopdatering fra operationens detaljer. Det er en eksisterende mulighed, og det er noget andet end at fjerne en planlagt opdatering fra kalenderen. Det afgørende er, hvad der sker, efter man trykker Annuller. Hvis virksomheden snart skal bruge systemet, får man så brugerne hurtigere ind igen ved at afbryde?

• Administrer opdateringer i Business Central Administration Center
• Afbryd en igangværende miljøopdatering: udgivelsesplan

Det kan man ikke gå ud fra. Annulleringen stopper opdateringen og gendanner miljøet til tilstanden lige før opdateringens start. Den gendannelse kan tage mere end en time, og miljøet er stadig utilgængeligt imens. Administratoren får altså mulighed for at gribe ind, ikke en knap til øjeblikkelig genåbning. Forestil dig, at arbejdsdagen snart begynder, mens opdateringen stadig kører. Der er to usikre forløb: lade opdateringen fortsætte eller annullere og vente på gendannelsen. At den ene mulighed hedder Annuller, gør den ikke til den hurtigste. Beslutningen kræver operationens aktuelle status og en klar prioritering fra virksomheden. Ikke bare irritation over, hvor længe det allerede har taget.

• Administrer opdateringer i Business Central Administration Center

Så er »vi har annulleret den« en dårlig besked til dem, der venter. De kan høre det som »nu kan I logge på«. Jeg ville hellere sige, at gendannelsen er begyndt, og at vi kontrollerer adgangen, før vi melder systemet klar. Men burde opdateringsvinduet ikke allerede beskytte starten på arbejdsdagen?

Almindelige opdateringer bliver automatisk annulleret, hvis de ikke er gennemført, når vinduet slutter. Manuel annullering er relevant, hvis man skal gribe ind tidligere, eller hvis opdateringen har fået lov til at fortsætte uden for vinduet. Der er også en fast begrænsning: Man kan ikke annullere, når den version, miljøet opdateres fra, er i sin tvungne opdateringsperiode, Enforced Update Period. Derfor begynder beslutningen med, hvilke muligheder denne operation faktisk har. Er annullering mulig, kan vi vurdere den. Er den ikke, hjælper det ikke de ventende medarbejdere at bruge en halv time på at lede efter en anden vej til samme knap. Så handler det om status, relevant support og klare beskeder til virksomheden.

• Administrer opdateringer i Business Central Administration Center

Lad os sige, at muligheden er der. Jeg ville gerne have den forretningsansvarlige med, før morgenen bliver til en diskussion om, hvem der trykkede på knappen. Måske er dagens vigtigste opgave en afsendelse med en fast tidsfrist. I morgen kunne virksomheden acceptere længere nedetid for at få opdateringen færdig. Samme ventetid kan altså føre til forskellige beslutninger.

Og det er værd at aftale, før opdateringen starter. Ikke en automatisk regel om at annullere efter fyrre minutter. Snarere: Hvem må beslutte det, hvilken forretningsmæssig frist er vigtig, og hvornår kan den ansvarlige kontaktes? I dit eksempel med afsendelsen er spørgsmålet, om et indgreb har en realistisk mulighed for at forbedre situationen ud fra de oplysninger, vi faktisk har. Vi skal ikke opfinde et sluttidspunkt for nogen af forløbene. Hvis ingen af dem har et pålideligt tidspunkt for færdiggørelse, kan virksomheden have brug for at tage sin aftalte nødprocedure i brug. Det er bedre end at vente på et beroligende klokkeslæt, som administratoren ikke har grundlag for at give.

Det afgrænser løftet meget godt: mere kontrol, men ikke en garanti for hurtigere genåbning. For udviklerne kommer version 29 med en anden slags fleksibilitet. AL-interfaces kan få standardimplementeringer af metoder i efterårsversionen fra 2026, med runtime 18. Hovedpointen er, at man kan tilføje funktionalitet, uden at alle eksisterende implementeringer skal ændres med det samme. Hvilken aftale er det egentlig, man ændrer her, hvis vi også skal have dem med, der ikke skriver AL?

• Interfaces i AL
• Vælg runtimeversion til AL

Et interface angiver, hvilke operationer forskellige stykker kode skal kunne tilbyde. Forestil dig en specialudviklet funktion, der eksporterer dokumenter gennem flere forskellige eksportkomponenter. Koden, der kalder dem, beder om et dokument uden at skulle kende deres indre opbygning. Det er vores tænkte design, ikke en standardfunktion, vi annoncerer. Ejeren vil nu tilføje en operation, som beder eksportkomponenten om en læsevenlig beskrivelse. En standardmetode kan give en fælles adfærd, mens den enkelte komponent kan levere sin egen. De eksisterende implementeringer bliver ikke alle tvunget til at skrive den nye metode bare for fortsat at kunne bruges. Det interessante er, om det fælles svar faktisk er nyttigt for alle dem, der arver det.

• Interfaces i AL

En beskrivelse lyder ret tilgivende. Står der dokumenteksport i stedet for et fint, præcist navn, kan funktionen stadig være til at forstå. Men forestil dig, at det nye spørgsmål er: Kan denne komponent håndtere fortrolige dokumenter? Så ville et ubekymret standardsvar gøre mig nervøs. Begge tilføjelser kan teknisk være valgfrie, men konsekvenserne er meget forskellige.

Der ville jeg holde op med at betragte standarden som en bekvemmelighed og skrive dens betydning ned. I vores design kan en generel beskrivelse være sand. Men komponentens eksistens siger ikke noget om, hvorvidt den kan håndtere fortrolige oplysninger. Har implementeringen aldrig leveret den oplysning, skal den kaldende kode ikke stiltiende læse manglende viden som en godkendelse. Vi kunne udforme et svar, der betyder ukendt eller ikke understøttet, og lade arbejdsgangen reagere på det. Eller beslutte, at muligheden først tilbydes, når der findes en udtrykkelig implementering. Det er designvalg, ikke adfærd, Business Central automatisk leverer. Sprogfunktionen lader os angive en reserveadfærd. Den vælger ikke en forsvarlig forretningsmæssig betydning for os.

Jeg foretrækker et ærligt ved ikke frem for et opdigtet ja. Men der er også en omkostning den anden vej: Hvis alle ældre eksportkomponenter pludselig fremstår som ikke understøttede, kan brugeren miste en arbejdsgang, der fungerede før. Hvordan undgår man, at et forsigtigt standardsvar kommer til at lukke en funktion ved et uheld?

Ved ikke at gøre den gamle arbejdsgang afhængig af det nye svar, før man har besluttet, at det er nødvendigt. Almindelig eksport kunne fortsætte efter de eksisterende regler, mens en ny mulighed for fortrolig eksport kræver udtrykkelig understøttelse. Så kan en ældre implementering beholde sin hidtidige opgave uden at få tillagt en evne, ingen har kontrolleret. Beslutter virksomheden derimod, at al eksport nu skal opfylde det strengere krav, er det en bevidst overgang med konsekvenser for brugerne. Den bør ikke komme forklædt som en harmløs ekstra metode. Din indvending ændrer min foreslåede test: Vi skal ikke kun se, at den nye mulighed bliver blokeret korrekt. Vi skal også se, at almindelig eksport stadig fungerer som tilsigtet med en uændret implementering.

Det giver løftet om kompatibilitet en meget tydeligere grænse. Microsoft skriver også, at en ny standardmetode ikke ændrer interfacets runtime-identifikator, så afhængige udvidelser ikke behøver at blive kompileret igen på grund af den tilføjelse. Jeg kan forestille mig en systemejer, der hører det som, at der slet ikke er noget at koordinere. Hvad er det egentlig, identifikatoren beskytter?

• Livscyklus for interfacemetoder

Den repræsenterer de krævede metoder i interfacets kontrakt under kørsel. En standardmetode føjer ikke en ny krævet metode til den identitet. Det fjerner en konkret kompatibilitetshindring, og det er en reel forbedring. Men det vurderer ikke vores regler for eksport, teksten brugeren ser, eller hvad den kaldende kode gør med et ukendt svar. Der er to spørgsmål: Kan delene stadig sættes sammen, og betyder deres samlede adfærd stadig det, vi ønsker? Funktionen hjælper med det første. Det andet skal vi stadig undersøge. Jeg ville koordinere ud fra den ændrede adfærd, ikke automatisk sætte alle afhængige teams til at bygge deres udvidelser igen, hvis det ikke er nødvendigt.

• Livscyklus for interfacemetoder

Og nogle gange kan det være dejligt udramatisk. Vi tilføjer den læsevenlige beskrivelse, de ældre komponenter bruger den generelle tekst, og kun dem, der har gavn af et bedre navn, behøver opmærksomhed. Jeg vil nødig have, at eksemplet med fortrolige dokumenter får hver lille interfaceændring til at lyde som et sikkerhedsprojekt.

Det skal det heller ikke. En lille, sandfærdig standard er netop et sted, hvor koordineringen kan blive lettere. I beskrivelseseksemplet ville jeg sammenligne en uændret komponent med en, der leverer en særlig beskrivelse. Se, om den kaldende kode viser begge fornuftigt, og om almindelig eksport stadig opfører sig som forventet. Det er en afgrænset kontrol af den konkrete ændring. Vi behøver ikke opfinde en stor overgangsplan, bare fordi sproget har fået et nyt værktøj. Det mere alvorlige eksempel viser, hvor samme genvej ikke længere er passende. Gode standarder gør hverdagstilfældene kedelige på den gode måde. De skal ikke skjule beslutninger, som hver implementering er nødt til at tage selv.

Hvad hvis det fælles svar er nyttigt nu, men ejeren ved, at hver eksportkomponent på sigt skal have sit eget? Dokumentationen beskriver RequiredPending til den overgang. Navnet lyder som en besked til udviklerne: I kan fortsætte i dag, men det her bliver jeres ansvar.

• Attributten RequiredPending

Det er den tilsigtede rækkefølge. Standardmetodens kode bliver stående, men RequiredPending får compileren til at advare de implementeringer, der ikke selv overtager metoden. I en senere hovedversion kan ejeren fjerne standardkoden og attributten, så metoden bliver krævet. Den senere ændring påvirker runtime-identiteten og kræver, at afhængige udvidelser kompileres igen. AppSourceCop skelner mellem den varslede overgang og bare at fjerne standardkoden uden varslingsfasen. De tekniske afsnitsnoter linker til den detaljerede beskrivelse af forløbet. Den praktiske pointe er, at valgfri indtil videre kræver en plan, andre kan handle på. En advarsel er ikke dokumentation for, at det andet team har set den, sat arbejdet i kalenderen eller udgivet sin opdatering.

• Livscyklus for interfacemetoder
• Attributten RequiredPending

Især hvis det team ikke har bygget sin udvidelse igen for nylig. Advarslen dukker op i udviklernes arbejdsgang. Den, der planlægger virksomhedens opgradering, ser den måske aldrig. Jeg ville også have begrundelsen og den planlagte version forklaret i almindeligt sprog. Ellers kan »vi har varslet det« komme til at betyde, at vi har lagt en tekst et sted, ingen har åbnet.

Og begrundelsen skal forklare, hvilken adfærd teamet skal levere. Ikke bare at der skal findes en metode. I vores eksportdesign kunne en stump kode med et bekvemt standardsvar få opgaven til at se færdig ud, uden at det egentlige spørgsmål var besvaret. Jeg ville bede det ansvarlige team vise det tilsigtede resultat for sin eksportkomponent og bede den kaldende side vise, hvordan resultatet bliver brugt. Så hænger begge sider af aftalen sammen. Standardmetoder kan altså mindske unødvendigt arbejde, som ellers skulle ske samtidig, og RequiredPending kan give nødvendig ændring en gradvis overgang. Ingen af delene fjerner behovet for at beslutte, hvad den fælles kontrakt betyder. Det er dér, det værdifulde designarbejde ligger.

Vi slutter med noget mindre, som mange vil genkende med det samme: Kunden sender et varenummer, som ikke er jeres varenummer. Varereferencer i Business Central er en eksisterende mulighed for at forbinde betegnelserne, inklusive kundens eller leverandørens beskrivelse, enhed og variant. Det er ikke en nyhed fra version 29. Det er en nyttig opdagelse for den, der skal oversætte andres varenumre, før ordren kan indtastes.

• Brug varereferencer

Forestil dig, at kunden bestiller sin kode BLUE-TWELVE. Virksomhedens vare har et andet nummer, og kundens kode betyder den blå variant i en karton. En opsat reference kan overføre den sammenhæng til dokumentet, når referencen vælges. Det er mere end et kaldenavn: Indeholder referencen en variant eller en enhed, bliver de værdier også kopieret, og beskrivelsen kan erstatte linjens beskrivelse. Værdien er derfor ikke kun, at man slipper for et opslag. Ordren kan afspejle, hvad kunden faktisk mener med sin kode. Det kræver selvfølgelig, at sammenhængen i referencen er sat rigtigt op.

• Brug varereferencer

Kartonen er den detalje, jeg ville kontrollere først. Beder kunden om to, mener de så to styk eller to kartoner? Varenummeret kan se rigtigt ud, selv om vi er på vej til at levere den forkerte mængde. Jeg vil hellere have betydningen afklaret én gang end være afhængig af, at den mest erfarne ordremedarbejder husker den for altid.

Det er et godt sted at begynde i det små. Tag én konkret handelspartner, og bekræft referencens betydning ud fra et aftalt ordreeksempel. I vores opdigtede situation skal det interne varenummer, den blå variant og kartonenheden passe med bestillingen, før opsætningen kan betragtes som klar. Giv derefter nogen ansvar for at vedligeholde sammenhængen, når kunden ændrer sin pakning eller sine numre. En reference kan spare gentagen fortolkning, men kun så længe den gemte fortolkning er rigtig. Jeg ville ikke oprette endnu en vare alene for at få nummeret til at ligne kundens, medmindre der var en anden forretningsmæssig grund til en særskilt vare.

Der er også en mobil mulighed. Microsoft beskriver scanning af stregkoder til varereferencer i Business Central-mobilappen på understøttede sider, blandt andet købs- og salgslinjer. Det er oplagt, når nummeret står på en etiket lige foran én. Men afgør en vellykket scanning vores spørgsmål om kartonen?

• Brug varereferencer

Den hjælper med at indtaste referencen. Den fastslår ikke, at det fysiske indhold passer til opsætningen. I kartoneksemplet kan en tydelig stregkode stadig pege på en forældet fortolkning. Jeg ville bruge scanningen til at spare indtastning og så kontrollere den udfyldte linje og den faktiske pakning ved en lille afprøvning på den understøttede mobilside. Fungerer det, har man fjernet en helt almindelig irritation uden at lave et stort projekt ud af det. Og har virksomheden kun brug for referencen ved ordreindtastning på computeren, er det nyttigt i sig selv. Mobilen er en ekstra vej ind, ikke en forudsætning for at få glæde af kunders og leverandørers referencer.

Det er et godt sted at slutte: En lille forbedring kan være nok. I dag fandt vi en mulighed for at stille spørgsmål til en plan før bogføring, et tydeligere valg om produktionens materialeregistrering og en måde, hvorpå udviklere kan ændre en fælles aftale, uden at alle skal følge med på én gang. Vi fandt også grænserne for løfterne: En annulleret opdatering kræver gendannelse, og en aflæst reference kontrollerer ikke varerne. Ingen af de beslutninger bliver afgjort af et nyt navn alene. Vælg den forskel, der betyder noget i dit arbejde, og hold den op imod en konkret opgave. Direkte kilder og tekniske detaljer finder du i afsnitsnoterne. Tak, fordi du lyttede til Central Perspectives fra ITrators. Vi høres ved.