Oversikt over valideringsfeil for API i MO

Sekvens for innsending - synkron og asynkron respons

Se også dokumentasjon her: https://toll.github.io/api/mo-vei.html#hvordanSende, dette er likt for alle transportformer.

Generelt fungerer innsending av informasjon slik at aktøren sender inn en melding (POST) og mottar en referanse (requestId). Ved å bruke den mottatte referansen kan aktøren spørre (GET) om resultat av innsendingen og ved suksess motta en permanent referanse til meldingen, utstedt av Tolletaten. Dette gjøres på et eget endepunkt (/validation-status) i spørre-API-et (query API) linket til lengre nede på denne siden. Disse tjenestene er asynkrone og man må derfor spørre inntil man får svar. Valideringsrespons vil vanligvis være tilgjengelig i løpet 1 til 2 sekunder, men det kan ta lenger tid i enkelttilfeller.
Spørring gjøres på /validation-status-endepunktet, som vil returnere den permanente referansen, et Master Reference Number, forkortet MRN ved suksess og en liste med valideringsfeil hvis de finnes.

Eksempel på innsendingssekvens for forsendelse (house consignment). Mønsteret er det samme for de andre meldingene, hovedforsendelse (master consignment) og transport.

Se figurtekst — Figur: sekvens for innsending av melding om forsendelse (house consignment)

MRN brukes når meldinger skal oppdateres eller kanselleres (put/delete) for å referere til tidligere innsendte meldinger. Valideringsendepunktet vil også kunne returnere en liste med dokumentstatuser for å indikere manglende opplysninger, se https://toll.github.io/api/mo-kodeverk.html#incompleteDocumentationReason. Anbefalt metode for innsending er at aktøren sender inn alle meldinger for oppretting (POST) som er aktuelle, og så venter 1-2 sekunder før spørring om validering (query API).

For eksempel: om man har 500 forsendelser for en hovedforsendelse på en transport, så sender man inn (POST) alle 500 meldingene om forsendelse, venter et par sekunder, ber om validering og får tilbake MRN og status for alle de 500 meldingene. Dersom man får status 404 ved kall til valideringsendepunktet må man vente litt og spørre igjen. Det anbefales å lage en algoritme som gjør gjentatte forsøk, inntil valideringsrespons mottas.

Synkrone valideringsfeil

Synkrone (via HTTP) valideringsfeil oppgis som svar med statuskode 400 på innsendelse mot API-et. Årsaken til valideringsfeilen returneres som innhold (body) i svaret. Når man får synkrone valideringsfeil blir innsendingen avvist umiddelbart og ikke behandlet videre før feilen(e) er rettet og det sendes inn på nytt. Dersom det ikke er noen synkrone valideringsfeil, vil svaret ha statuskode 202 og inneholde et felt "requestId" som benyttes for så å se om det avdekkes asynkrone valideringsfeil under videre behandling.

Innholdsformat på synkrone valideringsfeil

Valideringsfeilene returneres som en eller flere objekter i en liste "validationErrors". Innholdet i listen er et eller flere objekter som peker på hvilke felter som forårsaket valideringsfeilen angitt i feltet "field", og årsaken til feilen angitt i feltet "error".

        {
          "validationErrors": [
            {
              "field": "${fieldWithErrorOne}",
              "error": "${validationErrorCauseOne}"
            },
            {
              "field": "${fieldWithErrorTwo}",
              "error": "${validationErrorCauseTwo}"
            }
          ]
        }

Manglende eller blanke ("") påkrevde felt

Svar

{
  "validationErrors": [
    {
      "field": "${fieldname}",
      "error": "must not be null"
    },
    {
      "field": "${fieldname}",
      "error": "must not be blank"
    }
  ]
}

Årsak

Felter som er påkrevd mangler eller har tomme verdier. Felter som ikke kan ha tomme verdier vil gi "must not be blank" enten de mangler eller er tomme. Alle andre påkrevde felter vil gi "must not be null" om de mangler.

Rettelse

Feltet må være med ("must not be null") eller må være med og ha en verdi ("must not be blank").

Feil format på dato/tid:

Svar

{
  "validationErrors": [
    {
      "field": "${fieldname}",
      "error": "invalid ISO-8601 instant in UTC (yyyy-MM-ddTHH:mm:ssZ)"
    }
  ]
}

Årsak

Dato og tidspunkt felter har feil format. De må følge ISO-8601 standarden. Det vil si være i formatet: yyyy-MM-ddTHH:mm:ssZ

Rettelse

Endre formatet til å følge ISO-8601 standarden i formatet yyyy-MM-ddTHH:mm:ssZ.

Feil feltstørrelse - tall

Svar

{
  "validationErrors": [
    {
      "field": "${fieldname}",
      "error": "numeric value out of bounds (<${maxInteger} digits>.<${maxDecimalNumber} digits> expected)"
    }
  ]
}

Årsak

Man har angitt et tall som overskrider maksimalt antall siffer før elleretter desimalskille ("."). Der det er kun heltall som er tillat vil tallet etter desimalskille (".", det vil si maxDecimalNumber) være 0.

Rettelse

Endre tallet til å være et siffer innenfor maksimalt heltall (maxInteger-verdien) og maksimalt antall desimalsiffer (maxDecimalNumber-verdien).

Feil feltstørrelse - streng (tekst)

Svar

{
  "validationErrors": [
    {
      "field": "${fieldname}",
      "error": "size must be between ${minLength} and ${maxLength}"
    }
  ]
}

Årsak

Innholdet i feltet har overskredet maksimalt antall tegn eller har færre enn minimum antall tegn.

Rettelse

Endre innholdet til å være innenfor minimum og maksimum størrelse.

Minst ett av feltene må være oppgitt

Svar

{
  "validationErrors": [
    {
      "field": "${fieldname}",
      "error": "At least one of the following fields should be non null: [${fieldOne}, ${fieldTwo}]"
    }
  ]
}

Årsak

I noen tilfeller må minst et av flere felter være oppgitt. Objektet angitt (fieldname), må minst inneholde verdi i minst ett av de angitte feltene.

Rettelse

Påse at minst ett av de oppgitte feltene er oppgitt og har gyldig verdi på objektet.

Må ha en påkrevd verdier

Svar

{
  "validationErrors": [
    {
      "field": "${fieldname}",
      "error": "Must be one of [${valueOne}, ${valueTwo}]"
    }
  ]
}

Årsak

Feltet (fieldname) kan kun ha en av de angitte verdiene og må sendes inn med én av dem.

Rettelse

Endre feltets verdi slik at det har en av de fastsatte verdiene (valueOne, ValueTwo ...) som er påkrevd.

Asynkrone valideringsfeil

Dersom en innsending ikke hadde noen valideringsfeil som førte til umiddelbar avvisning (synkrone valideringsfeil) blir innsendingen behandlet videre. Det kan fortsatt oppstå valideringsfeil senere - under den videre behandlingen. Disse vil man da få som svar på kall mot det korresponderende "/validation-status" endepunktet når behandlingen er fullført. Valideringsfeil blir knyttet til "requestId" verdien man får i retur på den originale innsendingen, og returnert som asynkrone valideringsfeil.

Innholdsformat på asynkrone valideringsfeil

Dersom det er valideringsfeil funnet når asynkron validering er ferdig vil svaret mot "/validation-status" endepunktet returnere HTTP kode 202 med innhold der feltet "status" har verdien "FAILURE".
Valideringsfeilene returneres som ett eller flere objekter i en liste, "validationErrorList". Innholdet i listen er objekt(er) som peker på sti til felt(er) som forårsaket valideringsfeilen angitt i feltet "pointer.messageElementPath" og årsaken til feilen angitt i feltet "description".

Frem til behandling er ferdig vil svaret på endepunktet gi HTTP kode 404.

Dersom det ikke er noen valderingsfeil, og innnsending er vellykket , vil feltet "status" ha verdien "SUCCESS"

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}",
  "validationErrorList": [
    {
      "description": "${validationErrorCauseOne}",
      "pointer": {
        "messageElementPath": "${pathToFieldWithErrorOne}"
      }
    },
    {
      "description":  "${validationErrorCauseTwo}",
      "pointer": {
        "messageElementPath": "${pathToFieldWithErrorTwo}"
      }
    }
  ]
}

Feltet skal ha en verdi angitt av kodeverk

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}"
  "validationErrorList": [
    {
      "description": "Invalid code. Expected codes are one of [${codeOne}, ${codeTwo}]",
      "pointer": {
        "messageElementPath": "${pathToFieldWithError}"
      }
    }
  ]
}

Årsak

Feltet angitt på "messageElementPath" hadde en verdi som ikke ble funnet i kodeverket (tabell over lovlige verdier). En av kodeverkets verdier, som angitt i ["codeOne", "codeTwo"...], er påkrevd for feltet.

Rettelse

Endre feltet til å ha en verdi tilsvarende en gyldig kodeverkskode som påkrevd for feltet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Landkode ikke gyldig

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Country is invalid",
      "pointer": {
        "messageElementPath": "${pathToFieldWithError}"
      }
    }
  ]
}

Årsak

Feltet angitt på "messageElementPath" har en landkode som ikke ble funnet blant gyldige ISO-3166 Alpha-2 koder.

Rettelse

Endre feltet til å benytte en gyldig ISO-3166 Alpha-2 kode. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Format på oppgitt MRN er ugyldig for eksport av angitt eksporttype

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}"
  "validationErrorList": [
    {
      "description": "Invalid MRN format for export of type ${typeOfExport}",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.exportFromEU[${indexInList}].exportId"
      }
    }
  ]
}

Årsak

MRN for feltet "exportId" angitt på "messageElementPath" er oppgitt med et format som ikke er gyldig for angitt eksporttype ("typeOfExport").

Rettelse

Endre feltets verdi til å benytte et gyldig format for MRN. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Format på oppgitt MRN har ikke korrekt lengde for identifikator av eksport med type ECS_EXPORT

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}"
  "validationErrorList": [
    {
      "description": "Invalid MRN format for export of type ECS_EXPORT, must be 18 characters long.",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.exportFromEU[${indexInList}].exportId"
      }
    }
  ]
}

Årsak

MRN for "exportId" angitt på "messageElementPath" er angitt med lengde som ikke er gyldig for angitt typeOfExport - ECS_EXPORT.

Rettelse

Verifiser at MRN er korrekt og har korrekt lengde påkrevd for typen eksport.
Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kun veitransport (road-API): Eksport av type AES_EXPORT ble ikke funnet eller har feil status i AES

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}"
  "validationErrorList": [
    {
      "description": "Export of type AES_EXPORT is not found or has wrong status in AES.",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.exportFromEU[${indexInList}].exportId"
      }
    }
  ]
}

Årsak

Eksporten er av type AES_EXPORT men exportId ble ikke funnet, eller har feil status i AES. I tillegg til at det ikke finnes en eksportdeklarasjon med angitt iD, kan årsaken være:

eksportdeklarasjonen finnes, men er ikke frigitt fra avgangstollsted
eksportdeklarasjonen finnes, men er allerede utførselsregistrert

Rettelse

Verifiser og eventuelt endre slik at exportId er korrekt og har riktig status i AES.
Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Dersom verdi som angir prosedyren som forsendelsen var underlagt frem til grensepassering inn i Norge ("outgoing procedure"), er angitt, må verdien være en av kodene tillatt i kodeverket

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}"
  "validationErrorList": [
    {
      "description": "When field is provided, it has to be one of ${outgoingProcedureCodes}",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.importProcedure.outgoingProcedure"
      }
    }
  ]
}

Årsak

Verdi for feltet outgoingProcedure ble ikke funnet blant de gyldige kodene som finnes i OutgoingProcedure kodeverket https://toll.github.io/api/mo-kodeverk.html#outgoingprocedure.

Rettelse

Endre verdien til en av verdiene som finnes i OutgoingProcedure kodeverket. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Dersom man har angitt en verdi i et felt som benytter FNs stedskoder ("UNLOCODE") må dette være en av verdiene som finnes i kodeverket for CL144 UNLOCODE

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}", 
  "validationErrorList": [
    {
      "description": "Invalid code. Expected valid UNLOCODE",
      "pointer": {
        "messageElementPath": "${pathToFieldWithError}"
      }
    }
  ]
}

Årsak

Det er flere felter i meldingene der verdien som skal oppgis er basert på FN sine stedskoder, "UNLOCODE". Feltet angitt på "messageElementPath" har en innsendt verdi som ikke ble funnet i kodeverket for CL144 UNLOCODE.

Rettelse

Endre verdien til en av verdiene som finnes i CL144 UNLOCODE kodeverket. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kan ikke sende inn exportFromEU liste dersom prosedyren som forsendelsen var underlagt frem til grensepassering inn i Norge ("outgoing procedure") er Transittering (TRA)

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}"
  "validationErrorList": [
    {
      "description": "Field cannot have values when consignmentHouseLevel.importProcedure.outgoingProcedure is TRA",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.exportFromEU"
      }
    }
  ]
}

Årsak

Dersom prosedyren som forsendelsen var underlagt frem til grensepassering inn i Norge (i feltet outgoingProcedure ) har verdien TRA (for transittering) kan man ikke sende inn referanse til eksport fra EU (exportFromEU).

Rettelse

Fjern exportFromEU fra importprosedyren eller endre outgoingProcedure. Send inn på nytt.
Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Dersom verken adresse eller lokasjon er spesifisert, er FN stedskode ("UNLOCODE") påkrevd

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}", 
  "validationErrorList": [
    {
      "description": "If location AND address is not provided, then unloCode is required",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.placeOfDelivery.unloCode"
      }
    }
  ]
}

Årsak

Objektet angitt på "messageElementPath" har verken oppgitt adresse ("address") eller lokasjon ("location"). Da må feltet "unloCode" være oppgitt og ha en verdi for dette objektet.
Dette gjelder for lastested ("placeOfLoading"), lossested ("placeOfUnloading"), akseptansested ("placeOfAcceptance") og leveringssted ("placeOfDelivery").

Rettelse

Legg til gyldig "unloCode", eventuelt legg til "address" og/eller "location" på objektet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Referanse til transittering ("typeOfReference" lik "N820") refererer til transittering som ikke har gyldig status

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Document with typeOfReference N820 contains a referenceNumber in wrong state",
      "pointer": {
        "messageElementPath": "${pathToFieldWithError}"
      }
    }
  ]
}

Årsak

Det er oppgitt en referanse til en transittering der typen referanse er "N820" ("typeOfReference" lik "N820"). Denne transitteringen er ikke i riktig status. Kravet til riktig status i denne konteksten er at det er deklarert NO grensepasseringstollsted og NO destinasjonstollsted i transitteringsdeklarasjonen samt at transitteringen er frigitt fra avgangstollstedet.

Dokument av type N820 angitt på "messageElementPath" har feil status i transittsystemet.

Rettelse

Kontroller at transitterings-deklarasjonen er i samsvar med beskrivelsen over.

Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

VOEC varelinje ("goodsItem") har angitt en verdi som er over NOK 3.000, derfor må importdeklarasjon benyttes i stedet

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "When item value exeedes NOK 3000, a regular import-declaration have to be submitted",
      "pointer": {
        "messageElementPath": "${pathToFieldWithError}"
      }
    }
  ]
}

Årsak

VOEC har en maksimal verdi pr vare på NOK 3.000. Varelinje ("goodsItem") med angitt VOEC-nummer ("vatIdentificationNumber") har en angitt verdi per vare ("itemAmountInvoicedVOEC") over maksgrense på 3000 kroner.

Rettelse

Opprett vanlig importdeklarasjon for varen(e) og bruk denne. Vær oppmerksom på at hvis en eller flere av varene mottaker har kjøpt har en verdi over 3000 NOK, vil alle varene måtte bli fortollet på vanlig måte. Se https://www.skatteetaten.no/bedrift-og-organisasjon/avgifter/mva/utland/e-handel-voec/sending-av-pakker-i-voec-ordningen/.
Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Ingen tillatelser funnet for VOEC-nummeret angitt på VOEC varelinjen ("goodsItem")

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Unknown vatIdentificationNumber",
      "pointer": {
        "messageElementPath": "${pathToFieldWithError}"
      }
    }
  ]
}

Årsak

Finner ingen gyldig VOEC tillatelser for VOEC-nummereret ("vatIdentificationNumber") som er angitt på VOEC-varelinjen ("goodsItem"). Det er oppgitt et VOEC-nummer som vi ikke kan verifisere at er gyldig. Det kan være feil VOEC-nummer, eller VOEC-nummerets gyldighet har utløpt.

Rettelse

Endre VOEC-nummer til et gyldig nummer. Hvis ikke gyldig VOEC-nummer kan fremskaffes må varene deklareres med vanlig importdeklarasjon.
Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kan ikke sende liste med VOEC varelinjer ("goodsItem") dersom valgt tollprosedyre ("importProcedure") for forsendelsen ikke er VOEC ("IMMEDIATE_RELEASE_VOEC")

Svar

If consignmentHouseLevel.importProcedure.importProcedure is not IMMEDATE_RELEASE_VOEC, should not be provided.

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "If consignmentHouseLevel.importProcedure.importProcedure is not IMMEDATE_RELEASE_VOEC, should not be provided.",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.goodsItem"
      }
    }
  ]
}

Årsak

Man kan ikke sende inn VOEC varelinjer ("goodsItem" liste) med mindre man har oppgitt at tollprosedyren for forsendelsen ("importProcedure") er VOEC (har verdien "IMMEDIATE_RELEASE_VOEC")

Rettelse

Fjern "goodsItem" liste, eller angi "importProcedure" som "IMMEDLATE_RELEASE_VOEC". Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kode for Tollkontor det refereres til er ugyldig

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Must be a valid customs office",
      "pointer": {
        "messageElementPath": "customsOfficeOfFirstEntry.referenceNumber"
      }
    }
  ]
}

Årsak

Referansenummeret oppgitt for "customsOfficeOfFirstEntry" refererer ikke til et gyldig tollkontor. Bruk CL141 Customs office reference number fra kodeverk https://toll.github.io/api/mo-kodeverk.html#cl141

Rettelse

Oppgi et gyldig referansenummer til et tollkontor. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Feltet opprinnelig ankomsttid ("scheduledDateAndTimeOfArrival") er påkrevd for meldingen for transport

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "scheduledDateAndTimeOfArrival should be present",
      "pointer": {
        "messageElementPath": "transport.scheduledDateAndTimeOfArrival"
      }
    }
  ]
}

Årsak

Feltet for opprinnelig ankomsttid ("scheduledDateAndTimeOfArrival") må alltid være med på transport objektet.

Rettelse

Legg til feltet "scheduledDateAndTimeOfArrival" med gyldig verdi på transport objektet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Feltet for opprinnelig ankomsttid ("scheduledDateAndTimeOfArrival") kan ikke være satt til mer enn ett år frem i tid

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "scheduledDateAndTimeOfArrival cannot be more than one year into the future",
      "pointer": {
        "messageElementPath": "transport.scheduledDateAndTimeOfArrival"
      }
    }
  ]
}

Årsak

Feltet opprinnelig ankomsttid ("scheduledDateAndTimeOfArrival") kan ikke være mer enn ett år frem i tid.

Rettelse

Endre feltet "scheduledDateAndTimeOfArrival" til en dato som er mindre enn ett år frem i tid. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Feltet for estimert ankomsttid ("estimatedDateAndTimeOfArrival") er påkrevd på melding om transport

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "estimatedDateAndTimeOfArrival should be present",
      "pointer": {
        "messageElementPath": "transport.estimatedDateAndTimeOfArrival"
      }
    }
  ]
}

Årsak

Feltet for estimert ankomsttid "estimatedDateAndTimeOfArrival" må alltid være med på transportobjektet.

Rettelse

Legg til feltet "estimatedDateAndTimeOfArrival" med gyldig verdi på transportobjektet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kan ikke oppgi estimert ankomsttid ("estimatedDateAndTimeOfArrival") som er i fortiden

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "estimatedDateAndTimeOfArrival has already passed",
      "pointer": {
        "messageElementPath": "transport.estimatedDateAndTimeOfArrival"
      }
    }
  ]
}

Årsak

Tidspunkt oppgitt for estimert ankomsttid ("estimatedDateAndTimeOfArrival") må være frem i tid.

Rettelse

Endre "estimatedDateAndTimeOfArrival" til et tidspunkt frem i tid. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Tidspunkt oppgitt for estimert ankomsttid ("estimatedDateAndTimeOfArrival") kan ikke være mer enn ett år frem i tid

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "estimatedDateAndTimeOfArrival cannot be more than one year into the future",
      "pointer": {
        "messageElementPath": "transport.estimatedDateAndTimeOfArrival"
      }
    }
  ]
}

Årsak

Tidspunkt oppgitt for estimert ankomsttid ("estimatedDateAndTimeOfArrival") kan ikke være mer enn ett år frem i tid.

Rettelse

Endre "estimatedDateAndTimeOfArrival" tidspunkt som er mindre enn ett år frem i tid. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kun road og rail: Kan ikke oppgi conveyanceReferenceNumber dersom modeOfTransportCode har angitt verdi

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "transport.activeBorderTransportMeans.modeOfTransportCode is ${value}, then this field should not be provided",
      "pointer": {
        "messageElementPath": "transport.activeBorderTransportMeans.conveyanceReferenceNumber"
      }
    }
  ]
}

Årsak

Med koden angitt for modeOfTransportCode er det ikke tillatt å sende med en verdi for conveyanceReferenceNumber.

Rettelse

Fjern conveyanceReferenceNumber eller endre angitt modeOfTransportCode. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kun road og rail: Når modeOfTransportCode er av angitt verdi så må typeOfIdentification være bestemt verdi

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "transport.activeBorderTransportMeans.modeOfTransportCode is ${value}, then this field should have value ${requiredValue}",
      "pointer": {
        "messageElementPath": "transport.activeBorderTransportMeans.typeOfIdentification"
      }
    }
  ]
}

Årsak

Med koden angitt for modeOfTransportCode må typeOfIdentification være denne bestemte verdien ("requiredValue").

Rettelse

Endre typeOfIdentification feltet til verdien oppgitt som påkrevd i valideringsfeilen ("requiredValue"). Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Kun veitransport (road-API): Kan ikke finne det norske kjøretøyets registreringsnummer ("identificationNumber") i kjøretøyregisteret

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Could not find identificationNumber in Norwegian Public Roads Administration’s register of motor vehicles",
      "pointer": {
        "messageElementPath": "transport.activeBorderTransportMeans.identificationNumber"
      }
    }
  ]
}

Årsak

Man har sendt inn at kjøretøyet er norsk (countryCode er "NO"), men registreringsnummeret ("identificationNumber") finnes ikke i veivesenets kjøretøyregister.

Rettelse

Dersom kjøretøy er norsk, verifiser at identificationNumber er korrekt i henhold til det som er registrert i veivesenets kjøretøyregister. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Finner ikke tolldeklarasjon blant gyldige deklarasjoner angitt i våre systemer.

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Customs declaration is not valid",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments[${indexInList}]"
      }
    }
  ]
}

Årsak

Deklarasjonen angitt med "declarantNumber", "declarationDate" og "sequenceNumber" kan ikke knyttes til House Consignment. For at den refererte tolldeklarasjonen skal kunne valideres OK må den være sendt inn mot en definert ekspedisjonsenhet i TVINN. P.t er dette kun ekspedisjonsenhet 441001.

Rettelse

Verifiser at informasjonen om deklarasjonen er korrekt registrert. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Tolldeklarasjon angitt har en ugyldig status i våre systemer.

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Customs declaration is in wrong state",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments[${indexInList}]"
      }
    }
  ]
}

Årsak

Deklarasjonen angitt med "declarantNumber", "declarationDate" og "sequenceNumber" ble funnet i våre systemer, men har feil status. Dette betyr som regel at deklarasjonen allerede er avsluttet.

Rettelse

Påse at deklarasjonen er behandlet og har en gyldig status. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Spesifisert felt kan ikke ha en verdi når man har oppgitt spesifisert tollprosedyre ("importProcedure" er X)

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Field cannot be filled out when consignmentHouseLevel.importProcedure is ${importProcedureType}",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments[${indexInList}].${fieldName}"
      }
    }
  ]
}

Årsak

Dersom man har angitt at tollprosedyre ("importProcedure") er angitt verdi, kan man ikke fylle ut dette feltet, det vil si feltet som er angitt i "messageElementPath". Denne feilen kommer når angitt tollprosedyre er forskjellig fra "IMMEDIATE_RELEASE_IMPORT" samtidig som man angir verdier i feltene som skal fortelle om referansen til tolldeklarasjonen. ("consignmentHouseLevel.previousDocuments.sequenceNumber", og/eller "consignmentHouseLevel.previousDocuments.declarantNumber" og/eller "consignmentHouseLevel.previousDocuments.declarationDate")

Rettelse

Enten endre importProcedure eller fjern verdien i dette feltet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Felt kan ikke ha en verdi for transittering ("N820"), dersom man har angitt prosedyren som forsendelsen var underlagt frem til grensepassering inn i Norge ("outgoing procedure"), som eksport ("EXP")

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Field cannot have value N820 out when consignmentHouseLevel.outgoingProcedure is EXP",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments[${indexInList}].typeOfReference"
      }
    }
  ]
}

Årsak

Dersom man har angitt at prosedyren som forsendelsen var underlagt frem til grensepassering inn i Norge ("outgoingProcedure") er eksport (med verdi "EXP"), kan man ikke oppgi verdien "N820" i dette feltet. Dette gjelder referanser til tidligere tollprosedyrer som varene har vært underlagt. Dersom man oppgir at tidligere tollprosedyre er eksport, så kan man ikke henvise til en referanse til transittering.
Se valg av tollprosedyre https://toll.github.io/api/mo-vei.html#utfyllingForsend

Rettelse

Enten endre verdien i feltet eller outgoingProcedure. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Når referert dokument ("typeReference") er tolldeklarasjon ("CUDE") så er det spesifiserte feltet obligatorisk

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Required field when typeReference is CUDE",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments[${indexInList}].${fieldRequired}"
      }
    }
  ]
}

Årsak

Man har angitt at referert dokument er tolldeklarasjon ("typeReference" med verdi "CUDE"), da må man også oppgi verdi i det spesifisert feltet (feltet er spesifisert i feilmeldingen).

Rettelse

Enten endre typeReference eller oppgi verdi for feltet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Dersom man angitt en eller flere dokumentreferanser ("previousDocument") må tollprosedyre (feltet "importProcedure") være oppgitt

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "importProcedure is required when any consignmentHouseLevel.previousDocuments[] is provided",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.importProcedure"
      }
    }
  ]
}

Årsak

Man har sendt inn ett eller flere referanser til dokumenter (objekter i "previousDocuments" listen), men ikke oppgitt en tollprosedyre (verdi i "importProcedure" feltet).

Rettelse

Enten oppgi en verdi for importProcedure feltet eller fjern alle objekter i previousDocuments listen. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Man kan kun ha oppgitt en dokumentreferanse til en tolldeklarasjon (et objekt i "previousDocuments" listen) av type tolldeklarasjon ( med "typeOfReference" = "CUDE")

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "PreviousDocuments can only contain one document of type CUDE",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments"
      }
    }
  ]
}

Årsak

Man har sendt mer enn en tolldeklarasjon (objekt i "previousDocuments"-listen) med verdien "CUDE" i feltet "typeOfReference".
Det er kun tillatt med én tolldeklarasjon per forsendelse.

Rettelse

Påse at man kun har ett objekt med typeOfReference verdien "CUDE" i previousDocuments-listen.
Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Dersom dokumentreferanse er noe annet enn til en tolldeklarasjon ("typeOfReference" <> "CUDE") må referansen oppgis i feltet "referenceNumber" i "previousDocuments" objektet.

Svar

{
  "status": "FAILURE",
  "requestId": "${requestIdForSubmission}",
  "notificationDate": "${dateTimeResultWasReady}" 
  "validationErrorList": [
    {
      "description": "Field should have value unless typeOfReference is CUDE",
      "pointer": {
        "messageElementPath": "consignmentHouseLevel.previousDocuments[${indexInList}].referenceNumber"
      }
    }
  ]
}

Årsak

Når det angis referanse til andre typer dokumenter enn tolldeklarasjon skal feltet "referenceNumber" i "previousDocuments" benyttes for å oppgi denne referansen (typisk MRN eller lignende).
Man har sendt inn et objekt i "previousDocuments"-listen med en verdi som ikke er "CUDE" i feltet "typeOfReference", samtidig som man ikke har angitt en verdi i feltet "referenceNumber".
Det er påkrevd at dette feltet er angitt med en verdi med mindre "typeOfReference" har verdien "CUDE".

Rettelse

Endre objektet til å ha til å ha verdien "CUDE" i typeOfReference-feltet, eller legg inn gyldig verdi i referenceNumber-feltet. Send inn på nytt. Bruk ny "requestId" man får i retur for ny innsendelse og verifiser at asynkron validering for denne returner feltet "status" med verdien "SUCCESS" når ny behandling er ferdig.

Ufullstendig dokumentasjon / Incomplete documentation

I visse tilfeller kan informasjonen som er sendt inn ikke være nok til å fullføre behandling. På endepunktet "/house-consignment/validation-status/{requestIds}" vil man da få en liste med årsakskoder under "incompleteDocumentationReasonList". Det er også mulig å spørre på endepunktene "/house-consignment/transport-document/status" eller "/master-consignment/transport-document/status" for å få denne informasjonen.

Format på dokumentstatus

Dersom innsendingen er fullstendig vil feltet "documentStatus" ha verdien "SUCCESS", hvis ikke vil den ha "INCOMPLETE". Dersom status er "INCOMPLETE" vil det sendes med en "incompleteDocumentationReasonList" liste som lister opp årsakskoder for hvorfor innsendingen ble vurdert ufullstendig. Eksempler på verdier som kan komme som årsakskoder finner man her: https://toll.github.io/api/mo-kodeverk.html#incompleteDocumentationReason

{
  "documentNumber": "${documentNumber}",
  "type": "${documentType}",
  "documentStatus": "${documentProccessingStatus}",
  "incompleteDocumentationReasonList": [
    "${reasonsIfStatusIsIncomplete}"
  ]
}

Dokument status INCOMPLETE

Svar

{
  "documentNumber": "${documentNumber}",
  "type": "${documentType}",
  "documentStatus": "INCOMPLETE",
  "incompleteDocumentationReasonList": [
    "${reasonsIfStatusIsIncomplete}"
  ]
}

Årsak

Man har en innsendelse som ikke oppfyller kravene for en fullstendig innsending for valgt tollprosedyre. Se: https://toll.github.io/api/mo-vei.html#utfyllingForsend

Rettelse

Endre innsending slik at den oppfyller kravene for valgt tollprosedyre. Se: https://toll.github.io/api/mo-vei.html#utfyllingForsend. Send inn oppdatert innsending med endringene (HTTP PUT). Verifiser at "/transport-document/status" etter ny behandling etter hvert returnerer med status "SUCCESS"