Brugervejledning

Indledning#

SOFD Core er en organisationsløsning, der har et bredt anvendelsesområde. Denne brugermanual vil afdække de mest almindelige brugsscenarier, med udgangspunkt i brugergrænsefladen. SOFD Core løsningen finder typisk anvendelse indenfor

  • Dataaggregering. Opsamling af organisatoriske stamdata fra alle de autoritative kilder i kommunen (AD, Exchange, Løn, STIL/skole, osv)
  • Databesigtigelse- og berigelse. Prioriteret fletning af data fra alle datakilderne, med mulighed for berigtigelse og berigelse af data fra SOFDs brugergrænseflade
  • Datadistribution. Videregivelse af data fra SOFD til modtagersystemer, samt udstillelse af samme data via API
  • Organisationsstyring. Oprettelse og vedligeholde af organisatoriske stamdata, herunder enhedshierarki, organisatoriske tilhørsforhold, klassifikationer og navnestandarder.
  • Kommunikation. Anvendelse af organisatoriske stamdata til målrettet kommunikation, samt advisering om relevante organisatoriske hændelser
  • Identity Management (IdM). Automatisering af brugeroprettelse og brugernedlæggelse på tværs af forskellige systemer (AD, Exchange, CICS, LOS, osv)

I nedenstående brugermanual tages der udgangspunkt i fællesmængden af funktionalitet i SOFD. Hver anvenderkommuner har sin egen installation, med en tilpasset opsætning. Det betyder at skærmbillederne der vises er vejledende, men ikke nødvendigvis er identiske med den opsætning den enkelte kommuner kører med.

Der vil også blive beskrevet funktionalitet som ikke nødvendigvis er tilgængelig i alle anvenderkommunerne.

Organisation#

Dette område af SOFD tilgås ved at klikke på ”Organisation” i top-menuen. Her kan man se og vedligeholde de organisatoriske stamdata der er indlæst i SOFD Core.

Enheder#

Ved at klikke på ”Enheder” i venstremenuen, kan man tilgå et overblik over ens organisationshierarki som illustreret nedenfor

Hvis man har opsat flere organisationer i sin SOFD installation, kan man skifte mellem dem. Det mest almindelige er dog at man kun har én organisation.

Hvis man gør brug af TAG systemet (se mere nedenfor), så kan man bruge de opsatte TAGs til at filtrere det organisations-træ der vises nedenunder.

Ellers kan man enten navigere rundt i organisationsstrukturen, eller anvende søgefeltet til at finde en specifik enhed.

Detaljer for den enhed man markerer i træet, vises i højre side. Her kan man trykke på knappen ”Vis” for at navigere til detaljesiden for enheden, som er illustreret nedenfor

På en enhed vises en række stamdata, hvor enkelte af disse kan redigeres ved at trykke på ”Rediger” knappen. Hvilke felter der kan redigeres afhænger af opsætningen på SOFD, samt hvilken kilde som enheden kommer fra.

Under stamdata på enheden, vises en række faner, hvor man kan tilgå yderligere oplysninger om enheden, samt vedligeholde diverse oplysninger. Afhængigt af opsætningen af SOFD er der nogle af fanerne som ikke vil blive vist.

Her følger et kort overblik over nogle af fanerne (andre faner beskrevet i eget afsnit nedenfor)

  • Medarbejdere. Her kan man se et overblik over alle medarbejdere i enheden. Det er også muligt at knytte ekstra medarbejdere til enheden (ud over de tilhørsforhold som automatisk indlæses fra lønsystemet), samt downloade et excel ark over alle medarbejdere i enheden.
  • Adresser. Her kan man se og vedligeholde enhedens postadresse(r). Ud over at kunne vedligeholde adresserne direkte i SOFD, kan de også indlæses fra LOS, samt fra CVR registeret via det registrerede p-nummer på enheden.
  • Telefoni. Her kan man se og vedligeholde enhedens telefonnumre. Ud over at kunne vedligeholde telefonnumrene direkte i SOFD, kan de også indlæses fra LOS, samt fra SOFDs telefoni-modul.
  • Kontakt. Her kan man se og vedligeholde enhedens åbningstider, samt angive søgeord og noter på enheden. Åbningstiderne overføres til FK Organisation.

Opsætning af IdM bestillingsregler#

Hvis man anvender SOFD til IdM styring, vises fanen ”Bestillingsregler” på en enhed. Her kan man opsætte regler for automatisk oprettelse af diverse brugerkonti, for medarbejdere der tilknyttes denne enhed.

Bemærk at der kun kan opsættes bestillingsregler for de brugerkonti som er indeholdt i IdM opsætningen. Her henvises til afsnit 4.7.1 for ydereligere detaljer.

I ovenstående skærmbillede vises et eksempel hvor der er 4 brugerkontotyper der er styret af IdM processerne i SOFD. For hver af disse kan man opsætte regler for oprettelse samt deaktivering/sletning af konti.

Hvis man trykker på knappen ”Rediger”, kan man vælge regler for hver kontotype.

”Kræver godkendelse”-kolonnen bliver kun vist for de kommuner der har aktiveret den feature i OS2sofd hvor kontooprettelser skal godkendes af leder før de udføres. Når man anvender den feature vil alle Active Directory kontooprettelser som default blive sendt til godkendelse, medmindre man fjerner fluebenet i ”Kræver godkendelse”, så vil de blive sendt til direkte oprettelse uden godkendelse.

I ”Regel for kontooprettelse” kan man vælge mellem:

  • Mangler opmærkning. Dette er værdien der er sat før man har opsat nogle regler. Denne værdi fungerer i praksis identisk med ”Ingen automatisk bestilling”.
  • Ingen automatisk bestilling. Denne værdi vælges hvis man ikke ønsker en automatisk oprettelse af brugerkonti.
  • Automatisk bestilling til alle. Denne værdi vælges hvis alle der er tilknyttet enheden automatisk skal have en sådan brugerkonto.
  • Automatisk bestilling til alle på nær timelønnede. Denne værdi vælges hvis alle, på nær dem som lønsystemet angiver som værende timelønnede, skal have en sådan konto.
  • Styret via stillingsnavn. Denne værdi vælges hvis man ikke kan opsætte én generel regel for alle medarbejdere i enheden. Når man vælger denne, så viser SOFD en liste over alle stillinger i enheden, og så kan man konfigurere dem individuelt. Bemærk at denne indstilling er mere administrativ tung, og det anbefales at anvende en af de andre valgmuligheder hvis muligt.
  • Styret via stillingsnavn. Denne værdi vælges hvis man ikke kan opsætte én generel regel for alle medarbejdere i enheden. Når man vælger denne, så viser SOFD en liste over alle stillinger i enheden, og så kan man konfigurere dem individuelt. Bemærk at

