Vi har oppdatert dokumentasjonen med mer informasjon om naboenes svarfrist. Vi ber alle søknadssystemer lese gjennom og sikre at systemet er satt opp i tråd med denne spesifikasjonen.

Naboenes svarfrist

Naboenes svarfrist gjelder til midnatt den 14. dagen etter at varselet ble sendt, uavhengig av klokkeslettet det ble sendt. Eksempel: Hvis nabovarselet ble sendt den 10. januar kl. 08:00, har naboene frist til den 24. januar kl. 23:59.

Det er svært viktig at søknadssystemet henter inn alle merknader som sendes innen fristen. Vi anbefaler at søknadssystemene sperrer for at søknaden kan sendes inn til kommunen til og med den 15. dagen etter at nabovarselet ble sendt, med mindre alle naboene har sendt samtykke.

Bakgrunn

Vi har hatt en sak hvor nabomerknader har gått tapt som følge av at ansvarlig søker sendte søknaden den 14. dagen. Bare minutter etter at søknaden var sendt, kom nabomerknadene inn. Naboene hadde overholdt fristen for svarskjemaet i Altinn, men merknadene ble ikke importert til systemet eller fanget opp av ansvarlig søker, noe som har hatt svært alvorlige konsekvenser for naboene det gjaldt.

Mer informasjon

Dokumentasjonen for Svar på nabovarsel: Svar på nabovarsel (kvittering)

Se også våre anbefalinger for Nabomerknader som kommer etter fristen.

Hovedombygging ble satt i produksjon i går, 23. februar. Vi minner om at søknadssystemene har frist til 23. mars til å støtte sending av den nye tiltakstypen.

Les mer her: Varsel: Ny tiltakstype for hovedombygging

Alle API-ene for saksbehandlingsdata er nå klare til test i økosystemet. Vi har lagt ut eksempler på API-kall og valideringsregler som undersider til hvert av API-ene:

• API for kvittering

• API for dokumentformidler

• API for mangler

• API for vedtak

• API for oppdatert milepæl

• API for saksoppdatering

• API for endret saksnummer

API-et for dokumentformidling kan testes i Postman, mens de andre API-ene også kan testes på Swagger (autentisering med Basic Auth): https://saksbehandlingsdataapi-test.dibk.no/swagger/index.html

Pilotering

Vi ønsker ikke å legge ut API-ene før piloteringen er i gang. Det er tre søknadsleverandører og tre eByggesaksleverandører som har meldt seg som piloter. eByggesaksleverandørene har fått frist ut februar på å komme med tidspunkt for oppstart.

Tidsplan

I tillegg til API-ene ønsker vi å teste notifikasjon i pilotene. Vi i DiBK regner med at notifikasjon er ferdigstilt fra oss før påske. Det er likevel ingenting i veien for å begynne arbeidet med pilotene før den tid.

Vi legger ut en oppdatert tidsplan når vi har fått mer detaljer om tidspunkt for oppstart fra eByggesaksleverandørene.

KS melder om at SvarUt er utilgjengelig som følge av siste dagers ytelsesproblemer. Vi har derfor slått av prosesseringen av skjema frem til SvarUt er tilgjengelig igjen.

https://status.fiks.ks.no/incidents/blrmzptftfx2

Som følge av nedetiden har 6 skjema fått status Feilet i Fellestjenester Bygg. Vi vil informere de berørte søknadsystemene om hvilke skjema som har feilet.

Oppdatering 10:21 - KS melder at SvarUt er tilgjengelig igjen. Vi starter dermed opp igjen prosesseringen.

Testmotoren og TEST-miljøet i Fellestjenester Bygg er nå satt opp slik at det er mulig å teste den nye tiltakstypen hovedombygging.

Sjekklisteendringene for tiltakstypen er satt opp i testmiljøet for sjekklistene. Valideringer i FtB-TEST peker nå på disse sjekklistene slik at endringene kan testes før de blir lagt i PROD i 23. februar.

