Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Anvendes ved ændringer, der har betydning for eksterne.

Interne links (indhold i links ikke relevant for eksterne)

Indholdsfortegnelse

Ingen Afgrænsning af epic

Ved løsning af AC 1-3 og 8 kan

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)

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 som evt. ikke hidtil har været anvendt i det pågældende KSS.

Oplysninger om fornidlinger på den enkelte borger kan ikke fremover læses i PersonStatusService, men skal læses i en anden service.

Ny(e) WSRM-versioner vedr. jobordrer og formidlinger vil skulle anvendes.

KSS

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 fornidlinger på den enkelte borger kan ikke fremover læses i PersonStatusService, men skal læses i en anden service.

Ny(e) 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.7.1 DFDG understøtter vedr. jobordrer flere jobtyper / ansættelsesbetingelser end ordinære job (f.eks. fleksjob, lærling, jobrotation)

Løsningsmodel

• DFDG oprette de nye typer for fremadrette anvendelse
• Er der eksisterende jobordre allerede registreret i DFDG som reelt er en af de nye type, kan/bør KSS opdaterer typen, DFDG lave ikke konvertering. (Knud de Place (STAR) skal dette være både på åbne og lukkede?)

VirksomhedsIndsats.CodeListService.Jobordretype

(CompanyRecruitmentTypeIdentifier)

For at håndtere flere jobtyper udvides kodelisten 

Afklaring: Udenlandsk arbejdskraft skal juridisk afklares i STAR

Ad id 2: Ønske fra Schultz (Ws-møde 25.08.2021), jf. FB https://manuscript.star.dk/f/cases/231249/ndrings-nske-Angivelse-af-om-rekrutteringsanmodning-er-et-sm-job (internt link: 

STAR? Hvis nødvendigt - Validering i forhold til jobordretype hvilke der har mandatory tovholder eller andre valideringer, pt er arbejdsantagelsen der ikke er ekstra valideringer i forhold til jobordertypen

STAR?: hvad er forskel på Ordinære job, småjob og et Ordinære job på deltid?

Acc.kr. 746.7.2 DFDG understøtter vedr. jobordrer angivelse af max antal arbejdstimer ved deltidsjob

VirksomhedsrettetIndsats.CodeLists

VirksomhedsIndsats.CodeListService.UgenligArbejdstidType [UDV]

I dag kan som strukturerede data angives WeeklyWorkTimeTypeIdentifier, der har dette udfaldsrum:

Herudover kan i eksisterende SOAP-snitflade angives det faktiske antal timer pr. uge (HoursPerWeek).

Afklaring: Hvad er der yderligere brug for? Eller er der tale om at dette felt ikke er til rådighed i KSS? Pt ligge DFDG op til at sådanne forhold skrives i fritekst indtil yderlige afklaring er tage med KSS

Løsningsmodel

Ugentligt arbejdstid i timer (timerPrUge) kan angives i forbindelse med angivelse af deltid (ugenligArbejdstidType). DFDG validere dog ikke på at dette alene angives i forbindelse med deltid. Tilbydes der i jobordren et interval f.eks. mellem 20 og 30 timer, angives max antal timer og det angives i beskrivetekst (jobordreBeskrivelse) nærmere oplysninger omkring timetalsinterval 

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

Afklaring: Findes dette udfaldsrum i begge KSS? Og hvilket eksisterende udfaldsrum kan vi læne os imod?

VirksomhedsIndsats.CodeListService.ArbejdstidsforholdType [UDV]

Forretningsregel

• Type af arbejdstid (ArbejdstidsType) skal default sættes til "Normal arbejdstid" hvis intet andet er oplyst

Alternativ løsning: Disse oplysninger angives i beskrivetekst (jobordreBeskrivelse)

746.7.3 B Kommentar ifm statusskift på kandidat, bliver ikke udstillet til rekrutteringsfællesskabet

Samtidig løsning af FB 243077 (se 

JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-3)

GetJoborder (Get /v1/jobordre),

Feltet opdateringsKommentar - "Årsag til at kandidat opdateres." samt formidlingsaarsagType -"Årsag til at kandidaten fjernes fra formidlingen eller afvises af virksomhed" gøre tilgængelig for alle aftagere på snitfladen.

