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

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):

Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)

Beskrivelse af epic

Denne epic indeholder en backlog af ønsker til VITAS. De emner, der ikke implementeres i release skubbes til efterfølgende release. STAR prioriterr løbende om emner kan slettes.

(VL) BOBLER Automatiseret sats udfyldelse på bevillingen til voksenlærlingeforløb (KC68920)

Tilskuddet løber fra uddannelsesaftalens påbegyndelse og i hele det aktuelle uddannelsesforløb – eller i op til to år for beskæftigede

- Når jobcentermedarbejderen opretter bevillingen skal de selv sætte tilskudsperioden – deres eget ansvar. VITAS advarer eller vejleder ikke her.

- Der er mulighed for at vi kan presætte tilskudsperioden (og tilskudssats) for sagsbehandlerne og/eller give advarsler ved objektivt ’forkerte’ perioder/satser.

BHA: Hvad siger forretningen? Camilla undersøger

(VL) BOBLER Upload-funktion ifb. forlængelse af VL (ny uddannelsesaftale) (KC60205)

Der mangler en upload funktion ifm. forlængelses funktion af et voksenlærlinge forløb, hvor brugeren kan uploade en ny uddannelsesaftale. Dette skal løses via af ny funktionalitet eller evt. vejledning hvis muligt. Denne ændring skal releases til løsningen den 1/7-2019.

BHA: Hvad siger forretningen? Camilla undersøger

971.31.27 Integration til DFDG BI/VOA, dump af oplysninger fra E-indkomst i vitas DB (Eksport af IGU data) (KC60220)

Eksport – udtræk til VOA - IGU data til statistik formål (KC60240)

Vitas skal afleverer IGU data til VOA til statistik formål

BHA: Bør slettes. BI skal have ansvaret. Se tabel.

Vitas skal afleverer IGU data til VOA til statistik formål (KC60238)

VOA sender opgørelse over ansættelsesforhold på alle virksomheder. 

BHA: Bør slettes. BI skal have ansvaret

VOA sender opgørelse over ansættelsesforhold på alle virksomheder. (KC60239)

VOA sender opgørelse over antal ansætte eller mængde af ansættelsestimer på CVR eller p-niveau (eller begge) for alle virksomheder. Det er endnu ikke afklaret. 

BHA: Er det ikke implementeret?

971.31.28 Merbeskæftigelses- og forholdstalskrav tilpasninger i brugerflade og valideringer (KC63831)

Førtidspensionister skal ikke tælles med i opgørelse over personer i tilskudsforløb (KC60194)

Image Removed

Undersøgelse - kontrol af hvilke JobOrderTypeIdentifiere der skal tælles med som tilskudsansatte i rimlighedkravs (forholdstal) (KC63204)

Se vedhæftede mail:

Det drejer sig konkret om, hvordan vi i dag håndtere fleksjobbere i VITAS mht. rimelighedskravet. (og på sigt merbeskæftigelseskravet)

Som jeg har forstået på Igor, så er det således, at der trækkes oplysninger om antal personer i virksomhedspraktik og løntilskud når vi opgør antallet af tilskudspersoner. Og kun dem!

Antallet af ordinært ansatte angives manuelt af arbejdsgiveren, hvor denne selv skal fratrække fx fleksjobbere. Disse skal jo ikke tælles med.

I den foreslåede nye model, hvor antal ordinært ansatte skal hentes fra eIndkomst skal fleksjobberne trækkes fra. Er det korrekt forstået, at disse data skal/kan hentes via DFDG?

BHA:Slettes.  Er det ikke implementeret i de data, VITAS modtager fra VOA?

971.31.29 Tekstændringer til VITAS

Acceptkriterier:

• Når jeg som jobcenter indtaster en borgers CPR, som ikke hører til jobcentret: "Du arbejder på et forkert jobcenter" => "Den valgte borger er ikke tilknyttet dit jobcenter, og du kan derfor ikke hente oplysninger på denne".

BHA: Lille ændring: 1 SP

971.31.31 Flytning mellem JC og revision + notifikation hvis sag modtages der er overført fra andet jobcenter (FB 102612, KC32797)

Såfremt en ledig, som er bevilget ansættelse med løntilskud, flytter bopæl til anden kommune, mens pågældende er ansættelse med løntilskud, overflyttes bevillingen til det ansvarlige jobcenter. Men har vi nogen mulighed for at fremfinde bevillingen, hvis vi bliver bedt om at dokumentere forløbet af vores revision?

Hvis de manuelt overføres til et andet jobcenter, findes de rigtig nok ikke længere på tidligere jobcenters lister. Vi tror at jobcentrene vil blive en anelse bekymrede over et revision-besøg. Spørgsmålet er om det giver mening at lave en mulighed for at fremsøge ansøgningen under "Søg" i stil med at AA-sager, der er overført til JC. Alternativt give mulighed for at se en liste med "overførte" ansøgninger. Skal jeg oprettet en PBI til backloggen til dette? 

