MTD VAT

[plasticpig]

akirk said:

thoughts:
- helpful people
- hard to get hold of, and they do not reply to help desk questions within the specified 2 days
- the API and the requirements are changing continually - they are good at communicating and highlighting the changes - but this is an API which is in no way ready for mass-use - that will be okay then!
- for an API which simply requires validation and then the submission of max 9 numbers and a period - it is phenomenally over-complicated and extremely badly documented...
- their code is not complete yet - e.g. we were getting back an error code of 503 (meaning that their server didn't exist!) when it should have been 412 - which has a useful meaning
- their helpdesk can't see the trace of interaction with your account so are helping blind!

all in all - amazing that it actually seems to be working at all - I guess we will know later this year how successful it has been, but probably one of the worst APIs we have coded with...

You get a far faster response by posting your issue on the GitHub VAT-API issues page: https://github.com/hmrc/vat-api/issues. I am currently banging my head against a wall with HMRC with regards to the fraud prevention headers.

Despite HMRC seeming to favor Scala as their programming language of choice they fail to see the issue with requiring a header that gives the device manufacturer and model name when they are themselves using a development environment that targets a Java Virtual Machine. The very idea of abstraction and not needing to care about the underlying OS / hardware seems to have totally escaped them.

[Clockwork Cupcake]

MrJuice said:

DOH! I remember now. I did see that but you mentioned £1/month so I didn't make the connection

Obviously £0 is better than £1 but the mention of £1 threw me

The £1/month only became apparent when I clicked the link and looked at the pricing. It turns out it is only free for the first year.

[Eric Mc]

plasticpig said:

akirk said:

thoughts:
- helpful people
- hard to get hold of, and they do not reply to help desk questions within the specified 2 days
- the API and the requirements are changing continually - they are good at communicating and highlighting the changes - but this is an API which is in no way ready for mass-use - that will be okay then!
- for an API which simply requires validation and then the submission of max 9 numbers and a period - it is phenomenally over-complicated and extremely badly documented...
- their code is not complete yet - e.g. we were getting back an error code of 503 (meaning that their server didn't exist!) when it should have been 412 - which has a useful meaning
- their helpdesk can't see the trace of interaction with your account so are helping blind!

all in all - amazing that it actually seems to be working at all - I guess we will know later this year how successful it has been, but probably one of the worst APIs we have coded with...

You get a far faster response by posting your issue on the GitHub VAT-API issues page: https://github.com/hmrc/vat-api/issues. I am currently banging my head against a wall with HMRC with regards to the fraud prevention headers.

Despite HMRC seeming to favor Scala as their programming language of choice they fail to see the issue with requiring a header that gives the device manufacturer and model name when they are themselves using a development environment that targets a Java Virtual Machine. The very idea of abstraction and not needing to care about the underlying OS / hardware seems to have totally escaped them.

All gobbledygook to me. God knows how the local corner shop will cope.

[MrJuice]

Corner shops do not turnover above the threshold, surely?

[Clockwork Cupcake]

Eric Mc said:

All gobbledygook to me. God knows how the local corner shop will cope.

Corner shops aren't Software Developers trying to write software that uses the HMRC MTD API (Application Programming Interface) though.

Akirk and plasticpig are talking about developing software applications that interface with the HMRC systems.

Once everything settles down, and the issues are better understood, I would expect (or at least hope) that example code will be published, at which point I would be tempted to write my own bridging software since Software Development is my line of business.

Edited by Clockwork Cupcake on Wednesday 8th May 12:04

[akirk]

plasticpig said:

You get a far faster response by posting your issue on the GitHub VAT-API issues page: https://github.com/hmrc/vat-api/issues. I am currently banging my head against a wall with HMRC with regards to the fraud prevention headers.

Despite HMRC seeming to favor Scala as their programming language of choice they fail to see the issue with requiring a header that gives the device manufacturer and model name when they are themselves using a development environment that targets a Java Virtual Machine. The very idea of abstraction and not needing to care about the underlying OS / hardware seems to have totally escaped them.

All now working - and ours is a PHP environment - fortunately I just handed it over to someone who works for me and who has a bigger brain / more tolerance with badly put together systems... I know that government IT systems are usually poor, but considering that this is simply a system to pass over a VAT number / period and 9 further numbers (or less if they do the calculations) I would have expected an API to be written in an afternoon, and for us to have written the code in about 10 minutes flat:
- validation for security
- here is our VAT number / period & figures for boxes 1-9
- response back from HMRC
job done!

it has to be the simplest API I have ever seen at a concept level - but the most complex / badly written API for that conceptual simplicity ever!

Clockwork Cupcake said:

Eric Mc said:

All gobbledygook to me. God knows how the local corner shop will cope.

Corner shops aren't Software Developers trying to write software that uses the HMRC MTD API (Application Programming Interface) though.

Akirk and plasticpig are talking about developing software applications that interface with the HMRC systems.

Once everything settles down, and the issues are better understood, I would expect (or at least hope) that example code will be published, in which case I would be tempted to write my own bridging software since Software Development is my line of business.

Yes - apologies - I run a web / coding / etc. business - all our accounts and VAT are driven from our internal system which we have written over the last 14 years - it also manages our projects, so we add time / costs - press a button to send an invoice - press a button to reconcile for VAT - etc.

I would expect a corner shop to use a commercial accounting package, so they will not need to worry about APIs - my comments were more to give a picture of what is going on behind the scenes for those having to code solutions for this...

@Clockwork Cupcake - I would wait until at least later this year - but in reality, what is in the API guide is okay, you just need to guess / verify some with their helpdesk - or use the github reference above - they do also have a sandbox to use...

[Clockwork Cupcake]

akirk said:

Yes - apologies - I run a web / coding / etc. business

If you ever need the services of a very experienced freelance C++ developer then give me a shout. I generally bill by the hour but could do fixed-price work too.

I realise that C++ is increasingly specialised these days, though, and a shrinking market.

[akirk]

Clockwork Cupcake said:

akirk said:

Yes - apologies - I run a web / coding / etc. business

If you ever need the services of a very experienced freelance C++ developer then give me a shout. I generally bill by the hour but could do fixed-price work too.

I realise that C++ is increasingly specialised these days, though, and a shrinking market.

Thank you - always worth noting, we do get asked for all sorts of skills at times - generally though standard PHP / etc. - a lot of our work is working also with businesses on how to grow, so the coding supports that work - online processes etc.

[Eric Mc]

MrJuice said:

Corner shops do not turnover above the threshold, surely?

Absolutely they do.

[eps]

Clockwork Cupcake said:

MrJuice said:

DOH! I remember now. I did see that but you mentioned £1/month so I didn't make the connection

Obviously £0 is better than £1 but the mention of £1 threw me

The £1/month only became apparent when I clicked the link and looked at the pricing. It turns out it is only free for the first year.

Has anyone signed up to VitalTax? I've been avoiding MTD as much as possible, but need to register and sign up within the next 2 months. It almost seems too good, but then again it's all been written and just communicates via the HMRC API.

[98elise]

Eric Mc said:

MrJuice said:

Corner shops do not turnover above the threshold, surely?

Absolutely they do.

It may have been tongue in cheek!

In reality corner shops of course do go over the turnover. To be under, your profit has to sustain a shop and at least one wage, and mark up on stock is not huge.

[Eric Mc]

I've looked after a few "corner shop" type businesses over the years and all of them were over the VAT threshold.

In fact, preparing VAT returns for "corner shops" is quite complex because of the multiple VAT rates that apply to the products they sell and the methods used to reclaim VAT on their costs.

[Clockwork Cupcake]

Eric Mc said:

I've looked after a few "corner shop" type businesses over the years and all of them were over the VAT threshold.

In fact, preparing VAT returns for "corner shops" is quite complex because of the multiple VAT rates that apply to the products they sell and the methods used to reclaim VAT on their costs.

Indeed. Very much "high turnover, low profit".

I shop in Booker from time to time, and it always amazes me how little markup (and hence profit) there is on many goods, even when bought in bulk. Makes you wonder how some of these shops turn a profit at all.

[x5x3]

akirk said:

@Clockwork Cupcake - I would wait until at least later this year - but in reality, what is in the API guide is okay, you just need to guess / verify some with their helpdesk - or use the github reference above - they do also have a sandbox to use...

If I understand this correctly - it is a simple REST API utilising an OAuth 2.0 token and a JSON payload.

Therefore a simple series of Requests in POSTMAN (or similar) would suffice?

[Clockwork Cupcake]

x5x3 said:

If I understand this correctly - it is a simple REST API utilising an OAuth 2.0 token and a JSON payload.

I have a lot of experience with those technologies and it would be trivial for me to write something to do that.

However, my experience also says a few hours to write it, and a few days to test it and iteratively work out all the kinks in the nitty-gritty of the correct parameters in the correct format at the correct time and in the correct place.

The devil, as they say, is in the detail. Especially when talking to a poorly-documented REST API, and I have plenty of experience there too.

[eps]

Clockwork Cupcake said:

x5x3 said:

If I understand this correctly - it is a simple REST API utilising an OAuth 2.0 token and a JSON payload.

I have a lot of experience with those technologies and it would be trivial for me to write something to do that.

However, my experience also says a few hours to write it, and a few days to test it and iteratively work out all the kinks in the nitty-gritty of the correct parameters in the correct format at the correct time and in the correct place.

The devil, as they say, is in the detail. Especially when talking to a poorly-documented REST API, and I have plenty of experience there too.

Snap!

[x5x3]

eps said:

Clockwork Cupcake said:

x5x3 said:

If I understand this correctly - it is a simple REST API utilising an OAuth 2.0 token and a JSON payload.

I have a lot of experience with those technologies and it would be trivial for me to write something to do that.

However, my experience also says a few hours to write it, and a few days to test it and iteratively work out all the kinks in the nitty-gritty of the correct parameters in the correct format at the correct time and in the correct place.

The devil, as they say, is in the detail. Especially when talking to a poorly-documented REST API, and I have plenty of experience there too.

Snap!

yes I do agree - I have spent more than a few hours battling with badly written and documented REST APIs.

However, this whole idea that I am being forced to spend money to someone else to do this for me is not sitting well with me currently.

Its not about the amount (the £1 per month identified above seems very reasonable) it is the principle so I may well have to have a go at doing it myself.

[Clockwork Cupcake]

x5x3 said:

However, this whole idea that I am being forced to spend money to someone else to do this for me is not sitting well with me currently.

Absolutely. Same here.

[Eric Mc]

Clockwork Cupcake said:

Indeed. Very much "high turnover, low profit".

I shop in Booker from time to time, and it always amazes me how little markup (and hence profit) there is on many goods, even when bought in bulk. Makes you wonder how some of these shops turn a profit at all.

And complex from a VAT point of view because general store type retailers will sell a wide mix of goods and products that spans all the VAT categories -

Standard Rate
Zero Rate
Special Rates (such as domestic fuel)
Exempt
Outside the scope

Some of them will have to use special "Retail Schemes" which are supposed to simplify matters for the trader but which can be complex in themselves and throw up weird anomalies.

[akirk]

Clockwork Cupcake said:

x5x3 said:

If I understand this correctly - it is a simple REST API utilising an OAuth 2.0 token and a JSON payload.

I have a lot of experience with those technologies and it would be trivial for me to write something to do that.

However, my experience also says a few hours to write it, and a few days to test it and iteratively work out all the kinks in the nitty-gritty of the correct parameters in the correct format at the correct time and in the correct place.

The devil, as they say, is in the detail. Especially when talking to a poorly-documented REST API, and I have plenty of experience there too.

31 hours 42 minutes logged on our system against the internal project to write a connection to their API
probably along the lines of 30 minutes coding and 31 hours 12 minutes asking their helpdesk why they have changed things and not documented it!!!

the biggest issues have been that they have been continually iterating the code - and while there are some update notices emailed out, it doesn't cover all changes, or the full detail of the changes. Additionally, poor documentation has meant that you are trying to guess half the time what your code needs to do...

didn't help that the error codes they return are not accurate - so there was a phase (possibly still the case) where they returned a 501 (server doesn't exist) error, regardless of what the real error was (in our case, a change in how they handled headers) - so not only do you have to guess, so do they!

I have no issue with MTD / using an API, but for a system which basically has to pass over 12 bits of information, and receive back one response, it is over complex, badly documented, and badly coded - we spend all day plugging web code into APIs and have never seen anything as unready / badly written...