Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Overordnet beskrivelse:
Analyse af hvad der skal til for at D&S via de eksterne bookingsystemer kan lade borgere selv booke fællesjobsamtaler

Målgruppe:

PO, FA, Udviklere

Reference:

KON-65

Forfatter:

Kim Jørgensen

Teknisk analyse:
Vi har i dag to flow for selvbookings, dels via Jobnet (som burger JobnetBookingService og de bagvedliggende booking systemer) og dels via InterviewService hvor a-kasserne kan lave en indkaldelse og markere at det er borgeren selv der har booket. Vi begrænser her analysen til kun at omhandle Jobnet/JobnetBookingService/BorgerBookingService flowet.

Ændringer til flow for booking

  • For at kunne give de korrekte mødetilbud/timeslots, skal bookingsystemerne vide om borgeren tilhører den ene eller den anden a-kasse.

  • Vi skal tage højde for om borgeren og/eller a-kassen har frabedt sig a-kassens deltagelse.

  • Vi tillader ikke at fællesjobsamtaler bliver ombooket eller aflyst af borgeren og skal validere for dette.

  • Inden vi laver en booking på D&S’s side, skal vi hvis a-kassen skal deltage, indsætte en generisk a-kassekonsulent.

  • Borgere kan blive afmeldt pga. manglende selvbooking af fællesjobsamtaler og skal derfor også kunne straksbooke disse.

A-kassespecifikke møder

Dette er tænkt løst ved at jobcentrene laver persongruppemarkeringer for hver a-kasse, hvorefter bookingsystemerne kan tilbagesende mødetilbud og timeslots hvor netop den pågældende a-kasse kan deltage. Dette betyder at vi ikke skal lave snitfladeændringer, selvom det ville ha' været en lidt pænere løsning at give bookingsystemerne a-kasseinformationen direkte i kaldet fra JobnetBookingService

A-kasse deltagelsesvalg

Vi vil løse dette ved at efter vi har fået bookingdetaljerne fra bookingsystemet, så lave et opslag i JorbentBookingService for om enten borgeren eller a-kassen har frabedt sig deltagelse. Skulle de det, vil vi så lave en fællesjobsamtaler uden a-kasse deltagelse. Vi bliver herefter nødt til at fortælle bookingsystemet om a-kassen skal deltage for deres planlægningsskyld. Dvs. der kommer en snitfladeændring til BorgerBookingService.CreateBooking der skal have feltet “akasseDeltager” med. Da vi ikke medsender dette flag til at starte med, risikere vi at bookingsystemet bruger nogle fælles jobsamtaleslots unødigt.

Validering af ombooking og aflysning

Efter vi modtager bookingdetaljer fra bookingsystem, laver vi en validering af resultatet for at sikre vi kan oprette bookingen. Denne validering skal udvides således at for fællesjobsamtaler må borgeren ikke kunne ombooke eller aflyse.

Generisk a-kassekonsulent

Hvis a-kassen skal deltage, skal vi tilføje en genetisk a-kassekonsulent som deltager inden vi laver booking lokalt. A-kassen og jobcenteret kan så efterfølgende tilrettet denne deltager når de ved hvem der skal deltage.

Straksbooking af fællesjobsamtaler

Flowet i dag omkring om borgeren er straksbookingramt og med at lave en straksbooking kan håndtere alle typer samtaler og skal derfor ikke rettes, men blot testes grundigt.

Andre observationer

Vi har implementeret at man kan lave frister til fællesjobsamtaler. Hvis man har en frist til en jobsamtale i forvejen, vil man få en fejlmeddelelse 9219 “Borgeren har en frist med en anden samtaletype som først skal lukkes”. Hvis man derimod opretter en ny frist til en jobsamtale, vil man blot få lukket den gamle frist og oprettet en ny. Måske skulle vi ændre dette således at enhver oprettelse af en frist til samtaletype 7 og 17 lukker enhver aktiv frist til samtaletype 7 eller 17.

  • No labels