I ”Regel for deaktivering og sletning” kan man vælge mellem:

  • Behold konti aktiv. Dette er standardopførslen. Så længe en medarbejder har et aktivt tilhørsforhold i en enhed hvor denne regel er valgt, vil OS2sofd ikke automatisk deaktivere konti.
  • Deaktivér og slet konti. Denne værdi betyder at tilhørsforhold i denne enhed ikke er årsag nok til at holde en konto aktiv. Dvs. Hvis en medarbejder alene har aktive tilhørsforhold tilbage i enheder opmærket med denne regel, så vil OS2sofd bestille deaktivering og sletning af konti.
  • Deaktivér og slet konti for timelønnede, ellers behold aktiv. Denne værdi er en kombination af de 2 ovenstående værdier, hvor timelønnede tilhørsforhold i denne enhed ikke er årsag nok til at holde en konto aktiv, men andre ansættelsesforhold fortsat holder kontoen aktiv.

Det er også muligt at kopiere reglerne fra denne enhed til andre enheder. Dette gør det nemt og hurtigt at opsætte nogle standardregler, som skal gælde for det meste af organisationen.

Når man opdaterer bestillingsreglerne for en enhed, sætter SOFD automatisk gang i evt ny-oprettelse som skal ske på baggrund af ændringerne. Her vil man typisk få en informationsbesked om hvor mange nye konti der vil blive bestilt som følge af de ændringer man angiver, og man har mulighed for at afbryde hvis det ser forkert ud.

Bestillingsreglerne vil efterfølgende effektueres dagligt, så ændringer i organisationen (fx nyansættelser) vil resultere i nyoprettelser af brugerkonti.

Opmærkning med Tags#

TAGs er en form for klistermærke man kan sætte på enheder. De anvendes i diverse integrationer. Det anbefales at man anvender TAG systemet i samspil med en dialog med Digital Identity, så man sikrer at integrationen og TAGsene hænger sammen.

Et TAG består typisk af et navn (hvad anvendes dette TAG til) samt en værdi (optionelt, men nogle integrationer har brug for en konkret værditildeling på et TAG).

Ovenstående eksempel viser en enhed som er opmærket med TAG’et ”O365 Licens”, hvor værdien ”E3” er angivet. Her har kommunen en lokal integration kørende, som vedligeholder licenser på baggrund af TAG opmærkningen. Man kan bruge TAG systemet til en lang række integrationer, hvor man kan bruge en opmærkning på enhederne til at styre hvad integrationen skal gøre.

Listen at tilgængelige TAGs vedligeholdes under administration, som beskrevet i afsnit 4.7.4.

Opmærkning med KLE#

Enheder kan opmærkes med KLE. Her er KLE opmærkningen inddelt i 3 områder, som illustreret nedenfor.

  • Opgaveansvar. Her angives hvilke arbejdsopgaver som der varetages i denne organisatoriske enhed. Man kan vælge at disse data overføres til andre systemer, fx OS2rollekatalog.
  • Indsigtsbehov. Her angives hvilke opgaveområder som medarbejdere i enheden har brug for at få adgang til. Man kan vælge at disse data overføres til andre systemer, fx OS2rollekatalog.
  • FK Organisation. Her angives den KLE opmærkning som ønskes overført til FK Organisation. Denne fane er reserveret alene til FK Organisation, og anvendes ikke i andre sammenhænge.

Personer#

Ved at klikke på ”Personer” i venstremenuen, kan man tilgå et overblik over alle personer tilknyttet ens organisation som illustreret nedenfor

Tabellen lister alle personer der matcher de søge-kriterier der er indtastet i søgefeltet, eller blot alle personer registreret i SOFD.

Som udgangspunkt vises kun aktive personer, men kan skifte til at vise de inaktive personer (typisk medarbejdere der ikke længere er ansat i kommunen). SOFD gemmer historiske oplysninger på tidligere medarbejdere i en periode efter de er stoppet. Under administration kan man opsætte denne opbevaringsperiode.

Ud for den enkelte medarbejders navn kan der fremkomme ”klistermærker”, der angiver hvis der er opsat noget specielt på medarbejderen. Det kan være at medarbejderne er stoppet (men stadig har en aktiv ansættelse, fx i forbindelse med en fritstilling), eller at medarbejderen er på pause (fx orlov).

Ved at klikke på ”luppen” ud for en person, går man til detalje-billedet for den valgte person. Dette skærmbillede er illustreret nedenfor.

På detaljeskærmbilledet er der en række stamdata på personen, som vises øverst. Disse kommer typisk fra lønsystemet, men bl.a. fornavn og efternavn holdes automatisk ajour på baggrund af udtræk fra CPR registeret.

Nederst er en række faner, hvor man kan tilgå yderligere oplysninger om personen, herunder

  • Tilhørsforhold. Her kan se et overblik over alle de tilhørsforhold som personen har til organisationen. Klik på knappen med tandhjulet for at tilvælge/skjule kolonner i oversigten. Man kan også administrere personens tilhør til kommunen, hvilket er beskrevet længere nede.
  • Brugerkonti. Her kan man få et overblik over alle de brugerkonti som medarbejderen er tildelt, samt potentielt administrere disse (oprette / spærre / låse op). Mulighederne for administration af brugerkonti afhænger af kommunens SOFD opsætning.
  • Telefoni. Her kan man få et overblik over de telefonnumre (fastnet, ip, mobil, osv) som en person har tilknyttet. Disse oplysninger er enten indlæst fra en ekstern kilde (fx AD eller SOFDs telefonimodul) eller vedligeholdt inde i dette skærmbillede.
  • Kontakt. Her kan man opsætte søgeord og noter på en person.

Afhængig af kommunens opsætning, vil nogle af disse faner være udeladt, og ikke alle faner kan bruges til at redigere data.

Hasteoprettelse#

På oversigten over alle personer i organisationen, er der en knap med teksten ”Hasteoprettelse” som illustreret nedenfor

Denne anvendes til at oprette en ny person, som ikke allerede findes i SOFD. Typisk vil personer blive indlæst fra en ekstern kilde (fx lønsystemet, AD eller lignende autoritativt kilderegister), men der kan være tilfælde hvor man har brug for at oprette en person udenom disse kilder, eller man blot ikke kan vente på at data kommer fra den autoritative kilde.

Hvis man klikker på knappen, kommer nedenstående web-formular frem, hvor man kan oprette personen, og tilknytte denne til en enhed i organisationen.

Hvis man vælger at der er tale om et ”eksternt tilhørsforhold”, kommer der yderligere valg frem i web-formularen (leverandør, intern reference og mulighed for at angive hvorvidt personen skal nedarve rettigheder fra den enhed de indplaceres i).

Man kan lave et kontrolopslag på personens CPR nummer, hvor der hentes data direkte fra CPR registeret, der tilføjes til web-formularen. Hvis personen ikke har et CPR nummer, så kan man i stedet angive et fiktivt CPR nummer. Her findes en regel man kan bruge, hvor man tilføjer 6 til det første ciffer på fødselsdagen – fx hvis man har en person der har fødselsdag 21.maj 1979 (eller en robot man tænker skal have fødselsdag den dag 😉), så lægger man 6 til 2-tallet, og får

810579

Som de første 6 cifre i CPR nummeret. De sidste 4 kan så bare være et tilfældigt tal, så man fx kunne ende med følgende som et fiktivt CPR nummer

8105791234

Adresse-oplysninger er ikke obligatoriske og kan udelades, men man kan overveje at indtaste leverandørens adresse hvis der er tale om en ekstern person (fx en konsulent, leverandør eller anden 3.part).

Bemærk at slutdato er obligatorisk for eksterne tilhørsforhold.

Oprettelse af tilhørsforhold#

På samme måde som man kan haste-oprette en person, kan man også oprette et tilhørsforhold på en eksisterende person. Hvis man fremsøger en person som beskrevet tidligere, så fremgår personens nuværende tilhørsforhold på fanen ”Tilhørsforhold” under stamdata-sektionen.

Her er knappen ”Opret tilhørsforhold”, der kan anvendes til at tilføje et nyt tilhørsforhold til en eksisterende person. Dette kan fx give mening for personer der IKKE har et tilhørsforhold i forvejen (en forudsætning for at blive overført til OS2rollekatalog er at man har et tilhørsforhold), eller til at indplacere en eksisterende medarbejder i en ekstra enhed, fx i forbindelse med udlån.

Som ved hasteoprettelse af personer, kan man vælge om tilhørsforholdet til organisationen er for en egentlig medarbejder, eller for en ekstern part (konsulent, leverandør eller lignende).

Hvis man vælger ”ekstern”, kan man også angive ”leverandør” og ”intern reference”, og slutdatoen bliver obligatorisk.

Alle tilhørsforhold oprettet via brugergrænsefladen i SOFD kan redigeres og slettes via oversigten over tilhørsforhold på en person.

Angivelse af pause#

Hvis en person i en periode skal være væk fra kommunen, så kan man sætte personen på pause. Denne pause-markering går på tværs af alle personens tilhørsforhold til kommunen, og administreres inde i SOFDs brugergrænseflade.

På oversigten over tilhørsforhold for en person, findes knappen ”Sæt pausemarkering”

Hvis man klikker på knappen, så åbnes nedenstående skærmbillede, hvor man kan opsætte detaljerne for pausen

Hvis personen allerede er på pause, og man ønsker at fjern pause-markeringen, så trykker man blot på knappen (som nu hedder ”Fjern/rediger pausemarkering”), og så vises det samme skærmbillede, hvor man kan fjerne fluebenet ved ”På pause” og trykke ”Gem”.

I selve skærmbilledet er der følgende punkter man skal forholde sig til

  • Startdato. Her angiver man start-tidspunktet for pause-markeringen. Feltet er obligatorisk.
  • Stopdato. Her angiver man stop-tidspunktet for pause-markeringen. Man kan undlade at udfylde det. Hvis man udfylder det, så fjerner SOFD automatisk pause-markeringen ved afslutningen af den angivne dato.
  • Årsag. Her angives typen af pause-markering (fx skole-ophold, orlov eller lignende)
  • Uddybning. Her kan man angive yderligere detaljer som er relevante for administrationen (fx årsag til at deres konto ikke er låst under orlov’en eller hvad det nu måtte være).
  • Undtag for IdM processer. Hvis man sætter flueben i dette felt, så undtages personen for IdM processerne under hele pause-perioden. Funktionaliteten bag denne markering er angivet nedenfor.
  • Sæt udløb på AD konto. Hvis man sætter flueben i dette felt, så sættes udløb på personens tilknyttede AD konto/konti (med værdien fra start-dato), og dette udløb fjernes automatisk fra disse AD konti når pause-markeringen fjernes. Udløb på AD kontoen sikrer at medarbejderen ikke kan anvende den til login.

Undtagelse for IdM processer#

Hvis en person er undtaget for IdM processer, så betyder det, at der ikke automatisk oprettes, genaktiveres, deaktivers og/eller slettes brugerkonti (fx AD, Exchange, CICS, osv) for denne person.

Det kan være praktisk at sætte dette flag på en person hvis de i en periode ikke skal have it-adgange, men SOFDs bestillingsregler er opsat så de automatisk vil blive tildelt brugerkonti.

Bemærk at SOFD ikke lukker for eksisterende konti pga dette flag, men det blot er nye konti der ikke oprettes og/eller genaktiveres.

Flaget undtager personen for alle 3 typer undtagelser: oprettelse, deaktivering og sletning. Hvis man ønsker at nogle af undtagelserne ikke skal gælde, skal man efterfølgende redigere undtagelsesmarkeringerne på personen under ”brugerkonti”-fanen.

Flaget sættes typisk i forbindelse med pause-markeringen (se ovenfor), men kan også sættes direkte på personen på fanen ”Brugerkonti” som illustreret nedenfor (knappen ”Sæt undtagelsesmarkering”).

Bemærk at denne undtagelsesmarkering også kan sættes automatisk via en API integration. Enkelte kommuner har en automatiseret proces for lukning af brugerkonti der ikke har været anvendt i en given tidsperiode, og her sætter de typisk undtagelsesmarkeringen for at undgå at denne konto så reaktivere igen af SOFD.

STOP markering#

Der kan være tilfælde hvor man har brug for at stoppe en persons aktiviteter i organisationen øjeblikkeligt. Det kan være i forbindelse med en bortvisning eller lignende.

Her kan man inde fra detalje-skærmbilledet på en person, klikke på knappen ”Sæt STOP markering”, som illustreret nedenfor

Hvis man sætter en STOP markering på en person, så udføres følgende

  • Alle brugerkonti (som kan administreres af SOFD) spærres/lukkes øjeblikkeligt
  • Personen undtages for automatisk oprettelse/genaktivering af brugerkonti
  • I alle overførsler til eksterne systemer (fx OS2rollekatalog og FK Organisation) fremgår personen som værende ophørt

STOP markeringen fremgår samtidig tydeligt i alle skærmbilleder, hvor personen vises i brugergrænsefladen.

Når personens faktiske ansættelsesforhold ophører, så fjernes STOP markeringen efterfølgende, så personen blot fremgår som en normalt ophørt person.

STOP markeringen er tiltænkt markering af personer som skal fratages alle rettigheder, adgange og brugerkonti, samt skal fremgå i eksterne systemer som værende fratrådt kommunen.

Manuel bestilling af brugerkonti#

Hvis man gør brug af SOFDs IdM processer til automatisk oprettelse og nedlæggelse af brugerkonti, vil de fleste medarbejdere automatisk få de brugerkonti de har brug for. Det kan dog ske at man har en medarbejder som falder udenfor normen, og derfor har brug for yderligere brugerkonti end dem, som bestilles automatisk.

Disse brugere kan få tildelt ekstra brugerkonti, enten direkte i kildesystemet (fx direkte i AD’et), eller via SOFDs brugergrænseflade. Her kan man på listen over på brugerkonti for en given person, klikke på knappen ”Bestil it-brugerkonto”, vælge typen af brugerkonto som personen skal tildeles, og så få oprettet denne konto. På denne måde kan en person også tildeles flere af den samme type brugerkonto (fx flere AD konti).

Som illustreret ovenfor, kan man vælge mellem forskellige typer af brugerkonti. Hvilke der er tilgængelige afhænger af IdM opsætningen. Hvis både AD og Exchange er tilgængelige, kan man også vælge at oprette dem som et par af brugerkonti.

Skærmbilledet til oprettelse er forholdsvist simpelt, og det anbefales at man selv aktivt vælger brugernavnet til den valgte konto, hvis medarbejderen skal have konto nummer 2 af samme type (typisk anvendes en navnestandard der fungerer bedst med én konto per medarbejder).

Valg af primær konto#

Hvis en person har flere brugerkonti af den samme type, så er én af dem angivet som værende den primære. Da SOFD ikke har nogen beslutningsgrundlag til at vælge den primære konto intelligent, vælger den blot den første konto den ser som værende den primære.

Man kan ændre valget af den primære konto inde i SOFD. Her tilgår man personens detaljeside, og går til fanen ”Brugerkonti”. Her kan man trykke på knappen ”Vælg primær konto”, og så angive hvilken konto der skal være den primære for hver kontotype, som illustreret nedenfor

Når SOFD overfører data til andre systemer, og modtager systemet kun understøtter én brugerkonto/kontonavn, så vælges altid den primære.

For AD konti gælder det, at det er den primære AD konto, hvorfra kaldenavnet (displayName) udlæses. Så hvis en person har flere AD konti, kan man med fordel angive den primære, så man sikrer at kaldenavnet på den person indlæses korrekt.

Download af historik#

Der findes en simpel historik funktion i SOFD, hvor man kan udlæse et råt data-dump af en persons tilstand på tidligere tidspunkter. Ved at klikke på knappen ”Historik” øverst på detalje-siden for en person, får man præsenteret en liste af datoer og tidspunkter, hvor der er historiske data på den valgte person.

Ud for hver af disse kan man downloade historikken i et JSON filformat. Dette er i praksis kun anvendeligt for en tekniker, men kan bl.a. bruges til at lave opslag på gamle data på en person til fejlsøgningsformål.

Hvis man åbner en sådan fil med et tekstredigeringsværktøj som notepad++ eller lignende, vil man blive præsenteret for data på nedenstående form

Arbejdssteder#

Arbejdssteder er en feature der kan slåes til i OS2sofd, men som default er slået fra. Kontakt driftsleverandøren hvis i ønsker at slå denne feature til.

For nogle typer ansættelser i lønsystemet stemmer den registrerede afdeling ikke overens med den afdeling som medarbejderen rent faktisk arbejder i.

Et typisk scenarie er elev-ansættelser, hvor en elev typisk ansættes i lønsystemet i en overordnet enhed til elever, men under elevforløbet arbejder eleven i forskellige afdelinger uden at der foretages ændringer på ansættelsen i lønsystemet.

Arbejdssteder featuren giver mulighed for at specificere hvor eleven arbejder i en given periode under sit elevforløb. Denne oplysning om arbejdssted vil så anvendes som arbejdssted for tilhørsforholdet når der synkroniseres data fra OS2sofd til eksterne systemer (FK Organisation, OS2rollekatalog, AD m.fl.).

Bemærk at det ikke er muligt at lave datooverlap i angivelsen af arbejdssteder.

Rapporter og adviser#

Hvis man tilgår ”Rapporter og adviser” i top-menuen, får man adgang til de forskellige rapporteringsfunktioner i SOFD. I top-menuen vises også et lille badge med et tal i, hvor man kan se hvor mange ubehandlede advis’er man har liggende

Rapporter#

SOFD har en række standardrapporter man kan trække. Disse rapporter er individuelt opbygget, og der vil over tid blive tilføjet flere rapporter til denne liste, typisk drevet af konkrete behov.

Rapporterne tilgås ved at klikke på ”Rapporter” i venstre-menuen, hvor man præsenteres for følgende liste

Man kan tilgå den enkelte rapport ved at klikke på luppen ud for rapportens navn. Det kan tage lidt tid at danne rapporten, så det er vigtigt man er tålmodig her.

Når først en rapport er dannet, så husker SOFD på den i op til en time, så man hurtigt kan tilgå den igen senere, fx hvis man bevæger sig rundt mellem forskellige sider inde i SOFD (nogle rapporter har fx links til de personer som indgår i rapporten).

Når man tilgår en rapport (ved at klikke på luppen), så får man præsenteret en beskrivelse af rapporten (de kriterier der gør sig gældende for data), de personer der opfylder kriterierne, samt muligheden for at downloade resultatet i Excel format.

Der vises et eksempel på en sådan rapport nedenfor.

Adviser#

Man kan tilgå ”indbakken” for advis’er ved at klikke på menupunktet ”Adviser” i venstre-menuen. Advis’er dannes løbende af SOFD, og er typisk baseret på en eller flere relevante hændelser, som typisk er opstået, da noget er fejlet eller ”automatikken” ikke kan tage hånd om det uden menneskelig indblanding.

Et advis består af en hændelsestype, et tidspunkt og et ”subjekt” som hændelsen vedrører. Der kan være yderligere detaljer knyttet til et advis, som kan tilgås ved at klikke på luppen ud for advis’et.

Det er vigtigt her at huske, at advis-listen blot er en indbakke. Det underliggende problem der har skabt advis’et kan godt være løst, men advis’et vil forblive i indbakken til det fjernes (tryk på krydset).

Man kan tildele en administrator til løsning af ”opgaven” ved at klikke på ikonet af ”manden” i hver række. Dette kan fx give mening hvis man skal have undersøgt noget inden man kan lukke advis’et, men man gerne vil indikere overfor sine kollegaer, at man er ved at kigge på det, og de kan se bort fra advis’et her og nu.

Hvis man klikker på luppen, så får man et detaljebillede, som illustreret nedenfor. Indholdet af detaljebilledet er typisk er mere detaljeret forklaring på den hændelse der har skabt advis’et.

Ordrestatus#

Hvis man anvender IdM processerne i SOFD, så kan man tilgå menupunktet ”Ordre status” i venstremenuen. Denne leder brugeren til en liste over alle kontohandlinger (oprettelser, genaktiveringer, spærringer, sletninger, osv) som enten er planlagte til at blive afviklet i fremtiden, eller som er blevet afviklet indenfor de sidste 14 dage.

Hvis en ordre er fejlet, vil dette fremgå af kolonnen ”Status”. Typisk vil man også få et advis på dette, medmindre man har slået den type advis’er fra.

