OS2sofd

- Om OS2sofd: https://www.sofd.io/
- Brugervejledning: https://www.sofd.io/brugervejledning/
- Adviser: https://www.sofd.io/brugervejledning/adviser/
- Moduler og funktioner: https://www.sofd.io/moduler/
- Telefoni: https://www.sofd.io/moduler/telefoni/
- Implementeringsdrejebøger: https://www.sofd.io/implementation-guides/
- Drejebog: OPUS-kommune: https://www.sofd.io/implementation-guides/opus-loen-integration/
- Drejebog: SD-kommune: https://www.sofd.io/implementation-guides/sd-loen-integration/
- Drejebog: Opgradering til 2026R2 (IDM): https://www.sofd.io/implementation-guides/opgradering-2026r2-idm/
- Brugerstyring: https://www.sofd.io/idm/
- Forudsætninger og forberedelse: https://www.sofd.io/idm/prerequisites/
- Processer og hændelser: https://www.sofd.io/idm/processes/
- Personinaktivering: https://www.sofd.io/idm/person-inactivation/
- Konfiguration: https://www.sofd.io/idm/configuration/
- Teknik: https://www.sofd.io/teknik/
- Arkitektur: https://www.sofd.io/teknik/arkitektur/
- Datamodel: https://www.sofd.io/teknik/datamodel/
- Login og SAML: https://www.sofd.io/teknik/login/
- API: https://www.sofd.io/teknik/api/
- OData (læsning): https://www.sofd.io/teknik/api/odata/
- REST-API: https://www.sofd.io/teknik/api/rest/
- Fremtidig API-udvikling: https://www.sofd.io/teknik/api/strategi/
- Batchkørsler: https://www.sofd.io/teknik/batchkoersler/
- Integrationer: https://www.sofd.io/integrationer/
- Emply: https://www.sofd.io/integrationer/emply/
- FK Organisation: https://www.sofd.io/integrationer/fk-organisation/
- HR-ON: https://www.sofd.io/integrationer/hr-on/
- IST Tabulex: https://www.sofd.io/integrationer/ist-tabulex/
- KMD I2: https://www.sofd.io/integrationer/kmd-i2/
- KMD Nexus: https://www.sofd.io/integrationer/kmd-nexus/
- OS2rollekatalog: https://www.sofd.io/integrationer/os2rollekatalog/
- SD Løn: https://www.sofd.io/integrationer/sd-loen/
- On-premise agenter: https://www.sofd.io/agents/
- Brugerkonto Agent: https://www.sofd.io/agents/user-account-agent/
- AD Writeback Agent: https://www.sofd.io/agents/ad-writeback-agent/
- AD Replikator Agent: https://www.sofd.io/agents/ad-replikator/
- AD indlæsningsintegration: https://www.sofd.io/agents/ad-indlaesningsintegration/
- OPUS indlæsningsintegration: https://www.sofd.io/agents/opus-indlaesningsintegration/
- Indlæsning af skoleelever: https://www.sofd.io/agents/skoleelev-indlaesning/
- OS2vikar - Brugerkonto Agent: https://www.sofd.io/agents/os2vikar-agent/
- Download: https://www.sofd.io/downloads/
- Ændringslog: https://www.sofd.io/changelog/
- Support og kontakt: https://www.sofd.io/support/


## SD Løn

Integrationen til **SD Løn** gør lønsystemet til kilde for ansættelser i OS2sofd og
kan, afhængigt af den valgte model, også være kilde for enhederne eller omvendt
overføre kommunens enheder fra OS2sofd til SD. Se
[Datamodel](../../teknik/datamodel/) for begreberne person, tilhørsforhold og enhed.

Integrationen driftes som et centralt middleware-modul (se
[Arkitektur](../../teknik/arkitektur/)). Der skal ikke installeres noget hos
kommunen.

{{< mermaid >}}
flowchart LR
    SD[SD Løn] -->|enheder, ansættelser, ledere| INT[SD-integration]
    INT -->|enheder, personer, tilhørsforhold, ledere| SOFD[OS2sofd]
    SOFD -->|enheder opmærket med SD-tag| INT
    INT -->|enheder via MOX| SD
{{< /mermaid >}}

