Page Comparison

Occupations fra Escostarservicen (Sp. 9. februar)

Q: Netcompany

A: STAR

Vi har nu 3 services der kan give os en OrganisationTypeCodeList

Den kan hentes via codelistservice v5 (SOAP), under JobSearch.CodeListService og nu også under Taxonomy.codelistService

I skriver bl.a. for JobSearch.CodeListsService (2020-4) at: ”Kodelisterne er dog gyldige på tværs af alle forretningsområder.”

Betyder det, at hvis vi henter den ene kodeliste ned i vores system, så er der ingen grund til at hente den fra de 2 andre services ?

Vi kan ikke på noget tidspunkt komme ud for, at kodeliste fra Taxonomy servicen komme til at indeholde en organisationstype, som ikke returneres med de andre services ?

20210215 RMA og Ole:

Der er tale om den samme masterkodeliste som bliver udstillet i de 3 siloer, hvilket gør, at du kan benytte den du vil.

Vi vil dog anbefale at du benytter den fra DFDG.

Occupations fra Escostarservicen (Sp. 9. februar)

Q: Netcompany

A: STAR

Ang. Metoden GetDiscoAms08ConceptUriMapping der tager discoAms08Id som input.

( wiki beskrivelse )

Er det korrekte forstået at der ALTID vil være en oversættelse fra discoAms til EscoStar tilgængelig.

J.fr. rapporten fra Deloitte:

Image Added

Der vil altså altid blive oprettet en ESCO_STAR kode for hver DISCOAMS stillingskode (niveau 3) – også selvom der ikke er en ESCO kode der i dag matcher.

Metoden vil derfor kun kunne returnere fejl, hvis man kommer med en invalid DISCOAMS stillingskode  - og det vil så være en der ikke eksisterer, ELLER en på niveau 1 eller 2 ?

20210215 RMA:

Det er korrekt at der er lagt op til at der ALTID vil være en oversættelse fra discoAms til en EscoStar kode, så såvel eksterne som internt kan foretage en konvertering.

Vedr. det med at der bliver oprettet Esco_Star kode for hver DiscoAms:

Vær opmærksom på at der kan være mulighed for at flere DiscoAms bliver mappet til den samme Esco_Star kode.

Metoden vil derfor kun kunne returnere fejl, hvis man kommer med en invalid DISCOAMS stillingskode  - og det vil så være en der ikke eksisterer, ELLER en på niveau 1 eller 2 ?

Korrekt

Occupations fra Escostarservicen (Sp. 8. februar)

Q: Netcompany

A: STAR

