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.
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 av 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.
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}", "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
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"