1. oktober 2021 er første release av Ansako. Dette er en pre-prod og du finner flere detaljer på Utviklingsstatus Ansako. Denne siden vil vi oppdatere underveis.

Veiledning

Vi har lagt ut en integrasjonsveiledning med informasjon og illustrasjoner for Tjeneste-API, Status-API og Nedlastnings-API. Her finner dere eksempler på requests og responser for de ulike erklæringene, i tillegg til info om registeret for sentral godkjenning.

Det er lagt til en side for datafyll, med informasjon om miljø, datamodeller og signeringsfrist.

I tillegg har vi lagt informasjonen om test- og integrasjonsserveren, med beskrivelse av API-ene via Swagger, på en egen side. Lenkene er oppdatert.

Datamodeller

Informasjon om datamodellene har blitt oppdaterte underveis, og modellene kan lastes ned. Dette er en kort oppsummering av alle endringene:

• Attributtene er oppdatert

• Ryddet opp i namespace for alle modellene

Endringer i datamodellen for Ansvarserklæring:

• Lagt til feltet prosjektnr

• Endret navn på feltet vaarReferanse til soeknadssystemetsReferanse

• Flere felt oppdatert med minOccurs 0 i stedet for 1, og feltene er satt til å være nillable

Endringer i datamodellen for Samsvarserklæring:

• Endret navn på feltet SamsvarserklaeringVedDistribusjonType til SamsvarserklaeringType

• Feltene ErTEK10 og sluttbrukersystemUrl er fjernet fra datamodellen.

• Fikset stavefeil på feltet okForMidlertidigBrukstillatelse

• Endret navn på rotfelt til Samsvarserklaering

Endringer i datamodellen for Kontrollerklæring:

• Feltene ErTEK10 og sluttbrukersystemUrl er fjernet fra datamodellen

Det gjenstår å få ferdigstilt en versjon av datamodellene i modelleringsverktøyet Enterprise Architect.

Metadata

Det er også lagt ut et utkast til metadata for Ansako. Der ligger en oversikt over hvilke data som skal lagres for hver erklæring, i tillegg til en oversikt over de ulike statusene en erklæring kan ha - og hvor denne settes.

Valideringsregler v1

Utkast til valideringsregler er lagt ut for alle de tre erklæringene. De har et felles regelsett i bunnen, deretter har vi splittet opp de som er særegne for de respektive erklæringene.

Regelnummer, betingelser og forutsetninger kommer - men denne versjonen gir en god indikasjon på hva som kan forventes.

Brukergrensesnitt og varslingstekster

Vi har også lagt ut foreløpig informasjon om brukergrensesnittet og forslag til varslingstekster på e-post og SMS.

Undersidene pekt på i innlegget vil bli oppdatert. Ta kontakt på servicedesken om det skulle være noen spørsmål.

For at søknadssystemene skal kunne starte implementeringen av Ansako-tjenestene, må datamodellene være klare innen utgangen av september.

Vi har gått gjennom alle innspill i backlog og fra service desk, og har noen åpne avklaringer. Det vil ofte være en avveining mellom å få en bedre løsning, og å holde datamodellen mest mulig lik dagens, slik at det blir mindre arbeid for søknadssystemene.

Fristen for å komme med innspill er tirsdag 28. september (utløpt).

Innspillene kan sendes til service desk (fellestjenesterbygg@dibk.no).

Oversikt over temaer:

Harmonisering av datamodeller

Beskrivelse

Dagens datamodell for ansvarserklæring avviker noe fra datamodellene for samsvars- og kontrollerklæring.

Datamodell for ansvarserklæring

Datamodell for samsvarserklæring

Datamodell for kontrollerklæring

Ulikheter mellom datamodellene

Erklæring om ansvarsrett har ikke feltene sluttbrukersystemUrl eller erTEK10.

I tillegg ligger informasjon om ansvarlig foretak og erklæring for prosjekterende, utførende og kontrollerende under “ansvarsrett” i ansvarserklæringen:

Konklusjon

Det er kun følgende endringer som blir gjort i denne versjonen av Ansako:

• Fjerne erTEK10 fra datamodellene for samsvars- og kontrollerklæring

• Fjerne sluttbrukersystemUrl fra datamodellene for samsvars- og kontrollerklæring

Følgende endringer blir utsatt til versjon 2 av tjenesten:

• Flytte foretak til rotnivå i ansvarserklæring

• Flytte erklaeringAnsvarligProsjekterende, erklaeringAnsvarligUtfoerende og erklaeringAnsvarligKontrollerende til rotnivå i ansvarserklæring

Kommentarfelt i samsvarserklæring

Bakgrunn

Vi har tidligere fått innspill på service desk om at det er ønskelig å innføre muligheten til å spesifisere hvilken delsøknad samsvarserklæringen skal gjelde, for eksempel andre igangsettingssøknad i saken eller tilsvarende for midlertidig brukstillatelse. Innspillet går ut på å legge inn et fritekstfelt der foretakene kan legge inn tekst ved behov når erklæringen signeres i Altinn.

Konklusjon

Følgende endringer blir utsatt til versjon 2 av tjenesten:

Legge inn to nye, frivillige felt i datamodellen for samsvarserklæring:

• Kommentar fra ansvarlig søker

• Kommentar fra ansvarlig foretak

Kommentarene vil også være synlige på den signerte PDF-en.

Vi legger ikke opp til disse feltene i ansvarserklæring og kontrollerklæring.

Frist

Bakgrunn

Foretakene ønsker ofte å sette en frist for når erklæringen skal være signert. Det gjelder spesielt signering av ansvarsretter. For samsvar og kontroll kan det være hensiktsmessig å være mer tilbakeholden med bruk av frist, da ansvarlig søker ikke skal instruere samsvarende og kontrollerende foretak i når de skal ha gjort jobben sin.

Teknisk sett vil en frist være nyttig for at Ansako-tjenesten skal kunne “lukke” erklæringer som ikke blir signert, og for at sluttbrukersystemene skal kunne slutte å spørre på API-et etter at erklæringene er utgått.

Konklusjon

Følgende endringer kommer i denne versjonen av Ansako:

• Ansvarlig søker/søknadssystemet får muligheten til å sette en frist ved behov

• Om vi ikke får en frist fra søknadssystemet, blir default frist satt til 4 uker fra erklæringen er sendt

Fristen ligger i metadata og ikke i datamodellen, så søknadssystemene skal ikke behøve å gjøre endringer på sin side.

Milepæler i ansvarsrett

Bakgrunn

Vi har fått inn et innspill om å fjerne punktet om milepæler (“Våre samsvarserklæringer/kontrollerklæringer vil foreligge ved:”) fra ansvarsretterklæringen, for å forenkle utfyllingen. Dette spørsmålet har allerede vært sendt på en innspillsrunde til flere av leverandørene.

Konklusjon

Vi har kommet frem til at vi ikke vil fjerne dette punktet i første versjon av Ansako. Grunnene til dette er:

1. Forslaget vil bety en endring i blanketten. Blankettendringer må på en høringsrunde til kommunene, noe som betyr at vi ikke rekker det innen fristen for første versjon.

2. De ansvarlige søkere vi har snakket med ønsker å beholde punktet siden det gir dem nødvendig oversikt, og fordi det har en bevisstgjørende effekt særlig på utførende foretak.

Sentral godkjenning

Bakgrunn

Se eget blogginnlegg om sentral godkjenning her: Ansako og sentral godkjenning: Ber om innspill

Spørsmålet går i korte trekk ut på om vi skal be foretaket oppgi om den sentrale godkjenningen dekker ansvarsområdene én gang på slutten av erklæringen (ja/nei/delvis), eller om spørsmålet skal gjentas for hvert ansvarsområde (ja/nei).

Konklusjon

Vår foreløpige vurdering er at vi beholder datamodellen som den er, med et ja/nei-spørsmål for hvert ansvarsområde. Grunnen til dette er at:

• Vår referansegruppe for Ansako er tydelige på at de ønsker å beholde dagens løsning med vurdering av kompetansekrav per fagområde. De er innforstått med at dette medfører flere klikk for den som fyller ut erklæringen.

Innspillene som har kommet inn fra søknadssystemene har imidlertid ikke vært like entydige, så her tar vi gjerne imot kommentarer fra dere som ikke har uttalt dere ennå.

Øvrig om datamodell

Alle datamodeller med informasjon om noen endringer som allerede er gjort finner dere her: Datamodeller

Om dere har innspill som ikke er fanget opp i dokumentasjonen eller dette blogginnlegget, ber vi dere gi beskjed så snart som mulig.

