ELRAPP REST-API

Skjemaer

Generell informasjon om innsending og oppdatering av skjemaer

Alle skjemaer som sendes inn via dette APIet vil få den samme objekttypen i JSON-format returnert, både ved POST- og PUT-kall. Det er viktig at man tar vare på ID-en som returneres for å kunne gjøre fremtidige endringer på et skjema.

For at vi skal kunne beholde historikken for innsendte skjemaer endrer vi ikke de eksisterende skjemaene, men oppretter nye skjemaer med likt referansenummer, men med inkrementerende versjonsnummer. Ved å gjøre det på denne måten kan vi til enhver tid se nøyaktig hvordan en eldre versjon av et skjema så ut, selv om det er gjort endringer i nye versjoner.

For at dette skal fungere gir vi hver versjon av et skjema en unik ID. Dette er ID-en som settes i ID-feltet i returobjektet i POST og PUT-kallene. Dersom denne ID-en ikke er satt korrekt i DTOen man sender inn når man forsøker å oppdatere et skjema, vil ikke systemet være i stand til å knytte det innsendte skjemaet med en tidligere versjon.

Feltet Emne er ikke et obligatorisk felt, men vi anbefaler at det settes i de fleste tilfeller. Hvis det ikke settes så vil det bli generert et eget emne felt ved innsending/oppdatering. Maks tillatt lengde på Emne er 300 tegn. (Gjelder ikke R18, R20, da Emne er et obligatorisk felt i dette skjemaet)

I tillegg til dette må feltet oppdatertAv også fylles ut dersom man oppdaterer et skjema.

Eksempel på returnobjekt ved POST og PUT:

{
  "id": 123456,                 // Skjemaets id - Dette er IDen man MÅ ta vare på.
  "lopeNr": 1,                  // Skjemaets løpenummer i ELRAPP.
  "versjonNr": null,            // Skjemaets versjonsnummer i ELRAPP, inkrementeres ved PUT-kall.
  "emne": "R5-1-EV6 S1D1 m1234" // Generert emne i ELRAPP.
}

Vegreferanser

R2, R5, R11 og Avvik er skjema som krever at det spesifiseres en eller flere vegreferanser. Dette gjøres ved å oppgi en veglenke og en relativ posisjon. Når skjema sendes inn eller blir oppdatert så gjøres det ett oppslag mot NVDB fra ELRAPP basert på veglenke og relativposisjon. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding. Meldingen vil prøve å spesifisere hva feilen er men det kan også være tilfeller der det blir returnert en generell feilmelding.

R2 Innsending

Beskrivelse av endepunkter og modeller tilknyttet R2 Skjema innsending.

Endringslogg

DatoEndring
17.11.2023Lagt til endepunkte for uthenting av R2

Api versjon

R2 er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Metadata

I R2 skjemaet så skal det fylles ut en del statiske verdier, disse statiske verdiene henter man fra dette endepunktet.

For å få de kontraktspesifikke prosessene, må kontraktId sendes inn som et query-parameter i spørringen.

GET /skjema/r2/metadata HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

Innsending av R2

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved innsending av et R2 skjema er følgende felt påkrevd: sendtAv og vegreferanse.

Emne kan enten settes av bruker eller så blir det satt automatisk i ELRAPP ved innsending og returnert i responsen.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

Eksempel på kall

POST /kontrakt/{kontraktId}/skjema/r2 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
    "sendtAv": "TestBruker1",     // gyldig ELRAPP bruker skjema er sendt på vegne av, ikke servicebrukeren som sender skjema.
    "emne": "emne",               //maks 300 tegn
    "sted": "Teststedsnavn",      //Stedet for hendelsen, max 255 tegn
    "datoMottatt": "2020-12-10T00:00:00", //Registrert dato og klokkeslett
    "kommentar": "Kommentar",    //maks 500 tegn
    "utbedret": false,           // Utbedret status
    "datoUtbedret": "2020-12-10", // dato utbedret
    "planlagtUtbedret": "2020-12-11",// dato planlagt utbedret
    "vegreferanse": {
      "veglenke": 320513,            // Veglenkesekvensid
      "relativPosisjon": 0.11932794, //Relativ posisjon på veglenkesekvensid
    },
    "aarsakId": 2,      // fra R2 Metadata. id fra aarsaker[]
    "utbedringAvId": 0, // fra R2 Metadata  id fra utbedringer[]
    "prosessId": 12,    // fra R2 Metadata. id fra prosesser[]
    "avvikId": 334,     // fra R2 Metadata. id fra avvik[]. bruk kun id'er som har samme prosessId
    "objektId": 227,    // fra R2 Metadata. id fra objekter[]. bruk kun id'er som har samme prosessId
    "vedlegg": [ //Gyldige filformater er: "jpeg","jpg","png" og "tif". Vedleggene kan ikke overskride 50MB
    {
      "filnavn": "test1.jpeg",
      "contentType": "image/jpeg",
      "vedlegg": "ZGVhZGJlZWY=" // Dette feltet må være satt til en gyldig base64 string
    }
  ]
}

Kallet returnerer ett objekt med id som brukes ved oppdatering

{
    "id": 123123,      // skjemaets id
    "lopeNr": 5,       // elrapp løpenummer
    "versjonNr": null  // elrapp versjonsnummer
    "emne": "FV242: 78.2 Skilt" // Generert emne i elrapp
}

Oppdatering og innsending av ny versjon

Trykk her dersom du ikke allerede har lest den generelle informasjonen om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved oppdatering av et R2 skjema er det viktig at id og oppdatertAv feltet også sendes inn.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

PUT /kontrakt/{kontraktId}/skjema/r2?id=5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0


{
  "id": 1234, //id som ble returnert i tidligere POST eller PUT kall
  "oppdatertAv": "Testbruker" // gyldig ELRAPP bruker skjema er oppdatert på vegne av, ikke servicebrukeren som sender skjema.
  ...
}

R2 Uthenting

Beskrivelse av endepunkter og modeller tilknyttet R2 Skjema

Api versjon

R2 er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

Endepunkter

Uthenting av R2 skjemaer

GET /kontrakt/{kontraktId}/skjema/r2 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

For å liste ut R2 skjemaer kan man kalle GET-endepunktet som beskrevet i Endepunkter. GET-endepunktet har fem query-parametere. Disse er fraLopenummer, lopenummer, dato, datoFra og datoTil.

Dersom man kaller endepunktet uten parametere vil man få returnert alle skjemaene på den gjeldende kontrakten med den siste/nyeste versjonen av hvert skjema. Legger man til fraLopenummer til f. eks. 123 vil man motta alle skjemaer som er sendt inn fra den lopenummer f. eks. 123 og opp til den siste som er registrert.

For å hente skjemaer basert på løpenummer kan man sette lopenummer til f. eks. 123. Da mottar man den siste/nyeste versjonen av skjemaet med løpenummer 123. Gir man dato som f. eks. 2016-03-10 , vil man hente alle skjemaer som er sendt inn på den datoen. Setter man både datoFra og datoTil, vil man får aller skjemaer som er sendt inn mellom og like de datoene.

Merk at selv om man bare mottar ett skjema om gangen når man bruker lopenummer mottar man en liste med kun ett element, og ikke selve elementet.

Vedlegg er alltid inkludert men som en liste av linker som kan bli brukt til å hente ned vedleggene.

R5 Innsending

Beskrivelse av endepunkter og modeller tilknyttet R5 skjemainnsending.

Endringslogg

DatoEndring
17.11.2023Lagt til versjon 2 av uthenting for R5

Api versjon

R5 er et versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt-id hentes ut under kontraktinfo ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Metadata

I R5 skjemaet skal det fylles ut en del statiske verdier. Disse statiske verdiene henter man fra dette endepunktet.

GET /skjema/r5/metadata HTTP/1.1
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

Innsending av R5

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved innsending av et R5 skjema er følgende felt påkrevd: sendtAv og vegreferanse. Det er også påkrevd at enten skadeDato eller antattSkadedatoFra og antattSkadedatoTil er fylt ut.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

Slik ser DTOen for et R5-skjema ut.

POST /kontrakt/{kontraktId}/skjema/r5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

{
  "sendtAv": "TESTBRUK",                              // gyldig ELRAPP-bruker skjema er sendt på vegne av, IKKE servicebrukeren som sender skjema.
  "emne": "emne",                                     //maks 300 tegn.
  "skadested": "Skadevik",                            // Stedet skaden har skjedd. maks 50 tegn
  "skadedato": "2021-06-25T00:00:00.000Z",            // Dato og tid for skaden.
  "antattSkadedatoFra": null,                         // Antatt fradato i tidsrom for skade.
  "antattSkadedatoTil": null,                         // Antatt tildato i tidsrom for skade.
  "oppdagetDato": "2021-07-08T12:34:56.000Z",         // Dato for når man oppdaget skaden.
  "oppdagetAv": "TESTBRUK",                           // Innmelders brukernavn eller Navn på annen person som oppdaget skaden. maks 50 tegn
  "snobroyting": false,                               // Skyldes skaden snøbrøyting innenfor kontraktsarbeid?
  "skadeBeskrivelse": "Ødelagt kantstolpe.",          // Beskrivelse av skaden. maks 500 tegn
  "kostnadNok": 8000,                                 // Kostnad for reparasjon av skaden i NOK.
  "reparasjonDato": "2021-09-01T11:00:00.000Z",       // Dato da skaden ble reparert.
  "reparasjonstype": null ,                           // Hentes fra metadata 'reparasjonstyper', skal kun settes når skaden ikke har blitt utbedret.
  "vegreferanse": {
    "veglenke": 1110314,                               // Veglenkesekvensid
    "relativPosisjon": 0.02                            // Relativ posisjon på veglenkesekvensid
  },
  "skadevolderIkkeKjentKommentar": null,              // Kommentar ved ukjent skadevolder, maks 500 tegn
  "skadevoldere": [ // Liste over skadevoldere
    {
      "kjoretoy": "AB12345",                          // Dette feltet er obligatorisk dersom 'kommentar' ikke er fylt ut. Registreringsnummeret på bilen til skadevolder. maks 15 tegn
      "landkode": "NO",                               // Dette feltet er obligatorisk dersom 'land' ikke er fylt ut. Landet skadevolder er fra. ( ISO_3166-1_alpha-2. e.g NO for norge , SE for sverige ).
      "land": "NO",                                   // Dette feltet er obligatorisk dersom 'landkode' ikke er fylt ut. maks 50 tegn
      "kommentar": "Bilen som kjørte ned skiltet."    // Dette feltet er obligatorisk dersom 'kjoretoy' ikke er fylt ut. Kommentar om skadevolder. maks 500 tegn
    }
  ],
  "kontakter": [  // Liste over kontaktpersoner
    {
      "avdeling": "Test PolitiKammer",                // Hvor hører kontaktpersonen til. maks 50 tegn
      "kontaktperson": "Per Politi",                  // Navn på kontaktperson. maks 50 tegn
      "kommentar": "Politimannen som ble kontaktet.", // Kommentar om kontaktperson. maks 500 tegn
      "typeId": 51                                    // Id til type kontaktperson. Hentes fra R5 Metadata. Id fra Kontakttyper[].
    }
  ],
  "vedlegg": [  // Gyldige filformater er "png","jpeg","jpg","tif","pdf","doc","docx","xls","xlsx","htm","html","msg","sos","mpp","mppx","rtf","ppt","pptx","txt".  Vedleggene kan ikke overskride 50MB.
    {
      "filnavn": "test1.jpeg",
      "contentType": "image/jpeg",
      "vedlegg": "ZGVhZGJlZWY=",                      // Dette feltet må være satt til en gyldig base64 string.
      "kategoriId": 48                                // Id til kategorien man ønsker på bildet. Hentes fra R5 Metadata. Id fra VedleggKategorier[].
    }
  ]
}

Oppdatering og innsending av ny versjon

Trykk her dersom du ikke allerede har lest den generelle informasjonen om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved oppdatering av et R5 skjema er det viktig at id og oppdatertAv feltet også sendes inn.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

PUT /kontrakt/{kontraktId}/skjema/r5?id=5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
  "id": 1234, //id som ble returnert i tidligere POST eller PUT kall
  "oppdatertAv": "Testbruker" // gyldig ELRAPP bruker skjema er oppdatert på vegne av, ikke servicebrukeren som sender skjema.
  ...

R5 Uthenting

Beskrivelse av endepunkter og modeller tilknyttet R5 skjema.

Api versjon

R5 er et versjonert endepunkt og det er viktig at man setter header Ver til 1.0 eller 2.0 som vist i eksemplene.

Endepunkter

Uthenting av R5 skjemaer

GET /kontrakt/{kontraktId}/skjema/r5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

For å liste ut R5 skjemaer kan man kalle GET-endepunktet som beskrevet i Endepunkter. GET-endepunktet har fire query-parametere. Disse er fraId, lopenummer, versjon, og inkluderVedlegg.

Dersom man kaller endepunktet uten parametere vil man få returnert alle skjemaene på den gjeldende kontrakten. Legger man til fraId vil man motta alle skjemaer som er sendt inn etter skjemaet med id som er lik fraId. inkluderVedlegg er et heltall som settes til 0 dersom man ikke ønsker vedlegg, eller til et tall større enn 0 dersom man ønsker vedlegg. For at man skal kunne motta vedlegg må man ha fylt ut BÅDE fraId og inkluderVedlegg.

For å hente skjemaer basert på løpenummer kan kan man sette lopenummer til f. eks. 123. Da mottar man den siste/nyeste versjonen av skjemaet med løpenummer 123. Gir man derimot versjon en tallverdi som f. eks. 2, vil man hente skjema med løpenummer 123 og versjonsnummer 2. Dersom det ikke eksisterer et skjema med løpenummer 123 og versjonsnummer 2 vil man få en feilmelding om at skjemaet ikke finnes. Versjoneringen av skjemaer starter på 0. Det vil si at dersom du ønsker å hente den aller første versjonen av et skjema skal man be om versjon 0. Versjon 1 er dermed den første endrede versjonen av skjemaet.

Merk at selv om man bare mottar ett skjema om gangen når man bruker lopenummer mottar man en liste med kun ett element, og ikke selve elementet.

