925.1 - Diverse DFDG og LSS fejlrettelser i 2019-1
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
| Page Properties | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Table of Contents |
|---|
Versionsnummerering
...
Oversigt over berørte web services
Andre sager
Manuscript 131227 - Anmeldelsesdato for 'sygdom - sygemelding' må ikke være fremtidig
- IllnessCompositeService.CreateIllness og
- IllnessCompositeService.UpdateIllness
så NotificationDate ikke kan være fremtidig, dvs. at NotificationDate ikke må ligge efter d.d., men skal være d.d. eller tidligere.
Formål med ændringen:
Oversigt over sager der indgår i epic
Denne sag løses ved at udvide denne liste så valideringen også kommer til at omfatte kontaktgrupperne 14-23.
IllnessCompositeService
- CreateIllness
- UpdateIllness
Snitflade | Serviceaftager der er berørt | Bemærkninger | |||||||||
DFDG | Jobnet | Plannersystemer | KSS | A-kasse | Ydelsessystem | JobKon | Andet | ||||
TransferDataService | X | X | Ikke snitfladeændringer sag 126762 | ||||||||
IllnessRecoveryInformationService | X | X | X | Ingen snitfladeændringer sag 93311 | |||||||
IllnessCompositeService
| X | x | x | Ny fejlkode ¤¤¤¤9362 Sag 131227 |
Beskrivelse af epic
Konkrete FB-sager der kandiderer til løsning – eller som er løst til 2018-4 fremgår af bilag til epic 925.1 (regneark på dokumentationsarkivet – 925.1 Manuscript bilag 2019-1.
Sager relateret til DFDG flytte-batchjob (CPR-flytning)
Overordnet er problemet at DFDG ved modtagelse af en flyttemeddelelse fra CPRregisteret sammenligner jobcenter for den angivne nye adresse med aktuelt jobcenter i DFDG, og konstaterer at der ikke skal sættes gang i flytteflow til nyt jobcenter hvis det viser sig at borger tilsyneladende er flyttet indenfor samme kommune.
For at tage højde for at der skal laves flytteflow når nyt jobcenter har trukket borgeren til sig inden CPR flytningen, ændrer vi nu, så DFDG ved CPR-notits om flytning undersøger om der er sket et jobcenterskift til ny kommune inden for den seneste uge, og i så fald sætte flytteflow i gang.
Flytteflow er beskrevet på wiki: Borger flytter til ny kommune
Manuscript 126762 - Uønsket overlevering af PersonCategory fra fraflyttet jobcenter
Ved cpr-flytning til en ny kommunen ønskes det, at visitering nulstilles til "ikke-visiteret".
Hvis jobcenter i den nye kommune har trukket borger (ændret jobcentertilknytning til den nye kommune) skal borger kun sættes til ikke-visiteret, hvis det nye jobcenter endnu ikke har registreret en ny visitering.
Det skal gælde for kontanthjælps-, uddannelseshjælps- og integrationsydelses kontaktgrupperne.
Fraværene i nedenstående liste er ulovlige i kombination med visitationkategori (PersonCategory) Ikke Visiteret. Hvis borger har et af disse fravær vil PersonCategory derfor ikke blive nulstillet.
- 2 'MidlertidigtArbejde'
- 12 'SygdomHelbredForvaerresVedArbejde'
- 18 'FritagelseForRådighedUnderDeltagelseITilbud'
- 22 'SaerligOevrige'
- 41 'OpfoelgningUdenKontakt'
- 59 'TillaegForDanskkundskaber'
Manuscript 128141 – Slettes det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning?
Ved CPR-flytning:
Aflyses det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning er registreret?
Hvis ikke, så skal det gamle jobcenters indkaldelser til samtaler aflyses, når CPR-flytning til den nye kommune registreres.
Som hidtil skal henvisningssamtaler ikke aflyses ved CPR-flytning
DFDGs fristbatchjob
Manuscript 127548 - Fristbatchjob tager ikke højde for manuel ændring af JC-tilhørsforhold
DFDG må ikke lukke frister ifm borgerens CPR-flytning, når der er tale om, at jobcentertilknytningen allerede er ændret manuelt.
Det bør kun ske, hvis DFDG-batchjobbet ændrer jobcentertilknytning, eller ved lukning af en frist udstedt af borgerens tidligere jobcenter.
Manuscript 122650 To WarningRegistrationWSRM'er på afmeldt borger
Det er konstateret at der ved afmelding pga. manglende overholdelse af frist til selvbooking i Jobcenter afsendes 2 ens GetWarning WSRM'er til Jobcentret.
Løsningen bliver at fjerne den ekstra indlagte afsendelse, som er det sted i DFDG hvor der afsendes til både a-kasse og jobcenter - hvorfor a-kassens GetWarning WSRM ved afmelding pga. manglende selvbook udgår og ikke længere vil blive afsendt.
A-kassen vil fortsat modtage GetCancelUnemploymentEnrollment med afmeldeårsagen, og vil derigennem kunne identificere hændelsen.
925.1.2 - DFDG Nightly batch skal igen køre indenfor rammen af "nattetid"
Målet er, at Nightly batch er færdig med at køre inden kl 7 om morgenen 99% af alle dage udenfor releaseaktiviteter.
Manuscript-sag relateret til dette: MS-127525 - NightlyBatch - fortsat lange kørselstider efter patchrettelser
Løsningsmodel
De analyser, der er blevet foretaget i forbindelse med Manuscript 127525 har vist, at DFDGs database bruger mange kræfter og tid på at fremsøge borgeres seneste tilstande i forbindelse med afvikling af batchjob. Tilstandene, som batchjob typisk bruger kræfter og tid på at fremsøge, er borgeres aktuelle kontaktgruppe, borgeres aktuelle tilmelding, borgeres aktuelle personkategorisering samt borgeres seneste juridiske plan, hvilket i dag fremsøges på en ineffektiv måde.
For at gøre de forespørgsler (SQL queries), der skal finde borgeres seneste tilstande, langt mere effektive, skal der indføres et flag på en række tabeller. Dette flag skal angive, om data i den givne række er borgerens aktuelle tilstand, eksempelvis borgeren aktuelle/seneste kontaktgruppe. Flaget skal vedligeholdes når DFDG skriver til de enkelte tabeller og det skal sikres, at der kun eksisterer en markering for seneste tilstand for en borger i hver enkelt tabel. Samtidig skal der oprettes et index på flaget, som muliggør en hurtig og effektiv fremsøgning af den aktuelle tilstand. Alle forespørgsler, der fremsøger borgeres seneste tilstand i batchjob, ændres til at benytte de nyoprettede flag.
Dette løsningskoncept er som et eksperiment afprøvet på en række tabeller (se Manuscript 127525) og resultatet af dette eksperiment viser, at der er store forbedringer at hente ved batchjobkørsler. En forsigtig vurdering er, at det vil give en tidsforbedring på 50%.
Startimplementering på Kontaktgruppe, Tilmeldinger og Personkategori
Rammerne for denne Epic giver mulighed for at afprøve og implementere konceptet på kontaktgrupper, tilmeldinger og personkategorier. Planer og aktiviteter er ikke omfattet i denne epic, da vi p.t. har en anden stor ændring på vej på dette område, nemlig person ID. Vi vil kende de forbedringer det medfører inden vi laver yderligere tiltag. Ydermere har STAR og DFDG planer om at skille planer og aktiviteter fra hinanden, hvilket ligeledes er grund til at vente med denne epics indsats på plan-forretningsområdet.
Forretningsregler for aktuel/seneste tilstand
Nedenstående tabel viser de forretningsmæssige regler, der angiver om et forretningsobjekt indeholder en borgeres aktuelle/seneste tilstand.
Forretningsobjekt | Regler for aktuel/seneste tilstand |
|---|---|
Kontaktgruppe | En borgers seneste kontaktgruppe er kontaktgruppen med den seneste startdato (StartDate) uanset om kontaktgruppen er åben eller blevet lukket (også selv om den er lukket før dags dato) |
Tilmelding | En borgers seneste tilmelding er tilmeldingen med den seneste tilmeldedato (EnrollmentDate) uanset om tilmeldingen er igangværende (borger er tilmeldt) eller blevet afmeldt (også selv om afmeldingen er sket før dags dato) |
Personkategori | En borgers aktuelle personkategori er personkategorien med den seneste registreringsdato (RegistrationDate) |
Initiel populering af flag
Der oprettes et flag, som kan angive, om rækken indeholder data for en borgers seneste tilstand. Flaget oprettes og initieres på følgende tabeller:
- tblPersonStausContactGroup – flaget sættes til TRUE på borgeres seneste kontaktgruppe i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- tblPersonStatusEnrollment – flaget sættes til TRUE på borgeres seneste tilmelding i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- tblPersonStatusCategory – flaget sættes til TRUE på en borgeres aktuelle personkategorisering i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
Opdatering af flag i daglig drift
DFDGs kodebase tilrettes, således at de oprettede flag sættes og vedligeholdes, når:
- der oprettes nye kontaktgrupper – eventuelle eksisterende markeringer, som på flaget er sat til TRUE på borgerens kontaktgrupper fjernes og flaget sættes til TRUE på den seneste kontaktgruppe i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- en borger tilmeldes – eventuelle eksisterende markeringer, som på flaget er sat til TRUE på borgerens tilmeldinger fjernes og flaget sættes til TRUE på den seneste tilmelding i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- der laves nye personkategoriseringer – eventuelle eksisterede markeringer, som på flaget er sat til TRUE på borgerens personkategoriseringer fjernes og flaget sættes til TRUE på den aktuelle personkategorisering i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
Flaget på de enkelte tabeller er et internt DFDG felt og skal ikke publiceres udadtil. I de tilfælde, hvor DFDG skal fjerne en markering på en eksisterende række i en tabel, så skal oplysninger om den registerende myndighed ikke opdateres på rækken medmindre der samtidig er sket andre forretningsmæssige ændringer til denne række. Flaget skal IKKE indgå i historikken af hensyn til mulighed for fejlfinding, da det fordyrer opdateringer, og ikke giver anden viden end opdateringsdatoen, at alle rækker i historik indeholder at flaget har været true.
DFDGs kodebase skal også sikre at en borger ikke kan have to samtidige markeringer på en tabel.
Batchjobudnyttelse af flagene
Alle batchjob i DFDGs kodebase gennemgås og de forespørgsler (SQL queries), der benytter en borgers seneste tilstande i form af seneste kontaktgruppe, senest tilmelding og/eller aktuelle personkategorisering tilrettes, så de nødvendige oplysninger fremsøges ved hjælp af markeringer på de oprettede flag.
For at optimere disse forespørgsler yderligere, skal der oprettes et index på hver tabel, hvor flaget og CPR nummer indgår. Disse index kan med fordel implementeres, så de også inkluderer lidt mere information omkring borgerens tilstand, det drejer sig for de enkelte tabeller om følgende informationer:
- tblPersonStatusContactGroup – typen på kontaktgruppe (ContactGroupTypeIdentifier), startdato for kontaktgruppe (StartDate) og slutdatoen for kontaktgruppen (EndDate), da disse typisk også benyttes i forespørgslerne
- tblPersonStatusEnrollment – klientkategorien på tilmeldingen (ClientCategoryTypeId), tilmeldingsdato (EnrollmentDate) og afmeldingsdato (RemovalDate), da disse typisk også benyttes i forespørgslerne
- tblPersonStatusCategory – typen på personkategorien (PersonCategoryTypeIdentifier) og registreringsdatoen (RegistrationDate)
Sikring af at batchjob ikke kan køre med fejlagtigt eller mangelfuldt sat flagbestand
...
Test af løsningen
Idriftsættelsesaktiviteter hos D&S udviklere
Fagligt indlæg
...
Ændringer til Manuscript-sager med datagenopretninger og lignende skal fremover sætte flag
...
Eksisterende fejlkode 5015 Sag 119106 | |||||||||||
PersonNotificationReminderService (v1)
| x | x | x | Get-metoden returnerer nu null i NotificationReminderType for en borger uden kontaktoplysninger | Sag 132498 | ||||||
PersonHistoryService (v4)
| x | x | x | Returnerer fremover ophold i DK inden for de seneste 10 år (mod tidligere inden for de seneste 8 år) | Sag 132074 | ||||||
PersonRegistrationService (v9)
| x | x | Kaster fejlkode 9370, hvis KG lukkes, når der er åbent sygefravær | Sag 105003 Fejlkode 9370 | |||||||
WsrmMessageService (version 11)
| x | x | x | Felterne CalculationWeek, StartWeekProlongedSupplementalBenefits og StartWeekOrdinarySupplementalBenefits åbnes til at gå til 1989 som tidligste år | Sag 129429 | ||||||
WsrmMessageService (version 10)
| x | x | To WarningRegistrationWSRM'er på afmeldt borger - WarningTypeIdentifier id 48 og 49 udsendes ikke længere til a-kasse | Sag 122650 |
Beskrivelse af epic
Konkrete FB-sager der kandiderer til løsning – eller som er løst til 2019-1 fremgår i oversigt nedenfor.
Sager relateret til DFDG flytte-batchjob (CPR-flytning)
Overordnet er problemet at DFDG ved modtagelse af en flyttemeddelelse fra CPRregisteret sammenligner jobcenter for den angivne nye adresse med aktuelt jobcenter i DFDG, og konstaterer at der ikke skal sættes gang i flytteflow til nyt jobcenter hvis det viser sig at borger tilsyneladende er flyttet indenfor samme kommune.
For at tage højde for at der skal laves flytteflow når nyt jobcenter har trukket borgeren til sig inden CPR flytningen, ændrer vi nu, så DFDG ved CPR-notits om flytning undersøger om der er sket et jobcenterskift til ny kommune inden for den seneste uge, og i så fald sætte flytteflow i gang.
Flytteflow er beskrevet på wiki: Borger flytter til ny kommune
Manuscript 126762 - Uønsket overlevering af PersonCategory fra fraflyttet jobcenter
Ved cpr-flytning til en ny kommunen ønskes det, at visitering nulstilles til "ikke-visiteret".
Hvis jobcenter i den nye kommune har trukket borger (ændret jobcentertilknytning til den nye kommune) skal borger kun sættes til ikke-visiteret, hvis det nye jobcenter endnu ikke har registreret en ny visitering.
Det skal gælde for kontanthjælps-, uddannelseshjælps- og integrationsydelses kontaktgrupperne.
Fraværene i nedenstående liste er ulovlige i kombination med visitationkategori (PersonCategory) Ikke Visiteret. Hvis borger har et af disse fravær vil PersonCategory derfor ikke blive nulstillet.
- 2 'MidlertidigtArbejde'
- 12 'SygdomHelbredForvaerresVedArbejde'
- 18 'FritagelseForRådighedUnderDeltagelseITilbud'
- 22 'SaerligOevrige'
- 41 'OpfoelgningUdenKontakt'
- 59 'TillaegForDanskkundskaber'
Manuscript 128141 – Slettes det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning?
Ved CPR-flytning:
Aflyses det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning er registreret?
Hvis ikke, så skal det gamle jobcenters indkaldelser til samtaler aflyses, når CPR-flytning til den nye kommune registreres.
Som hidtil skal henvisningssamtaler ikke aflyses ved CPR-flytning
DFDGs fristbatchjob
Manuscript 127548 - Fristbatchjob tager ikke højde for manuel ændring af JC-tilhørsforhold
DFDG må ikke lukke frister ifm borgerens CPR-flytning, når der er tale om, at jobcentertilknytningen allerede er ændret manuelt.
Det bør kun ske, hvis DFDG-batchjobbet ændrer jobcentertilknytning, eller ved lukning af en frist udstedt af borgerens tidligere jobcenter.
Manuscript 122650 To WarningRegistrationWSRM'er på afmeldt borger
Det er konstateret at der ved afmelding pga. manglende overholdelse af frist til selvbooking i Jobcenter afsendes 2 ens GetWarning WSRM'er til Jobcentret.
Løsningen bliver at fjerne den ekstra indlagte afsendelse, som er det sted i DFDG hvor der afsendes til både a-kasse og jobcenter - hvorfor a-kassens GetWarning WSRM ved afmelding pga. manglende selvbook udgår og ikke længere vil blive afsendt.
A-kassen vil fortsat modtage GetCancelUnemploymentEnrollment med afmeldeårsagen, og vil derigennem kunne identificere hændelsen.
925.1.2 - DFDG Nightly batch skal igen køre indenfor rammen af "nattetid"
Målet er, at Nightly batch er færdig med at køre inden kl 7 om morgenen 99% af alle dage udenfor releaseaktiviteter.
Manuscript-sag relateret til dette: MS-127525 - NightlyBatch - fortsat lange kørselstider efter patchrettelser
Løsningsmodel
De analyser, der er blevet foretaget i forbindelse med Manuscript 127525 har vist, at DFDGs database bruger mange kræfter og tid på at fremsøge borgeres seneste tilstande i forbindelse med afvikling af batchjob. Tilstandene, som batchjob typisk bruger kræfter og tid på at fremsøge, er borgeres aktuelle kontaktgruppe, borgeres aktuelle tilmelding, borgeres aktuelle personkategorisering samt borgeres seneste juridiske plan, hvilket i dag fremsøges på en ineffektiv måde.
For at gøre de forespørgsler (SQL queries), der skal finde borgeres seneste tilstande, langt mere effektive, skal der indføres et flag på en række tabeller. Dette flag skal angive, om data i den givne række er borgerens aktuelle tilstand, eksempelvis borgeren aktuelle/seneste kontaktgruppe. Flaget skal vedligeholdes når DFDG skriver til de enkelte tabeller og det skal sikres, at der kun eksisterer en markering for seneste tilstand for en borger i hver enkelt tabel. Samtidig skal der oprettes et index på flaget, som muliggør en hurtig og effektiv fremsøgning af den aktuelle tilstand. Alle forespørgsler, der fremsøger borgeres seneste tilstand i batchjob, ændres til at benytte de nyoprettede flag.
Dette løsningskoncept er som et eksperiment afprøvet på en række tabeller (se Manuscript 127525) og resultatet af dette eksperiment viser, at der er store forbedringer at hente ved batchjobkørsler. En forsigtig vurdering er, at det vil give en tidsforbedring på 50%.
Startimplementering på Kontaktgruppe, Tilmeldinger og Personkategori
Rammerne for denne Epic giver mulighed for at afprøve og implementere konceptet på kontaktgrupper, tilmeldinger og personkategorier. Planer og aktiviteter er ikke omfattet i denne epic, da vi p.t. har en anden stor ændring på vej på dette område, nemlig person ID. Vi vil kende de forbedringer det medfører inden vi laver yderligere tiltag. Ydermere har STAR og DFDG planer om at skille planer og aktiviteter fra hinanden, hvilket ligeledes er grund til at vente med denne epics indsats på plan-forretningsområdet.
Forretningsregler for aktuel/seneste tilstand
Nedenstående tabel viser de forretningsmæssige regler, der angiver om et forretningsobjekt indeholder en borgeres aktuelle/seneste tilstand.
Forretningsobjekt | Regler for aktuel/seneste tilstand |
|---|---|
Kontaktgruppe | En borgers seneste kontaktgruppe er kontaktgruppen med den seneste startdato (StartDate) uanset om kontaktgruppen er åben eller blevet lukket (også selv om den er lukket før dags dato) |
Tilmelding | En borgers seneste tilmelding er tilmeldingen med den seneste tilmeldedato (EnrollmentDate) uanset om tilmeldingen er igangværende (borger er tilmeldt) eller blevet afmeldt (også selv om afmeldingen er sket før dags dato) |
Personkategori | En borgers aktuelle personkategori er personkategorien med den seneste registreringsdato (RegistrationDate) |
Initiel populering af flag
Der oprettes et flag, som kan angive, om rækken indeholder data for en borgers seneste tilstand. Flaget oprettes og initieres på følgende tabeller:
- tblPersonStausContactGroup – flaget sættes til TRUE på borgeres seneste kontaktgruppe i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- tblPersonStatusEnrollment – flaget sættes til TRUE på borgeres seneste tilmelding i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- tblPersonStatusCategory – flaget sættes til TRUE på en borgeres aktuelle personkategorisering i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
Opdatering af flag i daglig drift
DFDGs kodebase tilrettes, således at de oprettede flag sættes og vedligeholdes, når:
- der oprettes nye kontaktgrupper – eventuelle eksisterende markeringer, som på flaget er sat til TRUE på borgerens kontaktgrupper fjernes og flaget sættes til TRUE på den seneste kontaktgruppe i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- en borger tilmeldes – eventuelle eksisterende markeringer, som på flaget er sat til TRUE på borgerens tilmeldinger fjernes og flaget sættes til TRUE på den seneste tilmelding i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
- der laves nye personkategoriseringer – eventuelle eksisterede markeringer, som på flaget er sat til TRUE på borgerens personkategoriseringer fjernes og flaget sættes til TRUE på den aktuelle personkategorisering i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
Flaget på de enkelte tabeller er et internt DFDG felt og skal ikke publiceres udadtil. I de tilfælde, hvor DFDG skal fjerne en markering på en eksisterende række i en tabel, så skal oplysninger om den registerende myndighed ikke opdateres på rækken medmindre der samtidig er sket andre forretningsmæssige ændringer til denne række. Flaget skal IKKE indgå i historikken af hensyn til mulighed for fejlfinding, da det fordyrer opdateringer, og ikke giver anden viden end opdateringsdatoen, at alle rækker i historik indeholder at flaget har været true.
DFDGs kodebase skal også sikre at en borger ikke kan have to samtidige markeringer på en tabel.
Batchjobudnyttelse af flagene
Alle batchjob i DFDGs kodebase gennemgås og de forespørgsler (SQL queries), der benytter en borgers seneste tilstande i form af seneste kontaktgruppe, senest tilmelding og/eller aktuelle personkategorisering tilrettes, så de nødvendige oplysninger fremsøges ved hjælp af markeringer på de oprettede flag.
For at optimere disse forespørgsler yderligere, skal der oprettes et index på hver tabel, hvor flaget og CPR nummer indgår. Disse index kan med fordel implementeres, så de også inkluderer lidt mere information omkring borgerens tilstand, det drejer sig for de enkelte tabeller om følgende informationer:
- tblPersonStatusContactGroup – typen på kontaktgruppe (ContactGroupTypeIdentifier), startdato for kontaktgruppe (StartDate) og slutdatoen for kontaktgruppen (EndDate), da disse typisk også benyttes i forespørgslerne
- tblPersonStatusEnrollment – klientkategorien på tilmeldingen (ClientCategoryTypeId), tilmeldingsdato (EnrollmentDate) og afmeldingsdato (RemovalDate), da disse typisk også benyttes i forespørgslerne
- tblPersonStatusCategory – typen på personkategorien (PersonCategoryTypeIdentifier) og registreringsdatoen (RegistrationDate)
Sikring af at batchjob ikke kan køre med fejlagtigt eller mangelfuldt sat flagbestand
- og medføre at der må laves datagenopretning efter batchkørsel
Test af løsningen
Idriftsættelsesaktiviteter hos D&S udviklere
Fagligt indlæg
Der planlægges afholdt et faglig indlæg for udviklere i Data & Service, hvor løsningskonceptet og implementering af løsningen gennemgås. Det faglige indlæg skal tage udgangspunkt i DFDGs kodebase samt den dokumentation, som bliver skrevet på Wiki.Ændringer til Manuscript-sager med datagenopretninger og lignende skal fremover sætte flag
Fremover skal de implementerede flag vedligeholdes, når Manuscript sager giver anledning til datagenopretninger. Dette princip og den arkitekturmæssige beslutning herfor beskrives på Wiki.
Andre sager
Manuscript 131227 - Anmeldelsesdato for 'sygdom - sygemelding' må ikke være fremtidig
- IllnessCompositeService.CreateIllness og
- IllnessCompositeService.UpdateIllness
så NotificationDate ikke kan være fremtidig, dvs. at NotificationDate ikke må ligge efter d.d., men skal være d.d. eller tidligere.
Der kastes fejlkode 9362 (Illness NotificationDate must be today or earlier), hvis anmeldelsesdato er senere end d.d.
Formål med ændringen
Manuscript 105003 - Kontaktgruppe 6, 24 og 25 må ikke lukkes, når 'sygdom - sygemelding' er åben
Der ønskes en DFDG-validering, så KG 6, 24 og 25 ikke kan lukkes af sagsbehandler, hvis der er en
- "sygdom - sygemelding" (id 11) uden slutdato, eller
- en "sygdom - sygemelding" (id 11) med en fremtidig raskmeldingsdato
PersonRegistrationService.UpdateContactGroup validerer og kaster fejlkode 9370 (The contact group can not be ended due to an active absence), hvis KG lukkes i den anførte situation.
Formål med ændringen
Undgå at KSS, eDagpenge og STAR skal bruge tid på at undersøge indmeldinger om "fejl" for denne sagstype, når sagsbehandlerne bruger systemerne uhensigtsmæssigt - og utilsigtet får raskmeldt borgerne med sygedagpengedag i eDagpenge med forkert slutdato for sygefraværsforholdet.
Uhensigtsmæssig registrering er fx når sagsbehandler registrerer en fremtidig raskmelding og sekunder efter lukker kontaktgruppen, da dette samtidig fører til, at personen raskmeldes d.d.
Oversigt over sager der indgår i epic
Indsat dato | Manuscript-sag | Titel | Område | Manuscript oprettet af | Skal eller kan kundetestes i STAR? | Snitflader til Jobnet | Snitflader til KSS | Snitflader til A-kasser | Snitflader til andre | Bemærkninger | Kandidat til release | Løst til release-tidspunkt | Varslingstask (intern DFDG) | Afsnit 3 om berørte services i epic er opdateret? |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 22-10-2018 | 110325 | Engelsk tekst - ved afslut kontaktgruppe | KMD (KSS) | x | Kommentar på kontaktgruppe oversat til dansk ifm. afslutning pga. afslag på bevilling. | 2019-1 | ||||||||
| 22-10-2018 | 126762 | Uønsket overlevering af PersonCategory fra fraflyttet jobcenter | Schultz | Se nærmere beskrivelse i E 925.1 | 2019-1 | DS-541 og DS-542 | Ja | |||||||
| 22-10-2018 | 128141 | Slettes det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning? | STAR | Se nærmere beskrivelse i E 925.1 | 2019-1 | |||||||||
| 22-10-2018 | 127548 | Fristbatchjob tager ikke højde for manuel ændring af JC-tilhørsforhold | Schultz | Se nærmere beskrivelse i E 925.1 | 2019-1 | |||||||||
| 30-10-2018 | 93311 | Errorcode(8080) - An absence with the given NemRefusionIdentifier and startdate does not exists | IllnessRecoveryInformationService.CreateIllness | KMD (SDP) | x | eDagpenge | Ændret så følgende gælder: Hvis IRIS.CreateIllness kaldes med samme nemrefid som et eksisterende sygdomsfravær (for borgeren) og med den samme startdato genåbnes det eksisterende sygdomsfravær. Hvis IRIS.CreateIllness kaldes med samme nemrefid som et eksisterende sygdomsfravær (for borgeren) og med en anden startdato ændres startdatoen for det eksisterende sygdomsfravær. | 2019-1 | DS-658 | Ja | ||||
| 06-11-2018 | 89641 | KC-TASS-ProcessFutureEnrollments (The client has an absenceregistration...) - fejler for en borger | Batchjob | x | x | Hvis borger melder sig syg, raskmelder sig og melder sig syg igen dagen efter, fjernes eventuelle futureenrollments og et nyt sygdomsfravær oprettes. (Dette vil også ske hvis der oprettes andre fravær som ikke tillader tilmelding). | 2019-1 | |||||||
| 07-11-2018 | 127161 | KC-Tass-ReenrollWhenIllnessEndsLaterThanToday fejler: The client has an absence registration that does not allow enrollment | Batchjob | x | Batchjobbet gøres mere robust, så det ikke fejler. Batchjobbet vil ikke forsøge at tilmelde borgeren hvis der findes en anden åben aktiv sygemelding end den som er afsluttet | 2019-1 | ||||||||
| 15-11-2018 | 122650 | To WarningRegistrationWSRM'er på afmeldt borger | WSRM | Schultz | X | X | DFDG fjerner den ekstra afsendelse, hvorfor a-kassens GetWarning WSRM ved afmelding pga. manglende selvbook udgår og ikke længere vil blive afsendt. Se nærmere i epicdokument | 2019-1 | DS-442 | Ja | ||||
| 26-11-2018 | 129429 | UnemploymentBenefitsAccountService tæller SupplementalBenefitsAccount felt StartWeekOrdinarySupplementalBenefits | Dagpengetællere | KMD A-kasse | X | X | X | Beregningsuge, startuge for forlængede supplerende dagpenge og startuge for supplerende dagpenge kan sættes tilbage til 1989. | 2019-1 | DS-497, DS-498, DS-499, DS-501, DS-500 | Ja | |||
| 03-12-2018 | 89779 | Borger tilmeldt uden en kontaktgruppe | Til- og afmelding | STAR | x | x | x | Eksisterende funktionalitet: Hvis borger er i kontaktgruppe 1,2,3,8,12,26,27 eller 28 og borgerens kontaktgruppe lukkes med en slutdato som ligger på et tidspunkt hvor borger er tilmeldt, vil DFDG returne fejlkode 4919 "The contact group can not be ended due to an active enrollment" (dette gælder både ved oprettelse og opdatering). Denne sag løses ved at udvide denne liste så valideringen også kommer til at omfatte kontaktgrupperne 14-23. | 2019-1 | |||||
| 04-12-2018 | 125908 | LBA'ere i kommuner/jobcentre kan ikke udsøge bruger på roller | AMP-Admin2 - administration af roller | STAR | x | 2019-1 | ||||||||
| 04-12-2018 | 130373 | Batchjobbet KC-TASS-MissingAppropriation fejler dagligt med tom fejl | Batchjob | SF | 2019-1 | |||||||||
| 04-12-2018 | 130840 | Der skal kunne registreres "Særlig øvrige" (ID 22) på aktivitetsparate uddannelseshjælpsmodtagere i KG12 | Fravær og fritagelser | STAR | x | 2019-1 | ||||||||
| 05-12-2018 | 119539 | IllnessCompositeService - UpdatIllness - fejl 4981 | Wiki | FOA | x | x | x | Det fremgår nu på wiki, at fejlkode 4981 kan kastes af UpdateIllness | 2019-1 | |||||
| 05-12-2018 | 119106 | Fejlkode 5015 mangler på wiki under IllnessCompositeService.UpdateIllness | Wiki | STAR | x | x | x | Det fremgår nu på wiki, at fejlkode 5015 kan kastes af UpdateIllness | 2019-1 | |||||
| 10-12-2018 | 127179 | Execution Timeout Expired ved Joblogpersonsearch | JoblogService | KMD Facilia | x | 2019-1 | ||||||||
| 13-12-2018 | 131974 | Ensretning af logning af batchjobs | DFDG logning | DFDG | 2019-1 | |||||||||
| 14-12-2018 | Sygefravær modtages med fremtidige anmeldelsesdatoer | IllnessCompositeService
| FOA | x | x | x | Ny validering så anmeldelsesdato ikke kan være fremtidig. Ny fejlkode 9362. | 2019-1 | DS-627 og DS-628 | Ja | ||||
| 17-12-2018 | KC-TASS-ReenrollWhenIllnessEndsLaterThanToday fejl: The ContactGroupTypeIdentifier is invalid | DFDG batchjob | SF | Batchjobbet er ændret, så CPR-nummeret logges ved fejl. | 2019-1 | |||||||||
| 20-12-2018 | 'Aktuel opholdsadresse' Ja/Nej er byttet rundt | LSS | STAR | Rettelse i LSS brugergrænseflade | 2019-1 | |||||||||
| 21-12-2018 | 119106 | Fejlkode mangler op wiki | IllnessCompositeService
| STAR | x | x | x | Fejlkode 5015 vises på wiki | 2019-1 | |||||
| 02-01-2018 | 'Aktuel opholdsadresse' Ja/Nej er byttet rundt | LSS | STAR | x | Rettelse i LSS visning | 2019-1 | ||||||||
| 07-01-2018 | PersonNotificationReminderService. GetPersonContactAndNotificationData fejler | PersonNotificationReminderService | DFDG | x | x | x | Get-metoden returnerer nu null i NotificationReminderType for en borger uden kontaktoplysninger | 2019-1 | DS-659 | Ja | ||||
| 08-01-2019 | 132074 | Opholdskrav | PersonHistoryService
| STAR | x | x | x | Returnerer fremover ophold i DK inden for de seneste 10 år (mod tidligere inden for de seneste 8 år) | 2018-4.0.2 | DS-660 | Ja | |||
| 08-01-2018 | 119811 | Ferie- og sygemelding via Jobnet vises som registreret af caseworker | Registrering via JobnetIllnessService og JobnetVacationService. Udstilling af historik via PHS. | STAR | x | 2019-1 | ||||||||
| 08-01-2019 | 129939 | Døde-batchjobbets brug af udmeldingsårsag | Netcompany | x | Kodelistværdi ændret fra 8 til 7, så udmeldingsårsag er "Udmeldt grundet død" | 2019-1 | ||||||||
| 08-01-2019 | Uhensigtsmæssig sagsbehandler registrering (lukning af KG), når der registreres en fremtidig raskmelding | PersonRegistrationService - UpdateContactGroup | STAR på baggrund af drøftelser med KOMBIT | x | x | Kaster fejlkode 9370, hvis KG lukkes, når der er åbent sygefravær | 2019-1 | DS-661 | Ja | |||||
| 09-01-2019 | Batchovervågning: Mangler mulighed for at se hvad der er fejlet i weekender og helligdage | LSS | SF | LSS batchovervågning (webside BatchLog) nu tilgængelig fra hovedside via 3 links: Seneste døgn, Seneste 3 dage og Seneste uge. Det er nu muligt fra BatchLog side at fremsøge 'Alle exclusiv succes' samt at fremhæve batchjobs der indgår i NightlyBatch. | 2019-1 | |||||||||
| 09-01-2019 | Kundetest: Manglende genetablering af kontaktgruppe Seniorjobber efter raskmelding | Raskmelding af seniorjobbere, der har været i KG 24 (Sygedagpengemodtager fra beskæftigelse) | STAR | x | x | Ved raskmelding af borger i KG24 (Sygedagpengemodtager Fra Beskaeftigelse), som skiftede fra seneste anden KG23 Seniorjob, sættes borger tilbage i KG23 | 2019-1 | |||||||
| 10-01-2019 | Advis om utilstrækkelig joblogging på dagpengemodtagere | GetWarningVersion4 | Schultz | x | x | 2019-1 | ||||||||
| 10-01-2019 | Advis Utilstrækkelig joblogging er dannet på borger uden åben kontaktgruppe | GetWarningVersion4 | Schultz | x | x | 2019-1 | ||||||||
| 11-01-2019 | Er kursusfiltreringen i f.t. WSRM godt nok specificeret? | GetActivityGenerelEventVersion1 GetMyPlanVersionNotificationEventVersion1 | FOA | x | x | A-kasserne skal ikke have når afholdelseskategori er "Andet", dvs. når CourseTypeIdentifierType = 38. | 2019-1 | |||||||
| 28-01-2019 | Historisk oprettede hjælpemidler markeres ikke som "revision" | DFDG | x | x | Historisk oprettede hjælpemidler markeres nu som "revision" (historisk registrering). Det samme gælder for personlig assistance. | 2019-1 | ||||||||
| 07-02-2019 | Afbrudt aktivitet med fremtidig slutdato fejler på Jobnet | ActivityService - UpdateActivity | STAR | x | x | 2019-1 | ||||||||
| 07-02-2019 | Forskel på Eventtime i PSS og PHS for Contactgroup | PersonHistoryService | KMD (KSS) | x | x | Rettet fejlagtig mapning til ContactGroupEventTime fra EventDate feltet ved læsning til PHS. | 2019-1 | |||||||
| 22.07.2019 | 132757 | Åbne adgang for at Fagforbund får adgang til at kalde CompanyRecruitmentService - WSRM-ændringer så Fagforbund kommer med ud | WsrmMessageServiceV11. GetCompanyRecruitmentEvent i v3. | STAR | x | x | x | Ny version af WSRM-besked. Gl. version forbliver i live. | 2019-1 | |||||
| 22.07.2019 | 132756 | Åbne adgang for at Fagforbund får adgang til at kalde CompanyRecruitmentService | Myndighedstypen Fagforbund får adgang til at kalde CompanyRecruitmentService | STAR | x | Myndighedstypen Fagforbund får adgang til at kalde CompanyRecruitmentService | 2019-1 |
Særlige krav til test
Testscenarie | Berørte systemområder | Identificeret af |
...
Bilag 1 – FB xxxx – Redaktionelle ændringer til xxxxx
Id | Navn | Beskrivelse | Startdato | Slutdato |
|---|---|---|---|---|
Bilag 2 – FB xxxx – Redaktionelle ændringer til xxxxx
Her vises alene et udsnit af kodelisten.
Id | Navn | Beskrivelse | Startdato | Slutdato |