...
| Innholdsfortegnelse | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
✍️
...
Søknad om dispensasjon
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
4 sep Forslaget er åpen Beskrivelse og datamodell er lagt ut for innspill. 14 okt Frist for å komme med innspill er innen utgangen av måneden, 31.01.2024 Dokumentasjonen er oppdatert for datamodell, veiledningsmateriell og sammenheng med planregisteret. |
Tema | Status | Beskrivelse | Oppfølging |
|---|
Flyt og splitting av saker i kommunen |
|
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
versjonsdatoogversjonsnummer. For å gjøre overgangen til de nye versjonene enklere, ønsker vi å beholde dagens navngiving av datafelt.
Brukergrensesnitt hos søknadssystemene
Selv om datafeltet heter
versjonsdatoogversjonsnummer, står sluttbrukersystemene fritt til å velge andre begreper, for eksempeltegningsdatoogtegningsnummer.
PDF fra DiBK
I PDF-en kommer blir begrepene
tegnings-/versjonsdatoogtegnings-/versjonsnummerbrukt. Bakgrunnen er at flere vedleggstyper enn tegninger kan ha dato og nummer. Vi ønsker å unngå unødvendig kompleksitet ved å generalisere bruken av feltene.
Forslaget er åpent for innspill.
Obligatoriske metadata
| Status | ||||
|---|---|---|---|---|
|
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
Vi gjør oppmerksom på at søknadssystemene selv må sørge for at data sendes inn på riktig format.
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. Beslutning om forhåndsvisning av kvitteringen er lagt ut. |
Tema
Status
Beskrivelse
Oppfølging
Dokumentasjon kommer. | Forslaget vil gås gjennom på arbeidsgruppemøtet 27. november. | ||||||||
Harmonisering med NPAD |
| Se dokumentasjonsside: https://dibk.atlassian.net/wiki/spaces/FB/pages/3207430164/Mapping+mot+planregister+-+dispensasjonss+knad Dokumentasjonen er oppdatert i tråd med nytt forslag til datamodell. | Forslaget er åpent for innspill, og vil gås gjennom på arbeidsgruppemøtet 27. november. | ||||||
Inngangsbeskrivelser og veiledningsmateriell |
| Hver dispensasjon blir representert av en inngangsbeskrivelse. Knyttet til hver inngangsbeskrivelse vil vi tilby en rekke veiledningsmateriell. Vi ber om innspill til inndelingen i inngangsbeskrivelser: Veiledningsmateriell - dispensasjonssøknad | |||||||
Ny tiltakstype for ikke søknadspliktig tiltak |
| Vi foreslår å legge inn følgende tiltakstype i kodelista for tiltakstyper uten ansvarsrett: Mindre tiltak som ikke er søknadspliktig. Tiltakstypen skal bli tilgjengelig for følgende tjenester:
Les mer på blogginnlegget: Varsel: Ny tiltakstype for ikke søknadspliktige tiltak | Vi ber om tilbakemelding innen 9. desember dersom dere har behov for lenger frist. | ||||||
Datamodeller for dispensasjon |
| Se dokumentasjon: Vi ber om innspill til begge datamodellene, og spesielt til infobokser merket med “❓“. | Nytt forslag til datamodell er lagt ut. Forslaget vil gås gjennom på arbeidsgruppemøtet 27. november. |
✅ Gjennomføringsplan
| Tips |
|---|
Alle sakene anses som lukket. |
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Bruk av ansvarsomraadeStatus (v4) |
| Byggesøknaden presenterte sine funn på arbeidsgruppemøtet . Vi har publisert rapporten og en ny versjon av statusene her: Status for ansvarsområdet Følgende er endret siden forrige forslag:
| I og med at vi har gått mange runder på disse statusene nå, åpner vi ikke for større innspill, men vi tar gjerne imot tips til tekstlige justeringer. | ||||||
Valideringsregler |
| Valideringsregler er lagt ut her: Valideringsregler - Gjennomføringsplan Versjon 7 av gjennomføringsplanen gir en mer omfattende validering enn forrige versjon:
| Forslaget er åpent for innspill i testfasen. Vi har ikke fått noen innspill, og anser saken som lukket. | ||||||
Bruk av ansvarsomraadeStatus (v3) |
| Se dokumentasjonsside med nytt forslag til statuser: Historikk: 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. Konklusjon : Vi har publisert et nytt forslag. Se to rader over (v4). | ||||||
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 |
|
DiBK har kommet frem til at vi ikke vil prioritere funksjonalitet for preview av kvittering for sendt søknad.
Bakgrunn for beslutningen
Det gir liten mening å forhåndsvise en kvittering. En kvittering skal per definisjon vise hva som faktisk er sendt.
Vi mener sluttbrukersystemene kan gi en bedre oversikt over vedlegg og metadata enn det vi har mulighet til i en PDF-variant.
Søknadssystemene har ansvaret for dialogen med sluttbruker, mens DiBK skal sørge for å dokumentere hva som har blitt sendt.
Kvittering etter sending er i tråd med oppsettet for nabovarsel og planvarsel-tjenestene.
Konsekvenser for søknadssystemene
Må lage funksjonalitet for at bruker kan få oversikt over vedlegg og metadata før søknaden blir sendt til kommunen
Kan tilrettelegge for nedlasting av kvitteringen etter innsending, på samme måte som for nabovarsel
Konsekvenser for eByggesakssystemene: Ingen
Beslutningen er lagt ut og sendt til søknadsleverandørene.
Ny PDF-visning
| Status | ||||
|---|---|---|---|---|
|
Vi har lagt ut en ny skisse av PDF-en med følgende endringer:
I stedet for versjonsdato brukes tegnings- og versjonsdato
I stedet for versjonsnummer brukes tegnings- og versjonsnummer
I stedet for Søknaden ble mottatt av kommunen skriver vi Søknaden ble sendt til kommunen
Vi har lagt inn reelle eksempler i skissen
Les mer her: Kvittering for sendt søknad
Skissen er lagt ut og åpen for innspill.
Arbeidsflyt for søknadssystemet
| Status | ||||
|---|---|---|---|---|
|
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.
Oppdatering : Se forslag til obligatoriske metadata herVi 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 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 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 : Etter mange innspill på arbeidsgruppemøtet har vi publisert et nytt utkast. Se raden over om Bruk av ansvarsomraadeStatus (v2). |
✅ Metadata for vedlegg
| Tips |
|---|
Forslaget er åpen for innspill. Frist for å komme med innspill er innen utgangen av måneden, 31.10.2024. Vi fikk ingen innspill innen fristen, og går videre med planene. |
Tema | Status | Beskrivelse | Oppfølging | |||||
|---|---|---|---|---|---|---|---|---|
Dokumenttype for gjennomføringsplan |
| Vi ønsker å beholde Konsekvenser Dokumenttypen Begrunnelse For å unngå unødvendig kompleksitet, ønsker vi å ha lik bruk av dokumenttyper for gjennomføringsplan uavhengig av om de sendes med en søknad på Altinn2 eller Altinn3. Arkivlett 1 er en utgått standard som det ikke er prioritert å oppgradere til. I metadataene har vi en referanse til dokumenttypen fra Arkivlett 2. Denne blir i henhold til standard: |
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 |
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?
...
| 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.
Oppfølging: Supplering av søknad blir tema for arbeidsgruppemøtet
...
Endring i objektet for “ettersending”
...
| Status | ||||
|---|---|---|---|---|
|
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
...
| Status | ||||
|---|---|---|---|---|
|
...
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. |
Tema
Status
Beskrivelse
Oppfølging
Valideringsregler
| Status | ||||
|---|---|---|---|---|
|
Valideringsregler er lagt ut her: Valideringsregler - Gjennomføringsplan
Versjon 7 av gjennomføringsplanen gir en mer omfattende validering enn forrige versjon:
eiendomByggestedogkommunensSaksnummerer oppdatert til standard valideringansvarligSoekerTiltaksklasseblir nå validertansvarligSoekerer oppdatert til delvis standard valideringgjennomfoeringsplanhar fått mer finmasket validering:ansvarsomraadeStatuser påkrevd (ny funksjonalitet)foretakhar fått strengere validering der det er angitt for ansvarsområdet (organisasjonsnummer, partstype og navn)funksjonfor ansvarsområdet er påkrevdtiltaksklassehar blitt oppdatert med standard kodelistevalidering
Forslaget er åpent for innspill i testfasen.
Bruk av ansvarsomraadeStatus (v3)
| Status | ||||
|---|---|---|---|---|
|
med frist 31.01.2024. | |||||||||
Bruk av tegnings- eller versjonsdato og -nummer |
| 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
Brukergrensesnitt hos sluttbrukersystemene
PDF fra DiBK
| Forslaget er åpent for innspill. Frist for å komme med innspill er 31.10.2024. | ||||||
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 Vi gjør oppmerksom på at søknadssystemene selv må sørge for at data sendes inn på riktig format. | Forslaget er åpent for innspill. Frist for å komme med innspill er 31.10.2024. |
✅ 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. Ny skisse for PDF er lagt ut og er åpen for innspill. Frist for å komme med innspill til PDF-løsning er 31.10.2024. Beslutning om forhåndsvisning av kvitteringen er lagt ut. Vi fikk ingen innspill innen fristen, og alle sakene er lukket.. |
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Ny PDF-visning |
| Vi har lagt ut en ny skisse av PDF-en med følgende endringer:
Les mer her: Kvittering for sendt søknad | Skissen er lagt ut og åpen for innspill. Frist for å komme med innspill er 31.10.2024. | ||||||
Beslutning om forhåndsvisning av kvitteringen |
| DiBK har kommet frem til at vi ikke vil prioritere funksjonalitet for preview av kvittering for sendt søknad. Bakgrunn for beslutningen
Konsekvenser for søknadssystemene
Konsekvenser for eByggesakssystemene: Ingen | Beslutningen er lagt ut og sendt til søknadsleverandørene. | ||||||
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. Oppdatering : Se forslag til obligatoriske metadata her: https://dibk.atlassian.net/wiki/spaces/FB/pages/edit-v2/2880503845#Obligatoriske-metadata | ||||||
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 |
Bruk av ansvarsomraadeStatus (v2)
| Status | ||||
|---|---|---|---|---|
|
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.
. |
✅ Supplering av søknad
| Tips |
|---|
Datamodellen er ferdig avklart. Vi vil ha et eget arbeidsgruppemøte om supplering av søknad i løpet av høsten. Dokumentasjonen er oppdatert med anbefalinger etter arbeidsgruppemøtet, og supplering av søknad anses som ferdig avklart. Se Supplering av søknad v2 |
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 |
Konklusjon: Ingen innsigelser. Vi går videre med datamodellen.
Avvikling av gjennomføringsplan som hovedskjema
| Status | ||||
|---|---|---|---|---|
|
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
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.
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. Oppfølging: Supplering av søknad blir tema for arbeidsgruppemøtet Konklusjon: Vi har oppdatert beskrivelsen med anbefalinger for god praksis etter arbeidsgruppemøtet. Supplering av søknad v2 | ||||||||
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å |
Oppfølging : Vi fikk noen innspill som er tatt inn i nytt forslag. Se raden over om Bruk av ansvarsomraadeStatus (v2).
Bruk av ansvarsomraadeStatusarbeidsgruppemø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 |
|
|
ansvarsomraadeStatussom en erstatning for ansvarsomraadeAvsluttet.Vi foreslår følgende kodeverdier for ansvarsomraadeStatus:
Avsluttet
Ikke avsluttet
Erstattet
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.
| 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:
 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. |
✅ Fjerning av konseptet underskjema
...