IntegrationContractService (2021-1)


Formål med service

IntegrationContractService benyttes til at oprette og vedligeholde integrationskontraktdata

Denne service er forbeholdt Jobcenter, Anden Aktør og STAR. Servicen kan ikke anvendes af andre serviceaftagere, da det kun er de nævnte, der benytter integrationskontrakt data.

Forretningsbeskrivelse

Oprette og opdatere integrationskontraktdata

Integrationskontraktdata oprettes og opdateres ved CreateIntegrationContract. Hver gang metoden anvendes, laves en ny instans af integrationskontraktdata med egen GUID. 

  • For asylansøgerer, der har fået tildelt asyl, skal der oprettes en fremtidig Overgivelsesdato m.v. inden integrationskontraktdata oprettes, således bliver det også muligt at hente integrationskontraktdata fra asyloperatøren (LetAsyl).
  • For borgere, der familiesammenført, kan der oprettes en fremtidig eller historisk Overgivelsesdato m.v. inden integrationskontraktdata oprette. På en familiesammenført er det dog ikke muligt at hente integrationskontraktdata fra asyloperatøren (LetAsyl).
  • For borgere, der har en eksisterende integrationskontrakt , skal der oprettes en historisk Overgivelsesdator, herefter kan integrationskontraktdata oprettes. 

Se CVService og metoden CreateAsylumTransition for nærmere beskrivelse.

Skiftespor (hentning af integrationskontrakdata i DFDG eller Letasyl)

Da integrationskontraktdata jvf. flow fødes hos asyloperatøren (i systemet LetAsyl) og skal kunne hentes af jobcentret i perioden til jobcenteret selv tagert / får ansvaret for borgeren, har DFDG et skiftespor, der sikrer, at integrationskontraktdata hentes fra asyloperatøren (LetAsyl). Når jobcentret har overtaget ansvaret og gemt data første gang i DFDG vil integrationskontraktdata derefter hentes i DFDG. Se også /wiki/spaces/GI/pages/75858579 for yderlige beskrivelse.

Bemærk: Skiftespor har samme logik både for CV og integrationskontrakt, bortset fra de er to tidlige overtagelsesdatoer (EarlyIntegrationContractTransitionDate og EarlyCVTransitionDate), skiftesporsreglerne er beskrevet separat under /wiki/spaces/GI/pages/75858579.

Sikkerhed i LetAsyl 

Jobcenteret kan kun få lov til at hente data fra asyloperatøren (LetAsyl):

  1. Hvis borgerens jobcentertilknytning er hos det kaldende jobcenter, som helt på normal vis mod DFDG 
  2. Den rigtige kommune er angivet.
    Da LetAsyl anvender kommunekode i deres sikkerhedsmodel og jobcenteret til DFDG kalder ind med jobcenter kode, skal DFDG udlede den korrekte kommunekode, der anvendes mod LetAsyl også for jobcentre, der har forpligtende samarbejder, Dette gøre DFDG ud fra den kommunekode, der er angivet i TransitionMunicipality se CVService.   
  3. Hvis cpr.nr, der kaldes med ikke findes i LetAsyl kastes fejlkode 9289 - Invalid URL or unknown person civil registration identifier submitted to the asylum operator.
  4. Hvis cpr.nr. findes i LetAsyl, men ikke findes i Udlændingeministeriets system IBS, kastes fejlkode 9289 også, da det er en del af UIM's webservicens sikkerhedsmodel, at borgerens CPR-nummer skal fremgå ved opslag i IBS matchende asylansøgerens person-ID. I sådanne situationer kan kommunen kontakte UIM/US for nærmere afklaring af årsagen hertil.

Min plan og integrationskontraktdata

Integrationskontraktdata er en del af Min plan. Oprettelse/opdateringer til integrationskontraktdata herunder ændringer til danskmål og vejleding ifm. manglende dansktilegenelse samt lukning af integrationskontrakt udløser en ny version af Min plan og tilhørende events i forhold til Min plan.

En ny integrationskontrakt vil resultere i en ny version af min plan. Hvis der er ændringer i danskmål eller dansktilegnelse ift. forrige integrationskontrakt, vil en ny kvitteringsfrist blive beregnet på MinPlan. Der skal ikke kvitteres for de øvrige dele af integrationskontraktdata (dvs. integrationsoverblikket).

Hvis integrationskontrakten afsluttes, vil den blive fjernet fra MinPlan, således at der ikke længere eksisterer en reference dertil. Der dannes dermed en ny version af MinPlan, hvor integrationskontrakten er fjernet, men eventlisten på MinPlan vil indeholde eventet "Integrationskontrakten er afsluttet" (id. 67). Ydermere vil eventlisten på MinPlan i denne situation også indeholde eventet "Integrationskontrakten er opdateret" (id. 66), idet der er lavet en ny udgave af integrationskontrakten, som får tildelt en guid og bliver opdateret med slutdatoen.