Vi har nu haft held med at få hentet occupations in fra EscoStarServicen 😊

 Men vi mangler en relationType i aliasser:

 Vi har anvendt:  https://taxonomyt3.startest.dk/swagger/EscoStar-v1/swagger.json

 Og får eksempelvis:

             "aliases": [               

{

                    "aliasIdentifier": "fe6ecdca-14b8-450d-979c-c2063766ccf9",

                    "conceptUriDa": "http://data.europa.eu/esco/occupation/c3cae318-8b15-4339-a617-1a66b9ff6609",

                    "originConceptUriEu": "http://data.europa.eu/esco/occupation/c3cae318-8b15-4339-a617-1a66b9ff6609",

                    "alternativeLabelEu": "dieselmotorbygger",

                    "alternativeLabelDa": "dieselmotorbygger",

                    "origin": 2,

                    "escoStarStatus": 1 

},

 Ifølge /wiki/spaces/GI/pages/2352185416   skulle der være en relationType efter ”origin” - den får vi ikke p.t.

Er det fordi det fortsat er 2020-4 version af servicen der udstilles på T3 ?

 Vil det være Taxonomy.EscoStarService (Version 1, 2021-1) beskrivelsen der er den mest rigtige at rette sig efter ?

Altså den der vil blive udstillet med 2021-1 ?

Rent datamæssigt hænger det således sammen:,

 ""origin": 2" - kommer fra før Escostaraliasrelationtype blev introduceret. Carsten/Rolf ved nok mere.

 Der arbejdes lige nu med  Escostaraliasrelationtype i indlæsningen af data.   

 ... der kan antage værdien 1-3. 

 angiver at det er EU alias.

Denne type er fravalgt af STAR.

1. angiver at det er et "nyt", dansk alias. I dette tilfælde er originConceptUriEu NULL.

2. angiver at det er en EU ESCO stillingsbetegnelse, originConceptUriEu indeholder den (originale) EU URI for den fravalgte stilling.

3. angiver at det er en EU ESCO stillingsbetegnelse, originConceptUriEu indeholder den (originale) EU URI for den fravalgte stilling.

Image Added

Carsten/Rolf: Hvordan ser det ud i miljøet?

20210215 RMA:

På følgende side vil du kunne se den blivende ESCO-STAR GetOccupation og GetOccupations:

/wiki/spaces/GI/pages/2352185416

Der vil blandt andet relationType, origin og originConceptUriEu være en del af det, der kan komme ud på Aliasser.

Image Added

Vi er i gang med at identificere, hvorfor disse ændringer ikke er kommet ud på T3 og T4 miljøerne.

Opdatering:

20210216 RMA:

T3 og T4 skulle der nu være adgang til at få de nyeste version af EscoStarService, hvor relationType på Aliasser kan forekomme.

976.8 (Sp. til 5. februar)

Q: Netcompany

A: STAR

Jeg har tilføjet en kommentar til epic 976.8 – fordi jeg synes, det er svært at finde det sted hvor der præcist står hvilken service/metode vi skal anvende for at få hentet ESCO-STAR koderne ind og de underliggende kodelister.

Det jeg efterlyser er nok en kobling mellem de epics vi skal give tilsagn til, og så den virkelighed der er for de services i har implementeret.

Hvis jeg alene læser det der står i epic 976.8 synes jeg det er svært at gennemskue hvordan I har implementeret taxonomi delen.

Når jeg så går ”på opdagelse” på jeres service beskrivelser på wiki, så får jeg et mere klart billede af det – men jeg vil gerne være sikker på, at jeg kigger de rigtige steder, og ikke selv får strikket en forkert historie sammen.

Det jeg kort fortalt efterlyser er, hvilken epic omhandler selve indlæsningen af Occupations fra Taxonomy servicen ?

A: RMA og CO 04-02-2021

I epic vil der typisk være link til de nye serviceversioner med ESCO STAR f.eks. for 976.8 findes der link til de nye serviceversioner for:

UnemploymentEnrollmentService (Version 8 [UDV], 2021-2)

og JobSearch.CvService (Version 2 [UDV], 2021-2)

Her er ændringerne vist i forhold til snitfladen. På de tilhørende forretningssider vil vi opdater forretningsreglerene. disse er pt. kun nævnt i epic.

A: KPP 04.02.2021: Den aktuelle status for den ny version af UnemployentEnrollmentService (v8) fremgår på siden /wiki/spaces/GI/pages/2767323267 (der afspejler den kodede snitflade).

Indlæsning/Udtræk af taxonomy data (Sp. til 5 feb.)

Q: Eksterne

A: STAR

Hvornår bliver taxonomy tilgængelig på testmiljøerne?

BIs har foretaget dataindlæsning på T3 og T4, så man nu kan kan kalde servicen direkte og gemme returneringen af data til fil, for derefter at sende dette.

Indeholder alle felterne I vil få ud af servicen, og kan bruges til at få et overblik over, udformning af data, Der er tale om testdata der kan ændre sig.

Note: RMA og CO 04-02-2021. Data kan stadig ændre sig da STAR, BI og Deloitte arbejder med at QA nomenklaturen.

Note: TEHJ 15-02-2021: ESCO STAR Masterdata i xlsx-fil - ESCO STAR Masterdata

976.8 (Sp. til 5. februar)

Q: Netcompany

A: STAR

976.8 er en stor epic, der beskriver de fleste ændringer i forhold til ESCO-STAR stillingskodernes påvirkning på de services hvor koderne anvendes.

Jeg synes ikke ar den særlig godt beskriver selve introduktionen af Taxonomy.EscoStarService (2021-1)  - det skal man finde som et under punkt for epic.

Hvorfor er dette ikke beskrevet enten i en separat epic, eller taget med i 976.8?   - med korrekte  på virkninger til snitflader.

Se svar nedenfor.

976.8 (Sp. til 5. februar)

Q: Netcompany

A: STAR

I epic 976.8 er der nævnt en ”Taxonomy,CodeListService.GetOccupations” kodeliste, der efter min overbevisning ikke kommer til at eksistere?

Som jeg forstår det, ud fra det jeg kan tyde på wiki beskrivelsen af servicer under: Taxonomy services

Så er følgende services ”i spil”:

• Under ”ESCOSTARService (2020-4)” er der en getOccupations

• Under Taxonomy.EscoStarService  er der beskrevet en GetOccupations metode  - som er den jeg forventer at vi skal anvende ?

Under Taxonomy.Codelist (Taxonomy.CodeLists )

Står beskrevet i de mere ”simple” kodelister vedrørende taxonomy   - men altså ikke occupations.

Så det forvirrer mig lidt, når der er så mange muligheder, og jeg har svært ved at finde det sted, hvor der står bøjet i neon, at du som a-kasse leverandør skal anvende XX servicen til at hente ESCO-STAR stillingskoder ind i det system.

A (RMA og KPP 05.02.2021):

Det er Taxonomy.EscoStarService.GetOccupation og Taxonomy.EscoStarService.GetOccupations, der udstiller hhv. en konkret og alle stillingsbetegnelser.

Der er i epics nu indsat link med intro bl.a. disse 2 metoder. Se eksempe i E 976.8: https://starwiki.atlassian.net/wiki/spaces/ISB/pages/1617363060/976.8+Udrulning+af+ESCO+STAR+p+Tilmelding+CV+Jeg+s+ger+job+som+raskmelding+og+automatch+inkl.+EURES#id-976.8UdrulningafESCOSTARp%C3%A5Tilmelding,CV (linket springer desværre ikke til afsnittet)

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: KMD

A: STAR

Jeg tænker vi snart bliver indkaldt til forretningsmøde ang. 976.10 om ændringer til ”kvalifikationer”?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: KMD

A: STAR

Når jeg skriver ”Forretningsmøde”, så er det fordi at den epic er væsentlig anderledes en det normale mønster for opdateringer af kodelister.

Det burde måske have været taget med på det seneste WS møde. Jeg tænker at Kasper måske kan bringe lidt lys på emnet på fredag. Eks. er det planen at alle kodelister skal omlægges. Frekvens, opdatere WSRM på kode eller liste niveau (Opret/ret/…)…

Har du mulighed for at uddybe hvad du har brug for bliver belyst (Kasper)?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: KMD

A: STAR

At en kodeliste bliver opdateret via WSRM er et nyt mønster som vi alle skal generalisere en implementering af.

Derfor vil det være på sin plads at vi lige gennemgår metodikken bag sådan en udstilling.

Eks.

Vil kodelister fremover skifte antal af Attributter… eller er ESCO blot en undtagelse?

Hvilke oplysninger vil en WSRM besked om en kodeliste have? Er vi på ID niveau?

Er det behov for en varsling ved ændring af /tilføjelse af forekomster i en kodeliste?

Eks. hvor lang tid må det gå fra en kode tilføjes til den reelt kan benyttes… og dermed at den også skal være tilgængelig i alle systemet som kan modtage/behandle objekter med den omhandlende kodetype.

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: KMD

A: STAR

Jeg tænker vi snart bliver indkaldt til forretningsmøde ang. 976.10 om ændringer til ”kvalifikationer”?

976.10 kommer med i tilsagnsbølge - 10. februar.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: KMD

A: STAR

Når jeg skriver ”Forretningsmøde”, så er det fordi at den epic er væsentlig anderledes en det normale mønster for opdateringer af kodelister.

Det burde måske have været taget med på det seneste WS møde. Jeg tænker at Kasper måske kan bringe lidt lys på emnet på fredag. Eks. er det planen at alle kodelister skal omlægges. Frekvens, opdatere WSRM på kode eller liste niveau (Opret/ret/…)…

Har du mulighed for at uddybe hvad du har brug for bliver belyst (Kasper)?: Netcompany

A: STAR

Vi har kigget i denne epic, selv om den endnu ikke er sendt i tilsagn.

 Vi har en del spørgsmål ang. CV kvalifikationer.

De er måske lidt på grænsen mellem forretning og teknik.

Vi er lidt i tvivl om hvor vigtige kvalifikationer er for os, og hvad kvalifikationer er for størrelse.

Har CV kvalifikationer noget at gøre med ”Søjle 3” Uddannelse(Qualifications) i ESCO ?

(Den som Ditte (Netcompany) spurgte ind til i manuscript sag: 214971)

Epic kommer ud i tilsagnbølge 2 i 2021-2.

Nej, ESCOs søjle 2 omhandler færdigheder og kompetencer, søjle tre Uddannelse, men ingen af disse er en del af ESCO-STAR-projektet. p.t. Søjle 2 og 3 er endnu ikke obligatorisk for medlemslandende.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: KMD

A: STAR

At en kodeliste bliver opdateret via WSRM er et nyt mønster som vi alle skal generalisere en implementering af.

Derfor vil det være på sin plads at vi lige gennemgår metodikken bag sådan en udstilling.

Eks.

Vil kodelister fremover skifte antal af Attributter… eller er ESCO blot en undtagelse?

Hvilke oplysninger vil en WSRM besked om en kodeliste have? Er vi på ID niveau?

Er det behov for en varsling ved ændring af /tilføjelse af forekomster i en kodeliste?

Eks. hvor lang tid må det gå fra en kode tilføjes til den reelt kan benyttes… og dermed at den også skal være tilgængelig i alle systemet som kan modtage/behandle objekter med den omhandlende kodetype.)

Q: Netcompany

A: STAR

I Epic står der at kvalifikationer tidligere refererede til DISCOAMS (Stillingskoder?)  og nu skal referere til ESCO-STAR.

Men det er ikke ESCO-STAR stillingskoder vel?  (Tidligere var det jo et statisk kodeliste med elementer der ikke var stillingskoder)

(OccupationQualificationsTypeIdentifier )

Kvalifikationer der returneres i den nye QualificationService.GetQualifications  - står som (ConceptUriDaType) – er det et stillingskode id?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

Eksisterende kvalifikationer flyttes over i taxonomy siloen og som noget nyt vil de ikke længere linkes op til DiscoAms, men op til de tilsvarende ESCO-STAR koder for stillingsbetegnelser.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STAR

Vi har kigget i denne epic, selv om den endnu ikke er sendt i tilsagn.

 Vi har en del spørgsmål ang. CV kvalifikationer.

De er måske lidt på grænsen mellem forretning og teknik.

Vi er lidt i tvivl om hvor vigtige kvalifikationer er for os, og hvad kvalifikationer er for størrelse.

Har CV kvalifikationer noget at gøre med ”Søjle 3” Uddannelse(Qualifications) i ESCO ?

(Den som Ditte (Netcompany) spurgte ind til i manuscript sag: 214971)

Nej, ESCOs søjle 2 omhandler færdigheder og kompetencer, søjle tre Uddannelse, men ingen af disse er en del af ESCO-STAR-projektet. p.t. Søjle 2 og 3 er endnu ikke obligatorisk for medlemslandendeHvorfor er kvalifikationer vigtige for os som a-kasse at kunne håndtere?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

Koblingen mellem en kvalifikation og en ESCO-STAR stillingsbetegnelser bruges primært af STAR ift. CV’er i relation til rådgivning af borgere om valg, men der er ikke noget i vejen for at I har adgang til data.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STAR

I Epic står der at kvalifikationer tidligere refererede til DISCOAMS (Stillingskoder?)  og nu skal referere til ESCO-STAR.

Men det er ikke ESCO-STAR stillingskoder vel?  (Tidligere var det jo et statisk kodeliste med elementer der ikke var stillingskoder)

(OccupationQualificationsTypeIdentifier )

Kvalifikationer der returneres i den nye QualificationService.GetQualifications  - står som (ConceptUriDaType) – er det et stillingskode id?

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STAR

Hvorfor er kvalifikationer vigtige for os som a-kasse at kunne håndtere?Hvorfor kommer der en ny hændelse til kvalifikationer?

• Og er det på grund af den nye besked (WSRM) GetQualificationVersion1 at vi skal hente kvalifikationer ind?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STAR

