Abakion Legal 27.1.202625.6032 & Abakion Legal DK 27.1.202625.6034

Det er nu muligt at få datoer i dokumentskabeloner formateret efter skabelonens sprogkode. Tidligere var der kun de to faste formater dato_kort og dato_lang, som begge altid brugte dansk datoformat uanset skabelonens sprog.

For at anvende sprogsensitiv datoformatering skal feltet Datoformat på den relevante datakildeline sættes til 1 eller 4 for langt datoformat med månedsnavn (f.eks. 3. juni 2026 på dansk, 3 June 2026 på britisk engelsk, June 3, 2026 på amerikansk engelsk, 3 Juni 2026 på tysk), eller 2 for numerisk datoformat med fuldt årstal (f.eks. 03-06-2026 på dansk og europæiske sprog, 2026-06-03 på tysk).

Bemærk: Sprogsensitiv formatering fungerer kun når Datoformat-kolonnen anvendes på datakildelinjen. Hvis Format-kolonnen anvendes i stedet, ignoreres skabelonens sprogkode og datoen formateres altid med den angivne formatstreng uanset sprog.

Skabelonens sprogkode hentes fra feltet Sprogkode på dokumentskabelonen. Det kræver desuden at sproget i BC's sprogliste har en gyldig ISO-sprogkode (f.eks. EN-GB, EN-US, DE-DE). Mangler ISO-koden, falder systemet tilbage på dansk formatering.

Det var tidligere kun muligt at udfylde feltet Varighed på opgaver af typen Møde. For alle andre opgavetyper — fx Opkald, Fremnotering og Blank — var feltet nedtonet og kunne ikke redigeres.

Feltet Varighed er nu aktivt for alle opgavetyper. Det kan udfyldes i Opret opgave under fanen Udvidet samt på Opgavekortet. Feltet er ikke obligatorisk og kan sagtens stå tomt.

Det er nu muligt at tilføje en fritekst-bemærkning direkte på en klientbetalingspost i oversigten Klientbetalingsposter. Bemærkningen fungerer som en personlig huskeseddel og følger posten, men påvirker hverken bogføring eller eksport til bank.

Bemærkningen vises som en kolonne i listen og kan bruges til søgning og filtrering. For at skrive eller ændre en bemærkning på en post bruges handlingen Rediger bemærkning i båndet, som åbner en lille dialogside, hvor feltet kan redigeres. Siden gemmer automatisk ved lukning.

Derudover er der tilføjet en ny handling, Valider ikke eksporterede poster, som gennemgår alle ikke-eksporterede poster og opdaterer eventuelle fejlmeddelelser i kolonnen Eksport fejlbesked. Kolonnen vises nu med rød tekst, hvis der er en fejl, så det er let at få øje på poster der kræver opmærksomhed.

Når en medarbejders samlede tidsregistrering på en given dag overskred det tilladte maksimum, blev de berørte linjer markeret med en fejl og vist med rød farve på siden Tidsregistreringslinjer. Problemet opstod, når en bruger efterfølgende rettede fejlen — fx ved at reducere timerne på én af linjerne — men de øvrige linjer for samme dag forblev røde, selvom den samlede tid nu var korrekt.

Det betød, at brugeren så fejlmarkeringer på linjer, der reelt var i orden, hvilket kunne skabe forvirring om hvorvidt registreringen var godkendt.

Dette er nu rettet. Alle tidsregistreringslinjer for den pågældende medarbejder og dato opdateres automatisk, når der foretages en ændring. Fejlmarkeringen forsvinder fra alle linjer, så snart den samlede registrerede tid er inden for det tilladte maksimum.

Hvis en tidspost refererede til en dimensionsværdi (f.eks. en afdeling eller et projekt), der efterfølgende var blevet spærret i Business Central, ville hele baggrundskøen fejle. Det betød at ikke kun den fejlende post, men også alle efterfølgende tidsposter i samme kørsel, aldrig blev behandlet — og uden at brugeren fik besked om hvad der var galt.

Rettelsen sikrer at baggrundskøen nu håndterer fejl per post: hvis én post fejler på grund af en spærret dimension, markeres den som fejlet med en beskrivende fejlbesked, og kørslen fortsætter med de øvrige poster.

Derudover er der tilføjet en tidlig validering direkte i Tidsregistrering: systemet tjekker nu allerede inden bogføring om en posts dimensionsværdier er spærrede. Opdages en spærret dimension, markeres linjen som fejlet med en fejlbesked synlig i brugergrænsefladen — så problemet kan rettes, inden det overhovedet forsøges bogført.

Når man anvendte Tilbagefør/fremfør på en bogført faktura, og sagen benyttede salærdimensioner — fx til at registrere en skaffer som dimensionsværdi på finans- og sagsposter — blev dimensionerne ikke overført korrekt til kreditnotaen og den nye fremførte faktura.