OBS. Integrationskontrakt og invalid MinPlan. I modsætning til de øvrige elementer på MinPlan, så vil integrationskontrakten forblive en del af MinPlan, i de tilfælde hvor den eksisterende MinPlan version er invalid på det tidspunkt en ny version af MinPlan dannes. 

Se også  MyPlanService   

WSRM beskeder

I forbindelse med integrationskontraktdata er der en række evnets (se PlanVersionEventTypeIdentifier), når en sådan event udløses, vil der på linie med andre Min plan events blive sendt en Min plan WSRM (se WsrmMessageService GetMyPlanVersionNotificationEventVersionX).

Eksisterende integrationskontrakter

Eksisterende integrationskontrakter kan ligges ind vha. CreateIntegrationContract metode. Det er Jobcentret selv, der tager stilling til, hvornår oprettelsen sker, men forretningsmæssigt skal det minimum ske første gang, der er ændringer til integrationskontraktdata eller ved i forbindelse med den førstkommende integrationssamtale. Det er Jobcentret (KSS), der selv mapper over til den nye struktur for integrationskontraktdata. 

Se valideringsregler mht. Overgivelsesdato i CVService.CreateAsylumTransition

Integrationskontrakter for familiesammenført m.v. jf. § 2, stk. 3

For borgere der er familiesammenført m.v. er det muligt at oprette integrationskontraktdata direkte på CreateIntegrationContract. 

Lukning af integrationskontrakt

Integrationskontrakten lukkes ved at kalde metoden TerminateIntegrationContract og sætte slutdato for integrationskontrakten. Når integrationskontrakten lukkes, foregår det ved, at der laves en kopi af den eksisterende integrationskontrakt. Denne kopi bliver gemt, som den seneste udgave af integrationskontrakten, der tilhører borgeren, med den angivne slutdato (IntegrationContractEndDate). Det er derfor også muligt at angive et id, man ønsker den nyoprettede integrationskontrakt skal have (hvis et id ikke angives i kaldet, tildeler DFDG et guid til den lukkede integrationskontrakt). Det vil sige at den "IntegrationContractIdentifier" som kan angives i kaldet ikke må være den samme som guid'en for den integrationskontrakt der lukkes, da der i så fald vil eksistere to integrationskontrakter med samme id og dette er ikke tilladt.

Når en integrationskontrakt lukkes, berører metoden kun integrationskontraktdata. Eventuelle fravær, aktiviteter, registreringer i den snævre plan m.v. berøres ikke. De skal håndteres separat i de relevante services af en sagsbehandler.

Håndtering af fejloprettede integrationskontraktdata

Der er ikke eksplicit understøttelse for at markerer en integrationskontrakt som værende fejloprettet. 

Aktiv integrationskontrakt for en borger

Så længe der er en integrationskontrakt på en borger er den aktiv i forhold til Jobnet. Det er først når en sagsbehandler afsluttet integrationskontrakten den forsvinder i forhold til borger på Jobnet. Se afsnit Lukning af integrationskontrakt.

Link til snitfladebeskrivelsen

Link til forretningsbeskrivelser

 

Found 1 search result(s) for IntegrationContractService.


Metoder

CreateIntegrationContract

Metoden oprettet integrationskontraktdata i DFDG.