I forbindelse med den nye løsningen for ansvarserklæringer, samsvarserklæringer og kontrollerklæringer, ønsker vi innspill på hvordan disse best mulig kan mottas (og utnyttes) i sak-/arkivsystemene.

Les mer og se datamodell for ANSAKO på dokumentasjonssiden.

Relevante endringer

• Mulig å signere flere ansvarsområder per firma, slik at det totale antallet innsendte erklæringer reduseres

• Lagt opp til at mer metadata følger hver erklæring, slik at det er mulig å identifisere hver linje i gjennomføringsplanen med den enkelte ansvarsretten (se gjennomføringsplanID)

Mottatte innspill

• Beholde filnavn, prefiks og dokumentkategori som i dag

• Ønske om strammere design av de signerte erklæringene (PDF-ene), slik at mer info kommer på samme side. Følger innspill fra UU og brukertesting.

Vi ønsker innspill og betraktninger rundt import, visning og gjenbruk av erklæringene. Send de gjerne direkte til servicedesken.

Vi har lagt inn Kart som lovlig vedleggstype for Søknad om ferdigattest. Bakgrunnen for endringen var et krav fra en kommune om at søker skulle legge ved en SOSI-fil.

Vi har gjort noen endringer vedrørende arbeidsflyts behandling av vedlegg fra tjenesten “Tiltakshavers samtykke til byggeplaner”.

Endringene er som følger:

Vedleggstypen “TiltakshaverSignatur” er lagt til innsendingstjenestene for v3 av “rammesøknad” og “søknad om tillatelse i ett trinn”

Arbeidsflyt er oppdatert slik at vi IKKE automatisk legger til PDF fra Altinn av tiltakshavers signerte samtykke hvis vi finner at dette allerede er lagt ved søknadene med vedleggstype “TiltakshaverSignatur”.

Dette gir søknadssystemet muligheten til å laste ned samtykket fra APIet til “tiltakshavers samtykke” og legge det ved eksplisitt. Hvis vedlegget ikke er med innsendingen, blir samtykke PDF lagt ved automatisk som før.

Dokumentasjonen er oppdater her:

Tiltakshavers samtykke til byggeplaner

Innledning

Vi jobber med å ferdigstille datamodellene for Ansako-tjenestene, og har lagt ut de første forslagene til datamodeller her: Datamodeller

I den forbindelse må vi gjøre en avklaring om spørsmål om sentral godkjenning i erklæring om ansvarsrett: skal vi beholde dagens modell, eller implementere et enklere alternativ?

Dagens modell

Dagens system for ansvarsrett har to felter for sentral godkjenning:

• harSentralGodkjenning: indikerer om foretaket er registrert med sentral godkjenning, en variabel på foretaksnivå

• dekkesOmraadeAvSentralGodkjenning: indikerer om det enkelte fagområde er dekket av foretakets sentrale godkjenning, et felt per fagområde i erklæringen

Fordelen ved dette alternativet er at vi kan beholde dagens logikk/datamodell. Det gir også mer informasjon om hva som dekkes av den sentrale godkjenningen enn alternativ 2 (under).

Ulempen ved løsningen er at den gir flere klikk for ansvarlig foretak.

Alternativ modell

Et alternativ er at å flytte spørsmålet om den sentrale godkjenningen dekker ansvarsområdet ut fra hvert ansvarsområde, til en generelt spørsmål på slutten. Her er en skisse for hvordan det kan se ut:

Ulempen ved løsningen er at det krever en endring i datamodellen, hvor spørsmålet om den sentrale godkjenningen dekker ansvarsområdene, flyttes til å være generelt. Vi må også håndtere tre alternativer og ikke bare ja/nei.

Fordelen ved løsningen er at det blir færre klikk og et enklere skjema for den som skal fylle ut ansvarsretten. Dagens papirblankett har dette oppsettet, så en endring til alternativ 2 må ikke på høring.

Innspill?

Vi ber søknadssystemene vurdere hvilket alternativ de ønsker, og eventuelle konsekvenser av en datamodellendring.

Innspill kan sendes til service desk på fellestjenesterbygg@dibk.no. Vi samler inn innspill fra søknadssystemer og Ansako-brukergruppe og vil informere om valget etter en samlet vurdering.

