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)

DS-12138 - Getting issue details... STATUS

KON-2963 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

Pakke TILMELD-1 i Knuds liste - Beta roadmap DFDG

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)

[12.06.2024,27.06.2024, 10.09.2024] tilføjelser til ovenstående tabel

Automatisk oversigt

Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.

Beskrivelse af epic

Baggrund

Her udfylder PO oplysninger om baggrund for epic'en, herunder fx om der ligger politisk aftale eller lovgivning bag. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

Som en del af DFDG's udfasning af end of life teknologier og STAR's moderniseringsprogram sker der i forhold til Tillmelding som jobsøgende følgende:

• I DFDG et skift til REST snitflade - og i denne epic med tilføjelse af en Update-funktion og hændelsesdato for tilmelding:

• På tilmelding som jobsøgende tilføjes hændelsesdato således, at sagsbehandler i jobcenter og a-kasse kan registrere, hvornår tilmeldingen forretningsmæssigt burde være sket fra, selvom tilmeldedato ikke kan være i fortiden.

  • Ændringen foretages for at

    • lette bl.a. udbetalingen af dagpenge, hvis fx it-problemer i DFDG eller i lokale systemer har været årsag til, at en borger ikke kunne blive tilmeldt som jobsøgende

    • lette bl.a. udbetalingen af dagpenge, hvis sagsbehandler i jobcenter eller a-kasse af andre årsager end it-problemer ikke har fået tilmeldt borger den dag borger har henvendt sig i jobcenter eller a-kasse for at blive tilmeldt som jobsøgende

    • a-kassen via hændelsesdato kan registrere, hvis der for konkrete medlemmer dispenseres fra kravet om tilmelding

• En sanering i brug af ledighedsgrader ved tilmelding for mindske behovet for efterfølgende opdateringer

• I Jobnet en overgang til ny REST snitflade samt ny frontend arkitektur (denne opgave er ikke en del af denne epic, men vil blive specificeret i en efterfølgende epic)  

Forretningsmæssig anvendelse af hændelsesdato (15.08.2024)

• På tilmelding som jobsøgende tilføjes hændelsesdato således, at sagsbehandler i jobcenter (alene for andre kontaktgrupper end dagpengemodtagere) og a-kasse (for dagpengemodtagere og tilmeldte ‘Uden ydelse’) kan registrere, hvornår tilmeldingen forretningsmæssigt burde være sket fra, selvom tilmeldedato ikke kan være i fortiden.

• STAR/DFDG kan endvidere registrere/opdatere hændelsesdato, hvis der foretages datagenopretninger pga. fx driftsproblemer eller datafejl, der forårsager, at tilmelding ikke kunne registreres på rette dato

  • Ændringen foretages for at

    • lette bl.a. udbetalingen af dagpenge, hvis fx it-problemer i DFDG eller i lokale systemer har været årsag til, at en borger ikke kunne blive tilmeldt som jobsøgende

    • lette bl.a. udbetalingen af dagpenge, hvis sagsbehandler i jobcenter eller a-kasse af andre årsager end it-problemer ikke har fået tilmeldt borger den dag borger har henvendt sig i jobcenter eller a-kasse for at blive tilmeldt som jobsøgende (beror ift. jobcentrets registreringer ift. dagpengemodtagere på, at jobcenter fx via beskedtype 1 i dialogmodulet orienterer a-kassen om baggrunden for sen tilmelding fra jobcentrets side således, at a-kassen kan tage stilling til dispensation, jf. rådighedsbekendtgørelsen § 6, stk. 2, om dispensation for manglende tilmelding)

    • a-kassen via hændelsesdato kan registrere, hvis der for konkrete medlemmer dispenseres fra kravet om tilmelding

Særligt ift. dagpengemodtagere

• A-kasserne anvender hændelsesdatoen til at angive, at a-kassen har fået fornøden dokumentation for at den sene registrering af tilmelding skyldes jobcenteret, a-kasse eller DFDG - og at medlemmet i øvrigt opfylder betingelserne, så a-kassen har dispenseret for manglende tilmelding fra hændelsesdagen og frem til tilmelde-startdatoen.

• Hændelsesdatoen er dermed den dag, hvorfra der kan udbetales a-dagpenge.

• Hvis STAR/DFDG har registeret hændelsesdatoen er dette også udtryk for, at a-kassen har fået fornøden dokumentation for at den sene registrering af tilmelding DFDG

• A-kassemedarbejdere vil fremadrettet kunne undgå at lave en manuel asynkron tilmelding alene i a-kassen for at kunne komme til at udbetale på trods af manglende tilmelding i dispensationssagerne. Man ville i stedet opdatere tilmeldingen med en hændelsesdato, hvilket ville betyde, at a-kassesystemet kun kan udbetale, når tilmeldingen var registreret i DFDG, hvilket som yderligere gevinst ville sikre at tilmeldeperioden blev afsluttet, når medlemmet efterfølgende afmelder sig på Jobnet.

• Tilmeldedatoen er (fortsat) den dato, der anvendes ift. frister for fx samtaler og cv-godkendelse.

Regler

Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.

Jobcentre skal som hidtil kunne registrere tilmelding og afmelding som jobsøgende.

A-kasserne kan, jf. BAB, som hidtil vælge at tilbyde den service at de tilmelder ledige medlemmer som dagpengemodtagere. A-kasserne skal som hidtil kunne afmelde et medlem som jobsøgende, og herunder tilmelde personen uden ydelse, hvis personen ikke længere er ledig eller hvis medlemmet ikke skal have / kan få a-dagpenge.

23.04.2024: A-kassen skal, jf. databkg. § 66, som hidtil - når dimittender begynder at modtage arbejdsløshedsdagpenge - sikre, at personen er registreret som dagpengemodtager med tilmeldekategorien dagpengemodtager.

15.08.2024: A-kassen skal, jf. databkg. § 129, som hidtil ved medlemstilgang og ved tilmelding som arbejdssøgende hente/læse en række oplysninger i DFDG. Det gælder bl.a. oplysninger om tilmelding som jobsøgende. Den nye a-kasse kan ikke påregne, at DFDG sender WSRM eller WSB om fx aktuelle tilmeldinger ifm. medlemstilgang

15.08.2024: I databkg. vil der blive indarbejdet bestemmelser om registrering af hændelsesdatoen.

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.

Serviceaftager skal overgå til ny REST snitflade, men kan i en overgangsperiode (indtil 2025-1) forblive på eksisterende SOAP service således, at serviceaftager mere frit kan tilrettelægge deres it-udvikling.

Perioden kan dog ændres, hvis der efterfølgende kommer forretningsændringer til servicen. En sådan efterfølgende ændring af perioden, vil fremgå i epic med de nye forretningsændringer.

Acc.kr. 1005.17.23.1 - Som STAR vil jeg have flyttet forretningsområdet for til- og afmelding som jobsøgende til forretningsdomænet (silo) VisiteringOgStatus inkl. at det lever op til de principper, der er fastsat

Løsningsmodel (internt STAR acc.kr.)

1005.17.23.2 - Som serviceaftager og STAR vil jeg have udstillet til- og afmelding som jobsøgende via ny REST snitflade med samme forretningslogik og operationer som den eksisterende SOAP service (UnemploymentEnrollmentService), dog udvidet med ny Update-funktion og hændelsesdato for tilmelding og med en sanering af kodelisten for ledighedsgrad)

Løsningsmodel

• Ny REST service i VisiteringOgStatus hvor det er muligt at tilmelde en borger som allerede har jobønsker

• Ny REST service i Komposit hvor man ifm. tilmeldingen kan oprette jobønsker

• Fejlkoder bevares

• Der ændres ikke i adgangsforhold til service/metoder 

• Tilmelding udstilles i VisiteringOgStatus.VisiteringOgStatusStatusService#GetPersonVisiteringOgStatusStatus med kun seneste tilmelding. I TilmeldingService findes GetTilmeldinger som er den fulde samling af tilmeldinger og GetTilmeldingshistorik.

