Beskrivelse af epic

ISB: 903 Generation 2.0 af Min plan

ISB: 936 LAB - Min plan LAB relaterede ændringer

ISB 916 Mere enkle og skærpede sanktioner, styrket kontrol med snyd og færre fejludbetalinger

936.7.1 Som borger vil jeg kunne se de historisk Min plan versioner

Ved overgangen fra Min Plan 1.0 til Min Plan 2.0 skal borger fortsat kunne se de historiske planer. Og historiske planer vil blive vist for borger, om end lettere modificeret forsåvidt angår udtryk. Indholdet - dvs data - er dog stadig de samme, da snitfladerne ikke er ændret. 

Uddybning: Der foreligger ikke gemte udgaver af Plan PDF'er. De dannes derimod når de kaldes. Og de vises derfor med det indhold der returneres fra DFDGs snitflade, i den skabelon, som nu en gang er på dannelsestidspunktet er gældende. En plan fra 2014 vil således have et anderledes udtryk end selvsamme plan vil have, hvis den dannes nu. Indholdet er dog det samme omend det måske er struktureret anderledes. Mere herom i afsnit 936.7.6

936.7.2 Mål for jobparate, dagpengemodtagere og ledighedsydelsesmodtagere angives og vises på niveau 3

Målgrupperne Jobparate Kontanthjælpsmodtagere og dagpengemodtagere kan have planer af forskellig type hvoraf langt størstedelen har en Jobplan. For dem er det i dag muligt at oprette fritekstmål og mål på overordnede discokoder (niveau 1 og 2) men over 80% af målene er konkrete stillingbetegnelser.

Det ønskes at der fremover kun benyttes specifikke stillingsbetegnelser, dvs. Discokoder på niveau 3 på disse målgrupper. Dermed afskaffes planbeskrivelsen for disse målgrupper, da det ikke vil blive vist i brugergrænsefladen for borgeren.

Der skal være mere sammenhæng mellem borgerens ”Jeg søger job som” og planens ”Jobmål”. Dette skal ske ved at sagsbehandler ved planens udfærdigelse, skal tage udgangspunkt i borgerens ”jeg søger job som” og benytter konkrete stillingbetegnelser, som borger kan søge nu.

Såfremt borger har et mere langsigtet jobmål, som rækker ud over nuværende kompetencer, skal det beskrives i aftalefeltet, på seneste jobsamtale.

Såfremt sagsbehandleren sammen med borgeren ændrer eller laver nye ”Jobmål” som ikke er i borgerens ”Jeg søger job som”, skal borger på Jobnet motiveres mundtligt af sagsbehandleren til at medtage disse i borgerens ”Jeg søger job som”, således der er den bedst mulige overensstemmelse. 

Bemærk: For sagsbehandleren i jobcentret vil det efter releasen være muligt at hente eksisterende (tidligere) mål, også selvom de ikke overholder de fremadrette krav, men sagsbehandleren skal være opmærksom på at selvom de kan hente mål, vil de få en fejl hvis de forsøger at gennem noget for disse målgruppe ud over discokoder på niveau 3.   

PlanService (version 4)

SavePlanObjective

Der laves valideringer på ,at for jobparate og dagpengemodtagere m.v. skal jobmål angives efter discokode niveau 3.  

Forretningsregler (ny)

• Validering på mål skal være discokode niveau 3 skal ske for 
  • Dagpengemodtagere (kontaktgruppe Id 1)
  • Jobparat kontanthjælpsmodtager (kontaktgruppe Id 2, person kategori Id 4)
  • Jobparat kontanthjælpsmodtager omfattet af introduktionsprogrammet (kontaktgruppe Id 3, person kategori Id 4)
  • Jobparat integrationsydelsesmodtager (kontaktgruppe Id 26, person kategori Id 4)
  • Jobparat integrationsydelsesmodtager omfattet af integrationsprogrammet (kontaktgruppe Id 27, person kategori Id 4)
  • Fleksjobvisiteret (kontaktgruppe Id 7, person kategori Id 1)
• Eksisterende registreringer på borger skal kunne hentes ud selvom disse mål ikke overholder ovenstående

Jobnets visning af mål

For uddybning af Jobnets håndterering af mål: Se acceptkriterie 936.7.5, underoverskrit: "Mål (jobmål og uddannelsesmål)", hvor mål indgår som nummer to komponent i Min Plan.

936.7.3 Som borger vil jeg have at de beskeder jeg får vist på Min side på Jobnet og de beskeder jeg modtager på SMS og/eller e-mail er tilpasset mit flow omkring køleskabsplanen

Beskeder på Min side (grøn boks)

Hændelsesliste

Denne liste er ajourført i epic 903.5 Generation 2.0 af min plan - fase 2 (Visning af evaluering for jobparate m.fl.)

Øvrige grønne bokse

• Kvitteringsboks/kvitteringsbeskeder se epic 903.3 Generation 2.0 af Min plan - Fjernelse af kvitteringer og vejledningstekster

SMS og/eller e-mail - huskeservice (tekster og afsendelse) 

Afsendelse i forbindelse med Rehabiliteringsforløb (SMS/e-mail)

Når borger er et rehabiliteringsforløb og befinder sig i det afskærmede Jobnet, skal borger ikke have beskeder, der påminder borgeren om, at der skal kvitteres for Min plan.

Forretningsregler for udsendelse af beskeder vedr. Min plan generelt

• Kvittering for Min plan (GroupId 12, TextId 3) og (GroupId 12, TextId 4, 5) udgår 
• Husk at læse din plan på Jobnet(JobplanDeadlineWarningNotification) (GroupId 4, TextId 5) og (GroupId 6, TextId 4) udgår

Følgende Min plan beskedtekster ændres ikke:

• Ny Min plan på Jobnet(GroupId 6, TextId 9 og 10), (GroupId 7, TextId 4), (GroupId 12, TextId 0), (GroupId 12, TextId 1 og 2)
• Husk frist på uddannelsesplan (GroupId 6, TextId 7 og 8) og (GroupId 7, TextId 3)
• Besked til uddannelsesindtution ((GroupId 9, TextId 0, 1 og 2)     

Forretningsregler for udsendelse af beskeder vedr. Min plan og rehabiliteringsforløb

• Når en borger har et rehabiliteringsforløb i en af følgende status (RehabilitationProcessStatusTypeIdentifier)
  • "Forberedende del" (Id 1)
  • "Forberedende del videregivet fra Jobcentersystem" (Id 7)
  • "Forberedende del afsluttet" (Id 2)
  • "Indstillet" (Id 3)
  • "Indsats igangsat" Id 4)
    
• Og borger er fritager for selvbook eller ikke har pligt til selvbook (PersonExemptTypeIdentifier - Pligt til Selvbook (Id 2))
• Skal der ikke sendes Min plan beskeder (SMS eller e-mails)
  Beskeder der ikke skal sendes vedrørende: (rød farve betyder, at borger i et rehabiliteringsforløb og er i det afskærmede Jobnet jf. ovenstående ikke skal have beskeden, orange farve betyder, at teksten skal tilrettes)
  
  • Husk frist på uddannelsesplan (GroupId 6, TextId 7 og 8) og (GroupId 7, TextId 3)  
  • Ny Min plan på Jobnet (GroupId 6, TextId 9 og 10), (GroupId 7, TextId 4), (GroupId 12, TextId 1 og 2), (GroupId 12, TextId 0)
  • Hvad med CV sms'er f.eks. (GroupId 7, TextId 1 og 2) skal de sendes ved rehab? 

Følgende Min plan tekstsituationen rettes:RehabilitationProcessStatusTypeIdentifier

• Ny Min plan på Jobnet MÅSKE (GroupId 12, TextId 0)

For nye beskedtekster se SMS og e-mail tekster samt digital post

936.7.5 Som borger på Jobnet vil jeg kunne se min plan i Min Plan 2.0

Hvor det i 2019-1 releasen alene var Jobparate kontanthjælpsmodtagere og -ansøgere uden integrationskontrakt, der gjorde brug af Min Plan 2.0 er Min Plan 2.0 nu for alle borgere.

Der er sket en række udvidelser og tilpasninger. Først og fremmest holder Jobnet ikke længere nogen logik i forhold til planer eller plantyper. Jobnet viser de data DFDG kommer med på snitfladen og det er DFDGs ansvar at foretage valideringer. Dette har forsimplet Min Plan betydeligt. 

Dernæst er der kun én Min Plan. Hvor 2019-1 bød på forskelle i Min Plan for borgere med RehabilitationProcessStatusTypeIdentifier = 4 (dvs. borgere i det afgrænsede Jobnet med "Igangsat indsats") og Jobparate Kontanthjælpsmodtagere i Min Plan 2.0, styret af Jobnet logik, så er der (næsten) ingen logik til styring heraf i dag. I 2019-1 måtte et jobmål for førstnævnte fx kun være fristekst (custom) mens Jobmålet for sidstnævnte kun kunne være discoams kode (stillingsbetegnelse). I den nye plan vises de Jobmål, som DFDG lader slippe igennem valideringen for borgeren uanset borger bruger Min Plan 2.0 i det afgrænsede Jobnet eller i det store Jobnet. Det samme gælder for de øvrige elementer i planen.


For at alle borgere kan se deres planer i Min Plan 2.0 er det nødvendigt at udvide planen med en række nye moduler. Jobnet viser dog kun moduler, hvis der for borger i den pågældende plan er data til modulet. Der eksisterer derfor ikke længere en "plantype" i Jobnet regi og en definition af hvilke moduler der skal være - blot en "Min plan". Dynamikken i planen kan godt gøre det svært at danne et over indhold og rækkefølge. Derfor er, for overblikkets skyld, herunder gengivet de mulige moduler og rækkefølgen i hvilken de vil fremtræde.

Bemærk: Tekster og billeder i Epic er vejledende - modulerne kan i deres implementerede udgaver have et andet udseende og en anden ordlyd. Se de enkelte userstories for detaljer. Tekst angivet i acceptkriterier rangerer over wireframes.

Alle skal have vist min plan 2.0

I 2019-1 var Min Plan 2.0 kun for Jobparate kontanthjælpsmodtagere/-ansøgere uden integrationskontrakt. Fra 2019-2 LAB er Min Plan 2.0 for alle og Min Plan 1.0 vil ikke længre være tilgængelig. I det følgende redegøres for hvilke komponenter der er udviklet for at kunne imødekomme dette. Den eksisterende kode er dog også tilrettet, således at alle links i kalender, detaljevisning, mentorordning, menupunkter, notifikationsbokse mv. som før pegede på Min Plan 1.0 nu peger på Min Plan 2.0. Se JOB-199 Som borger vil jeg ved klik på menupunkt "Min plan" have vist min Plan 2.0 og JOB-186 Tilretning af Jobnet, så Min Plan 1.0 links peger på elementer i Min Plan 2.0 for detaljer.

Kontrakt

Første modul i ovennævnte oversigt over Min Plan 2.0 er "Kontrakt". Hvor "Integrationskontrakten" (der nu hedder "Kontrakt") i Min Plan 1.0 var en integreret del af GUI'en, vil borgere med kontrakt i Min Plan 2.0 kun kunne se den via PDF'en. For borgere med kontrakt vil øverste del af Min Plan 2.0 se ud som følger:

 

For borgere uden kontrakt vises modulet om kontrakt ikke. Disse borgere skal dog stadig kunne hente PDF'en af deres seneste plan og øverst af deres Min Plan 2.0 fremgår derfor en knap "Hent som PDF" til venstre for knappen "Udskriv".

Linket "> Vis plan inklusiv kontrakt" og knappen "Hent som PDF" henter begge seneste plan som sagsbehandlerne også ser den. Knappen "Udskriv" danner PDF af GUI.

Se story for detaljer: JOB-135 Som borger vil jeg se min seneste Min Plan PDF, som sagsbehandler ser den.

PDF tilretninger 

PDF'en tilrettes dog også, så den bedre afspejler det sprog der anvendes i Min Plan 2.0. Sigtet her er, at sagsbehandler og borger skal have lettere ved at tale sammen, når en fælles terminologi anvendes i PDF og Jobnet. Konkret tilrettes labels ordlyd på den eksisterende PDF. Bemærk, at dette tillige slår igennen på de gamle PDF'er, da PDF dannes i realtid som ikke foreligger i en egentlig historisk udgave.

JOB-179 Ny mapper i til Plan 2.0 GUI og PDF (Teknisk userstory der er nødvendig for at kunne genbruge gamle elementer i ny kontekst).
JOB-180 Tilpasninger af Plan PDF i det omfang det har kunne lade sig gøre, er ordlyd på labels rettet og data sammensat så det fremgår på samme måde som Jobnet.

Mål (Jobmål og uddannelsesmål)

Jobnet viser ukritisk, dvs. uden logik til styring af hvad der skal vises, de mål der måtte være for en borger på DFDG snitfladen. Jobnet har dog logik til sikring af, at en evt. angivet sorteringsrækkefølge på borgers mål overholdes. Eksemplevis kommer uddannelsesmål nederst og grupperet under en overskrift "Udannelsesmål" uanfægtet prioriteringsrækkefølge. 

Består en borgers mål alene af fritekst mål, vil de fylde hele bredden på skærmen. Er der blandede discomål og fritekstmål, vil discomålene have knap til Find Job i en kolonne til høre og da vil fritekst ikke blive skrevet ud i fuld bredde. teksten skrives altså ikke ind under knappen.
Find Job knappen linker til den respektive disco kode på Find Job, hvor job i hele landet, der matcher koden, vises.

Der vises maksimalt 3 jobmål i modulet. Er der mere end 3 jobmål, skal elementet foldes ud før resten kan ses. Har et tekssmål mere end 5 linjer, skal det tillige foldes ud før al tekst vises.  

Det redesignede Jobmåls modul er implementeret ind i det afgrænsede Jobnet såvel som på Min Plan 2.0. I praksis er der ingen forskel.

Se mere i JOB-181 Som STAR ønsker jeg, at Jobmålselement i min plan 2.0 tilpasses, så den kan rumme alle måltyper.

For at jeg kan nå mit mål, har vi aftalt

Planbeskrivelsesfeltet kan ikke længere udfyldes for alle borgere. DFDG validerer herfor og afviser, hvis felt ikke er berettiget jf. kontaktgruppe. For de borgere der kan få feltet angivet, vil feltet i Min Plan fremgå under en overskrift "For at jeg kan nå mit mål, har vi aftalt". For borgere der har Plan i det afgrænsede Jobnet, dvs. borgere med RehabilitationProcessStatusTypeIdentifier = 4, vil et evt. angivet plandescriptionfelt fremgå under overskriften "Forløbets formål". Plan 2.0 har altså minimal logik i Jobnet her og er ikke ens i de to situationer.

Er teksten længere end 3 linjer, fremkommer et link "Vis mere". Ved klik på "Vis mere" vises hele teksten og et link "Vis mindre" fremkommer.

Har borger ingen data i Plandescrription felte på responset, fremgår feltet ikke af GUI. 

Se mere i JOB-204 Som borger med min plan vil jeg kunne se PlanDescription, hvis feltet foreligger.

Uddannelsesmoduler

Funktionaliteteten i uddannelsesplanens trin 1-4 er uændret. Der er dog sket en del styling, da min Plan 2.0 er responsiv og designet derfor skal kunne tilpasse sig alt fra mobiltelefoner til desktop PC'ere. Der er fortsat 4 trin og de kommer i den kronologiske rækkefølge de hele tiden er kommet i, men som noget nyt vises nu kun ét trin ad gangen. Det fremgår ikke hvor mange trin der er. Eller hvilket trin borger er på. Dette har været et ønsket forårsaget af, at borgere følte, at de sad fast, når de var lang tid på et trin og kunne se flere trin foran sig.
Detaljeret gennemgang af de enkelte trin kan ses her: 

Valg af uddannelsesønsker (tidligere trin 1): /wiki/spaces/ISB/pages/1015349366

Angivelse af uddannelsesønsker (tidligere trin 2): JOB-171 Som ledig med uddannelsespålæg ønsker jeg i min plan 2.0 at kunne angive mine uddannelsessteder til min sagsbehandler (trin 2)

Angivelse af status på optagelse (tidligere trin 3): JOB-175 Som ledig med uddannelsespålæg ønsker jeg i min plan 2.0 at kunne angive status på optagelse på uddannelse til min sagsbehandler (trin 3)

Beskrivelse af uddannelsepålæg (tidligere trin 4): JOB-176 Som sagsbehandler ønsker jeg at kunne informere borgere med uddannelsespålæg om, at jeg har sendt en beskrivelse af deres uddannelsespålæg til deres kommende uddannelsessted (trin 4)

