customs declaration service - acita

Customs Declaration Service

1Customs Declaration Service | Official Marking

Date: 21 January 2020

Time: 11:00 – 15:00

Venue: HMRC Business Centre,

Suites 1.11, 1.12, 1.13

1 Ruskin Square

Dingwall Road

Croydon

CR0 2WF


NCTS API changes

James Waters


NCTS API changesWe want to speak to you!

We are making some changes to the NCTS API that is currently in use

We would like to understand

• how you use it now

• what we can do to help you make these changes easier

• Understand any problems you have with the current API

• If we remove EDIFACT, how does that effect you?

And help us shape what you want the new API to do

For further details please contact:

[email protected]

SDST Stats

Raymond Cameron

Customs Declaration Service | Official Marking 4

Trade Test Queries

Total Number of Queries

Raised3821


Resolved3708


Outstanding113

Accurate up to and including 15th January 2020

Total Number of Queries Resolved Total Number of Queries Outstanding

97%

3%


Query Statistics by Month

Month Queries RaisedTotal responses

sent (per month)

Outstanding (from

that month)

July 201 227 0

August 174 186 3

September 240 238 7

October 200 176 8

November 182 194 22

December 130 174 34


Average Response Time

MonthAverage Response Time

(working days)

July 14

August 14

September 12

October 9

November 10

December 90

2

4

6

8

10

12

14

16

July August September October November December


CDS Trade Test – Answered Queries Log (AQL)

Raymond CameronMick Buckley


• Specialist Projects team commissioned by the Director and DD to deliver new tools and processes to support Software Developers and CSPs.

• To date delivered i) an FAQ and ii) a newsletter (about to be issued).

• Commissioned to deliver a tool that enables SWDs to view closed queries raised by the developer community without breaking commercial confidences.

• Explored IT solutions –restricted by time to deliver and commercial issues with suppliers.

• Opted for a simple spreadsheet solution that would provide quick results but requires a) a one-off historical query review and b) essential changes to current ticket processes


Background


What is the AQL and where can I find it?

• The AQL is a spreadsheet that has been introduced to provide software developers participating in the CDS Trade Test with visibility of queries raised by other developers.

• The AQL contains both the developer's query and HMRC's response.

• Each query is categorised to facilitate search.

• The AQL will be published on Google Drive.


How and when will the AQL be updated?

• Following the initial launch, we plan to update the AQL on a regular basis, frequency to be agreed.

Which queries will be included in the launched AQL?

• To ensure that content is relevant we have opted to include closed queries you raised from 4th September 2019, following Trade Test Release 8.1.0

• Queries have not been added to the AQL if:

• responses were superseded by updated guidance

• they contained personal information

• they related to personal requests (e.g. request for an application ID to be whitelisted)

• a final answer is yet to be provided

• they were chasing a response to a previous query

• they related to a past event – e.g. system outage.



• A query is only entered on the AQL if the developer raising it has given HMRC explicit permission to do so.

• If after receiving a response to your query you no longer wish to share it via the AQL, you must e-mail SDST within 5 working days.

Permission to share

• You can provide feedback at any time via the SDST

mailbox or via your Business Responsible Manager.

• We will be asking for structured feedback via a survey in

March as part of a formal review of the AQL.


How do I provide feedback to AQL?

Programme Updates

Dave Morgan


Programme Updates

KELs (Known Error Logs)

Tax Lines Document

High level overview of Release 2.6.0 to 3.6.0 / TT 8.4 - TT9.0

OGD Routes


CDS Trade Test Roadmap

V4.1

Last updated 17/01/2020

17| OFFICIAL | Trade Test Roadmap |

Tariff download

service.Submission &

cancellation of type:

• Exports Y, Z.

Authorisation

validation:

• SDP, EIDR,

AEO.

Licensing.

DMSTAX

consolidation

change.

Unhappy path

imports inventory

linking.

Removal of

workarounds on

inventory-linked

submissions.

Submission of types:

• A, B, D, E.

Aggregation of

declarations.

Relief & Suspension:

• Onward Supply

Relief.

• Inward

Processing.

Resolution of some

inventory linking

defects.

Authorisation

validation:

• SDP, AEO, EIDR

and special

procedures

authorisations.

Error code

transformation.

Procedure codes:

• 07 00 000.

• 51 71 000.

• 51 00 000.

• 51 21 000.

• 42 00 000.

• 40 53 000.

• 40 51 000.

Amendment of type:

• A, B, C, Y, Z.

Cancellation of type:

• A, B, D, E, F.

Further Relief &

Suspension.

• Increased range

of procedure

codes available.

Imports Immediate

Payments MOP:

• A (cash).

• B (cheque,

bankers draft).

• C (card).

• H (electronic bank

transfer).

All Imports

Declaration Types

Initial Exports

Inventory Linking

Further Imports

Frontier

Declarations

Exports

Supplementary

Declarations

Imports Frontier

Declarations and

Immediate

Payments

Tariff Download

Service

Imports

Supplementary

Declaration

TTM6.1.0

Imports

Enhancements

TTM6.0.0TTM5.1 Scope

Inventory linked types:

• C, F.

Submission of type:

• C, F, Y, Z.

Cancellation of type:

• C, Y, Z.

Currency conversion.

Front-End Credibility checks.

Declare goods with local DIT

/ RPA licences.

Value build-up.

CCG authorisation validation.

Validation of DAN / EORI

relationship.

Procedure codes:

• 40 00 000.

• 40 71 000.

• 61 23 000.

• 71 00 000.

• 42 71 000.

• 07 71 000.

CDS Trade Test Roadmap – Mar 2019

18

Key Notes:

1. Trade Test roadmap calls out key externally-facing functionality that has

been prioritised, but is not indicative of all releases into Production and is

not a definitive list of all content within each Trade Test delivery.

2. The order of releases into CDS Trade Test and their content are subject

to change. Specifically, multiple functional areas may be delivered

together or a single functional area may be broken into smaller releases.

In addition, system upgrades may be released into the Trade Test

environment between releases to resolve high priority defects.

TTM6.

2

Continued on Next Slide

| OFFICIAL | Trade Test Roadmap |

All C21 procedures.

Simulated quota

service.

CCG waiver &

document status

codes.

Tariff error handling

(CDS4-series).

Error code

enhancements &

granularity.

Ability to use CDS to

arrive, depart, and

consolidate inventory

linked declarations

submitted in CHIEF.

For TTM7.2.0:

CHIEF stubbed.

Date for full

integration TBC.

Submission,

amendment &

cancellation of types:

• J, K.

Excise movements.

Documentary and

physical controls for

multiple arrivals.

Multiple arrivals.

Multiple departures.

Automatic

departures.

Notification

enhancement: ROE

control type to SOE

topic type.

Submission,

amendment &


• A, B, C, D, E, F.

Authorisation

validation:

• IP, OP, TA, CW,

CSE.

Exports frontier

declarations A/D.

Validation of MUCR.

Movement of goods.

Consolidation.

Push Notification API

Enhancement.

File Upload Endpoint

Enhancement.

Submission,

amendment &


• J, K (limited

procedure codes).

Documentary and

physical controls.

View declaration

status & history

(Iteration 1).

Paper licenses.

Security scenarios

with Immediate

Payment and Duty

Deferment for:

• Preference.

• Relief &

suspension.

Excise calculations.

Further Reliefs &

Suspensions.

Front-End Credibility

enhancement.

Minimum import price

calculation.

Low value bulking.

Exports Dual

Running

All Exports

Declaration Types

Further Imports

Enhancements

Multiple Exports

Arrivals &

Frontier

Processing

TTM8.0.0

All Imports

Declaration

Types

TTM8.0.0

Exports Dual

Running TTM7.2.0

Initial Exports

Frontier

Movements

TTM7.1.0

Maintenance

Release

TTM7.0.0

Imports Frontiers,

Immediate

Payment, Exports

Supplementary

Declarations

TTM6.2.0

Amendment of Imports

declaration types:

• A, B, C, Y, Z.

Cancellation of Imports

declaration types:

• A, B, D, E, F.

Further Relief & Suspension.

• Increased range of

procedure codes

available.

Imports Immediate Payments

MOPs A, B, C, H.

Submission & cancellation of

Exports declaration type:

• Y, Z.

Authorisation validation:

• SDP, EIDR, AEO, MoU.

Exports Licensing.

CDS Trade Test Roadmap – Jun 2019

19

Key Notes:

1. Trade Test roadmap calls out key externally-facing

functionality that has been prioritised, but is not indicative of

all releases into Production and is not a definitive list of all

content within each Trade Test delivery.

2. The order of releases into CDS Trade Test and their content

are subject to change. Specifically, multiple functional areas

may be delivered together or a single functional area may

be broken into smaller releases. In addition, system

upgrades may be released into the Trade Test environment

between releases to resolve high priority defects.

TTM8.

0.0

TTM8.

1.0

Continued on Next Slide


Further error codes

enhancements.

Enhanced processing

of electronic DIT &

RPA licences.

Complex Excise

scenarios.

Imports Type B&E

rework (address

known errors).

Non-standard country

codes (exports).

ILE Query Service

Uplift (exports).

Dual Running

Location Codes

(exports)

Enhanced

cancellation

processing.

Declaration

processing using all

methods of payment:

• Cash accounts

• Guarantee

accounts

• Individual

Guarantees

Non-functional

infrastructure update.

Declaration

processing in

preparation for a UK

Exit from the EU:

• Roll-on Roll-off

Movements

(RoRo)

• Northern Ireland

Calculation of

Duties (NI)

• Parcels Relief

• Transitional

Simplified

Procedures (TSP)

• Postponed VAT

Accounting (PVA)

• Merchandise in

Baggage (MIB)

Amendment and

cancellation of a

declaration where an

electronic licence has

been declared.

Future

Enhancements

Additional

Methods of

Payment

Licensing

Anti-dumping and

countervailing

measures.

SPV / SIV calculation

of duties.

Interim deferment

payments and

deferment account

top-up.

Reprocessing errors.

Rules rework

(address known

errors).

Imports & Exports

Enhancements

TTM9.X.0

Imports & Exports

Functional

Enhancements

TTM9.0.0

Integration between CDS

Trade Test and CHIEF

HMUT established.

Aggregation and

consolidation of inventory

linked declarations submitted

on both CDS and CHIEF.

CDS Trade Test Roadmap – Jan 2020

20

Key Notes:

1. Trade Test roadmap calls out key externally-facing

functionality that has been prioritised, but is not indicative of

all releases into Production and is not a definitive list of all

content within each Trade Test delivery.

2. The order of releases into CDS Trade Test and their content

are subject to change. Specifically, multiple functional areas

may be delivered together or a single functional area may

be broken into smaller releases. In addition, system

upgrades may be released into the Trade Test environment

between releases to resolve high priority defects.

Trade Test Continues


View declaration

status & history

(Iteration 2).

EORI, Badge ID or

CSP authentication

details for identifying

originating party in

CDS.

Infrastructure

Release &

D1ND Rollback

TTM8.4.0

Non-functional

infrastructure update.

EU Tariff Data load to

align with Production

Infrastructure

Release

TTM8.3.0

D1ND

TTM8.2.0

Exports Dual Running with

HMUT Connectivity

TTM8.1.2

ERROR CODES & POINTERS RED TEAM OUTPUTS


•Change from supplier implemented into Trade

Test will allow multiple pointers to be returned

for 800+ rule instances

Principles:• Immediate focus on most frequently

triggered error messages and “quickwins” where HMRC can implementthe changes through in-houseconfiguration.

• Improve granularity of existingmessages where required.

• Update error message & add moredetail to errors where the opportunityexists to do so.

Aug 19

Sept 19

Nov 19

Jan 20

•Red Team Formed

• Initial analysis workshops complete

•50 new error codes created to add granularity

to CDS12056 & CDS10001

•6 new error with 20+ wording updates to

add granularity to CDS12007

•Tariff error messages updated

Red Team Overview

Milestones:


September 2019

CDS12056 split into 48 codes (47 new).

CDS10001 split into 4 codes (3 new) and wording updated.


CDS12056 is an error code previously triggered in the majority of instances where cross fieldvalidation has failed a validation test. The previously generic all-encompassing message has beenbroken down into forty-seven new error codes with more detailed corresponding error message(excluding BR675).

CDS12056Relation error: The combination of elements is not allowed

+ 44 New Error Codes with newly defined Error Messages

Previously Returned Error Message

CDS12056 Relation Error: The combination of elements is

not allowed

Updated Error Messages Returned

Improvements to CDS12056

NEW: CDS12120Relation error: The appropriate authorisation has not been declared for this Declaration Type (D.E. 1/2)

NEW: CDS12121Relation error: This combination of Additional Information codes (DE.2/2) is not allowed

NEW: CDS12070Relation error: The value supplied in Data Element 1 mandates the completion ofDate Element 2

Note: This document only contains specific examples andis not a comprehensive guide to all the changes. Pleaserefer to the CDS codelist document for full list of errorcodes & messages.


CDS10001 is an error code previously triggered for a number of different scenarios relating toobligatory declaration completion rules. The previously generic all-encompassing message has beenbroken down into four error codes (three new codes) with more detailed error messages.

CDS10001Obligation error: Mandatory Data Element has not been provided

NEW: CDS10002Obligation error: Data Element is not allowed

NEW: CDS10003Obligation error: Number of Occurrences exceeds what is allowed for the Data Element

Previous Error Message

CDS10001Obligation Error: Obligation rule not met

Updated Error Messages

Split of CDS10001

NEW: CDS10004Commodity code error: Mandatory data element not provided or format error or number of occurrences exceeds what is allowed for the data element


November 2019CDS120007 split into 2 additional codes

4 new error codes

Wording changes made to 20+ error messages

Tariff error messages updated for 6 scenarios


CDS12007 is an error code previously triggered for a number of different scenarios relating toauthorisations, licences and duty deferment validation failures. The previously generic all-encompassing message has been broken down into three error codes (2 new codes) with moredetailed error messages.

CDS12007Authorisation error: Authorisation has expired; orAuthorisation reference number does not belong to the party on the declaration; orAuthorisation reference number provided is not recognised

NEW: CDS12124License error: License has expired; orLicense ID cannot be recognised; orLicense ID does not belong to the party on the declaration; orLicense declared has Insufficient balance remaining; orLicense does not apply to the goods or country declared

NEW: CDS12125DAN error: Account number is not recognised; orAccount is suspended or revoked; orParties declared on the declaration do not have authority to use account number provided

Note: Due to the set up of the business rule templates,error codes could not be configured for each individualscenario within the License, DAN and Authorisation space.

Previously Returned Error Message

CDS12007Authorisation Error: Authorisation, License orDAN is invalid or required permissions not held

Updated Error Messages Returned

Split of CDS12007

Note: This document only contains specific examples andis not a comprehensive guide to all the changes. Pleaserefer to the CDS codelist document for full list of errorcodes & messages.


The wording of all other declaration validation related error messages have been reviewed andupdated where feasible. 20+ updates have been made. See below for examples:


CDS11003Relation Error: invalid Item total value

Other Error Message Updates

CDS11003Relation error: The value declared in Total Numberof Items (D.E. 1/9) does not correspond with thenumber of goods items on the declaration



CDS11003Relation Error: differing requested procedure

CDS11003Relation error: The Requested Procedure (D.E.1/10) for each goods item must derive the samedeclaration category. (eg H1)



CDS11003Uniqueness Error: non-unique amendment element

CDS11003Relation error: The same data element cannot beamended more than once in the same request.


Note: This document only contains specific examples and is not a comprehensive guide to allthe changes. Please refer to the CDS codelist document for full list of error codes & messages.


• Scenario 1 - Required certificate not supplied:

• DMSREJ points to the additional documents for the goods item throwing the error.

• DMSREJ confirms details of certificate required to fulfil the measure condition.

• DMSREJ confirms details of measure type & commodity code.

• The action code & measure condition code will also be returned.

• Scenario 2 - Quantity or Price per Unit is incorrect:

• DMSREJ points to the goods item throwing the error.

• DMSREJ confirms details of values required to fulfil the measure condition

• DMSREJ confirms details of measure type & commodity code.

• The action code & measure condition code will also be returned.

We have reviewed error handling for our Tariff application. We are now returning more informationwhen measure conditions are not fulfilled alongside various other updates. This additional informationnow gives a more detailed breakdown of the cause of the error as well as the actions required toresolve the issue.

Tariff Error Message Updates

Note: This document only contains specific examples and is not a comprehensive guide to allthe changes. Please refer to the CDS codelist document for full list of error codes & messages.


January 2020

Multiple pointers can be returned

Affects 863 rule instances

Note: The error codes used in this section are not yet be available in Trade Test or Production.


BR675 Headline Change

<_2_1:Error><_2_1:ValidationCode>CDS12070</_2_1:ValidationCode><_2_1:Pointer>

<_2_1:DocumentSectionCode>42A</_2_1:DocumentSectionCode></_2_1:Pointer><_2_1:Pointer>


<_2_1:SequenceNumeric>1</_2_1:SequenceNumeric><_2_1:DocumentSectionCode>68A</_2_1:DocumentSectionCode>

</_2_1:Pointer><_2_1:Pointer>

<_2_1:SequenceNumeric>6</_2_1:SequenceNumeric><_2_1:DocumentSectionCode>02A</_2_1:DocumentSectionCode><_2_1:TagID>360</_2_1:TagID>

</_2_1:Pointer></_2_1:Error>







</_2_1:Pointer></_2_1:Error><_2_1:Error>

<_2_1:ValidationCode>DMS12070</_2_1:ValidationCode><_2_1:Pointer>





<_2_1:SequenceNumeric>6</_2_1:SequenceNumeric><_2_1:DocumentSectionCode>02A</_2_1:DocumentSectionCode><_2_1:TagID>D028</_2_1:TagID>


Previous DMSREJ (example) Updated DMSREJ (example)

One Error Block Pointing

to Data Element 1


to Data Element 1


to Data Element 2

BR675 Relation Error has been updated to return two or more (where relevant) error blocks. Thisallows CDS to describe all relevant data items that have caused a validation rule to fail. There are 863instances of BR675 in the CDS2.6.0 release, all of which will return the newly designed DMSREJnotification.

CDS12070: Relation error: The value supplied in Data Element 1mandates the completion of Data Element 2.

The updated BR675 DMSREJ now points to Data Element 1 & DataElement 2. This will allow you to determine which Data Element ismandating the completion of which other Data Element.

Additional Examples of the updated BR675 can be found in“Understanding DMSREJ”


Understanding DMSREJ – A “How To” Guide


Principles and Assumptions:

• Schema is aligned to: WCO v3.6

• Multiple pointers are returned across multiple Error objects using WCO IDs

and no explicit link.

• No explicit link between pointers - Software has to infer that where a given

Error code is encountered, the next Error object contains the related pointer

for that same validation failure.

• Additional guidance has been provided by CDS to describe the number of

expected pointers per error code.

N.B. If error is related to D.E. 2/3 Document Type and D.E. 2/6 Deferred

Payment, then an additional error block will be received due to concatenated

fields. This means where two pointers are usually returned, then three will be

sent.

DMSREJ Analysis – Current Approach and WCO Pointer Structure

<Error><ValidationCode>CDS12056</ValidationCode><Pointer>

<DocumentSectionCode>42A</DocumentSectionCode></Pointer><Pointer>

<SequenceNumeric>1</SequenceNumeric><DocumentSectionCode>67A</DocumentSectionCode>

</Pointer><Pointer>


</Pointer><Pointer>

<SequenceNumeric>3</SequenceNumeric><DocumentSectionCode>02A</DocumentSectionCode><TagID>D006</TagID>

</Pointer></Error><Error>

<ValidationCode>CDS12056</ValidationCode><Pointer>



</Pointer><Pointer>


</Pointer><Pointer>


</Pointer></Error>


• Validation Code:

• The <ValidationCode> XML element captures the error code thrown identifying the

error. The error code can be mapped to an error message.

• Pointer:

• The <Pointer> XML elements are used to locate the specific WCO element that

has triggered the rejection of a declaration.

• Tag ID:

• Once a WCO element has been identified, a <TagID> XML Element may be used

to further specify the data element that has caused the rejection of the

declaration.

• Sequence Numeric:

• Where a declaration may have multiple instances of an item that a pointer could

refer to (e.g. second entry in D.E. 2/3 (Documents)), the <SequenceNumeric> XML

Element may be used to identify which specific instance has caused the

declaration to be rejected.

• Where a specific instance can not be identified as the offending item, a

sequence numeric will not be returned.

DMSREJ Analysis – Understanding the XML Elements

<Error><ValidationCode>CDS12056</ValidationCode><Pointer>



</Pointer><Pointer>


</Pointer><Pointer>


</Pointer></Error><Error>

<ValidationCode>CDS12056</ValidationCode><Pointer>



</Pointer><Pointer>


</Pointer><Pointer>


</Pointer></Error>


Example 1 – One Pointer


<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header>

<v1:dmsGatewayHeader xmlns:v1="http://ecf.dms.core/gatewayHeader/v1/"><communicationAddress>hmrcgwid:a000a0aa-aaa0-00a0-…-0aa0-0000a0a00000</communicationAddress><messageType>WCOTN</messageType>

</v1:dmsGatewayHeader></soap:Header><soap:Body>

<v3:notifyTrader xmlns:_2="urn:wco:datamodel:WCO:DocumentMetaData-DMS:2"xmlns:_2_1="urn:wco:datamodel:WCO:RES-DMS:2"xmlns:_2_2="urn:wco:datamodel:WCO:Response_DS:DMS:2"xmlns:v3="http://core.dms/.../v3/"><_2:MetaData>

<_2:WCODataModelVersionCode>3.6</_2:WCODataModelVersionCode><_2:WCOTypeName>RES</_2:WCOTypeName><_2:ResponsibleCountryCode/><_2:ResponsibleAgencyName/><_2:AgencyAssignedCustomizationCode/><_2:AgencyAssignedCustomizationVersionCode/>

<_2_1:Response><_2_1:FunctionCode>03</_2_1:FunctionCode><_2_1:FunctionalReferenceID>fc34cb18eefe4ddcbf07456b4d1a12a4</_2_1:FunctionalReferenceID><_2_1:IssueDateTime>

<_2_2:DateTimeString formatCode="304">20191107115245Z</_2_2:DateTimeString></_2_1:IssueDateTime><_2_1:Error>

<_2_1:ValidationCode>CDS71252</_2_1:ValidationCode><_2_1:Pointer>





<_2_1:DocumentSectionCode>92A</_2_1:DocumentSectionCode><_2_1:TagID>063</_2_1:TagID>

</_2_1:Pointer></_2_1:Error><_2_1:Declaration>

<_2_1:FunctionalReferenceID> KM_20191107111111</_2_1:FunctionalReferenceID><_2_1:ID>19GBAAAAAAAAAAAAA0</_2_1:ID><_2_1:RejectionDateTime>

<_2_2:DateTimeString formatCode="304">20191107115245Z</_2_2:DateTimeString></_2_1:RejectionDateTime><_2_1:VersionID>1</_2_1:VersionID>

</_2_1:Declaration></2_1:Response></_2:MetaData></v3:notifyTrader></soap:Body></soap:Envelope>

DMSREJ XML









<_2_1:FunctionalReferenceID>KM_20191107111111</_2_1:FunctionalReferenceID><_2_1:ID>19GBAAAAAAAAAAAAA0</_2_1:ID><_2_1:RejectionDateTime>