Når et R5 skjema blir sendt inn til ELRAPP så blir det lagt på kommunenavn og kommunenummer. Dette blir hentet ut fra NVDB basert på vegreferansen som knyttet til skjemaet. Dette er verdier som kan bli hentet ut ved uthenting av R5 skjema. Verdiene vil være i feltene kommuneNr og kommuneNavn. kommuneNr er et heltall og kommuneNavn er et tekst felt. Begge feltene kan ha verdien null. Det eksisterer også et felt med navn sted, dette feltet vil inneholde navn på stedet vegreferansen er knyttet. Verdien i feltet vil være null siden dette ikke er implementert enda.

Uthenting av R5 skjemaer (V2)

GET /kontrakt/{kontraktId}/skjema/r5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 2.0

R5 Uthenting

Beskrivelse av endepunkter og modeller tilknyttet R5 skjema.

Api versjon

R5 er et versjonert endepunkt og det er viktig at man setter header Ver til 1.0 eller 2.0 som vist i eksemplene.

Endepunkter

Uthenting av R5 skjemaer

GET /kontrakt/{kontraktId}/skjema/r5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

For å liste ut R5 skjemaer kan man kalle GET-endepunktet som beskrevet i Endepunkter. GET-endepunktet har fire query-parametere. Disse er fraId, lopenummer, versjon, og inkluderVedlegg.

Dersom man kaller endepunktet uten parametere vil man få returnert alle skjemaene på den gjeldende kontrakten. Legger man til fraId vil man motta alle skjemaer som er sendt inn etter skjemaet med id som er lik fraId. inkluderVedlegg er et heltall som settes til 0 dersom man ikke ønsker vedlegg, eller til et tall større enn 0 dersom man ønsker vedlegg. For at man skal kunne motta vedlegg må man ha fylt ut BÅDE fraId og inkluderVedlegg.

For å hente skjemaer basert på løpenummer kan kan man sette lopenummer til f. eks. 123. Da mottar man den siste/nyeste versjonen av skjemaet med løpenummer 123. Gir man derimot versjon en tallverdi som f. eks. 2, vil man hente skjema med løpenummer 123 og versjonsnummer 2. Dersom det ikke eksisterer et skjema med løpenummer 123 og versjonsnummer 2 vil man få en feilmelding om at skjemaet ikke finnes. Versjoneringen av skjemaer starter på 0. Det vil si at dersom du ønsker å hente den aller første versjonen av et skjema skal man be om versjon 0. Versjon 1 er dermed den første endrede versjonen av skjemaet.

Merk at selv om man bare mottar ett skjema om gangen når man bruker lopenummer mottar man en liste med kun ett element, og ikke selve elementet.

Når et R5 skjema blir sendt inn til ELRAPP så blir det lagt på kommunenavn og kommunenummer. Dette blir hentet ut fra NVDB basert på vegreferansen som knyttet til skjemaet. Dette er verdier som kan bli hentet ut ved uthenting av R5 skjema. Verdiene vil være i feltene kommuneNr og kommuneNavn. kommuneNr er et heltall og kommuneNavn er et tekst felt. Begge feltene kan ha verdien null. Det eksisterer også et felt med navn sted, dette feltet vil inneholde navn på stedet vegreferansen er knyttet. Verdien i feltet vil være null siden dette ikke er implementert enda.

Uthenting av R5 skjemaer (V2)

GET /kontrakt/{kontraktId}/skjema/r5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 2.0

For å liste ut R5 skjemaer kan man kalle GET-endepunktet som beskrevet i Endepunkter. GET-endepunktet har fem query-parametere. Disse er fraLopenummer, lopenummer, dato, datoFra og datoTil.

Dersom man kaller endepunktet uten parametere vil man få returnert alle skjemaene på den gjeldende kontrakten med den siste/nyeste versjonen av hvert skjema. Legger man til fraLopenummer til f. eks. 123 vil man motta alle skjemaer som er sendt inn fra den lopenummer f. eks. 123 og opp til den siste som er registrert.

For å hente skjemaer basert på løpenummer kan man sette lopenummer til f. eks. 123. Da mottar man den siste/nyeste versjonen av skjemaet med løpenummer 123. Gir man dato som f. eks. 2016-03-10 , vil man hente alle skjemaer som er sendt inn på den datoen. Setter man både datoFra og datoTil, vil man får aller skjemaer som er sendt inn mellom og like de datoene.

Merk at selv om man bare mottar ett skjema om gangen når man bruker lopenummer mottar man en liste med kun ett element, og ikke selve elementet.

Vedlegg er alltid inkludert men som en liste av linker som kan bli brukt til å hente ned vedleggene.

Uthenting av R5 skjemaer med gamle vegreferanser

GET /kontrakt/{kontraktId}/skjema/r5/gammel HTTP/1.1
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

For å hente R5-skjemaer på gammelt format med vegreferanse V2 må man kalle dette endepunktet. GET-endepunktet har tre query-parametere. Disse er lopenummer, versjon, og inkluderVedlegg. Av disse parameterene er lopenummer obligatorisk.

For å hente et skjema kan kan man sette lopenummer til f. eks. 123. Da mottar man den siste/nyeste versjonen av skjemaet med løpenummer 123. Gir man derimot versjon en tallverdi som f. eks. 2, vil man hente skjemaet med løpenummer 123 og versjonsnummer 2. Dersom det ikke eksisterer et skjema med løpenummer 123 og versjonsnummer 2 vil man få en feilmelding om at skjemaet ikke finnes. Versjoneringen av skjemaer starter på 0. Det vil si at dersom du ønsker å hente den aller første versjonen av et skjema skal man be om versjon 0. Versjon 1 er dermed den første endrede versjonen av skjemaet.

Dette endepuktet returnerer alltid kun ETT enkelt skjema.

R11 Innsending

Beskrivelse av endepunkter og modeller tilknyttet R11 Skjema innsending.

Endringslogg

DatoEndring
17.11.2023Lagt til endringslogg

Api versjon

R11 er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Metadata

I R11 skjemaet så skal det fylles ut en del statiske verdier, disse statiske verdiene henter man fra dette endepunktet.

GET /skjema/r11/metadata HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

Både "R11BeskrivelseLoesneomraadetId" og "R11HoeydeForskjellId" har en avhengighet mot skredtype. Under hver skredtype så ligger det en liste med gyldige id'er for både "R11BeskrivelseLoesneomraadetId" og "R11HoeydeForskjellId". Eksempel: Stein er valgt som skredtype. Stein ser slik ut:

{
  "id": 1,
  "navn": "Stein",
  "skredaarsaker": [
    {
      "id": 1,
      "navn": "Regn og smeltevann"
    },
    {
      "id": 2,
      "navn": "Fryse- og tineprosesser"
    },
    ...
  ],
  "gyldigeR11BeskrivelseLoesneomraadetIds":[
    24, 25, 26, 27
  ],
  "gyldigeR11HoeydeForskjellIds": [
    12, 13, 15, 42, 43, 44
  ]
}

Dette vil si at R11BeskrivelseLoesneomraadetId må ha en av disse verdiene: 24, 25, 26, 27 Dette vil også si at R11HoeydeForskjellId må ha en av disse verdiene: 12, 13, 15, 42, 43, 44

