Dispensasjon i nabovarsel

lukket

Dispensasjonselementet gjøres i første omgang valgfritt i nabovarsel og søknadene som er planlagt til høsten, etter ønske fra EG Holte. Det vil si at vi legger det inn i datamodellene, men at elementet ikke valideres med mindre noe er utfylt. Slik kan de leverandørene som ønsker å innføre dispensasjon med byggesøknadene gjøre det nå, mens de som ønsker å vente kan implementere dispensasjon etter migreringen. Informasjon oppdatert på Søknad om dispensasjon v1 | Fremtidige utvidelser

Jun 18, 2025 Til informasjon

Forslag til endring av naboGjenboer

lukket

Vi ønsker tilbakemelding på om det vil være nyttig å omstrukturere naboGjenboerEiendommer (tidligere naboEier). Dette innebærer også navneendring av elementer. I dag ligger informasjon om naboen sammen med naboens eiendom(mer) og sluttbrukersystemVaarReferanse på samme nivå i listen naboGjenboer. Dersom en person er hjemmelshaver til flere naboeiendommer dupliseres informasjonen i innsendingen. Vi i FtPB håndterer sammenslåing og varsling i backend, dvs at hjemmelshaveren kun mottar ett varsel og én melding i Altinn for alle eiendommene som berøres.

Dette er en uheldig duplisering av data, fører til ekstraarbeid og dårlig logikk. I tillegg gjenbrukes dette i svarskjemaet. Vi har derfor laget et forslag til struktur som inneholder en liste over eiendommer (med sluttbrukersystemVaarReferanse) per eier, slik at strukturen i modellen samsvarer og harmoniserer med elementer dere kjenner fra andre tjenester:

Vårt spørsmål er derfor om denne strukturen enkelt kan implementeres, eller om det skaper unødvendige utfordringer.

Jun 5, 2025 Ønsker innspill på forslaget. Frist 12.06.2025. Arbeidsgruppa varsles også på Slack/mail.

Jun 16, 2025 Kun mottatt svar fra én leverandør, som påpeker viktigheten av at API-ene returnerer opprinnelig struktur. Dette ivaretas. Datamodellen er oppdatert og vi går videre med forslaget.

Endring i datamodell - nytt element

lukket

ansvarForByggesaken Vi legger til dette nye standardelementet slik at vi kan filtrere tiltakstypene på om nabovarselet gjelder tiltak som er ansvarsbelagt, uten ansvar eller ikke-søknadspliktige tiltak som krever dispensasjon (men som må nabovarsles).

May 14, 2025 Til informasjon.

Bruk av gjenpart

ÅPEN

Behov for å avklare hvilke leverandører som bruker Opplysninger gitt i nabovarsel (gjenpart) da dette var et underskjema i Altinn 2. Vi må ta stilling til hva vi skal gjøre

• endre det til et vedlegg med egen XML (som for gjennomføringsplan)

• fases ut til fordel for kopi av nabovarsel og kvittering

• generere funksjonaliteten i XML for kvittering ved å legge til mer strukturert informasjon

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Behov for endelig avklaring. Frist for innspill 07.05.2025

May 16, 2025 Det er kun én av leverandørene som i dag bruker gjenpart av nabovarsel, mens de øvrige sender med kopi av nabovarselet og kvittering fra distribusjonen. Det er ikke registrert noen henvendelser fra kommuner som etterspør dette. Vi ønsker å avvente en avgjørelse om videre fremdrift til vi har mottatt tilbakemelding om dagens bruk og behov fra leverandørene og enkelte kommuner. 

Vårt ønske er å avvikle gjenpart og legge til en utvidet XML til kvitteringen. Denne tilnærmingen vil sammenstille funksjonalitet fra dagens løsning for kvittering og gjenpart, men forenkler utviklingen til én tjeneste. Ny funksjonalitet må støtte oppdateringer underveis mens nabovarslet er aktivt, med en siste oppdatering enten når svarfrist er utløpt eller om alle naboer har samtykket. 

Denne informasjonen er også sendt arbeidsgruppa på mail.

Kommunikasjon med avsender via API til søknadssystemet

ÅPEN

For profesjonelle utbyggere som sender mange nabovarsel er det frustrerende å forholde seg til Altinn innboks og arkiv for å håndtere kopi av nabovarsel, kvittering og merknader.

Vi ønsker at dialogen med avsender skal gå direkte til søknadssystemet via status-API-et. Vi vil bruke FtPB Hendelser for notifikasjon. Dette krever at ingen av leverandørene har basert seg på bruk av Altinn innboks/arkiv.

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Behov for endelig avklaring. Frist for innspill 07.05.2025