Release v21.9 deployes til Altinn Produksjon mandag 20. september i tidsrommet kl. 08:00-22:00. Tjenesteeiere vil ikke kunne sende eller motta data i tidsrommet kl. 20:00-21:00. Alle forsendelser i dette tidsrommet legges i kø og vil bli håndtert etter utført deploy. Forsendelser fra sluttbrukersystemer vil ikke bli påvirket og vil gå som normalt.

Les mer på: https://www.altinndigital.no/driftsmeldinger/

Fredag 10. september mellom kl 15:15 og 15:50 var SvarUt utilgjengelig. Dette medførte at 9 forsendelser til SvarUt ikke ble sendt. Vi tar kontakt med de berørte systemleverandørene for avklaring om det er behov for re-kjøring.

Bakgrunn

Fra tid til annen (men svært sjelden) sendes filer med så lange navn at forsendelsen feiler i SvarUt.

Filnavnet sendt fra Fellestjenester BYGG består av to elementer:

1. Filnavnet vi får fra søknadssystemet

2. Metadata som FtB arbeidsflyt legger på til eByggesak (opptil 46 tegn)

Om filnavnet sendt fra søknadssystemet + metadata fra FtB overstiger 226 tegn, blir hele søknaden avvist i SvarUt og får status Feil.

Anbefaling

Filer sendt til Fellestjenester BYGG skal ikke overstige 180 tegn, gjerne mindre for å være på den sikre siden.

Mer informasjon

Se all dokumentasjon om navngiving av vedleggsfiler her: Krav til navngiving av vedleggsfiler

Vi har fikset litt småtteri i Tiltakshavers samtykke til byggeplaner med fokus på å gjøre brukeropplevelsen bedre. Dette betyr at vi blant annet har:

• Fjernet en unødvendig meny

• Oppdatert brødsmulestien med rett tekster

• Lagt til en varslingstekst om at brukeren kommer til Altinn etter utlogging

• Lagt på logging

I tillegg er det lagt ut en varslingstekst om at tjenesten ikke fungerer i Safari. Dette vil vi se nærmere på etter hvert.

Endringene kom i prod 6. september 2021.

Les mer om Tiltakshavers samtykke til byggeplaner i det opprinnelige blogginnlegget.

eByggesakssystemene jobber med å implementere Nasjonale sjekklister for byggesak. Sjekklistene brukes blant annet av saksbehandlerne til registrering og oppfølging av mangler. DiBK har sammen med Arkitektum hatt møter med alle de tre leverandørene.

Sjekklistene er filtrert både på søknadstype og tiltak, for å unngå urelevante punkter.

Sjekklistepunkt

Sjekklistepunktene skal ha en automatisk sjekk, utsjekk eller vurderes av saksbehandler. Utfallet avgjør hva som blir oppfølgingen. Dette er fremstilt både på nettsidene våre og i API-et som eByggesakssystemene bruker.

Nettsidene viser i tillegg gyldighet og lovhjemler.

Maskinlesbare regler

Mange sjekkpunkt har nå maksinlesbare regler, og etter innspill kommer vi nå til å legge til en tekstlig fremstilling på dem. Slik blir det enklere å forstå hva som er hensikten med den enkelte regel.

Eksempler:

Mer informasjon kommer i dokumentasjonen og direkte til eByggesaksleverandørene så snart vi har ferdigstilt forklaringene.

Dokumentasjon

• Detaljert beskrivelse av tjenesten: Supplering av søknad

• Mottak av mangelbesvarelser i eByggesak: Mottak av mangelbesvarelser (Supplering av søknad) i eByggesakssystemene

Begrensninger i PDF-en

Vi har måttet fjerne listen over vedlegg og underskjema knyttet til hver mangel/ettersending fra PDF-en grunnet begrensninger i Infopath. Vi anbefaler likevel å sende dette med XML-en slik at eByggesakssystemene kan vise relevante dokumenter til hver mangel.

Godkjenning av søknadsløsning

Søknadssystemene må som vanlig demonstrere og få godkjent sin løsning før de kan gå i produksjon.

For å få godkjent Supplering av søknad, må søknadssystemet vise at det kan hente inn og svare ut strukturerte mangler fra API-et. Se dokumentasjon på API for mangelbrev her: API for Mangelbrev - anmodning om tilleggsinformasjon