<_2_2:DateTimeString formatCode="304">…000A</_2_2:DateTimeString></_2_1:RejectionDateTime><_2_1:VersionID>1</_2_1:VersionID>

</_2_1:Declaration>

DMSREJ XML – Focus on the Error XML Blocks











</_2_1:Declaration>

DMSREJ XML – Understanding What’s LeftEr

ror

Blo

ck

Error Code: Describes what Error has been thrown

Po

inte

r

Pointer: Narrows down to the WCO Element causing the error to be thrown

Sequence Numeric: (Where a list exists) identifies offending instance of the list.

Tag ID: Narrows down to the WCO Element causing the error to be thrown

Please refer to “CDS Codelists and WCO References v1.41” to translate DocumentSectionCode & TagID

Note: The error codes used in this page may not yet beavailable in Trade Test or Production.











</_2_1:Declaration>

DMSREJ XML – Understanding What’s Left – Refer to WCO.Er

ror

Blo

ck

CDS71252: Licence not valid for declared Country of Origin

Po

inte

r

42A: Declaration

063: Country Code

62A: Goods Shipment

68A: 1st Government Agency Goods Item

92A: Origin

This DMSREJ tells us that the Country Code for the Originon the declaration of the first goods item on thedeclaration is not a valid Country Code.

Note: The error codes used in this page are not yet beavailable in Trade Test or Production.


• The Error Message is: Licence not valid for declared Country of Origin.

• The pointer points to:• The Country of Origin on the 1st goods item

(D.E. 5/15).

• D.E. 5/15 on the first goods item is “NZ”.

• Allowed Countries on the licence is “JP”.

With this information, we now know that the licence is not valid for the Country of Origin.

Therefore, we either need to use a different licence where Allowed Countries include “NZ” or submit a declaration for the goods where the Country of Origin is “JP”.

Resolving the Issue for this Example


Example 2 – Two Pointer


<_2_1:Error><_2_1:ValidationCode>DMS12070</_2_1:ValidationCode><_2_1:Pointer>














DMSREJ XML (Error Blocks Only)

CDS12056: Relation error: The combination of elements is not allowed42A: Declaration

67A: Goods Shipment

02A-360: The Document Status Code of the sixth entry in D.E. 2/3


42A: Declaration

67A: Goods Shipment

02A-D028: The Document Reason of the sixth entry in D.E. 2/3


CDS12056: Relation error: The combination of elements is not allowed

The 2 error blocks point to:• The 6th Document Status Code for Goods Item 1 on the

declaration• The 6th Document Reason for Goods Item 1 on the declaration



• The Error Message is: Relation Error: The value supplied in Data Element 1 mandates the completion of Data Element 2.

• The pointers point to:• The 6th Document Code on the 1st goods item (D.E.

2/3).

• The 6th Document Reason on the 1st goods item (D.E. 2/3).

• The declaration was completed as follows:• The 6th Document Status Code on the first goods

item on the declaration is: “XY”

• The 6th Document Reason on the first goods item on the declaration is : Null

Resolving The Issue

Looking at the guidance on the Paper Tariff:

• The Paper Tariff confirms that Document Status Code “XW” mandates a Reason be provided.

• To resolve this issue, we must provide a Reason when using Document Status Code “XW”.


https://www.gov.uk/guidance/documents-and-other-reference-codes-for-de-23-of-cds

Example 3 – Two Pointer














DMSREJ XML (Error Blocks Only)

42A: Declaration

67A: Goods Shipment

70A-161: The Previous Procedure Code in D.E. 1/10


CDS12119: Relation Error: Declared Additional Document (D.E. 2/3) is not allowed with this Procedure Code (D.E. 1/10 or D.E. 1/11)

The 2 error blocks point to:• Pervious Procedure Code for Goods Item 1 on the declaration• The 2nd Previous Document Code on the declaration

42A: Declaration

67A: Goods Shipment

99A-D019: The 2nd Previous Document Code in D.E. 2/1




• The Error Message is: Relation Error: Declared Additional Document (D.E. 2/3) is not allowed with this Procedure Code (D.E. 1/10 or D.E. 1/11).

• The pointers point to:• The Previous Procedure Code on the 1st goods item

(D.E. 1/10).

• The 2nd Previous Document Code on the declaration (D.E. 2/1).

• The declaration was completed as follows:• The Procedure Code for the 1st goods item of the

declaration is: “4051”• The Previous Procedure Code is “51”

• The 2nd Previous Document Code on this declaration is : “X337”

Resolving The Issue


• The Paper Tariff confirms that Previous Document Code “X337” is not a valid Previous Document Code for Procedure Code 4051.

• To resolve this issue, we can remove the Previous Document Status Code “X337”.


https://www.gov.uk/government/publications/requested-and-previous-procedure-codes-for-data-element-110-of-cds/imports-release-for-free-circulation-codes-01-to-44--3#code4051

Example 4 – Three Pointer

















DMSREJ XML (Error Blocks Only)<_2_1:Error>









CDS12056: Relation error: The combination of elements is not allowed42A: Declaration

67A: Goods Shipment

02A-360: The Document Status Code of the second entry in D.E. 2/3


42A: Declaration

67A: Goods Shipment

02A-D006: The Document Type of the second entry in D.E. 2/3



42A: Declaration

67A: Goods Shipment

02A-D031: The Document Category of the second entry in D.E. 2/3



The 3 error blocks point to:• Document Status Code for Goods Item 2 on the declaration• Document Type for Goods Item 2 on the declaration• Document Category for Goods Item 2 on the declaration

• N.B. Document Type + Document Category = DocumentCode



• The Error Message is: Relation error: The combination of elements is not allowed.

• The pointers point to:• The Document Code on the 2nd goods item (D.E.

2/3).

• The Document Status Code on the 2nd goods item (D.E. 2/3).

• D.E. 2/3 on the second goods item was completed as follows:

• The 2nd Document Code on this declaration is: “X001”

• The 2nd Document Identifier on this declaration is : “AAA11111111A”