På fejlede ordre kan det give god mening at klikke på luppen, da man her kan se yderligere detaljer om, hvorfor oprettelsen er fejlet. Typisk vil det dog være modtagersystemet der har afvist oprettelsen, og indholdet af fejlbeskeden kan derfor være en smule teknisk, da SOFD blot viderebringer den fejlbesked som systemet (fx AD, OPUS, CICS eller lignende) har givet.

Hvis en ordre er fejlet, har man mulighed for at genkøre den inde fra detaljesiden. Hvis fejlen skyldes et problem med det ønskede brugernavn, kan man med fordel redigere dette (feltet til ønsket brugernavn er redigerbart), inden man afvikler ordren igen.

Administration#

Hvis man har administrator-rollen i SOFD, er det også muligt at tilgå menupunktet ”Administration” i top-menuen. Venstre-menuen vil her blive udfyldt med alle de funktioner som kan administreres i den konkrete SOFD installation. Det vil være forskelligt fra kommune til kommune, hvilke menupunkter der er tilgængelige, da ikke alle kører de samme integrationer. Nedenfor er beskrevet de mest almindelige menupunkter/funktioner.

Opsætning af filtre på indlæsning fra OPUS#

Hvis man indlæser data fra OPUS, så vil der være adgang til et punkt i venstre-menuen der hedder ”Indlæsningsfiltre”. Disse filtre angiver hvilke data fra OPUS som IKKE bliver læst ind i SOFD.

Typisk vil man her har opsat Å-historik, økonomiske/tekniske enheder, og måske stillingskoder som ikke er relevante (efterindtægt og lignende).

De muligheder der findes er

  • LOS enheder der filtreres bort. Her er angivet en explicit liste af enheder som filtreres bort. Der anvendes LOS ID’et på enhederne.
  • OPUS stillinger der filtreres bort. Her er angivet en explicit liste af stillingskoder som filtreres bort. Der anvendes ID’et fra OPUS på stillingerne.
  • Navnefilter på LOS enheder. Her er angivet et tekstfilter på LOS enheder. Alle enheder som indeholder den angivne tekststreng (fx ”STOP”) vil blive filtreret bort
  • Tjenestemandspensioner. Hvis tjenestemandspensioner filtreres bort, så angives det her
  • Efterindtægt. Hvis efterindtægt filtreres bort, så angives det her (alle stillinger med ordet ”efterindtægt” i sig)

Man kan ikke selv redigere i disse filtre, da de ikke håndteres af SOFD. De er opsat teknisk i integrationen til OPUS, der afvikles som en agent udenfor SOFD. Listen af blot en dokumentation af hvordan denne integration er opsat. Tag fat i Digital Identity for at få tilpasset konfigurationen (og dokumentationen).

Opsætning af stedfortræderkontekster#

I venstremenuen findes punktet ”Stedfortræderkontekster”. Dette er en klassifikation, og der findes 2 indbyggede klasser i denne klassifikation. Man kan tilføje yderligere via brugergrænsefladen.

En stedfortræderkontekst beskriver delegeringen af en opgaveudførsel fra en leder til en betroet medarbejder. Værdisættet for en sådan delegering består af

  • Et navn (en beskrivelse af konteksten).
  • Et tekniske ID (bruges til systemmæssige integrationer)
  • En angivelse af hvorvidt integrationen kan afgrænses organisatorisk

Man kan oprette alle de kontekster man ønsker, men de har ikke nogen funktionel effekt, medmindre der udvikles en modsvarende integration, der gør brug af disse kontekster.

De to kontekster som SOFD er født med er følgende

  • Global. Denne kontekst skal ses som en ”stedfortræder for alt” kontekst, og kan anvendes der, hvor en leder bare udpeger en betroet medarbejder til at agerer som stedfortræder i alle sammenhænge.
  • SOFD Core. Denne kontekst anvendes internt i SOFD, og gør det muligt for en stedfortræder at være modtager for adviseringer fra SOFD (fx email skabeloner), som normalt vil blive sendt til lederen.

Når en kontekst er oprettet, kan den tildeles. Hvis man tilgår detalje-billedet for en person, og denne person er leder, så vil der være en ekstra fane under stamdata, hvor man kan vælge stedfortrædere for denne leder

Ved at klikke på ”Tilføj stedfortræder” kan man angive en kontekst, en stedfortræder og evt en afgrænsning til en konkret enhed (som lederen er leder for)

Bemærk igen at dette kun har en reel funktion hvis der er lavet en integration som gør brug af denne stedfortræderopmærkning. SOFD har et stedfortræderbegreb indbygget som vil have en effekt, men andre stedfortræderkontekster skal der udvikles funktionalitet til, hvis en sådan ønskes.

Opsætning af klienter og API adgange#

SOFD udstiller et API hvor man kan hhv. indlæse/administrere stamdata, samt et API hvor man kan udlæse data. Dette API er der rettighedsstyring på, som administreres inde fra SOFDs brugergrænseflade. En Administrator kan tilgå ”Administration” i top-menuen, og derefter ”List klienter” for at få et overblik over alle aktuelle klienter, som illustreret nedenfor

Hvis man ønsker at oprette yderligere klienter, så kan det gøres ved at klikke på ”Opret klient” i venstre-menuen. Det skærmbillede der kommer frem er det samme som vises hvis man redigerer en eksisterende klient, og funktionaliteten er tilsvarende.

En klient er tildelt en rolle, og afhængig af den valgte rolle, vil skærmbilledet udvide sig med yderligere valgmuligheder. Hvis man tildeler en Læseadgang eller en Skriveadgang, så ser skærmbilledet ud som vist nedenfor

Her skal man alene forholde sig til navnet på klienten, samt den API nøgle som klienten skal bruge til at kalde API’erne. Navnet anvendes primært til visning i skærmbilleder og logs, og det anbefales at vælge et nogenlunde forståeligt navn til sine klienter, så det er nemt at gennemskue, hvad de bruges til. Det anbefales samtidig at man ikke deler API nøgler mellem forskellige integrationer, men at man i stedet opretter individuelle klient-adgange, så det er nemmere at spore hvor et givent API kald kommer fra.

Hvis man vælger ”Begrænset læseadgang” som en klients rolle (feltet ”Adgange”), så udvides skærmbilledet så man kan vælge præcist hvilke dataområder på hhv personer og enheder der gives læseadgang til. Dette er illustreret nedenfor

Der er en beskrivelse til hver af dataområderne, der angiver hvilke data som klienten får adgang til.

Bemærk at hvis man sletter og/eller ændrer API nøglen på en klient, kan der går lidt tid før dette slår igennem. Årsagen er, at der skal replikeres data rundt til alle noderne i SOFD clusteret, der holder en cache af klient-data i hukommelsen. Nye klienter vil fungere med det samme, da de ikke allerede ligger i cachen på de enkelte noder, og vil blive indlæst fra databasen på første kald til API’erne.

Opsætning af mailskabeloner#

SOFD kan afsende både e-mails og digital post til relevante modtagere, når der indtræffer en hændelse som SOFD overvåger. Listen med potentielle hændelser bliver løbende udvidet, men de fungerer på samme måde, hvilket er beskrevet nedenfor.

Skærmbilledet til opsætning af mailskabeloner tilgås som Administrator, ved at klikke på ”Administration” i top-menuen, og så vælge ”Mailskabeloner” i venstre-menuen.

Her præsenteres man for nedenstående skærmbillede, hvor man kan vælge mellem de forskellige hændelsestyper, og opsætte mailskabeloner for hver af disse

En mailskabelon består af følgende elementer

  • En hændelsestype (kaldet ”Skabelon” i brugergrænsefladen). Her er på skrivende tidspunkt mere end 20 forskellige at vælge mellem, omend flere af disse kan være skjult i den enkelte kommunes installation, da nogle er bundet op til konkrete integrationer, som muligvis ikke er opsat i denne installation.
  • Konkrete ”mails” der udsendes på baggrund af denne hændelse. Her kan man ved at klikke på knappen ”+” tilføje yderligere mails på samme hændelse, hvis man har behov for at der sendes flere på samme hændelsestype. Når man trykker på ”+” knappen. Laves en ny standard-mail, med den tekst som er hardkodet ind i SOFD. Denne tekst kan efterfølgende redigeres. I standard-teksten kan man se hvilke pladsholdere som findes i den valgte skabelon – dette er de eneste pladsholdere som fungerer i netop denne skabelon, og man kan ikke gøre brug af andre. Hvis man har flere mails tilknyttet en given hændelse/skabelon, så kan man skifte mellem dem i dropdown boksen ud for ”Mail” punktet.
  • De individuelle ”mails” til en given hændelse har følgende informationer knyttet til dem
    • Aktiv. Her angives om mailen pt er aktiv. Hvis den ikke er aktiv, så udsendes denne mail ikke når denne hændelse indtræffer
    • Forskudt afsendelse. Hvis man ikke ønsker at denne mail skal sendes med det samme hændelsen indtræffer, så kan man opsætte en forskudt afsendelse. Et almindeligt brugsscenarie er velkomst e-mailen der kan sendes til en medarbejder, når denne får en ny e-mail adresse. Da e-mail adressen muligvis ikke er klar til at modtage post før den er fuldt replikeret til Office 365, kan det være en god ide at udskyde afsendelsen med en times tid
    • Overskrift og Brødtekst. Her angiver man hvad der faktisk sendes til modtageren af mailen. Det er muligt at anvende rig formatering i brødteksten, og pladsholderne der anvendes i skabelonen kan anvendes både i overskriften og i brødteksten.
    • Bilag. Man kan tilføje bilag. Der er pladsbegrænsninger på størrelsen af bilag, og man skal være opmærksom på at e-boks afkræver betaling på størrelsen af de beskeder man sender via digital post, så undlad at sende alt for store bilag.
    • Gem, Slet og Test. Der ligger en række knapper i bunden, som kan bruge til at gemme de ændringer man har foretaget, slette hele mailen, og evt teste den. Hvis man trykker på ”Test”, sendes en prøve e-mail (altid e-mail, så selv skabeloner som ville blive sendt til digital post vil blive sendt som test e-mails) til den administrator som er logget ind i SOFD. Her kan man se formateringen, men selve pladsholderne vil ikke blive udfyldt.

Opsætning af sletningsregler for inaktive personer#

Når en person ikke længere har et aktivt forhold til kommunen, så slette-markeres de i SOFD. Det er dog kun en markering, og selvom de effektivt bliver fjernet fra brugergrænsefladen, ligger de stadig i SOFD databasen, og man kan udlæse dem via API’et (hvor man dog kan se at de er slettet).

En person anses som værende inaktiv, og dermed markeret med en slette-markering, hvis følgende gør sig gældende

  • Personen har enten ikke nogen tilhørsforhold, eller alle tilhørsforhold er afsluttede. Et registreret tilhørsforhold med en start-dato i fremtiden vil tælle som et aktivt tilhørsforhold i denne kontekst.
  • Personen har ikke nogen aktive it-brugerkonti (dvs ingen AD konto, ingen OPUS konto, ingen CICS konto, osv osv). En spærret konto (fx en AD konto der er disabled) vil ikke tælle som en aktiv konto i denne kontekst.

For at overholde persondataforordningen, skal man opsætte en periodisk sletning af disse inaktive personer. Dette kan opsættes af en Administrator under top-menuen ”Administration” via venstre-menuens ”Sletning af personer”.

Her kan man opsætte hvor lang tid man beholder data på personer efter de er markeret til sletning. Vær opmærksom på at hvis en person slettes, så glemmer SOFD også hvad deres UUID er, og hvis personen senere vender tilbage til kommunen, vil de i det tilfælde få et nyt UUID (hvis de vender tilbage inden de er blevet fysisk slettet fra databasen, vil de beholde deres gamle UUID).

Opsætning af advis-dannelse#

SOFD danner en række advis’er på baggrund af hændelser i SOFD. Anvendelsen af disse advis’er er beskrevet andetsteds i brugermanueaen, men selve konfigurationen af hvilke advis’er man kan få, er noget som opsættes af en Administrator. Dette gøres via top-menuen ”Administration” og venstre-menuens ”Indstil advis-dannelse”.

Her kan man sætte flueben ud for de advis-typer man ønsker at SOFD skal danne. Hvis man fravælger nogle af disse advis’er, og trykker på ”Gem”, så spørger SOFD om den skal slette allerede dannede advis’er af den type som man har fravalgt. Her kan man med fordel sige ”Ja” for at få ryddet op i gamle advis’er.

Bemærk også det sidste felt i opsætningen. Her kan man vælge antal dage en AD konto skal have været inaktiv, før en re-aktivering af denne AD konto skal trigge adviseringer og e-mail afsendelse omkring denne hændelse. Det anbefales at denne værdi sættes til 3 (default) eller tilsvarende højt tal, for at undgå adviseringer, hvis man ved et uheld spærrer og så reaktiverer en AD konto.

Opsætning af klassifikationer#

SOFD gør brug af en række indbyggede klassifikationer. Disse klassifikationer kan opsættes og vedligeholdes af en Administrator inde i SOFD. De tilgås alle via top-menuen ”Administration”, og findes i venstre-menuen under overskriften ”Klassifikationer”. De enkelte klassifikationer er beskrevet nedenfor. Bemærk at ikke alle klassifikationer nødvendigvis er synlige, da det afhænger af den konkrete opsætning af SOFD.

Brugerkontotyper#

SOFD arbejder med brugerkonti som er tilknyttet personer. Hver brugerkonto har en type-angivelse, som baserer sig på en underliggende klassifikation. Før en brugerkonto kan indlæses i SOFD, skal der være oprettet en tilsvarende brugerkonto-type i denne klassifikation.

SOFD har ikke nogen holdning til hvilke brugerkonti man indlæser, så længe de er knyttet til en sådan type. Nogle brugerkontotyper indgår dog i SOFDs indbyggede IdM processer, og SOFD har dermed en forretningsmæssige forståelse for, hvad disse kontotyper er for størrelser.

Hvis man tilføjer nye kontotyper så har SOFD ikke den samme forretningsmæssige forståelse, men kan dog stadig drive et generisk IdM flow for disse – så længe der er en selvstændig agent udenfor SOFD, der udfører den faktisk oprettelse/nedlæggelse af disse brugerkonti, på baggrund af de hændelser der udstilles af SOFDs IdM motor.

I skærmbilledet ovenfor, kan man se en liste af brugerkontotyper og deres primære IdM konfiguration. Der er yderligere detaljer gemt bag ”redigerings”-ikonet, og det skærmbillede der bruges til at redigere, er det samme som det der bruges, hvis man opretter en ny brugerkontotype (ved at klikke på knappen ”Opret brugerkontotype”).

De enkelte attributter på en brugerkontotype beskrives under nedenstående skærmbillede

En brugerkontotype skal have både et navn (som vises i brugergrænsefladen) og et ID (som anvendes når brugerkontotypen skal identificeres via API og IdM motoren). Det tekniske ID må ikke efterfølgende ændres, mens navnet kan redigeres/tilpasses løbende.

Der er 2 generelle indstillinger, som skal opsættes for alle brugerkontotyper, disse er

  • Kan bestilles. Her sætter man et flueben hvis SOFD skal understøtte IdM processer for denne brugerkontotype. Hvis man alene er interesseret i at indlæse oplysninger om disse brugerkonti (fx UniLog-in fra STIL), så skal man ikke sætte hak i ”kan bestilles”.
  • Én konto pr medarbejder. Dette felt har en stor indflydelse på SOFDs IdM opførsel- Hvis man sætter et hak i dette felt (det er default), så vil SOFD alene sørge for at en medarbejder får én af disse konti, uagtet hvor mange ansættelser og jobskifte som en medarbejder måtte lave i løbet af sit forhold til kommunen. Hvis man fjerner fluebenet her, så vil SOFD binde denne brugerkontotype til ansættelsen. Det betyder at hver gang en medarbejder får en ekstra ansættelse eller skifter ansættelse, så nedlægges (ved ophør af en konkret ansættelse) eller oprettes (ved opstart på ny ansættelse) brugerkonti. Dette giver typisk kun mening for brugerkonti der tilhører lønsystemet (fx OPUS brugerkonti), men kan slås til for alle brugerkontotyper hver for sig.

Hvis man vælger at en brugerkontotype skal indgå i SOFDs IdM processer (dvs hak i ”Kan bestilles”), så skal man også udfylde de to efterfølgende sektioner, dvs

  • Frister
    • Aktivering. Her skal angives hvor mange dage før første arbejdsdag, at denne type brugerkonto automatisk skal oprettes. Hvis man ikke ønsker automatisk oprettelse, sættes værdien til 0. For at automatisk oprettelse fungerer, skal værdien sættes til mindst 1 dage før første arbejdsdag.
    • Deaktiver. Her skal angives hvor mange dage efter sidste arbejdsdag at denne type brugerkonto automatisk skal deaktiveres. Hvis man ikke ønsker automatisk deaktivering, sættes værdien til 0. For at automatisk deaktivering fungerer, skal værdien sættes til mindst 1 dage efter sidste arbejdsdag.
    • Slet. Her skal angives hvor mange dage efter sidste arbejdsdag at denne type brugerkonto automatisk skal slettes. Hvis man ikke ønsker automatisk sletning, sættes værdien til 0. For at automatisk sletning fungerer, skal værdien sættes til mindst 1 dage efter sidste arbejdsdag. Bemærk at hvis man både har automatisk deaktivering og automatisk sletning slået til, skal man sætte slettefristen til SENERE end deaktiveringsfristen, ellers giver det ikke mening 😊
    • Afhængig af. Nogle brugerkontotyper kan kun fungere hvis personen også har en brugerkonto af en anden type (fx kan man kun få en Exchange konto hvis man har en AD konto). For at sikre at SOFD ikke går på fejl i oprettelsen, skal man opsætte en evt afhængighed her, så SOFD sikrer at kontiene oprettes i den rigtige rækkefølge
    • Forskudt oprettelse. Hvis der er en afhængighed til en anden brugerkonto, så kan det være nødvendigt at indlægge en forsinkelse mellem de to oprettelse. Det anbefales at man indlægger en kort forsinkelse (fx 30 minutter) når der er tale om afhængigheder, så man er sikker på at den første konto er fuldt oprettet før SOFD forsøger at oprette den næste
  • Navnekonvention
    • Prefix. Hvis man har en fast værdi som skal indgå i starten af et brugernavn, så kan man angive det her. Et typisk brugsscenarie er brugerkonti til OPUS, der skal starte med 2 faste bogstaver.
    • Infix. Dette er det faktiske brugernavn, og man kan her vælge mellem forskellige strategier. Disse er
      • Tilfældig. Fuldstændigt tilfældigt dannet brugernavn
      • Kort fra navn. Her dannes et brugernavn baseret på personens fulde navn, fx kunne Hans Jensen blive til ”haje”
      • Langt fra navn. Her dannes et brugernavn baseret på personens fulde navn, fx bliver Hans Jensen til ”hans.jensen” – dette giver typisk kun mening til Exchange konti.
      • Medarbejdernummer. Hvis man ønsker at brugernavnet skal matche medarbejdernummeret fra lønsystemet. Dette giver typisk kun mening for brugerkonti der følger en konkret ansættelse (fx OPUS).
      • Samme som anden brugerkonto. Hvis man vælger denne, så angiver man hvilken brugerkontotype som det skal matche. Dette giver fx mening hvis man ønsker at AD brugernavn og Exchange email adressen skal være identisk. Så kan man på Exchange brugerkontotypen opsætte at brugernavnet skal være identisk med AD.
    • Infix længde. Hvis man har valgt ”tilfældig” eller ”kort fra navn”, så skal man angive hvor lange brugernavnene skal være. Det anbefales at man vælger en værdi der er stor nok til at der altid kan dannes et brugernavn (fx 5 eller 6)
    • Suffix. Hvis man har brug for at brugernavnet altid ender på den samme værdi, så kan man angive dette her. Dette finder typisk ikke anvendelse, og man kan vælge at udelade denne ved at sætte den til ”Ingen”.

Konfigurationen af klassifikationen er grundlaget for SOFDs håndtering af disse brugerkonti. Bemærk dog at SOFD ikke automatisk begynder at bestille brugerkonti bare fordi man har sat hak i ”Kan bestilles”. Det kræver stadig at der opsættes bestillingsregler på de enkelte enheder for netop denne brugerkontotype.

Mht oprettelsen af Exchangekonti, er det kun den del af brugernavnet der kommer før @ der opsættes i SOFD Core. Den lokale agent der udfører den faktisk oprettelse håndterer delen efter @. Her kan man konfigurere forskellige maildomæner afhængig af hvor medarbejderen ansætter. Se detaljerne til dette i vejledningen til den lokale agent.

Enhedstyper#

Enheder i SOFD er alle opmærket med en type-angivelse. Som udgangspunkt kan man i SOFD vælge mellem ”Afdeling” og ”Team”. Disse opsættes inde på enheden som vist nedenfor

Hvis man har et behov for at tilføje yderligere valgmuligheder, så kan man udvide denne klassifikation under ”Administration”. Her kan man tilføje nye enhedstyper til nedenstående liste.

Der er ikke nogen funktionalitet bundet op på evt. ekstra enhedstyper man tilføjer, så der vil blot være tale om dokumentation af enhedens type til internt brug.

Hvis man opmærker en enhed med typen ”Team”, så vil overførslen til FK Organisation opmærke enheden som værende et Team. Der er pt ét system der gør brug af denne oplysning (DUBU), og det er formodentligt ikke noget der skal bruges i kommunen, medmindre man arbejder med Team begrebet i DUBU (det gør de færreste).

Forbudte ord#

Når man lader SOFD oprette brugerkonti, så dannes brugernavnet ud fra den navnestandard man har opsat. Det kan resultere i uheldige/uhensigtsmæssige brugernavne, og det er derfor muligt at vedligeholde en liste af forbudte ord. Disse matches op mod ”infix” delen af det brugernavn som SOFD danner når den opretter en ny brugerkonto.

Ord på listen vil IKKE blive brugt som brugernavne af SOFD.

Listen er blot en simpel liste af ord, som kan vedligeholdes under ”Administration”, og et eksempel på listen er vist nedenfor

Tags#

Som beskrevet tidligere, har SOFD et TAG begreb, som er en slags klistermærker man kan sætte på enheder. De kan funktionelt anvendes til en lange række ting, typisk forbundet med integrationer til eksterne systemer, hvor TAG’et bruges til at styre integrationen.

En Administrator kan opsætte og vedligeholde de tilgængelige TAGs i SOFD. Dette gøres under ”Administration” hvor man kan tilgå nedenstående liste

Et TAG består af følgende oplysninger

  • Tag (navn). Dette er det navn som TAG’et har, og som vises i brugergrænsefladen når man arbejder med TAG’et.
  • beskrivelse. Dette er en beskrivelse, der vises for brugergrænsefladefladen når man arbejder med TAG’et.
  • Har værdi. Her angives med flueben hvorvidt at dette TAG også kræver indtastningen af en konkret værdi når man sætter TAG’et på en enhed. Hvis man fx gerne vil opmærke enheder med hvilken type Office licens der anvendes (E1, E3, F3, F5, osv), så kan man her afkræve at der skal indtastes en sådan værdi. Man kan med fordel skrive i beskrivelsen hvad de lovlige værdier er.
  • Unik værdi. Hvis der ikke må være 2 enheder som er opmærket med samme værdi (indenfor dette TAG), så sætter man flueben her. Det kan give mening hvis man har brug for at opmærke enheder med en fremmednøgle, som enheden skal være kendt under i det eksterne system.
  • Navn på værdi. Dette er det navn som bruges om værdien (fx ”Licenstype”), og som vises i brugergrænsefladen når brugeren skal indtaste en værdi.
  • Regulært udtryk. Denne kan udfyldes når man har valgt at der skal indtastes en værdi, og er valideringsreglen for den indtastede værdi. Det angives som et regulært udtryk. Hvis man efterlader den blank, foretages ikke nogen validering af input.

Hvis man opretter et TAG uden en værdi tilknyttet, så er det bare et simpelt ”klistermærke” man kan sætte på enheder, og som evt. kan bruges til et filter i en udlæsning til et eksternt system.

Skærmbilledet til at oprette/redigere et TAG ser ud som vist nedenfor

Stillingskatalog#

Det er muligt at tilføje et katalog over alle kommunens stillinger. Der findes et separat stillingskatalog for hver organisation i OS2sofd (såfremt man har flere/andre organisationer end den administrative organisation).

Kataloget kan benyttes til at ensrette alle de forskellige stavemåde af samme stilling fra kildesystemerne (f.eks. lønsystemet).

Stillingskataloget benyttes også når der oprettes et tilhørsforhold direkte i OS2sofd – her vil stillingskataloget fungere som auto-complete kilde således at stillinger fra kataloget vises i en dropdown når brugeren begynder at skrive en stilling i stillingsbetegnelse feltet.

Stillingskataloget træder i kraft så snart der er oprettet mindst én stilling i kataloget.

Når stillingskataloget fra starten er tomt, har man mulighed for at lave en éngangsoprettelse af alle de stillinger der ønskes medtaget i kataloget fra start.

Dette gøres ved at trykke på knappen ”Generér nyt katalog”.

De valgte stillinger vil blive oprettet som stillinger i stillingskataloget, men uden en egentlig mapningsregel. Dog fungerer systemet således at et tilhørsforhold med samme stillingsbetegnelse som en stilling i stillingskataloget altid vil blive mappet til den pågælende stilling i kataloget (selv om der ikke er oprettet en mapning endnu).

På siden over stillinger i stillingskataloget har man mulighed for at tilføje nye stillinger til kataloget, slette eksisterende stillinger eller redigere mapningsreglerne for eksisterende stillinger.

Et typisk forretningsbehov er at kommunen gerne vil ensrette de utallige måder man kan stave til f.eks. ”Social- og sundhedsassistent” på. Men samtidig ønsker man at adskille ”Social- og sundhedsassistent elev” fra ”Social- og sundhedsassistent”-stillingen.

Dette kan gøres ved at oprette de 2 stillinger som vist nedenfor:

Her er der lavet en ”Positiv wildcard” mapning på ”so*su*as*” som rammer størstedelen af alle stavemåderne for ”Social- og sundhedsassistent”. Men for at undgå at denne stillings også skal sættes på eleverne, er der lavet en ”Negativ wildcard” mapning på ”*ele*”.

Her er der kun lavet en ”Positiv wildcard” mapning på ”so*so*as*ele*” som rammer størstedelen af alle stavemåderne for ”Social- og sundhedsassistentelev”.

Lignende regler kan så laves for ”Social- og sundhedshjælper” (so*su*hj*) osv.

I meget avancerede tilfælde er det muligt at lave en maping baseret på et regulært udtryk.

På fanen ”Oversættelser” kan man se en oversigt over alle stillingsbetegnelser i kommunen. Her kan man også se om der skulle være konflikter i mapningen. Dvs. stillinger som ikke kan mappes til nogle stillinger i stillingskataloget, eller stillinger hvor mapningen er tvetydig (de kan mappes til flere stillinger i kataloget).