Innsending av R11

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved innsening av R11 har man muligheten til å sende inn enten skred-skjema eller skredfare-skjema. Dette valget tas når man setter feltet SkjemaType. Om man sender inn skredfare er det kun feltet R11Vegstenginger som er påkrevd. Om det er skred som sendes inn så er sendtAv, skredDato, skredtypeId, fraVegreferanse, og tilVegreferanse påkrevd. Enten det er skred eller skredfare og det er en vegstenging på skjemaet så er alle feltene under R11Vegstenginger påkrevd

Emne kan enten settes av bruker eller så blir det satt automatisk i ELRAPP ved innsending og returnert i responsen.

Feltet sendtAv er obligatorisk når skjema sendes inn første gang. Når et skjema oppdateres så er feltet oppdatertAv obligatorisk mens sendtAv er ikke obligatorisk.

Skredårsak er avhengig av skredtype. Avhengigheten kan sees i metadatene hvor hver skredtype har en liste med gyldige skredårsaker.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

Eksempel på avhengighet mellom skredtype og skredårsak. De skredårsakene som kan velges er de som ligger i skredtypens tilhørende liste av skredårsaker.

"r11Skredtyper": [
    {
      "id": 1,
      "navn": "Stein",
      "skredaarsaker": [
        {
          "id": 1,
          "navn": "Regn og smeltevann"
        },
        {
          "id": 2,
          "navn": "Fryse- og tineprosesser"
        },
        ...
      ]
    },
    {
      "id": 2,
      "navn": "Jord/løsmasse",
      "skredaarsaker": [
        {
          "id": 1,
          "navn": "Regn og smeltevann"
        },
        {
          "id": 7,
          "navn": "Undergraving av skråningsfot"
        },
        ...
      ]
    },
    ...
]

Innsendingen av skred sender også skjemaet til regobs. Det sendes inn som jordskred om SkredtypeId er satt til:1 (stein), 2 (jord/løsmasse), 3 (flomskred), 6 (is/stein), 7 (sørpeskred), eller 8 (utglidning av veg). Det sendes inn som snøskred om skredtype er satt til 4 (snø).

Ved innsending av vegreferanser må tilhørende til- og fra-vegreferanse være på samme veg. Om de har samme veglenkesekvensid så må til ha større relativ-posisjon enn fra.

POST /kontrakt/{kontraktId}/skjema/r11 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
    "Id": 0, //unik id for skjemaet som settes av ELRAPP på innsending, ved oppdatering så skal denne være satt med id man har fått i retur fra tidligere POST eller PUT
    "SkjemaType": "SKRED", //To gyldige verdier; "SKREDFARE" og "SKRED". Ved skredfare er kun R11Vegstenginger påkrevd.
    "emne": "emne", //maks 300 tegn
    "SendtAv": "TestBruker", //gyldig ELRAPP bruker skjema er sendt på vegne av, ikke bruker som sender skjema
    "Tileggsinformasjon": "string", //Ekstra informasjon om skredet, ikke påkrevd. Maks 500 tegn
    "Sted": "Teststedsnavn", //Stedet skredet hendte, maks 255 tegn
    "SkredDato": "2020-01-31T00:00:00", //Hendelsesdato og klokkeslett
    "Felt": "string", //Side av veg skredet hendte; "V" for venstre og "H" for høyre
    "Skredstoerrelse": 0, //Anslag på totalt skredvolum (m3)
    "R11SkredmasseId": 0, // Hentes fra metadataobjektet R11Skredmasser
    "R11HoeydeForskjellId": 0, //Hentes fra metadataobjektet R11HoydeForskjeller
    "R11BeskrivelseLoesneomraadetId": 0, //Hentes fra metadataobjektet R11BeskrivelseLoesneomraadetVerdier
    "R11BlokkertVeglengdeId": 0, //Hentes fra metadataobjektet R11BlokkertVeglengder
    "SkredtypeId": 0, //Hentes fra metadataobjektet R11Skredtyper
    "SkredaarsakId": 0, //Hentes fra valgt R11Skredtype hvor det er en liste av skredaarsaker
    "FraVegreferanse": {
      "Veglenke": 0, // Veglenkesekvensid
      "RelativPosisjon": 0, //Relativ posisjon på veglenkesekvensid
  },
    "TilVegreferanse": {
      "Veglenke": 0, // Veglenkesekvensid
      "RelativPosisjon": 0, //Relativ posisjon på veglenkesekvensid
    },
    "R11Skader": [
      {
        "Id": 0, //Hentes fra metadataobjektet R11Skader
      }
    ],
    "Stengning": "string", // Tre gyldige verdier: Y=ja, N=nei og S=vegen allerede stengt.
    "R11Vegstenginger": [ //Kan kun inneholde verdier om stegning er "Y", eller om skjemaType er "SKREDFARE"
    {
      "StengtFraDato": "2020-01-31T00:00:00",
      "StengtTilDato": "2020-01-31T00:00:00",
      "R11StegningTypeId": 0, //Hentes fra metadataobjektet R11StegningTyper
      "R11StengtRetningId": 0, //Hentes fra metadataobjektet R11StengtRetningVerdier
      "FraVegreferanse": {
        "Veglenke": 0, // Veglenkesekvensid
        "RelativPosisjon": 0, //Relativ posisjon på veglenkesekvensid
      },
      "TilVegreferanse": {
        "Veglenke": 0, // Veglenkesekvensid
        "RelativPosisjon": 0, //Relativ posisjon på veglenkesekvensid
      }
    }
  ],
     "Vedlegg": [ //Gyldige filformater er: "jpeg","jpg","png" og "tif". Vedleggene kan ikke overskride 50MB
    {
      "filnavn": "test1.jpeg",
      "contentType": "image/jpeg",
      "vedlegg": "ZGVhZGJlZWY=" // Dette feltet må være satt til en gyldig base64 string
    }
  ]
}

Kallet returnerer ett objekt med id som brukes ved oppdatering

{
    "id": 123123,      // skjemaets id
    "lopeNr": 5,       // elrapp løpenummer
    "versjonNr": null  // elrapp versjonsnummer
    "emne": "FV242: 78.2 Skilt" // Generert emne i elrapp
}

Oppdatering og innsending av ny versjon

Trykk her dersom du ikke allerede har lest den generelle informasjonen om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved oppdatering av et R11 skjema er det viktig at id og oppdatertAv feltet også sendes inn.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

PUT /kontrakt/{kontraktId}/skjema/r11?id=5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
  "id": 1234, //id som ble returnert i tidligere POST eller PUT kall
  "oppdatertAv": "Testbruker" // gyldig ELRAPP bruker skjema er oppdatert på vegne av, ikke servicebrukeren som sender skjema.
  ...

R15 Innsending (alpha)

Beskrivelse av endepunkter og modeller tilknyttet R15 Skjema innsending.

NB! Dette er under utvikling og er kun operativ i STM og ATM. Det kan komme endringer i funksjonalitet!

Endringslogg

DatoEndring
17.11.2023Lagt til api for innsending, overskriving og uthenting av R15 avfall

Api versjon

R15 er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Metadata

R15 skjema må fylles ut med en del statiske verdier, disse statiske verdiene henter man ut fra dette endepunktet.

Kontrakt og år må oppgis ettersom noen av metadataene settes for hvert år på kontrakten.

Datane man får fra endepunktet er ns koder(Norsk standard) som blir brukt til å spesifisere avfall/masse. Opphav som sier noe om hvor avfall/massene kommer fra, og disponeringsmåter som sier noe hvordan avfallet/massene har blitt håndtert. Hvis ns koder ikke har blitt spesifisert på kontrakten i ELRAPP for året så vil det ikke være noen ns koder i uttrekket. I dette tilfellet så må bruker ta kontakt med byggeleder å be dem legge til avfallskoder for året.

NB! Dette er under utvikling og er kun operativ i STM og ATM. Det kan komme endringer i funksjonalitet!

GET /kontrakt/{kontraktId}/skjema/r15/metadata?ar={år} HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0
Metadata i dagens løsning

Ns koder (viser kun noen ettersom disse er spesifikke for kontrakt og år)

IdBeskrivelseKodeUnderkode
1Asfalt1619null
109Gips1615null
288Rene masser1601null
326Rene steinmasser16011

Opphav

IdVerdi
202Anleggsområde
203Eksisterende veg
204Sideområde

Disponeringsmåter

IdVerdi
197Levert direkte til gjenvinning
198Levert direkte til gjenvinning til utfyllingsformål/teknisk formål, eks. betong/tegl
199Levert direkte til ombruk
200Levert til forberedelese til ombruk
201Levert til godkjent avfallsmottak

Uthenting

Det er mulig å hente ut data som har blitt sendt inn. Dette gjøres med endepunktet beskrevet under med parametrene år og måned. Måned er ikke obligatorisk. Hvis måned ikke sendes med som parameter så hentes data kun ut på år. I eksempelet under vises data der kun år har blitt sendt som parameter. I begge tilfeller så blir det returnert en lista av data, og hvis måned er sendt med så skal det kun være et innslag i lista

NB! Dette er under utvikling og er kun operativ i STM og ATM. Det kan komme endringer i funksjonalitet!

GET /kontrakt/{kontraktId}/skjema/r15?ar={år}&maned={måned} HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

[
    {
        "id": 1534490,
        "kontraktId": 0,
        "ar": 2023,
        "maned": 9,
        "datoOverskrevet": "2023-10-18T12:58:26.8795488",
        "datoOppdatert": "2023-10-18T12:58:26.8794739",
        "avfall": [
            {
                "id": 12,
                "elementid": 1534490,
                "kodeId": 1,
                "kode": 1619,
                "underkode": null,
                "kodenavn": "Asfalt",
                "disponeringsmateId": 201,
                "disponeringsmateVerdi": "Levert til godkjent avfallsmottak",
                "opphavId": 202,
                "opphavVerdi": "Anleggsområde",
                "disponeringssted": "Norsk gjennvinning",
                "mengde": 100
            },
        ]
    },
    {
        "id": 1534491,
        "kontraktId": 0,
        "ar": 2023,
        "maned": 10,
        "datoOverskrevet": null,
        "datoOppdatert": "0001-01-01T00:00:00",
        "avfall": [
            {
                "id": 15,
                "elementid": 1534491,
                "kodeId": 1,
                "kode": 1619,
                "underkode": null,
                "kodenavn": "Asfalt",
                "disponeringsmateId": 201,
                "disponeringsmateVerdi": "Levert til godkjent avfallsmottak",
                "opphavId": 202,
                "opphavVerdi": "Anleggsområde",
                "disponeringssted": "Norsk gjennvinning",
                "mengde": 100
            },
        ]
    },
]

Innsending

Innsending av R15 avfall består av kontraktId, år, måned og en liste over avfall. se eksempel dto under.

NB! Dette er under utvikling og er kun operativ i STM og ATM. Det kan komme endringer i funksjonalitet!

POST /kontrakt/{kontraktId}/skjema/r15 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
    "id": 0, //unik id som settes i elrapp, obligatorisk
    "kontraktId": 5377, //kontrakt id, obligatorisk
    "ar": 2023, //år innsending gjelder, obligatorisk
    "maned": 6, //måned innsending gjelder, verdi må være 1-12, obligatorisk
    "avfall": [ //liste av avfall/masser for gjeldende måned, det må være minimum et innslag i lista
        {
            "kodeId": 1, //id på ns kode som blir brukt, obligatorisk og hentes fra metadata
            "disponeringsmateId": 201, //id på disponeringsmåte som er blir brukt til avfallet/massen. obligatorisk og hentes fra metadata
            "opphavId": 202, // id på opphavet til avfallet/massen. Obligatorisk og hentes fra metadata
            "disponeringssted": "Norsk gjennvinning", //navnet på stedet der avfall/masse blir disponert
            "mengde": 100.00 //mengde på avfall/masse i tonn, obligatorisk
        },
        {
            "kodeId": 252,
            "disponeringsmateId": 201,
            "opphavId": 203,
            "disponeringssted": "Norsk gjennvinning",
            "mengde": 42.543
        },
        {
            "kodeId": 272,
            "disponeringsmateId": 201,
            "opphavId": 204,
            "disponeringssted": "Norsk gjennvinning",
            "mengde": 69.5423
        }
    ]
}

Overskriving

Det er mulig og overskrive data som er sendt inn. Dette gjøres med å bruke samme endepunkt som innsending men med å ta med "overskriv" parameter. se eksempel under. Det forventes at all data for gjeldende måned vil bli sendt med når data overskrives, med det så mener vi at ikke er mulig å overskrive deler av dataene for den måneden. Data som blir overskrevet blir lagret i en historikk tabell.

NB! Dette er under utvikling og er kun operativ i STM og ATM. Det kan komme endringer i funksjonalitet!

POST /kontrakt/{kontraktId}/skjema/r15?overskriv=true HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

Validering

Obligatoriske felter må selvfølgelig fylles ut, og de er: "kontraktId", "ar", "maned" og "avfall". Et avfall objekt må ha disse feltene: "kodeId", "disponeringsmateId", "opphavId", "disponeringssted" og "mengde". Det er avhengigheter mellom ns kode og disponeringsmåte. Alle ns koder kan ha "Levert til godkjent avfallsmottak" som disponeringsmåte. Når det gjelder de andre disponeringsmåtene så er det kun noen ns koder som kan bruke de. Se tabell under

ns koder som kan bruke disponeringmåten "Levert direkte til gjenvinning":

kodebeskrivelse
1131Park- og Hageavfall (Løv, kvist og planter)
1141Rent trevirke
1601Rene masser
1611Betong uten armeringsjern
1613Tegl og takstein

ns koder som kan bruke disponeringmåten "Levert direkte til gjenvinning til utfyllingsformål/teknisk formål, eks. betong/tegl":

kodebeskrivelse
3851Alunskifer / potensielt syredannende bergarter
1601Rene masser
1611Betong uten armeringsjern
1613Tegl og takstein

ns koder som kan bruke disponeringmåten "Levert direkte til ombruk":

kodebeskrivelse
3851Alunskifer / potensielt syredannende bergarter
1141Rent trevirke
1502Store husholdningsapparater
1503Små husholdningsapparater
1518Elektronisk utstyr
1520Lyskilder
1601Rene masser

ns koder som kan bruke disponeringmåten "Levert til forberedelese til ombruk":

