690.8 Ændringer til aktiviteter – bl.a. Kendskab til jobcenter på aktivitet
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
(Skabelon af dato 17/12-2015)
Indholdsfortegnelse
1 Ændringslog
2 Afgrænsning af epic
3 Oversigt over berørte web services
4 Beskrivelse af epic
4.1 690.8.1 Som virksomhedskonsulent ønsker jeg at kunne se hvilket jobcenter der har oprettet en aktivitet
4.1.1 ActivityService (Version 3)
4.1.2 ActivityService (Version 4)
4.1.3 Andre service der udstiller aktiviteter
4.2 690.8.2 UpdateHistoricActvity tilrettes så den fremadrettet opdaterer aktiviteter på sagsbehandlerkladden også
4.3 690.8.3 På en aktivitet kan jeg registrere reference til en jobordre eller jobannonce.
4.3.1 ActivityService (Version 4)
4.3.2 CodeListService (Version 5)
4.3.3 Andre service der udstiller aktiviteter
4.4 690.8.4 Hvis forsørgelsestype indberettes af en serviceaftager ignoreres denne 690.8.5 En aktivitet der hentes i DFDG udstiller ikke forsørgelsestype
4.4.1 ActivityService (Version 4)
4.4.2 Andre service der udstiller aktiviteter
4.5 690.8.6 Nytteindsats for en dagpengemodtager, skal markeres som et rådighedsafprøvende tilbud
4.5.1 ActivityService (Version 3 og 4)
4.6 690.8.7 CVR- og p-nr. skal være udfyldt med 8 hhv. 10 tegn ved Create
4.6.1 Ny validering på CreateActivity –krav om CVR- og p.nr. eller hhv 8 og 10 tegn
5 Særlige krav til test
6 Kendte udeståender fra udviklingsfasen
7 User stories

Ændringslog

Afgrænsning af epic

Oversigt over berørte web services

f = frivillig

Beskrivelse af epic

Denne epic samler en række mindre rettelser og forbedringer i forbindelse med aktiviteter efterlyst bl.a. af KSS.
Dog er det sådan at det er frivilligt for KSS at benyttet version 4 i 2018-1 dog vil der j.f. afsnit 4.5 690.8.6 Nytteindsats for en dagpengemodtager, markeres automatisk som et rådighedsafprøvende tilbud. være påkrævet af anvende den nye fejlkode der vil være i både version 3 og 4.

690.8.1 Som virksomhedskonsulent ønsker jeg at kunne se hvilket jobcenter der har oprettet en aktivitet

ActivityService (Version 3)

Bevares uændret af hensyn til a-kasserne.

ActivityService (Version 4)

GetActivity

Udvides med myndighedkode for de jobcenter der har oprettet aktiviteten. Det er det Jobcenter kaldt der CreateActivity de anvendes. Det efterspørges også om det er muligt at medtage dato for første publicering af aktiviteten.

Kun relevante og ændrede elementer er vist.

Oplysningen kan kun hentes vis "GetActivity".

Andre service der udstiller aktiviteter

PersonStatusService (Version 20)

Berøres ikke ved denne ændring og oprettende jobcenter vil ikke fremgå i denne service på aktiviteter.

PlanService (Version 3)

Berøres ikke ved denne ændring og oprettende jobcenter vil ikke fremgå i denne service på aktiviteter.

JobnetActivityService (Version 3)

Berøres ikke ved denne ændring og oprettende jobcenter vil ikke fremgå i denne service på aktiviteter.

MyPlanService (Version 2 og 3)

Berøres ikke ved denne ændring og oprettende jobcenter vil ikke fremgå i denne service på aktiviteter.

WSRMessageService (Version 10 og 11) ændres ikke

WSRMbeskeder i relation til dette Berøres ikke ved denne ændring.

JobnetMyPlanService

Berøres ikke ved denne ændring og oprettende jobcenter vil ikke fremgå i denne service på aktiviteter.

PersonHistoryService (Version 4)

Berøres ikke ved denne ændring.

690.8.2 UpdateHistoricActvity tilrettes så den fremadrettet opdaterer aktiviteter på sagsbehandlerkladden også

Afventer beskrivelse til acceptkriterie er defineret i scope
UpdateHistoricActvity tilrettes så den fremadrettet opdaterer aktiviteter på sagbehandlerkladden også.

690.8.3 På en aktivitet kan jeg registrere reference til en jobordre eller jobannonce.

ActivityService (Version 4)

CreateActivity, UpdateActivity, CreateHistoricActivity, UpdateHistoricActivity og GetActivity

Alle metode udvides men en collection der indeholder valgfrie referancer til f.eks. jobordre (ordinær eller tilskuds), jobannonce m.f.
Forretningsregler:

• Hvis "Ekstern system reference" Id 4 så angives identifikation af hvilken reference det er i ReferanceTypeDescription. DFDG valideret ikke for dette.

Kun relevante og ændrede elementer er vist.

Konvertering

Eksisterende JobOrderIdentifier konverteres ikke og fra version 4 af AktivityService skal/må feltet ikke mere anvendes. Feltet fjernes ikke af hensyn til eksisterende referancer og eksisternde referancer kan forsat læses og gemmes. DFDG validerer ikke på hvad der er i feltet og om det anvendes.

CodeListService (Version 5)

Kodelister vedr. activityservice.

ReferanceTypeIdentifier

Kodeliste der angiver om hvilken type af reference (ReferenceIdentification) peger på.
Bemærk: "Ekstern system reference" Id 4 kan bruges af de eksterne serviceaftagere til at angive lokale (interne referencer), det kan så i "ReferanceTypeDescription" beskrives hvilken reference der er tale om.
OBS. Listen er generisk og indeholder derfor også kodelisteværdier på typer der ikke nødvendigvis bliver brugt i forbindelse med aktiviteter.
Ny kodeliste.

Andre service der udstiller aktiviteter

Disse service berøres ikke, da ReferenceIdentifierCollection kun anvendes i ActivityService.

690.8.4 Hvis forsørgelsestype indberettes af en serviceaftager ignoreres denne690.8.5 En aktivitet der hentes i DFDG udstiller ikke forsørgelsestype

ActivityService (Version 4)

CreateActivity, UpdateActivity, CreateHistoricActivity, UpdateHistoricActivity og GetActivity

Model 1.
SustenanceTypeIdentifier fjernes fra snitflade men ikke database, af hensyn til historik og de andre service hvor den forsat udstilles.
Model 2.
Eventulle valideringer på SustenanceTypeIdentifier og indhold smides væk

Andre service der udstiller aktiviteter

PersonStatusService (Version 20)

Berøres ikke ved denne ændring.

PlanService (Version 3)

Berøres ikke ved denne ændring og SustenanceTypeIdentifier vil stadig fremgå.Dette er tekniskgæld til senere oprydning når data ikke mere er relevant på historiske aktiviteter.

JobnetActivityService (Version 3)

Berøres ikke ved denne ændring og SustenanceTypeIdentifier vil stadig fremgå.Dette er tekniskgæld til senere oprydning når data ikke mere er relevant på historiske aktiviteter.

MyPlanService (Version 2 og 3)

Berøres ikke ved denne ændring og SustenanceTypeIdentifier vil stadig fremgå.Dette er tekniskgæld til senere oprydning når data ikke mere er relevant på historiske aktiviteter.

WSRMessageService (Version 10 og 11) ændres ikke

WSRMbeskeder i relation til dette Berøres ikke ved denne ændring og SustenanceTypeIdentifier vil stadig fremgå.Dette er tekniskgæld til senere oprydning når data ikke mere er relevant på historiske aktiviteter.

JobnetMyPlanService

Berøres ikke ved denne ændring og SustenanceTypeIdentifier vil stadig fremgå.Dette er tekniskgæld til senere oprydning når data ikke mere er relevant på historiske aktiviteter.

PersonHistoryService (Version 4)

Berøres ikke ved denne ændring.

690.8.6 Nytteindsats for en dagpengemodtager, skal markeres som et rådighedsafprøvende tilbud

ActivityService (Version 3 og 4)

CreateActivity, UpdateActivity, CreateHistoricActivity og UpdateHistoricActivity

Forretningsregel (i alle metoder, Ny regel, der ændres ikke i eksisterende regler):

• Når et tilbud om nytteindsats for en dagpengemodtager indberettes, skal det markeres automatisk som et rådighedsafprøvende tilbud. Ved virksomhedsrettet aktivitet skal det når:
  • Kontaktgruppen er Id 1, Dagpengemodtager
  • JobTypeIdentifier er
    • Id 46 Nytteindsats, kommune
    • Id 47 Nytteindsats, regional
    • Id 48 Nytteindsats, stat
    • Id 49 Nytteindsats, selvejende institution

DFDG validerer for, at nytteindsats for dagpengemodtagere skal indberettes som rådighedsafprøvende. Dvs. kaster fejl, hvis dette ikke er tilfældet(fejlkode XXXX "For the specified JobTypeIdentifier is AvailabilityProving mandatoryKun forslag til tekst."

• • Eksisterende valideringer i f.t. rådighedsafprøvende tilbud gælder også for de tilbud, der automatisk er markeret som rådighedsafprøvende.

690.8.7 CVR- og p-nr. skal være udfyldt med 8 hhv. 10 tegn ved CreateActivity

Det er ikke hidtil valideret, om der er anvendt et CVR-nr. eller et p-nr. på 8 hhv. 10 tegn, når der registreres aktiviteter med Create-metoden. Det har betydet, at der i DFDG er gemt mange aktiviteter med CVR- og p-numre kortere end 8 hhv. 10 tegn.
Sådanne aktiviteter kan imidlertid ikke hentes ud vha. Get-metoderne på ActivityService eller i PSS, idet der på Output-siden foretages valideringer.
Derfor indføres validering på input-siden.

Ny validering på CreateActivity –krav om CVR- og p.nr. eller hhv 8 og 10 tegn

På Create-metoden indføres validering for, om CVR- og p.nr. er hhv 8 og 10 tegn.
Der valideres fortsat ikke for, om det anvendte CVR- og p-nr. findes i CVR-registeret. Der er således tale om en validering af det tekniske format – og ikke af, om de anvendte CVR- og p-nr. er forretningsmæssigt valide.
Dette er bl.a. bagrundet i, at nogle tilbud/aktiviteter gennemføres hos virksomheder m.v., der ikke har et CVR-nummer. For tilbud/aktiviteter, der gennemføres hos virksomheder m.v. uden CVR-nr., kan som CVR-nr. fx anvendes 00000000 (8 stk. 0'er) og som p-nr. fx anvendes 0000000000 (10 stk. 0'er).

Særlige krav til test

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.