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. Hvilke verdier kodelista skal inneholde, må diskuteres med arbeidsgruppa. Vi foreslår følgende verdier:

• Fellestjenester BYGG

• eInnsyn

• Offentlig postjournal

• SvarUt

• Altinn

• Digipost

• Brev

• Annet

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. Vi ønsker også at fristen kommer inn i et standardisert datoformat. Er det alltid mulig å velge en dato for SvarFrist i eByggesakssystemet, og hvilket format er fristen i?

OppfyllesTilFase

Vi foreslår at OppfyllesTilFase er obligatorisk ved følgende typer utfall:

• Mangel

• Mangel/pauser løpende tidsfrist

• Mangel/tidsfrist starter ikke

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]

OppfyllesTilFase

Vi foreslår at OppfyllesTilFase er obligatorisk ved følgende type utfall:

• Sett vilkår i vedtak

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

Vi har tidligere besluttet at søknadstype skal sendes i API for saksoppdatering dersom søknadstypen endres fra søknad til tillatelse i ett til to trinn. Riktig søknadstype blir i de tilfellene RS.

Vi lurer også på om det finnes andre tilfeller hvor søknadstype endres. Kan for eksempel saksbehandler endre fra ferdigattest til midlertidig brukstillatelse? Vil det i så fall påvirke kravet om utgående dokument?

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.