| Tips |
|---|
Revidert forslag er lagt inn etter arbeidsgruppemøtet. Forslaget er publisert. Endringer vil komme etter diskusjoner med arbeidsgruppa 9. desember. |
Under følger en oversikt over valideringen av datafelt som går igjen på tvers av API-ene, og hvilke felter som er obligatoriske . Spesifikke valideringsregler er dokumentert på egne sider for hvert API.
| Innholdsfortegnelse | ||||
|---|---|---|---|---|
|
...
Om feltene er obligatoriske eller frivillige, avhenger både av hvilke API-er som brukes og betingelser internt i det enkelte API-et.
Felt | Beskrivelse |
|---|---|
Metadata | Obligatorisk for alle API-er. |
Saksnummer | Obligatorisk for alle API-er. |
Avsenders kontaktpunkt | Alltid frivillig å sende. |
Milepæl | Obligatorisk ved:
|
Saksbehandlingsfrist | Er frivillig for alle API-er i og med at fristen ikke alltid vil være satt ved API for kvittering. Feltet skal kun benyttes når ny eller oppdatert dato settes, som en følge av milepælene. Merk at søknadsleverandørene må være tydelig på at fristen kan endres underveis i saksbehandlingen siden den følger milepælene og saksbehandlingsfasene, slik at søker/tiltakshaver ikke oppfatter den som fastsatt. |
Utgående dokument | Obligatorisk ved følgende oppdateringer:
Kan være ett eller flere dokumenter/vedlegg. |
Melding | Alltid frivillig å sende. |
Distribusjonstype for utgående dokument
...
for utgående dokument
...
Vi foreslår å opprette en ny kodeliste for distribusjonsmetode med følgende verdier:
...
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
...
Spesifikk validering for hvert API
Kravtabeller og validering finnes på egne sider under hvert API: