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

The content of the field has exceeded the maximum number of characters or contains fewer than the minimum number of characters.

Correction

Adjust the content to be within the minimum and maximum size limits.

At Least One of the Fields Must Be Provided

Response

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

Cause

In some cases, at least one of several fields must be provided. The object specified by in (fieldname) must contain a value in at least one of the specified fields.

Correction

Ensure that at least one of the specified fields is provided and has a valid value in the object.

Must be one of (required)

Response

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

Cause

The field (fieldname) must be submitted and can only have one of the specified values.

Correction

Submit the field with one of the required values (e.g., valueOne ...).

Asynchronous Validation Errors

If a submission does not have any validation errors that lead to immediate rejection (synchronous validation errors), it will be processed further. However, validation errors may still occur later, during the processing. These errors will be returned in response to a call to the corresponding "/validation-status" endpoint once the processing is complete. Validation errors will be associated with the "requestId" value received in the original submission and returned as asynchronous validation errors.

Content Format for Asynchronous Validation Errors

If validation errors are found once asynchronous validation is complete, the "/validation-status" endpoint will return an HTTP code 202 with content where the "status" field has the value "FAILURE".
Validation errors are returned as one or more objects in a list called "validationErrorList". The content of the list consists of objects that indicate the path to the field(s) that caused the validation error, specified in the "pointer.messageElementPath" field, and the cause of the error is specified in the "description" field.

Until the processing is complete, the response from the endpoint will return an HTTP code 404.

If there are no validation errors and the submission is successful, the "status" field will have the value "SUCCESS".

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

The Field Must Have a Value Specified by the Code List

Response

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

Cause

The field specified in "messageElementPath" had a value not found in the code list (table of valid values). One of the values from the code list, as indicated by ["codeOne", "codeTwo", ...], is required for the field.

Correction

Change the field to have a value that corresponds to a valid code list value required for the field. Resubmit the request. Use the new "requestId" received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

Invalid Country Code

Response

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

Cause

The field specified in "messageElementPath" has a country code that was not found among the valid ISO-3166 Alpha-2 codes.

Correction

Change the field to use a valid ISO-3166 Alpha-2 code. Resubmit the request. Use the new "requestId" received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

Invalid MRN Format for the Specified Export Type

Response

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

Cause

The MRN for the "exportId" field specified in "messageElementPath" is provided in a format that is invalid for the specified export type ("typeOfExport").

Correction

Change the field's value to use a valid MRN format. Resubmit the request. Use the new "requestId" received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

The Provided MRN Has an Incorrect Length for the ECS_EXPORT Export Type Identifier

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

The MRN for "exportId" specified in "messageElementPath" is provided with a length that is invalid for the specified export type, ECS_EXPORT.

Correction

Verify that the MRN is correct and has the required length for the export type. Resubmit the request. Use the new "requestId" received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

Road Transport Only (road-API): Export of type AES_EXPORT was not found or has incorrect status in 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

The export is of type AES_EXPORT, but the exportId was not found or has an incorrect status in AES. In addition to there being no export declaration with the specified ID, other possible causes include:

The export declaration exists but has not been released from the departure customs office
The export declaration exists but has already been registered for export.

Correction

Verify and, if necessary, correct the exportId to ensure it is correct and has the appropriate status in AES. Resubmit the request. Use the new requestId received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

If a value indicating the procedure the consignment was subjected to before crossing the border into Norway ("outgoing procedure") is specified, it must be one of the codes allowed in the code list

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

The value for the outgoingProcedure field was not found in the OutgoingProcedure code list: https://toll.github.io/api/mo-kodeverk-EN.html#outgoingprocedure.

Correction

Change the value to one of the values available in the OutgoingProcedure code list. Resubmit the request. Use the new requestId received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

If a value is provided in a field using un location codes ("UNLOCODE"), it must be one of the values found in the CL144 UNLOCODE code list

Response

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

Cause

Several fields in the notifications require a value based on the UN Location Codes, "UNLOCODE". The field specified in "messageElementPath" contains a submitted value that was not found in the CL144 UNLOCODE code list.

Correction

Change the value to one of the values available in the CL144 UNLOCODE code list. Resubmit the request. Use the new requestId received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

Cannot submit exportFromEu list if the procedure the consignment was subjected to until crossing the border into Norway ("outgoing procedure") is transit (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

If the procedure the consignment was subjected to until crossing the border into Norway (in the outgoingProcedure field) has the value TRA (for transit), you cannot submit a reference to export from the EU (exportFromEU).

Correction

Remove exportFromEU from the import procedure or change the outgoingProcedure. Resubmit the request. Use the new requestId received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

If neither address nor location is specified, UN location code ("UNLOCODE") is required

Response

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

Cause

The object specified in "messageElementPath" has neither an "address" nor a "location" provided. In this case, the "unloCode" field must be provided and have a value for this object. This applies to the "placeOfLoading", "placeOfUnloading", "placeOfAcceptance", "placeOfDelivery".

Correction

Add a valid "unloCode" or, alternatively, add an "address" and/or "location" to the object. Resubmit the request. Use the new "requestId" received for the new submission and verify that asynchronous validation returns the "status" field with the value "SUCCESS" once the new processing is complete.

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"