Vil WSRM kun indeholde et id (kodeliste id) og for at kunne oversætte det til noget forståeligt skal vi så indlæses alle kvalifikationer.

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STAR

Hvorfor kommer der en ny hændelse til kvalifikationer?

Er der vigtige ting der skal håndteres, når kvalifikationer ændrer sig?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STARVil

WSRM kun indeholde et id (kodeliste id) og for at kunne oversætte det til noget forståeligt skal vi så indlæses alle kvalifikationerEr kvalifikationer også dækket af CvUpdate hændelsen?

Epic kommer ud i tilsagnbølge 2 i 2021-2.

976.10 CV-kvalifikationer 15 Dashboard (Sp. til 5. feb.)

Q: Netcompany

A: STAR

Er der vigtige ting der skal håndteres, når kvalifikationer ændrer sig?

976.10 CV-kvalifikationer (Sp. til 5. feb.)

Q: Netcompany

A: STAR

Er kvalifikationer også dækket af CvUpdate hændelsenfebruar)

Q: Netcompany

A: STAR

Vi har brug for en lidt mere info om tanker/beslutninger omkring den nye service EscoStarDataService(Version 1) som nævnes i epicen.

 Der lægges op til, at det er en ny version af DiscoCodesService (om-navngivning i stedet for version 7?). I "Oversigt over berørte webservices" nævnes det i sidste kolonne i tabellen, at der kommer en ny service der overtager fra  DiscoCodesService, men der står at der stadig mangler afklaring omkring placering, er det blevet endeligt besluttet nu?

976.15 Dashboard (Sp. til 5. februar)

Q: Netcompany

A: STAR

Vi har brug for en lidt mere info om tanker/beslutninger omkring den nye service EscoStarDataService(Version 1) som nævnes i epicen.

 Der lægges op til, at det er en ny version af DiscoCodesService (om-navngivning i stedet for version 7?). I "Oversigt over berørte webservices" nævnes det i sidste kolonne i tabellen, at der kommer en ny service der overtager fra  DiscoCodesService, men der står at der stadig mangler afklaring omkring placering, er det blevet endeligt besluttet nu?

976.15 Dashboard  Vi har ikke tidligere benyttet DiscoCodesService, så som udgangspunkt berøres vores systemer ikke af overgangen til EscoStarDataService, men vi vil evt. gerne informere vores kunder om de potentielle muligheder der kan være i servicen.
Er de tre metoder på servicen tænkt som en mulighed til at give forslag til f.eks. et medlem der skal udfylde information om 'Occupations'? Eller hvad er tanken?

976.15 Dashboard (Sp. til 5. februar)

Q: Netcompany

A: STAR

Hvad er relationen til Dashboard og BIDataService?

Taxonomy (Sp. til 5. februar)

Q: NetcompanyKMD