May 14, 2025 Innspillene uttrykker bekymring knyttet til gjenfinning, frykt for å miste informasjon etter at de stopper å polle/spørre og løsningens robusthet. Vi mener mye av uroen løses ved å stenge for merknader etter svarfristen og ved å innføre en referanse/ID som knytter sammen nabovarselet, kvitteringen og merknadene (pt hovedinnsendingsnummer). I tillegg er det viktig å påpeke at dette vil være et robust system med push-varsel over hendelsene, inkludert en logg der hendelsene skal kunne kvitteres ut. Vi påpeker også at dette er informasjon som kommer i tillegg til dagens info i Status-API-et. Forbedret funksjonalitet i Altinn 3 gir oss bedre sporing og sammenknytning av naboene som er varslet i samme nabovarsel.   

FtPB ønsker å gå for en løsning der kommunikasjon med avsender er basert på API-et, og vi kommer til å fortsette å undersøke ulike alternativer før vi konkluderer.

Denne informasjonen er også sendt arbeidsgruppa på mail.

Oppdatering av kryptering av naboenes fødselsnummer

lukket

Vi gjør en oppdatering av krypteringen for å øke sikkerheten. I den forbindelse ser vi at krypteringsstrengen blir mye lengre enn i dag. Kan leverandørene håndtere dette?

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Behov for endelig avklaring. Frist for innspill 07.05.2025

May 14, 2025 Ingen hindringer for leverandørene, og vi fortsetter arbeidet med oppdatert krypteringslønsing. Spørsmål om ytelse ved store utsendelser vil ikke være et problem da distribusjonen i Altinn 3 er bedre enn i dagens versjon. Merk at vi ønsker tilbakemelding fra sak-/arkivleverandørene på hvordan dekryptering løses i dag.

Denne informasjonen er også sendt arbeidsgruppa på mail.

Endring i datamodell - nytt element

trukket

hovedinnsendingsnummer Behov for kobling mellom det sendte nabovarselet, kvitteringen og merknadene som kommer inn. Vi undersøker om hovedinnsendingsnummer kan brukes.

Apr 28, 2025 Forslag er lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet, men holder denne åpen frem til løsning er avklart.

Jun 3, 2025 Vi løser koblingen utenom datamodellen. Dette forslaget trekkes.

Endringer i datamodell - innføring av standardelementer

lukket

Innføre standardelementer

• metadata

• soeknadGjelder

  • erstatter beskrivelseavTiltak og beskrivPlanlagtFormaal

• generelleVilkaar

  • nabovarsel har samme krav til språk som søknaden

Apr 28, 2025 Forslag er lagt ut.

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Endring i datamodell - oppdatering av eksisterende elementer

lukket

Endring av eksisterende elementer

• naboEier endrer navn til eierNaboeiendom

  • fjerne telefonnummer, mobilnummer og epost

  • endre adresse til postadresse

  • legge til land, ev. avklare bruk av landkode

• dispensasjon

  • oppdatert til siste versjon, ref. Søknad om dispensasjon

• ansvarligSoeker

  • fjernet kontaktperson

• tiltakshaver

  • fjernet kontaktperson

• plan

  • erstatter gjeldendePlan

Apr 28, 2025 Forslag er lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Endring i datamodell - sletting

lukket

Følgende elementer slettes eller erstattes av nye elementer

• fraSluttbrukersystem

  • ivaretas i metadata

• prosjektnavn

  • ivaretas i metadata

• beskrivelseAvTiltak

  • varetas i soeknadGjelder

• beskrivPlanlagtFormaal

  • varetas i soeknadGjelder

• foelgebrev

  • ivaretas i soeknadGjelder

• signatur

  • slettes, brukes ikke i Altinn 3

Apr 28, 2025 Forslag er lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Endring i datamodell - nytt element

lukket

svarfrist Behov for at søker setter en dato for når merknader må være i hende. Fristen må være på minst 14 dager.

Apr 28, 2025 Forslag er lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Endring i datamodell - nytt element

lukket

kontaktperson Behov for at naboen enkelt skal kunne gjenfinne hvem de skal kontakte dersom de har spørsmål til nabovarselet. Dette vil være obligatorisk og skal fremkomme på PDF-en.

Apr 28, 2025 Forslag er lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Bruk av kontaktperson på naboEier (eierNaboeiendom)

trukket

Behov for å avklare hvilke leverandører som bruker kontaktperson på naboEier. Dette er ikke informasjon avsender kan fylle ut - brukes det ifbm sending til styret i sameier?

Apr 29, 2025 Forslag lagt ut.

Apr 30, 2025 Brukes dersom det er registrert kontaktperson til feks. et styre. Objektet videreføres.

Distribusjon til nabo

lukkket

Naboer som mottar varsel digitalt, skal få varselet med vedlegg som lenker i stedet for at de kopieres opp for hver mottaker - slik det er i dag.

Dette vil gi oss en besparelse av datamengden på 94 %

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Sende til naboer med utenlandsk postadresse

lukkket

Naboer som ikke kan nås digitalt og med postadresse i utlandet, blir i dag ikke varslet. Vi undersøker muligheten for å sikre postal varsling også til disse.

MERK at dette også er et kostnadsspørsmål.

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Positiv respons i arbeidsgruppemøtet. Vi tilrettelegger og ser på kostnadene

Skjule ‘Til utfylling’ i Altinn-innboksen

lukkket

Naboer mottar i dag to instanser i Altinn-innboksen, én melding om nabovarsel og én melding der svarskjema kan utfylles. Det lenkes i tillegg til svarskjema i nabovarsel-meldingen. Dette gir en uheldig brukeropplevelse, og vi ønsker å skjule svarskjema-instansen frem til naboen selv aktiverer den via meldingen.

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Ingen innvendinger i arbeidsgruppemøtet

Prevalidering av distribusjon til naboer

backlog

Dersom naboer på nabolisten ikke kan nås av ulike årsaker (feks. reservert mot digital kommunikasjon, ufullstendig adresse, utenlandsk adresse, dødsfall) vil ikke avsender få informasjon om at disse naboene bør varsles manuelt. En prevalidering for å avklare distribusjonen ville gitt en bedre brukeropplevelse og høyere treffprosent.

MERK Denne funksjonaliteten krever en juridisk avklaring. Den blir ikke prioritert, men legges i backlog.

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Positiv respons til tenkt funksjonalitet i arbridsgruppemøtet. Vi legger denne som avtalt i backloggen

Distribusjon til offentlige myndigheter

backlog

Ønske om at offentlige myndigheter som kan nås via SvarUt mottar nabovarselet direkte i sitt sak-/arkivsystem. Vi ønsker ikke at dette skal være brukerstyrt, feks via en boolsk verdi som i Varsel om planoppstart, men løses teknisk. Vi undersøker mulighetene.

MERK Denne funksjonaliteten vil ikke bli prioritert, men legges i backlog.

Apr 29, 2025 Forslag lagt ut

Apr 30, 2025 Positiv respons til tenkt funksjonalitet i arbridsgruppemøtet. Vi legger denne som avtalt i backloggen

Endring i datamodell for Varsling

lukket

Vi foreslår følgende endring i datamodellen for varsling (dokumentasjon av nabovarsling):

• soeknadSeesKontaktperson fjernes

• redgjorelseFritak er tatt inn

Open

Endringer i objektet for varsling

Endringen vil også påvirke hovedsøknadene når de migreres til Altinn3.

Dec 2, 2024 Oppdatert forslag er lagt ut etter tilbakemeldinger 27. november.

Dec 16, 2024 Konklusjon Ingen innspill mottatt innen fristen. Vi beholder forslaget.

Flyt og splitting av saker i kommunen

lukket

Se dokumentasjonsside Arbeidsflyt splitting

Forslaget vil gås gjennom på arbeidsgruppemøtet 27. november.

Dec 16, 2024Konklusjon Ingen innspill mottatt innen fristen. Vi beholder forslaget.

Harmonisering med NPAD

lukket

Se dokumentasjonsside: Sammenheng med planregister - dispensasjonssøknad

Nov 26, 2024 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.

Dec 16, 2024 Konklusjon Ingen innspill mottatt innen fristen. Vi beholder forslaget

Inngangsbeskrivelser og veiledningsmateriell

lukket

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: Kodelister for søknadstjenesten

Dec 16, 2024 Konklusjon Ingen innspill mottatt innen fristen. Vi beholder forslaget

Ny tiltakstype for ikke søknadspliktig tiltak

lukket

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:

• Søknad om dispensasjon

• Nabovarsel

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.

Dec 9, 2024 Konklusjon Ingen innspill mottatt innen fristen. Forslaget lagt som utkast i GeoNorge

Datamodeller for dispensasjon

lukket

Se dokumentasjon:

• Oversiktsdokument: Søknad om dispensasjon

• Dispensasjonssøknad

Vi ber om innspill til begge datamodellene, og spesielt til infobokser merket med ““.

Nov 26, 2024 Nytt forslag til datamodell er lagt ut. Forslaget vil gås gjennom på arbeidsgruppemøtet 27. november.

Dec 16, 2024 Konklusjon Ingen innspill mottatt innen fristen. Vi beholder forslaget

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

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

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: https://dibk.atlassian.net/wiki/spaces/FB/pages/edit-v2/2880503845#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: https://dibk.atlassian.net/wiki/spaces/FB/pages/3095199752

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

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.

Open

Oversikt over endringer i ettersending

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

Open

Oversikt over endringer på rotnivå

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 : Vi fikk ingen innspill på arbeidsgruppemøtet. Saken er åpen for skriftlige tilbakemeldinger.