## Hvornår overføres data

Integrationen kører typisk en gang i timen inden for normal kontortid og desuden hver
gang den startes. Hver kørsel gennemløber trinnene i fast rækkefølge.

1. **Enheder og ansættelser hentes fra SD.** Første gang hentes alle personer og
   ansættelser i institutionen, inklusive de ændringer der allerede er planlagt ud i
   fremtiden. Derefter hentes kun det, der er ændret siden sidste kørsel. Enhederne
   hentes altid i deres helhed.
2. **Enheder overføres fra OS2sofd til SD**, hvis kommunen bruger den model, hvor
   OS2sofd er master for organisationen.
3. **Enheder overføres fra SD til OS2sofd**, hvis kommunen bruger den model, hvor SD
   er master for organisationen.
4. **Personer og tilhørsforhold overføres til OS2sofd**, og ledere sættes på enhederne.
5. **Enhederne i OS2sofd beriges** med oplysninger fra SD.

Integrationen holder sin egen kopi af de hentede SD-data, så en kørsel ikke skal
spørge SD om hele organisationen hver gang. Får en enkelt person brug for en fuld
genindlæsning, kan Digital Identity bestille den, hvorefter personens data hentes
forfra ved næste kørsel.

Svarer SD ikke, springes kørslen over. Fejlen logges som en advarsel, så længe der er
gået mindre end en aftalt periode siden det seneste vellykkede kald til SD, og først
derefter som en egentlig fejl.

Kommunen kan have mere end én institution i SD. Én institution er den primære, og
enhederne fra den udgør organisationen i OS2sofd. Ansættelser fra de øvrige
institutioner placeres på enheder i OS2sofd via en aftalt mapning mellem
SD-afdelinger og OS2sofd-enheder.

## Tre modeller for enhederne

Kommunen vælger ved implementeringen, hvor organisationen vedligeholdes. Se også
[Drejebog: SD-kommune](../../implementation-guides/sd-loen-integration/).

| Model | Master for enheder | Hvad integrationen gør |
| --- | --- | --- |
| 1 | SD | Afdelingshierarkiet i SD indlæses som enheder i OS2sofd |
| 2 | OS2sofd | Enheder i OS2sofd, der er opmærket med tagget `SD`, oprettes og vedligeholdes i SD via MOX-snitfladen |
| 3 | Begge | Enhederne vedligeholdes hvert sted for sig, og OS2sofd-enhederne opmærkes med de tilhørende SD-afdelingskoder |

I alle tre modeller er det tilhørsforholdenes placering, der afgøres af modellen. Se
afsnittet om medarbejdere nedenfor.

### Model 1, enheder fra SD

Afdelingerne i SD's organisation bliver til enheder i OS2sofd med samme placering i
hierarkiet. Afdelinger, der forsvinder fra SD, nedlægges i OS2sofd, og afdelinger, der
kommer igen, genaktiveres.

SD's hierarki er typisk langt mere findelt end den ledelsesstruktur, kommunen ønsker i
OS2sofd. Som standard overføres derfor kun de afdelinger, der har betydning for
ledelsesstrukturen. En afdeling kommer med, hvis den selv har en leder, hvis en
afdeling direkte under den har en leder, eller hvis der er mere end én leder længere
nede i dens gren. Afdelinger, der ikke kommer med, springes over, så deres
underliggende afdelinger placeres under den nærmeste overliggende afdeling, der kommer
med. Kommunen kan i stedet vælge, at alle afdelinger skal med.

Udvælgelsen kan justeres.

- **Altid med.** En liste over afdelinger, der skal med uanset reglen ovenfor.
- **Aldrig med.** En liste over afdelinger, der udelades sammen med alt under dem, og
  et navnemønster, der udelader afdelinger med bestemte navne.
- **Sammenfald af navne.** Afdelinger, der hedder det samme som deres overliggende
  afdeling (typisk en NY-enhed og en afdeling med samme navn), kan slås sammen, så
  navnet ikke optræder to gange i træet.

