TTM6.0.0 live and available for testing

This release includes upgrades to all the applications in the CDS infrastructure, a result of which mitigates some of the notification issues seen previously. In the interests of transparency, please note that some underlying issues within the applications remain under investigation and re-test. It is still possible there may be some notification issues that require a restart as a temporary workaround.

TTM6.0.0 deployment end-to-end was tested by submitting our XML sample messages into CDS from v2.0 of the API and all expected notifications were received.

The Following functionality is available: 

  • Relief & suspensions: Onward Supply Relief (OSR) and Inward Processing (IP)
  • Validation of SDP, AEO, EIDR, and special procedures authorisations
  • Aggregation of declarations
  • Transformation of error codes to use CDS-- or CDS4—prefix

The inventory linking unhappy path defects are not in this release. This release does, however, correct the defect with the ROE values in the declaration status notifications. These now correctly return ROE = 6, indicating that risking has taken place with no controls.

Supporting Documentation

TTM6.0.0 Scenarios – this provides a high-level summary of the test scenarios enabled by this release. This is a new format based on feedback that scope documentation did not provide enough detail about the test scenarios available within the functional areas. If you have any further comments on the scope documentation, please let us know.

TTM6.0.0 Test Data Cover Sheet– please note that the test data used in CDS Trade Test has now changed due to the introduction of authorisation validation rules. Please refer to the TTM6.0.0 Test Data Cover Sheet for a library of the test data available and please be sure to use the correct authorisation ID number for the EORI used in all happy path tests submitted during TTM6.0.0.

 XML Samples – new XML samples have been produced for TTM6.0.0 alongside updated versions of the samples from previous milestones.

C_Sample_TC01_Payload_v3.3 C_Sample_TC01_Scenario_v3.3 C_Sample_TC01_DMSACC_v3.3 C_Sample_TC01_DMSROG_v.3.3 C_Sample_TC01_DMSACC_v3.3 C_Sample_TC01_DMSROG_v.3.3 C_Sample_TC01_Payload_v3.3 C_Sample_TC01_Scenario_v3.3 C_Sample_TC01_DMSROG_v.3.3 C_Sample_TC01_Payload_v3.3 C_Sample_TC01_Scenario_v3.3 C_Sample_TC01_DMSACC_v3.3

Cancellation_Sample_TC02_DMSRCV_v1.0 Cancellation_Sample_TC02_DMSREQ_DMSINV_v.1.0 Cancellation_Sample_TC02_Cancellation_Message_v1.0 Cancellation_Sample_TC02_DMSACC_v1.0


F_Sample_TC01_Payload v1.2


IVL_Sample_Scenario_TC01_v1.2 IVL_Sample_TC01_DeclarationStatusNotification_1_v1.2 IVL_Sample_TC01_DeclarationStatusNotification_2_v1.2 IVL_Sample_TC01_DeclarationStatusNotification_3_v1.2 IVL_Sample_TC01_DMSACC_v.1.2 IVL_Sample_TC01_DMSRCV_1_v.1.2 IVL_Sample_TC01_DMSRCV_2_v1.2 IVL_Sample_TC01_DMSRES_DMSROG_v1.2 IVL_Sample_TC01_Goods_Arrival_Message_v.1.2 IVL_Sample_TC01_Payload_v1.2 IVL_Sample_TC01_ValidateMovementRequest_1_v.1.2 IVL_Sample_TC01_ValidateMovementRequest_2_v.1.2 IVL_Sample_TC01_ValidateMovementResponse_1_v.1.2 IVL_Sample_TC01_ValidateMovementResponse_2_v.1.2



Y_Sample_TC01_ DMSACC_v.1.3







Y_Sample_TC04_Relief_OSR_Payload_DMSACC_v1.2 Y_Sample_TC04_Relief_OSR_Scenario_v1.2

Y_Sample_TC04_Relief_OSR_ DMSTAX_DMSCLE_v.1.2

Y_Sample_TC05_DMSREJ_Scenario_v1.2 Y_Sample_TC05_DMSREJ_TraderNotification.v1.2 Y_Sample_TC05_DMSREJ_Payload_v1.2









Z_Sample_TC04_Suspension_IP_Payload_v1.2 Z_Sample_TC04_Suspension_IP_Scenario_v1.2





Z_Sample_TC05_AGG_Payload_DMSACC_v.1.2 Z_Sample_TC05_AGG_Payload_DMSTAX_DMSCLE_v1.2


Z_Sample_TC01 has been temporarily removed due to a defect found that impacts this scenario in this phase of Trade Test. Additionally, the structure of the cancellation message has changed. Please see the Known Error Log section for more information about these defects. Once they have been resolved, Z_Sample_TC01 will be added back into the Trade Test XML sample messages with any relevant updates and an updated version of Cancellation_Sample_TC01 will be issued.

TTM6.0.0 Known Error Log (KEL) – an updated version of the KEL  is expected to be issued on Monday, 28/01, at the latest. 

This document is being updated to remove the errors from TTM5.1 that are resolved in this release, as well as to include new errors identified through our testing of TTM6.0.0. This new KEL will also be added to the online forum. Please refer to the online forum for the latest updates against the Trade Test known errors.

There are two key defects which have impacted the XML samples and may impact your testing in TTM6.0.0. These will also be included on the next published KEL.

  • KEL ID 043a cancellation request cannot be submitted that includes the amendment reason text within the XML structure during TTM6.0.0 only. If the free text amendment reason field is included, processing of the cancellation request will fail. This is a new defect which did not occur in TTM5.1 and a fix is being developed for the next functional release into Trade Test.
  • KEL ID 044 declaration is incorrectly rejected in a direct representation scenario. If the agent is authorised to use the DAN owned by the importer (function code = 2), the declaration should be accepted and cleared.

 Improvements to the Pull Notification API – TTM6.0.0 also introduces a set of improvements to the Pull Notifications API. While the use of these enhancements are entirely optional they do provide significant benefit when retrieving notifications.

The capability to repeatedly retrieve the same notification in the event of that notification being lost or not successfully received or processed is now in place. Rather than deleting the notification once pulled, the API now retains pulled notifications. All notifications are kept for a maximum of 14 days from when they are first sent, after which time they cannot be retrieved.

Currently the Pull Notifications API works as follows:

  • GET /notifications - returns a list of all notifications IDs available to be pulled for a given Client ID.
  • DELETE /notifications/{Id} - retrieve and delete the requested notification.

 The current implementation does not allow for a failure scenario where a notification needs to pulled more than once in the event of a client side failure to process the notification.  To rectify this the Pull Notifications API has been extended by adding the following new endpoints to the API:

  • GET /notifications/unpulled - returns a list of new notifications IDs only. With ‘new’ being defined as notifications that have not been previously pulled.
  • GET /notifications/unpulled/{notificationId} - returns an individual new notification. Instead of the previous DELETE operation,  pulled notifications are now retained with a ‘pulled’ status for a period of 14 days from the date the notification was generated.
  • GET /notifications/pulled - returns a list of previously pulled notification IDs only, the response will contain IDs for all pulled notifications for a given Client ID, for the past 14 days.
  • GET /notifications/pulled/{notificationId} - returns an individual, previously pulled notification up to 14 days from the date the notification was generated.

 Improvements to the Pull Notifications API:

  • The previous Pull Notifications API endpoints  (/notifications and /notifications{Id}) will remain available and unchanged. This offers a choice of whether to remain integrated with the endpoints, or start developing to consume the new endpoints.
  • If the existing ‘DELETE /notifications/{Id}’ and new ‘GET /notifications/pulled’ endpoints are used in conjunction, an incomplete list of previously pulled notifications will be returned as the DELETE endpoint will have removed them from the queue. Therefore we advise against using a combination of the existing endpoints and the new ones detailed above.
  • Any enhancements will be introduced to the new endpoints only and the current GET and DELETE endpoints will eventually be deprecated. Precise timescales for deprecation are to be confirmed but will be prolonged.

Inventory linking

(For software houses that are not testing inventory linking, this is for information only)

There are some limitations to the inventory linking functionality that is available in CDS Trade Test. This information will remain documented on the Known Error Log (KEL), but we wanted to bring a few specific elements to your attention.

 TTM5.1 is limited to ‘happy path’ responses to the inventory match request only. While we have resolved the defect in our core product that was preventing ‘unhappy path’ journeys following an inventory mismatch, a defect was found late in our test cycle which impacts the outbound notifications in this scenario. This therefore remains out of scope for this phase of Trade Test.

 There will be two elements to the ‘unhappy path’ which will be released into CDS Trade Test once resolved:

  • Inventory mismatch is received by CDS, after which the declaration is held in a registered state for 4 hours. Once this timer has elapsed, the match request is re-sent and, unless the inventory match is confirmed, the declaration is rejected.
  •  Inventory mismatch is received by CDS, after which the declaration is held in a registered state for 4 hours. Without waiting for the timer to elapse, an amendment can be made by the CSP that leads either to an inventory match or confirms the mismatch. The declaration is either accepted or rejected, based on the results of the amendment and inventory matching.

 Additionally, the following workarounds will be in place during TTM5.1. Once the underlying issue causing each workaround is resolved, a fix will be released into Trade Test and communicated:

  •  MUCR – an inventory linked declaration is not processed and all notifications received unless the MUCR is declared at both the Header and Item level on the declaration. The end-state requirement is for the MUCR to be declared at Header level only.
  •  Package Quantity – the total package quantity used for inventory matching should be entered in the first instance of DE 6/10 at the Item level, as well as in DE 6/18 at Header level. This is due to a defect that prevents 6/18 from being mapped to the inventory match request. Instead, the value from the first instance of 6/10 (Declaration/GoodsShipment/GovernmentAgencyGoodsItem/Packaging/QuantityQuantity) will be returned in the inventory match request.
  • Border Transport Means – the (optional) data element BorderTransportMeans/RegistrationNationalityCode must be included at the Header level on the initial pre-lodged Type F declaration to ensure the final clearance notification is received following the arrival of the goods through the Goods Arrival notification.

 We recognise that unhappy path testing is a key journey for your development and that these workarounds impact your ability to develop and test against the end-state solution. However, the programme has taken the decision to move forwards with this release. We are currently impacting a defect fix release into Trade Test that focuses specifically on inventory linking by addressing the unhappy path and the workarounds that are currently in place.

The CSP-specific XML sample pack (IVL_Sample_TC01) includes the following:

  • Inventory-linked pre-lodged Type F declaration
  • Inventory match request and response
  • Goods arrival message
  • CSP status notifications

CDS Trade Test is still a test system so if you do encounter any issues, please continue to raise these via the SDST keeping in mind that trade test is currently supported from 9am to 5pm Monday to Friday, excluding UK bank holidays.

Back to news

We use cookies on this site to improve your experience. By continuing to browse the site you are agreeing to our use of cookies. You will only see this message once. Find out more