Tiltakstypen hovedombygging er satt opp både for BYGG og Arbeidstilsynet.

Lenke til kodelisten:

https://register.geonorge.no/kodelister/byggesoknad/tiltaktype/hovedombygging

Vi har fått inn flere saker på at postnummer valideringer feiler slik at det ikke er mulig å prevalidere innsedninger av erklæringer til Ansako.

Oppdatering 1: vi har funnet at Bring APIet vi bruker for valideringer ikke for tiden returnerer poststed og derfor feiler vår validering som sjekker både for gyldig postnummer og at poststed er fylt ut i henhold til postnummer. Vi jobber med en løsning … vi har identifisert et annet API hos Bring vi kan bruke.

Oppdatering 2:

Bring rapporterer nå feilen selv og har en workaround som vi tester ut.

https://status.bring.systems/

Oppdatering 3: ser ut som Bring har fått fikset APIet og vi ser nå at valideringstjenesten i PROD fungerer igjen uten at vi trang å deploye noen endringer. Vi følger med utover dagen.

KS melder om at Fiksplattformen har driftsproblemer. Vi har derfor slått av prosessering av skjema frem til dette er løst.

https://status.fiks.ks.no/incidents/p4qqxxpcf3j2

Oppdatering: KS melder at SvarUt er tilgjengelig igjen. Vi starter dermed opp igjen prosesseringa av innsendinger.

Oppdatering og ny anbefaling

Grundige tester og tilbakemeldinger fra søknadssystemene, tyder på at vi ikke har tap av data ved sending av lister med ettersendinger og mangelbesvarelser.

Vi finner imidlertid problemer med sending av lister av vedlegg og underskjema, som er felter som ligger under både ettersending og mangelbesvarelse.

Ny anbefaling er derfor å ikke bruke lister med vedlegg og underskjema. Vi anbefaler å bruke underskjemaet Vedleggsopplysninger til å spesifisere hvilke vedlegg som er sendt.

Videre ber vi søknadssystemene følge med på support og varsle oss dersom viktig data blir tapt. Det er sendt over 14.000 suppleringer av søknad uten at vi har sett tap av data, så vi tror sjansen for dette er svært liten.

Opprinnelig blogginnlegg

Vi har funnet ut at InfoPath i Altinn2 kan ha informasjonstap med datamodeller der foreldre/barn liste-noder har samme navn. Vi har denne situasjonen spesielt i datamodellen for Supplering av søknad.

Feilen fører til at vi kan miste data dersom brukeren sender en liste av følgende dataobjekter:

• ettersending

• mangelbesvarelse

• vedlegg i ettersending eller mangelbesvarelse

Forslag til midlertidig løsning

En endring av datamodellen vil kreve bruk av ressurser og koordinering i hele verdikjeden. Vi ønsker derfor å finne en løsning hvor vi kan fortsette å bruke dagens versjon i Altinn 2, uten å bruke ressurser på å lage en ny versjon på en plattform som er på vei ut. Vi vil selvsagt prioritere å løse problemet i neste versjon av tjenesten, i forbindelse med flytting fra Altinn 2.

Vårt forslag til løsning er på bakgrunn av dette at søknadssystemene begrenser sending av de berørte elementene til én verdi. Vi kan i tillegg legge på en validering som gir ERROR i prevalideringen dersom det sendes lister med flere enn én verdi.

Problembeskrivelse

Figuren under markerer hvor feilene oppstår i datamodellen.

For eksempel har noden “ettersending” knyttet til en liste som også heter “ettersending”, “vedlegg” er knyttet til et listeobjekt “vedlegg”. Det samme skjer for elementet “mangelbesvarelse“ (ikke vist i bildet).

Problemet i InfoPath er at bare det første elementet i disse listeobjektene kommer med videre til backend, så informasjon som ligger videre i listene blir tapt.