Seneste aftale med Jobcenter/a-kasse

I 2019-1 versionen af min plan, blev seneste aftale med jobcenter implementeret. Nu da Min Plan 2.0 åbnes for alle, kan myndigheden a-kasse tillige komme i spil. Har borger derfor en "seneste aftale med a-kasse" skal mødereferatet fra denne fremgå af planen. Har borger både en seneste aftale med jobcenter og a-kasse, skal jobcenteret stå øverst.

Detaljer kan ses i JOB-170 Som borger med plan vil jeg kunne se min seneste aftale med a-kasse.

Rummer referatet af aftalen med jobcenter eller a-kasse mere end 3 linjer, skal teksten afbrydes med 3 punktummer og et link "Vis mere" skal fremkomme. Ved klik foldes elementet ud, så resten af teksten vises og et link "Vis mindre" vil fremkomme. Funktionaliteten er indarbejdet i "Seneste aftale med a-kasse" via ovennævnte Job-170. I "Seneste aftale med jobcenter", der i 2019-1 koden viste hele refereatet med det samme, er funktionaliteteten med folde ind/ud ved mere end 3 linjers referat tilknyttet via JOB-125 Elipsis på 'Seneste aftale'.

Listevisning af aktiviteter, møder mm.

I Min Plan 2.0 i 2019-1 versionen var listevisning af borgers aktiviteter markant anderledes end tidslinjens repræsentation af samme data. Hvor tidslinjen brugte 3, 6 eller 12 måneder og frem- og tilbagepile, der skubbede visningen frem eller tilbage i tid, så havde listevisningen to muligheder for visning i en dropdown: "Alle aktiviteter/møder over al tid" eller "Alle igangværende/kommende aktiviteter/møder".

I 2019-2 LAB udgaven er koden tilrettet, så listevisningen styres af de samme filtre som tidslinjen, altså med visning af data for 3, 6 eller 12 måneder og frem- og tilbagepile til at skubbe visningen i tid. Borger kan sømløst springe imellem de to views, der reelt blot er forskellig repræsentation af de samme data. Se mere under /wiki/spaces/ISB/pages/1012727903

Jobcenters krav til jobsøgning

I 2019-1 releasen blev jf. /wiki/spaces/ISB/pages/891617666 udfærdiget et modul til visning af a-kassens krav til borgers jobsøgning. Samme elementer anvendes i 2019-2 til at kunne vise Jobcenters krav til borgers jobsøgning via JOB-165 Jobcenters krav til borgers jobsøgning. Elementet tilgås via tidslinjen eller via listevisning. Ved tidslinjen klikkes på den grønne bjælke hvorved krav vises i modal. Jobnet har ingen logik til visning, men viser elementer for de krav, som der er data til på snitfladen fra DFDG.

Sletning af standardelementet Jobsøgning

For borgere med Min Plan 2.0, har der indtil 2019-2 LAB været vist et standard været vist et element "Jobsøgning". Ved klik på elementet i tidslinjen eller ved visning på listevisning har budskabet til borger været, at borger "hele tiden skal søge efter job". Elementet er nu fuldt erstattet af ovennævnte "Jobcenters krav til jobsøgning" og tidligere udviklede "a-kasses krav til jobsøgning" og er derfor slettet fra koden. Der foreligger således ikke længere et generelt formuleret krav om jobsøgning straks borger melder sig ledig. Krav slår først igennem, når de eksplicit er formuleret af Jobcenter/a-kasse. Se mere i JOB-189 Sletning af standardelementet Jobsøgning.

Mindre tilretninger

Der har været et ønske om bedre at kunne skelne brødtekst fra overskrift i listevisning i Min Plan 2.0, da alt i 2019-1 udgaven af denne var meget "hvidt i hvidt". Men /wiki/spaces/ISB/pages/1049329769 introduceres farver, for bedre at kunne skelne.

På tekstbokse med meget tekstindhold, har det været et ønske - uanset visning sker på mindre devices eller på desktop - at kunne lade antallet af linjer være den styrende parameter for, hvorvidt tekst skulle "forkortes" med 3 punktummer og suppleres med "vis mere/vis mindre" link. En komponent der kan imødekomme dette er derfor udviklet i JOB-126 Angular komponent til intellisense. Komponenten kan tages i anvendelse hvor funktionaliteten ønskes implementeret (I Angular kontekst). Og dette er sket flere steder i Plan 2.0.

Som følge af ændringer i DFDG XML namespaces på en række service, hvoraf Jobnet er påvirket på 

• PersonActivityStatusService v. 2
• JobnetMyPlanService v. 3

er i userstory JOB-313 Efterleverance: Nyt namespace på en række services ajourført, så namespace i Jobnet passer til det af DFDG anvendte. 

936.7.6 Som borger og sagsbehandler vil jeg have en opdateret PDF udgave af detaljeret PDF inkl. alle de dele der i dag er (aktiviteter, mål, integrationskontrakt, fravær, CV m.v.)  

Layout i PDF tilrettes så borger og sagsbehandler nogenlunde ser det i samme struktur med samme navngivning (Jobnet). Evalueringer medtages ikke i sagsbehandler PDF

Hensigten er, at det skal være lettere for sagsbehandler og borger at tale sammen, når det de ser er det samme og det i ord afspejler terminologien på Jobnet, som sagsbehandlere fra 2019-1 ligeledes har adgang til at se. 

936.7.7 Som STAR vil jeg have at andre systemer/myndigheder end Jobcentersystemerne kan oprette/opdaterer aktiviteter i DFDG

Bemærk: Dette acceptkriterie er at lukke op for muligheden for at andre systemer og myndighedder kan registrerer aktiviteter. Det ligge ikke i dette acceptkriterie at der forretningsmæssigt lukkes op. Dette vil ske i separate acceptkriterier i andre epic's 

/wiki/spaces/GI/pages/839483393

Se /wiki/spaces/ISB/pages/1192493156 for resultat af SPIKE  DS-790 - Getting issue details... STATUS

Tilladte organisationer

• STAR, JobCenter, A-kasse, AndenAktør, Kommune
  Udvidelse i forhold til i dag med kommune. A-kasse har hele tiden haft adgang til at oprette, opdatere og hente, med forretningsmæssigt har de aldrig lavet oprette eller opdatering

Det er ikke tænkt at der sker snitfladeændringer i ActivityService i denne forbindelse.

CreateActivity

Forretningsregler (udvidelser i forhold til idag, eksisterende forretningsregler der ikke er nævnt her bibeholdes uændret):

• Tilladte organisationer
  • STAR, JobCenter, A-kasse, AndenAktør, Kommune
• A-kassen må oprette alle aktivitetestyper bortset fra afholdelseskategorien (CourseTypeIdentifier) = Id 38 "Andet" og kursusallokering (CourseAllocationTypeIdentifier) = Id 9 "Andet"
• JobCenter, A-kasse, AndenAktør, Kommun må oprette alle aktivitetestyper bortset fra afholdelseskategorien (CourseTypeIdentifier) = Id 52 "A-kasse aktivitet" og CourseAllocationTypeIdentifier = Id 16 "A-kasse aktivitet"

UpdateActivity

Forretningsregler (udvidelser i forhold til idag, eksisterende forretningsregler der ikke er nævnt her bibeholdes uændret):

• Tilladte organisationer
  • STAR, JobCenter, A-kasse, AndenAktør, Kommune
• Uanset hvem der har oprettet en aktivitet, kan systemer / myndigheder der har adgang til borgeren og den pågældende aktivitet rette i den pågældende aktivitet.
  • Borger egen jobcenter vil således altid kunne rette alle aktiviteter. 
  • A-kasse og Kommune bør dog kun rette i de aktiviteter de selv har oprettet (DFDG validere ikke for dette, da det ikke kan afvises at der vil være situationer hvor dette kunne være relevant)

GetActivities, GetActivity

Forretningsregler (udvidelser i forhold til idag, eksisterende forretningsregler der ikke er nævnt her bibeholdes uændret):

• Tilladte organisationer
  • STAR, JobCenter, A-kasse, AndenAktør, Kommune

GetCompanyActivitySummaries og GetActivitiesByJobCenter

Forretningsregler (udvidelser i forhold til idag, eksisterende forretningsregler der ikke er nævnt her bibeholdes uændret):

• Tilladte organisationer
  • STAR, JobCenter, AndenAktør
    A-kasse og Kommune har ikke adgang til disse metoder.

