SD Løn

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 for begreberne person, tilhørsforhold og enhed.

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

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

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.

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.

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.

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.

Æ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.

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#

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.

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.

Adviser#

Integrationen danner adviset 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#

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 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.