• Ny forretning

  • Ny hændelsesdato (optionelt felt), der skal angive evt. anden dato (end registreringsdatoen) som tilmeldingen forretningsmæssigt skal være gældende gældende fra, selvom der som tilmeldedato kun kan registreres “dags dato”. Formålet er, at sagsbehandler (og STAR ifm. datagenopretninger) kan angive, hvornår tilmeldingen forretningsmæssigt burde have været gældende fra, selvom registreringen foretages “dags dato”. Fx hvis der har været it-problemer i lokale systemer eller i STARs systemer. Eller hvis a-kassen dispenserer fra kravet om tilmelding.

    • Validering ift. tilbagedatering af hændelsesdato:

      • A-kasser: Ingen begrænsning, da dispensationsbehovet for tilmelding ligge langt tilbage i fortiden

      • STAR: Ingen begrænsning (pga. testformål - og datagenopretninger)

      • Jobcentre:

        • Op til 7 dage før registreringsdato. Fejlkode: 100033 - “Hændelsesdato må ikke ligge mere end 7 dage tilbage i tid ved jobcenterregistrering”

        • Validering ift. registrering af hændelsesdato ved tilmelding af dagpengemodtagere: Jobcentret må ikke registrere hændelsesdato ved tilmelding af dagpengemodtagere. Fejlkode 1000xx - 'Hændelsesdato må for dagpengemodtagere kun registreres og opdateres af a-kassen og STAR'

      • Hændelsesdato må ikke ligge tidligere end seneste afmeldedato. Fejlkode: 100034 - “Hændelsesdato må ikke ligge i tidligere tilmeldeperiode”

  • Ny Update-metode: UpdateTilmelding til brug for

    • afmelding

    • fjernelse af fremtidig afmelding således, at der ikke (længere) teknisk foretages en afmelding og samtidig gentilmelding i disse situationer

    • opdatering af ledighedsgrad således, at der ikke (længere) teknisk foretages en afmelding og samtidig gentilmelding i de situationer, hvor ledighedsgraden skal ændres

    • Validering:

      • Hændelsesdato må ikke ligge tidligere end seneste afmeldedato på tidligere tilmeldeforhold (se fejlkode ovenfor)

      • Ved afmelding validerer DFDG for, at alene afmeldedato og afmeldeårsag angives / opdateres. Fejlkode: 100032 - “Det er ikke lovligt at opdatere øvrige felter ifm. en afmelding”.

      • Når afmeldedato er i fortiden må der ikke opdateres på andet end hændelsesdato og berigtigelseskommentar. Fejlkode 100030 - “Når afmeldedato er i fortiden må kun hændelsesdato og berigtigelseskommentar opdateres”

      • Afmeldedato kan kun opdateres, herunder slettes, hvis den er i fremtiden - fejlkode 100031 ‘Afmeldedato må kun opdateres eller slettes hvis den er i fremtiden’

      • Validering ift. registrering af hændelsesdato ved opdatering af tilmelding af dagpengemodtagere:

        • Hvis Hændelsesdato er registreret og jobcenteret kommer med en UpdateTilmelding for klientkategori (ClientCategoryTypeIdentifier) 1 (dagpengemodtager) med en anden hændelsesdato end der allerede er registreret i DFDG kastes fejlkode 1000xx - 'Hændelsesdato må for dagpengemodtagere kun registreres og opdateres af a-kassen og STAR'

  • Sanering af registrering af ledighedsgrad ved tilmelding således, at der ikke ved tilmelding længere skal sondres mellem “fuldt ledig” og “delvis ledig”.

    • [06.09.2024] Afgrænsning: Denne validering sker udelukkende på CreateTilmelding (dvs. hverken på UpdateTilmelding eller ifm. syge- /raskmelding)

    • [03.09.2024] Fejlkoder i den sammenhæng:

      • Til a-kasser: 9300 - "Ledighedsgraden kan ikke anvendes af a-kasser" og

      • Til jobcentre: 100045 - “Ledighedsgraden kan ikke anvendes af jobcentre”

VisiteringOgStatus.TilmeldingService

Ny REST service til oprettelse, opdatering og udlæsning af tilmeldinger: VisiteringOgStatus.TilmeldingService (2024-2)

STAR / DFDG anvender denne service internt til at registrere tilmelding, når der registreres tilmelding via Komposite.TilmeldingService med samtidig registrering af 'jeg-søger-job-som' stillingsbetegnelser og tilmelding. Eksterne aftagere kan også anvende denne service til at registrere tilmelding på borgere/medlemmer, der i forvejen har registreret 'jeg-søger-job-som' stillingsbetegnelser - og sagsbehandler ikke vil opdatere disse ifm. tilmeldingen.

CreateTilmelding og CreateTilmeldingMedIdentifier (30.04.2024)

Nye REST-metoder CreateTilmelding og CreateTilmeldingMedIdentifier til internt brug for tilmelding, kan kun kaldes af STAR.

[27.06.2024]

UpdateTilmelding - https://starwiki.atlassian.net/wiki/spaces/FYS/pages/4301553665/VisiteringOgStatus.TilmeldingService+Version+1+2024-2+UDV+tidl.+UnemploymentEnrollmentService+v+8+2023-1#UpdateTilmelding-(PUT-v1/Tilmelding/%7BtilmeldingId%7D-(tidl.-CancelUnemploymentEnrollment)

Nye valideringer:

• Se ovenfor under Ny forretning

Metoden har response med kvitteringstekst til visning for borger i snitflade som er udfyldt ved afmelding, eksterne kan se bort fra denne.

[27.06.2024]

Komposit.TilmeldingService - Komposit.TilmeldingService (2024-3)

Ny REST service til oprettelse af tilmeldinger med samtidig oprettelse af jobønsker: Komposit.TilmeldingService (Version 1, 2024-2) [UDV] (tidl. UnemploymentEnrollmentService v 8, 2023-1)

Internt i STAR bruges denne også til at kunne tilmelde og straksbooke en borger som tilmelder sig på Jobnet

Nye valideringer:

• Se ovenfor under Ny forretning

CreateTilmelding

Kan kaldes med eller uden id, DFDG tildeler et id hvis det ikke medsendes.

Metoden har response med kvitteringstekst til visning for borger i snitflade, eksterne kan se bort fra denne.

[27.06.2024]

WSRM og WSB udsendelse samt flow

[Tilføjet 02-05-2024]

Komposit.TilmeldingService.CreateTilmelding kalder først til JobSearch.CreateJoboensker og derefter til VisiteringOgStatus.Tilmelding hvis det foregående kald er gået godt. Man kan dermed risikere at kun Jobønskeoprettelsen går godt, det er ikke være et problem da man uden problemer kan gentage det fulde kald til Komposit.Tilmelding og genoprette Jobønsker. Hvis begge kald går godt returneres succes.

I forbindelse med oprettelsen af Jobønsker vil WSRM/WSB blive udsendt og tilsvarende ved tilmelding - selv om det samlede flow ikke er fuldført endnu. Da data er tilgængelige ved get når beskeder skaber dette efter vores bedste overbevisning ikke gener for aftagere.

1005.17.23.3 - Som serviceaftager vil jeg gerne beholde den eksisterende SOAP service (UnmeploymentEnrollmentService) uændret i en overgangsperiode indtil 2025-1 for at sikre en fleksibel overgang til ny snitflade

Løsningsmodel

• Eksisterende SOAP (UnmeploymentEnrollmentService) bevares uændret i en overgangsperiode indtil 2025-1 for at sikre en fleksibel overgang til ny snitflade

• Ekstern deltagelse i test af til- og afmelding ønskes - og af WSB / WSRM-beskeder

1005.17.23.4 - Som STAR vil jeg have dataleverancer i forhold til DOA tilpasset til det nye forretningsdomæne (silo)

Løsningsmodel (internt STAR acc.kr.)

• Initial load af data / Tilpasning af BI load til VisiteringOgStatus domænet (silo)

• TASS-Data til DOA påvirkes.

1005.17.23.5 - Som STAR vil jeg have at dokumentation for såvel servicelag og frontend lever op til STAR's principper på releasetidspunktet

Løsningsmodel (internt STAR acc.kr.)

• QA af regler fra kode mod dokumenteret regler og fejlkode

• Ajourfører dokumentation

Sider der skal rettes og QA er (liste er ikke udtømmende)

• Servicesnitflade 

1005.17.23.6 - Som STAR vil jeg have, at data er omfattet af dataløft og pseudonymisering mod testmiljøer

Løsningsmodel (internt STAR acc.kr.)

• Tilpasning af regler af for pseudonymisering og aftale hvornår data skal med i dataløft

• Systemforvalter tilretter pseudonymiseringsflow 

1005.17.23.7 - VisiteringOgStatus udstiller kodelisterne for til- og afmelding, herunder tilmeldekategorier og ledighedsgrad

Løsningsmodel 

• DFDG udstiller kodelister for 

  • Tilmeldekategori - ClientCategoryTypeIdentifierType

  • Ledighedsgrad - CurrentUnemploymentStatusTypeIdentifier

  • Afmeldingsårsag - RemovalCauseTypeIdentifierType

