| Info |
|---|
Forslaget er publisert 30. november 2022. 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 | ||||
|---|---|---|---|---|
|
...
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.
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
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
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. 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
...
Spesifikk validering for hvert API
Kravtabeller og validering finnes på egne sider under hvert API: