I’ve just started getting a strange error from the QuickFile Invoice_Create
API:
<?xml version="1.0" encoding="utf-8"?>
<Invoice_Create>
<Header>
<MessageType>Response</MessageType>
<SubmissionNumber>1494354085819</SubmissionNumber>
</Header>
<Body>
<Errors>Account is not VAT registered however the tax amount is supplied on item row 1.</Errors>
</Body>
</Invoice_Create>
Two things are strange here - firstly I’ve checked my account settings and I definitely am set to be VAT registered, and secondly when I’ve had errors from the APIs before they’ve come as an Error
element directly under the top level response element rather than as Errors
inside the Body
(so I wrote my code to assume that receiving a Body
rather than an Error
meant the request was successful).
Have you changed things recently? Can I do anything else to help you debug this? (Account ending 3368 if you want to check the logs on your side)
Hi @ian_roberts
We did fix a bug earlier today that was allowing VAT to be entered onto a non-VAT registered account. I’ll refer this to our development team and get it checked out.
1 Like
Sorry @ian_roberts, this is being looked into right now. We should have this fixed in the next 30 mins.
EDIT:
Fixed!
1 Like
Indeed, working fine now.
On my other question, while you have detailed documentation on all the different types of request messages that we can send to your API, is there any documentation of what we should expect the response messages to look like (in both the success and the error cases)?
There isn’t anything documented for the responses, but I’ll raise this with the team and see if anything can be added to the documentation.
Will keep you updated
1 Like
Thanks, I’ve managed so far with trial and error (dumping raw responses and seeing what I get) but it’d be nice to have it documented if only so I know what to expect in the cases I haven’t tested.
It’s very much trial and error with API responses, so I agree it would be very helpful to build a set of response schemas. It’s on our mid-term planner so hopefully we’ll be able to address this soon enough.