...
Siste innspillsrunde vises øverst, og tema merket med✍️ er fortsatt åpne for innspill:
| Innholdsfortegnelse | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
✍️ Søknad om dispensasjon
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Frist for tilbakemelding på saker med status
Dokumentasjonen er oppdatert for datamodell, veiledningsmateriell og sammenheng med planregisteret. Frist for innspill er 13.12.2024 |
Tema | Status | Beskrivelse | Oppfølging |
|---|
Endring i datamodell for |
Varsling |
| Vi foreslår |
følgende endring i datamodellen for |
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.
Endring i objektet for “ettersending”varsling (dokumentasjon av nabovarsling):
 Endringen vil også påvirke hovedsøknadene når de migreres til Altinn3. | Oppdatert forslag er lagt ut etter tilbakemeldinger 27. november. | ||||||||
Flyt og splitting av saker i kommunen |
| Dokumentasjon kommer. | Forslaget vil gås gjennom på arbeidsgruppemøtet 27. november. | ||||||
Harmonisering med NPAD |
|
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.
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 |
Oppfølging : Saken er åpen for skriftlige tilbakemeldinger.
Generelle innspill: hvordan funker Supplering av søknad i dag?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 |
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 avforeslå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 |
| 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. | ||||||
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: Les mer: https://dibk.atlassian.net/wiki/spaces/FB/pages/2866184368/Metadata+i+SvarUt#Metadata-om-vedlegg | Forslaget er åpent for innspill 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. |
✅ 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 Oppfølging : Vi fikk følgende innspill på møtet:
|
Gjennomføringsplan
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Frist for tilbakemelding på saker med status
|
Tema
Status
Beskrivelse
Oppfølging
Bruk av ansvarsomraadeStatus (v2)
| Status | ||||
|---|---|---|---|---|
|
Se eget blogginnlegg med nytt forslag til statuser: Ny gjennomføringsplan: Forslag til statuser
Frist for innspill er
Datamodell for gjennomføringsplan
| Status | ||||
|---|---|---|---|---|
|
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.
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å arbeidsgruppemøtet Oppfølging : |
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
| Status | ||||
|---|---|---|---|---|
|
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 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 |
Bruk av ansvarsomraadeStatus
| Status | ||||
|---|---|---|---|---|
|
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 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
| 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 |
Oppfølging : Etter mange innspill på arbeidsgruppemøtet har vi publisert et nytt utkast. Se raden over om Bruk av ansvarsomraadeStatus (v2).
Konklusjon: Vi fikk ingen innsigelser på arbeidsgruppemøtet og går derfor videre med endringene. |
✅ Søknad om igangsettingstillatelse (oppdatert datamodell)
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Endring i foreslått datamodell |
| Vi foreslår å legge inn feltet ansvarForByggesaken i søknad om igangsettingstillatelse, på samme måte som for midlertidig brukstillatelse og ferdigattest. Les mer her: Søknad om igangsettingstillatelse v3: Endring i utkast til datamodell | Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Konklusjon: Endringen ble presentert på arbeidsgruppemøtet uten innsigelser, og vi går derfor videre med endringen. |
✅ Ferdigattest (datamodell)
...
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
FDV-dokumentasjon, hvor kravet ikke er relevant |
| Som hovedregel skal dokumentasjon om forvaltning, drift og vedlikehold være overlevert eier, men i tilfeller der FDV-dokumentasjon åpenbart er overflødig, bortfaller kravet. Vi ønsker tilbakemelding på hvordan dette behovet bør løses.  Mulige alternativer:
Vi ber om innspill til hvilket alternativ dere foretrekker. | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Etter innspill på arbeidsgruppemøtet, foreslår vi å beholde dagens datamodell. Vi endrer ordlyden dersom svaret er nei slik at det kommer tydelig frem at FDV-dokumentasjon ikke må overleveres der det åpenbart er overflødig. | ||||||
Endringer for energiforsyning |
| For å bedre strukturen foreslår vi følgende endringer i objektet for energiforsyning:
Begrunnelse: Endringene vil gi en ryddigere struktur, og hvor ulike felter ikke har samme navn. | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget. | ||||||
Felter for sluttrapport for bygningsavfall og miljøkartlegging |
| En del tiltak har krav til sluttrapport for bygningsavfall og/eller sluttrapport fra miljøkartlegging. Vi lurer på om vi bør ha felter i søknaden for å fange opp disse kravene, og ønsker innspill. Begge sluttrapportene vil kunne være oppfølgingspunkt fra vedtaket hos kommunen. utarbeideAvfallsplan er også et eget felt i hovedsøknaden. Vi har noen alternativer:
 Vi ber om innspill til hvilket alternativ dere foretrekker. | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Vi går videre med alternativ 1. Det kom spørsmål om ikke sluttrapport for miljøkartlegging inngår i sluttrapport for bygningsavfall. Vi skal gå gjennom disse kravene faglig og oppdatere sjekklistene slik at riktige krav til vedlegg blir fanget opp. Oppdatering 2 : Vi har avklart at det kun er Sluttrapport for bygningsavfall som skal vedlegges. Det gjelder både der det er krav om avfallsplan, og der det er krav om miljøkartlegging. | ||||||
Gruppering av felter |
| Vi foreslår å gruppere fire av de eksisterende feltene i et nytt objekt kalt kravFerdigattest:  Begrunnelse: Vi ønsker å gi bedre oversikt over datamodellen og felter som henger logisk sammen. | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget. | ||||||
Generell oppdatering av datamodellen |
| Vi foreslår å oppdatere datamodellen for ferdigattest til ny standard. Det gjelder følgende felter:
Se datamodellen i sin helhet her: Datamodell - Søknad om ferdigattest v3 | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget. |
✅ Midlertidig brukstillatelse (datamodell)
...
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Nytt felt for ansvar i byggesaken |
| Vi foreslår å legge inn et nytt felt for å angi ansvar i byggesaken. Feltet vil ha en kodeliste med følgende verdier:
Begrunnelse: Vi ønsker å bruke koden til å tilby bedre validering av krav til gjennomføringsplan, tiltakstyper og søker. Vi ønsker også å bruke feltet i andre søknader, for eksempel søknad om ferdigattest. | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget. | ||||||
Gruppering av felter |
| Vi foreslår gruppere feltene for midlertidig brukstillatelse, som tidligere lå på rotnivå i datamodellen:
Begrunnelse: Vi ønsker å gi bedre oversikt over datamodellen og felter som henger logisk sammen. | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget. | ||||||
Generell oppdatering av datamodellen |
| Vi foreslår å oppdatere datamodellen for midlertidig brukstillatelse til ny standard. Det gjelder følgende felter:
Se datamodellen i sin helhet her: Søknad om midlertidig brukstillatelse v3 - Datamodell | Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023. Oppdatering : Det kom spørsmål om tiltakstype er nødvendig. Vi ønsker å beholde det for å gi riktigere validering, samt tilrettelegge for automatisering. Vi viser også til veiledning for bruk og endring av tiltakstyper. |
✅ Generelle datamodellendringer
...
Tema | Status | Beskrivelse | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
XSD av datamodell for søknad om igangsettingstillatelse |
| Se fullstendig datamodell i xsd- og pdf-format: Søknad om igangsettingstillatelse v3 - Datamodell | Vi går videre med utvikling av tjenesten og ber om innspill dersom det er noe i datamodellen som ikke fungerer for dere. Oppdatering : Vi har ikke fått noen innspill, og går derfor videre med forslaget. | ||||||
Endring i oppbyggelse av kodelisteobjekter |
| Vi foreslår at alle lister med kodelisteobjekter får et nytt nivå kalt
Begrunnelse: Endringen vil gi riktigere struktur i datamodellene på Fellestjenester BYGG. Endringen vil også muliggjøre gjenbruk av koden i økosystemet. Konsekvenser: Det vil eksistere ulike versjoner av tiltakstype-objektet for gamle og nye skjemaer frem til migreringen til Altinn 3 er ferdig. Den nye måten å strukturere kodelister på vil føre til datamodellendringer i de neste tjenestene som skal migreres. Eksempler er lister med varmefordeling og energiforsyning i søknad om ferdigattest, og tiltaksformaal i hovedsøknaden. Innspill: Tieto og Sikri minner om at alle endringer vil ha kostnader for systemene, og ber om at endringene vi foreslår kommer tydeligere frem. | Vi ber om innspill om hvilke konsekvenser endringene har for økosystemet, og tilbyr en-til-en-møter for å få innsikt i hvordan vi kan ivareta deres behov i overgangen. Oppdatering Vi har ikke fått noen innspill, og går derfor videre med forslaget. | ||||||
Bruk av vilkår og oppfølgingspunkt |
| Vi foreslår følgende løsning for vilkår og oppfølgingspunkt:
Begrunnelse: Formålet med diskusjonen var å bli enige om en omforent måte å bruke vilkår og oppfølgingspunkt på, på tvers av søknadssystemene. Innspill: Tieto påpeker at det er opp til kommunen om vilkåret er besvart tidligere, og foreslår at vi kun bruker to statuser: Besvares nå og Besvares senere. Sikri lurer på om man kan referere til tidligere svar, f.eks. “Dokumentasjon sendt inn tidligere”. | Vi tar en ny runde på om det er nødvendig at alle vilkår for IG er med, eventuelt om navngivingen skal endres. Send oss gjerne deres innspill. Oppdatering Nytt forslag til formulering er “Svar innsendt tidligere”. Oppdatering Forslaget til ny formulering ble godkjent på arbeidsgruppemøtet. | ||||||
Fjerne metadatafelter for å hindre innsending |
| Metadata-objektet har i dag to felter som hindrer brukere fra å sende nabovarsler og søknader før de har betalt for tjenesten. Vi foreslår å fjerne følgende felter i de nye tjenestene:
Begrunnelse: I Altinn3 vil skjemaet ikke være synlig i Altinn-portalen. Disse feltene blir derfor overflødige i de nye tjenestene. | Forslaget ble presentert for arbeidsgruppa uten protester, og blir innført i nye datamodeller. | ||||||
Navneendring: igNummer |
| Vi foreslår følgende navneendring fra tidligere skisse av datamodellen for IG v3, som blir brukt i soeknadGjelder og delsoeknader:
Begrunnelse: Vi ønsker å tilrettelegge datamodellen for gjenbruk i søknad om midlertidig brukstillatelse. Feltet finnes ikke i dag, og endringen antas ikke å ha konsekvenser for sluttbrukersystemene. | Forslaget ble presentert for arbeidsgruppa uten protester, og blir innført i nye datamodeller. | ||||||
Endring i struktur: foelgebrev |
| Vi foreslår følgende strukturendring fra tidligere skisse av datamodellen for IG v3:
 Begrunnelse: Vi ønsker å gjøre de nye datamodellene likest mulig hovedsøknadene, hvor foelgebrev og tiltakstype er samlet under beskrivelseAvTiltak. Endringen antas ikke å ha konsekvenser for sluttbrukersystemene, da foelgebrev ikke finnes i datamodellene for IG, MB og FA i dag. | Forslaget ble presentert for arbeidsgruppa uten protester, og blir innført i nye datamodeller. | ||||||
Nytt felt for utfallBesvarelse: beskrivelse |
| Vi foreslår å legge inn følgende felt i tidligere skisse av datamodellen for IG v3:
Begrunnelse: Tilbakemelding fra en byggesaksbehandler er at de ønsker å se beskrivelsen av vilkåret som ble gitt fra kommunen. Feltet finnes i dagens datamodell for supplering av søknad og API for vedtak, og anses derfor naturlig å ta inn. utfallBesvarelse er et nytt dataobjekt i søknadene, og endringen anses derfor ikke å ha konsekvenser for søknadssystemene. | Forslaget ble presentert for arbeidsgruppa uten protester, og blir innført i nye datamodeller. | ||||||
Navneendring: utfallType |
| Vi foreslår følgende navneendring fra tidligere skisse av datamodellen for IG v3. Feltet blir brukt i utfallBesvarelse:
Begrunnelse: Vi ønsker en datamodell som er riktigere i bruk av upper-/lowercase. | Endringen ville ført til ulikhet mellom API-et for vedtak og utfallsbesvarelse. Vi trekker derfor tilbake forslaget, og beholder følgende navngiving: | ||||||
Bruk av tiltakstype |
| Tidligere har vi diskutert muligheten for å velge hvilken tiltakstype denne IG-søknaden gjelder. Vi foreslår følgende endring:
Begrunnelse: Det har kommet innspill om at det vil være krevende for søker og saksbehandler å holde orden på om alle tiltakstypene blir dekket ved siste IG. For å få en lik bruk på tvers av systemene, foreslår vi at listen med tiltakstyper følger fra hovedsøknaden til oppfølgende søknader. Unntaket er om det har blitt gjort endringer i tiltakstypen underveis. Se veiledning her: Endring av tiltakstype - flyt | Forslaget ble presentert for arbeidsgruppa uten protester, og vi går derfor videre med forslaget. Oppdatering : Det kom noen spørsmål om tiltakstype er nødvendig. Vi ønsker å beholde det for å gi riktigere validering, samt tilrettelegge for automatisering. Vi viser også til veiledning for bruk og endring av tiltakstyper. |
✅ Arbeidsflyt og underskjema
...
Tema | Status | Beskrivelse og oppfølging | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Avvikling av vedleggsopplysninger |
| Vi foreslår å avvikle underskjemaet Vedleggsopplysninger. Begrunnelse: I Altinn 3 kan søker legge inn Vedleggsopplysninger som key/value. Dette kan FtB sende videre til SvarUt som metadata. Les mer om metadata dataene vi tilbyr her: Metadata i SvarUt Konsevenser: Løsningen medfører endret registrering av metadata for vedlegg for både søknads- og saksbehandlingssystemene, men vil føre til økt kvalitet i dataene. Vi ba om innspill på om leverandørene kan håndtere endringene, og om det er behov for PDF av vedleggsopplysninger. Innspill: Tieto ga uttrykk for at de gjerne vil bli kvitt vedleggsopplysninger. Metadata må inneholde informasjon om forsendelsen er ny eller gammel versjon, og valideres så vi unngår feil dokumenttype. Sikri lurer på om vi kan ta det i to steg, dvs. fase ut skjemaet når alle er over på ny løsning. Sikri sa at det ikke er behov for PDF-visning av vedleggsopplysninger. | Vi går videre med nytt oppsett av metadata for vedlegg. Dersom noen av leverandørene ikke klarer å tilpasse seg endringene i tide, vil vi se på løsninger for mapping av data i en overgangsperiode. Oppdatering : Vi har fått innspill om at søknadssystemet trenger en måte å vise hva som har blitt sendt kommunen. Vi vil tilrettelegge for dette. | ||||||
Gjennomføringsplan i Altinn 3 |
| Vi ba om innspill på videre bruk av underskjemaet Gjennomføringsplan. Begrunnelse: Gjennomføringsplan er et underskjema til de fleste tjenester på Altinn 2. Dersom vi lager en ny versjon i Altinn 3, vil det være ulike versjoner av skjemaet over lang tid (ut 2025). Søker vil for eksempel få en gammel versjon ved søknad om rammetillatelse, og ny versjon i søknad om igangsettingstillatelse. Vi antar at det vil være krevende å håndtere for både søknads- og eByggesakssystemene. Vi ber om innspill på om det finnes et stort verdipotensiale i å oppdatere gjennomføringsplanen i denne runden, eller om dagens versjon fungerer godt nok. Innspill: En samlet forsamling ga inntrykk av at det ikke er nødvendig å oppdatere datamodellen for gjennomføringsplan i denne omgangen. Tieto ville avklare det med Oslo kommune før endelig uttalelse. | Vi går videre med planen om å “kopiere” versjon 6 fra Altinn 2 til Altinn 3. | ||||||
Gjennomgang av arbeidsflyt |
| Vi presenterte følgende arbeidsflyt i Altinn 3:  Innspill: Flere søknadssystemer uttrykte at det ikke er nødvendig med process completed på innsendingen. | Etter innspill fjerner vi det siste steget (process completed). |
✅ Søknad om igangsettingstillatelse (datamodell, PDF og validering)
...
Tema | Status | Beskrivelse og oppfølging | Oppfølging | ||||||
|---|---|---|---|---|---|---|---|---|---|
Valideringsregler |
| Se spesifikasjon: Søknad om igangsettingstillatelse v3 - Valideringsregler Innspill: Vi fikk ingen innspill i denne runden. | Vi går videre med valideringsreglene slik de er spesifisert. | ||||||
PDF-skisser |
| Se spesifikasjon: Søknad om igangsettingstillatelse v3 - PDF-visning Innspill: Vi sendte skissene til arbeidsgruppa og til utvalgte kommuner. Vi fikk følgende innspill:
| Vi har gjort noen tiltak:
| ||||||
Datamodell |
| Se spesifikasjon: Sammenligning av datamodeller - IG v2 og 3 Innspill: Vi diskuterte datamodellen på arbeidsgruppemøtet 22.11.2023 med følgende konklusjoner:
|