Den øverste enhed er enten en bestemt afdeling i SD eller, når institutionen i SD har
flere topafdelinger, en eksisterende enhed i OS2sofd, som SD's topafdelinger så
placeres under.

| Oplysning i OS2sofd | Kilde i SD |
| --- | --- |
| Navn | Afdelingens navn |
| Kortnavn | Afdelingskoden |
| Overordnet enhed | Den nærmeste overliggende afdeling, der er med i overførslen |
| Adresse | Afdelingens postadresse. Land sættes til Danmark |
| Telefon | Afdelingens ottecifrede telefonnummer |
| P-nummer | Afdelingens produktionsenhedsnummer. Kan slås fra. Har SD intet P-nummer, røres det ikke i OS2sofd |
| Lokaludvidelse `SDDepartmentLevelIdentifier` | Afdelingens niveau i SD (fx `NY3-niveau` eller `Afdelings-niveau`) |

### Model 2, enheder til SD

Her er OS2sofd master for organisationen, og integrationen opretter, retter og flytter
enhederne i SD via SD's MOX-snitflade. Det er kun enheder, der er opmærket med tagget
`SD`, der overføres. Tagget skal have en værdi, som fortæller, hvad enheden er i SD.

| Tag-værdi | Betydning |
| --- | --- |
| `NY1`, `NY2`, ... | Enheden er en NY-enhed på det angivne niveau i SD. Integrationen opretter selv en NY-enhed i SD og kan derudover oprette en tilhørende afdeling (skyggeafdeling) under den |
| `NUV` | Enheden er en afdeling (afdelings-niveau) i SD |
| `NY3-xxxx-yyyy` og `NUV-yyyy` | Som ovenfor, men med de fire tegn lange enhedskoder, som enheden skal have i SD. Bruges når kommunen selv vil styre koderne |

Enheder uden tag springes over, så en tagget enheds overordnede i SD bliver den
nærmeste taggede enhed over den i OS2sofd. Det øverste niveau lægges under
institutionen i SD.

| Oplysning i SD | Kilde i OS2sofd |
| --- | --- |
| Navn | Enhedens navn, afkortet til 52 tegn |
| Niveau og enhedskode | Fra tag-værdien |
| Overordnet enhed | Nærmeste taggede enhed over enheden |
| P-nummer | Enhedens P-nummer |
| Adresse | Enhedens primære postadresse |
| Telefon | Enhedens primære telefonnummer |

Ændringer får virkning fra den 1. i indeværende måned, eller fra 1. januar i
indeværende år, hvis kommunen ønsker det. Mister en enhed sit tag, eller nedlægges den
i OS2sofd, kan den ikke slettes i SD. Kommunen vælger i stedet, om enheden skal flyttes
ind under en fast enhed til nedlagte enheder i SD, eller om den skal omdøbes efter et
aftalt mønster, fx med dato og "Nedlagt" foran navnet.

Alle beskeder til SD gemmes, så det kan spores, hvad der er sendt hvornår. Integrationen
kan køres i en prøvetilstand, hvor beskederne dannes og gemmes uden at blive sendt til
SD.

### Model 3, mapning via tags

Her vedligeholdes enhederne begge steder, og kommunen fortæller integrationen, hvilke
SD-afdelinger der hører til hvilke OS2sofd-enheder. Det sker med et tag på enheden i
OS2sofd (navnet på tagget aftales med kommunen), hvor værdien er en eller flere
SD-afdelingskoder adskilt af komma. Ansatte i en SD-afdeling placeres på den enhed, der
er opmærket med afdelingens kode, eller ellers med koden på afdelingens overliggende
NY-enhed.

Er den samme afdelingskode sat på mere end én enhed, vælges den samme enhed hver gang,
og der logges en advarsel, så opmærkningen kan rettes. Findes der slet ingen enhed med
koden, dannes et advis, se nedenfor.

## Berigelse af enheder

I model 2 og 3 skriver integrationen desuden oplysninger fra SD tilbage på enhederne i
OS2sofd, så de kan ses i brugergrænsefladen og bruges af andre integrationer.

| Oplysning på enheden | Model 2 | Model 3 |
| --- | --- | --- |
| Lokaludvidelse `SDDepartmentIdentifier` (afdelingskoden i SD) | Ja | |
| Lokaludvidelse `SDDepartmentLevelIdentifier` (niveauet i SD) | Ja | |
| Lokaludvidelse `SDDepartmentUUIDIdentifier` (afdelingens id i SD, i model 3 alle de taggede afdelingers id'er) | Ja | Ja |
| Lokaludvidelse `Leder i SD` (e-mailadressen registreret på afdelingen i SD) | | Ja |
| P-nummer | | Ja |
| Postadresse fra SD | | Ja |

I model 3 tages P-nummer og adresse fra den første af de taggede afdelinger, der har
oplysningen. Adressen fra SD bliver kun primær, hvis enheden ikke i forvejen har en
primær adresse fra en anden kilde.

## Medarbejdere

Medarbejdere samles pr. CPR-nummer. En person med flere ansættelser i SD bliver én
person i OS2sofd med ét tilhørsforhold pr. ansættelse. Har kommunen flere
institutioner i SD, samles ansættelser på tværs af dem på samme person.

### Personen

| Oplysning i OS2sofd | Kilde i SD |
| --- | --- |
| CPR-nummer | Personens CPR-nummer. Bruges som nøgle |
| Fornavn og efternavn | Personens navn. Bruges kun, når personen oprettes. Derefter vedligeholdes navnet af OS2sofd, typisk ud fra CPR |
| Folkeregisteradresse | Personens adresse i SD. Sættes kun ved oprettelsen, og kun hvis kommunen har slået det til og adressen er komplet og ikke beskyttet |
| Første ansættelsesdato | Den tidligste startdato blandt personens ansættelser |
| Jubilæumsdato | Den tidligste jubilæumsdato blandt personens ansættelser |

Personer, der ikke har nogen ansættelse, der kan overføres, oprettes ikke. Personer,
der er inaktive i OS2sofd, oprettes og opdateres heller ikke, før SD leverer en
ansættelse, der ikke er ophørt. Ændringer til en inaktiv person går dermed tabt, og
antallet af sådanne personer logges ved hver kørsel.

### Tilhørsforholdet

Hver ansættelse bliver til et tilhørsforhold af typen ansat. SD registrerer alle
ændringer med virkningsdatoer, og integrationen vælger i hvert felt den oplysning, der
gælder i dag. Starter ansættelsen først i fremtiden, vælges den oplysning, der gælder
på startdatoen, og findes der kun fremtidige oplysninger, den der får virkning først.

| Oplysning i OS2sofd | Kilde i SD |
| --- | --- |
| Enhed | Afdelingen på ansættelsen, omsat til en enhed i OS2sofd efter den valgte model. I model 1 bruges den nærmeste overliggende afdeling, hvis afdelingen selv ikke er overført |
| Medarbejdernummer | Ansættelsesnummeret i SD. For ansættelser i andre institutioner end den primære sættes institutionens id foran |
| Startdato | Den tidligste dato, hvor ansættelsen har en aktiv status, dog ansættelsesdatoen i SD, hvis den ligger tidligere. Er personen på orlov med en planlagt tilbagevenden, bruges datoen for tilbagevenden |
| Stopdato | Slutdatoen på den seneste status, eller dagen før en ikke-aktiv status træder i kraft |
| Stillingsbetegnelse | Stillingens navn fra SD's stillingskatalog. Kommunen kan vælge, at det manuelt indtastede stillingsnavn på ansættelsen bruges i stedet, og bestemte stillingskoder kan oversættes til et aftalt navn. Mangler navnet, sættes det til "Ukendt" |
| Stillingstype | Stillingskoden og stillingens navn fra stillingskataloget |
| Ansættelsesvilkår | Udledt af aflønningsformen. `00` Månedsløn forud, `01` Månedsløn bagud, `03` Måneds-/timeløn. Værdierne svarer til dem, der bruges for OPUS |
| Løntrin | Lønklassen på ansættelsens overenskomst |
| Ugentlig arbejdstid | Beskæftigelsesgraden ganget med en aftalt normtid for fuld tid. Normtiden kan afvige for bestemte stillingskoder. Timelønnede får arbejdstiden 0 |
| Lokaludvidelse `SDDepartmentIdentifier` | Afdelingskoden i SD |
| Lokaludvidelse `SDDepartmentName` | Afdelingens navn i SD |

Følgende ansættelser overføres ikke, og et eventuelt tidligere overført tilhørsforhold
fjernes igen.

- Ansættelser uden afdeling eller uden startdato, eller hvor stopdatoen ligger før
  eller på startdatoen.
- Ansættelser med status slettet i SD.
- Ansættelser, hvis afdeling ikke kan omsættes til en enhed i OS2sofd.
- Ansættelser, hvis stillingsbetegnelse matcher et aftalt mønster. Bruges til at holde
  udbetalinger, der ikke er egentlige ansættelser (fx honorarer eller aflastning efter
  serviceloven), ude af OS2sofd. Hvad der udelades, opsummeres i loggen ved hver
  kørsel.

Forsvinder en ansættelse fra SD, fjernes tilhørsforholdet i OS2sofd. Forsvinder
personen helt fra SD, fjernes de af personens SD-tilhørsforhold, der ikke allerede er
ophørt. Tilhørsforhold fra andre kilder røres ikke.

SD kan genbruge et ansættelsesnummer på en anden person, når den oprindelige ansættelse
er slettet. Integrationen sørger for, at ansættelsesnummeret kun er i brug på én person
i OS2sofd ad gangen, og retter det selv, hvis ændringerne fra SD er kommet i en uheldig
rækkefølge.

## Ledere

Kommunerne registrerer deres ledere forskelligt i SD, så integrationen understøtter
fire metoder. Kommunen vælger én af dem, og integrationen sættes op efter den.

- **Leder på afdelingen.** SD har ikke et lederfelt på afdelinger, så lederens
  femcifrede ansættelsesnummer registreres i afdelingens telefonnummerfelt. Metoden
  bruges også til at afgøre, hvilke afdelinger der kommer med i model 1, og kan
  udpege ledere fra andre institutioner end den primære via mapningen af enheder.
- **Lederkode på ansættelsen.** Ansættelser med lederkoden `L` i SD gør personen til
  leder af ansættelsens enhed.
- **Stillingskode.** En aftalt liste over stillingskoder, der betyder leder. Står en
  gruppe fra SD's stillingskatalog på listen, dækker den alle stillinger under gruppen.
- **SD's funktionshierarki.** Lederen hentes fra en aftalt lederfunktion i SD's
  funktionshierarki.

Kun personer med et aktivt tilhørsforhold kan blive sat som leder, og en enhed får
højst én leder fra SD. Lederne sendes til OS2sofd som ledere fra kildesystemet. Har
enheden en manuelt valgt leder i OS2sofd, fastholdes den, og der dannes adviset
[Enhed har fået ny leder fra kildesystemet](../../brugervejledning/adviser/#enhed-har-fået-ny-leder-fra-kildesystemet).

## Adviser

Integrationen danner adviset
[Lønenhed der ikke findes i SOFD](../../brugervejledning/adviser/#lønenhed-der-ikke-findes-i-sofd),
når der er ansatte i en SD-afdeling, som ikke kan omsættes til en enhed i OS2sofd.
Adviset nævner afdelingens navn og afdelingskode. De ansatte i afdelingen kommer ikke
over i OS2sofd, før opmærkningen eller mapningen er rettet. Dannelsen af adviser kan
slås fra.

## Hvad kan tilpasses

| Mulighed | Formål |
| --- | --- |
| Model for enhederne | SD som master, OS2sofd som master, eller mapning via tags |
| Institutioner i SD | Hvilke institutioner der læses fra, og hvilken der er den primære |
| Mapning af afdelinger | For institutioner ud over den primære, hvilke SD-afdelinger der svarer til hvilke enheder i OS2sofd |
| Udvælgelse af afdelinger (model 1) | Alle afdelinger eller kun ledelsesstrukturen, lister over afdelinger der altid eller aldrig skal med, navnemønster for udeladte afdelinger, og sammenlægning af afdelinger med samme navn som deres overliggende |
| Øverste enhed (model 1) | En afdeling i SD eller en eksisterende enhed i OS2sofd |
| P-nummer på enheder (model 1) | Kan slås til og fra |
| Enhedskoder (model 2) | Om kommunen selv angiver enhedskoderne i tag-værdien |
| Skyggeafdelinger (model 2) | Om der oprettes en afdeling under hver NY-enhed |
| Virkningsdato (model 2) | Den 1. i måneden eller 1. januar |
| Nedlagte enheder (model 2) | Flyt til en fast enhed i SD eller omdøb efter et mønster |
| Prøvetilstand (model 2) | Beskeder til SD dannes uden at blive sendt |
| Tag til mapning (model 3) | Navnet på det tag, der bærer SD-afdelingskoderne |
| Normtid | Timer pr. uge for fuld tid, eventuelt pr. stillingskode |
| Stillingsbetegnelser | Om manuelt indtastede stillingsnavne i SD bruges, og faste navne for bestemte stillingskoder |
| Udeladte ansættelser | Mønster for stillingsbetegnelser, der ikke skal overføres |
| Ledere | Hvilken af de fire metoder der bruges, listen over lederstillingskoder og navnet på lederfunktionen |
| Folkeregisteradresse | Om adressen fra SD sættes på nye personer |
| Adviser | Kan slås til og fra |
| Tolerance for fejl hos SD | Hvor længe fejl hos SD logges som advarsler, før de logges som fejl |

## Forudsætninger

- **En systembruger i SD** med adgang til de webservices, der læser afdelinger,
  organisation, institution, personer, ansættelser og stillingskatalog. Se
  [Drejebog: SD-kommune](../../implementation-guides/sd-loen-integration/) for den
  præcise liste. Skal ledere udledes af funktionshierarkiet, skal brugeren også have
  adgang til funktionerne.
- **Adgang til SD's MOX-snitflade** med certifikat, hvis OS2sofd skal være master for
  enhederne (model 2). Aftales med SD.
- **Tags i OS2sofd.** Tagget `SD` i model 2 og det aftalte mapningstag i model 3 skal
  være oprettet under administration, og enhederne skal være opmærket.
- **API-adgang til OS2sofd.**

## Ændringslog

Ændringslog for SD Løn integrationen. Nyeste ændring øverst.

| Dato | Ændring |
| --- | --- |
| <span class="nowrap">29.09.2026</span> | • ansættelser kan udelades ud fra et mønster i stillingsbetegnelsen, fx honorarer og aflastning. Tidligere overførte tilhørsforhold fjernes igen, og hvad der udelades, opsummeres i loggen |
| <span class="nowrap">03.09.2026</span> | • enheder beriges med afdelingens id i SD i lokaludvidelsen `SDDepartmentUUIDIdentifier` |
| <span class="nowrap">26.08.2026</span> | • kørslen afbrydes ikke længere, når SD ikke kender navnet på et CPR-nummer i en institution |
| <span class="nowrap">21.08.2026</span> | • er samme SD-afdeling tagget på flere enheder, vælges den samme enhed ved hver kørsel, så tilhørsforhold ikke flytter frem og tilbage. Der logges en advarsel |
| <span class="nowrap">18.08.2026</span> | • personer, der er inaktive i OS2sofd, forsøges ikke længere oprettet eller opdateret, og antallet logges<br>• P-nummeret i OS2sofd røres ikke, når SD ikke har et, så enheden ikke opdateres ved hver kørsel |
| <span class="nowrap">14.08.2026</span> | • ledere kan udledes af stillingskoder, herunder hele grupper i SD's stillingskatalog |
| <span class="nowrap">15.07.2026</span> | • navne hentes efterfølgende for personer, der først er set gennem en ansættelsesændring uden navn, så de ikke afvises af OS2sofd |
| <span class="nowrap">09.07.2026</span> | • genbrugte ansættelsesnumre afgøres nu ud fra ansættelsernes status, så tilhørsforholdet ender hos den rigtige person uanset rækkefølgen af ændringer fra SD |
| <span class="nowrap">09.06.2026</span> | • et helt nyt undertræ af afdelinger oprettes i OS2sofd i én kørsel i stedet for ét niveau pr. kørsel<br>• tydelig fejl, når den opsatte øverste afdeling ikke findes i SD |
| <span class="nowrap">02.06.2026</span> | • ugyldige tegn i svar fra SD fjernes, så de ikke vælter indlæsningen<br>• ansættelser, hvis nummer er genbrugt af en anden person, gemmes i stedet for at blive slettet |
| <span class="nowrap">16.04.2026</span> | • enheder opdateres kun i de felter, integrationen ejer, og P-nummer uden værdi håndteres korrekt |
| <span class="nowrap">10.04.2026</span> | • berigelse af enheder også i model 2, hvor afdelingskode, niveau og id i SD skrives på enheden |
| <span class="nowrap">26.02.2026</span> | • berigelsen kan sætte enhedens postadresse fra SD |
| <span class="nowrap">23.02.2026</span> | • berigelsen sætter P-nummer på enheden |
| <span class="nowrap">13.01.2026</span> | • ny berigelse af enheder i model 3 med lokaludvidelsen `Leder i SD`<br>• enhedsnavne afkortes til 52 tegn ved overførsel til SD |
| <span class="nowrap">28.10.2025</span> | • nedlagte enheder kan omdøbes i SD i stedet for at blive flyttet |
| <span class="nowrap">19.10.2025</span> | • fejl hos SD logges som advarsler inden for en aftalt periode efter det seneste vellykkede kald, og først derefter som fejl |
| <span class="nowrap">06.10.2025</span> | • vedligehold af P-nummer på enheder i OS2sofd kan slås til og fra |
| <span class="nowrap">11.09.2025</span> | • sikring mod forkerte eller flere øverste enheder i OS2sofd<br>• rettet P-nummer og brugen af en OS2sofd-enhed som øverste enhed |
| <span class="nowrap">26.08.2025</span> | • forbedret valg af fremtidige ansættelsesoplysninger og beregning af startdato |
| <span class="nowrap">20.08.2025</span> | • stillingstype (kode og navn) sættes på tilhørsforholdet |
| <span class="nowrap">15.08.2025</span> | • afdelinger, der kommer igen i SD, genaktiveres i OS2sofd |
| <span class="nowrap">04.07.2025</span> | • P-nummer hentes fra SD og sættes på enheder<br>• manuelt indtastede stillingsnavne i SD kan fravælges til fordel for stillingskataloget |
| <span class="nowrap">10.06.2025</span> | • ledere kan udledes af SD's funktionshierarki |
| <span class="nowrap">30.05.2025</span> | • ledere kan udledes af lederkoden `L` på ansættelsen |
| <span class="nowrap">28.04.2025</span> | • afdelingens niveau i SD gemmes på enheden i lokaludvidelsen `SDDepartmentLevelIdentifier` |
| <span class="nowrap">25.04.2025</span> | • tilhørsforhold kan placeres ud fra enhedens kobling til SD i stedet for enhedens id |
| <span class="nowrap">24.04.2025</span> | • opslag i stillingskataloget kan slås fra |
| <span class="nowrap">23.04.2025</span> | • afdelinger med samme navn som deres overliggende afdeling kan slås sammen |
| <span class="nowrap">13.03.2025</span> | • stillingsbetegnelsen "Empty" fra SD behandles som manglende og bliver til "Ukendt" |
| <span class="nowrap">28.01.2025</span> | • afdelingskode og afdelingsnavn fra SD gemmes som lokaludvidelser på tilhørsforholdet |
| <span class="nowrap">17.01.2025</span> | • stopdatoen tager højde for orlov, og startdatoen bruger ansættelsesdatoen i SD, hvis den ligger tidligere |
| <span class="nowrap">10.01.2025</span> | • landekode på adresser overføres korrekt, og rettelser efter test hos den første kommune |
| <span class="nowrap">20.12.2024</span> | • ny udgave af integrationen, der erstatter den tidligere. Indlæser afdelinger og ansættelser fra SD, overfører enheder til SD via MOX og sætter ledere fra SD |