I det eksisterende KOT-Ansøgning er det vanskeligt for ansøgere at håndtere, hvis de efter at have godkendt en ansøgning, opdager, at de har tastet noget forkert eller glemt at oplyse en væsentlig detalje. Mange ansøgere ser ikke andre muligheder end at slette deres ansøgning og oprette en ny. Særligt for ansøgere til Kvote 2 kan dette have betydelige konsekvenser, hvis de ikke er opmærksomme på at gøre det før 15. marts-fristen. Desuden ses, at ansøgere i stedet for at slette kontakter uddannelsesinstitutionen, som retter de forkerte oplysninger i SA-systemet eller andet system udenfor KOT-Ansøgning. På denne måde er der risiko for at væsentlige oplysninger for fordelingen af pladser går tabt for KOT-Optagelse som det autoritative og centrale system.
Det har derfor været centralt i moderniseringen af KOT-Optagelse at sikre, at ansøgere i hele ansøgningsperioden kan redigere i data på ansøgninger på ansøgningsportalen, også efter at disse er godkendt og hentet af den modtagende institution.
Ansøgere kan redigere data indenfor rammerne af de to frister, hhv. 15. marts for primært Kvote 2 og 5. juli for Kvote 1. Data, som knytter sig entydigt til Kvote 2 og/eller 15. marts-fristen (fx grønlandsk særordning) (se Tabel 1), kan ændres indtil 15. marts-fristen, mens øvrige data kan ændre sig indtil 5. juli-fristen. Alle bilagstyper inkl. kvote 2 og grønlandsk særordning kan uploades i hele perioden og desuden i en kort periode efter 5. juli-fristen.
I tabellen herunder ses ansøgningsåret delt op i fem perioder. I de grønne perioder kan ansøgere redigere data og/eller tilføje bilag. I de hvide perioder er der lukket for alle ændringer, dog er det i den korte periode fra 5-10/7 muligt for ansøger at tilføje bilag (typisk efter udtrykt ønske fra institutionen til ansøger). Bemærk også, at ansøger efter 15. marts ikke kan redigere data for Grønlandsk særordning og Kvote 2, men kun uploade bilag. Endelig bemærkes, at visse data knytter sig til ansøger som person. Hvis de rettes på én ansøgning, vil ændringerne slå igennem på alle ansøgers ansøgninger.
Tabel 1. Redigeringsmuligheder betinget af frister
| Frist for oprettelse/redigering | Data | 1/2-15/3 | 15/3-16/3 (read only) | 16/3-5/7 | 5/7-10/7 (bilagsupload) | 10/7-31/1 (read only) |
| Frist for oprettelse/redigering | Data | 1/2-15/3 | 15/3-16/3 (read only) | 16/3-5/7 | 5/7-10/7 (bilagsupload) | 10/7-31/1 (read only) |
| Tidlig frist (15/3) (Se note 1) |
Ansøgerdata med tidlig redigeringsfrist
|
✒️Rediger data 📄Tilføj bilag 🗑️Slet bilag |
🔒Låst for redigering af data 🔒Låst for upload af bilag |
🔒Låst for redigering af data 📄Tilføj bilag |
🔒Låst for redigering af data 📄Tilføj bilag |
🔒Låst for redigering af data 🔒Låst for upload af bilag |
|
Ansøgningsdata med tidlig redigeringsfrist
|
||||||
| Almindelig frist (5/7) |
Ansøgningsdata uden tidlig redigeringsfrist
|
✒️Rediger data 🗑️Slet bilag |
||||
|
Ansøgerdata uden tidlig redigeringsfrist
|
Ad tabel 1: Vær særlig opmærksom på følgende:
Det fremgår enkelte steder i brugergrænsefladen, at ansøger kan tilføje bilag og redigere data frem til fristen. Det bliver dog ikke eksplicit forklaret, hvordan det gøres i selve brugergrænsefladen. I perioder, hvor alle eller enkelte datafelter er låst for redigering, er tilføjelsen af bilag muligt, men umiddelbart skjult i brugergrænsefladen bag et link, som indikerer, at ansøger alene kan se data, ikke at der kan tilføjes bilag. Dette design er valgt for at understøtte, at ansøgers tilføjelse af bilag sker på opfordring fra institutionen i sagsbehandlingen og ikke som noget ansøger bør gøre af egen drift.
Afhentningsservicen (REST-service), hvorigennem ansøgninger udstilles til modtagende institutioner via SA-systemerne, er designet med henblik på at understøtte institutioners arbejdsgange i et it-system, hvor ansøgere som noget nyt har muligheder for at redigere ansøgninger.
Webservicen består således af to metoder, der samlet gør det muligt at hente alle ansøgninger på én gang eller at hente ansøgninger, som har ændret sig siden et valgt tidspunkt, fx siden sidste afhentning. Udover disse to kernemetoder findes også en metode dedikeret til hentning af bilag.
Det er anbefalingen, at SA-leverandører anvender metoderne som tiltænkt: som deltakald. Således hentes ændringer i daglige/natlige kald med Metode 1 og med et fra-tidspunkt (epoch) svarende til tidspunktet for starten af det seneste forrige kald. Herved returneres de nye ansøgninger, der må være kommet samt de ansøgninger, som er ændret i perioden siden sidste hentning. Ydermere fremgår det af responset, hvis nogen af de returnerede ansøgninger er slettet. Ved sammenligning med det tidligere sæt af returnerede ID'er kan nye såvel som ændrede ansøgninger identificeres. Herefter kan data for disse hentes med Metode 2 i et samlet kald eller evt. i to separate kald, så de kan markeres som hhv. nye og ændrede i SA-systemets brugergrænseflade.
Disse kontinuerlige kald kan evt. kombineres med on demand-kald, når der i forbindelse med aktuel sagsbehandling er behov for at se en specifik ansøgning igennem det studieadministrative system. Her anbefales Metode 2 anvendt med angivelse af det konkrete ansøgningsID, hvorved returneres nyeste version af ansøgningen. Hvis kaldet ikke returnerer data, er ansøgning slettet.
Tabel 2. Metoder i Afhentningsservicen (REST-service) fra KOT Optagelse
| Version |
Metode |
Inputfelter |
Beskrivelse (input) |
Beskrivelse (response) |
| 1.1.0.0 |
Metode 1 (GET) https://et-services-kottil.mitoptag.dk/SA/Ansoegning/1.1.0.0/GetAnsoegningerIds |
|
Institutionsnummer er ejerinstitutionen, der hentes ansøgninger for.
AnsoegningAendretFra er epoch for det tidspunkt, data ønskes hentet fra, fx siden sidste hentning. Der udstilles nye ansøgninger og ændrede ansøgninger siden epoch. |
ansoegning_id er ID på ansøgningen i KOT. institutionsnummer er institutionsnummeret på undervisningsinstitutionen. ejer_institutions_nummer er institutionsnummeret på ejerinstitutionen. sidst_opdateret er, hvornår der sidst er sket en opdatering relateret til denne ansøgning. ansoegning_status er ansøgningens status, hvorvidt en ansøgning er gennemført eller slettet. |
|
1.1.0.0 |
Metode 2 (POST) https://et-services-kottil.mitoptag.dk/SA/Ansoegning/1.1.0.0/GetAnsoegningListByIds |
|
Institutionsnummer er ejerinstitutionen, der hentes ansøgninger for. Body er en liste/array af integers. Dette er ansøgnings-id'er som en kommasepareret liste. |
Metadata for en ansøgning (der udstilles ingen metadata for slettede ansøgninger).
Metadata vil inkludere tilbagemeldingsdata om fordelingsresultatet. Dette gælder både tilbagemeldingsdata for endelig tilbagemelding og tilbagemeldingsdata for midtvejshøring. |
|
1.1.0.0 |
Metode 3 (GET) https://et-services-kottil.mitoptag.dk/SA/Ansoegning/1.1.0.0/HentBilagsUrl |
string (header)
integer($int32) (query) |
Institutionsnummer er institutionen, der hentes ansøgninger for. BilagId er ID for det bilag, der ønskes en URL for |
Indeholder URL: til filservice for hentning af bilag. Valid til hentning 1 gang og i 15 min. |
Med Metode 1 returneres en række data, som er centrale for at identificere ansøgninger, som allerede er kendt i et SA-system, men hvor der optræder ændringer:
Tabel 3. Response fra Metode 1 (se Tabel 2 for beskrivelse af Metode 1)
| Property | Beskrivelse | Supplerende beskrivelse |
| ansoegning_id | Unikt ID på ansøgningen | |
| institutionsnummer | Institutionsnummeret på undervisningsinstitutionen | Responset kan indeholde flere institutionsnumre afhængigt af, om ejerinstitutionen har flere afdelinger, hvortil der udstilles ansøgninger |
| ejer_institutions_nummer | Institutionsnummeret på ejerinstitutionen | Metode 1 kaldes med dette |
| sidst_opdateret | hvornår der sidst er sket en opdatering relateret til denne ansøgning. | En ansøgning indeholder et dato-tidsstempel for hver af følgende:
Hvis en af disse tre er opdateret siden sidste kald, vil ansøgningen figurere i responset på Metode 1. |
| ansoegning_status | ansøgningens status, hvorvidt en ansøgning er gennemført eller slettet. | Der udstilles ID for ansøgninger med hhv. status gennemført og status slettet i response fra Metode 1. Med Metode returneres alene data for ansøgninger i status Gennemført. |
I det følgende ses bort fra sidst_opdateret på TilbagemeldingSAHentDto.
Når en ansøgning, som er kendt i SA-systemet, dukker op i responset fra Metode 1, er der sket ændringer på ansøgningen og/eller konkret på ansøgeren, hvorved sidst_opdateret på en eller begge af de ovenfor nævnte datotidsstempler er opdateret.
Der kan være sket ændringer en eller flere gange i det forløbne tidsrum afhængigt af, hvilke ændringer ansøger har foretaget i brugergrænsefladen.
Desuden kan ændringerne være sket i en af de eksterne kilder (primært CPR-registeret og Eksamensdatabasen), som KOT Optagelse integrerer mod. Dette vil typisk dreje sig om ansøgerens navne- og adressedata samt CPR-nummeret fra CPR-registeret eller bevis- og suppleringsbevisdata fra Eksamensdatabasen, som er tilføjet, fjernet og/eller tilføjet i en opdateret version. Sidstnævnte vil desuden udmøntes i tilføjelse af et nyt bilag eller i sjældnere tilfælde fjernelse af et bilag.
Servicen udstiller ikke dedikeret information om, hvilke data, der er ændret. Det er derfor nødvendigt at SA-systemets kode kan sammenligne eksisterende data med seneste hentet data. Herfra kan det fx markeres i en brugergrænseflade, hvilke felter, der er ændret data i eller tilføjede data.
I det følgende eksempel tages udgangspunkt i det trin i ansøgers brugergrænseflade, hvor højskoleophold registreres som en del af Kvote 2-data. Som det ses i figur 1 har ansøger angivet et ophold på Højskolen i X-by på sin ansøgning. Når ansøgningen hentes i servicen, vil den kunne identificeres som ny ift. seneste afhentning, hvor den ikke eksisterede endnu.
|
Ifm. sagsbehandlingen undrer sagsbehandler sig over, at ansøger ifølge data har været på højskole i over 1½ år. Ansøgeren kontaktes derfor og forklarer, at det er en tastefejl. Ansøger retter sluttidspunktet i brugergrænsefladen på KOT Optagelse til 1. oktober 2024. Ved samme lejlighed oplyser ansøger endnu et højskoleophold, som ansøger gerne vil have med i vurderingen. Ved næste kald til servicen vil ansøgningen igen figurere i listen af ID'er, der hentes med Metode 1, fordi sidst_opdateret er ændret som følge af ansøgerens ændringer. Modtagende institution kan se de nye data og fortsætte sagsbehandlingen. |
I figurerne herunder ses ansøgers brugergrænseflade med det oprindelige og det ændrede højskoledata (Figur 1 og 3) samt udsnit af responses, der udstilles med hhv. den nye ansøgning (Figur 2) og den redigerede ansøgning (Figur 4). Bemærk, at der i Figur 4 er en ny sidst_opdateret dato-tidspunkt samt nu to elementer af højskoleophold. I begge tilfælde udstilles den fulde ansøgning.
Det bemærkes, at ansøger kun kan foretage ændringer i sine højskoledata indtil 15. marts-fristen. Efter fristen er det alene muligt at se de indtastede oplysninger. Dette gælder for alle Kvote 2-felter samt grønlandsk særordning, jf. tabel 1. ovenfor.
Figur 1. Registrering af højskoleophold på en ansøgning (som oprettes før 15. marts-fristen)

Figur 2. Udstilling af data i Afhentningsservicen (før ændring)

Figur 3. Redigering af højskoleophold på ansøgning fra Figur 1 og 2

Figur 4. Udstilling af data i Afhentningsservicen (efter ændring)
