Krav: vitnemålsbehandling i søknadsbehandling

[joranindseth]

Nytt krav for vitnemålsbehandling i søknadsbehandling. Erstatter to funksjoner i FS-klienten — vitnemålsbehandling (FS143.001 Vg.dokument) og vitnemålskalkulatoren — med ett samlet krav for FS Admin, steg 2 «Grunnlag».

Lukker ingenting ennå: kravet står som @draft til leveransekuttet er besluttet.

• Krav: krav/02 Opptak/13 Søknadsbehandling/01 Behandling/vitnemålsbehandling.feature (@OPT-BEH-BEH-004)
• Issue: Vitnemålsbehandling #607, med leveransene L1–L6 som sub-issues
• Confluence: Vitnemål og kvalifikasjoner (Steg 2) · Jira: SOPP-184

Hvorfor kravet trengs

Den automatiske saksbehandlingen stopper når søkeren har flere vitnemål. vurderKravelementerAutomatisk hopper over hele saken «uten entydig vitnemål», og beregnPoengAutomatisk har samme forutsetning (FlereVitnemaalException).

For generell studiekompetanse er dette allerede løst semi-automatisk med settGskKonklusjonFraVitnemaal, der saksbehandleren peker ut ett vgdoknr. For poengberegning og kravelementvurdering finnes ingen tilsvarende inngang. Det er hullet kravet fyller.

Hva som er avklart

Ti åpne spørsmål ble besluttet i gjennomgang med produkteier 21.09.2026. Hver beslutning står som AVKLART-kommentar ved scenarioet den gjelder, med begrunnelse og kildereferanse. De som er verdt å se nærmere på:

• Manuelt innlagte fag skal ha fagkode, valgt fra fagkodeverket. Dette er ny datamodell — verken SKOLEPOENGOPPLELEMENT i FS-klienten eller den allerede migrerte VitnemalKarakterrad har fagkode. Uten den kan et manuelt innlagt resultat bare påvirke snittet; realfagspoeng, språkpoeng og kravelementvurdering er utilgjengelige. Fritekst beholdes som nødløsning, med den begrensningen synlig for saksbehandleren.
• Fagvalget er per poengvariant, og det samme er valget av vitnemål. Begge datamodeller er entydige på dette (TILLEGGVARIANT nøklet på poengvariant, VitnemalUtregning på poengklasse_kode + poengvariant_kode). Designskissen viser én avkryssingskolonne og må forstås som valget for den varianten som er åpen.
• Tilleggsfag teller ikke før de aktivt velges. Dette avviker fra FS-klienten, som har to ulike defaulter i samme bilde (nvl(status_valgt,'J') i hovedlista, rå status_valgt i tilleggsfagslista). Forskjellen ser ut som en tilfeldighet og videreføres ikke.
• Tilgang styres av rettighet, ikke av tilordning. SE_SØKNADSBEHANDLING gir innsyn, MODIFISERE_SØKNADSBEHANDLING kreves for å endre. Ingen tjeneste i opptak-service sjekker tilordnet bruker før en endring, og kravet innfører ikke tilordning som tilgangsgrense.
• Annullerte vitnemål vises kun når de har vært brukt i en beregning på opptaket. Et tall saksbehandleren ser må kunne spores til grunnlaget sitt; gamle vitnemål som aldri har vært i bruk er støy.

Det viktigste enkeltfunnet

f_forbedretvitnemal(vgdoknr, poengvariant) returnerer 1 hvis vitnemålet har fag med status_forbedring = 'J', eller har et tilleggsfag som er valgt for den poengvarianten.

Konsekvensen er alvorlig og lett å overse: å huke av ett tilleggsfag gjør et førstegangsvitnemål forbedret, og kan slå søkeren ut av førstegangsvitnemålskvoten. En saksbehandler som gir søkeren noen tideler realfagspoeng kan koste hen kvoteplassen. Dagens løsning sier ingenting om dette. Kravet krever at konsekvensen fremgår i valgøyeblikket.

Avgrensninger

Dokumentert med begrunnelse nederst i filen: høyere utdanning (ELMO er umodellert, og #319 slår fast at det ikke er viktig for 2026), kobling til opplastet dokumentasjon (utenfor første leveranse), grunnlagsvalg (GSK), fagprofil og kravelementvurdering, tverrgående moduler i steg 2, og fagkonvertering mellom reformer.

Gjenstår

• Ett @openquestion: NVB_FAG skiller har_standpunkt_elev fra har_standpunkt_privatist. Skal skjemaet hindre standpunktkarakter på et fag søkeren tok som privatist? Uten håndheving går en karakter som ikke kan finnes inn i snittet. Blokkerer ikke hovedflyten.
• Leveransekuttet må besluttes før kravet kan settes til @planned. Forslaget ligger nederst i filen og som sub-issues på Vitnemålsbehandling #607.

Oppfølging i egne endringer

• behandle_søknad.feature har to skisselinjer dette kravet overtar («se resultater fra videregående skole» / «fra høyere utdanning»). Bør fjernes der.
• registrere_praksis.feature har to åpne spørsmål som er besvart her og bør lukkes likt.
• Tre ulike måter å beskrive samme aktør i repoet: rettigheter (her), «opptakssaksbehandler» (registrere_praksis), «saksbehandler for opptak» (behandle_søknad), og bare «saksbehandler» i gherkin-conventions.md. Bør samordnes — og spørsmålet er prinsipielt: skal krav beskrive tilgang med rollenavn eller med rettigheter?

🤖 Generated with Claude Code