Etter gode innspill i møter med leverandørene tidligere denne måneden har vi i dag publisert ny dokumentasjon til API-er for saksbehandlingsdata. Den største endringen går ut på at API for oppdatering er delt opp i flere spesialiserte API-er. Kodelista for Status/Milepæl endres og blir tettere knyttet opp mot API-ene. Mye av innholdet er ellers likt, men noen datafelter er endret.

Endringer i API-ene

For at API-ene og tilhørende validering skal være enkle å forvalte, ser vi behov for å dele API for oppdatering i flere, mer spissede API-er. API-kallene vil i hovedsak være utløst fra milepæler i saksbehandlingsløsningen, i tillegg til noen andre oppdateringer som påvirker søker.

Vi foreslår følgende API-er for saksbehandlingsdata:

API-er for oppdaterte milepæler:

• API for kvittering (v2)

• API for mangel (v2)

• API for vedtak (v2)

• API for oppdatert milepæl (nytt)

API-er for andre oppdateringer:

• API for endret saksnummer (nytt)

• API for saksoppdatering (nytt)

Kallene skal trigges ved oppdatering av milepæler i saksbehandlingssystemet, eller automatisk ved journalføring av innsending og ved en eventuell endring av saksnummer.

Les mer API-ene og tilhørende datamodeller her: Utkast 2: API-er for saksbehandlingsdata, v2

Endret kodeliste for status/milepæl

Forrige versjon av kodelista for status/milepæl blandet sammen ulike ting. Vi har derfor rendyrket kodelista til å kun inneholde milepæler vi mener skal omfattes av Fellestjenester BYGG, og knyttet API-ene tettere opp mot disse.

Les mer om milepælene som dekkes av FtB: Bruk av milepæler

Endring i datafeltene

I all hovedsak vil API-ene omfatte det samme innholdet som ble presentert i forrige runde. Vi foreslår imidlertid følgende endringer:

• Kodeliste for SoknadStatus er endret og erstattes med en kodeliste for milepælene vi mener dekkes i Fellestjenester BYGG.

• Strukturerte utfall sendes kun ved milepælene “Mangelbrev” eller “Vedtak fattet”, og begrenses til et gitt antall relevante utfall.

• Vedtak har fått ny objekt for VedtakStatus. Feltet følger kodeliste med godkjente statuser.

• Melding fjernes i de tilfellene det skal foreligge et formelt brev fra kommunen.

• I API for kvittering skal kommunen melde tilbake hvilke filer, med metadata, som er mottatt. Vi har endret navn til FilNavn, og lagt til MimeType og EkstraMetadata, slik at det samsvarer med informasjonen som ligger i SvarUt.

• Vi har lagt til saksnummer og saksansvarlig i alle API-ene, bortsett fra API for endret saksnummer.

• Saksbehandler har endret navn til Saksansvarlig og kan inneholde enten navnet til en saksbehandler, til en avdeling eller for eksempel et kundesenter.

• Vi har fjernet Journalår og Journalsekvensnummer fra Saksnummer. Dette er erstattet med Dokumentnummer, og kan brukes til for eksempel kobling til saksbehandlingsfase.

• AvsenderNavn og EkspedertDato er flyttet til Metadata.

• Vi har slått sammen oppdatering av søknadstype og oppdatering av tiltakstype i et nytt API for saksoppdatering.

Annen viktig informasjon

I innspillsmøtene har vi avklart følgende:

• API for kvittering sendes for hver innsending og ikke kun for hovedsøknaden.

• API for kvittering brukes når innsendingen er journalført i eByggesakssystemet. Systemene håndterer dette ulikt, og det kan derfor ta noe tid før kvittering og saksnummer sendes. Det er derfor viktig at søknadssystemene forventningsavklarer søker om at kvitteringen ikke kommer umiddelbart etter innsending.

• Oppdatering av milepæl sendes for hver innsending, og ikke for søknadsprosessen i sin helhet. Det vil si at for eksempel Søknad om igangsettingstillatelse og Supplering av søknad oppdateres på samme måte, men at søknaden/saken som helhet ikke oppdateres.

• API-ene skal ikke fange ikke opp uformell kommunikasjon, men skal dekke formelle utsendinger av brev og lignende.

• Svar tilbake til kommunen sendes som ettersending/mangelbesvarelse i Supplering av søknad eller ved å oppfylle vilkår og oppfølgingspunkt ved søknad om igangsetting, midlertidig brukstillatelse og ferdigattest.

• API for saksoppdatering krever at sjekklistene oppdateres til å gjelde for den nye tiltakstypen/søknadstypen. Dette må oppdateres både i søknadssystemene og i saksbehandlingssystemet, i tillegg til at sjekklistene må oppdateres.

• Endring av saksnummer kan forekomme, og blir sendt tilbake til søknadssystemet i et eget API. Det kan være at saken flyttes, deles opp eller slås sammen. Det er viktig at søknadssystemene oppdaterer saksnummer/saksnumrene basert på denne informasjonen. På sikt ønsker vi å komme frem til en standard oppdeling av saker som gjelder både fra søknadssystem og i mottakssystem, for å minimere behovet for slike endringer i ettertid. Det vil følges opp i et eget prosjekt.

• Vi har ikke landet på hvordan det utgående dokumentet fra kommunen skal leveres, eller hvilke felter objektet skal inneholde.

Vi har mottatt en henvendelse på service desken der søknaden feilet etter innsending, på grunn av at sjekklistene var nede.

Når vi mister kontakten med sjekklistene vil regelen be om informasjon for sjekklistepunkter i søknaden uten å kunne filtrere på tiltakstyper. Vi endrer derfor valideringsresultat fra WARNING til ERROR, for å forhindre at søknaden stopper etter innsending. Siden regelen blir strengere, varsler vi nå om at denne endringen kommer.

Valideringsregel

Regelen gjelder for

• Søknad om rammetillatelse (4397.0.1)

• Søknad om tillatelse i ett trinn (4528.0.1)

• Søknad om tillatelse til tiltak uten ansvarsrett (4373.0.1)

Søknadsløsningene trenger altså ikke endres, det er kun resultatet som endres. Hvis du har spørsmål, tar vi de gjerne i mot på service desk.

Digdir har varslet at testmiljøet er nede. De har lokalisert feilen, men det er sannsynlig at tjenesten er nede ut dagen.

Hendelsen gjør at testing i FtPB er utilgjengelig for de fleste tjenester, herunder innlogging på tt02 og ansako.

Dere kan følge status for hendelsen her: https://testmiljo.status.digdir.no/

En feil i en cache-tjenesten gjorde at sjekken mot SG-registeret sluttet å virke forrige fredag. Feilen gjelder forespørsler om erklæring om ansvarsrett som ble opprettet fredag 9. september mellom ca. kl. 06:12 og til kl. 13:40.

Feilen fører til at harSentralGodkjenning ble satt til false, både i GUI og den signerte PDF-en.

Det er grunn til å tro at mange ikke har oppdaget feilen og derfor signert ansvarsretter som feilaktig sier at foretaket ikke har sentral godkjenning. Vi ber søknadssystemer som ikke setter harSentralGodkjenning før sending til FtB om vurdere følgende tiltak:

1. Trekke alle ansvarsretter sendt i perioden, og sende disse ut på nytt

2. Vurdere om ansvarsretter som har blitt signert må slettes og hentes inn på nytt

Vi forstår at dette potensielt kan føre til mye arbeid med opprydning, og beklager hendelsen på det sterkeste. Vi utbedrer nå logging og varsling av cache-tjenesten så dette ikke skal skje igjen.

Altinn har for tiden en feil som gjør at alle skjema i Altinn feiler ved åpning. Dette gjør at blant annet naboer og berørte parter ikke får svart på nabovarsler og varsler om planoppstart.

Status for hendelsen kan følges her: https://www.altinndigital.no/driftsmeldinger/