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)

https://starwiki.atlassian.net/browse/VIR-1870

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

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

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

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.

Automatisk oversigt

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

Beskrivelse af epic

Denne epic implementerer forbedringer, som reducerer kompatibilitetsproblemer mellem VITAS, KSS'er og DFDG ActivityService. På møde mellem STAR, KMD og Schultz d. 24. februar 2022 blev følgende forbedringer aftalt:

• VITAS begrænser fritekstfelter til 2.000 tegn ved oprettelse af nye sager. Eksisterende sager har uændrede feltlængder, som kan være op til 4.000 tegn (FB 232258, FB 171457 m.fl.).

• VITAS må ikke returnere NULL i ActivityStatusCauseTypeIdentifier ved nye sager. ActivityStatusCauseTypeIdentifier udbygges med nye koder, som repræsenterer, 1) at bevillingen er lukket inden den er blevet godkendt, 2) bevilling er udløbet planmæssigt (FB 220307).

• VITAS forhindrer permanent fleksjob for selvstændige (FB 217619).

Forbedringerne er et led i den løbende tilpasning af VITAS til ActivityService, så KSS'ernes opgave med at mappe fra VITAS til ActivityService forenkles. Figuren herunder illustrerer samspil mellem VITAS, KSS'er og ActivityService, samt formål med data i VITAS hhv. ActivityService.

Open

Mange (måske de fleste?) tekster på bevillinger udarbejdes af sagsbehandlere på jobcentrene med henblik på at samme tekster kan anvendes både i dialog med virksomhed (VITAS) og i dialog med borgeren (ActivityService / Min plan). 

Ikke omfattede forbedringer

Epic'en adresserer ikke følgende sager i integrationen mellem VITAS, KSS'er og DFDG ActivityService, som fortsat er åbne:

971.30.1 ActivityStatusCauseTypeIdentifier har koder til ikke-igangsat og normalt udløb

ActivityStatusCauseTypeIdentifier har i dag fortrinsvis koder for afslutning af en bevilling af særlige årsager og disse er ikke tilstrækkelige til at repræsentere alle de tilstandsskifter, hvor VITAS sender WSRM'er til KSS. KSS ønsker altid - for de ordninger, som anvender ActivityStatusCauseTypeIdentifier - at modtage en værdi i ActivityStatusCauseTypeIdentifier og ønsker ikke at modtage NULL. ActivityStatusCauseTypeIdentifier skal derfor udbygges med nye værdier, som understøtter alle de tilstandsskifter, hvor VITAS sender WSRM'er.

VITAS har overordnet set 3 faser i en bevilling jf. nedenstående figur.

Open

ActivityStatusCauseTypeIdentifier får følgende nye koder:

VITAS mapning til ActivityStatusCauseTypeIdentifier

VITAS mapper til disse nye koder jf. nedenstående tabel:

BEMÆRK: Ikke alle ordninger anvender ActivityStatusCauseTypeIdentifier.

Observation til senere overvejelse sammen med KSS

OBS! Ikke del af denne epic.

VITAS bør ved evt. renovation udstille nye, eksternt rettet hændelser (ikke status) til KSS'erne fx med tilhørende eksterne tilstande:

Denne ændring er ikke relevant nu og skal analyseres nærmere inden beslutning. Formålet er at undgå at afkoble VITAS' interne tilstandshåndtering fra eksterne interessenter ( 

Brugervejledning om negative underretningspligtige hændelser fra jobcenter til a-kasse og a-kassens besvarelser (star.dk).

971.30.2 VITAS fritekstfelter er begrænset til 2.000 tegn ved nyoprettelse

VITAS anvender i dag oftest feltlængder på 4.000 tegn ved fritekstfelter. Det betyder, at virksomheder og sagsbehandlere kan indtaste tekster, der ikke kan lagres i ActivityService, som har følgende maksimale feltlængder:

MyPlanService

• Core-elementet

• CauseRemark: 1-2000 tegn

• ReasonForActivity: 1-2400 tegn

• ActivityDescription: 1-2000 tegn

VITAS skal fremover kun tillade feltlængder på max. 2.000 tegn ved nyoprettelse af sager (ansøgninger, bevillinger ...). VITAS ændrer ikke på eksisterende data, som fortsat kan være op til 4.000 tegn. VITAS implementerer derfor længdebegrænsningen ved frontend validering, mens backend valideringen stadig anvender 4.000 tegn. 

KSS vil opleve, at WSRM'er og webservices er uændrede og tillader fortsat længder på op til 4.000 tegn. KSS vil opleve at WSRM'er og webservicekald ved nye sager i praksis altid har længder på max. 2.000 tegn, mens  WSRM'er og webservicekald ved ældre sager kan returnere feltlængder på op til 4.000 tegn. KSS håndterer for lange tekster i forhold til ActivityService ved ældre sager. Dette princip er aftalt med KSS på mødet 24. februar 2022.

KSS kan evt. trunkere for lange data på ældre sager og henvise til VITAS, fx "... Teksten er beskåret, men findes komplet i VITAS, som sagsbehandleren har adgang til". Borgeren har ikke adgang til VITAS.

Konsekvens

Tidligere udvidelse omgøres:

971.30.3 VITAS tillader ikke permanent fleksjob for selvstændige

VITAS validerer at selvstændige ikke kan få permanent fleksjob, dvs. følgende kombination er ikke tilladt: FlexjobDurationIdentifierType type=2 og EmployedInOwnCompany=true

VITAS' mapninger af ophørsårsager

Når arbejdsgivere registrerer ophør på bevillinger, skal de (afhængig af ordning) angive årsag til ophør. Det gøres med følgende valg (Virksomhedspraktik, ,tilsvarende for Løntilskud og delvis for Voksenlærling):

Ved valg af "Den ansatte er ophørt før tid" udfyldes "Uddyb venligst årsagen" jf. ovenstående.

Årsag: Hvis KSS registrerer ophør i ActivityService med en ActivityStatusCauseTypeIdentifier for årsagerne vedr. "Den ansatte er ophørt før tid", udløser aktiviteten en NUP (Negativ Underretningspligtig hændelse) til a-kasserne, som kan påføre den berørte borger en sanktion. Det er kun jobcentre, som må udløse en NUP, det må arbejdsgiverne ikke. (Nogle) KSS'er opretter og opdaterer automatisk ActivityService baseret på WSRM'er fra VITAS, hvilket betyder, at arbejdsgiverens registrering i VITAS kan udløse en NUP og det må ikke ske. STAR kan derfor ikke åbne op for mapning af disse ophørsårsager før alle KSS'er har givet tilsagn om at de aldrig registrerer en ActivityStatusCauseTypeIdentifier i ActivityService uden at det er godkendt af en sagsbehandler i jobcenteret. Det er tidsmæssigt ikke muligt at aftale dette tilsagn til release 2022-3. Det vil være muligt at aftale dette med KSS'er til en senere release.

Se også: https://star.dk/media/17661/2021_04_12_vejledning-om_underretningskoder_tilbagemeldinger_2021_1.pdf

For release 2022-3 gælder derfor følgende mapninger fra arbejdsgiverens registrering af årsag til ophør til ActivityStatusCauseTypeIdentifier i WSRM:

Mapninger markeret med gult er nye i 2022-3, mens øvrige mapninger er uændrede i forhold til foregående release.

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 

Mapning til ActivityService implementeres i en særskilt komponent i VITAS således at kendskab til ActivityService ikke spredes til hele VITAS applikationen. Derved vil det også blive lettere at omlægge til eventbroker på et senere tidspunkt, når / hvis en sådan implementeres hos STAR.

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.