kodebeskrivelse
1141Rent trevirke
1601Rene masser

NB! Dette er under utvikling og er kun operativ i STM og ATM. Det kan komme endringer i funksjonalitet!

R18 Innsending

Beskrivelse av endepunkter og modeller tilknyttet R18 Skjema innsending.

Endringslogg

DatoEndring
17.11.2023Lagt til endringslogg

Api versjon

R18 er ett versjonert endepunkt og det er viktig at man setter header Ver til 2.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Metadata – Entreprenor

I R18 skjemaet så skal det sies noe om hvem de involverte partene er. Dette kan være en entreprenør (hoved- eller underentreprenør). For at det skal bli registrert riktig så må det sendes inn en eller flere entreprenør-ider. Disse IDene samt annen info kan dere hente ut via dette endepunktet. Det må også sendes inn et parameter for om man ønsker å hente ut hoved- eller underentreprenør. «he» for hovedentreprenør, og «ue» for underentreprenør.

GET /kontrakt/{kontraktId}/entreprenor HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 2.0

Metadata – R18

R18 skjema må fylles ut med en del statiske verdier, disse statiske verdiene henter man ut fra dette endepunktet.

GET /skjema/r18/metadata HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 2.0

Innsending av R18

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

POST /kontrakt/{kontraktId}/skjema/r18 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 2.0

{
      "id":  0, //unik id for skjema som blir satt når skjema blir sendt inn
      "emne":   "R18skjema - test2 sømløst", //skjemaet emne(overskrift) burde ha maks 80 tegn
      "sendtAv":   "MORTSTEN", //gyldig ELRAPP brukerId skjema er sendt på vegne av, ikke bruker som sender skjema.
                              //Blir brukt ved POST, kan være blankt ved PUT
      "oppdatertAv": "MORTSTEN", //gyldig ELRAPP brukerId skjema er sendt på vegne av, ikke bruker som sender skjema.
                                //Blir brukt ved PUT, kan være blankt ved POST
      "hendelseDato":   "2022-01-28T00:00:00", //dato for hendelse
      "klokkeslett":   "17:30", //klokkeslett for hendelsen
      "hendelseBeskrivelse":   "Litt tekst om selve hendelsen", //beskrivelse av hendelsen, maks 1999 tegn
      "nestenulykke":  0, //forteller om det har skjedd en ulykke(0) eller nesten ulykke(1)
      "tiltakBeskrivelse":   "Her skal det være beskrivelse av tiltak", //tiltaksbeskrivelse, maks 1999 tegn
      "tiltakTidsfrist":   "2022-01-31T00:00:00", //tidsfrist for tiltak, obligatorisk hvis tiltaksbeskrivelse har verdi
      "tiltakUtfoert":   "2022-01-29T00:00:00", //når tiltak har blitt utført
      "aarsakBeskrivelse":   "Årsak", //årsaksbeskrivelse, maks 1999 tegn
      "miljoeSkadeKode": "K2", //miljoeSkadeKode tatt fra metadata objektet r18Miljoskader
      "materiellSkadeKode": "K3", //materiellSkadeKode tatt fra metadata objekt r18Materiellskader
      "arbeidsoperasjonId":  5017, //kode hentet fra metadata under r18ArbeidsOperasjoner objektet
      "personskader":  [
          {
              "aldersgruppe":   "20-29", //hentes fra metadataobjektet r18Aldersgruppeer
              "nasjonalitet":   "Norsk", //hentes fra metadata objektet r18Nasjonaliteter
              "alvorlighetsgradKode":   "K4", // "Mulig varig mèn"  hentes fra metadata objektet r18PersonAlvorlighetsgrader
              "fravaerEstimert":   "3", //verdi for estimert fravær
              "fravaerTotalt":   "4", //verdi for estmiert fravær
              "involvertPartId":  5, //  "Byggherre" en av partene som er valgt og ligger i listen over involverte parter
              "skadetLegemsdeler":  [
                  {
                      "id":  2, // "Arm/albue" verdi tatt fra metadata objekt r18SkadetLegemsdeler
                }
                 ],
              "entreprenorId":  null //hvis personskaden gjelder enten HE eller UE, sett riktig entreprenør ID
             
        }
	   ],
      "risikopotensialler":  [
          {
              "skadetypeKode":   "PE", // "Personskade" hentet fra metadata objekt r18Risikopotensialer
              "alvorlighetsgradKode":  "K", // "Kritisk" hentet fra metadata objekt r18Risikopotensialer
          },
          {
              "skadetypeKode":   "MA", // "Materiell skade" hentet fra metadata objekt r18Risikopotensialer
              "alvorlighetsgradKode":   "M", // "Mindre alvorlig"  hentet fra metadata objekt r18Risikopotensialer
        },
        {
              "skadetypeKode":   "MI",  // "Miljøskade",hentet fra metadata objekt r18Risikopotensialer
              "alvorlighetsgradKode":   "A", // "Alvorlig" hentet fra metadata objekt r18Risikopotensialer
        }
      ],
      "aarsaker":  [
          {
              "id":  48, // "Handling i strid med instruks, prosedyre" hentet fra metadata objekt r18Aarsaker
          },
          {
              "id":  49, // "Handling i strid med skilting og sperring" hentet fra metadata objekt r18Aarsaker
          }
      ],
      "ytreSkader":  [
      	{
               "alvorlighetsgradKode": "K4", // "Nok 5 mill. - 10 mill."
               "skadetypeKode": "MA", // "Materiellskade"
        }
      ],
      "invovlerteParter":  [
        {
              "id":  5, //"Byggherre" hentet fra metadata objekt r18InvolverteParter
        },
        {
              "id":  1, // "Hovedentreprenør"  hentet fra metadata objekt r18InvolverteParter
              "entreprenorIds":  [27]//hentet fra metadata for hoved- og underentreprenører
        }
      ],
      "sakskategorier":  [
          {
              "id":  21, //"Brakke og innkvarteringsforhold" hentet fra metadata objekt r18Sakskategorier
          }
    ],
    "vedlegg": [
    	{
    		filnavn: "test1.txt",
    		contentType: "application/text",
    		vedlegg: "ZGVhZGJlZWY="
    	}
    ]
}

Oppdatering og innsending av ny version

Trykk her dersom du ikke allerede har lest den generelle informasjonen om hvordan vi håndterer innsending og oppdatering av skjemaer.

For sende inn en ny versjon av ett R18 skjema så sender man inn skjema ved bruk av PUT samtidig som man fyller ut id som man fikk i retur ved innsending av nytt skjema. Man må også sette oppdatertAv som er en gyldig ELRAPP bruker som skjema blir sendt på vegne av.

PUT /kontrakt/{kontraktId}/skjema/r18 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 2.0

{
  "id":  1234,
  ? // unik id for skjemaet som man skal lage en ny version for.
    "emne"
  :   "R18skjema - test2 sømløst",
  //skjemaet emne(overskrift),
  burde ha verdi,
  ? maks 80 tegn
    "oppdatertAv"
  :   "TESTER",
  //Gyldig ELRAPP bruker skjema er sendt på vegne av,
  ikke bruker som sender skjema
  ...,
}

Modeller

Nederst i bildet i swagger så ligger modellene. Modellene sier noe om hvordan endepunktene forventer at dataene skal være strukturert samt hva slags type/gyldige verdier dataene skal ha. R18SkjemaV2Dto er hovedmodellen og det er det som skal sendes inn.

Nyttig informasjon: elementId(og id under element objekt) er den unike IDen til skjema, den skal ha verdi 0 når den blir sendt inn.

Verdier som IKKE er obligatoriske:

  • tiltakUtfoert
  • tiltakTidsfrist, men kun hvis tiltaksbeskrivelse har verdi
  • Hvis skjema har en personskade: fravaerTotalt
  • Emne under elementDto er obligatorisk, tar maks 80 tegn.
  • sendtAv under elementDto må bli satt til den brukeren skjemaet er sendt på vegne av og ikke webservice brukeren skjema blir sendt inn med.
  • nestenUlykke 1 for nesten ulykke og 0 for ulykke
  • Hvis hendelsen er en ulykke så skal det være minst en personskade, miljøskade eller materiellskade.
  • Risikopotensial skal bli sendt selv om alvorlighetsgraden er «ikke aktuelt», de skal også være minst en risiko satt til høyere grad en «ikke aktuelt».
  • Det kan registreres flere personskader, men kun 1 miljøskade og/eller materiellskade.

Involverte parter under personskader er basert på den lista av valgte involverte parter. Hvis personskaden gjelder hoved- eller underentreprenør så skal entrepnrenorIDen knyttet til personskaden være en av de valgte entreprenørIDene i de valgte involverte partene. Ytre skader en liste med verdier for miljø og matereillskade. Den skal innholde alvorlighetgradkode og navn som kommer fra metadataene samt skadetype kode og navn. svvSaksnummer, svvFeilkode og svvFeilbeskrivelse skal ikke fylles ut og skal være null. Dette er verdier som blir satt når skjemaet har blitt videresendt til synergi. Aarsaksbeskrivelse, tiltaksbeskrivelse, hendelsesbeskrivelse har alle en maks lengde på 1999 tegn//

Du kan velge flere Involverte parter, og hvis den involverte parten er en underentreprenør så kan du igjen velge en liste av underentreprenører på samme ledd. eks: den involverte parten er underentreprenør 1. ledd, og det gjelder 4 av de