A: STAR

 Vi har ikke tidligere benyttet DiscoCodesService, så som udgangspunkt berøres vores systemer ikke af overgangen til EscoStarDataService, men vi vil evt. gerne informere vores kunder om de potentielle muligheder der kan være i servicen.
Er de tre metoder på servicen tænkt som en mulighed til at give forslag til f.eks. et medlem der skal udfylde information om 'Occupations'? Eller hvad er tanken?

976.15 Dashboard (Sp. til 5. februar)

Q: Netcompany

A: STAR

Hvad er relationen til Dashboard og BIDataService?

Taxonomy (Sp. til 5. februar)

Q: KMD

A: STAR

Udpegning af ESCO instanser som kan benyttes ved indberetning af en ”stillingsbetegnelse” i andre DFDG service.

Det jeg prøver at finde ud af……. er den simple formel for at udpege hvilke ”ConceptUriDa”, ud af alle dem som findes bag servicen, der kan indberettes som en stillingsbetegnelse via eks. tilmeldeservicen.

Min revurderede antagelse er,  at hvis både IscoGroup og IscoCode er udfyldt og status  er” Aktiv”, da kan den pågældende ”ConceptUriDa” anses for at være en valid stillingsbetegnelse der kan benytte ved eks. en tilmelding.

Er dette korrekt?

Jeg vil gerne anbefale at strukturen til taxonomien tilføjes et simpelt flag som kan angive ovenstående tilstand.

Det vil sikre at serviceaftagere bedre forstå indhold og brugen af taxonomien.

Det er et testdata-issue, hvor alle stillingsbetegnelser er markeret med status=1 lige nu. 

Aktive, danske stillingsbetegnelser kodes med status=1 i tabellerne, ikke-aktive stillingsbetegnelser (mange ESCO-stillingsbetegnelser fra EU konverteres til aliaser for aktive stillinger, andre fravælges) markeres som fravalgt med status=3.

EscoStarStatus=1 vil udpege en aktiv stilling i den danske taksonomi, 2 vil pege på en EU-inaktiveret stilling (jeg tror ikke vi har den slags endnu), 3 en markering for en stilling, der er fravalgt i den danske taksonomi - dem vil der i øvrigt være mange af, så jeg forstår forvirringen.

IscoCode skal ikke bruges til noget i min optik. En stilling vil referere til en firecifret ISCO08-gruppe, det har mest statistiske implikationer.. 

Udpegning af ESCO instanser som kan benyttes ved indberetning af en ”stillingsbetegnelse” i andre DFDG service.

Det jeg prøver at finde ud af……. er den simple formel for at udpege hvilke ”ConceptUriDa”, ud af alle dem som findes bag servicen, der kan indberettes som en stillingsbetegnelse via eks. tilmeldeservicen.

Min revurderede antagelse er,  at hvis både IscoGroup og IscoCode er udfyldt og status  er” Aktiv”, da kan den pågældende ”ConceptUriDa” anses for at være en valid stillingsbetegnelse der kan benytte ved eks. en tilmelding.

Er dette korrekt?

Jeg vil gerne anbefale at strukturen til taxonomien tilføjes et simpelt flag som kan angive ovenstående tilstand.

Det vil sikre at serviceaftagere bedre forstå indhold og brugen af taxonomien.

Det er et testdata-issue, hvor alle stillingsbetegnelser er markeret med status=1 lige nu. 

Aktive, danske stillingsbetegnelser kodes med status=1 i tabellerne, ikke-aktive stillingsbetegnelser (mange ESCO-stillingsbetegnelser fra EU konverteres til aliaser for aktive stillinger, andre fravælges) markeres som fravalgt med status=3.

EscoStarStatus=1 vil udpege en aktiv stilling i den danske taksonomi, 2 vil pege på en EU-inaktiveret stilling (jeg tror ikke vi har den slags endnu), 3 en markering for en stilling, der er fravalgt i den danske taksonomi - dem vil der i øvrigt være mange af, så jeg forstår forvirringen.