Flyttes til

• VisiteringOgStatus.CodeListService

  • Tilmeldekategori

  • Ledighedsgrad

  • Afmeldingsaarsag

28.06.2024: Bemærk at kodelisterne i test i 2024-3 vil bære de gamle engelske navne

[13.09.2024] Kodelisterne som VisiteringOgStatus overtager ansvaret for skifter til dansk navn i 2024-4 i alle REST services. Kodelistenavne og kontrakter er uændrede i SOAP og kodelisteværdierne berøres ikke af ændringen som dermed er non-breaking change.

VisiteringOgStatus - Tilmeldekategori

Ny kodeliste i VisiteringOgStatus - Tilmeldekategori

VisiteringOgStatus - Ledighedsgrad

Ny kodeliste i VisiteringOgStatus - Ledighedsgrad

Tilsvarende ændringer i DFDG (classic).CodeListService (version 5).CurrentUnemploymentStatusTypeIdentifier

Ledighedsgrad ‘Arbejdsfordeling’ kan som hidtil angives v/tilmelding gennem KSS, men ikke ved borgers tilmelding på Jobnet. Og heller ikke ved a-kassens registrering af tilmelding som jobsøgende.

Ifm. CreateTilmelding ([05.09.2024] fra Jobnet, jobcenter igsystemer og a-kassefagsystemer) anvendes fremover id 2-4. [05.09.2024] Hver aktør anvender de ledighedsgrader som aktøren må anvende.

[06.09.2024] Bemærk at der altså ikke er nogen validering på UpdateTilmelding da dette ville kræve en ensretning af ledighedsgrad over til sygemelding, som ikke er mulig

Ifm. sygemelding ([05.09.2024 og 10.09.2024] fra Jobnet, jobcenter fagsystemer og a-kassefagsystemer) anvendes som hidtil id 0 og 1 til angivelse af, om den sygemeldte er i delvis beskæftigelse eller fuldt ledig, da denne registrering af betydning for, om a-kassen skal udbetale a-dagpenge under de første 14 dages sygdom eller om borger skal modtager sygedagpenge (hvis betingelserne i øvrigt er opfyldt), jf. denne flowtegning i E 536.4 fra 2014-4.

(DAK har efter drøftelse med a-kasser bekræftet, at vi ifm. tilmelding ikke behøver sondre mellem fuldt og delvist ledig.)

VisiteringOgStatus - Afmeldeaarsag

Ny kodeliste i VisiteringOgStatus - Afmeldeaarsag

1005.17.23.8 - PersonStatusService (version 20) og PersonHistoryService (version 4) udstiller i en overgangsperiode oplysninger om til- og afmelding

/wiki/spaces/GI/pages/3690397697

GetVariablePersonStatus

PersonStatusService (version 20) udstiller i en overgangsperiode indtil 2025-1 oplysninger om til- og afmelding

PersonHistoryService (version 4)

GetPersonHistory

PersonHistoryService (version 4) udstiller i en overgangsperiode indtil 2025-1 oplysninger om til- og afmelding

1005.17.23.9 - Som aftager vil jeg kunne få besked om opdateringer til tilmelding med WSRM eller WSB og kunne hente en unik tilmelding baseret på id

Løsningsmodel

• Eksisterende WSRM’er om tilmelding og afmelding som jobsøgende opretholdes i en overgangsperiode

  • GetUnemploymentEnrollmentVersion4 på WsrmMessageService (version 10) og

  • GetCancelUnemploymentEnrollmentVersion4 på WsrmMessageService (version 10)

• Ny WSB: Tilmelding.wsb

• WSRM om fremtidig afmelding sendes som hidtil på tidspunktet for indberetning af opdateringen. Tilsvarende vil gælde for WSB om afmelding.

Udsendelse af WSRM og WSB som følger:

Ny Tilmelding.wsb

1005.17.23.10 - Død kode i DFDG, i forbindelse med til- og afmelding, fjernes

Løsningsmodel (internt STAR acc.kr.)

• Fjernelse af gammel og død kode i DFDG classic

1005.17.23.11 - Landssupport/LSS er skiftet over til at brug den nye REST-servicen ift. til- og melding , i stedet for UnemploymentEnrollmentService fra DFDG classic