746.7.3 C DFDG understøtter markering for udenlandsk arbejdskraft markering

Forretningsregler

Løsningsmodel

• Der laves et flag hvor man på jobordre kan angive om udenlandsk arbejdskraft ønskes

746.7.4 Ifm. udbygningen omlægges DFDGs snitflader fra SOAP til REST 

For at undgå en opgradering af SOAP-snitflade til ny SOAP-version, for forholdsvis kort efter at skulle opgradere til REST-snitflade ifm. moderniseringen af STARs it-systemer, foretages samtidig med nærværende udbygning af jobordrer tillige en omlægning til REST.

JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-3)

Følge nye felter er medtaget

• arbejdstidsType
• udlandsArbejdskraft

CreateJoborder (POST /v1/jobordre), GetJoborder (Get /v1/jobordre), UpdateJoborder (PUT /v1/jobordre), CreateJoborderFormidling (POST /v1/jobordre/formidling), GetJoborderForVirksomhed (GET/v1/jobordre/formidling{virksomhed}), GetJobordrePaaTypeOgStatus (GET/v1/jobordre/{jobordreType, jobordreStatusType}), UpdateJobordreStatus (PUT /v1/jobordre/status), GetVirksomhedJobcenterTilknytning (GET/v1/VirksomhedJobcenterTilknytning/{CVR-nummer, P-nummer}) og UpdateJobordreFormidling (PUT /v1/jobordre/formidling)

Metode ændret til dansk og følge nye felter

Der skal afklares om GetVirksomhedJobcenterTilknytning (GET/v1/VirksomhedJobcenterTilknytning/{CVR-nummer, P-nummer}) skal ligge i virk indsat silo eller f.eks. eksterne data

Forretningsregler (nye/ændret)

• Se JobordreService (CompanyRecruitmentService) (2022-3) pt den grønne tekst

WsrmMessageService (Version 11, 2022-2)

GetCompanyRecruitmentEventVersion3 og GetCompanyRecruitmentEventVersion3

Bebeholdes uændret. Bemærk at nye felter ikke medtages i WSRM beskeder, da de senere vil blive erstattet af tynde WSRM beskeder. Serviceaftager bør derfor / kan med fordel tage hensyn til at disse beskeder bliver tynde i deres implementering.

ELLER

Der laves nye tynde og Danske WSRM (jvf. ny arkitekturmodel)

DFDG løsningsmodel

• Der rejses events på jobordre og et events formidling (DFDG skal vurderer konkret model om det er generisk silo EV besked eller specifik jobordre besked)
• DFDG abonnerer på event og sende GetCompanyRecruitmentEventVersion3 og GetCompanyRecruitmentEventVersion3 ud

VirksomhedsrettetIndsats.CodeLists

VirksomhedsIndsats.CodeListService.JobordreType [UDV]

Flyttet fra CompanyRecruitmentStatusTypeIdentifier 1 til 1 plus og nye værdier

VirksomhedsIndsats.CodeListService.JobordreStatusType [UDV]

Flyttet fra CompanyRecruitmentStatusTypeIdentifier 1 til 1 plus og ny værdi

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 beskder udvides DFDG kodelister 

CompanyRecruitmentTypeIdentifier

Udvid med indhold i VirksomhedsIndsats.CodeListService.JobordreType [UDV]

CompanyRecruitmentStatusTypeIdentifier

Udvid med indhold i VirksomhedsIndsats.CodeListService.JobordreStatusType [UDV]

CompanyRecruitmentStatusTypeIdentifier

Ingen udvidelser.

WeeklyWorkTimeTypeIdentifier 

Ingen udvidelser.

CompanyRecruitmentEventActionTypeIdentifier

Ingen udvidelser.

CandidateRecruitmentStatusTypeIdentifier

Udvid med indhold i VirksomhedsIndsats.CodeListService.FormidlingsstatusType [UDV]

746.7.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 Virksomhedsrettet Indsats

PersonStatusService (Version 20, 2021-3)

GetVariablePersonStatus

CompanyRecruitmentInfo i PersonStatusService (version 20) vil returnere et tomt resultat.

VirksomhedsrettetIndsats.PersonStatusService (Version 1, 2022-3)

GetPersonStatus (GET /v1/personstatus{personnummer})