• The 2nd Document Status Code on this declaration is: “RE”


Resolving The Issue

• The Paper Tariff confirms that Document Status Code “RE” is not a valid Document Status Code for Document Code “X001”.

• To resolve this issue, we can use one of the allowed Document Status Codes for Document Code “X001”.


https://www.gov.uk/guidance/documents-and-other-reference-codes-for-de-23-of-cds#appendix-5a-documents-and-other-reference-codes-union

Errors and Pointers


Should you have any questions regarding Errors and Pointers, please write to your BRM at the following address

[email protected]

Please note this mailbox is only to be used to collate queries relating to Errors and Pointers.

mailto:[email protected]

API Rate Limit / Questionnaire

Raymond Cameron


• It protects our platform from harm

(intentional/unintentional)

• Important because our platform supports a large number

of APIs, many of which are already Live

• Breaching the rate limit results in a 429 HTTP error (too

many requests). This does not result in permanent

disconnection from the platform. Once the peak drops

away, transactions will be accepted again.


• Make sure that applications have the required ‘bandwidth’

to do what they need to do

• Make sure that we’re able to adapt to changes in

requirement within a reasonable period of time

• All CDS applications are pre-approved for a rate limit of

500, but start at 150 transactions per minute.

• If you want your limit increased to 500, just send SDST an

email including the Application ID for the app which needs

increasing. Customs Declaration Service | Official Marking 53

• 500 transactions per minute

• 720,000 transactions per day

• 262.8 million transactions per

year


External Test Strategy

Elli Bell


External Test Overview

The purpose of CDS External Test is to provide an HMRC platform for all external partners (CSPs, SWHs, express operators, and declarants) to complete their

required assurance activities so they are confident in their readiness for migration to CDS. The CDS External Test offering has two core services: Trade Test and

Trader Dress Rehearsal, which are outlined below.

In addition to Trade Test and Trader Dress Rehearsal, HMRC also provides a range of Technical Documentation, including API specifications, Technical

Completion Matrix, and the online UK Trade Tariff to support the CDS development journey.

Purpose Audience & Availability Core Capabilities

Trade Test

A functional test platform where 3rd

party developers can assure their

software integration against CDS APIs

and a CDS back-end for all core

declaration processes and notification

types.

Code in Trade Test is one version

ahead of Production.

Audience:

• SWHs

• CSPs

• FPOs / EOs

• Traders with in-house capabilities

Available 24/7 to all whitelisted users.

Supported 9am – 5pm Monday to Friday,

excluding UK bank holidays via SDST.

• Test trader and account data

• Process all declaration types and procedures

• Integration testing for all APIs

• Exports inventory linking, including dual running

arrivals via CHIEF (HMUT)

• Simulated controls, quota, immediate payments

services

Trader Dress

Rehearsal

A CDS-like service to support

declarants in submitting all types of

declarations to expose all actors in the

supply chain to declaration processing

in CDS as part of their final assurance

activity prior to migration.

Code in TDR matches Production.

Current: Limited number of migrating traders

for a pre-agreed period of time.

Future: All declarants for up to 4 weeks after

migration to CDS.

Available 24/7 to all subscribed declarants. To

be supported by CDS Live Services during

open TDR / migration (TBC)

• Live trader and account data

• Process all declaration types and procedures (Note:

does not currently support inventory linking)

• Integration testing for all APIs (Note: current service is

Customs Dec API only)

• Simulated controls, quota, immediate payments

services


External Test Phases

After receiving access to CDS technical specifications and business documentation, developers (SWHs, CSPs, FPOs, and traders with in-house capabilities) use

Trade Test to assure their software integration against CDS APIs and a CDS back-end for all core declaration processes and notification types.

Once software is “declarant-ready”, Trader Dress Rehearsal (TDR) is used to expose all actors in the supply chain to declaration processing in CDS as part of their

final assurance activity prior to migration to CDS. Multiple declarants using the same software package may go through separate TDR and migration phases.

Enhanced support will be provided during Trader Dress Rehearsal for the first declarant migrated to CDS for each developer or CSP.

Develo

per

Dec

lara

nt D

ecla

ran

t 1

Decla

ran

t 2

Decla

ran

t 3

Receive

Documentation

Software

Declarant-

Ready

Analysis

& DesignDevelopment Test

Declarant

MigratesTDR Declarant 1

Prepare for CDS

Trade Test

Declarant


Declarant



Trade Test Service: Purpose and Principles

Purpose: Trade Test is an HMRC functional test platform where 3rd party developers (SWHs, CSPs, FPOs, and traders with in-house capabilities) can assure their

software integration against CDS APIs and a CDS back-end for all core declaration processes and notification types.

Principles:

1. The scope of the Trade Test service is one release ahead of Production or aligned with Production depending on the delivery lifecycle. Functionality is

typically delivered into Trade Test a week before Production.

2. Trade Test is not to be used by declarants. The service targets developers building applications to integrate with CDS. Developers should test all declaration

processing scenarios and notifications for CDS and be able to fully assure their integration with CDS through the Trade Test service.

3. Trade Test is the CDS equivalent of CHIEF HMUT. There are no plans to decommission the Trade Test environment and the capabilities offered will become

part of the ongoing CDS Live Service, providing a platform for assurance on any future fix or enhancement to CDS.

4. Trade Test uses Production-equivalent applications as much as possible for both Imports and Exports processing, but some components may be stubbed or

particular scenarios may be limited for business or technical reasons.

5. Intervention by HMRC users should not be required to support BAU declaration processing and testing in Trade Test.

6. No live party or deferment account data should be used in Trade Test.

7. Full performance and throughput analysis should not be conducted in Trade Test (e.g. to break point). The Trade Test environment has not been configured

and sized to the same standard as a Production environment. For technical reasons any measured or perceived levels of system performance should not be

expected to be matched in the final Production system. The speed at which Trade Test processes declarations is controlled and delays may be experienced

during peak use. Please contact HMRC for specific analysis requirements.

8. Automated testing and testing of legitimate business volume scenarios are supported in Trade Test.

9. Open and continual access to the service will be available to validated developers that have been whitelisted to the Trade Test APIs.

10. Trade Test is supported Monday to Friday (9am – 5pm), excluding UK bank holidays, but service is available through the environment 24/7.

11. Developers should complete integration testing for all core customer processes in Trade Test before proceeding to TDR or migration to CDS.


Trader Dress Rehearsal Service: Purpose & PrinciplesPurpose: Trader Dress Rehearsal is the HMRC platform targeting the trader / declarant community. It is used to expose all actors in the supply chain to

declaration processing in CDS as part of their final assurance activity prior to migration to CDS.

Principles:

1. Scope of the Trader Dress Rehearsal service to always aligned to Production. Functionality is typically delivered into TDR the day after a Production

release.

2. Trader Dress Rehearsal is not intended for functional testing (e.g. by developers). Declarants should use Trader Dress Rehearsal to assure their

declaration processing scenarios prior to CDS migration using their own party and deferment data.

3. Trader Dress Rehearsal is not a replacement for CHIEF Live Training but provides an open and usable service to support transition to CDS. It is funded as

a finite service, currently planned to end once migration to CDS is complete.

4. Trader Dress Rehearsal uses Production-equivalent applications as much as possible for both Imports and Exports processing, but some components

may be stubbed or particular scenarios may be limited for business or technical reasons.

5. Intervention by HMRC users should not be required to support BAU declaration processing and testing in Trader Dress Rehearsal.

6. Real party and deferment account data will be used to allow declarants to “dress rehearse” using their own information. Data will be handled using the

same access security controls as Production to ensure confidentiality of data.

7. Full performance and throughput analysis should not be conducted in Trader Dress Rehearsal (e.g. to break point). The Trader Dress Rehearsal

environment has not been configured and sized to the same standard as a Production environment. For technical reasons any measured or perceived

levels of system performance should not be expected to be matched in the final Production system. The speed at which Trader Dress Rehearsal

processes declarations is controlled and delays may be experienced during peak use. Please contact HMRC for specific analysis requirements.

8. Automated testing and testing of legitimate business volume scenarios are supported in Trader Dress Rehearsal.

9. Open and continual access will be available to “legitimate” declarants (with EORIs) that are already subscribed to CDS for the duration of each declarant’s

Trader Dress Rehearsal period, which extends for up to 4 weeks after migration (Note: not currently enabled).

10. Enhanced support will be provided for the first declarant migrated to CDS for each developer or CSP. For other customers, Trader Dress Rehearsal will be

supported Monday to Friday (9am – 5pm), excluding UK bank holidays, but service will be available 24/7.

11. Developers should complete functional integration testing for all core customer processes in Trade Test prior to TDR. Declarants should have completed

sufficient testing in Trader Dress Rehearsal to be confident in all major declaration processes prior to submission in Production.



Nicholas Swaffer / Phillip Le Quesne

Migration Update

Agenda

Introduction

Exports Migration Actors and Phasing

Implications of phase one on development,

testing and rollout

Snapshot - Dual Running for export migration

Explanation of what that means for migration and

testing

Imports - frontiers update

Discussion

Migration session

MigrateLoaders

DEP, ConsolidatorsAir Sheds

CSP Testing /proving

CSP Migration

SWDs & Declarants

Prove Process

Migration

Phase 1 Entry gate

Phase 1 Exit gatePhase 2

Entry GatePhase 2

Proving

Phase 1Pre Phase 1

MigrationPlanning Phase 2 Testing

Phase 2

Proving Phase 2

Roll out strategy

CSP Readiness

Loader readiness

SWD and movement

testing

Phase 2 Entry Gate

Exports Migration Actors and Phasing

CHIEFDeclarations

100%

CDSDeclarations

0%

CDA

Currently Phase 1 Phase 2

CDA CDA

10

0% 0

%

50

%

0%

0%

0%

CSP/Loader CSP/Loader CSP/Loader

0%

50

%

• All movement messages submitted to CHIEF

• All declarations submitted to CHIEF

• Movement messages start to be migrated to CDA

• All declarations submitted to CHIEF

• All movement messages submitted to CDA• Declarations start to migrate to CDS

• Key phase of CSP migration where community readiness of loaders, DEPS, SHEDs and consolidators needs to have been completed before exit to phase 2

• Declarants will initially be managed across to CDS, reducing volumes on CHIEF.

• True open migration may only occur once in phase two when all CSPs have migrated to CDS.

CHIEFDeclarations

100%

CDSDeclarations

0%

CHIEFDeclarations

50%

CDSDeclarations

50%

10

0%

Movement Messages

Migration to CDA

Migration to CDS

Snapshot - Dual Running for export migration

Imports update

&

General discussion


CDS Performance Update

Dougie Mackenzie – Volumetrics Lead, CDS Performance, CDIO

January 2020


Summary

If CDS can handle submissions of 10 declarations per second (DPS) at a 5 second response time, then we can meet the priority 1 declaration SLAs as agreed with the business for March 2020

If CDS can handle submissions of 14 declarations per second (DPS) at a 5 second response time, then we can meet all prioritised declaration SLAs as agreed with the business for March 2020


Summary

CDS Major Performance Milestones

DecFeb

March

8 declarationsper second

14 declarationsper second

Enhanced and Prioritised Queue

99 Line Item Declarations


The Context

The “throttle” and “declaration optimisation service”

MDTP MDG

High Priority Queue

Medium Priority Queue

LowPriority Queue

Priority Overflow Queue*

Declaration Optimisation

Service

DMS

Intermediate Queue

Throttled Queue

Max queue length set to 60s

Max queue length set to 60m

Max queue length set to 3hrs

Expired items

The solution diagram illustrates the flow of our volume of declarations and messages through queues and solution components

Mix of H priority / Overflow items

This priority overflow queue (or “expired queue”) will hold items which have exceeded the maximum queue length for medium and low priority declarations / messages. In the instance where the overflow queue is populated the declaration optimisation service will pull messages from the overflow queue and the high priority queue at a 50/50 ratio until the overflow queue is empty