IscoCode skal ikke bruges til noget i min optik. En stilling vil referere til en firecifret ISCO08-gruppe, det har mest statistiske implikationer.. 

Rolf og Carsten 2021-02-10:

Hvis stillingsbetegnelse har en ISCOGroup defineret og er aktiv eller at validFrom og validTo er indenfor valideringen indenfor det forretningsmæssige område, kan denne stillingsbetegnelse benyttes og stillingsbetegnelsen er i niveau 5 eller under.

RMA 20210212:

Præcisering:

• Hvis stillingsbetegnelse har en IscoGroup defineret er det en stillingsbetegnelse.

• Hvis stillingsbetegnelse er Aktiv og validFrom og validTo, er indenfor tidspunktet registreringen omhandler, kan denne benyttes.

• Ovenstående er i niveau 5 eller under.

Taxonomy (Sp. til 5. februar)

Q: KMD

A: STAR

For at kunne kode op til STAR 2021-2 skal vi implementere vores egen lokale kopi af ESCOSTAR med tilhørende operationer til at fremsøge og udstille relevante ”Stillingsbetegnelser” til brug for oprettelse af eks. tilmelding fra vores egen applikation. På samme måde som Jobnet skal hjælpe borgeren, ved at vise relevante/mulige stillingsbetegnelser, når borgeren tilmelder sig via Jobnet.

 Hvis min antagelse i første spørgsmål er korrekt, så vil vi gerne vide, om der som en del af omlægningen vil komme være services, hvor det forventes at der skal kunne indsende ESCOSTAR ”koder” som ikke lever op til ”spørgsmål 1”.

Her tænker jeg specielt på ”Planmål”.

Følger af svaret ovenfor (Nikolaj).

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Hvem konverterer hvad?

STAR konverterer i blandt andet DFDG, hvor det er aftager selv der skal konvertere, hvis der er lokalt data.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Er der tale om kodelister vi kan abonnere på, eller skal der ske opslag hver gang?

Der er tale om en avanceret kodeliste, hvor I vil få WSRM-besked ved ændringer.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

IT ønsker en konverteringstabel, men syntes ikke, de kan læse ud af materialet om STAR stiller det til rådighed?

Der vil være en servicemetode der vil kunne benyttes:

For enkelt:Taxonomy.EscoStarService (Version 1, 2021-1)

/wiki/spaces/GI/pages/2352185416

 For alle:Taxonomy.EscoStarService (Version 1, 2021-1)

/wiki/spaces/GI/pages/2352185416

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

I har i noterne til jeres mail skrevet, at ”Det vil være en simpel én til én udskiftning af et DiscoAms felt til fremadrettet at være et ESCO-STAR felt.”, kan I oplyse om/hvordan det besvarer spørgsmålene?                                             A: Du kan se eksempel på dette nedenstående for UnemploymentEnrollmentService.UnemploymentEnrollment:

UnemploymentEnrollmentService (Version 8 [UDV], 2021-2)

Vi mener, at kunne konstatere, at i det omfang vi ikke abonnerer på WSRM-beskeder, som er en kopi af, hvad vi selv har sendt til DFDG, så er vi nødt til selv at konvertere lokalt gemte data (f.eks. JobSearchDefinition).

Kan det bekræftes?

Dvs. Hvis a-kassens data vedr. jobsøgningskrav ikke matcher DFDGs datasæt om jobsøgningskrav (efter release 2021-2), fordi a-kassen kun sender data til DFDG, men ikke får dem retur herfra, og fordi DFDG har konverteret data i f.t. stillingsbetegnelser, så skal vi/a-kasserne vel også ”gøre noget” (fx konvertere data) for at have samme data som DFDG vedr. jobsøgningskrav. Da jeg læste epic sidst, var der intet acceptkriterium omkring dette.   Vi skal konvertere lokale data, men det forekommer mig, at der var andre løsninger fremme: vi kunne hente jobsøgningskrav fra DFDG efter de var konverteret her. Det er også derfor, jeg synes epic 976.3 er relevant for a-kasser.

Hvorfor skulle der ikke det i 2021-2?, epic er placeret i 2021-3. Epic 976.9.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Er der andre løsninger?                                      

Vi/FOAs A-kasse er jo netop ikke aftagere af disse data. Vi opretter dem selv, sender dem til DFDG og så gør vi ikke mere (i dag). Jeg spurgte på WS-mødet, om der var en løsning i at vi abonnerede på WSRM-beskeder vedr. disse data, som jo kommer fra os selv. Det var der ikke så meget fidus til, fordi vi ikke kan sikre, at få alle data opdateret på den måde.

Ja det er der mulighed for, hvis det er det man abonnere på det, dog skal aftagere, der registrerer data, fremadrettet benytte sig af ESCO-STAR.

A: KPP 05.02.2021: Konkret er der dog ikke WSRM’er, der indeholder de indberettede krav til jobsøgning.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Vi bliver nødt til at ændre i vores afsendelse af aktiviteter, fordi vi ikke må bruge den version, som er i drift nu, og der skal ændres i hentning af aktiviteter af samme årsag - kan det undgås?

STAR bestemmer om man vil kunne indbygge nogle valideringer så KSSer ikke kan kalde den "gamle version".

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Det handler om ActivityServiceVersion4. Spørgsmålet er om DFDG kunne leve med, at undlade at skifte versionsnr., fordi a-kasser kun sender kursusaktiviteter, hvor der ingen stillingsbetegnelser er. Alle a-kasser skal altså løse opgaver vedr. afsendelse af aktiviteter, som de absolut ingen glæde har af, hvis der skal skiftes version. Man kunne lade den nugældende version leve videre for a-kasser?

At forblive på version 4 og lave ændringer direkte i denne er ikke en mulighed, da der er snitflade ændringer fremadrettet.

Aktiviteter er en del af 976.14 Min plan mål, inkl udkast til Min plan, VITAS m.v.

Som først er sat til at blive udviklet i 2021-3.

A: KPP 05.02.2021: Det er ikke en mulighed at holde v4 åben. Konkret vil FOA skulle skifte til v6 og ophøre med at bruge v3, v4 og v5, der alle bruges af FOA i dag. Bl.a. vil GetActivity fremover indholde ESCOSTAR stillingsbetegnelser mod i dag DISCOAMS.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Som Sagsbehandler eller jobkonsulent vil jeg kunne angive ESCO-STAR ved - Collection profession gøres til null – er der en erstatning?

Der ændres ikke i snitflader og regler i forhold til professionTypeCollection, det skal angives ved tilmelding, ud over at det fremadrettet skal angives som ESCO-STAR fremfor DiscoAms08, AliasIdentifier er optionelt.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

976.9 KSS og a-kasser ibrugtager i 2021-3 nye versioner af webservices med ESCO-STAR – hvad ligger der i det acceptkriterie?

976.9.2, hvor A-kasser skal indberette ESCO-STAR fremfor DiscoAms ved, krav til jobsøgning.

976.17 Vi tilslutter os bemærkningerne fra Schultz af 3. dec.

976.13, 15, 16, 18, 20

 Som det fremgår af epic er nogle ikke relevant for a-kasser.

15, 20: Ja, hvis ikke i gør brug af tidligere frivillige services.

16: : Ja, hvis ikke i gør brug af tidligere frivillige services.

18: Som det fremgår af epic er denne ikke relevant for a-kasser.

Flere epics (Tidligere spørgsmål)

Q: FOA

A: STAR

Vi synes, at I bør ”reklamere” mere for 976.3, hvor der findes nogle svar på strukturelle/tabelmæssige ændringer, som ligger til grund for flere andre epics.)

976.3 er en intern epic.