Under følger en oversikt over datafelt som går igjen på tvers av API-ene, og hvilke felter som er obligatoriske for hvert API.

Feltene er merket med følgende fargekoder:

Dersom et felt ikke er merket, vil det si at feltet er frivillig å sende.

Felles datafelt

Under følger en oversikt over datafelt som blir brukt på tvers av API-ene:

Om feltene er obligatoriske eller frivillige, avhenger både av hvilke API-er som brukes og betingelser internt i det enkelte API-et.

Distribusjonstype for utgående dokument

Vi foreslår å opprette en ny kodeliste for distribusjonsmetode med følgende verdier:

• Fellestjenester BYGG

• SvarUt

• E-post

• Annen

Det er obligatorisk å velge distribusjonsmetode. Hver fil kan ha flere distribusjonsmetoder, for eksempel dersom dokumentet sendes både via SvarUt og tilgjengeliggjøres i FtB.

Hvis distribusjonsmetode er Fellestjenester BYGG, vil DokumentUrl være obligatorisk. Da vil en lenke mellomlagres i FtB frem til søknadssystemet har hentet dokumentet.

API for kvittering

Vi foreslår følgende validering ved utsending av kvittering for mottatt innsending:

For detaljert informasjon om validering av metadata, saksnummer og milepæl, se felles datafelt.

API for mangel

Vi foreslår følgende validering ved utsending av mangelbrev:

For detaljert informasjon om validering av metadata, saksnummer, milepæl og utgående dokument, se felles datafelt.

UtlostFraSjekkpunkt

For å kunne hente inn sjekkpunkt som ikke er lagt inn i Nasjonale sjekklister for byggesak, ønsker vi først å validere på sjekkpunktEier.

Dersom sjekkpunktEier er DiBK eller SSB, vil sjekkpunktID og SjekkpunktTittel være obligatorisk.

Dersom sjekkpunktEier er kommunen, vil det være frivillig å legge inn sjekkpunktID og sjekkpunktTittel.

Svarfrist

Vi foreslår å gjøre SvarFrist obligatorisk i API for mangel. Fristen skal angis i standard datoformat.

API for vedtak

Vi foreslår følgende validering ved utsending av vedtak:

For detaljert informasjon om validering av metadata, saksnummer, milepæl og utgående dokument, se felles datafelt.

SjekklisteUtfall

Det vil ikke alltid være utfall ved utsending av vedtak, derfor er bolken frivillig. Utfall skal sendes strukturert dersom det er vilkår eller oppfølgingspunkt.

UtlostFraSjekkpunkt

Se nærmere detaljer om logikken i valideringen her: API for mangel - Utlost fra sjekkpunkt.

API for oppdatert milepæl

Vi foreslår følgende validering ved utsending av informasjon om oppdatert milepæl:

For detaljert informasjon om validering av metadata, saksnummer og milepæl, se felles datafelt.

API for saksoppdatering

Vi foreslår følgende validering ved saksoppdatering:

For detaljert informasjon om validering av metadata, saksnummer og utgående dokument, se felles datafelt. Feltene skal kun oppdateres dersom det er noe nytt å melde i saken.

Utgående dokument

Utgående dokument er påkrevd dersom det er verdi i søknadstype. Endring skal alltid skje etter avtale mellom kommunen og ansvarlig søker, og dokumenteres med et utgående brev.

Søknadstype

Søknadstype skal kun sendes med API for saksoppdatering dersom søknadstypen endres fra ettrinnssøknad til rammesøknad. Vi vil derfor validere på at søknadstype er RS dersom feltet har verdi.

Dersom søknadstypen skal endres av andre grunner, for eksempel fra uten ansvarsrett eller fra ferdigattest til midlertidig brukstillatelse, oppfordrer vi til at kommunen avslår søknaden, og at en ny søknad sendes inn.

API for endring av saksnummer

Ved endring av saksnummer foreslår vi følgende validering:

For detaljert informasjon om validering av metadata, se felles datafelt.

Opprinnelig saksnummer og til saksnummer

Feltene OpprinneligSaksnummer og TilSaksnummer kan inneholde ett eller flere saksnummer. Ved splitting, vil det være ett OpprinneligSaksnummer og to eller flere TilSaksnummer, og det motsatte ved samling - mens det ved endring kan være én til én.