JC Hvidovre kunne godt tænke sig, at der kommer en advis i Vitas. Hvis et andet JC overføre en sag til dem i Vitas. Hvis sagen i Vitas kører som den skal og et JC overføre sagen, så ser det nye JC typisk først sagen når der sker et ophør og kommer ned i deres ophør boble. JC Hvidovre kunne godt tænke at der kom en besked i Vitas om der er kommet en sag over til dem fra et andet JC så de kan følge op på sagen før den evt. kommer til et ophør. Og JC kunne også godt tænke hvis man kunne skrive en tekst, om hvorfor den bliver overflytte til andet JC.

BHA: Bør flyttes til selvstændig epic

971.31.32 Virksomhed ønsker flere filtreringsmuligheder (MC 120257)

Jem&Fix A/s: Vil det være muligt at man eks. under status kan afgrænse til kun aktive virksomhedspraktik bliver vist, Det kunne give et bedre overblik over hvor vi har praktikanter p.t. Det samme gælder for aktive i løntilskud. Jem&Fix A/S svarer, at de ikke umiddelbart har brug for at kunne udsøge de inaktive. De vil bare gerne have et overblik/ trække en liste over, hvor de p.t har nogle i praktik og løntilskud.

Det forvirrer billedet, når de kan se alle, også de der er stoppet.

Reference: MC 120257

BHA: Forekommer relevant

971.31.33 Forbedret håndtering af forlængelse (MC 166767)

Forretningsreglerne omkring forlængelse fungerer ikke korrekt, da der bla. (i nogle tilfælde?) skal kunne forlænges indtil rammen for den oprindelige bevilling er opbrugt. Der er desuden ikke fuld specifikation af alle forlængelsesregler, men kun af de nye. Endelig er forlængelser i dag styret teknisk med WWF, hvilket er for dyrt og for kompleks at vedligeholde. Vi ønsker at få en ny og bedre specifikation, samt implementering.

BHA: Forretningsbehov? Bemærk, at KC her nævner problemer med WWF.

971.31.38 Robust routning af ansøgninger om voksenlærling (fjerne teknisk gæld fra VIR-730)

Der er lavet en midlertidig løsning i VIR-730, epic 971.14, som efterlader teknisk gæld.

Dette epic acceptkriterie fjerner den tekniske gæld ved at:

• DFDG serviceudstiller [BrokerServices].[dbo].[tblMunicipalityJobcenterRelation]
• VITAS mapper kommune til jobcenter via den nye DFDG service
• VITAS fjerner sin kopi af [BrokerServices].[dbo].[tblMunicipalityJobcenterRelation]

BHA: Bør implementeres ved lejlighed

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.
• Kommunalt sagsbehandlingssystem
• A-kasse sagsbehandlingssystem
• Kommunalt bookingsystem
  • JobcenterPlanner (JCP)
  • WorkForcePlanner (WFP)
• Kommunalt ydelsessystem

Særlige krav til test

971.31.1 Nyt felt CourseTypeIdentifier på Vitas.MentorService

• Vitas.MentorService, Version 2 er udgået og erstattet af Vitas.MentorService, Version 3
• Der er tilføjet et nyt obligatorisk felt "CourseTypeIdentifier" af typen "CourseTypeIdentifierType" til Vitas.MentorService, Version 3
  • Feltet er indsat efter og under "MentorEducation"
• Beskrivelse på Wiki: "Mentorbevillingstype: Mentor, individuel (CourseTypeIdentifier = 34) eller Mentor, Plads (CourseTypeIdentifier = 35)"
• CourseTypeIdentifier er mappet til den valgte værdi for Mentorbevillingstype.

971.31.2 Det er muligt at vælge "Mentorbevillingstype" = "Mentor, individuel" [CourseTypeIdentifier = 34] eller "Mentor, Plads" [CourseTypeIdentifier = 35] på Mentor tillægsbevillinger

• WSRM VitasNotificationService.SendJobAllocationAddOnsStatusNotification sender CourseTypeIdentifier = 34 eller CourseTypeIdentifier = 35 afhængigt af valg på bevillingen. Bemærk: Ingen ændringer i snitflade eller kodeliste. VITAS har hidtil sendt en statisk kode 34, men kan fremover sende 34 eller 35.
• Jobcentermedarbejder kan ved udarbejdelse af mentortillægsbevilling vælge "Mentorbevillingstype" = "Mentor, individuel" [CourseTypeIdentifier = 34] eller "Mentor, Plads" [CourseTypeIdentifier = 35].

971.31.3 Det er muligt at vælge "Mentorbevillingstype" = "Mentor, individuel" [CourseTypeIdentifier = 34] eller "Mentor, Plads" [CourseTypeIdentifier = 35] på Mentorbevillinger ved ordinær beskæftigelse

• Jobcentermedarbejder kan ved udarbejdelse af mentorbevilling til ordinær beskæftigelse vælge "Mentorbevillingstype" = "Mentor, individuel" [CourseTypeIdentifier = 34] eller "Mentor, Plads" [CourseTypeIdentifier = 35].

Særlige krav til test

Ingen særlige krav.

* 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

Ingen særlige krav.

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 

Ingen arkitekturændringer.

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.