Status på borger i forbindelse med virksomhedsindsats

• Formidlinger på en borger / et medlem

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

LSS (før ændring)

xxx hvor vises jobordre på borger i LSS?

Datakanon (før ændring)

Ordreoprettelse

• Flyt til ny snitflade CreateJoborder (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

Image Modified

• Flyt til ny snitflade UpdateJobordreFormidling (PUT /v1/jobordre/formidling)

746.7.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 VirksomhedsrettetIndsats 2022-3 [UDV]#Star.dfdg.abonnement.Events.V1.SystemomraadeAbonnementOpdateretEvent)
• 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 pt. 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.7.8 JobAG udstiller servicesnitflade, hvor KSS / a-kasse kan se, om arbejdsgiver har oprettet sig som bruger af JobAG

Løsningsmodel

I denne sammenhæng er der umiddelbart 3 løsningsmodeller. endelig burde disse data ligge i Virksomhedsindsats siloen og ikke i JobAG, men det er nok en del af moderniseringen 

A) Virksomhedsindsats silo udstiller - loadmodel (skud fra hoften er denne umiddelbart den billigste, men data er 1 dag forsinket)

• Vi laver en kopi af data i Virksomhedsindsats silo (en eller anden model, billigst er nok at BI smider dem ind i silo hver nat - BI har dem alleredes og hvis BI laver fuld load har vi ikke GDPR udfordringer i silo)
• Vi laver en blivende service der udstiller data
• Når moderniseringsprojektet når der til og data ligges officiel i siloen, BI loadet dør
• JobAG skal fortælle virksomheder at data videregives til Jobcenter / a-kasse 
• Nyt tilsagnbeskrivelse til JobAG

B) Virksomhedsindsats silo udstiller - proxy model

• JobAG laver en service til Virksomhedsindsats silo 
• Virksomhedsindsats silo laver en "blivende" service der udstiller data
• Når moderniseringsprojektet når der til og data ligges officiel i siloen, JobAG service dør

C)  JobAG udstiller

• JobAG laver en service de direkte udstiller til KSS m.v.
• Når moderniseringsprojektet når der til og data ligges officiel i siloen, JobAG service dør

VirksomhedsrettetIndsats.Virksomhedsbrugerkonto (Version 1, 2022-3)

GetVirksomhedskonto (GET /v1/virksomhedskonto{CVR-nummer, P-nummer})

Ny metode der giver oplysninger om en virksomhed der har en konto på JobAG

746.7.9  JobAG anvender ny snitflade med nye jobtyper og flere felter, når arbejdsgivere opretter og redigere jobordrer

xxxx Christopher Juhl (Unlicensed)

DFDG

Filtrering i forhold til virksomheder, tovholder og kandidaten således at der kun medtages kandidater der skal vises for virksomheden (denne gl. service er før vores nye smarte filtrering)

Hvis nødvendigt - Validering i forhold til jobordretype hvilke der har mandatory tovholder

746.7.10  Som STAR og jobcenter vil jeg gerne være sikker permanetene jobordre håndteres

Forretningsmæssig er der jobordre der er permanente eller stående, 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 er håndteret delvist men kunne smidiggøres.

Preformanceissuse ved mange formidlinger, hvis det vurderes det er en problem, kan løses med 746.7.12 Adskillelse af aktuelle og historikdata i to metoder

Permanenter jobordre (ny status)

Permanent, løbende eller stående (eller hvad vi nu skal kalder dem) Dvs. en sådan jobordre holdes åben i princippet uendeligt, da virksomheden løbende vil kunne aftag arbejdskraft af den pågældende type.

En sådan type får en speciel status  "Permanent" (Id 4) da den forretningsmæssigt opfører sig forskelligt fra en normal/standard jobordre da

• senesteSvarDato reelt ikke give mening og derfor burde være Null 
• maxAntalKandidater reelt ikke give mening og derfor burde være Null 
• forventetAnsættelsesdato reelt ikke give mening og derfor burde være Null 

• jobordreAntalDage reelt ikke give mening og derfor burde være Null 

DFDG vil dog ikke lave valideringer for dette.

Ved at lave en bestemt status "Permanent" er det synligt for alle der ønsker anvende jobordren det kan lade sig gøre og virksomheden er interesseret i løbende at få tilbudt arbejdskraft. En "Permanent" jobordre styres stadig af et ansvarligt jobcenter og en tovholder, hvis en sådan er sat

En sådan Permanent jobordre kan overgå til en af de andre jobordrestatus 

• Åben - kan skiftes til en normal åben jobordre, det er uvist om dette reelt er et forretningsmæssigt behov, i givet fald skal der tages stilling til on nogle af de ovenstående parametre skal udfyldes
• Midlertidig inaktiv - arbejdsgiver kan midlertidig stoppe for formidling, f.eks fordi arbejdsgiver for indeværende har fået formidlet tilstrækkelig arbejdskraft
• Lukket - Hvis den permanente jobordre ikke mere er relevant for virksomheden

En sådan Permanent jobordre betragtes som rækkes af individuelle formidlinger,  en slags små selvstændige jobordre inden i den permanente jobordre

Gentagende enes 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 "Permanent" åben jobordre er tre arbejdsgange muligt

1. Nyoprettelse - eksisterende arbejdsgang
2. Genoplivning af eksisterende - ny arbejdsgang, der måske kun er relevant på JobAG
3. Kopiering af eksisterende - ny arbejdsgang Knud de Place (STAR) skal denne mulighed være der? Tænker hvis vi lave 2 er der ikke behov i jobAG men der er ikke noget til hindre for at JobAG kan dette med de eksisterende service. KSS vil jo altid kunne lave en kopieringsfunktion til sagsbehandler

Forretningsmæssige forhold

1. Nyoprettelse - eksisterende arbejdsgang

En virksomhede eller et jobcenter kan altid oprette en ny jobordre også selvom rekrutteringsbehovet allerede eksisterer i en tidligere jobordre. Hvis en ny jobordre oprettes for 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 formidlet 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 tovholde selv eller af virksomhed. Dermed risikere man at der formidles borgere der allerede har være i proces (Knud de Place (STAR) / Camilla Hagedorn Trolle er der noget juridisk vi skal være obs på her?) 

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

DFDG vil hvis en jobordre skifter jobordrestatus fra "Lukket" eller til "Åben" eller "Permanent" gøre:

• Hvis seneste senesteSvarDato er i dag (skal vi f.eks. sige den min skal være x dage frem?) eller historisk fjerne denne
  Sagsbehandler kan hvis UpdateJobordreStatus (PUT /v1/jobordre/status) kaldes altid opdaterer jobordren med disse oplysninger hvis relevant og anvendes UpdateJobordre (PUT /v1/jobordre) kan oplysningerne direkte medtages
• Hvis seneste forventetAnsættelsesdato er i dag (skal vi f.eks. sige den min skal være x dage frem?) eller historisk fjerne denne
  Sagsbehandler kan hvis UpdateJobordreStatus (PUT /v1/jobordre/status) kaldes altid opdaterer jobordren med disse oplysninger hvis relevant og anvendes UpdateJobordre (PUT /v1/jobordre) kan oplysningerne direkte medtages

• Hvis der er formidlet kandidater på jobordren når jobordrestatus skiftes, vil DFDG hvis de har formidlingsstatus (FormidlingsstatusType):

  • "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 7 dage siden jobordren blev sat "Lukket" gøres ingenting hvis det er mere 7 dage sættes formidlingsstatus "Formidling afventer godkendelse (Id 1)" da tovholde 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 7 dage.

3. Kopiering 

Her renses tidligere formidlinger væk og man starter på en frisk, svare til at man 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

Knud de Place (STAR) skal det virke anderledes ved de forskellige Jobordretype?

Kandidater jobcenter ikke får fuldt op på 

Har vi ikke et batchjob der fjerne kandidater der ikke mere er tilgængelig f.eks ved KG skift? Kan ikke finde det

For at kandidater ikke står tilgængelig for virksomheden og ikke bliver behandlet unødigt af sagsbehandler og virksomheden vil DFDG:

• Hvis der er en kandidat der der ikke har åben kontaktgruppe og et søgbart CV (skal vi holde åbent hvis borger alene har et søgbart CV for di borgere der er skiftet til beskæftigelse) sættes kandidaten til "Kandidat fjernet - ikke mere relevant" (Id 3) med formidlingskommentar (opdateringsKommentar) "Borger fjernet i forbindelse med skift i ledigsforhold og er ikke længere til rådighed for formidling". Dette sker uanset jobordrestatus.
• Hvis en kandidat står med formidlingsstatus (FormidlingsstatusType) "Formidling tilgængelig for virksomhed" (Id 2) på en Permanent eller Åben joborder og der efter 30XX dage ikke er sket en til statusskift til enten "Kandidat fjernet - ikke mere relevant" (Id 3), "Ansat af virksomheden" (Id 4) eller "Ikke ansat af virksomheden" (Id 5) vil DFDG skifte formidlingsstatus til XXXX "Formidlingsresultat ukendt" (Id 6) således at virksomhenden ikke har dem stående åbne på en permanent jobordre. Det samme gøre på almindelige Åbne jobordre, men her burde situationne ikke forekomme med mindre sagsbehandler ikke følger arbejdsgang.

746.7.11 Ændret valideringsregler 

Løsningsmodel

220234 - Active 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)

235426 - Besked fra DFDG: Kandidaten findes ikke på rekrutteringsanmodningen eller er allerede blevet fjernet

Sag løst

JobordreService (CompanyRecruitmentService) [UDV] (Version 1, 2022-3)

CreateJobordreFormidling (POST /v1/jobordre/formidling)

• Der må ikke formidles på en joborder der har status (JobordreStatusType) Midlertidig inaktiv (Id 2) eller Lukket (Id3)

UpdateJobordreFormidling (PUT /v1/jobordre/formidling)

• Hvis joborder har status (JobordreStatusType) Midlertidig inaktiv (Id 2) eller Lukket (Id3) må en formidlingsstatus (FormidlingsstatusType) ikke skiftes til Formidling tilgængelig for virksomhed (Id 2) 

746.7.12 Adskillelse af aktuelle og historikdata i to metoder

Løsningsmodel

i den nuværende model medtages alle formidlingsevente i getmetoder (det er fuld historik for hver borger) dette er der forretningsmæssigt ingen grund til så i stedet etableres 

1. En historikservice der medtager alle formidlingsevents
2. De alm. getmetode retunere allene den seneste formidlingsstatus for hver borger (der inddførse en is lates markering eller ny historikmodel med temp tables (ny arkitektur for historik)

Det skal afklares med KSS og JobAG om det er forretningsmæssigt er korrekt forstået at de alene anvende/har brug for seneste formidlingsstatus 

746.7.13 Mulighed for at vedligge CV (PDF) og/eller kontakt oplysninger, hvis borger ikke har et CV på Jobnet eller et link til disse oplysninger

Baggrund

Der kan være tilfælde hvor en borger formidles inden et CV er gjort søgbar på Jobnet, i det tilfælde har den formidlende sagsbehandlerfor behov at give virksomheden kontakt og CV oplysninger om borger således af virksomheden kontakte borger og evt. have oplysninger om borgeres kvalifikationer.

Hvordan skal et sådan CV PDF komme ind til formidlingen, borger kan jo ikke selv få den ind, da de ikke kan se formidlinger?

Løsningsmodel

• I den tilfælde af sagsbehandleren formidler en borger der ikke har et CV der er søgbart på Jobnet, kan sagsbehandleren:
  • Nudge borger til at få færdiggjort sin Jobnet CV hurtigst muligt og det vil så automatisk blive tilgængelig for virksomheden
  • Sende kontaktoplysninge og evt. CV som PDF (hvis borger har videregivet eget CV til sagsbehandleren) til virksomheden via de digitale kanaler Jobcentere normalt bruger til fremsendelse af CV
  • Skrive specifikke/udvalgte kontakt- og/eller kompetenceoplysninger i kommentarfeltet om borgeren (kommentarOmKandidat), denne kan virksomheden se direkte på formidlingen i JobAG

746.7.14 Som sagsbehandler vil jeg have en å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.  

746.7.15 Blokageramte virksomheder skal der ikke oprettes jobordre på og eksisterende jobordre skal der ikke formidles borger på.

Star har for nuværende ingen teknisk understøttelse af dette i forhold til jobordre.

Særlige krav til test

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

•   Ja, det er tjekket, at epic ikke indeholder dette.

• 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 )

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