Note: Arrows represent logical flow of declarations and messages through the system and do not represent whether system is pushing or pulling information between components

This queue is built with a 2x throttle capacity, which may result in an additional 2 second delay to high priority declarations


The Context

How the prioritisation works

Scenario 1(Total number messages) =< (Intermediate Queue length)The total messages on all queues is less than the Intermediate queue length.All messages will be transferred onto the Intermediate queue.

Scenario 2(Total number of messages) > (Intermediate Queue length) AND (Length P1 Queue + Expired Queue Length) =< (Intermediate Queue length)The total messages on all queues is greater than the hopper queue length. All P1 and expired messages can fit on the Hopper queueAll messages from P1 queue and expired queue are transferred to the Intermediate queueIf the hopper queue still has availability, transfer any available messages from P2 queue onto Intermediate queueIf the hopper queue still has availability, transfer any available messages from P3 queue onto Intermediate queue

Scenario 3(Total number of messages) > (Intermediate Queue length) AND (Length P1 Queue + Expired Queue Length) > (Intermediate Queue length)The total messages on all queues is greater than the Intermediate queue length. Not all P1 and expired messages can fit on the Hopper queueThe Intermediate queue should be filled with half messages from the P1 queue and half messages from the expired queue. Giving the P1 queue and the expired queue messages equal priority.

P1 P2 P3 Expired Queue

P1 P2 P3 Expired Queue


All results indicative

Agreed Prioritisation, SLAs & Associated Volumes

2018 CHIEF Priority Declaration and Message Volumes for MVP

Priority SLAsImports / Exports

Declaration / Message Type

Volumes%

Contribution

Priority Volumes

Priority %

High95% processed in 5s99% processed in 20s100% processed in 65s

Import

GPNs (Arrivals) 5,184,800 7.50%

16,121,365 22.99%

Frontier (stand-alone)

- 0.00%

Amendments / cancellations

427,072 0.62%

Export

GPNs (Arrivals) 10,396,348 13.54%

Frontier (stand-alone)

- 1.50%

Amendments / cancellations

113,145 0.16%

Medium90% processed in 5m95% processed in 10m100% processed in 1hr

Import Pre-lodged 5,184,800 7.50%15,581,148 22.22%

Export Pre-lodged 10,396,348 13.54%

Low45% processed in 1hr92% processed in 2hr100% processed in 3hr

Import Supplementary 37,510,094 54.30%38,428,222 54.80%

Export Supplementary 918,128 1.33%

70,130,735*

*Total equates to c.55m declarations

The volume of Frontier standalone declarations is being investigated but at this stage they are all being modelled as a pre-lodge and a GPN as a worst case scenario

NB: this prioritisation will be revisited following MVP



The Results of 2018 CHIEF Analysis

Modelling the Throttle for P1 declarations and messages

Rules1) It is assumed that high priority Declarations are prioritised2) The results are based on minute by minute total declaration data 2018 3) The analysis only indicates when high priority declarations don’t queue for longer than a minute, there may be spikes within the minute that queue

declarations to the next second(s) – and therefore, we advise applying an uplift to understand when queues are below 20 seconds or 5 seconds etc.

Results impact on High Priority declarations and messagesThe analysis of P1 declarations show that if the declaration per minute capacity is greater that 440 then the P1 declarations will not queue. This equates to 7.3dps

Analysing these numbers against the peak P1 declaration minutes across the whole of 2018, there is 1 instance where 10dps is not sufficient to keep the queue less than 1 minute, so this is an outlier. A 10dps minimum requirement for P1 declarations is suggested

318330

437 437 437

356

310

0

50

100

150

200

250

300

350

400

450

500

Top 5 Peaks - Sep 18 min data

average

median

st dev

max

min

-3 -2 -1 Peak 1 2 3

DPM



The Results of 2018 CHIEF Analysis

Modelling the Throttle on P3 declarations

Rules1) The results are based on hour by hour total declaration data for the whole of 20182) The analysis only indicates when P3 declarations queue for hour long periods (we know from the previous slide that at 10dps and higher there will be

no queue for P1 declarations)3) All P2 declarations are queued within the hour at both 10dps and 14dps

At 10 dps it is forecast that 5.4% of supplementary declarations (low priority) will go into the “priority overflow queue”. At 14 dps all declaration types are forecast to meet their SLAs

10 dps 14 dps

P3 RATIO: Results - Hours # %

Total 2018 volumes 38,428,222 N/A

Total volume of declarations processed without being queued 22,048,298 57.38%

Total volume of queued declarations 16,379,924 42.62%

1 ≤ t < 2 hours 15,866,016 41.29%

2 ≤ t < 3 hours 513,908 1.34%

3 ≤ t < 4 hours 0 0.00%

4 ≤ t < 5 hours 0 0.00%

5 ≤ t < 6 hours 0 0.00%

6 ≤ t < 7 hours 0 0.00%

7 ≤ t < 8 hours 0 0.00%

8 ≤ t < 9 hours 0 0.00%

9 ≤ t < 10 hours 0 0.00%

10 ≤ t hours 0 0.00%

Max queue time (hours) 3.00 42.62%

P3 RATIO: Results - Hours # %

Total 2018 volumes 38,428,222 N/A

Total volume of declarations processed without being queued 12,011,057 31.26%

Total volume of queued declarations 26,417,165 68.74%

1 ≤ t < 2 hours 13,982,298 36.39%

2 ≤ t < 3 hours 10,373,151 26.99%

3 ≤ t < 4 hours 2,061,716 5.37%

4 ≤ t < 5 hours 0 0.00%

5 ≤ t < 6 hours 0 0.00%

6 ≤ t < 7 hours 0 0.00%

7 ≤ t < 8 hours 0 0.00%

8 ≤ t < 9 hours 0 0.00%

9 ≤ t < 10 hours 0 0.00%

10 ≤ t hours 0 0.00%

Max queue time (hours) 4.00 68.74%


End
