3C Integrationsbeskrivelser
3C INTEGRATIONSBESKRIVELSER... 1 3C.2 INDLEDNING 3 3C.3 GENERELT OM INTEGRATIONER 3 3C.3.1 Standarder for integrationer og data 4 3C.3.2 Protokoller 4 3C.3.3 Ressourcestyring og overvågning 4 3C.3.4 Mapning, validering og komprimering 5 3C.3.5 ØDUP 5 3C.4 STATENS LØNSYSTEM (SLS) 6 3C.4.1 Nyansættelser 7 3C.4.2 Person 7 3C.4.3 Engangsløndele 8 3C.4.4 Løbende løndele 8 3C.4.5 Kontering 9 3C.4.6 Løndelskontering 9 3C.4.7 Oprykning 10 3C.4.8 Overenskomst 10 3C.4.9 Statistik 11 3C.4.10 Afgang 12 3C.4.11 Yderligere tilgængelige webservices 12 3C.4.12 Retursvar fra webservices 13 3C.4.13 Læse- og listewebservices 14 3C.4.14 AdminDB 14 3C.5 NAVISION STAT (NS) 15 3C.5.1 Registreringsrammen 15 3C.5.2 Medarbejderdata 16 3C.6 SINGLE-SIGN-ON (SSO) 16 3C.7 INTEGRATION TIL ACTIVE DIRECTORY (AD) 17 3C.8 LOKALE FAGSYSTEMER 18 3C.8.1 Lokale ESDH-systemer 18 3C.9 CVR-REGISTRET 19 3C.10 CPR-REGISTRET 19 3C.11 STATENS LOKALE DATAVAREHUS (LDV) 20 3C.12 CAMPUS 21 Side 2 af 21
3C.2 Indledning HR-Løsningen antages at blive en central komponent i den fællesstatslige systemportefølje. Løsningen kommer til at indgå i en mængde sammenhænge med øvrige systemer som angivet i figur 1 Integrationsoverblik HR- Løsningen, for at føre til en hensigtsmæssig opgaveløsning og sikre projektets gevinster. Dette dokument indeholder overordnede beskrivelser af de integrationsteknologier og protokoller, der forventes at skulle understøttes i integrationen mellem HR-Løsningen og øvrige systemer i staten. Herudover indeholder dokumentet beskrivelser af de enkelte systemer, og deres specifikke integrationer. CPR CVR Single Sign On Systemadgang CPR Navn/Adresse CVR Adresse AD (SIT) Medarbejder data SLS admindb Løn stamdata Medarbejder B-Nummer Medarbejder E-mail HR-data Lokale fagsystemer Medarbejder persondata og løndata HR-løsningen SLS Medarbejder data CAMPUS Spejl af HR-databasen Registreringsrammer Medarbejderdata Lokal Datavarehus Navision Stat Internt system Eksternt system Planlagt proces Hændelsesdrevet proces Udover Leverandørens ydelser i forbindelse med opsætning af integrationer, vil Kunden naturligvis også skulle levere ydelser i form af viden, nødvendig information til opsætning af integrationerne mv. I det tilfælde, at Kunden ikke kan levere den nødvendige information til opsætning af integrationer, afløftes Leverandørens forpligtelse til at levere den krævede funktionalitet, frem til, at Kunden er i stand til at levere. En sådan udsættelse kan ikke falde leverandøren til last i forhold til opnåelse af milepæle, vederlagsbetalinger mv. 3C.3 Generelt om integrationer Side 3 af 21
I dette afsnit gennemgås en række betragtninger vedr. diverse funktionaliteter, integrationsteknologier og protokoller for Løsningen på tværs af alle interfaces og datastrømme. 3C.3.1 Standarder for integrationer og data For at sikre at der anvendes åbne og almindeligt anerkendte standarder er det afgørende at leverandøren overholder god praksis på markedet. Det vil derfor være ønskeligt, at der følges alment anerkendte retningslinjer som fx WCAG 2.0 fra World Wide Web consortium (W3C) hvad angår software og standarder for data i staten som defineret af Digitaliseringsstyrelsen. Der kan læses mere om Digitaliseringsstyrelsen arbejde med standardisering og åbne standarder her: http://www.digst.dk/arkitektur-og-standarder/standardisering Der kan læses mere om W3C og WCAG her: https://www.w3.org/ 3C.3.2 Protokoller Webservices er den mest anvendte integrationsprotokol mellem Kundens systemer. De webservices som er i anvendelse i øjeblikket er for størstepartens vedkommende baseret på simple XML-filer. Alle webservices er fyldestgørende dokumenteret på Kundens hjemmeside, www.modst.dk, hvor der kan findes komplette vejledninger til adgang, konfiguration og opbygning af filer for alle Kundens systemer. Kunden bruger på enkelte systemer SFTP/FTP adgange. Adgange til disse servere skal aftales nærmere med Statens It i det tilfælde denne integrationsprotokol ønskes anvendt. I det tilfælde der forventes anvendt denne protokol er det angivet under den enkelte integration. 3C.3.3 Ressourcestyring og overvågning Kunden ønsker, at integrationer designes på en sådan måde, at de ressourcemæssigt er adskilt fra den almindelige drift af HR-Løsningen. Det må således ikke påvirke medarbejderes almindelige arbejde i Løsningen, såfremt en Institution indsender et stort antal transaktioner i forbindelse med en integration. Det bør være muligt at schedulere kørsler således at de gennemføres på definerede tidspunkter. Kørsler bør dog også kunne være hændelsesbaserede, så- Side 4 af 21
ledes at fx oprettelse eller ændring af en medarbejderes data, igangsættes dataudveksling. HR-Løsningen bør i den sammenhæng være i stand til at understøtte push og pull funktionalitet. Herudover bør det være muligt at etabelere en kø-mekanisme som sikrer, at data som ikke umiddelbart behandles ved modtagelse, vil blive behandlet i modtaget rækkefølge. Kø-mekanismen bør desuden styre antallet af samtidige processer med henblik på at optimere performance. Det bør være muligt at overvåge integrationer fra et fælles dashboard, som giver overblik over trend, historik, schedulerede kørsler og log for hver integrationskomponent. Det bør fra samme dashboard være muligt at schedulere kørsler, samt opsætte begrænsning for båndbredde og ressourceforbrug på de enkelte integrationskomponenter. 3C.3.4 Mapning, validering og komprimering Løsningen bør indeholde funktionalitet som giver mulighed for at mappe data efter både generelle og konditionsbaserede regler, både i forbindelse med modtagelse og afsendelse af data. Formålet med denne funktionalitet er at sikre størst mulige fleksibilitet i anvendelse af HR-Løsningens, og øvrige systemers data. Input via webservices, samt via andre integrationer hvor det er praktisk muligt, skal understøtte hård validering af data, både i forhold til integrationsfilens opbygning, og det indeholdte data. Fejlet validering skal medføre afvisning af filen, uanset årsagen til fejlen. Det bør være muligt at komprimere data via webservices, og denne komprimering bør kunne administreres fra dashboardet. 3C.3.5 ØDUP ØDUP (Økonomistyrelsens DataUdvekslingsPunkt) er en JBOSS-baseret løsning til udveksling af data via flade filer. Den nuværende løsning tilbyder ingen udvidede services(hermed menes fx push/pull funktionalitet, schedulerede kørsler mv.). Den fungerer udelukkende som en postkasse funktion. Til afhentning af data fra ØDUP skal udvikles en komponent i HR-Løsningen. Komponenten afvikles centralt og køres efter en fast schedulering. Tidspunktet skal kordineres ift. den forudgående aflevering af data fra afsender- /modtagersystemet (fx Navision Stat). For hver enkel kørsel henter/afleverer komponenten de tilhørende filer i ØDUP. Ved afhentning kan filen derefter indlæses i HR-Løsningen. Side 5 af 21
ØDUP tilgås via en partnerskabsaftale og til HR-Løsningen skal oprettes en ny partnerskabsaftale. Samtlige Institutioners datafiler kan tilgås via denne partnerskabsaftale. Kunden er i proces med at erstatte ØDUP ved etablering af en fælles integrationsplatform, ligeledes baseret på JBOSS-teknologi, men med et udvidet serviceniveau herunder fx push/pull, schedulering mv. Da denne nye integrationsplatform bliver et strategisk valg for Kunden, vil integrationen fra flest mulige systemer blive forsøgt placeret her. Det er derfor væsentligt, at den kommende HR-Løsning i størst muligt omfang understøtter teknologien. Nærmere information om ØDUP kan findes på dette link: http://www.modst.dk/systemer/oedup 3C.4 Statens Lønsystem (SLS) Statens Lønsystem anvendes til at beregne, anvise og kontere løn til den overvejende del af de statslige lønmodtagere og en lang række lønmodtagere inden for selvejerområdet. HR-Løsningen skal kunne oprette, vedligeholde og nedlægge medarbejderforhold i SLS, herunder oprettelse og ændring i lønforhold. Det er dermed tænkt, at HR-Løsningen skal understøtte følgende processer i SLS: 1. Oprettelse af medarbejder 2. Løbende ændringer på medarbejders data (ajourføring) 3. Lukning af medarbejder Til understøttelse af ovenstående processer, udstiller SLS en række webservices, som kan findes nærmere specificeret på nedenstående link: http://www.modst.dk/systemer/statens-loensystem-sls/slswebservice/webservicevejledninger I nedenstående afsnit er de nødvendige webservices til understøttelse af ovenstående processer overordnet beskrevet. Det vil være nødvendigt at hente de detaljerede vejledninger for nærmere detaljer på de enkelte webservices. Kommunikationen med SLS via webservices forventes at være hændelsesbaseret, og vil derfor ske i det tilfælde en medarbejder ansættes, data på medarbejderen opdateres, eller medarbejderen nedlægges. Side 6 af 21
Til understøttelse af oprettelse af medarbejder skal anvendes flere webservicekald, da ikke alle data vedrørende oprettelsen kan registreres ved en enkelt webservice. 3C.4.1 Nyansættelser Webservicen Nyansættelser anvendes til oprettelse af medarbejderens stamdata, som vist i listen nedenfor over de data som kan overføres til SLS via denne webservice. Denne webservice kan kun anvendes til oprettelse, og kan dermed ikke ajourføre data efterfølgende. Vær opmærksom på, at nedenstående data er udtryk for de alment anvendte felter, men ikke er udtømmende. Der kan anvendes andre felter end angivet. Endvidere er alle nedenstående informationer ikke obligatoriske for oprettelse af en ny medarbejder i SLS. For nærmere information, se webservicebeskrivelsen. 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold. Hvis der ikke angives løbenr. tildeler systemet et. 2. Fradato, som identificerer startdatoen for ansættelsesforholdet 3. For- og efternavn på personen 4. Bankkontooplysninger (for personer uden NemKonto) 5. Skattekorttype, som angiver om der skal benyttes hovedkort eller ej 6. Personalekategori (PKAT), klasse og trin, som specificerer hvilken overenskomst personen er ansat under 7. Oprykningsdato eller lønanciennitetsdato, som anvendes til beregning af næste oprykning 8. Stillingsbetegnelse 9. Lønform, som f.eks. kan være forudlønnet eller bagudlønnet 10. Ansættelsesbrøken, som personen aflønnes i forhold til 11. Delregnskab, som identificerer den fulde specifikation af bogføringskreds og delregnskab, fx 06514010 (Moderniseringsstyrelsen) 12. Administrativ tjenestestedskode som sammen med gruppen identificerer tjenestestedet Den yderligere registrering og løbende opdatering af data, fx på løndele, kontering, oprykning, overenskomst og lignende, foregår med den relevante webservice til ajourføring. Webservices til ajourføring af medarbejdere som vurderes nødvendige for understøttelse af HR-Løsningens processer bliver gennemgået nedenfor. 3C.4.2 Person Side 7 af 21
Webservicen Person anvendes til ajourføring af navneoplysninger og stillingstekst på medarbejderen. Med denne webservice er det muligt at opdatere nedenstående data. 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Efternavn og fornavn på medarbejderen 3. Evt. kaldenavn på medarbejderen 4. StillingTekst, som kan anvendes som alternativ tekst til stillingsbetegnelseskodens tekst, på lønspecifikationen. 5. Bankkontooplysninger (se bemærkning nedenfor) Bemærk, at punkt 5, Bankkontooplysninger, blot dækker over de tilfælde, hvor der er behov for at indrapportere bankoplysninger på personer, der ikke har Nemkonto. Medarbejderne kunne tidligere få fordelt løn på to konti, men dette tilbydes ikke længere. 3C.4.3 Engangsløndele En engangsløndel i SLS er en løndel, der kun udbetaler én gang på en given dato. Engangsløndele anvendes fx i forbindelse med anvisning af overarbejde, merarbejde eller natpenge. De data der kan overføres til SLS er følgende: 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Løndelskode og dato, som identificerer den relevante løndel 3. Løndelsfelter, som indeholder relevante oplysningertil brug for beregningen. Det kan dreje sig om beløb, sats, timer eller andre enheder 4. Kreditor, som identificerer en betalingsmodtager i SLS, fx SKAT, ATP eller en pensionskasse 5. Delregnskab, som identificerer den fulde specifikation af bogføringskreds og delregnskab, fx 06515010 (Økonomistyrelsen) 6. Artskonto, som identificerer den 4-cifrede artskonto i statens kontoplan fx 1811 (Almindelig løn) 7. Segmenter. I SLS er reserveret 6 felter kaldet segmenter til registrering af Institutionernes interne kontoplan 8. Løndelstekst, som er en brugerbestemt betegnelse for en løndel 3C.4.4 Løbende løndele Side 8 af 21
En løbende løndel i SLS er en løndel, der foretager løbende udbetaling typisk én gang månedligt. Løbende løndele anvendes f.eks. til kvalifikationstillæg, rådighedstillæg, funktionsbestemte tillæg mm. De data der kan overføres til SLS er følgende: 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Løndelskode, som identificerer den relevante løndel 3. Fradato til angivelse af, hvornår løndelen skal beregne 4. Tildato, hvis løndelen er tidsbegrænset 5. Løndelsfelter, som indeholder relevante oplysninger til brug for beregningen. Det kan dreje sig om beløb, sats, timer eller andre enheder 6. Kreditor, som identificerer en betalingsmodtager i SLS (kun pensionskasser og faglige organisationer. 3C.4.5 Kontering Ajourføring af konteringer anvendes til ændringer i lønmodtagerens normale udgiftskontering. De data der kan overføres til SLS er følgende: 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Fradato og evt. tildato, som identificerer gyldighedsperioden for konteringen 3. Delregnskab, som identificerer den fulde specifikation af bogføringskreds og delregnskab, fx 06514010 (Moderniseringsstyrelsen) 4. Artskonto, som identificerer den 4-cifrede artskonto i statens kontoplan fx 1811 (Almindelig løn) 5. Segmenter. I SLS er reserveret 6 felter kaldet segmenter til registrering af Institutionernes interne kontoplan 6. Administrativ tjenestestedskode som sammen med gruppen identificerer tjenestestedet 7. Arbejdsstedskode som identificerer ansættelsesstedet Der findes ydermere en webservice kaldet Afvigende kontering som anvendes i det tilfælde der ønskes en anden kontering i SLS end den der opsættes generelt. Der henvises til ovenstående link for nærmere detaljer om denne webservice. 3C.4.6 Løndelskontering Side 9 af 21
Særlige løndelskonteringer anvendes hvis der ønskes en anden kontering af en løbende løndel i SLS end den der opsættes generelt. De data der kan overføres til SLS er følgende: 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Løndelskode, som identificerer den relevante løndel 3. Fradato og evt. tildato, som identificerer gyldighedsperioden for den særlige kontering 4. Delregnskab, som identificerer den fulde specifikation af bogføringskreds og delregnskab, fx 06514010 (Moderniseringsstyrelsen) 5. Artskonto, som identificerer den 4-cifrede artskonto i statens kontoplan fx 1811 (Almindelig løn) 6. Segmenter. I SLS er reserveret 6 felter kaldet segmenter til registrering af Institutionernes interne kontoplan 7. Opsplitningsprocent, en procent, der angiver hvor stor en del af det beregnede beløb, der skal anvende den særlige kontering 3C.4.7 Oprykning Webservicen anvendes til at ajourføre oprykningsoplysninger om et ansættelsesforhold. De data der kan overføres til SLS er følgende: 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Oprykningsdato, som anvendes til beregning af næste oprykning 3. Personalekategori, klasse og trin, som specificerer hvilken overenskomst personen er ansat under 4. Stillingsbetegnelse 5. Lønform, som f.eks. kan være forudlønnet eller bagudlønnet 6. Oprykningssluttrin, som anvendes til at bremse den automatiske oprykning i et ansættelsesforhold 7. Oprykningsindikator, der anvendes til særlige oprykningsajourføringer 3C.4.8 Overenskomst Webservicen anvendes til ajourføring af overenskomstoplysninger. De data der kan overføres til SLS er følgende: Side 10 af 21
1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. OverenskomstFradato, som identificerer startdatoen for overenskomstforholdet 3. OverenskomstTildato, som identificerer slutdatoen for overenskomstforholdet 4. Personalekategori, klasse og trin, som specificerer hvilken overenskomst personen er ansat under 5. Oprykningsdato eller lønanciennitetsdato, som anvendes til beregning af næste oprykning 6. Stillingsbetegnelse 7. Lønform, som f.eks. kan være forudlønnet eller bagudlønnet 8. Ansættelsesbrøken, som personen aflønnes i forhold til 9. Lønpulje, der angiver om personen kan få tildelt lønpulje fra cheflønspuljen eller lokallønspuljen 10. Forhandlingsberettiget organisation 11. Forsøgsordning, der angiver forskellige ordninger vedr. aflønningsform 3C.4.9 Statistik Denne webservices anvendes til ajourføring af statistik på en medarbejder i forbindelse med ændringer. Ved oprettelsen af medarbejderen første gang, etableres alle de statistikoplysninger Danmarks Statistik skal bruge. Statistikoplysningerne indeholder bl.a. koder vedrørende medarbejderes arbejdsfunktion og jobstatus. Oplysningerne indgår som grundlag for Danmarks Statistiks lønstatistikker og indberettes kvartalsvis. Statistikoplysningerne, der kan overføres til SLS er følgende: 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Fra- og Tildato, som identificerer perioden hvor oplysningerne er gældende 3. Ansættelsesform, som f.eks. betegner om der er tale om fast- eller vikaransættelse 4. Vikarordning, som f.eks. kan være barsel eller uddannelse 5. Beskæftigelsesordning, som er en kode der f.eks. kan angive jobtræning, nedsat arbejdsevne, revalidering mv. 6. Officiel stillingskode, som er en entydig identifikation af stillinger, omfattet af Finansministeriets stillingskontrol. 7. Bevillingslønramme, anvendes for personer der aflønnes i lønramme 35 eller derover Side 11 af 21
8. Lokal stillingskode, som er et nummer for en Lokalt defineret stilling 9. Job funktions kode, Danmarks Statistiks DISCO-koder over arbejdsfunktioner 10. Job status kode, Danmarks Statistiks job-status-kode anvendes til at skelne elever og ledere fra andre medarbejdere 11. Ansættelsesvilkår, Danmarks Statistiks ansættelsesvilkårs-kode 3C.4.10 Afgang Til standsning af et ansættelsesforhold anvendes webservicen Afgang. Der kan med denne webservice opdateres nedenstående data. 1. CPR-nummer og løbenr., som identificerer lønmodtagerens ansættelsesforhold 2. Afgangsårsagskoden, som identificerer, hvilken type afgang der er tale om (anden ansættelse, pension, sygdom mv.) 3. Fradato og evt. tildato, som identificerer gyldighedsperioden for afgangsårsagen 3C.4.11 Yderligere tilgængelige webservices Udover de ovenfor nævnte webservices, findes der desuden nedenstående webservices tilgængelige i SLS. Disse vurderes ikke umiddelbart til at være relevante for at understøtte de ønskede processer og funktionalitet vedrørende integration til HR-Løsningen. De vil ikke blive behandlet yderligere i dette Bilag, men fuld dokumentation kan findes på ovenstående link. De yderligere webservices er følgende: Ansættelsesforholdets faste felter, i et ansættelsesforhold er der mulighed for at registrere en lang række valgfri oplysninger på såkaldte faste felter. Ajourføring af ansættelsesforholdets faste felter anvendes til at vedligeholde disse oplysninger. Erindringer, erindringsoplysninger kan anvendes til brug for registrering af påmindelser om særlige begivenheder i tilknytning til et ansættelsesforhold i SLS. Der er mulighed for at registrere en kode, der markerer en særlig begivenhed, f.eks. prøvetids ophør eller jubilæum. Desuden registreres datoen for tidspunktet for den særlige begivenhed. Der kan desuden tilknyttes en bemærkning (erindringstekst) til begivenheden. De registrerede erindringsoplysninger udmeldes på et særligt uddata i SLS (734). Ferieret, i SLS er der mulighed for at registrere oplysninger om en medarbejders ferieret. For hver medarbejder oprettes automatisk et ferieregnskab, hvoraf Side 12 af 21
fremgår den optjente ferie (ferieretten), afholdt ferie samt restferie. Afholdelse af ferie sker ved indrapportering af hændelser med relevante årsagskoder. (Se Vejledning til SLS webservice Hændelse). Ferie korriger, anvendes til korrektion af data indberettet med webservices Ferieret som vist ovenfor. IAP, Individuelt afregnet pension (IAP) betegner pensionsordninger, som den enkelte lønmodtager selvstændigt opretter, eller kollektive pensionsordninger, hvor man har valgt et pengeinstitut, der opretter individuelle konti til lønmodtagerne. IAP er karakteriseret ved, at beløbet skal indsættes på individuelle konti.. Der skal anvendes en række særlige lønkoder (IAP-løndele) samt stamoplysninger om bankkontoen, hvor beløbet skal overføres.omsorgsregnskab, i SLS er der mulighed for at registrere oplysninger om en medarbejders omsorgsret (omsorgsregnskab). Omsorgsret optjenes ved at konvertere afspadseringsdage til omsorgsdage eller ved tildeling. Pensab, Pensab-data er oplysninger om pensionsskalatrin, overenskomstoplysninger, oprykningsdato mv. og anvendes til at vedligeholde oplysninger om statstjenestemænd på ny løn. Disse oplysninger overføres herefter til det egentlige Pensab-system. Skatteløndele, i SLS hentes der automatisk oplysninger om personernes skatteforhold fra SKAT. Det drejer sig om informationer om beskatningstype, trækprocent, månedligt fradrag samt evt. skattefritagelse. I enkelte situationer kan der være behov for at indrapportere ændringer til disse oplysninger, fx hvis lønmodtageren ønsker en forhøjelse af trækprocenten. Timebank, I SLS er der mulighed for at ajourføre oplysninger om en medarbejders ferie-fravær via vores timebank. 3C.4.12 Retursvar fra webservices Alle SLS-webservices er opbygget som request-response operationer, dvs. et input resulterer i et output. Hver overførsel fra det lokale system til SLS giver et øjeblikkeligt retursvar, indeholdende resultatet af SLS-behandlingen. Hvis transaktionen ikke kan gennemføres i SLS returneres en kode for at behandlingen er fejlet. En transaktion i SLS kan udløse en eller flere følgetransaktioner. Hvis den oprindelige transaktion gennemføres korrekt, men danner en advarsel, returneres en kode med betydningen Gennemført, men advarsel dannet. Denne kode returneres ligeledes hvis en evt. følgetransaktion fejler eller danner en advarsel. Side 13 af 21
De data der kan returneres til det eksterne system er følgende: 1. Returkode, som angiver en status for behandlingen af transaktionen 2. CPRnummer, som identificerer lønmodtageren 3. Løbenummer, som sammen med CPRnummer identificerer lønmodtagerens ansættelsesforhold 4. Fejl/advis art og Fejl/advis kode, som sammen identificerer fejlen eller advarslen 5. Fejl/advis tekst, som er en verbal beskrivelse af fejlen eller advarslen 6. Transaktionskode og Transaktionsnavn, som sammen identificerer den transaktion, der har givet anledning til fejlen eller advarslen 3C.4.13 Læse- og listewebservices Ud over de her nævnte webservices, findes der en række læse- og listewebservices, beskrevet samlet nedenfor. Der henvises til ovenstående link for nærmere detaljer om mulighederne. Det forventes at denne funktionalitet vil være relevant i forbindelse med præsentation af data i HR-Løsningen. Læsewebservices supplerer de webservices, som er udviklet til brug for opdatering af oplysninger i SLS. Læsewebservices kan ikke manipulere data i SLS, men er services som på baggrund af et input læser og returnerer en række forskellige oplysninger, som er registreret i SLS, f.eks. overenskomstoplysninger, konteringer eller indholdet i faste felter. Listewebservices kan returnere flere poster vedrørende udsøgningen, f.eks. en liste over en persons ansættelsesforhold eller en liste over samtlige løndele for et ansættelsesforhold. 3C.4.14 AdminDB I forbindelse med integrationen med SLS og de krævede data i nævnte webservices, stiller Kunden en database, AdminDB, til rådighed. Formålet med AdminDB er at sikre korrekt data i forbindelse med udvælgelse af personalekategorier, overenskomster, løndele og lignende. Dette sikrer en nem og brugervenlig arbejdsgang i HR-Løsningen, og mindsker risikoen for fejl i forbindelse med webservice-kald. Alle data oprettes og vedligeholdes i SLS og sendes derfra til AdminDB med henblik på at udstille dem for øvrige systemer. AdminDB indeholder derfor komplette datasæt fra SLS. Det vil være hensigtsmæssigt at HR-Løsningen henter data fra AdminDB, tilknytter dem til medarbejdere og afleverer data tilknyttet medarbejdere til SLS via de ovenfor beskrevne webservices. Side 14 af 21
AdminDB er udformet som en relationel database som beskriver den korrekte sammenhæng mellem data i SLS. Et eksempel kan fx være sammenhæng mellem forhandlingsberettiget organisation og overenskomst (PKAT). Det anbefales at downloade denne struktur, således, at der kan etableres en funktion i HR-Løsningen, som sikrer en nem, hurtig og sikker udvælgelse af korrekt data for HR-medarbejderen. AdminDB opdateres med nye værdier efter hver lønkørsel på SLS, og er dermed altid baseret på nyeste tilgængelige data om overenskomster, personalekategorier, løndele og lignende. AdminDB skal hentes umiddelbart efter hver lønkørsel, dvs. to gange månedligt. AdminDB er implementeret som en Microsoft SQL-database. Der er i øjeblikket bygget en dedikeret grænseflade til HR-Løn, som fungerer som brugergrænsefladen til indrapportering til SLS. Da denne grænseflade netop er dedikeret til HR-Løn, forventes den ikke at kunne genbruges direkte til HR- Løsningen. Der er derfor behov for at opsætte en ny eller tilpasse eksisterende grænseflade til AdminDB, så den kan tilgås fra andre systemer, herunder HR- Løsningen. Denne løsning forventes fortsat at bygge på SQL-teknologi. Kunden er ansvarlig for denne opgave, og den forventes at blive gennemført i samarbejde med den kommende leverandør af HR-Løsningen og leverandøren af SLS AdminDB. 3C.5 Navision Stat (NS) Navision Stat er det økonomisystem, som hovedparten af de statslige virksomheder, herunder de selvejende, anvender. Navision Stat er en videreudvikling af økonomisystemet MS Dynamics NAV, tidligere kendt som Navision Attain, der igen er en videreudvikling af Navision Financials, som har været på markedet i flere år. Integrationen til Navision Stat foregår enten via GIS eller ØDUP. Nærmere information om GIS kan findes på dette link: http://www.modst.dk/systemer/navision-stat/generiskintegrationssnitflade ØDUP er beskrevet i afsnit 3C.3.4 under Generelt om integrationer. 3C.5.1 Registreringsrammen Navision Stat indeholder den økonomiske registreringsramme for statens Institutioner. Denne registreringsramme har en sammenhæng til bl.a. Institutio- Side 15 af 21
nernes organisering og lønnens kontering. Det vil derfor være relevant at kunne knytte elementer fra registreringsrammen til organisatoriske enheder og personer i HR-Løsningen. Registreringsrammen udstilles gennem ØDUP, hvor den kan afhentes som en XML-fil. Registreringsrammen består af finanskonti og et antal dimensioner og tilhørende dimensionsværdier. 3C.5.2 Medarbejderdata På nuværende tidspunkt oprettes nye medarbejdere i Navision Stat via SLS, men det er ønsket, at denne oprettelse fremover kommer til at ske via HR- Løsningen. De oplysninger der skal sendes til Navision, og som i dag bliver sendt fra SLS er oplysninger om den fysiske medarbejder, som kan have flere tilknyttede ansættelsesforhold. De oprettede medarbejdere kan internt i Navision Stat konverteres til kreditorer. 3C.6 Single-Sign-On (SSO) Single-Sign-On giver brugere af de tilsluttede systemer mulighed for kun at logge ind en enkelt gang, og derefter tilgå alle tilknyttede systemer. Kunden er i proces med at etablere en føderationsløsning, som giver Single Sign-On til Kundens kunderettede systemer. Når brugere tilgår den nye log-in side, initierer applikationen log-in via føderationsserveren med SAML 2.0 protokollen. SAML integrationen anvender den fællesoffentlige OIOSAML 2.0.9 standard i rollen som SAML Service Provider ved integration til føderationsserveren 1. Herefter foregår login som følger: 1. Der sendes et signeret SAML Authentication Request. 2. Der modtages et SAML Authentication Response fra føderationsserveren indeholdende en signeret SAML Assertion. 3. Systemet validerer den modtagne SAML Assertion. 4. Systemet skal ud fra brugernavn fra SAML Assertion (fx i Subject feltet eller i en attribut) og give brugeren adgang til systemet på baggrund af denne (dvs. uden at prompte for brugernavne og kodeord). 1 Det er ikke nødvendigt at medtage alle attributter fra OCES attributprofilen, men brugernavnet skal som minimum kunne overføres via Subject elementet i den SAML Assertion, der modtages fra Identity Provideren. Side 16 af 21
SSO-projektet er på nuværende tidspunkt kun i en tidlig fase, og der kan komme ændringer til ovenstående specifikationer. 3C.7 Integration til Active Directory (AD) HR-Løsningen bør understøtte integration med Active Directory hos Statens IT, med henblik på oprettelse, ajourføring og lukning af medarbejdere. Det vil desuden være hensigtsmæssigt at HR-Løsningen kan modtage retursvar med de oplysninger der oprettes i AD et. På nuværende tidspunkt anvendes Active Directory hos Statens IT udelukkende til håndtering af brugere på Statens ITs netværk og enheder. Ved oprettelse af ny medarbejder i Statens AD, anvendes som minimum følgende data (listen er ikke udtømmende da der er tale om manuel proces): - Ansættelsesdato - Styrelse/Institution - BrugerNavn, Fornavn, Efternavn - Initialer - Titel - Afd./Center/Kt./Enhed/Land - Oprettes pr.(dato) - Lokalenr. - Mobil - Oplysninger om ledelsesophæng Ved oprettelse i AD et oprettes medarbejders mail-adresse, unikt medarbejdernummer (såkaldt B-nummer) samt adgangskode. Det vil være hensigtsmæssigt at mail og unikt medarbejdernummer modtages i HR-Løsningen som retursvar fra AD et. Efter oprettelse modtager den oprettende leder en mail med B-nummer, samt en separat mail med password fra AD et. Ved ændringer og fratrædelser anvendes udover den overover nævnte data som minimum desuden: - Ændringsdato, Fratrædelsesdato Statens IT er påbegyndt arbejdet med at specificere en integrationsløsning til AD et (en IGA-løsning), baseret på webservices. Løsningen forventes implementeret hos Statens IT inden HR-Løsningen. Integrationen til Active Direc- Side 17 af 21
tory via en mulig kommende IGA-løsning formodes dermed at holde sig inden for de overordnede rammer beskrevet i dette dokument. I første omgang forventes oprettet webservice til at håndtere oprettelse, ajourføring og lukning af medarbejdere samt modtagelse af retursvar på brugere i Active Directory. På Institutioner som ikke anvender Statens ITs AD, er det ikke muligt at definere nærmere hvilken teknologi, funktionalitet og data der håndteres. Leverandøren af HR-Løsningen forpligtes ikke til at levere anden funktionalitet, end det, der er udviklet til integration med Statens IT. Enkelte Institutioner vil dog være i stand til at anvende denne funktionalitet til deres Lokale AD, hvilket de bør have adgang til. Statens IT har ca. 12.000 kunder, primært fordelt på 9 ministerier. 3C.8 Lokale fagsystemer Det er Kundens mål at stille Løsningens data til rådighed for Institutionernes Lokale fagsystemer via almindeligt anvendte protokoller. Lokale fagsystemer kan dække et væld af forskelligartede systemer fra Lokalt intranet eller AD til systemer der understøtter Institutionernes administration eller faglige opgaveudførelse. For at sikre, at der anvendes åbne og almindeligt anerkendte standarder er det afgørende at leverandøren overholder god praksis på markedet. Det vil derfor være ønskeligt, at der følges alment anerkendte retningslinjer og standarder som beskrevet i afsnit 3C.3. Det vil være Institutionernes ansvar at de kan hente data via de protokoller og formater data udstilles via i HR-Løsningen. Det er dog afgørende at HR- Løsningen kan differentiere adgange således at Institutionerne kun har adgang til at afhente egne data og eventuelt behøvede metadata. Det vil desuden være muligt for Institutionerne, efter aftale med Moderniseringsstyrelsen, at indlæse data fra Lokale fagsystemer i HR-Løsningen. Opsætningen af Lokale integrationer til indlæsning eller udlæsning af data i HR- Løsningen er ikke en del af de ydelser der er reguleret af Kontrakten og dens Bilag, og det vil derfor være ydelser som Institutionerne vil skulle tilkøbe som konsulentydelser jf. Bilag 11 Vederlag. 3C.8.1 Lokale ESDH-systemer Side 18 af 21
3C.9 CVR-registret Der er anskaffet en række ESDH-systemer af statens Institutioner som varetager journal-opgaverne. Systemerne er anskaffet Lokalt, og er derfor leveret af forskellige leverandører og af forskellige type. Det er desuden op til den Lokale Institution, hvilke integrationer der opsættes til ESDH-systemet og i det hele taget hvilke muligheder systemet indeholder herfor. HR-Løsningen forventes, at indeholde en række data/dokumenter som skal journaliseres, bl.a. til Dokumentation for personers ansættelsesforhold, ændringer af dette og øvrige hændelser i ansættelsesforløbet. Det vil være hensigtsmæssigt, hvis HR-Løsningen understøtter en overførsel til Lokale ESDHsystemer, for at lette opgaven mest muligt. Da en eventuel integration til ESDH-system vil være afhængigt af de Lokale forhold, antages det ikke at være en del af det et standard implementeringsforløb. Det vil dog være hensigtsmæssigt, hvis Institutionen har mulighed for at trække relevante data ud af Løsningen eller alternativt tilkøbe denne service hvis der er ønske herom. CVR er statens stamregister for virksomhedsoplysninger. Der kan søges på virksomheder og finde CVR-numre, adresser og virksomhedsform m.m. Almindelig information om CVR-registret kan findes her: https://datacvr.virk.dk/data/ 3C.10 CPR-registret I HR-Løsningen er der et behov for at kunne validere organisationsdata herunder lokation på Institutionerne. CVR-registret tilbyder en system-til-system adgangsløsning som tillader denne validering. Nærmere detaljer om denne løsning kan findes på nedenstående link: http://datahub.virk.dk/dataset/system-til-system-adgang-til-cvr-data CPR-registret er statens stamregister for personoplysninger. HR-Løsningen vil have behov for at kunne håndtere opslag i CPR-registret med henblik på validering af persondata. Ligeledes vil der være behov for at oprette og nedlægge abonnementer på CPR-numre. HR-Løsningen bør understøtte kommunikation med CPR-registret, baseret på CPR Direkte. Løsningen skal kunne håndtere opslag, samt oprettelse og nedlæggelse af abonnementer på CPR-numre. Side 19 af 21
HR-Løsningen bør efter nærmere fastsatte regler fjerne abonnementer på CPR-numre, når der ikke længere er behov for løbende at modtage hændelser på personen. HR-Løsningen må til enhver tid kun abonnere på CPR-numre på personer som er aktive. Nærmere detaljer omkring CPR Direkte kan findes på dette link: https://cpr.dk/kunder/offentlige-myndigheder/cpr-direkte-program-tilprogram/dokumentation-for-cpr-direkte-til-offentlige/ 3C.11 Statens Lokale Datavarehus (LDV) Statens Lokale Datavarehusløsning anvendes både til Statslig styring og til styring i de enkelte statslige og selvejende Institutioner. Datavarehusløsningen bygger på standard Microsoft SQL server teknologi. Under betegnelsen Statens Lokale Datavarehusløsning (LDV) er der flere Datavarehus løsninger. Der er et Datavarehus til centrale styringsbehov og flere Datavarehuse til styring i de enkelte Institutioner. Leverandøren af HR-Løsningen skal levere et samlet datadump af produktionsdata til LDV. Produktionsdata bør leveres så tæt som muligt i realtid. Moderniseringsstyrelsen udtrækker herefter de oplysninger der skal bruges fra datadumpet til LDV og opbygger rapporteringen herpå. Udtrækkende til LDV vil ske enten i realtid eller i natlige kørsler alt efter behovet for informationer. Den foretrukne integrationsløsning, som benyttes på andre af Kundens systemer er, at integrationen til LDV foregår via en Microsoft SQL Server leveret af Kunden, der fungerer som et spejl af HR-Løsningens database. Protokollen er baseret på SQL Database Mirroring. Dette spejl bør opdateres løbende nær realtid. Såfremt HR-Løsningen ikke er baseret på Microsoft SQL Server, bør leverandøren sikre, at den pågældende database-løsning kan levere den ønskede funktionalitet eller tilsvarende. Nærmere detaljer om LDV kan findes på systemets hjemmeside: http://www.modst.dk/systemer/oes-ldv Kunden er undervejs med et projekt som skal erstatte LDV med en dedikeret Business Intelligence løsning. Dette arbejde er imidlertid på nuværende tidspunkt i en for tidlig fase til at kunne definere integrationer nærmere. Side 20 af 21
3C.12 CAMPUS CAMPUS er Statens kompetence og læringsportal, indeholdende bl.a. e- læringskurser, administration af tilstedeværelseskurser samt medarbejderes læringshistorik. Oprettelse i CAMPUS sker i dag på baggrund af primært SLS, men fremadrettet ønskes oprettelsen at ske baseret på HR-Løsningen. Dette er for at sikre at en nyansat medarbejder ved jobstart kan anvende CAMPUS, da medarbejdere fra SLS først oprettes ved lønkørsel. HR-Løsningen bør kunne oprette, ajourføre og lukke medarbejdere i CAMPUS. Der antages ikke modtaget data tilbage fra CAMPUS, men der bør modtages retursvar på om de fremsendte oplysninger er accepteret. Der er ved at blive udviklet en webservice som skal overtage denne funktion, og som skal give mulighed for at oprette brugere løbende i CAMPUS. Nedenstående er de felter der kan overføres til CAMPUS. Bemærk at denne webservice er under udvikling, og der derfor kan komme ændringer som ikke nødvendigvis er registreret i nedenstående. - AfgangsAarsagskode - AfgangsDato - Akko (forklaring) - AnsaettelsesDato - BevillingsLoenramme () - CprNummer - Cvr - DelRegnskab - Efternavn - FinansieringsForm () - FoedselsDato - Fornavn - GruppeNummer () - Hovedansættelse () - Klasse () - Koen (Køn) - KommuneNr - OpdateringsForm () - Personalekategori (PKAT) - PersonaleNummer (Unikt medarbejder-id) - SeNummer - Stillingskode - UnderKonto Side 21 af 21