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)

https://starwiki.atlassian.net/browse/DS-8943

https://starwiki.atlassian.net/browse/DS-11964

https://starwiki.atlassian.net/browse/BI-2072

Indholdsfortegnelse

Afgrænsning af epic

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)

Open

Open

Open

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å JobAG

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

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:

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

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)

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

Open

Datakanon (før ændring)

Ordreoprettelse

Open

• 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

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:

1. Nyoprettelse - eksisterende arbejdsgang

2. Genoplivning af eksisterende - ny arbejdsgang, der måske kun er relevant på JobAG

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

• Hvis 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]

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

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

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