Forretningsregler

  • Integrationskontraktdata kan først gemmes på eller efter den tidlige overtagelsesdato for integrationskontrakt (EarlyIntegrationContractTransitionDate), hvis denne er angivet (se AsylumService for regler for hvornår der må oprettes en tidlige overtagelsesdato m.v.).
  • Hvis der er angivet en overgivelsesdato (AsylumTransitionDate) men ingen tidlig overtagelsesdato (EarlyIntegrationContractTransitionDate), kan integrationskontraktdata først gemmes på eller efter overgivelsesdato.
  • Hvis hverken overgivelsesdato (AsylumTransitionDate) eller den tidlige overtagelsesdato (EarlyIntegrationContractTransitionDate) er angivet, kan integrationskontraktdata gemmes. 
  • Der laves et ny kopi (selvstændig GUID), hver gang der oprettes en ny ”udgave” af integrationskontrakten i DFDG, hvilket sikrer, at der laves fuld tilgængelig historik fra MinPlan og GetIntegrationContract.
  • Ved angivelse af datoen for underskrift af første kontrakt (IntegrationContractFirstSigningDate), skal denne ligge tilbage i tiden eller være lig med dags dato.
  • Ved angivelse af slutdato for integrationsprogrammet (IntegrationProgramEndDate) og der på integrationskontrakten er angivet en startdato for integrationsprogrammet (IntegrationProgramStartDate), så kan angivne slutdato for integrationsprogrammet (IntegrationProgramEndDate) ikke ligge længere tilbage end startdatoen for integrationsprogrammet (IntegrationProgramStartDate).
  • Ved angivelse af sprog i kollektionen hertil, skal hvert enkelt sprog identificeres med enten en kode for sproget (LanguageCodeTypeIdentifier) eller det danske navn for sproget (LanguageName). Det er således ikke muligt at udelade begge værdier hertil, ligesom det ikke er muligt at angive begge værdier.
  • Ved angivelse af sprog i kollektionen hertil, skal de sprog, som er identificeret med en kode for sproget (LanguageCodeTypeIdentifier), være kendt i DFDG’s kodeliste over sprog (GetLanguagesTypeIdentifierCodeList).
  • Ved angivelse af sprog i kollektionen hertil, skal hvert enkelt sprog være unikt. Det er således ikke muligt at angive:
    • To eller flere sprog i kollektionen med den samme kode for sproget (LanguageCodeTypeIdentifier).
    • To eller flere sprog i kollektionen med det samme danske navn for sproget (LanguageName).
    • Et sprog i kollektionen, hvor koden for sproget (eksempelvis 10) matcher et andet sprog i kollektionen, hvor det danske navn for sproget er angivet (eksempelvis Dansk).
  • Ved angivelse af datoen for, hvornår der sidst er givet meddelelse til udlændingen om konsekvenserne om manglende dansktilegnelse, jf. bek. § 15, stk. 9 og 11 (LastModifiedInformedAboutMissingDanishQualifications), skal denne ligge tilbage i tiden eller være lig med dags dato.
  • Ved angivelse af datoen for, hvornår der sidst er vejledt vedr. konsekvenserne vedr. manglende dansktilegnelse, ifht I-ydelsen, familiesammenføring, tub (LastModifiedInformedAboutMissingDanishQualificationsRegardingBenefits), skal denne ligge tilbage i tiden eller være lig med dags dato.
  • Ved angivelse af datoen for, hvornår der sidst er vejledt om, at medbragt formel uddannelse kan vurderes af Styrelsen for Videregående Uddannelser (LatestGuidedRegardingExistingEducation), skal denne ligge tilbage i tiden eller være lig med dags dato.
  • Når der foretages en oprettelse af en integrationskontrakt, sættes der samtidigt et flag, som angiver at Jobcenteret henter integrationskontrakter fra DFDG fremover.

GetIntegrationContract

Metoden henter integrationskontraktdata fra LetAsyl / DFDG.

Forretningsregler:

  • Skiftesporslogik i DFDG sikre, at data hentes i LetAsyl eller fra DFDG, alt efter hvordan Jobcentret har sat den tidlige overtagelsesdato for integrationskontrakt (EarlyIntegrationContractTransitionDate) og om data er gemt i DFDG allerede. 
  • Integrationskontraktdata kan ikke hentes i LetAsyl, med mindre der er oprettet Overgivelsesdato (AsylumTransitionDate) og en modtagende kommune (TransitionAythority).
  • Hvis skiftesporslogik i DFDG tilskriver, at data skal hentes i LetAsyl, vil DFDG hente så længe data er tilgængelig i LetAsyl (ikke falder for forældelsesregler i LetAsyl).
    Bemærk: DFDG kender ikke, hvor længe LetAsyl holder data tilgængelig.
  • Kun den kommune, der modtager flygtningen (TransitionMunicipality) og som vil være angivet i CVService.CreateAsylumTransition/UpdateAsylumTransition, kan hente data i LetAsyl.
  • Det er den seneste udgave af borgerens integrationskontraktdata, der hentes, hvis der ikke er angivet en specifik IntegrationContractIdentifier (guid). Har borgeren ikke en integrationskontrakt returneres et tomt response.
  • Det er den specifikke udgave af borgerens integrationskontraktdata, der hentes, hvis der angives en specifik IntegrationContractIdentifier (guid). Har borgeren ikke en udgave af integrationskontraktdata med denne specifikke IntegrationContractIdentifier fejler metoden.

Mapning af data fra LetAsyl 

Når der integrationskontraktdata hentes data fra LetAsyl sker der en mapning fra LetAsyl struktur til den struktuer der udstilles i GetIntegrationContract. for mapningsregler se 752.4 Bilag 1 Letasyl-DFDG mapning af snitflader

Tekstformatering / HTML

Når der hentes data fra LetAsyl vil DFDG fjerner de html tags fra tekstfelterne, som beskrevet i afsnittet "Tekstformatering / HTML" under /wiki/spaces/GI/pages/75858579.

TerminateIntegrationContract

Metoden lukker en integrationskontrakt.

Forretningsregler:

  • Slutdato for integrationskontrakten (IntegrationContractEndDate) skal ligge tilbage i tiden eller være lig med dags dato.
  • Slutdato ikke kan ligge længere tilbage end datoen for underskrift af første kontrakt (IntegrationContractFirstSigningDate), hvis denne dato er angivet for integrationskontrakten.