datamodell for dispensasjon

åpen

Se dokumentasjonssider:

• Søknad om dispensasjon

• Datamodell - dispensasjonssøknad

Forslaget er åpent for innspill, og vil gås gjennom på arbeidsgruppemøtet 13. november.

Bruk av ansvarsomraadeStatus (v4)

lukket

Byggesøknaden presenterte sine funn på arbeidsgruppemøtet Nov 6, 2024.

Vi har publisert rapporten og en ny versjon av statusene her: Status for ansvarsområdet

Følgende er endret siden forrige forslag:

• Utgått erstattes med Avlyst og Foretak utgått

• Erstattet endrer navn til Ansvar overført

• Delvis erstattet endrer navn til Ansvar splittet

• Ikke avsluttet og Avsluttet beholdes

• Gjennomstreking er tatt ut av PDF-en av hensyn til universell utforming. I stedet markerer vi ansvarsområdet med “[STATUS]: “ for å tydeliggjøre endringen

Nov 15, 2024 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

lukket

Valideringsregler er lagt ut her: Valideringsregler - Gjennomføringsplan

Versjon 7 av gjennomføringsplanen gir en mer omfattende validering enn forrige versjon:

• eiendomByggested og kommunensSaksnummer er oppdatert til standard validering

• ansvarligSoekerTiltaksklasse blir nå validert

• ansvarligSoeker er oppdatert til delvis standard validering

• gjennomfoeringsplan har fått mer finmasket validering:

  • ansvarsomraadeStatus er påkrevd (ny funksjonalitet)

  • foretak har fått strengere validering der det er angitt for ansvarsområdet (organisasjonsnummer, partstype og navn)

  • funksjon for ansvarsområdet er påkrevd

  • tiltaksklasse har blitt oppdatert med standard kodelistevalidering

Forslaget er åpent for innspill i testfasen.

Nov 13, 2024 Vi har ikke fått noen innspill, og anser saken som lukket.

Bruk av ansvarsomraadeStatus (v3)

trukket

Se dokumentasjonsside med nytt forslag til statuser: Historikk: Status for ansvarsområdetarchived

Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet Aug 21, 2024

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 Nov 13, 2024 : Vi har publisert et nytt forslag. Se to rader over (v4).

Bruk av ansvarsomraadeStatus (v2)

trukket

Se eget blogginnlegg med nytt forslag til statuser: TRUKKET - Ny gjennomføringsplan: Forslag til statuser

Frist for innspill er May 31, 2024

Oppfølging: Etter arbeidsgruppemøte Jun 18, 2024 har vi publisert et nytt forslag. Se raden over.

Datamodell for gjennomføringsplan

lukket

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 May 15, 2024

Konklusjon: Ingen innsigelser. Vi går videre med datamodellen.

Avvikling av gjennomføringsplan som hovedskjema

lukket

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 May 15, 2024

Oppfølging May 23, 2024: 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

lukket

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 May 15, 2024

Oppfølging May 23, 2024 : Vi fikk noen innspill som er tatt inn i nytt forslag. Se raden over om Bruk av ansvarsomraadeStatus (v2).

Bruk av ansvarsomraadeStatus

trukket

Vi foreslår tå ta i bruk feltet ansvarsomraadeStatus som 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.

Open

Eksempelvisning på PDF, der Oppmålingsteknisk prosjektering er overtatt av et annet foretak

Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet May 15, 2024

Oppfølging May 23, 2024: Etter mange innspill på arbeidsgruppemøtet har vi publisert et nytt utkast. Se raden over om Bruk av ansvarsomraadeStatus (v2).

Dokumenttype for gjennomføringsplan

lukket

Vi ønsker å beholde Gjennomføringsplan som dokumentType for gjennomføringsplan.

Konsekvenser

Dokumenttypen Gjennomføringsplan følger ikke standarden for Arkivlett v1. I følge Arkivlett 1 skal dokumenttypen være ANKO.

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: ANSVKONT. Vi anbefaler eByggesakssystemene å bruke feltet DokumenttypeArkivlettV2 for riktig kategorisering.

Les mer: Metadata i SvarUt | Metadata om vedlegg

Oct 16, 2024 Forslaget er åpent for innspill med frist 31.01.2024.

Bruk av tegnings- eller versjonsdato og -nummer

lukket

På arbeidsgruppemøtet Aug 21, 2024 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 versjonsdato og versjonsnummer. For å gjøre overgangen til de nye versjonene enklere, ønsker vi å beholde dagens navngiving av datafelt.

Brukergrensesnitt hos sluttbrukersystemene

• Selv om datafeltet heter versjonsdato og versjonsnummer, står sluttbrukersystemene fritt til å velge andre begreper, for eksempel tegningsdato og tegningsnummer.

PDF fra DiBK

• I PDF-en kommer blir begrepene Tegnings-/versjonsdato og Tegnings-/versjonsnummer brukt. Bakgrunnen er at flere vedleggstyper enn tegninger kan ha dato og nummer. Vi ønsker å unngå unødvendig kompleksitet ved å generalisere bruken av feltene.

Sep 4, 2024 Forslaget er åpent for innspill.

Oct 14, 2024 Frist for å komme med innspill er 31.10.2024.

Obligatoriske metadata

lukket

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.

Sep 4, 2024 Forslaget er åpent for innspill.

Oct 14, 2024 Frist for å komme med innspill er 31.10.2024.

Ny PDF-visning

lukket

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

Open

Ny skisse

Les mer her: Kvittering for sendt søknad

Sep 4, 2024 Skissen er lagt ut og åpen for innspill.

Oct 14, 2024 Frist for å komme med innspill er 31.10.2024.

Beslutning om forhåndsvisning av kvitteringen

lukket

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

Sep 16, 2024 Beslutningen er lagt ut og sendt til søknadsleverandørene.

Arbeidsflyt for søknadssystemet

lukket

• 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 Aug 21, 2024

Konklusjon: Vi kommer tilbake med et nytt utkast basert på innspillene vi fikk.

Oppdatering Sep 16, 2024 : Se forslag til obligatoriske metadata her: Logg for endringer og avklaringer | Obligatoriske metadata

Mottak av metadata for eByggesakssystemet

lukket

• 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 Aug 21, 2024

Konklusjon: Ingen av mottakssystemene uttrykte ønske om å motta vedleggsopplysninger.xml. Vi går derfor videre med forslaget.

Generelle innspill: hvordan funker Supplering av søknad i dag?

lukket

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 May 15, 2024

Oppfølging May 23, 2024 : 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 Jun 18, 2024 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 Oct 16, 2024

Konklusjon: Vi har oppdatert beskrivelsen med anbefalinger for god praksis etter arbeidsgruppemøtet. Supplering av søknad v2

Endring i objektet for “ettersending”

lukket

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 May 15, 2024

Oppfølging May 23, 2024 : Saken er åpen for skriftlige tilbakemeldinger.

Konklusjon Jul 1, 2024 Vi har ikke fått noen tilbakemeldinger. Saken lukkes.

Endringer i datamodell for supplering av søknad

lukket

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: https://dibk.atlassian.net/wiki/spaces/FB/pages/2955640835

Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet May 15, 2024

Oppfølging May 23, 2024 : Vi fikk ingen innspill på arbeidsgruppemøtet. Saken er åpen for skriftlige tilbakemeldinger.

Konklusjon Jul 1, 2024 Vi har ikke fått noen tilbakemeldinger. Saken lukkes.

Underskjema fjernes fra datamodellene

lukket

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 Aug 21, 2024

Konklusjon: Vi fikk ingen innsigelser på arbeidsgruppemøtet og går derfor videre med endringene.

Endring i foreslått datamodell

lukket

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: https://dibk.atlassian.net/wiki/spaces/FB/blog/2024/04/30/2949709825

Forslaget er åpent for innspill og vil bli gjennomgått på arbeidsgruppemøtet May 15, 2024

Konklusjon: Endringen ble presentert på arbeidsgruppemøtet uten innsigelser, og vi går derfor videre med endringen.

FDV-dokumentasjon, hvor kravet ikke er relevant

lukket

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:

1. Beholde dagens datamodell, men endre ordlyden til: “Tilstrekkelig dokumentasjon (…) er levert til eieren av byggverket”. Svaret vil kunne være ja dersom ingen dokumentasjon er nødvendig. Søker kan eventuelt utdype i følgebrevet.

2. Legge inn et nytt felt for kommentar som søker kan fylle ut dersom dokumentasjon ikke er overlevert eier

3. Legge inn et nytt felt for å angi ikke relevant

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 Mar 20, 2024: 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

lukket

For å bedre strukturen foreslår vi følgende endringer i objektet for energiforsyning:

• Navneendring fra energiforsyning → varmesystem

• Oppdatering til ny struktur for lister av kodelister

• Endring i kodelistene slik at relevant kun angis i datamodellen. I dag finnes “ikke relevant” også som valg i kodelistene for energiforsyning og varmefordeling.

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 Mar 20, 2024 : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget.

Felter for sluttrapport for bygningsavfall og miljøkartlegging

lukket

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:

1. Ikke ta inn felter for sluttrapportene, og gå ut fra at kravene blir fanget opp i kommunens oppfølging

2. Ta inn felt for dato for sluttrapport for bygningsavfall, slik at det samsvarer med blanketten for ferdigattest

3. Ta inn felter for utarbeideAvfallsplan, eventuelt også utarbeideMiljoekartlegging som grunnlag for validering

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 Mar 20, 2024 : 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 Mar 20, 2024 : 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

lukket

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 Mar 20, 2024 : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget.

Generell oppdatering av datamodellen

lukket

Vi foreslår å oppdatere datamodellen for ferdigattest til ny standard. Det gjelder følgende felter:

• eiendomByggested beholdes som i dag

• kommunensSaksnummer beholdes som i dag

• tiltakshaver beholdes som i dag

• ansvarligSoeker beholdes som i dag

• metadata oppdateres til nytt standardfelt (som for IG)

• generelleVilkaar oppdateres til nytt standardfelt (med kun norskSvenskDansk)

• soeknadGjelder oppdateres til nytt standardfelt (kun utdrag fra IG)

• utfallBesvarelse oppdateres til nytt standardfelt (som for IG)

• signatur slettes

• ansvarForByggesaken oppdateres til nytt standardfelt (som for MB)

Se datamodellen i sin helhet her: https://dibk.atlassian.net/wiki/spaces/FB/pages/2891710525

Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023.

Oppdatering Mar 20, 2024 : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget.

Nytt felt for ansvar i byggesaken

lukket

Vi foreslår å legge inn et nytt felt for å angi ansvar i byggesaken. Feltet vil ha en kodeliste med følgende verdier:

• Søknad om tillatelse til tiltak med ansvarlige foretak

• Søknad om tillatelse uten ansvarsrett etter pbl § 20-4

• Søknad om tillatelse uten ansvarsrett etter pbl § 20-4, men med uavhengig kontroll

• Søknad om tillatelse til tiltak hvor selvbygger har alt ansvar

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 Mar 20, 2024 : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget.

Gruppering av felter

lukket

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 Mar 20, 2024 : Vi fikk ingen innspill på arbeidsgruppemøtet, og går derfor videre med forslaget.

Generell oppdatering av datamodellen

lukket

Vi foreslår å oppdatere datamodellen for midlertidig brukstillatelse til ny standard. Det gjelder følgende felter:

• eiendomByggested beholdes som i dag

• kommunensSaksnummer beholdes som i dag

• tiltakshaver beholdes som i dag

• ansvarligSoeker beholdes som i dag

• metadata oppdateres til nytt standardfelt (som for IG)

• generelleVilkaar oppdateres til nytt standardfelt (med kun norskSvenskDansk)

• soeknadGjelder oppdateres til nytt standardfelt (som for IG)

• delsoeknader oppdateres til nytt standardfelt (som for IG)

• utfallBesvarelse oppdateres til nytt standardfelt (som for IG)

• signatur slettes

Se datamodellen i sin helhet her: https://dibk.atlassian.net/wiki/spaces/FB/pages/2864414848

Forslaget er åpent for innspill og vil bli presentert på arbeidsgruppemøtet 19.02.2023.

Oppdatering Mar 20, 2024 : 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.

XSD av datamodell for søknad om igangsettingstillatelse

lukket

Se fullstendig datamodell i xsd- og pdf-format: https://dibk.atlassian.net/wiki/spaces/FB/pages/2838855701

Vi går videre med utvikling av tjenesten og ber om innspill dersom det er noe i datamodellen som ikke fungerer for dere.

Oppdatering Mar 20, 2024 : Vi har ikke fått noen innspill, og går derfor videre med forslaget.

Endring i oppbyggelse av kodelisteobjekter

lukket

Vi foreslår at alle lister med kodelisteobjekter får et nytt nivå kalt kode. Endringen vil påvirke alle datamodeller som har lister av kodelister. For søknad om igangsettingstillatelse gjelder det følgende felter:

• type (tiltakstype) i soeknadGjelder og delsoeknader

• underskjema i utfallBesvarelse

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 Mar 19, 2024 Vi har ikke fått noen innspill, og går derfor videre med forslaget.

Bruk av vilkår og oppfølgingspunkt

lukket

Vi foreslår følgende løsning for vilkår og oppfølgingspunkt:

• Kun vilkår som gjelder fasen (f.eks. IG) skal listes opp. Hvilken fase et vilkår gjelder kan hentes fra API-et for vedtak.

• Alle vilkårene for IG listes opp i hver IG-søknad med en status: Besvares nå, Besvart tidligere, Besvares senere

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 Mar 13, 2024 Nytt forslag til formulering er “Svar innsendt tidligere”.

Oppdatering Mar 19, 2024 Forslaget til ny formulering ble godkjent på arbeidsgruppemøtet.

Fjerne metadatafelter for å hindre innsending

lukket

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:

• klartForSigneringFraSluttbrukersystem

• sluttbrukersystemUrl

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

lukket

Vi foreslår følgende navneendring fra tidligere skisse av datamodellen for IG v3, som blir brukt i soeknadGjelder og delsoeknader:

• igNummer → delsoeknadsnummer

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

lukket

Vi foreslår følgende strukturendring fra tidligere skisse av datamodellen for IG v3:

• foelgebrev flyttes fra rotnivå til soeknadGjelder

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

lukket

Vi foreslår å legge inn følgende felt i tidligere skisse av datamodellen for IG v3:

• beskrivelse for utfallBesvarelse

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

trukket

Vi foreslår følgende navneendring fra tidligere skisse av datamodellen for IG v3. Feltet blir brukt i utfallBesvarelse:

• utfallType→ utfalltype

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: utfallType

Bruk av tiltakstype

lukket

Tidligere har vi diskutert muligheten for å velge hvilken tiltakstype denne IG-søknaden gjelder. Vi foreslår følgende endring:

• Den samme lista med tiltakstyper følger fra hovedsøknaden og gjennom hele søknadsløpet

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: https://dibk.atlassian.net/wiki/spaces/FB/pages/2855337988

Forslaget ble presentert for arbeidsgruppa uten protester, og vi går derfor videre med forslaget.

Oppdatering Mar 19, 2024 : 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.

Avvikling av vedleggsopplysninger

lukket

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: https://dibk.atlassian.net/wiki/spaces/FB/pages/2866184368

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 Mar 19, 2024 : 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

lukket

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

lukket

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).

Valideringsregler

lukket

Se spesifikasjon: https://dibk.atlassian.net/wiki/spaces/FB/pages/2838626404

Innspill: Vi fikk ingen innspill i denne runden.

Vi går videre med valideringsreglene slik de er spesifisert.

PDF-skisser

lukket

Se spesifikasjon: https://dibk.atlassian.net/wiki/spaces/FB/pages/2839412761

Innspill: Vi sendte skissene til arbeidsgruppa og til utvalgte kommuner. Vi fikk følgende innspill:

• Usikkert hva som er forskjellen på vilkår og oppfølgingspunkt

• Ønske om å kunne se mer informasjon om hva som er vilkåret

• Ønske om å kunne se hva som er siste delsøknad. Vi anser dette innspillet som ivaretatt: Ved siste delsøknad skal alltid gjelderHeleTiltaket være true.

Vi har gjort noen tiltak:

• Veiledning om forskjellen mellom vilkår og oppfølgingspunkt

• Vi foreslår å legge inn beskrivelse som et valgfritt felt i datamodellen for utfallsbesvarelse

Datamodell

lukket

Se spesifikasjon: https://dibk.atlassian.net/wiki/spaces/FB/pages/2783870977

Innspill: Vi diskuterte datamodellen på arbeidsgruppemøtet 22.11.2023 med følgende konklusjoner:

• Vi beholder generelleVilkaar som foreslått.

• DiBK tar kontakt med Arbeidstilsynet for å drøfte muligheten til at samtykket kun sendes fra ansvarlig søker.

• Nyttig med igNummer som integer (tall)

• DiBK oppdaterer dokumentasjonen slik at utfallsbesvarelse vises som en liste

• Overgangsordning og egenerklaering blir i denne omgangen ikke tatt med som en del av søknad om igangsettingstillatelse