"invovlerteParter": [
	{
      	"Id": 2,
      	"Beskrivelse": "Underentreprenør – 1. ledd",
     		 "entreprenorIds": [1, 2, 3, 4]	//underentreprenør IDer
 	}

Metadata for aarsaker, sakskategorier og arbeidsoperasjoner består av lister med flere nivåer. Det vil si at en verdi på ett nivå kan være parent til flere andre verdier via en id. De verdien kan igjen i noen tilfeller være parent til flere andre verdier igjen. Det som er viktig er å sende inn det nederste nivået. Eks på valg arbeidsoperasjon hendelsen skjedde på: begynner på nivå 1 og velger en arbeidsoperasjon, denne har ingen «parent» siden parentKode er 0.

Nivå. 1

{
  "kode": 4,
  "beskrivelse": "Arbeid i tunnel",
  "parentKode": 0,
  "aktiv": true
}

Arbeid i tunnel har flere undervalg i nivået under, et av de valgene må velges.

Nivå. 2

{
      "kode": 129,
      "beskrivelse": "Transport/kjøring/forflytting",
      "parentKode": 4,
      "aktiv": true
    },

I noen tilfeller så har også nivå 2 noen undervalg, da må et av de velges og det er det siste nivået som skal sendes inn.

Nivå. 3

{
      "kode": 5041,
      "beskrivelse": "Land",
      "parentKode": 129,
      "aktiv": true
    },

I R18SkjemaV2Dto så blir da r18Arbeidsoperasjon objektet satt til det objektet som vi valgte i nivå 3. r18ArbeidsoperasjonKode på R18SkjemaV2Dto blir også satt til kode som er I dette tilfellet så skal nivå 3 bli sendt inn som er det siste nivået i den rekken av valg. Nivå 1, «arbeid i tunnel», har ikke noen «parentKod» og derfor på toppen, men den har flere barn, og en av dem er «Transport/kjøring/forflytting», nivå 2 har en parentKode, men den er ikke det siste nivå i denne rekken, det finnes også en arbeidsoperasjon som har «transport/kjøring/forflyttning som parentKode som er «land». Det er det siste nivået som skal sendes inn. Det skal kun velges en sakskategori og en arbeidsoperasjon, men det er mulig og sende inn en liste av årsaker. Årsakene som sendes inn må heller ikke være under samme top nivå, det vil si at du kan f.eks sende inn to årsaker hvor en har parentId = 1 og den andre har parentId = 2.

Flyt

  • Hente token hvis man ikke har gjort det.
  • Hent ut metadata som trengs for å fylle ut skjemaet.
  • fylle ut skjema med fritekst samt valg av statiske verdier (hentet fra metadataene)
  • sende inn skjema, dette returnerer en elementId

R19 Innsending

Beskrivelse av endepunkter og modeller tilknyttet R19 skjemainnsending.

Endringslogg

DatoEndring
17.11.2023Lagt til endringslogg
DatoEndring

Api versjon

R19 er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Innsending av R19

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved innsending av et R19 skjema forblir hver innsending unik, dvs. at historikken for alle innsendte skjema bevares.

Dersom man ønsker å opprette en kladd for R19 skjema gjøres dette ved å lage en kopi av eksisterende skjema (sist innsendte skjema). Åpne R19 skjema og trykk på ”Lagre-knappen”. Spørsmål ”Ønsker du å lagre skjemaet ditt med nåværende endringer?. Trykk OK. Legg inn oppdaterte tall og trykk på Lagre-knappen”. Endringene blir lagret og dato for ”Sist lagret:” oppdateres.

H- N- og F-verdier i skjemaet beregnes ut fra tidligere innsendte skjemaer hittil i prosjektet, og beregnes også underveis i utfylling av skjemaet.

Eksempel på kall:

GET /kontrakt/${kontraktId}/r19/periode?dato=${dato}
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

{
  "id": 123456,                 // Skjemaets id - Dette er IDen skjemaet får ved innsending.
  "SendtAv": "TESTBRUK", gyldig ELRAPP-bruker som skjemaet er sendt på vegne av, IKKE servicebrukeren som sender skjema.
  "versjonNr": null,            // Skjemaets versjonsnummer i ELRAPP, inkrementeres ved PUT-kall.
  "ReferanseNr": null           // Skjemaets referansenummer i ELRAPP.
  "emne": "R19 Månedsrapport HMS" // Generert emne i ELRAPP.
  "datoSendt": 202201, // Dato for når innsending er utført.
  "datoOppdatert": 202202, // Dato for når innsending er oppdatert.
  "TimeverkHovedentrPeriode": 1, // Timeverk for hovedentreprenør v/peride.
  "TimeverkUnderentrPeriode": 2, // Timeverk for underentreprenør v/periode.
  "TimeverkLaerlingetimerSamlet": 3, // Timeverk for læringtimer samlet.
  "HovedentrPeriode1": 1, // Uønskede hendelser personskade med fravær for hovedentreprenør periode1
  "HovedentrPeriode2": 2, // Uønskede hendelser personskade med fravær for hovedentreprenør periode2
  "HovedentrPeriode3": 3, // Uønskede hendelser personskade med fravær for hovedentreprenør periode3
  "HovedentrPeriode4": 4, // Uønskede hendelser personskade med fravær for hovedentreprenør periode4
  "HovedentrPeriode5": 5, // Uønskede hendelser personskade med fravær for hovedentreprenør periode5
  "HovedentrPeriode6": 6, // Uønskede hendelser personskade med fravær for hovedentreprenør periode6
  "UnderentrPeriode1": 1, // Uønskede hendelser personskade med fravær for underentreprenør periode1
  "UnderentrPeriode2": 1, // Uønskede hendelser personskade med fravær for underentreprenør periode2
  "UnderentrPeriode3": 1, // Uønskede hendelser personskade med fravær for underentreprenør periode3
  "UnderentrPeriode4": 1, // Uønskede hendelser personskade med fravær for underentreprenør periode4
  "UnderentrPeriode5": 1, // Uønskede hendelser personskade med fravær for underentreprenør periode5
  "UnderentrPeriode6": 1, // Uønskede hendelser personskade med fravær for underentreprenør periode6
  "vedlegg": [  // Gyldige filformater er "png","jpeg","jpg","tif","pdf","doc","docx","xls","xlsx","htm","html","msg","sos","mpp","mppx","rtf","ppt","pptx","txt".  Vedleggene kan ikke overskride 50MB.
    {
      "filnavn": "test1.jpeg",
      "contentType": "image/jpeg",
      "vedlegg": "ZGVhZGJlZWY=",                      // Dette feltet må være satt til en gyldig base64 string.
    }
  ]
}

Oppdatering og innsending av ny versjon

R19 skjema har ikke versjonering, hvis bruker skal sende inn en ny innsending på allerede innsendt måned så blir dette et nytt skjema i ELRAPP. Det benyttes samme endepunkt for oppdatering som for innsending.

R20 Innsending

Beskrivelse av endepunkter og modeller tilknyttet R20 skjemainnsending.

Endringslogg

DatoEndring
17.11.2023Lagt til endringslogg

Api versjon

R20 er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Innsending av R20

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved innsending av et R20 skjema er følgende felt påkrevd: SentBy (sendt av), Subject (emne) og Attachments (vedlegg).

POST /kontrakt/{kontraktId}/skjema/r20 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey {DIN_API_KEY}
Ver: 1.0

{
  "sentBy": "TESTBRUK",                              // gyldig ELRAPP-bruker som skjema er sendt på vegne av, IKKE servicebrukeren som sender skjema.
  "subject": "R20 Generell inspeksjon: Samlerapport",    // skjemaets emne(overskrift)
  "attachments": [  // Gyldige filformater er "png","jpeg","jpg","tif","pdf","doc","docx","xls","xlsx","htm","html","msg","sos","mpp","mppx","rtf","ppt","pptx","txt".  Vedleggene kan ikke overskride 50MB.
    {
      "filnavn": "test1.jpeg",
      "contentType": "image/jpeg",
      "vedlegg": "ZGVhZGJlZWY=",                      // Dette feltet må være satt til en gyldig base64 string.
    }
  ]
}

Oppdatering og innsending av ny versjon

Trykk her dersom du ikke allerede har lest den generelle informasjonen om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved oppdatering av et R20 skjema er det viktig at Id og UpdatedBy (oppdatert av) feltet også sendes inn.

PUT /kontrakt/{kontraktId}/skjema/r20?id=5 HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
  "id": 1234, //id som ble returnert i tidligere POST eller PUT kall
  "updatedBy": "Testbruker" // gyldig ELRAPP bruker skjema er oppdatert på vegne av, ikke servicebrukeren som sender skjema.
  ...

Avvik innsending

Beskrivelse av endepunkter og modeller tilknyttet Avvik Skjema innsending.

Endringslogg

DatoEndring
17.11.2023Lagt til endringslogg

Api versjon

Avvik er ett versjonert endepunkt og det er viktig at man setter header Ver til 1.0 som vist i eksemplene.

KontraktId

Kontrakt id hentes ut under kontrakt info ved å logge inn med en entreprenør eller superbruker i ELRAPP.

Endepunkter

Metadata

I Avvik skjemaet så skal det fylles ut en del statiske verdier, disse statiske verdiene henter man fra dette endepunktet.

GET /skjema/avvik/metadata HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

Innsending av Avvik

Trykk her for informasjon om hvordan vi håndterer innsending og oppdatering av skjemaer.

Ved innsending av et Avvik er følgende felt påkrevd: sendtAv, avvikRegistrert, fraVegreferanse, tilVegreferanse, prosessId og merknad.

Emne kan enten settes av bruker eller så blir det satt automatisk i ELRAPP ved innsending og returnert i responsen.

Avvik kan bli registrert som en strekning eller som et punkt. Hvis det er et punkt så sett tilVegreferanse = fraVegreferanse.

Det gjøres ett oppslag mot NVDB basert på veglenke og relativposisjon som er sendt inn. Når vi gjør oppslaget så kan det f.eks være at NVDB er nede eller innsendt veglenke ikke er riktig. I slike tilfeller vil vi returnere en 500 feil med en melding.

Eksempel på kall:

POST /kontrakt/{kontraktId}/skjema/avvik HTTP/1.1
Content-Type: application/json
Authorization: ApiKey 1b9a1439-25ef-436e-8558-49ae982f9689
Ver: 1.0

{
  "SendtAv": "TestBruk",    // brukeren skjema er sendt på vegne av, ikke servicebrukeren som sender skjema.
  "emne": "emne",           //maks 300 tegn
  "AvvikRegistrert": "2021-01-15T06:52:52.366Z",  //Dato når avviket ble oppdaget
  "FraVegreferanse": {
    "Veglenke": 231234,         //veglenkesekvensId
    "RelativPosisjon": 0.1234   //relativposisjon på veglenkesekvensid
  },
  "TilVegreferanse": {
    "Veglenke": 231234,         //veglenkesekvensId
    "RelativPosisjon": 0.1234   //relativposisjon på veglenkesekvensid
  },
  "Side": "string",       //fra avvik metadata, bruk id fra sideAvVeg
  "ProsessId": 0,         //fra avvik metadata, id fra prosesser[]
  "ProsessAvvikId": 0,    //fra avvik metadata, id fra avvik[], bruk kun id'er som har lik prosessId
  "ObjektId": 0,          //fra avvik metadata, id fra objekter[], har en avhengighet mot prosess
  "Merknad": "Merknad/Kommentar", //maks 500 tegn
  "Vedlegg": [
    {
      "Filnavn": "test1.jpeg",    //navn på fil
      "Vedlegg": "ZGVhZGJlZWY=",    // Dette feltet må være satt til en gyldig base64 string
      "ContentType": "image/jpeg"
    }
  ]
}

Kallet returnerer dette objektet.

{
    "id": 123123,      // skjemaets id
    "lopeNr": 5,       // elrapp løpenummer
    "versjonNr": null  // elrapp versjonsnummer
    "emne": "FV242: 78.2 Skilt" // Generert emne i elrapp
}
Last Updated:
Contributors: Øyvind Gujord