I utviklingsperioden har vi hatt en referanse ID på GUID formatet.

Ettersom vi har vurdert drift, sikkerhet, lesbarhet og brukerstøtte hensyn lurer vi nå på om vi skal gjøre en endring til en mer lesbar ID.

Ved oppretting av erklæringer returner vi en lenke til signering av erklæringen. Denne er det ønskelig å beholde slik som den er slik at man ikke kan gjette seg til URLen.

Vi returnerer også en referanseId som er samme GUID. Denne ønsker vi å oppdaterer til en mer lesbar ID lignende arkivreferansen i Altinn. Vi kan f.eks. bruke ANSAKO1337 (ANSAKO prefix med et løpenummer).

Denne IDen blir da også brukt til å hente informasjon via status APIene. Den blir også å finne på skjemaet. Vi tenker at dette gir oss et bedre utgangspunkt for brukerstøtte da en lesbar ID kan kommuniseres letter.

Responsen på opprettelse av en erklæring ser da slik ut:

{
    "formType": "ansvarsrett",
    "referanseId": "ANSAKO1234567", **** NYTT FORMAT PÅ ID ****
    "dataFormatId": "10000",
    "dataFormatVersion": "1",
    "formMetadata": {
        "signeringsfrist": "2021-09-30T23:59:59Z"
    },
    "ansvarsomraadeReferanser": [
        {
            "soeknadsystemetsReferanse": "20afb7d0-4ac5-4622-9e85-6978bd002cc1",
            "beskrivelseAvAnsvarsomraade": "Overordnet ansvar for kontroll",
            "anSaKoAnsvarsomraadeId": "5c89ba27-49e4-416f-887f-74345227b519"
        }
    ],
    "_links": {
        "utfylling_av_skjema": {
            "href": "https://ansako-test.dibk.no/skjema/a15dddc0-8576-459b-aece-7f33a62d7b33"
        }
    }
}

Spørsmålet til søknadssystemene er som dette er en endring som kan gjøres uten for store innvirkninger?

Datamodellene som brukes i Altinn inneholder en signatur bolk som settes automatisk at Altinn på det tidspunktet som Altinn skjemaet blir signert. Det er lagt til for at den Altinn genererte PDFen skal kunne ha informasjon om hvem som har signet innsendingen (som ligger på bunn av de fleste PDFen). Feltet/bolken ser ut som eksemplet under.

	<ns3:signatur>
		<ns3:signertAv>OLA NORDMANN på vegne av KARI NORDMANN BYGG AS</ns3:signertAv>
	</ns3:signatur>

I eSignering fungerer dette helt annerledes og signature bolken er ikke i bruk. Vi vurderte å oppdatere denne bolken i etterkant av utført signatur, men konkluderte at XMLen som ligger til grunn for det signerte dokumentet ikke skal endres i etterkant av signaturen.

For erklæringer signert med Ansako kommer signaturebolken i XMLen til å være tom. Dato og hvem som har signert fremkommer fra den signerte PDFen.

Vi ønsker innspill fra søknadssystemene om dette blir et problem ved mottak at signerte erklæringer.

Filstruktur

Den nåværende Altinn baserte tjenesten for kontrollerklæring tillater at selve erklæringen og vedlegget “PlanForUavhengigKontroll” signeres samtidig men består som to forskjellige filer .

I eSignering, når flere flere PDF filer skal signeres samtidig, blir det signerte dokumentet en enkelt PDF der erklæringen og vedlegget er kombinert inn i samme fil.

API tilgang

For å oppnå best mulig bakoverkompatibel på status og nedlastings APIene mellom Ansako og den Altinn baserte løsningen har vi valgt å legge til rette for at den signerte kombinerte filen blir lagt ut som hovedskjema og det usignerte vedlegget blir også tilgjengelig som en separat nedlastbar fil (sammen med XMLen som ligger til grunn for erklæringen).

   "Distribusjoner": [
        {
            "Distribusjonstype": "Kontrollerklæring",
            "Status": "receiptSent",
            "ReferanseIdSendt": "34212381",
            "Sendt": "2021-11-05T10:40:58.417",
            "ReferanseIdSignert": "AR10014182",
            "Signert": "2021-11-05T10:43:53.963",
            "ReferanseIdKvittering": "13408651",
            "SendtKvittering": "2021-11-05T10:45:10.15",
            "Filnedlastinger": [
                {
                    "Filbeskrivelse": "SkjemaPdf", **** SIGNERT KOMBI FIL ****
                    "FilURL": "https://test-admbygg.dibk.no/api/download/2231e781-9475-47ac-bcc0-014252336601/Kontrollerklaering.pdf",
                    "Mimetype": "application/pdf"
                },
                {
                    "Filbeskrivelse": "MaskinlesbarXml",   **** Erklæring XML ****
                    "FilURL": "https://test-admbygg.dibk.no/api/download/2231e781-9475-47ac-bcc0-014252336601/Kontrollerklaering.xml",
                    "Mimetype": "application/xml"
                },
                {
                    "Filbeskrivelse": "PlanForUavhengigKontroll",   **** USIGNERT VEDLEGGSFIL ****
                    "FilURL": "https://test-admbygg.dibk.no/api/download/2231e781-9475-47ac-bcc0-014252336601/Vedlegg1.B2133-01%20Ny%20plan%202.%20etasje.pdf",
                    "Mimetype": "application/pdf"
                }
            ],
            "AltinnInnboksMeldingsreferanse": "13408628"
        }
    ]

