Duty expression as a single string instead of parameterised

In looking at the alternative to the TSO data file we spot a problem regarding the duty calculation. You currently give us the duty expression as a single string, e.g. “8.60 % + 20.20 EUR / 100 kg MAX 19.40 % + 9.40 EUR / 100 kg”
e.g. commodity 2105001000

You should give us the data in the same way that the TSO file used to:

  1. It separates the data fields out into separate elements. For example, the above would be expressed as
    a. Ad valorum rate 1 = 8.60
    b. Specific date 1 = 20.20
    c. Ad valorum rate 2 = 19.40
    d. Specific rate 2 = 9.40
    e. Unit of quantity 1 = “per 100kg”
    f. Unit of quantity 2 = “per 100kg”
  2. It gives us the Calculation formula = “16” meaning “Ad valorem plus specific subject to a maximum ad valorem plus specific”

Once we know formulae #16, and all the parameters’ values, we know how to apply the parameters to perform the calculation.

Receiving the duty expression as a string doesn’t allow that. We have a terrible job of chopping up the expression to extract the parameters, but we do not have information about the formulae.

Your JSON service does not list those data – which must be available to HMRC because they go into the TSO file.

Instead the JSON file sends back a human-readable block of text:


Yes, human-readable, even though this is supposed to be a computer-to-computer service.

So the service is not suitable as a replacement for the TSO file as it does not give us the data we need.

Please give us the duty expression as a set of parameterised fields.

Thanks

1 Like

Hi Daniel,

Thank you for raising this, the GOV.UK Trade Tariff service at the moment doesn’t do duty calculation, as HMRC CDS handles this. That said I do agree with you that we could send this additional information in the API so that others can do their duty calculations.

Duty calculation is on our roadmap, but I had been struggling to find more use cases (given CDS would do this), but if people need the data that would help make the case for it.

TSO did a fair amount of manual processing, to generate their data, I’m not sure we could generate the same format, we get our data directly from HMRC (CHIEF/CDS) and the EU (TARIC3), but the individual measure components are available (as we combine them to produce the full expression).

I’ll have a chat with HMRC and see if we can get this prioritised.

Thanks,
Matt

1 Like

Hello Matt
Thanks for reply.
Both CDS and CHIEF do the duty calculation, but that they do them doesn’t mean that we don’t want to as well. We want our declaration software to pre-calculate duty before submission.
Not to mention the design “feature” that CDS has which is to not return the DMSTAX until after the 1-minute timer, meaning declarants cannot see their duty calculation until their entry has cleared.

We don’t need you to do the duty calculation. We just need all the data, parameterised, please. If you have it already, do please send it.

The use case is:
a) Joe Trader wants to see the amount of duty he’s going to pay BEFORE submission to check he’s not made any mistakes. He needs his declaration software to have the data to do that automatically for him.
b) Joe Trader wants to minimise his duty by ensuring he’s selecting the applicable preferneces and documents. He needs his declaration software to have the data to do that automatically for him.

Thanks

Hi Daniel,

Yes thanks, we’ll put this on our backlog, we store our data in TARIC3 format, so we can expose the individual measure_components.

That said, our API might not be the best place, to get this data, HMRC has released an API (which is in beta) to expose all the Tariff data and daily updates, https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/secure-data-exchange-bulk-download/1.0

We will use this to get the daily updates once it comes out of beta. This file format loosely follows TARIC3 (with some modifications), I believe it’s the recommended HMRC source, as we do not have a way currently in our API to return just the commodity codes with updates, so you would need to periodically refresh everything.

Thanks,
Matt

Thanks for adding it to the backlog. Any idea of timescale? We need it by end December because that’s when the TSO file subscription ends.

We’re painfully aware of the XML files service. It’s been an awful service all year, either with missing data or a malfunctioning webservice.
The annual file is over 8GB and is very hard to parse. It’s inflated due to having all the quota transactions inside it.
We’re much rather use your lighter service.

And you elaborate on the difference between TARIC 1 and TARIC 3 please?

Hi Daniel,

We should be able to complete that by early December, we have a few other user stories in play at the moment which I would like to wrap up before we tackle this.

RE: the XML service - I have also been reporting issues with it to the HMRC team so they should hopefully have these resolved soon. We also feel your pain about the parsing of the XML.

With regards to the differences between TARIC1 and 3, I do not have documentation on TARIC1 to be able to comment, but there is a link I found to a pdf that explains the data format of TARIC3: TARIC3 IDS Technical Message Exchange Specification and the data within each duty expression.

Thanks,
Matt

Hi @Daniel.Clarke.WiseTech, we too face a similar issue. I totally agree it is easier to have it split rather than in one sentence. Thanks for bringing this up.

Hello Matt
Please could you let us know how you’re getting on with separating the duty expression into discrete parameters.
Thanks

Just a quick update on this one, we have added the additional information to the commodity code request and are in the process of updating the API documentation.

Thanks,
Matt

1 Like