Validation errors in MO APIs

Sequence for Submission - Synchronous and Asynchronous Responses

Also review this documentation: https://toll.github.io/api/mo-vei-EN.html#hvordanSende, this applies to all modes of transport.

In general, the submission of information works like this: a party sends a notification (POST) and receives a reference (requestId). By using the received reference, the party can query (GET) the result of the submission and, upon success, receive a permanent reference to the notification issued by Norwegian Customs. This is done at a separate endpoint (/validation-status) in the query API linked further down on this page. These services are asynchronous, so one must query repeatedly until a response is received. The validation response is usually available within 1 to 2 seconds, but it may take longer in some cases.
The query is made to the /validation-status endpoint, which will return the permanent reference, a Master Reference Number (MRN), upon success, along with a list of validation errors if they exist.

Example of a submission sequence for consignment (house consignment). The pattern is the same for other notifications, such as the master consignment and transport.

See caption — Figure: Sequence for submission of a notification for a house consignment

The MRN is used when notifications need to be updated or canceled (put/delete) to refer to previously submitted notifications. The validation endpoint can also return a list of document statuses to indicate missing information; see https://toll.github.io/api/mo-kodeverk-EN.html#incompleteDocumentationReason. The recommended method for submission is for the party to send all notifications for creation (POST) that are relevant and then wait 1-2 seconds before querying for validation (query API).

For example: If there are 500 house consignments for a master consignment in a transport, submit all 500 consignment notifications (POST), wait a couple of seconds, then request validation, the MRN and status for all 500 notifications is returned. If a status 404 is received when calling the validation endpoint, wait a little longer and query again. It is recommended to create an algorithm that makes repeated attempts until the validation response is received.

Synchronous Validation Errors

Synchronous validation errors (via HTTP) are returned as a response with status code 400 from the API. The reason for the validation error is returned as the content (body) of the response. When synchronous validation errors occur, the submission is immediately rejected and not processed further until the error(s) are corrected and resubmitted. If there are no synchronous validation errors, the response will have a status code 202 and contain a "requestId" field, which is then used to check for asynchronous validation errors during further processing.

Content Format of Synchronous Validation Errors

Validation errors are returned as one or more objects in a "validationErrors" list. The content of the list consists of one or more objects that indicate which fields caused the validation error, specified in the "field" field, and the reason for the error, specified in the "error" field.

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

Missing or Blank ("") Required Fields

Response

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

Cause

Fields that are required are missing or contain empty values. Fields that cannot have empty values will return "must not be blank" whether they are missing or empty. All other required fields will return "must not be null" if they are missing.

Correction

The field is required ("must not be null"), or must be present and have a value ("must not be blank").

Incorrect date/time format

Response

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

Cause

Date and time fields are in the wrong format. They must follow the ISO-8601 standard, which means they should be in the format: yyyy-MM-ddTHH:mm:ssZ.

Correction

Change the format to follow the ISO-8601 standard in the format yyyy-MM-ddTHH:mm:ssZ.

Incorrect Field Size – Numeric Values

Response

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

Cause

A numeric value has been provided that exceeds the maximum number of digits allowed before or after the decimal point ("."). If only integers are allowed, the number of digits after the decimal point (".", i.e., maxDecimalNumber) should be 0.

Correction

Adjust the number to be within the maximum number of integer digits (maxInteger value) and the maximum number of decimal digits (maxDecimalNumber value).

Incorrect Field Size – String (Text)

Response

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

Cause

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

Correction

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

Minst ett av feltene må være oppgitt

Response

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

Cause

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.

Correction

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

Må ha en av påkrevd verdi

Response

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

Cause

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

Correction

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

Response

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

Cause

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.

Correction

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

Response

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

Cause

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

Correction

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

Response

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

Cause

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

Correction

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

Response

{
  "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"
      }
    }
  ]
}

Cause

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

Correction

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

Response

{
  "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"
      }
    }
  ]
}

Cause

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

Correction

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

Response

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

Cause

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

Correction

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

Response

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

Cause

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.

Correction

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)

Response

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

Cause

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).

Correction

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

Response

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

Cause

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").

Correction

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

Response

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

Cause

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.

Correction

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

Response

{
  "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}"
      }
    }
  ]
}

Cause

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.

Correction

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")

Response

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

Cause

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.

Correction

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")

Response

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"
      }
    }
  ]
}

Cause

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")

Correction

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

Response

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

Cause

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-EN.html#cl141

Correction

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

Response

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

Cause

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

Correction

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

Response

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

Cause

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

Correction

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

Response

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

Cause

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

Correction

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

Response

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

Cause

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

Correction

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

Response

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

Cause

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

Correction

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

Response

{
  "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"
      }
    }
  ]
}

Cause

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

Correction

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 må typeOfIdentification være bestemt verdi

Response

{
  "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"
      }
    }
  ]
}

Cause

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

Correction

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

Response

{
  "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"
      }
    }
  ]
}

Cause

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

Correction

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

Response

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

Cause

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.

Correction

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

Response

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

Cause

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.

Correction

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)

Response

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

Cause

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")

Correction

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")

Response

{
  "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"
      }
    }
  ]
}

Cause

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

Correction

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"), er det spesifiserte feltet obligatorisk

Response

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

Cause

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).

Correction

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

Response

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

Cause

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

Correction

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")

Response

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

Cause

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.

Correction

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.

Response

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

Cause

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".

Correction

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-EN.html#incompleteDocumentationReason

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

Dokument status INCOMPLETE

Response

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

Cause

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

Correction

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"