...
| Innholdsfortegnelse | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
✅ Kvittering for sendt søknad (erstatter Vedleggsopplysninger)
| Tips |
|---|
Vi har nå lagt ut dokumentasjon av Kvittering for sendt søknad, og ønsker tilbakemelding på om beskrivelsen dekker behovene til søknads- og saksbehandlingssystemene. Vi har oppdatert tabellen under med innspill og foreløpige konklusjoner. |
...
Tema
...
Status
...
Beskrivelse
...
Oppfølging
...
✍️ Metadata for vedlegg
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Forslaget er åpen for innspill. |
Tema | Status | Beskrivelse | Oppfølging | |
|---|---|---|---|---|
Bruk av tegnings- eller versjonsdato og -nummer |
|
|
Legger metadata direkte på vedlegg via API i stedet for å legge de i en separat XML-innsending
Kvittering for innsending blir tilgjengelig via nedlasting etter innsending i stedet for at den blir generert direkte i Altinn.
Preview er ikke tilgjengelig
Les mer her: Kvittering for sendt søknad
Innspill fra arbeidsgruppemøtet 21.08.2024:
Begrepene tegningsdato- og nummer brukes, ikke versjonsdato og -nummer
Endring fra “Søknaden ble mottatt av kommunen” til “Søknaden ble sendt til kommunen”
Vi lager mer reelle eksempler med lange og vanskelige filnavn, nummer osv.
Vi vurderer om DiBK skal legge inn flere begrensninger for filstørrelse og -type
Ønske om validering/standardisering i dataene søknadssystemene leverer
Ønske blant søknadssystemene om preview av kvitteringen
Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet
Konklusjon: Vi kommer tilbake med et nytt utkast basert på innspillene vi fikk.
Mottak av metadata for eByggesakssystemet
| Status | ||||
|---|---|---|---|---|
|
vedleggsopplysninger.xml blir ikke tilgjengelig lenger, men metadata er i stedet tilgjengelig på vedleggene.
Les mer her: Kvittering for sendt søknad
Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet
Konklusjon: Ingen av mottakssystemene uttrykte ønske om å motta vedleggsopplysninger.xml. Vi går derfor videre med forslaget.
✅ Fjerning av konseptet underskjema
| Tips |
|---|
Ny endring i datamodellen. Vi fikk ingen innsigelser på arbeidsgruppemøtet, og går derfor videre med endringene. |
...
Tema
...
Status
...
Beskrivelse
...
Oppfølging
...
Underskjema fjernes fra datamodellene
...
| Status | ||||
|---|---|---|---|---|
|
...
I Altinn 3 er konseptet “underskjema” fjernet, og det skilles ikke mellom vedlegg og underskjema. Vi ønsker derfor å fjerne dette fra datamodellene.
Objektet underskjema ligger i datamodellene som har utfallBesvarelse og ettersending.
Endringen vil påvirke følgende søknader:
Søknad om igangsettingstillatelse
Søknad om midlertidig brukstillatelse
Søknad om ferdigattest
Supplering av søknad
I tillegg til at datamodellene blir endret, vil endringen påvirke valideringsregler for utfallsbesvarelse og kodelistene på GeoNorge.
Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet
Konklusjon: Vi fikk ingen innsigelser på arbeidsgruppemøtet og går derfor videre med endringene.
✍️ Supplering av søknad
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Datamodellen er ferdig avklart. Vi vil ha et eget arbeidsgruppemøte om supplering av søknad i løpet av høsten. |
Tema
Status
Beskrivelse
Oppfølging
Generelle innspill: hvordan funker Supplering av søknad i dag?
| Status | ||||
|---|---|---|---|---|
|
Vi inviterer søknads- og eByggesakssystemene til å gi generelle innspill om hvordan supplering av søknad fungerer i dag.
Vi inviterer til å gi innspill på arbeidsgruppemøtet
Oppfølging : Vi fikk følgende innspill på møtet:
Gjenpart av nabovarsel må være tilgjengelig ved supplering av søknad, da mange bruker supplering for å ettersende nabovarsel eller varsle på nytt
Det viktig at vi skiller mellom ettersending og søknad om endring av gitt tillatelse. Som en hovedregel kan vi si at en ettersending ikke skal saksbehandles før i neste delsøknad, hvis et vedtak allerede er gitt. Brukerne må få tydelig veiledning om dette.
Oppfølging: På arbeidsgruppemøtet ble det bestemt at vi skal ha et eget arbeidsgruppemøte for å bli enige om felles bruk. Mer informasjon kommer.
| På arbeidsgruppemøtet kom det frem at brukerne har et forhold til begrepet tegningsdato/-nummer, og ikke versjonsdato/-nummer. Vi skiller mellom bruken av begrepene i datafelt og brukergrensesnitt. Datafelt I dagens datamodeller og metadata i SvarUt bruker vi begrepene Brukergrensesnitt Selv om datafeltet heter PDF og validering I PDF og valideringsregler fra DiBK kommer blir begrepene | Forslaget er åpent for innspill. | |||||||
Obligatoriske metadata |
| Vi har lagt ut et forslag til hvilke metadata for vedlegg som skal være påbudt, og om de skal settes av DiBK eller søknadssystemene: Metadata om vedlegg | Forslaget er åpent for innspill. |
✍️ Kvittering for sendt søknad (erstatter Vedleggsopplysninger)
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Vi har nå lagt ut dokumentasjon av Kvittering for sendt søknad, og ønsker tilbakemelding på om beskrivelsen dekker behovene til søknads- og saksbehandlingssystemene. Vi har oppdatert tabellen under med innspill og foreløpige konklusjoner. Ny skisse for PDF er lagt ut og er åpen for innspill. |
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Ny PDF-visning |
| Vi har lagt ut en ny skisse av PDF-en med følgende endringer:
Grunnen til at vi ikke endret Les mer her: Kvittering for sendt søknad | Skissen er lagt ut og åpen for innspill. | ||||||
Arbeidsflyt for søknadssystemet |
|
Les mer her: Kvittering for sendt søknad Innspill fra arbeidsgruppemøtet 21.08.2024:
| Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Konklusjon: Vi kommer tilbake med et nytt utkast basert på innspillene vi fikk. | ||||||
Mottak av metadata for eByggesakssystemet |
|
Les mer her: Kvittering for sendt søknad | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Konklusjon: Ingen av mottakssystemene uttrykte ønske om å motta vedleggsopplysninger.xml. Vi går derfor videre med forslaget. |
✍️ Supplering av søknad
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Datamodellen er ferdig avklart. Vi vil ha et eget arbeidsgruppemøte om supplering av søknad i løpet av høsten. |
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Generelle innspill: hvordan funker Supplering av søknad i dag? |
| Vi inviterer søknads- og eByggesakssystemene til å gi generelle innspill om hvordan supplering av søknad fungerer i dag. | Vi inviterer til å gi innspill på arbeidsgruppemøtet Oppfølging : Vi fikk følgende innspill på møtet:
Oppfølging: På arbeidsgruppemøtet ble det bestemt at vi skal ha et eget arbeidsgruppemøte for å bli enige om felles bruk. Mer informasjon kommer. | ||||||
Endring i objektet for “ettersending” |
| Vi foreslår å gjøre to navneendringer i objektet ettersending, som vist med gule lapper i bildet under. Formålet med endringene er å oppdatere datamodellen til ny standard, slik at objektene blir like som for utfallBesvarelse.  | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Oppfølging : Saken er åpen for skriftlige tilbakemeldinger. Konklusjon Vi har ikke fått noen tilbakemeldinger. Saken lukkes. | ||||||
Endringer i datamodell for supplering av søknad |
| Vi foreslår å gjøre to navneendringer i objektet ettersending, som vist med gule lapper i bildet under. Formålet med endringene er å oppdatere datamodellen til ny standard, slik at objektene blir like som for utfallBesvarelse. noen mindre endringer i datamodellen for supplering av søknad. Formålet er å oppdatere til ny standard. Nytt forslag til datamodell medfører følgende endringer:
 Se dokumentasjon av ny datamodell her: Supplering av søknad - datamodell | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Oppfølging : Vi fikk ingen innspill på arbeidsgruppemøtet. Saken er åpen for skriftlige tilbakemeldinger. Konklusjon Vi har ikke fått noen tilbakemeldinger. Saken lukkes. Endringer i datamodell for supplering av søknad |
✍️ Gjennomføringsplan
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Vi har publisert et nytt forslag til bruk av ansvarsomraadeStatus. Saken er åpen for innspill. Resten av sakene er ferdig avklart. |
Tema | Status | Beskrivelse | Oppfølging | |
|---|---|---|---|---|
Bruk av ansvarsomraadeStatus (v3) |
|
Tema | Status | Beskrivelse | Oppfølging | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Bruk av ansvarsomraadeStatus (v3) |
| Se dokumentasjonsside med nytt forslag til statuser: Status for ansvarsområdet
|
Vi foreslår å gjøre noen mindre endringer i datamodellen for supplering av søknad. Formålet er å oppdatere til ny standard. Nytt forslag til datamodell medfører følgende endringer:
metadata oppdateres til ny standard, på samme måte som for IG, MB og FA
foelgebrev oppdateres til soeknadGjelder, på samme måte som for FA
ettersending oppdateres til nye standardfelter (se egen rad under)
mangelbesvarelse oppdateres til ny standard for utfallBesvarelse
ansvarForByggesaken legges inn som ny standard, på samme måte som for IG, MB og FA
Se dokumentasjon av ny datamodell her: Supplering av søknad - datamodell
Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet
Oppfølging : Vi fikk ingen innspill på arbeidsgruppemøtet. Saken er åpen for skriftlige tilbakemeldinger.
Konklusjon Vi har ikke fått noen tilbakemeldinger. Saken lukkes.
✍️ Gjennomføringsplan
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Vi har publisert et nytt forslag til bruk av ansvarsomraadeStatus. Saken er åpen for innspill. Resten av sakene er ferdig avklart. |
| Se dokumentasjonsside med nytt forslag til statuser: Status for ansvarsområdet | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Oppfølging: Vi går videre med forslaget, men økosystemet gjør undersøkelser blant sine brukere om hvordan det vil fungere. DiBK går også gjennom bruken av gjennomstreking i PDF-skissen. | |||||||||||||||||
Bruk av ansvarsomraadeStatus (v2) |
| Se eget blogginnlegg med nytt forslag til statuser: TRUKKET - Ny gjennomføringsplan: Forslag til statuser | Frist for innspill er Oppfølging: Etter arbeidsgruppemøte har vi publisert et nytt forslag. Se raden over. | ||||||||||||||||
Datamodell for gjennomføringsplan |
| Vi foreslår å beholde datamodellen i Altinn 3 identisk som nåværende versjon (v6). Les mer her: Datamodell - Gjennomføringsplan | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Konklusjon: Ingen innsigelser. Vi går videre med datamodellen. | ||||||||||||||||
Avvikling av gjennomføringsplan som hovedskjema |
| Vi foreslår at gjennomføringsplan kun blir tilgjengelig som vedlegg/underskjema, og ikke som en egen innsending til kommunen. Ved opppdatering av gjennomføringsplanen utenom en søknad, kan gjennomføringsplanen og vedlegg sendes med supplering av søknad. | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet 21 aug. DatamodellOppfølging : Vi går videre med forslaget, men økosystemet gjør undersøkelser blant sine brukere om hvordan det vil fungere. DiBK går også gjennom bruken av gjennomstreking i PDF-skissen. | ||||||||||||||||
Bruk av ansvarsomraadeStatus (v2) |
| Se eget blogginnlegg med nytt forslag til statuser: TRUKKET - Ny gjennomføringsplan: Forslag til statuser | Frist for innspill er Oppfølging: Etter arbeidsgruppemøte har vi publisert et nytt forslag. Se raden over. | ||||||||||||||||
: Et av søknadssystemene har vært bekymret for at avvikling gir dårligere brukeropplevelse. Erfaringer fra andre søknadssystemer viser likevel at det også har fordeler for søkere og saksbehandlere, da supplering av søknad gir mulighet for å legge inn mer informasjon om innholdet i gjennomføringsplanen. Et av søknadssystemene brukte gjennomføringsplan som hovedskjema for å forhåndsvise gjennomføringsplanen underveis. Vi vil tilrettelegge for denne funksjonaliteten i ny versjon. Konklusjon: Vi går videre med forslaget. | |||||||||||||||||||
PDF-visning for gjennomføringsplan |
| Vi foreslår å beholde datamodellen i Altinn 3 identisk som nåværende versjon (v6). Les mer her: Datamodell noen endringer for visning av gjennomføringsplanen, og ber om innspill: PDF-visning - Gjennomføringsplan | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Konklusjon: Ingen innsigelser. Vi går videre med datamodellen. | Avvikling av gjennomføringsplan som hovedskjema |
| Vi foreslår at gjennomføringsplan kun blir tilgjengelig som vedlegg/underskjema, og ikke som en egen innsending til kommunen. Ved opppdatering av gjennomføringsplanen utenom en søknad, kan gjennomføringsplanen og vedlegg sendes med supplering av søknad. | Oppfølging : Vi fikk noen innspill som er tatt inn i nytt forslag. Se raden over om Bruk av ansvarsomraadeStatus (v2). | ||||||||||||
Bruk av ansvarsomraadeStatus |
| Vi foreslår tå ta i bruk feltet Vi foreslår følgende kodeverdier for ansvarsomraadeStatus:
Formålet er å gi en bedre visning og validering av ansvarsområder som er utgått/erstattet av et annet foretak, for eksempel dersom et foretak går konkurs før alle arbeidene er avsluttet.  | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Oppfølging : Et av søknadssystemene har vært bekymret for at avvikling gir dårligere brukeropplevelse. Erfaringer fra andre søknadssystemer viser likevel at det også har fordeler for søkere og saksbehandlere, da supplering av søknad gir mulighet for å legge inn mer informasjon om innholdet i gjennomføringsplanen. Et av søknadssystemene brukte gjennomføringsplan som hovedskjema for å forhåndsvise gjennomføringsplanen underveis. Vi vil tilrettelegge for denne funksjonaliteten i ny versjon. Konklusjon: Vi går videre med forslaget. | ||||||||||||||||
PDF-visning for gjennomføringsplan |
| Vi foreslår noen endringer for visning av gjennomføringsplanen, og ber om innspill: PDF-visning - Gjennomføringsplan | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Oppfølging : Vi fikk noen innspill som er tatt inn i nytt forslag. Se raden over om Bruk av ansvarsomraadeStatus (v2). | ||||||||||||||||
Bruk av ansvarsomraadeStatus |
| Vi foreslår tå ta i bruk feltet ansvarsomraadeStatussom en erstatning for ansvarsomraadeAvsluttet.Vi foreslår følgende kodeverdier for ansvarsomraadeStatus:
Formålet er å gi en bedre visning og validering av ansvarsområder som er utgått/erstattet av et annet foretak, for eksempel dersom et foretak går konkurs før alle arbeidene er avsluttet. Etter mange innspill på arbeidsgruppemøtet har vi publisert et nytt utkast. Se raden over om Bruk av ansvarsomraadeStatus (v2). |
✅ Fjerning av konseptet underskjema
| Tips |
|---|
Ny endring i datamodellen. Vi fikk ingen innsigelser på arbeidsgruppemøtet, og går derfor videre med endringene. |
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Underskjema fjernes fra datamodellene |
| I Altinn 3 er konseptet “underskjema” fjernet, og det skilles ikke mellom vedlegg og underskjema. Vi ønsker derfor å fjerne dette fra datamodellene. Objektet Endringen vil påvirke følgende søknader:
I tillegg til at datamodellene blir endret, vil endringen påvirke valideringsregler for utfallsbesvarelse og kodelistene på GeoNorge. | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet |
Konklusjon: Vi fikk ingen innsigelser på arbeidsgruppemøtet og går derfor videre med endringene. |
✅ Søknad om igangsettingstillatelse (oppdatert datamodell)
...