CodeListService (Version 5)

CourseTypeIdentifier

WSRM beskeder

• Der sendes WSRM på alle ændringer til Jobcenter og evt. a-kasse efter de eksisterende regler og eksisterende WSRM beskedtyper, dog sådan at CourseTypeIdentifier = 52 også sendes til a-kassen
  Er der behov for at andre kommunale eller jobcentersystemer skal have WSRM beskeder sker dette vha. skyggekøer

/wiki/spaces/GI/pages/1358858445

GetActivityGenerelEventVersion1 og GetActivitySpecialEventVersion1

Bebeholdes uændret men på disse er det ikke muligt at se hvilket system der har lavet aktiviteten.

GetMyPlanVersionNotificationEventVersion1

Der sker ingen ændringer til denne da man allerede kan se hvem (hvilken myndighed) der er ansvarlig for seneste version. 

/wiki/spaces/GI/pages/863961613

GetActivityGenerelEventVersion2 og GetActivitySpecialEventVersion2

Løftes til version 2, så de følger den nye WSRM-struktur i WsrmMessageService v11 og medtager bl.a. ClientSystemTypeIdentifier, således at WSRM-aftagerne kan se, om de selv eller et andet system har oprettet en given aktivitet.

I GetActivityGenerelEventVersion2 og GetActivitySpecialEventVersion2 anvendes kodelisten JobOrderTypeIdentifier fortsat til elementet JobTypeIdentifier (ændring af  elementnavnet sker ikke i denne nye version af WSRM'erne).

I denne forbindelse laves ikke tynde WSRM, da der ikke laves om i snitfladen.

936.7.8 Som STAR vil jeg have en slankning af PSS mht. aktiviteter og Min plan

BEMÆRK: Dette acceptkritere er flyttet til 936.10 Forenkling af Plan i Min plan universet. Dette har ikke konsekvenser for aftagere, da det det er en forberedelse til senere release of der ikke fra STAR side har være planer om i 2019-2 at få aftagerne til at skifte fra PersonStatusService  

936.7.9 SPIKE - Som borger vil jeg undgå at sagsbehandler laver kopier af allerede eksisterende aktiviteter.

I forbindelse med at VOA ofte finder at sagsbehandlerne i jobcentrer er kommet til at oprette flere kopier af den samme aktivitet er der behov for at hjælpe sagsbehandleren til at undgå dette fordi:

• Der er ingen grund til at sagsbehandler laver det samme arbejde flere gange
• DFDG får dårlig datakvalitete der bl.a. betyder at
  • VOA får samme aktivitet talt med flere gange / er nød til at have speciel logik der sorterer dobbeltindberettede aktiviteter fra
  • Borger på Jobnet får vist flere udgaver af samme aktivitet

Før løsningsmodel vælges (DFDG eller KSS validering) undersøges omfang Jvf. VOA er der 12.000 tilfælde det sidste halve år se https://manuscript.star.dk/f/cases/133829/Dobbeltregistreret-aktiviteter-tilbud-fra-sagsbehandler-i-JC

DFDG ser på data og vil komme med forslag til DFDG validering 

Implenteringen af valideringen sker i E 936.10 (2019-3 LAB). Se afsnit 936.10.8.

Særlige krav til test

Konsekvenser for drift

<Her beskriver PO/FA konsekvenser for løsningen efter idriftsættelse.>

Arkitektur- og implementeringsnoter

Der røres ved den eksisterende løsning for PDF dannelse og denne er på arkitektur "obslisten", da modellen for denne ikke er særlig god. Det er dog ikke i denne epic regi at ændre i denne model, da Jobnet alene lave nogle designændringer i PDF.

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

Kendte udeståender fra udviklingsfasen

Link til søgeresultat fra FogBugz på epic-nummer:

User stories

User stories er kun til interne brug for STAR’s leverandører.

Konsekvenser i forhold til folketingsvalg

Her beskrives hvilke konkrete konsekvenser og handlinger der er fortaget i regi af denne epic for at sikre at evt. ændringer pga. forketingsvalg i forhold til den forventede release i 2019-2 kan håndteres af alle interessenter.

Herunder:

• Model i STAR denne epic er unde LAB branch
• Konsekvenser KSS og a-kasse og deres tilsagn er her alene de generelle forhold omkring LAB's release