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

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Beskrivelse af epic

Oversigt over sager der indgår i epic

Det fremgår ud for de enkelte sager om de idriftsættes i juni med release 2019-2 (markeret som 2019-2 Øvrige og grøn baggrund) eller om de idriftsættes med release 2019-LAB (markeret med 2019-2 LAB og gul baggrund), der pga. lovforslag L 209 / 2019 (først) forventes idriftsat med release 2019-4.

Om udvalgte FB-sager

FB 130249 - Ny validering på JobcenterMessageService (2019-2 LAB - forventes idriftsat med 2019-4)

Vi tilretter JobcenterMessageService (Version 2).SaveAvailabilityAssessment, så det for en a-kasse er muligt at kalde den for alle nuværende og tidligere medlemmer.

RecallAvailabilityAssessment tilrettes så der kun er validering på at det er samme a-kasse, som har oprettet rådighedsvurderingen (identificeret ved sin GUID), som må tilbagekalde den.

Hvis en anden a-kasse end den, der har oprettet rådighedsvurderingen, forsøger at recall'e den, kastes en ny fejlkode 9375 - "RecallAvailabilityAssessment is only allowed for unemployment fund who entered the given assessment".

FB 132126 - Ny validering til RecallMembershipRegistration (2019-2 LAB - forventes idriftsat med 2019-4)

Der har været en lang række eksempler på, at en a-kasse har foretaget recall af medlemsskabsregistrering, hvor dette har medført, at medlemmet er ført tilbage til at være medlem i en a-kasser, der ikke længere eksisterer. Det er i de fleste tilfælde sket ved sammenlægning af a-kasser, hvor den "overlevende" a-kasse (A) har recall'et medlemskab på det overførte medlemskab (efter der er registreret MT i a-kasse A) og medlemmet er dermed tilbageført med et aktivt medlemskab i den "ophørte" a-kasse (B).

Medlemmet er dermed havnet i en ulovlig (datamæssig) tilstand, der giver problemer i de øvrige aftager-systemer.

Der etableres derfor en ny validering, så dette ikke kan finde sted:

• Hvis RecallMembershipRegistration medfører at et medlemskab af en udgået A-kasse genaktiveres, kastes en fejl (ny fejlkode skal implementeres)
• Udkast til tekst: "RecallMembershipRegistration is illegal make a MembershipCancellation instead"

I denne situation skal den "overlevende" a-kasse (A) i stedet foretaget en MA-registrering (UnemploymentFundMembershipService.MembershipCancellation).

Ny fejlkode 9374 (RecallMembershipRegistration is illegal make a MembershipCancellation instead)

FB 118122 - Ny validering til IllnessCompositeService (2019-2 LAB - forventes idriftsat med 2019-4)

Der har været flere eksempler på, at jobcentre annullerer "sygdom - sygemelding" med  AbsenceCauseTypeIdentifier id 36 (annullering / sletning), når først sygedagpengesagen er oprettet i eDagpenge, dvs. når der er tilknyttet et UUID på "sygdom - sygemelding". Det må jobcentret imidlertid ikke, jf. aftalerne mellem DFDG, eDagpenge og KSS. eDagpenge frafiltrerer derfor i dag sådanne annulleringer, der registreres af KSS og kommunikeres til eDagpenge via DFDG. Data kommer dermed ud af sync i KSS, DFDG og eDagpenge.

DFDG etablerer derfor ny validering således, at der ikke fra KSS og a-kasser kan anvendes AbsenceCauseTypeIdentifier id 36 (annullering / sletning), når først sygedagpengesagen er oprettet i eDagpenge, dvs. når der er tilknyttet et UUID på "sygdom - sygemelding".

Fejlkode 9361 (AbsenceCause is illegal for this AbsenceType).

FB 132685 - Tilføjelse af stillingsbetegnelser (2019-2 øvrige)

Følgende stillingbetegnelser oprettes så de kan benyttes til Joblog, Mål i Min plan, Jeg søger job som, krav til jobsøgning, Dashboard kort udhentning, mm.

De nye stillingsbetegnelser vil blive udstillet i blandt andet:

• DiscoCodesService(Version 6).GetDiscoCodes
• CodeListService(Version 5).GetDiscoAms08
• CodeListService(Version 5).GetTaxonomiOccupation

Da der (alene) er tale om nye stillingsbetegnelser i kodelisterne, vil der ikke skulle ske konvertering af allerede foretagne registreringer i  forbindelse med ibrugtagningen af de nye kodelisteværdier.

Grøn markering er de nye DiscoAms08 stillingsbetegnelser der oprettes:

FB 136892 - Fire stillingsbetegnelser udskiftes med stillingsbetegnelses synonymer (2019-2 øvrige)

De nye stillingsbetegnelses synonymer vil blive udstillet i:

• CodeListService(Version 5).GetTaxonomiOccupation

Da der (alene) er tale om nye stillingsbetegnelses synonymer i kodelisten, vil der ikke skulle ske konvertering af allerede foretagne registreringer i forbindelse med ibrugtagningen af de nye kodelisteværdier.

Følgende stillingbetegnelses synonymer oprettes:

Følgende stillingsbetegnelser fjernes (blev oprettet i FB 132685):

Følgende stillings betegnelse synonym fjernes (FB: 137308):

Datagenopretning

Jobnet CVer og "Jeg søger job som" oprettet ud fra stillingsbetegnelses synonymet "rengøringsassistent, hotel", vil blive datagenoprettet fra at være stillingsbetegnelse: "rengøringsassistent" til at være "rengøringsassistent, hotel".

FB 129320 - Benefitsgradingidentifier's mangler tilsyneladende i tabellen BenefitsgradingBasis (2019-2 Øvrige)

Ved en fejl er det i version 2 af UnemploymentBenefitsAccountService blevet muligt at oprette en BenefitsGrading uden minimum 1 grundlag i BenefitsGradingBasisCollection.

WSDL for UnemploymentBenefitsAccountService (version 2) opdateres så forekomst "0-*" for BenefitsGradingBasisTypeIdentifierTypes ændres til forekomst "1-*"

FB 125875 - Jobcentertilknytning registreret den 01-01-1900 kl. 00:00? (2019-2 LAB - forventes idriftsat med 2019-4)

Jobcenter-historikken er lidt speciel, idet der ikke er nogen "fact"-tabel. Når en borger skifter jobcenter, og han ikke har skiftet før, oprettes der en "før"-række i historiktabellen, hvor bl.a. EventTime sættes til null. Det ser ud til at være gammel funktionalitet.

EventTime bruges som både startdato og registreringsdato ved udlæsning via PHS'en, men da registreringsdato er et obligatorisk felt i PHS-svaret, sætter man datoen til 1/1-1900, hvilket slår igennem i LSS:

Der forventes behov for et større analysearbejde af eventuelle sideeffekter, hvis vi vil udfylde EventTime med andet end null i ovennævnte tilfælde, da det både sker ved manuelt skift af jobcenter (via PRS'en) og ved load af CPR-data.

... og at ændre kardinalitet i PHS'en, så der kan returneres null, anses heller ikke for en løsning uden videre.

Derfor foretages i denne omgang en ren LSS-løsning, hvor 1/1-1900 visningsmæssigt udskiftes med blankt hhv. "{ Ingen data }" i jobcenter-historikken i LSS.

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

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