Status samsvar- og kontrollerklæring

Tjenestene for samsvarserklæring og kontrollerklæring er nå funksjonelle i forhold til å kunne sette opp erklæringene gjennom APIet, signerer i grensesnittet og hente ned status via status og download API.

Tjenestene er ikke ferdigstilt, men kan brukes for integrasjonstester for søknadssystem.

Etter innspill fra service desk har vi lagt til Uttalelse vedtak fra annen offentlig myndighet som gyldig vedlegg for Søknad om ferdigattest.

Endringen er ute i produksjon.

Onsdag 24.11.2021 slår vi på Basic Authentication på Ansako tjeneste API.

Autentiseringer er helt likt det som er satt opp på Status APIet, både på test og prod miljø.

Innlogging på ID-porten sluttet å fungere i løpet av helgen for våre testbrukere. Vi jobber med å få på plass nye, men inntil videre får vi låne Digdirs testbruker: 06120050239.

Engangskode og passord er det samme som for de gamle testbrukerne.

Ved innsending av kontrollerklæring i Altinn i dag, krever vi vedlegget Plan for uavhengig kontroll. Det følger av veiledningen til SAK 12-5 bokstav a at det skal sendes ved dokumentasjon av gjennomført kontroll.

For å gjøre det mer tydelig hva vedlegget skal inneholde, foreslår vår jurist å endre navnet på vedlegget til Dokumentasjon av gjennomført kontroll.

Alternativer

Vi ser følgende alternativer:

1. Beholde både kodeverdi og kodebeskrivelse slik det er i dag, og eventuelt oppdatere vedleggstypen senere

2. Legge til en ny vedleggstype i GeoNorge som beholder kodeverdien PlanForUavhengigKontroll, men med oppdatert kodebeskrivelse til Dokumentasjon av gjennomført kontroll

3. Legge til en ny vedleggstype i GeoNorge hvor både kodeverdi og kodebeskrivelse er oppdatert

Frist for innspill

Vi er jo som kjent i Ansako-sluttfasen og anerkjenner at søknadssystemene ikke har tid til store endringer. Vi ber derfor om tilbakemelding på hvorvidt alternativene over er noe som påvirker mottaket av kontrollerklæring i sluttbrukersystemene.

Frist for tilbakemelding er innen slutten av uka (19.11.21).

Dersom minst ett søknadssystem ønsker alternativ 1, vil dette måtte “trumfe” andre ønsker.

Introduksjon

Det er mye aktivitet på testing og service desk om Ansako for tiden, og det setter vi stor pris på! For å hjelpe søknadssystemene med å holde oversikt, legger vi her ut en oversikt over hvilke oppgaver vi jobber med, og en prioritering/plan for når vi vil løse problemet. Oversikten holdes oppdatert.

Meld gjerne fra til oss på service desk om dere savner noe på lista.

Oppgavene er delt opp i følgende kategorier:

Oversikt over oppgaver

1. Kritiske oppgaver (løses før 1. desember)

Dette er oppgaver vi mener må være løst før produksjonssetting 1. desember.

2. Viktige oppgaver

Dette er oppgaver vi mener bør være løst før de gamle distribusjonstjenestene stenges 1. januar 2022.

3. Middels viktige oppgaver

Dette er oppgaver vi mener kan vente til første halvdel av 2022. Det er ikke sikkert alle oppgavene vil bli løst.

Endringslogg

Vi har et problem med distribusjonstjenesten for ansvarsrett, samsvarserklæring og kontrollerklæring. Vi hotfikser produksjonsserveren nå og har slått av behandling av innsendinger noen minutter.

Saken oppdateres snart.

• 09:56 – Bug fiks er på veg ut i test. Vi validerer fiks nå

• 09:56 – Vi ser på omfanget av utsendelser som er problematiske. Distribusjoner har gått ut med det bel en feil i rapportering av status. Mer info kommer angående dette når vi har hotfiks på plass.

• 10:11 – fix validert i test, deployer til PROD nå

• 11:20 – prod behandling er skrud på igjen med bug fix på plass

• 10:52 – Vi kommer tilbake med mer data om omfanget. Vi har lagt til en beskrivelse av problemet under

• 13:01 – Altinn jobber med å slette innsendinger med feil status, i de tilfellende der dette er mulig

• 14:16 – Se nedenfor for en mulighet for å få håndterer besvarte erklæringer

• 18:27 – oppdatering rett nedenfor i “Opprydding”

Opprydding

Vi tar kontakt med søknadssystemene innen mandag med liste over distribusjoner, erklæringer som er sendt ut og erklæringer som er besvart fra ansvarlige foretak men er knyttet til en distribusjon som er markert som feil. Hvis noe trenger hjelp i løpet av helga så ta kontakt på service desk.

Forklaring av bug

• Distribusjonen har blitt mottatt som normalt

• Meldinger og pre-utfylte erklæringer er opprettet i Altinn

• Backend har samlet opp statusmeldinger

• En bug i rapportering av statusmeldinger har resultert i at hele distribusjonen er satt med status FEIL

Problemet

Det ligger mange erklæringer i ansvarlige søkers meldingsboks i Altinn som kan besvares men der søknadssystemet har oppfattet at innsendelsen har feilet.

Hva vi gjør

• Vi har fått oversikt over antall erklæringer (ca 600)

• Vi ser at noen ser ut til å ha blitt sendt mange ganger siden distribusjonene rapporterte feil, og noen meldingsbokser har blitt fylt opp med 30+ erklæringer.

• Vi har forespurt Altinn om de kan slette meldinger of preutfylte skjema der AF ikke har vært inne og sett at de har mottatt noe i Altinn.

• Vi ser også at noen erklæringer allerede er besvart, vi kommer tilbake med mer info og mulig fiks for dette.

• Vi beklager!

Besvarte erklæringer

Erklæringer som hører til en distribusjon som har feilet men er besvart kan kobles opp mot en annen distribusjon om ønskelig og om dette fungerer med flyten i systemet.

Vi kan bytte om på arkiv referansen for distribusjonen slik at den hører til en annen distribusjon og dukker opp i status APIet. Erklæringene er loget med eiendom, gnr/bnr, etc i våre metadata om dette er til hjelp.

Beskrivelse

Kvitteringstjenesten for nabovarsel har en feil som gjør at ikke alle naboer blir listet opp i visse tilfeller. Feilen ser ut til å ha vart siden 3. september, og 20 forsendelser er rammet.

Vi sender ut oversikt over forsendelsene det gjelder til berørte sluttbrukersystemer, sammen med oppdaterte kvitteringer.

Vi holder blogginnlegget oppdatert.

Logg

10.11.2021 kl. 14:48: Vi jobber med å generere kvitteringer og få ut en fiks i PROD.

11.11.2021 kl. 10:45: Alle oppdaterte kvitteringer er sendt til søknadssystemene. Vi har en fiks i testmiljøet som produksjonssettes i løpet av dagen om den består testene.

11.11.2021 kl. 15:05: Fiksen er lagt ut i produksjon.

Her er de siste oppdateringene i Ansako tjenesten

Brukertesting

I uke 43 og 44 ble det utført brukertesting fra ansvarlig foretaks sitt perspektiv. Grensesnittet for utfylling og signering av erklæring om ansvarsrett har blitt kontinuerlig oppdatert de to siste ukene.

Status

Statusbildet er oppdater:

Utviklingsstatus Ansako

Datamodeller

Datamodellene er modellert i Enterprise Architect.

Datamodeller - Ansako

Autentisering på tjeneste API

Vi har avgjort tjenesten blir prod satt med basic authentication på tjeneste APIet. Maskinporten blir lagt til senere.

Ansako Tjeneste-API

Validering

Test versjon av valideringstjeneste er tilgjengelig. Dokumentasjon her:

Ansako Valideringstjeneste

KS har lagt til en utvidelse av tilgjengelige metadata i forsendelsen til SvarUt, og vi ønsker innspill fra FtPB økosystemet om hvordan vi kan utnytte dette!

Utvidelse fra KS

Oppdateringen fra KS betyr at hver enkelt vedleggsfil i forsendelsen kan berikes med et “ekstra metadata”-felt som består av en liste med “key/value”-par.

Utvidelsen er tilgjengelig på REST-versjonen av API-et som er dokumentert her: https://ks-no.github.io/svarut/integrasjon/forsendelserestservicev1/

Dette betyr at hvert enkelt vedlegg i en innsendelse kan få sine egne metadata. Se eksempel på en innsendelse med underskjema og vedlegg:

Ekstra metadata på vedleggsnivå

Tabellen nedenfor viser noen potensielle metadata vi kan legge på hver fil for å styrke muligheten for digitalisering i kommunemottaket:

Vi minner om at vi i dag har tilgang til et “ekstra metadata”-felt per innsendelse, og at det blir brukt slik:

{
    "skjemaversjon.dokument.10": "6740.45751",
    "1_GBNR": "63/110/0/0",
    "skjemaversjon.dokument.7": "5797.42813",
    "klassering.1.GBNR": "63/110/0/0",
    "skjemaversjon.dokument.6": "6146.44096",
    "2_SID": "AR9992606",
    "klassering.2.SID": "AR9992606"
}

Innspill

Vi ønsker innspill på hvordan det er best å utnytte de ekstra mulighetene vi får i KS. Send dem til servicedesken eller samle dem til statusmøtene, slik at de kan diskuteres der.

Les mer om hvordan vedleggene er satt opp på denne siden.