746.9 Udbygning af jobordre funktionalitet - 2023-1
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
STAR Projektleder (PL) | Forretningsanalytiker (FA) | STAR Release | Epic status | Eksterne snitflader |
---|---|---|---|---|
@Camilla Hagedorn Trolle | @Carsten Olsen | 2023-1 | 1.0 | KSS, A-kasser (f) |
Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)
Anvendes ved ændringer, der har betydning for eksterne.
Dato | Version | Hvem | Hvad er ændret? |
---|---|---|---|
10.05.2022 | 0.3 | Carsten Olsen | Opdelt i forhold til hvad der laves i 2022-3 (epic 746.7) og i 2022-4 denne epic (746.9) |
15.06.2022 | 0.3 | Knud | Det er under afklaring, om AC 746.7.3b kan udføres i 2022-3 (E 746.7) uden snitfladeændring - eller det skal afvente snitfladeændring i nærværende E 746.9. |
18.08.2022 | 0.3 | Knud | Kommentater indsat på baggrund af tlf meldinger fra KMD (vedr. jobtyper ad AC-1 / ikke alle typer giver mening - og vedr. permanente ordrer ad AC-10 / ønske om ny attribut frem for statuskode). Forretningsafklaringsmøde ønskes. |
22.09.2022 | 0.3 | Knud | Titel opdateret fra "... 2022-4" til ".... 2023-1" |
05.10.2022 | 0.3 | Carsten Olsen | Opdateret efter input fra KSS og STAR forretning og klar til tilsagnsproces |
07.10.2022 | 0.3 | Knud | Tilføjet (internt) AC-15 |
07.10.2022 | 0.5 | Carsten Olsen | Løftet til version 0.5 og fjerne kommentar |
05.01.2023 | 0.5 | Knud | Tilføjet FB https://manuscript.star.dk/f/cases/218334/CompanyRecruitmentService-Tovholder-kan-ikke-opdatere-en-formidling-p-en-jobordre under AC 11a. (Fjernet igen, da KSS melder at det ikke er et praktisk problem)
|
20-01-2023 | 1.0(/0.5) | Jesper | Løftet til 1.0 ift. alt hvad der berører eksterne. Der udestår mindre interne opgaver som ikke berører eksterne eller test |
06-02-2023 | 1.0 | Carsten Olsen | Løftet til 1.0 |
Interne links (indhold i links ikke relevant for eksterne)
https://starwiki.atlassian.net/browse/DS-8943
https://starwiki.atlassian.net/browse/DS-11964
https://starwiki.atlassian.net/browse/BI-2072
https://starwiki.atlassian.net/browse/BVL-516
Indholdsfortegnelse
- 1 Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)
- 2 Indholdsfortegnelse
- 3 Afgrænsning af epic
- 4 Oversigt over berørte webservices
- 5 Beskrivelse af epic
- 5.1 Baggrund
- 5.2 Regler
- 5.3 Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer
- 5.3.1 KSS
- 5.3.2 A-kasse
- 5.3.3 Logisk beskrivelse
- 5.4 Acc.kr. 746.9.1 DFDG understøtter vedr. jobordrer flere jobtyper / ansættelsesbetingelser end ordinære job (f.eks. fleksjob, lærling, jobrotation)
- 5.5 Acc.kr. 746.9.2 DFDG understøtter vedr. jobordrer angivelse af max antal arbejdstimer ved deltidsjob
- 5.6 746.9.3 A DFDG understøtter vedr. jobordrer arbejdstid på dagen/ugen (fx morgen, dag, aften, nat, weekend)
- 5.7 746.9.3 B Kommentar ifm statusskift på kandidat, bliver ikke udstillet til rekrutteringsfællesskabet
- 5.8 746.9.4 Ifm. udbygningen omlægges DFDGs snitflader fra SOAP til REST
- 5.8.1 Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
- 5.8.1.1 CreateJobordre (POST /v1/jobordre)
- 5.8.1.2 GetJobordre (Get /v1/jobordre)
- 5.8.1.3 UpdateJobordre (PUT /v1/jobordre)
- 5.8.1.4 CreateJobordreFormidling (POST /v1/jobordre/formidling)
- 5.8.1.5 GetJobordreForVirksomhed (GET/v1/jobordre/formidling{virksomhed})
- 5.8.1.6 GetJobordrePaaTypeOgStatus (GET/v1/jobordre/{jobordreType, jobordreStatusType})
- 5.8.1.7 UpdateJobordreStatus (PUT /v1/jobordre/status)
- 5.8.1.8 UpdateJobordreFormidling (PUT /v1/jobordre/formidling)
- 5.8.2 Virksomhedsindsats.Virksomhedsservice (2022-4)
- 5.8.3 WsrmMessageService (Version 11, 2022-2)
- 5.8.4 Virksomhedsindsats.CodeLists
- 5.8.4.1 Virksomhedsindsats.CodeListService.JobordreType [UDV]
- 5.8.4.2 Virksomhedsindsats.CodeListService.JobordreStatusType [UDV]
- 5.8.4.3 Virksomhedsindsats.CodeListService.JobordreSvarType [UDV]
- 5.8.4.4 Virksomhedsindsats.CodeListService.UgenligArbejdstidType [UDV]
- 5.8.4.5 Virksomhedsindsats.CodeListService.FormidlingshaendelsesType [UDV]
- 5.8.4.6 Virksomhedsindsats.CodeListService.FormidlingsstatusType [UDV]
- 5.8.4.7 Virksomhedsindsats.CodeListService.ArbejdstidsforholdType [UDV]
- 5.8.5 CodelistService (Version 5)
- 5.8.6 CompanyRecruitmentService (Version 4, 2022-3)
- 5.8.1 Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
- 5.9 746.9.5 CompanyRecruitmentInfo udgår af PersonStatusService og "flyttes" til ny REST service
- 5.10 746.9.6 LSS og Datakanon understøtter minimum de samme funktioner som i dag ift. dannelse af testdata og visning af formidlinger på den enkelte borger
- 5.10.1 Internt STAR acc.kri.
- 5.10.2 LSS (før ændring)
- 5.10.3 Datakanon (før ændring)
- 5.10.3.1 Ordreoprettelse
- 5.10.3.2 Oprettelse af event på ordren
- 5.11 746.9.7 DFDGs SystemAreaSubscriptionService eller tilsvarende kan fortsat anvendes til via LSS at "tænde"/"slukke" for det enkelte jobcenters tilslutning til jobordre-modtagelse
- 5.11.1 LSS (før ændring)
- 5.11.2 Løsningsmodel
- 5.12 746.9.10 Som STAR og jobcenter vil jeg gerne være sikker permanetene (langvarig) jobordre håndteres
- 5.12.1 Løsningsmodel mht. stående eller langvarig jobordre
- 5.12.2 Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
- 5.12.2.1 CreateJobordre (POST /v1/jobordre)
- 5.12.2.2 GetJoborder (Get /v1/jobordre)
- 5.12.2.3 UpdateJobordre (PUT /v1/jobordre)
- 5.12.2.4 GetJobordreForVirksomhed (GET/v1/jobordre/formidling{virksomhed})
- 5.12.2.5 GetJobordrePaaTypeOgStatus (GET/v1/jobordre/{jobordreType, jobordreStatusType})
- 5.12.2.6 Forretningsregler
- 5.12.3 Præcisering af forretningsflows
- 5.13 746.7.11a Ændret valideringsregler
- 5.13.1 Løsningsmodel
- 5.13.1.1 220234 - Manglende mulighed for genformidling af borger i CompanyRecruitment servicen
- 5.13.1.2 244512 - Interne tilbud i JobAG, som ikke er delt, kan ses i andre kommuner
- 5.13.1.3 223917 - Arbejdsgiver bliver notificeret omkring fjernede kandidater på CompanyRecruitment, som virksomheden aldrig har fået formidlet
- 5.13.1.4 218334 - CompanyRecruitmentService: Tovholder kan ikke opdatere en formidling på en jobordre
- 5.13.1 Løsningsmodel
- 5.14 746.9.14 Som sagsbehandler vil jeg have en mere differentieret årsag sat hvis en kandidat skifter status til "Kandidat fjernet - ikke mere relevant" eller "Ikke ansat af virksomheden"
- 5.15 746.9.15 Som landssupporter, tester og STAR-SPOC vil jeg i LSS kunne udsøge på virksomhedens CVR og p.nr. de ordrer, der er registreret på virksomheden og se indholdet i ordren
- 5.15.1 Løsningsmodel
- 6 Særlige krav til test
- 7 Konsekvenser for drift/idriftsættelse
- 8 Arkitektur- og implementeringsnoter
- 9 Husk GDPR stillingtagen
- 10
Afgrænsning af epic
Afgrænsning | ||
---|---|---|
Som en jobkonsulent vil jeg gerne kunne dele flere oplysningstyper om en jobordre og ordrer for andre jobtyper end ordinære job for at jeg effektivt kan samarbejde med andre jobcentre og a-kasser om formidling af job uanset, hvilket it-system den samarbejdende part anvender Bemærk det ønskede forretningsindhold er blevet opdelt i en 2022-3 (E 746.7) og nærværende 2023-1 (E 746.9) implementering | ||
Acceptkriterier | ||
Nr. | Beskrivelse | Relevant for (links nedenfor er interne links) |
746.9.1 | DFDG understøtter vedr. jobordrer kan have en følgende primære jobtyper ordinære job, fleksjob, lærling/elev eller IGU
(FB 231249 - Ændringsønske: Angivelse af om rekrutteringsanmodning er et småjob) | DFDG, JobAG, BI |
746.9.2 | DFDG understøtter vedr. jobordrer angivelse af max antal arbejdstimer ved deltidsjob | DFDG, JobAG - ingen udviklingsopgaver til DFDG eller JobAG |
746.9.3a | DFDG understøtter vedr. jobordrer angivelse af arbejdstidens placering på dagen/ugen (fx morgen, dag, aften, nat, weekend) | DFDG, JobAG https://starwiki.atlassian.net/browse/DS-7009 https://starwiki.atlassian.net/browse/DS-7966 https://starwiki.atlassian.net/browse/DS-7015 |
746.9.3b | Kommentar ifm statusskift på kandidat, bliver ikke udstillet til rekrutteringsfællesskabet (FB 243077) | DFDG, JobAG https://starwiki.atlassian.net/browse/DS-7966 |
746.9.4 | Ifm. udbygningen omlægges DFDGs snitflader fra SOAP til REST | DFDG, JobAG. BI https://starwiki.atlassian.net/browse/DS-7009 https://starwiki.atlassian.net/browse/DS-10337 https://starwiki.atlassian.net/browse/DS-8451 https://starwiki.atlassian.net/browse/DS-10700 https://starwiki.atlassian.net/browse/DS-8436 https://starwiki.atlassian.net/browse/DS-8682 https://starwiki.atlassian.net/browse/DS-7966 https://starwiki.atlassian.net/browse/DS-7015 https://starwiki.atlassian.net/browse/DS-10408 https://starwiki.atlassian.net/browse/DS-10411 https://starwiki.atlassian.net/browse/DS-8681 https://starwiki.atlassian.net/browse/DS-8680 https://starwiki.atlassian.net/browse/DS-8498 https://starwiki.atlassian.net/browse/BI-1917 https://starwiki.atlassian.net/browse/BI-1918 https://starwiki.atlassian.net/browse/BI-1920 https://starwiki.atlassian.net/browse/BI-1921 https://starwiki.atlassian.net/browse/BI-1922 https://starwiki.atlassian.net/browse/BI-1923 https://starwiki.atlassian.net/browse/BI-1940 https://starwiki.atlassian.net/browse/BI-1925 https://starwiki.atlassian.net/browse/BI-1924
|
746.9.5 | CompanyRecruitmentInfo udgår af PersonStatusService og "flyttes" til ny REST service | DFDG |
746.9.6 | LSS og Datakanon understøtter minimum de samme funktioner som i dag ift. dannelse af testdata og visning af formidlinger på den enkelte borger | DFDG |
746.9.7 | DFDGs SystemAreaSubscriptionService eller tilsvarende kan fortsat anvendes til via LSS at "tænde"/"slukke" for det enkelte jobcenters tilslutning til jobordre-modtagelse STAR (intern): OBS på Odsherred, der som eneste JC ikke kan modtage jobordrer i dag fra JobAG. AMK Øst spørger Odsherred om dette er en fejl…..KPP har efterfølgende fortalt, at de er kommet med! | DFDG, BI |
746.9.9 | JobAG anvender ny snitflade med nye jobtyper og flere felter, når arbejdsgivere opretter og redigere jobordrer | JobAG https://starwiki.atlassian.net/browse/BVL-655 https://starwiki.atlassian.net/browse/BVL-590 https://starwiki.atlassian.net/browse/BVL-591
|
746.9.10 | Som STAR og jobcenter vil jeg gerne være sikker på, at stående/langvarige jobordrer håndteres | DFDG, JobAG https://starwiki.atlassian.net/browse/DS-10337 https://starwiki.atlassian.net/browse/DS-7966 https://starwiki.atlassian.net/browse/DS-7015 https://starwiki.atlassian.net/browse/DS-10411 https://starwiki.atlassian.net/browse/BVL-688 |
746.9.11a | Forskellige FB'er og valideringer der kandiderer til løsning:
| DFDG, JobAG? |
746.9.14 | Som sagsbehandler vil jeg have en mere differentieret årsag sat hvis en kandidat skifter status til "Kandidat fjernet - ikke mere relevant" eller "Ikke ansat af virksomheden" | DFDG |
746.9.15 | Som landssupporter, tester og STAR-SPOC vil jeg i LSS kunne udsøge på virksomhedens CVR og p.nr. de ordrer, der er registreret på virksomheden og se indholdet i ordren | DFDG |
746.9.16 | CompanyRecruitmentService erstattes af Virksomhedsindsats.Jobordreservice. Aftageres adgang skal opdateres - orientér SF om dette i FB sag | DFDG |
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||||||
---|---|---|---|---|---|---|---|---|---|
746.9.1 | 746.9.2 | 746.9.3 | 746.9.4 | 746.9.5 | 746.7.8 | 746.9.10 |
| ||
KSS og jobcentre anvender ny REST-snitflade med nye jobtyper og nye "felter" | X | X | X | X | X | ||||
A-kasser, der (frivilligt) har taget CompanyRecruitmentService (SOAP) i brug overgår til ny REST-snitflade med nye jobtyper og nye "felter" | X | X | X | X | X | ||||
KSS og a-kasser læser ikke længere oplysninger om borgeres / medlemmers formidlinger i PersonStatusService, men i ny / anden Get-metode. | X | ||||||||
KSS udstiller i eget fagsystem om arbejdsgiver er oprettet som bruger af JobAG | X | Implementeret i 2022-3 i E 746.7 | |||||||
|
|
Andre kriterier for eksterne
Herudover tages i KSS efter nærmere aftale med egne kunder hånd om følgende, der er adresseret i henvendelserne fra rekrutteringsfællesskaberne på Sjælland (citat fra henvendelserne):
Schultz
"Tværkommunale udfordringer hos Schultz Fasit:
Jobcenter får ikke besked om status skift (formidling tilgængelig for virksomhed/ansat/Ikke ansat) på egne kandidater formidlet på ordrer, hvor andre jobcentre er tovholderjobcenter.
Bemærkningsfeltet på kandidatformidlinger slår ikke igennem ved formidling af kandidat og
statusskift (f.eks. årsag til ikke-ansat) på tværs af kommuner.Vi kan ikke se kontaktoplysninger (e-mail) på formidlende sagsbehandler fra Momentumkommuner
på kandidatformidlinger.Tovholder jobcenter fremgår ikke af jobordrer hvor jobcenter er Momentum kommune (er lovet
løst, men hvornår?)Ønske om ensartet PDF visning af jobordrer (Beliggenhed skal altid vise by og postnummer)"
KMD
"Tværkommunale udfordringer hos KMD Momentum:
Vi kan ikke se kontaktoplysninger (e-mail) på formidlende sagsbehandler fra FASIT-kommuner på
kandidatformidlinger.CV´er på Jobordrer står ALLE som ”ikke godkendt”; enten skal der stå om de er søgbare eller også
skal feltet fjernes (da det forvirrer billedet)Der er felter i jobordremodulet i Momentum, som ikke findes på DFDG. Disse felter kommunikeres
aldrig til hverken Momentum eller FASIT kommuner. Det drejer sig bl.a. om felterne:
Ansættelsesbetingelser (f.eks. Fleksjob), arbejdstid (f.eks. dag, aften, weekend) og max timer på
deltidsjob. Hvordan løses denne problematik?ALLE kommuner ØST for Storebælt skal have alle 3 delingsknapper på rekrutteringsfællesskaberne: NRS, HRS, JRS. Derudover laver det enkelte jobcentre selv delinger efter aftale med KMD (kommunerne i HRS og NRS har én gang for flere år siden betalt KMD for at udvikle en HRS og NRS delingsknap (STÆR løsningen).
På jobordre dashboardet skal det være muligt at filtrere på flere primære myndigheder samtidigt. Dette for at kunne lave dashboards/jobordrelister med jobordrer, hvor flere forskellige jobcentre er tovholder/primær myndighed.
Det skal være muligt at lave faste dashboards på jobordrer, som kan deles på team niveau (standardlister på f.eks. fleksjob, der kan tildeles fleksjobgruppen). Pt. skal hver enkelt medarbejder i det enkelte jobcenter individuelt selv filtrere på jobordrer og lave egne dashboards, lister med jobordrer.
Jobordrer der har overskreden formidlingsfrist/behandlingsfrist, skal forsvinde fra dashboardet automatisk indtil de redigeres og opdateres med korrekt dato (således at alle åbne jobordrer til enhver tid er aktuelle og indenfor aktuel behandlingsperiode)
Det skal være muligt delvist at kunne maskere arbejdsadresse, så man f.eks. kun kan se by og postnummer ved dannelse af PDF (Og korrekt kommune ved dannelse af PDF jobordre. Pt. viser den altid kommune, hvor jobcentret ligger)"
Oversigt over berørte webservices
Manuel oversigt som er synlig for eksterne
Links i listen virker kun med STAR Jira konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår i tabellen.
(kopiér og indsæt manuelt i tabellen)
Summary | Varslingstype | Varslingsnote | Eksterne Snitflader | Interne Snitflader | Project |
---|---|---|---|---|---|
CodelistService (Version 5).CandidateRecruitmentStatusTypeIdentifier | Andet | Af hensyn til WSRM beskeder beholdes og udvides DFDG classic kodelister | A-kasse(f), Andre, KSS | JobAG | D+S |
CodelistService (Version 5).CompanyRecruitmentEventActionTypeIdentifier | Andet | Af hensyn til WSRM beskeder beholdes DFDG classic kodelister | A-kasse(f), Andre, KSS | JobAG | D+S |
CodelistService (Version 5).CompanyRecruitmentStatusTypeIdentifier | Andet | Af hensyn til WSRM beskeder beholdes DFDG classic kodelister | A-kasse(f), Andre, KSS | JobAG | D+S |
CodelistService (Version 5).CompanyRecruitmentStatusTypeIdentifier | Andet | Af hensyn til WSRM beskeder beholdes DFDG classic kodelister | A-kasse(f), Andre, KSS | JobAG | D+S |
CodelistService (Version 5).CompanyRecruitmentTypeIdentifier | Andet | Af hensyn til WSRM beskeder beholdes og udvides DFDG classic kodelister | A-kasse(f), Andre, KSS | JobAG | D+S |
Andet | Af hensyn til WSRM beskeder beholdes DFDG classic kodelister | A-kasse(f), Andre, KSS | JobAG | D+S | |
Udgået | Erstattes af ny REST service | A-kasse(f), Andre, KSS | JobAG | D+S | |
Ny | Ny kodeliste | A-kasse(f), Andre, KSS | JobAG | D+S | |
Virksomhedsindsats.CodeListService.FormidlingshaendelsesType | Ny | Afløser CompanyRecruitmentEventActionTypeIdentifier | A-kasse(f), Andre, KSS | JobAG | D+S |
Ny | Nye værdier og afløser CandidateRecruitmentStatusTypeIdentifier | A-kasse(f), Andre, KSS | JobAG | D+S | |
Ny | Afløser CompanyRecruitmentStatusTypeIdentifier | A-kasse(f), Andre, KSS | JobAG | D+S | |
Ny | Afløser CompanyRecruitmentRespondTypeIdentifier | A-kasse(f), Andre, KSS | JobAG | D+S | |
Ny | Nye jobordretyperkodeliste og afløser CompanyRecruitmentTypeIdentifier | A-kasse(f), Andre, KSS | JobAG | D+S | |
Ny | Afløser WeeklyWorkTimeTypeIdentifier | A-kasse(f), Andre, KSS | JobAG | D+S | |
Virksomhedsindsats.JobordreService (Version 1).CreateJoborder (POST /v1/jobordre) | Ny | Ny REST udgave af CreateCompanyRecruitment | A-kasse(f), Andre, KSS | BI, JobAG | D+S |
Ny | Ny REST udgave af CreateCompanyRecruitmentEvent | A-kasse(f), Andre, KSS | JobAG | D+S | |
Ny | Ny REST udgave af GetCompanyRecruitmentsOnCompany | A-kasse(f), Andre, KSS | JobAG | D+S | |
Virksomhedsindsats.JobordreService (Version 1).GetHistoriskeJoborder (Get /v1/jobordre/historik) | Ny | Ny REST udgave af GetCompanyRecruitment med historik | A-kasse(f), Andre, KSS | JobAG | D+S |
Virksomhedsindsats.JobordreService (Version 1).GetJoborder (Get /v1/jobordre) | Ny | Ny REST udgave af GetCompanyRecruitment dog uden historik | A-kasse(f), Andre, KSS | JobAG | D+S |
Ny | Ny REST udgave af GetCompanyRecruitments | A-kasse(f), Andre, KSS | N/A | D+S | |
Ny | Ny REST udgave af UpdateCandidateOnCompanyRecruitmentEvent | A-kasse(f), Andre, KSS | JobAG | D+S | |
Virksomhedsindsats.JobordreService (Version 1).UpdateJobordreStatus (PUT /v1/jobordre/status) | Ny | Ny REST udgave af SetCompanyRecruitmentStatus | A-kasse(f), Andre, KSS | JobAG | D+S |
Virksomhedsindsats.JobordreService (Version 1).UpdateJoborder (PUT /v1/jobordre) | Ny | Ny REST udgave af UpdateCompanyRecruitment | A-kasse(f), Andre, KSS | JobAG | D+S |
Ny | Ny REST udgave af GetCompanyJobcenterAffiliation | A-kasse(f), Andre, KSS | JobAG | D+S | |
WsrmMessageService (Version 11).GetCompanyRecruitmentVersion4 | Andet | WSRM uændret | A-kasse(f), KSS | N/A | D+S |
WsrmMessageService (Version 11).GetCompanyRecruitmentEventVersion3 | Andet | WSRM uændret | A-kasse(f), KSS | N/A | D+S |
Automatisk oversigt
Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.
Beskrivelse af epic
Baggrund
Skriftlige henvendelser til STAR, KMD og Schultz fra de tre rekrutteringsfællesskaber Øst for Storebælt:
Jobcentrenes Rekrutteringsservice Sjælland (JRS – 17 kommuner)
Hovedstadens Rekrutteringsservice (HRS – 19 kommuner) og
Nordsjællands Rekrutteringsservice (NRS – 9 kommuner)
Regler
Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.
Databekendtgørelsens kapitel om jobordrer vil blive opdateret svarende til de nye jobtyper og nye felter.
Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer
Her beskriver PO overordnet, hvordan epic'en forventes at påvirke aftagerne. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.
KSS
KSS vil skulle ibrugtage ny REST service for at registrere og indberette jobordrer til DFDG, herunder med anvendelse af felter/oplysningstyper, som evt. ikke hidtil har været anvendt i det pågældende KSS.
Oplysninger om formidlinger på den enkelte borger kan ikke fremover læses i PersonStatusService, men skal læses i en anden service.
Eksisterende WSRM-versioner vedr. jobordrer og formidlinger vil skulle anvendes.
A-kasse
Den eller de (få) a-kasser, der anvender CompanyRecruitmentService (SOAP) vil skulle ibrugtage ny REST service for at registrere og indberette jobordrer til DFDG, herunder med anvendelse af felter som evt. ikke hidtil har været anvendt i det pågældende a-kasse.
Oplysninger om formidlinger på den enkelte borger kan ikke fremover læses i PersonStatusService, men skal læses i en anden service.
Eksisterende WSRM-versioner vedr. jobordrer og formidlinger vil skulle anvendes.
Logisk beskrivelse
For yderlige beskrivelse se Formidling af ordinært job m.v. - efter 2022-3.
Acc.kr. 746.9.1 DFDG understøtter vedr. jobordrer flere jobtyper / ansættelsesbetingelser end ordinære job (f.eks. fleksjob, lærling, jobrotation)
Løsningsmodel
DFDG opretter de nye primære typer for fremadrette anvendelse
Bemærk det er kun ordinært job (Id 1) der vises for virksomheden på JobAG. Fleksjob (Id 3), lærling/elev (2), IGU (Id 4) anvendes og deles alene internt mellem Jobcentre/a-kasser/rekrutteringsfælleskaberne og vises således ikke for arbejdsgivere på JobAGDFDG opretter en kollektion hvor en subtype kan tilføjes
Er der eksisterende jobordre allerede registreret i DFDG, som reelt er en af de nye type, kan/bør KSS opdatere typen. DFDG laver ikke konvertering.
Fleksjob, lærling/elev, IGU undestøttes også i regi af VITAS og det dér den primære sagsbehandling sker.
VirksomhedsIndsats.CodeListService.Jobordretype
(CompanyRecruitmentTypeIdentifier)
For at håndtere flere jobtyper udvides kodelisten
Identifikator | Navn | Beskrivelse | Startdato | Slutdato |
---|---|---|---|---|
1 | Ordinært job | Henvendelse om formidling af arbejdskraft til ordinære timer | 01-06-2016 | 01-07-2100 |
2 | Lærlinge og elevjob | Lærlinge og elevjob herunder også voksenlærling/voksenelev | 01-11-2022 | 01-07-2100 |
3 | Fleksjob | Fleksjob | 01-11-2022 | 01-07-2100 |
4 | IGU-ansættelse | Uddannelse - borgere som har en IGU-aftale (IntegrationsGrundUddannelse) | 01-11-2022 | 01-07-2100 |
Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
(Se Virksomhedsindsats.JobordreService (CompanyRecruitmentService) (2022-4) for samlet beskrivelse af forretning, ændret/ny forretning er pt med grøn tekst)
Forretningsregler (nye) for flere detaljer se snitfladebeskrivelse
Se Virksomhedsindsats.JobordreService (CompanyRecruitmentService) (2022-4) pt den grønne tekst
Typerne (jobordreType) Lærlinge og elevjob (Id 2), Fleksjob (Id 3) og IGU-ansættelse (Id 4) anvendes kun internt mellem myndigheder. Virksomheder/arbejdsgivere har ikke adgang til disse via JobAG.
Virksomheder kan fra JobAG (som hidtil) kun oprette Typen (jobordreType) Ordinær job (Id 1 ).
Forretningsmæssigt anvende jobordertypen (jobordreType) til at angive hvilken r type jobordren er. Her kan sagsbehandler vælge mellem alle værdier Ordinær job (Id 1), Lærlinge og elevjob (Id 2), Fleksjob (Id 3) eller IGU-ansættelse (Id 4) og hvor det kun er Ordinær job (Id 1), der er tilgængelig for virksomheder på JobAG.
Acc.kr. 746.9.2 DFDG understøtter vedr. jobordrer angivelse af max antal arbejdstimer ved deltidsjob
Løsningsmodel
Forretningen beholdes uændret. Hvor:
Virksomhedsindsats.CodeLists
Virksomhedsindsats.CodeListService.UgenligArbejdstidType [UDV]
I dag kan som strukturerede data angives WeeklyWorkTimeTypeIdentifier, der har dette udfaldsrum:
Identifikator | Navn | Beskrivelse | Startdato | Slutdato |
---|---|---|---|---|
1 | Fuldtid | Fuldtid, 37 timer pr. uge | 01-10-2014 | 01-07-2100 |
2 | Deltid | Deltid, mellem 1 og 36 timer pr uge | 01-10-2014 | 01-07-2100 |
3 | Ikke angivet | Ikke angivet | 01-10-2014 | 23-03-2015 |
Herudover kan som i eksisterende SOAP-snitflade angives det faktiske antal timer pr. uge (HoursPerWeek).
Element | Type | Detaljer | Forekomst | Beskrivelse |
---|---|---|---|---|
- ugenligArbejdstidType (WeeklyWorkTimeTypeIdentifier) | Virksomhedsindsats.CodeListService.UgenligArbejdstidType [UDV] | 0 - 1 | Hvorvidt jobordre er fuldtid eller deltid. | |
- timerPrUge (HoursPerWeek) | int | MinInclusive: 0 | 0 - 1 | Samlet antal timer der tilbydes i hele timer. |
746.9.3 A DFDG understøtter vedr. jobordrer arbejdstid på dagen/ugen (fx morgen, dag, aften, nat, weekend)
Løsningsmodel
Der laves en liste hvor arbejdstid på dagen kan angives (ArbejdstidsforholdType)
Identifikator | Navn | Beskrivelse | Startdato | Slutdato |
---|---|---|---|---|
1 | Normal arbejdstid | Jobbet er indenfor normal arbejdstid | 01-11-2022 | 01-07-2100 |
2 | Morgenarbejde | Jobbet er primært (eller indeholder) morgenarbejde | 01-11-2022 | 01-07-2100 |
3 | Aftenarbejde | Jobbet er primært (eller indeholder) aftenarbejde | 01-11-2022 | 01-07-2100 |
4 | Natarbejde | Jobbet er primært (eller indeholder) natarbejde | 01-11-2022 | 01-07-2100 |
5 | Weekendarbejde | Jobbet er primært (eller indeholder) weekendarbejde | 01-11-2022 | 01-07-2100 |
6 | Skiftende arbejdstid | Jobbet indeholde skiftende arbejdstider | 01-11-2022 | 01-07-2100 |
Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
(Se Virksomhedsindsats.JobordreService (CompanyRecruitmentService) (2022-4) for samlet beskrivelse af forretning, ændret/ny forretning er p.t. med grøn tekst)
Følge nye felter er medtaget i dette acc. kri.
ArbejdstidsforholdType (der er en kollektion af Virksomhedsindsats.CodeListService.ArbejdstidsforholdType)
Forretningsregel
Type af arbejdstid (ArbejdstidsType) skal default sættes til "Normal arbejdstid", hvis intet andet er oplyst
746.9.3 B Kommentar ifm statusskift på kandidat, bliver ikke udstillet til rekrutteringsfællesskabet
Samtidig løsning af FB 243077 (se https://starwiki.atlassian.net/browse/DS-7752 - internt link)
Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
GetJoborder (Get /v1/jobordre),
Felter
opdateringsKommentar - "Årsag til at kandidat opdateres."
gøre tilgængelig for alle aftagere på snitfladen.
746.9.4 Ifm. udbygningen omlægges DFDGs snitflader fra SOAP til REST
For at undgå en opgradering af SOAP-snitflade til ny SOAP-version på end-of-life teknologi, for forholdsvis kort efter at skulle opgradere til REST-snitflade, foretages samtidig med nærværende udbygning af jobordrer tillige en omlægning til REST.
Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
Følge nye felter er medtaget
arbejdstidsType
opdateringsKommentar (eksisterende med medtages på flere get-metoder)
langvarigJobordre
CreateJobordre (POST /v1/jobordre)
GetJobordre (Get /v1/jobordre)
UpdateJobordre (PUT /v1/jobordre)
CreateJobordreFormidling (POST /v1/jobordre/formidling)
GetJobordreForVirksomhed (GET/v1/jobordre/formidling{virksomhed})
GetJobordrePaaTypeOgStatus (GET/v1/jobordre/{jobordreType, jobordreStatusType})
UpdateJobordreStatus (PUT /v1/jobordre/status)
UpdateJobordreFormidling (PUT /v1/jobordre/formidling)
Metoder ændret til dansk og ovenstående nye felter tilføjes
Virksomhedsindsats.Virksomhedsservice (2022-4)
Service, der giver stamoplysninger om en virksomhed
GetVirksomhedJobcenterTilknytning (GET/v1/VirksomhedJobcenterTilknytning/{CVR-nummer, P-nummer})
Flyttes ud en selvstændig service ændret til dansk og ingen nye felter. Ingen forretningsændringer.
Forretningsregler (nye/ændret)
Se Virksomhedsindsats.JobordreService (CompanyRecruitmentService) (2022-4) pt den grønne tekst
DFDG løsningsmodel
Der rejses events på jobordre og et events formidling (Intern kommentar: DFDG skal vurderer konkret model om det er generisk silo EB besked eller specifik jobordre besked)
DFDG classic abonnerer på event og sende GetCompanyRecruitmentEventVersion3 og WsrmMessageService (Version 11, 2022-2)#GetCompanyRecruitmentVersion4 ud som hidtid
WsrmMessageService (Version 11, 2022-2)
GetCompanyRecruitmentEventVersion3 og GetCompanyRecruitmentVersion4
I kontekst af denne epic overgåes ikke til nye WSRM beskeder GetCompanyRecruitmentEventVersion3 og WsrmMessageService (Version 11, 2022-2)#GetCompanyRecruitmentVersion4 bibeholdes uændret. Omlægning til tynde vil ske senere i forbindelse med modernisering at STAR DFDG platform.
Bemærk: WSRM udvides ikke med nye attributter, da STAR senere overgår til tynde webservicebeskeder (Ny WSRM model).
Virksomhedsindsats.CodeLists
Virksomhedsindsats.CodeListService.JobordreType [UDV]
Flyttet fra CompanyRecruitmentTypeIdentifier 1 til 1 plus og nye værdier
Virksomhedsindsats.CodeListService.JobordreStatusType [UDV]
Flyttet fra CompanyRecruitmentStatusTypeIdentifier 1 til 1
Virksomhedsindsats.CodeListService.JobordreSvarType [UDV]
Flyttet fra CompanyRecruitmentRespondTypeIdentifier 1 til 1
Virksomhedsindsats.CodeListService.UgenligArbejdstidType [UDV]
Flyttet fra WeeklyWorkTimeTypeIdentifier 1 til 1
Virksomhedsindsats.CodeListService.FormidlingshaendelsesType [UDV]
Flyttet fra CompanyRecruitmentEventActionTypeIdentifier 1 til 1
Virksomhedsindsats.CodeListService.FormidlingsstatusType [UDV]
Flyttet fra CandidateRecruitmentStatusTypeIdentifier 1 til 1 plus ny værdi
Virksomhedsindsats.CodeListService.ArbejdstidsforholdType [UDV]
Ny kodeliste
CodelistService (Version 5)
Af hensyn til WSRM beskeder beholdes og evt. udvides DFDG classic kodelister
CompanyRecruitmentTypeIdentifier
Udvid med indhold i Virksomhedsindsats.CodeListService.JobordreType [UDV]
CompanyRecruitmentStatusTypeIdentifier
Ingen udvidelser.
CompanyRecruitmentStatusTypeIdentifier
Ingen udvidelser.
WeeklyWorkTimeTypeIdentifier
Ingen udvidelser.
CompanyRecruitmentEventActionTypeIdentifier
Ingen udvidelser.
CandidateRecruitmentStatusTypeIdentifier
Udvid med indhold i Virksomhedsindsats.CodeListService.FormidlingsstatusType [UDV]
CompanyRecruitmentService (Version 4, 2022-3)
Udgår
Bemærk: Da der sker forretningsmæssig ændringer er det ikke muligt at forlænge levetiden på den eksisterede SOAP service.
746.9.5 CompanyRecruitmentInfo udgår af PersonStatusService og "flyttes" til ny REST service
Løsningsmodel
CompanyRecruitmentInfo i PersonStatusService (version 20) vil returnere et tomt resultat
Der etableres en ny statusservice i Virksomhedsindsats
PersonStatusService (Version 20, 2021-3)
GetVariablePersonStatus
CompanyRecruitmentInfo i PersonStatusService (version 20) vil returnere et tomt resultat.
Virksomhedsindsats.PersonStatusService [UDV] (Version 1, 2022-3)
GetPersonStatus (GET /v1/personstatus{personnummer})
Status på borger i forbindelse med virksomhedsindsats
Formidlinger på en borger / et medlem
746.9.6 LSS og Datakanon understøtter minimum de samme funktioner som i dag ift. dannelse af testdata og visning af formidlinger på den enkelte borger
Internt STAR acc.kri.
LSS (før ændring)
Jobordrer hvorpå en borger er formidlet vises under Formidlinger
Datakanon (før ændring)
Ordreoprettelse
Flyt til ny snitflade CreateJobordre (POST /v1/jobordre)
Kan vælge de nye jobordretype i "type af henvendelse"
Kan vælge den nye status i "Status på henvendelse"
Kan angive ny liste med arbejdstidsforhold i "Arbejdsforhold"
Kan vælge ny boolean om udenlandsk arbejdskraft ønskes i "Udenlandsk arbejdskraft"
Oprettelse af event på ordren
Flyt til ny snitflade CreateJoborderFormidling (POST /v1/jobordre/formidling)
Opdatering af event på ordren
Flyt til ny snitflade UpdateJobordreFormidling (PUT /v1/jobordre/formidling)
746.9.7 DFDGs SystemAreaSubscriptionService eller tilsvarende kan fortsat anvendes til via LSS at "tænde"/"slukke" for det enkelte jobcenters tilslutning til jobordre-modtagelse
LSS (før ændring)
Løsningsmodel
DFDG udstiller en event på ændringer i systemtilmeldinger Modtagne events i Virksomhedsindsats
Den nye Virk-Indsats silo abonner på denne event
BI loader eksisterende data til Virk-Indsats silo
Bemærk SystemAreaSubscriptionService logikken burde ligge i en tekniksilo, men da denne silo ikke eksisterer p.t. er flytning udenfor scope af denne epic og kan tage i forbindelse med modreniseringsprojektet.
Bemærk: der er afklaret det stadig er relevant med systemtilmeldinger
746.9.10 Som STAR og jobcenter vil jeg gerne være sikker permanetene (langvarig) jobordre håndteres
Forretningsmæssig er der jobordre, der er stående eller langvarige, dvs. at virksomheden løbende har behov for at få formidlet den i jobordren angivende arbejdskraft. Dette forhold understøttes ikke rigtigt i den nuværende løsningsmodel. Ligeledes kan der være tilfælde, hvor jobordre ønskes genanvendt, dette er håndteret delvist, men kunne smidiggøres.
Løsningsmodel mht. stående eller langvarig jobordre
Der etableres et felt (langvarigJobordre), hvor virksomhed eller sagsbehandler kan markerer, at en jobordre er af en type der er “stående”/langvarig.
Virksomhedsindsats.JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-4)
CreateJobordre (POST /v1/jobordre)
GetJoborder (Get /v1/jobordre)
UpdateJobordre (PUT /v1/jobordre)
GetJobordreForVirksomhed (GET/v1/jobordre/formidling{virksomhed})
GetJobordrePaaTypeOgStatus (GET/v1/jobordre/{jobordreType, jobordreStatusType})
Forretningsregler
Se Virksomhedsindsats.JobordreService (CompanyRecruitmentService) (2022-4) pt den grønne tekst
Stående/langvarige jobordrer, (hvor langvarigJobordre er TRUE) holdes åben, i princippet uendeligt, da virksomheden løbende vil kunne aftage arbejdskraft af den pågældende type. For stående/langvarige jobordre gælder:
senesteSvarDato skal ikke angives (skal være Null)
maxAntalKandidater skal ikke angives (skal være Null)
forventetAnsættelsesdato skal ikke angives (skal være Null)
jobordreAntalDage skal ikke angives (skal være Null)
De øvrige forretningsregler ændres ikke ved en Stående/langvarige jobordre
DFDG vil dog ikke lave valideringer for dette.
En sådan stående/langvarig jobordre betragtes forretnings- og opgørelsesmæssigt som rækkes af individuelle formidlinger, da de anses for små selvstændige jobordre inden i den stående/langvarige jobordre.
Præcisering af forretningsflows
Gentagende ens jobordre - virksomhed har et behov der opstår med jævne mellemrum
I de tilfælde hvor en virksomhed gentagende gange har det samme rekrutteringsbehov, men hvor der ikke er tale om en stående/langvarig åben jobordre, er tre arbejdsgange muligt:
Nyoprettelse - eksisterende arbejdsgang
Genoplivning af eksisterende - ny arbejdsgang, der måske kun er relevant på JobAG
Kopiering af eksisterende - ny arbejdsgang
1. Nyoprettelse - eksisterende arbejdsgang
En virksomhed eller et jobcenter kan altid oprette en ny jobordre også selvom rekrutteringsbehovet allerede eksisterer i en tidligere jobordre. Hvis en ny jobordre oprettes, får man et helt nyt forløb.
Denne model har dog et par ulemper:
Alle oplysninger skal genindtastes (med mindre Jobcentret har etableret en kopifunktion)
Sagsbehandler/tovholder kan ikke se tidligere formidlede kandidater, og skal dermed både se på, om der er kandidater fra tidligere, der stadig er relevante eller om der er kandidater, der allerede er frasorteret f.eks. af tovholder selv eller af virksomhed. Dermed risikerer man, at der formidles borgere, der allerede har være i proces.
2. Genoplivning af eksisterende - ny arbejdsgang
Bedre understøttelse af at eksisterende jobordre genanvendes. I dag er det muligt af skifte status på en "Lukket" eller "Midlertidig inaktiv" tilbage til en "Åben" jobordre, men DFDG gør ingenting for at validere oplysningerne i den genoplivede jobordre.
Her vil tidligere formidlinger kunne ses og kandidater, der ellers er afvist i forbindelse med en tidligere behandling, kan ses af sagsbehandler, og virksomheden får således ikke genhenvist kandidater, de ikke er interesseret i.
Hvis serviceaftager vil genoplive, dvs. en jobordre skifter jobordrestatus fra "Lukket" eller til "Åben", skal serviceaftager før eller ved status skift sikre at:
Hvis seneste senesteSvarDato er i dag eller nærmeste fremtid skal denne justeres eller fjernes
Hvis seneste forventetAnsættelsesdato er i dag eller nærmeste fremtid skal denne justeres eller fjernesHvis der er formidlet kandidater på jobordren, når jobordrestatus skiftes, så:
Hvis kandidat har status "Formidling afventer godkendelse (Id 1)" Se om kandidaten stadig har en åben kontaktgruppe.
Hvis borger har det, gøres ingenting ved kandidaten. Hvis ikke, sættes formidlingsstatus til "Kandidat fjernet - ikke mere relevant" med formidlingskommentar (opdateringsKommentar) "Borger fjernet i forbindelse med genaktivering af jobordre, da borger ikke længere er til rådighed for formidling""Formidling tilgængelig for virksomhed" (Id 2)
Hvis borger har det, og det er mindre en X (7) dage siden jobordren blev sat "Lukket", gøres ingenting, hvis det er mere x (7) dage sættes formidlingsstatus "Formidling afventer godkendelse (Id 1)", da tovholder lige igen skal se på kandidaten (denne regel er for at undgå problemer, hvis jobordre ved en fejl lukkes). Hvis ikke sættes formidlingsstatus til "Kandidat fjernet - ikke mere relevant" (Id 3) med formidlingskommentar (opdateringsKommentar) "Borger fjernet i forbindelse med genaktivering af jobordre, da borger ikke længere er til rådighed for formidling"
En sådan genoplivning af en jobordre betragtes som en ny jobordre, hvis den er genoplivet efter mere end X (7) dage.
3. Kopiering
Her renses tidligere formidlinger væk og man starter på en frisk, svarende til, at man laver en nyoprettelse, hvor relevante data medtages fra en eksisterende jobordre. DFDG understøtter ikke kopiering på JobAG, men KSS kan af egen drift stille denne funktionalitet til rådighed for Jobcentret.
746.7.11a Ændret valideringsregler
Løsningsmodel
220234 - Manglende mulighed for genformidling af borger i CompanyRecruitment servicen
Dette burde kunne lade sig gøre allerede ud fra eksisterende dokumentation
Det er ikke muligt at skifte status på en fjernet borger. Er en borger fjernet ved en fejl, kan borger formidles igen som en normal formidling.
Hvis der er en fejl i forhold til dette skal det fikses, så det er muligt at formidle en borger igen såfremt borgers tidligere er formidlingsstatus er "Kandidat fjernet - ikke mere relevant" (Id 3), "Ansat af virksomheden" (Id 4), "Ikke ansat af virksomheden" (Id 5) eller "Formidlingsresultat ukendt" (Id 6).
244512 - Interne tilbud i JobAG, som ikke er delt, kan ses i andre kommuner
Dette burde kunne lade sig gøre allerede ud fra eksisterende dokumentation
Hvis jobordren sættes til Intern (RecruitmentIsInternal=true) er den kun redigerbar for de primære rekrutteringsmyndigheder, ansvarligt jobcenter og eventuelt tovholder-jobcenter. Eventuelle jobcentre med formidlede borgere kan se den, men ikke opdatere.
Hvis rekrutteringen er intern, filtreres output så kalder kun modtager de rekrutteringer som han har rettighed til at se.
223917 - Arbejdsgiver bliver notificeret omkring fjernede kandidater på CompanyRecruitment, som virksomheden aldrig har fået formidlet
Der laves en ny regel for udsendelse af beskeder til virksomheden
Der sendes ikke besked hvis formidlingsstatus ændres til "Kandidat fjernet - ikke mere relevant" (Id 3) og den forgående formidlingsstatus har været <> "Formidling tilgængelig for virksomhed" (Id 2)
218334 - CompanyRecruitmentService: Tovholder kan ikke opdatere en formidling på en jobordre
En tovholder kan i dag ikke opdatere en formidling på en jobordre med CreateCompanyRecruitmentEvent eller UpdateCandidateOnCompanyRecruitmentEvent medmindre denne er tilføjet som primær myndighed. Det gøres muligt.
746.9.14 Som sagsbehandler vil jeg have en mere differentieret årsag sat hvis en kandidat skifter status til "Kandidat fjernet - ikke mere relevant" eller "Ikke ansat af virksomheden"
Baggrund
For at forbedre opfølgningen på formidlingerne og give sagsbehandler m.v. mere præcise årsager på formidlingeresultatet på en borger udvides udfaldsrummet jvf. nedenstående kodeliste.
Virksomhedsindsats.CodeListService.FormidlingsstatusType [UDV]
Identifikator | Navn | Beskrivelse | Startdato | Slutdato |
---|---|---|---|---|
1 | Formidling afventer godkendelse | Borgers formidling til virksomhed afventer tovholders godkendelse | 01-11-2016 | 01-07-2100 |
2 | Formidling tilgængelig for virksomhed | Borgers formidling er tilgængelig for virksomhed | 01-11-2016 | 01-07-2100 |
3 | Kandidat fjernet - ikke mere relevant | Borger er ikke længere til rådighed, fx ikke mere er ledig / er i beskæftigelsesindsats | 01-11-2016 | 01-07-2100 |
4 | Ansat af virksomheden | Kandidat er ansat i virksomhed | 01-03-2017 | 01-07-2100 |
5 | Ikke ansat af virksomheden - ikke egnet match | Virksomheden ønskede ikke at ansætte kandidaten, fx vurderes at kandidat ikke er kvalificeret | 01-03-2017 | 01-07-2100 |
6 | Ikke ansat af virksomheden - har ansat en anden | Virksomhed har ansat en anden | 01-11-2022 | 01-07-2100 |
7 | Kandidat fjernet - på vej til andet job, pension m.v. | På vej til andet job, pension m.v. | 01-11-2022 | 01-07-2100 |
8 | Kandidat fjernet - ikke egnet match | Tovholder vurdere kandidat ikke er kvalificeret | 01-11-2022 | 01-07-2100 |
746.9.15 Som landssupporter, tester og STAR-SPOC vil jeg i LSS kunne udsøge på virksomhedens CVR og p.nr. de ordrer, der er registreret på virksomheden og se indholdet i ordren
Internt STAR acc.kri.
Løsningsmodel
LSS udvides til at kunne hente og vise en liste med jobordre for en virksomhed inkl. evt. formidlinger og hændelseslog
Særlige krav til test
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
---|---|---|
* Batchjobs
bør testes både med delta og fuldt load,
bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
bør testes i samarbejde med teams som har afhængigheder
kørselstid, særligt hvis det er en del af NightlyBatch
Konsekvenser for drift/idriftsættelse
I forbindelse med idriftsættelse:
Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres:
Skal der køres konvertering:
Skal der køres databasescripts for opdatering af tabeller i databasen:
Efter idriftsættelse:
Arkitektur- og implementeringsnoter
Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:
Nye dataområder:
Nye snitflader:
Nye komponenter:
Nye miljøer:
Nye teknologier:
Nye aftagertyper:
Eller afvigelser fra principperne:
Eventuelle behov for reduktion af teknisk gæld skal afdækkes:
Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.
Husk GDPR stillingtagen
Ingen personfølsomme data i epics
Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.
Angiv hvem der har foretaget dette tjek:
Angiv dato for tjek:
Opbevaring af oplysninger i STARs it-systemer
Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.
Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.
Hvem må tilgå oplysningerne?
Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.
Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.
Korrekte sikkerhedsattributter på services
PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.
Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )
Alle borgere | Egne borgere | Tidligere egne borgere | Gæsteadgang | Anden Aktør - egne borgere | Anden Aktør - gæsteadgang | |
---|---|---|---|---|---|---|
A-kasse | X | |||||
JobCenter | X | X | ||||
Kommune | X | |||||
STAR | X | |||||
AUB | ||||||
UDK | ||||||
STIL |
A-kasse filtrering
Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin
Sagsbehandlerlogin på Jobnet - tag stilling til adgang!
En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.
En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.
Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.
Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin