Søknad om tiltak uten ansvarsrett ble utviklet med utgangspunkt i at tiltakshaver sender inn søknaden selv. I praksis er det mange tiltakshavere som ønsker å sette denne jobben bort til andre, som da får en søker- eller hjelperrolle på vegne av tiltakshaver. Vi har i lengre tid jobbet med departementet for å se på ulike løsninger, og går gjennom disse under.

Kort oppsummert anbefaler vi alternativ 1, hvor søker utarbeider et utkast som tiltakshaver signerer og sender til kommunen. Alternativ 2-3 er også tillatt, men trolig ikke ønsket av brukerne. Alternativ 4-6 er ikke mulige å bruke i dag.

Les mer om de ulike alternativene, med tenkt flyt og vurdering:

1. Søker lager et utkast som tiltakshaver sender inn

Beskrivelse

1. Søker lager et utkast av søknaden. Når søknaden er klar for sending til kommunen, sender søker en lenke til utkastet til tiltakshaver.

2. Tiltakshaver følger lenken og kan gå gjennom søknaden og vedlegg i et eget brukergrensesnitt.

3. Dersom tiltakshaver godkjenner søknaden, kan hen signere og sende søknaden ved å logge inn på ID-porten via Altinn.

Se denne dokumentasjonssiden for flere detaljer: Søkerrolle i tiltak uten ansvarsrett

Vurdering ✅

• Juridisk uproblematisk og anbefalt løsning.

• Teknisk gjennomførbar og i drift i et søknadssystem i dag.

• Dersom det er interesse for det, kan DiBK ta initiativ til en workshop med søknadssystemene for å tegne ut et felles forslag til steg og tekster.

2. Tiltaket belegges med ansvarsrett

Beskrivelse

1. Tiltakshaver belegger tiltaket med ansvarsrett og bruker ettrinnssøknad i stedet.

Vurdering ✅

• Etter SAK10 § 6-7 er det mulig for tiltakshaver å ta i bruk ansvarsrettssystemet selv om tiltakshaver selv kan søke om tiltaket (pbl. § 20-4), men det er da en forutsetning at hele tiltaket belegges med ansvarsrett.

• Trolig ikke et ønsket alternativ for søker/tiltakshaver.

3. Søker påtar seg rollen som tiltakshaver

Beskrivelse

1. Søker påtar seg rollen som tiltakshaver i byggesaken og sender søknaden til kommunen. Ansvarsforholdet må avklares privatrettslig.

2. Søker kan gjerne sende en bekreftelse på ansvarsforholdet til kommunen med søknaden.

3. Søker viderefakturerer gebyret til tiltakshaver.

Vurdering ✅

• Det er juridisk mulig å være tiltakshaver for tiltak på andres eiendom, så lenge man har det privatrettslige i orden.

• Det er neppe noe søkerne ønsker å gjøre, fordi de da vil stå ansvarlig for alt tilknyttet både prosessen og byggetiltaket.

4. Tiltakshaver gir søker fullmakt i Altinn

Beskrivelse

1. Søker ber tiltakshaver om rettigheter til søknadsskjemaet i Altinn.

2. Søker utarbeider en kladd og sender denne til gjennomlesing hos tiltakshaver før innsending.

3. Søker sender inn og signerer søknaden på vegne av tiltakshaver.

Vurdering

• Løsningen er ikke avklart juridisk, da departementet ønsker mer informasjon om hvordan det kan løses privatrettslig.

• Teknisk kan det være utfordrende for tiltakshaver å gi riktige rettigheter i Altinn. I tillegg glemmer tiltakshaver ofte å fjerne rettighetene.

• Personvernmessig kan løsningen være utfordrende fordi søkere ofte må be om fødselsnummeret til tiltakshaver for å få riktige rettigheter i Altinn.

5. Søker er avsender og henter signatur via tiltakshavers samtykke

Beskrivelse

1. Søker gjør søknaden klar for signering og sender den til gjennomlesing via tjenesten for tiltakshavers samtykke

2. Søker må ha rettigheter i Altinn eller ha eget organisasjonsnummer i feltene for tiltakshaver

Vurdering

• Ikke en holdbar løsning fordi det juridiske i tiltakshavers samtykke er tilpasset en annen hjemmel.

• Det vil også bli feil i kommunenes fagsystem at hjelper registreres som tiltakshaver uten å være det formelt.

6. Opprettelse av et eget søker-objekt i datamodellene

Beskrivelse

1. I tillegg til tiltakshaver-objektet som ligger i datamodellen i dag, legger vi inn et “søker”-objekt. Dette vil fungere på samme måte som “ansvarlig søker” i søknader med ansvarsrett.

Vurdering

• Ikke avklart juridisk.

• Ressursmessig krevende, da det vil kreve ny datamodell, PDF og valideringer for både søknad uten ansvarsrett og påfølgende søknader (midlertidig brukstillatelse, endringssøknad, ferdigattest og supplering av søknad). Feltet for “ansvarlig søker” kan ikke brukes da det kan føre til feilregistrering i kommunenes fagsystem.

• I og med at vi har bedre og enklere alternativer vil vi ikke gjennomføre et slikt prosjekt i overskuelig fremtid.

Etter innspill på service desk har vi gjort følgende justeringer i kodelister og valideringsregler:

Ny kode for avløp der bygningen ikke har innlagt vann

Beskrivelse

Vi har lagt til en ny kode for avløpstilknytning: Bygningen skal ikke ha innlagt vann. Kodelisten for avløp blir med dette mer i tråd for vanntilknytning, som ble endret våren 2021.

Feltet brukes i søknad om rammetillatelse, søknad om tillatelse i ett trinn og søknad om tiltak uten ansvarsrett.

Vi har også tilpasset valideringsreglene slik at søker ikke må svare på spørsmål som ikke er relevante, dersom IkkeAvlop er valgt. Det gjelder følgende regler:

Tilpasninger hos søknadssystemene

Søknadssystemer som ikke henter kodelistene direkte fra GeoNorge, bes oppdatere disse så snart som mulig.

Vi anbefaler også at søknadssystemene besvarer spørsmålet om avløpstilknytning automatisk med Bygningen skal ikke ha innlagt vann dersom vanntilknytning er Ikke innlagt vann.

Endringen antas ikke å ha konsekvenser for eByggesakssystemene.

Endringssøknad: Endret validering for dispensasjon

Vi hadde en opprydding av dispensasjonsreglene for nabovarsel tidligere i år, men er gjort oppmerksom på at endringssøknad ikke samsvarer med endringene. Derfor er søknad om endring av gitt tillatelse nå oppdatert slik at den samsvarer med valideringsreglene for rammesøknad.

Samtidig har vi oppdatert teksten på regel 4402.1.24 slik at den samsvarer med forventet valideringsresultat.

Supplering av søknad: Endret kodelistevalidering

I ettersending er det endret valideringsresultat for en kodebeskrivelse som dessverre var feil.

Ansako: Justerte tekster og betingelser

Vi har lagt til forutsetning på reglene om saksnummer, og en ny regel som sjekker om saksåret er gyldig. I tillegg har et par regler fått ny og forbedret tekst. Den viktigste endringen er at valideringsresultatet er endret fra advarsel til feil på to av saksnummer-reglene.

Følgende endringer er felles for alle erklæringene (prefiks er fjernet):

• .25.108.2

• 25.109.1

• .25.108.1

• .35.30.38.3

• .28.16.39.1

• .28.16.38.3

Følgende regel gjelder kun for ansvarserklæring:

• 10000.1.27.29.31.38.3

Direkte innsendt kontrollerklæring

Vi har slettet regel 5444.1.6.7 og endret valideringsresultat på 5444.1.6.8 fra advarsel til feil, for å sikre at søker kan sende inn flere kontrollerklæringer for det samme kontrollområdet.

Vi har merket kravtabellene med datoen 20.05.22 for å gjenspeile endringene. Disse er oppdatert.

Oppsummert:

• FtB backend får ikke innsendelser fra Altinn 18. mai 2022 i tidsrommet 20:00 -- 21:00

• Innsendelser fra søknadssystemer kan gå som normalt, blir køet opp for behandling etter nedetid.

• Status APIet vil oppleves forsinket siden vi først får AR referansen for behandling etter kl 21

• Tjenester utenfor Altinn (Ansako) kjører som normalt

Info:

Altinn oppdaterer sine systemer 18. mai. I denne forbindelsen vil Fellestjenester BYGG ikke kunne hente ned innsendelser for behandling i tidsrommet kl. 20:00-21:00.

Altinn sitt REST API for sluttbrukere vil være tilgjengelig slik at kunder/søknadssystemer kan gjøre innsendinger inn til Altinn. Disse blir køet opp og behandlet etter kl 21 i FtB.

Status APIet vil ikke kunne levere status informasjon for disse innsendingene før etter kl 21.

Driftsvarsel fra Altinn:

Vi har produksjonssatt en rekke søknader på nytt for å gjøre følgende endringer:

Endringene er i produksjon.

1. Miljøsaneringsbeskrivelse er lagt inn for supplering av søknad

Miljøsaneringsbeskrivelse er lagt inn som gyldig vedleggstype for følgende søknad:

• Supplering av søknad

2. Utomhusplan er lagt inn for IG, MB og FA

Utomhusplan er lagt inn som gyldig vedleggstype for følgende søknader:

• Søknad om igangsettingstillatelse

• Søknad om midlertidig brukstillatelse

• Søknad om ferdigattest

3. Godkjente filformat for tegningEksisterendePlan er redusert

Vi har justert tillatte filformat for Tegning eksisterende plan til pdf, jpeg, jpg, tif, tiff, png. Bakgrunnen er at vedlegget skal kunne printes dersom det legges ved nabovarsel.

Det gjelder følgende søknadstyper i tillegg til nabovarsel:

• Supplering av søknad

• Søknad om igangsettingstillatelse

• Søknad om midlertidig brukstillatelse

• Søknad om tillatelse i ett trinn

• Søknad om rammetillatelse

• Søknad om tiltak uten ansvarsrett

• Søknad om endring av gitt tillatelse

• Tiltakshavers samtykke

Mer om godkjente filformat her: Godkjente filformat

Sluttrapport for bygningsavfall er nå klar i test! Planlagt produksjonssetting er 30. mai.

Sluttrapporten er et underskjema til søknad om ferdigattest. Underskjemaet lar søker levere informasjon om planlagt og levert avfall digitalt til kommunen. Avfallsdataene sendes også automatisk til SSB ved innsending.

For søknadssystemer er all informasjon om tjenesten samlet her, inkludert flyt, datamodell, valideringer og PDF: Sluttrapport for bygningsavfall

Vi har også laget en veileder til eByggesakssystemene: Mottak av Sluttrapport med avfallsplan

Som vi kunne lese på nyhetene i går kveld, har Norkart blitt utsatt for et omfattende dataangrep der personopplysningene til 3,3 millioner innbyggere kan være lastet ned. Angrepet ble oppdaget 5. mai.

Mer informasjon om angrepet ligger her:

• Artikkel fra NRK: https://www.nrk.no/norge/1.15962268

• Pressemelding fra Norkart: https://www.norkart.no/

Hvilke følger har angrepet for FtPB?

DiBK følger situasjonen nøye med tanke på om angrepet kan få andre konsekvenser enn at persondataene er på avveie. Blant flere trusselscenarier har vi bedt Norkart bekrefte at angriperne ikke kan ha lagt igjen skadelig programvare som kan spre seg videre, ev. også til FtPB-økosystemet.

Norkart kan forsikre om at angrepet ikke medfører noen risiko for FtPB-verdikjeden. Administrerende direktør i Norkart, Leif Arne Brandsæter, ønsker å formidle følgende:

Saken om datainnbrudd hos Norkart knytter seg til Norkart fritektssøketjeneste. Fritekstsøketjenesten er en kopi av matrikkel. Svakheten som var medvirkende til angrepet er rettet. Norkart er behandlingsansvarlig for denne tjenesten. Saken er politianmeldt. Norkart har ikke indikasjoner på at opplysningene er blitt forsøkt misbrukt eller at andre Norkart tjenester er berørt.

Norkarts øvrige systemer som f.eks. Gisline, Komtek og tjenester på eTorg, er slik vi ser det, ikke påvirket av hendelsen.

Angrepet er en viktig påminnelse på at vi alle må jobbe aktivt og kontinuerlig med sikkerhet og personvern. Vi intensiverer sikkerhetsarbeidet vårt og vil nå gå gjennom prosedyrene for håndtering av cyberangrep mot FtPB-verdikjeden.

Varslingsplikt ved lignende hendelser

Vi minner om at alle konsesjonshaverne har en plikt til å varsle oss om lignende hendelser. Dette følger av punkt 4.8 i bruksavtalen:

Spørsmål og kommentarer kan som alltid rettes til service desk.

EDIT 12.05.22: Offisiell uttalelse fra Norkart er lagt inn i saken.

Feil ved henting av skjema og vedlegg fra Altinn.

Vi har valgt å slå av FtB behandling av alle innsendinger til vi vet mer om feilen, dette blogg innlegget blir oppdatert etter hvert.

Nå er det mulig for kommunene å få lagt inn egne sjekkpunkt i de nasjonale sjekklistene. Funksjonaliteten er tilgjengelig både i test og produksjon, og vi ønsker innspill fra dere på endepunktene i API-et.

Pilot for kommunale sjekkpunkter

Foreløpig er det kun Bærum som har lagt inn 5 egne sjekkpunkt som en pilot. I skrivende stund er kun 2 av disse tilgjengelig i testmiljøet, men de resterende legges ut fortløpende.

I innsynsløsningen er det lagt inn en mulighet til å filtrere på kommunenummer og organisasjonsnummer slik at kun det ønskede utvalget kommer opp: https://dibkchecklist.azurewebsites.net/checklist/RS/?Owner=3024

De kommunale sjekkpunktene blir lagt inn av DiBK via nettløsningen. Kommuner som ønsker å legge inn egne sjekkpunkt må ta kontakt med hgl@dibk.no.

Tilpasninger i søknads- og eByggesakssystem

De kommunale sjekkpunktene blir merket med kommunenummer. Det er derfor viktig at både søknadssystemene og sakssystemene er klar over dette slik at de kommunale sjekkpunktene kan hentes inn ved søknad til den aktuelle kommunen.

Sjekkpunktene kan filtreres via API: https://dibk-checklist-api.azurewebsites.net/api/sjekkliste/{søknadstype}?eier={dibk}&eier={kostra}&eier={kommune}

Eksempel:

• DiBK - https://dibk-checklist-api.azurewebsites.net/api/sjekkliste/RS?eier=974760223

• Kostra - https://dibk-checklist-api.azurewebsites.net/api/sjekkliste/RS?eier=971526920

• Bærum kommune https://dibk-checklist-api.azurewebsites.net/api/sjekkliste/RS?eier=3024

• Kostra og Bærum: https://dibk-checklist-api.azurewebsites.net/api/sjekkliste/RS?eier=971526920&eier=3024

Grensesnitt og API-er er dokumentert nærmere her: Nasjonale sjekklister for byggesak

Frist for innspill er 14. juni.

Vi har oppdatert signeringsløsingen for ansvarlige foretak. Planlagt produksjonssetting er onsdag 11. mai.

Under beskriver vi endringer som er gjort, samt et par oppdateringer vi ber søknadssystemene om å gjøre.

Oversikt over endringer

Følgende endringer er lagt ut:

• Frontend er oppdatert til nytt rammeverk for å støtte utfylling på mobil og nettbrett

• Linjeskift er lagt inn i signerte PDF-er der de manglet

• Adresselinje 2 og 3 er lagt inn i GUI og PDF

• Funksjonalitet for telefonnummer er endret slik at mellomrom ikke blir med i XML-en

• Redirect er lagt inn blant annet når man trykker “tilbake” i ID-porten

• Løsning for håndtering av midlertidige feil

• Diverse forbedringer i design/GUI

Tilpasninger hos søknadssystem

Søknadssystemene trenger ikke gjøre tilpasninger for å imøtekomme endringene. Vi ser imidlertid at ikke alle leverandørene bruker løsningen slik vi har tenkt. Vi ber derfor om at alle tar en gjennomgang for å påse at:

1. XML-en til den signerte ansvarsretten sendes med til kommunen sammen med PDF-en, som beskrevet her. Det er for at eByggesakssystemene kan bruke de strukturerte dataene fra erklæringen.

2. Det nye validerings-APIet brukes, som beskrevet her.

Vi har fått en avklaring fra Kommunal- og distriksdepartementet (KDD) om hvordan nabovarsling skal håndteres når mottaker er død.

Departementet skriver at at det er mulig å unnlate nabovarsling der mottaker av varselet er død og dødsboet eller boets adresse ikke fremgår av matrikkelen. De konkluderer videre med at pbl. § 21-3 ikke gir hjemmel til å kreve at ansvarlig søker foretar ytterligere undersøkelser.

Svaret kan lastes ned som PDF her:

Vi har oppdatert dokumentasjonen så den reflekterer avklaringen fra KDD: FAQ: Spesialtilfeller og mangler

Vi ønsker innspill fra både søknadssystem- og sak-/arkivleverandører på hvordan vi på en enkel måte kan heve kvaliteten på matrikkeldata.

Vi jobber med et API som kan hente ut nåværende matrikkeldata for en eiendom. Vi ønsker at disse dataene kan forbedres og suppleres, før de sendes tilbake til matrikkelfører i kommunen gjennom et underskjema til byggesøknadene.

Dette vil hjelpe matrikkelføring som følge av byggesak.

Dataflyt/Prosess

Vi ser for oss følgende prosess:

1. Søknadssystemet henter nåværende matrikkeldata for en eiendom gjennom matrikkel API-et

2. Dataene blir returnert fra API-et som en preutfylt “matrikkelopplysninger”-xml

3. Søknadssystemet oppdaterer/supplerer gitte data hvis nye data er tilgjengelige

4. Oppdatert xml blir lagt ved byggesøknad innsending som underskjemaet “Matrikkelopplysninger”

5. Matrikkelfører i kommunen mottar oppdaterte og strukturerte data ved mottak av søknaden

Figur av API-et for å hente matrikkeldata

Prosess

Innsending til kommunene

Datamodell

Den eksisterende datamodellen for matrikkelopplysninger er tilgjengelig her:

https://altinn.no/api/metadata/formtask/5721/1/forms/5625/42144/xsd

Nye felter

Vi tenker å modellere noen nye felter som kan heve kvaliteten av matrikkelen. Disse feltene kan være:

På eiendomsnivå:

• Kommunenummer

• Gårdsnummer

• Bruksnummer

• Festenummer

• Seksjonsnummer

• Areal på eiendommen

• Informasjon om usikre grenser

• Grense nr. 1:

  • nøyaktighet ukjent

  • nøyaktighet (heltall)

  Grense nr. 2:

  • nøyaktighet ukjent

  • nøyaktighet (heltall)

• Informasjon om kulturminner (ja/nei)

• Informasjon om grunnforurensning (ja/nei)

• BRA totalt for alle bygninger på hele eiendommen

• BYA totalt for alle bygninger på hele eiendommen

• BTA bruttoareal for alle bygninger på hele eiendommen

På bygningsnivå:

• Bygningsnummer

• BRA bruksareal per etasje

• BRA totalt for bygningen

• BYA bebygd areal (kun én verdi per bygning)

• BTA bruttoareal per etasje

• BTA totalt for bygningen

Videre arbeid

Vi jobber med å ferdigstille datamodellen og arbeidet med å fylle den med eksisterende matrikkeldata. Vi vil også oppdatere API-et og tjenester rundt matrikkelopplysninger-skjemaet.

Notater til datamodell

• Vi vurder å legge et atributt på alle elementene i datamodellen for å indikerer om feltene er oppdaterte etter uthenting av matrikkel data.

Innspill

Vi ønsker innspill fra økosystemet på hvordan vi kan forbedre matrikkeldataene, hvilke data vi bør innhente og hva som er “lavthengende frukt” for å forbedre matrikkeldata med en tjeneste som så langt ikke er påkrevd.

Frist for innspill er 14. juni.

Vi varsler med dette at en ny versjon av tiltakshavers samtykke blir produksjonssatt om fire uker. Oppdateringen er nødvendig blant annet for å bedre brukeropplevelsen og gjøre tjenesten tilgjengelig på mobil og Safari.

Under følger en oversikt over hvilke tilpasninger søknadssystemene må gjøre for å imøtekomme endringene, samt en oversikt over andre endringer vi har gjort.

Tilpasninger hos søknadssystemene

Søknadssystemene må gjøre følgende endringer innen fristen for å imøtekomme endringene:

1. Oppdatere URL for signeringsoppdrag

2. Sende partstype og organisasjonsnummer for tiltakshaver i API-kallet

3. Sørge for at API-kallet er i henhold til ny validering

1. Oppdatert URL for signeringsoppdrag

URL-en for signering er endret til tiltakshavers-samtykke.dibk.no/veiviser/{id}. Se oversikt over URL-er her: Datafyll, tiltakshavers samtykke.

Gamle URL-er vil automatisk få redirect til den nye tjenesten for å sikre sømløs overgang. Dette trer i kraft så fort vi prodsetter den nye løsningen.

2. Nye felter i API-kall

Vi har lagt inn to nye felter i API-kallet: TiltakshaverPartstypeKode og TiltakshaverOrgnr. Organisasjonsnummer er påkrevd dersom tiltakshaver ikke er privatperson. Feltene er nødvendige for å sikre at tiltakshaver velger riktig aktør i oversikten over hvem hen kan representere. Mer informasjon finnes her: API for å opprette et nytt samtykke.

3. Validering av API-kall

Vi har tidligere ikke hatt validering på at nødvendige felter sendes med API-kallet. Vi legger nå inn en slik validering. Hvilke felter som er påkrevd er dokumentert her: Start en ny signering

Oversikt over andre endringer

Vi har blant annet gjort følgende endringer i tjenesten:

• Oppdatert koden slik at tjenesten fungerer på mobil og alle nettlesere. Dette innebærer at vi har byttet autentisering mellom veiviseren og Altinn REST-API til Oauth.

• Endret rollevisningen slik at tiltakshaver kun ser relevante parter i listen over hvem hen kan representere. Dersom tiltakshaver er en organisasjon, huker vi automatisk av for firmaet med riktig organisasjonsnummer. Tjenesten er lagt inn i rollen Plan- og byggesak i Altinn.

• Laget en informasjonsside med brukerrettet informasjon på dibk.no/tiltakshavers-samtykke.

• Oppdatert tjenesten med mer veiledning og kontroll, samt personvern- og cookieerklæringer.

Vi har også oppdatert malen for e-postvarsling. E-postmal og resten av flyten i tjenesten er dokumentert her: Flyt og utfylling av tiltakshavers samtykke

I tillegg har vi lagt til rette for at søknadssystemene kan lage en egen veileder med FtBs API. Ta kontakt på service desk hvis dette er interessant.