An update on our progress towards CDS
HMRC recently announced a proposed plan for completing delivery of the new Customs Declaration System (CDS).
The plan requires all traders to migrate from CHIEF to CDS by September 2020, allowing HMRC to turn off CHIEF in March 2021 when the current contract ends.
HMRC recognise that this timeline is challenging!
In collaboration with AFSS, AICES, Community Systems Providers (CSPs) and other trade bodies, ASM is engaging with HMRC to ensure that the above timelines evolve to become realistic and achievable for all parties concerned.
We will update you as soon as the dates are agreed by all, but you can rest assured that we will deliver a CDS compliant version of Sequoia within the required timelines.
We, along with most other trade bodies, are sceptical about the achievability of the dates announced by Customs, for a number of mostly technical reasons.
Lack of coverage
Currently, the range of functions required by a forwarder are not yet operational on CDS. The only declarations that can be processed by CDS in the live environment are certain supplementary declarations for goods entering free circulation, mainly submitted by those operating customs warehouses.
From a forwarder’s perspective, frontier declarations are an essential part of their core business; to release goods for import or export at the border. For that to work, the inventory processes that release the goods are fundamental.
Inventory Linking Complexity
For imports, this requires interfaces between CDS and CSPs – CCS-UK, MCP (Destin8), CNS (Compass), Pentant and the direct connection to CDS (the replacement for EDCS). All of these new interfaces need to be developed and thoroughly tested. This work is currently in the early stages.
For exports, CDS does not yet handle the links between MUCRs and DUCRs as CHIEF did. A separate development is being planned to do this. The system will then need to talk to both CHIEF and CDS – as well as all the CSPs – to coordinate the links to ensure that all declarations are arrived and departed when an arrival or departure is reported by MUCR.
Declarations linked to an MUCR could be on either customs system (or in some cases, both) and the relationship is complex – involving software providers, customs, and CSPs – but fundamental to the correct functioning of exports. The work on this complex new system has barely begun.
For all the crucial inventory-related processes, we are completely dependent on the CSPs to develop, implement, and test the new interfaces with CDS. This also extends to the way CDS declaration data is exchanged with them (inventory-linked declarations have to be sent via the CSP by whom the inventory is controlled).
All of the communications links (gateways) to do this are also being changed and that means we have to accommodate those changes as well as the way in which data is exchanged (xml as opposed to the old CHIEF EDIFACT format).
Error handling and information
As far as the declarations themselves are concerned, the scenarios (declaration types, CPCs, preferences, quotas etc.) that have been exposed in the test environment are, to date, a very small subset of what CDS will have to handle.
Declarations to CDS (under UCC legislation) are very different – and in most aspects more complicated – than those made to CHIEF. Therefore, at least initially, there is a far greater chance of people getting those declarations wrong.
So far, the response from the CDS system when errors are identified is not specific enough in most cases. The complicated system of ‘pointers’ to identify where the error has occurred, tends to just say ‘you have made an error somewhere’, without telling you what or where the problem lies. Customs recently acknowledged this deficiency and has promised to address it. This is, in itself, no small development and is likely to push the timelines back even further.
Furthermore, declarations to CDS are supposed to allow up to 999 items in each declaration. Currently, the test environment restricts users to a maximum of 14 items (anything above doesn’t work).
Also, to date the live environment is being carefully managed to only allow a small volume of traders to submit declarations. This would seem to suggest an issue with capacity somewhere in the system, which needs to be addressed, although early 'load testing' results are encouraging.
As the testing is extended to include more scenarios, and more traders go ‘live’ on the service, more issues will no doubt be identified, clarifications will be needed, and more changes to trade software will inevitably be required.
CDS is a very big project and the challenges still to be overcome should not be underestimated.
Many of the solutions to outstanding issues will have a knock-on effect for customs, trade software providers and community system providers alike.
There are many critical parts and complex interactions between systems and they all have to work together, seamlessly. To ensure that this is successful, ASM will continue to work on behalf of the forwarding community, with all parties involved, to be certain that the necessary functions are available on CDS, the necessary changes to IT systems and business processes are made, and that the whole ecosystem is tested end-to-end.