Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Page Properties | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Indholdsfortegnelse
Table of Contents | ||
---|---|---|
|
Afgrænsning af epic
Afgræsning | ||
---|---|---|
Som a-kasse og kommune, vil jeg gerne have styr på hvem der har ansvaret for de lediges kontaktforløb. | ||
Acceptkriterier | ||
Nr. | Beskrivelse | Relevant for |
935.4.1 | Som a-kasse vil jeg kunne varetage kontaktforløbet og registrere de afholdte samtaler med borger | DFDG |
935.4.2 | Som Jobcenter vil jeg løbende kunne følge med i kontaktforløbet som varetages af a-kassen | DFDG |
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
---|---|---|---|---|---|
Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | ||
Oversigt over berørte webservices
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Beskrivelse af epic
Denne epic er en fortsættelse af arbejdet i 935.3 LAB - A-kasse forsøg Bemærk: Jobnet userstory job-151 omhandlende acceptkriterie 935.3.5 (visning af at borgers forløb varetages i a-kasse) først er leveret med 2019-2, da opgaven ikke blev nået i 2019-1 i 935.3. Beskrivelsen ligger dog fortsat i 935.3, da det er den rette kontekst for forståelsen.
Samtaleafholdelse med borger og registreringen af den afholdte samtale med henblik på en klar fælles forståelse af det fælles kontaktforløb
Der indføres en ny, forsøgsspecifik samtaletype: "A-kasse forsøgssamtale". For borgere i forsøget skal alle samtaler indberettes under samtaletypen "A-kasse forsøgssamtale" (id 20) og der tilføjes en ekstra dimension, hvor a-kassen på den afholdte samtale angiver formålet med samtalen (cv, rådighed, jobsamtale).
Samtaletypen er tilgængelig for alle a-kasser og jobcentre, men der indføres validering så "A-kasse forsøgssamtale" kun kan bookes for borgere omfattet af forsøget og der tilsvarende kun kan registreres afholdt samtale på forsøgsomfattede borgere. .
Sammenhold af samtaleindsats i jobcenteret og a-kassen kan ske ved at anvende samtaletype ”Jobsamtale” for ledige i jobcenteret og samtaletypen "A-kasse forsøgssamtale". Der kan kun afholdes 1 samtale af denne type pr dag.
A-kassen skal derudover kunne indkalde, afholde og registrere registrere den nye samtaletype Fællessamtale med dagpengemodtager (InterviewType id 19) som afløser Jobsamtale med a-kasse deltagelse (id ). Sidstnævnte udfases. ¤Afklaring: men ikke længere jobsamtale (InterviewType id 7)
A-kassen opretter indkaldelser med BookingService hvor der generelt (¤Afklaring: eller kun for forløbsdeltagere) åbnes åbnes op for at samtaletype 19 og 20 for a-kasser. Samtalerne registreres efterfølgende
Jobcentret får WSRM på alle bookinger for egne borgere, og er således orienterede om bookingen.
De nærmere detaljer om indkaldelse m.m. på Fællessamtale med dagpengemodtager vil blive behandlede i epic 935.2 i 2019-3 ¤¤¤
Bemærk: Jobnet userstory job-151 omhandlende acceptkriterie 935.3.5 (visning af at borgers forløb varetages i a-kasse) først er leveret med 2019-2, da opgaven ikke blev nået i 2019-1 i 935.3. Beskrivelsen ligger dog fortsat i 935.3, da det er den rette kontekst for forståelsen.
935.4.1 Som a-kasse vil jeg kunne varetage kontaktforløbet og registrere de afholdte samtaler med borger
InterviewService (Version 1)
Som en del af arkitekturstrategien om mindre status-services og domænespecifikke services. Overtager en række metoder fra PersonRegistrationService:
UpdatePersonInterview, AddInterviewParticipant, UpdateInterviewParticipant og DeleteInterviewParticipant. Metoderne udfases fra PersonRegistrationService (evt. i en senere release).
CreatePersonCategoryAndInterview tænkes ikke ført med over, men udfaset.
Nedenfor gennemgås metoderne i det omfang der er væsentlige ændringer til dem.
CreatePersonInterview
Metoden flyttes fra PersonRegistrationService med følgende ændringer:
Der er ikke længere en validering for at samtale skal registreres 7 dage efter mødeafholdelse ¤Afklaring 1: valideringen udgår helt/ sættes op til 30 dage. "Afklaring 2: Det er dog et krav at man har ansvaret for borgeren for såvel jobcenter som a-kasse.
GetPersonInterview
Metoden til at få det resultat som kendes fra PersonStatusService, det fulde udtræk af information om registrerede samtaler.
935.4.2 Som Jobcenter vil jeg løbende kunne følge med i kontaktforløbet som varetages af a-kassen
PersonContactStatusService (Version 1)
Aftager efter PersonStatusService på kontaktforløbsområdet, dvs. for domænet med Booking, Interview, NUPH og Anden Aktør. I regi af denne epic
GetPersonContactStatus
Returnerer statusoverblik for de 4 collections
CodelistService (Version 5)
InterviewType
InterviewPurposeType
Ny kodeliste med samtaleformålene CV, Rådighed og Job
WSRMMessageService (Version 11)
GetPersonInterviewVersion10
"Tynd" WSRM med nedenstående. Se evt. GetPersonInterviewVersion9 på wiki
CPR
InterviewType
InterviewPurpose collection
InterviewTime
(Metadata med oprettende myndighed mm)
JobnetBookingService.GetConductedInterviews
Jobnet får afholdte samtaler her, det skal verificeres at tilføjelsen af formål ikke volder problemer i den sammenhæng.
Min Plan effekter
Registrerede samtaler af typen A-kasse forsøgssamtale vil alle optræde på Min Plan
Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:
- DFDG
- Services
- WSRMer
- Kodelister
- PersonStatusService (PSS)
- PersonHistoryService (PHS)
- LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
- Jobnet
- VITAS
- JobKon
- JobAG
- BI integrationsplatform
- Alle områder
- Nye batchjobs
- Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon)
- Dataløft
- Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.
- Nye batchjobs
- Kommunalt sagsbehandlingssystem
- A-kasse sagsbehandlingssystem
- Kommunalt bookingsystem
- JobcenterPlanner (JCP)
- WorkForcePlanner (WFP)
- Kommunalt ydelsessystem
Særlige krav til test
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
---|---|---|
For forståelse af Job-151 henvises til beskrivelse af acceptkriterie 935.3.5 i 2019.1. Her ligger beskrivelsen for at bevare kontekst, men da arbejdet ikke blev nået i 2019-1 blev story flyttet til 2019-2. | Jobnet | Kenneth Ingemann Larsen (KEIL) (Unlicensed) |
* 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
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.