Løsningsmodel (internt STAR acc.kr.)

• Landssupport/LSS er skiftet over til at brug den nye REST-servicen ift. til- og melding , i stedet for UnemploymentEnrollmentService fra DFDG classic

• Kode brugt i forbindelse med UnemploymentEnrollmentService er fjernet fra LSS

1005.17.23.12 - DFDG batchjobs vedr. til- og afmelding flytter til til forretningsdomænet (silo) VisiteringOgStatus

Løsningsmodel (internt STAR acc.kr.)

• DFDG-TASS-CancelEnrollmentForRelevantAbsenceTypes

• DFDG-TASS-CancelEnrollmentLetter

• DFDG-TASS-CancelEnrollmentSalarySubsidiaryEnded

• DFDG-TASS-CloseContactGroup1ForPersonsNotEnrolled

• DFDG-TASS-EndEnrollmentWhenFutureIllnessStarts

• DFDG-TASS-ReenrollWhenIllnessEndsLaterThanToday

• DFDG-TASS-ProcessFutureEnrollments

• DFDG-TASS-RunMTOccurence (skifter tilmelding fra tilmeldekategori ‘dimittend’ til ‘dagpengemodtager’ på dagpengeretsdato , dvs. ved opnåelse af 1 års anciennitet som medlem af a-kasse/a-kasser)

• DFDG-TASS-RunMTOccurenceIllDimittends

Se på TopDesk sag sammen med genimplementering af batchjob;

• S2312-626 Serviceeftersyn af DFDG-TASS-ReenrollWhenIllnessEndsLaterThanToday

1005.17.23.13 - Forfine DFDG-TASS-ProcessFutureEnrollments, når batchjobbet skal flyttes til nyt DFDG forretningsdomæne

Løsningsmodel (internt STAR acc.kr.)

• Hvis borger raskmeldes d.d. og har eller får et andet sygefravær, der er aktivt før DFDG-TASS-ProcessFutureEnrollments kører, skal batchjobbet ikke fejle, men blot springe over at forsøge at raskmelde den pågældende borger (FB 368766).

1005.17.23.14 - Som aftager vil jeg kunne abonere på WSB om Varslinger som afløsning for GetWarning WSRM

WSB Varsling som afløser for GetWarning WSRM. Den udsendes i denne release kun for WarningTypeIdentifier id’er relaterede til afmelding, dvs. hvor afmeldeårsag refereres i WarningTypeIdentifier

WSB Varsling oprettes:

1005.17.23.15 - Som borger vil jeg modtage tilmeldekvittering i Beskedbakken på Jobnet (frem for via alm mail)

Som borger vil jeg modtage tilmeldekvittering i Beskedbakken på Jobnet (frem for via alm mail).

1005.17.23.16 - Friholde Jobnet (classic) for ændringer ift. tilmelding og ledighedsgrad (04.09.2024)

Ved tilmelding fra Jobnet (Classic) igennem SOAP UnemploymentEnrollmentService sker konvertering så ledighedsgrad 0 (fuldt ledig) og 1 (delvist ledig) begge oversættes til 4 (ledig)

Særlige krav til test

19.06.2024 og 26.08.2024: Tabel opdateret

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

BI foretager initial load af forsørgelseshistorik i ydelsesudstilling silo. Der er ikke tale om konvertering i denne forbindelse da det er samme loadmodel som i den gamle forsørgelseshistorik på DFDG classic.

Efter idriftsættelse:

N/A

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder: Nej, flytning til domæne Ydelsesudstilling 

• Nye snitflader: Nej, flytning til domæne Ydelsesudstilling

• Nye komponenter: Nej 

• Nye miljøer: Nej 

• Nye teknologier: Modernisering 

• Nye aftagertyper: Nej 

• Eller afvigelser fra principperne: Nej 

• Eventuelle behov for reduktion af teknisk gæld skal afdækkes: N/A 

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: Jesper Brunholm

• Angiv dato for tjek: 17-4-2024

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.

Dette er ikke et nyt dataområde blot en flytning fra DFDG classic og til VisiteringOgStatus 

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

A-kasse filtrering i de nye getmetoder følger a-kasse filtreringen på deres soap-forgængere

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

Der ændres ikke på sagsbehandlerlogin ifm. omlægningen