Resultatet var, at brugeren ved efterfølgende statusskift på den fremførte faktura fik fejlmeddelelsen: Dimensionskode XXXXX ikke fundet for Faktura ####. Denne er obligatorisk.

Fejlen er rettet. Salærdimensioner overføres nu korrekt til både kreditnota og fremført faktura ved brug af Tilbagefør/fremfør, og statusskift kan gennemføres uden fejl.

Ved oprettelse af en ny undersag på en sag med mange eksisterende undersager kunne systemet fejle med beskeden "Recorden i tabellen Kontakt findes allerede". Fejlen opstod, når antallet af undersager overskred et rundt tal — f.eks. ved overgang fra 9 til 10, fra 99 til 100 eller fra 999 til 1000 undersager.

Årsagen var, at systemet fandt det seneste undersagsnummer ved hjælp af tekstsortering frem for numerisk sortering. Det betød at f.eks. "Sag-99" blev vurderet som "nyere" end "Sag-100", og systemet forsøgte derefter at oprette "Sag-100" på ny — selv om den allerede fandtes.

Fejlen er nu rettet, så systemet altid finder det korrekte næste ledige undersagsnummer. Rettelsen gælder både ved direkte sagsoprettelse i Abakion Legal og ved oprettelse via CMI.

Ved tryk på Journalisering-knappen i Abakion Legal basis-rollecenteret opstod en fejl, hvis den e-mail der skulle journaliseres havde mange modtagere i Til- eller CC-feltet. Fejlen betød at journaliseringen ikke kunne gennemføres.

Årsagen var at listen over e-mail-modtagere i visse tilfælde overskred den tilladte tegngrænse på 250 tegn, inden den blev gemt. Rettelsen sikrer nu at modtagerlisten afskæres korrekt, så journaliseringen gennemføres uden fejl — også ved e-mails med mange modtagere.

I rapporten Tid til afregning pr. medarbejder ignorerede systemet det datofilter, som brugeren angav ved kørsel. Uanset om der fx blev valgt et enkelt månedsinterval, viste rapporten timedata og beløb fra hele perioden.

Årsagen var, at rapporten ikke tog højde for det valgte Datofilter, når den hentede data fra sagsposter. Dette er nu rettet.

Rapporten viser herefter kun fakturerbare timer og beløb inden for det valgte datointerval.

Ved debitorefterudligning kunne tilsvarsberegningen give forkerte resultater fra og med den anden bogføring. Tilsvarsberegningen blev ikke korrekt nulstillet, og kurs tab/gevinst blev i nogle tilfælde ikke bogført på den korrekte finanskonto (Tilsvar/tilgode).

Fejlen er nu rettet, så tilsvarsberegningen fungerer korrekt ved alle bogføringer — også når der udlignes flere gange på samme sag.

Derudover er der rettet en fejl, hvor tilsvarsniveauet fra udligningsposten ikke blev overført korrekt til justeringsposten.

Når man i indbetalingskladden brugte funktionen Opdel samlebetaling på en linje med en samlefaktura, blev de nye linjer i visse tilfælde oprettet uden beløb eller med forkert fortegn.

Fejlen er nu rettet. De nye linjer udfyldes korrekt med beløbene fra de tilknyttede fakturaer, og den samlede betaling fordeles præcist ud på linjerne.

Hvis en Azure AD-gruppe blev omdøbt i Entra AD, viste faktaboksen Sikkerhedsgruppemedlemmer på sagen stadig det gamle gruppenavn — selv efter at synkroniseringen med Azure var kørt.

Årsagen var, at gruppenavnet på eksisterende sager blev gemt som et snapshot ved oprettelsen og ikke blev opdateret efterfølgende. Selve rettigheder i SharePoint var korrekte, men det forældede navn kunne skabe forvirring hos brugerne.

Rettelsen sikrer, at næste gang Azure-grupper synkroniseres — enten via jobkøen eller via den manuelle Hent Azure-grupper-handling — opdateres gruppenavnet automatisk på alle sager, hvor gruppen er tildelt. Eksisterende sager med et forældet gruppenavn rettes automatisk ved den næste synkronisering uden behov for manuel oprydning.

Ved CVR-opslag på kontakter i Abakion Legal DK kunne søgningen fejle med en fejlmeddelelse om tekstlængde, hvis den virksomhed man slog op havde en særligt lang branchebeskrivelse fra Virk. Fejlen opstod fx ved virksomheder med branchekoden for finansielle tjenesteydelser, hvis beskrivelse er over 100 tegn.

Årsagen var, at branchebeskrivelsen fra Virk API'et blev gemt direkte i feltet Branchegruppe – Beskrivelse, som har en maksimal længde på 100 tegn. Når Virk returnerede en længere tekst, afbrød systemet med en fejl frem for at gemme.

Rettelsen sikrer, at branchebeskrivelsen automatisk afkortes til feltets maksimale længde inden den gemmes, så CVR-søgningen altid gennemføres uden fejl. Branchekoden gemmes fortsat uændret og er den forretningsmæssigt centrale oplysning.