steve-james-xero commented 1 year ago

Bug report

You must read the information below before you submit a bug report.

The MTD API team cannot help if your bug report is about:

Fraud Prevention Headers
Issues relating to OAuth2
Subscribing or registering to use the API Platform, MTD enrolment, de-enrolment, registration for VAT, Beta services, etc.
Issues integrating with the API Platform (e.g. setting up an application/access)
Code examples in a given programming language
Business-related questions or processes pre MTD
Scheduled maintenance windows and days
Onboarding (e.g. registering, obtaining keys)
Performance metrics

For any of the above, you must contact the Software Developer Support Team directly at SDSTeam@hmrc.gov.uk. The SDS Team do not monitor this repository.

This repository is for bug reports relating to VAT API code in this repository only.

Fill in the sections below to submit your bug report:

[ ] Documentation
[x] API

Describe the bug In the sandbox environment, the VAT obligations endpoint responds with inconsistent data.

To Reproduce Create a test organisation user in the sandbox environment. Authenticate and call these endpoints. https://test-api.service.hmrc.gov.uk/organisations/vat/128780155/obligations?status=O

responds with

{
    "obligations": [
        {
            "periodKey": "18A1",
            "start": "2017-01-01",
            "end": "2017-03-31",
            "due": "2017-05-07",
            "status": "O"
        }
    ]
}

https://test-api.service.hmrc.gov.uk/organisations/vat/128780155/obligations?from=2021-09-27&to=2022-09-26&status=F

responds with

{
    "obligations": [
        {
            "periodKey": "18A1",
            "start": "2017-01-01",
            "end": "2017-03-31",
            "due": "2017-05-07",
            "status": "F",
            "received": "2017-05-06"
        },
        {
            "periodKey": "18A2",
            "start": "2017-04-01",
            "end": "2017-06-30",
            "due": "2017-08-07",
            "status": "O"
        }
    ]
}

According to these responses, the obligation with periodKey 18A1 is both Open and Fulfilled. The request for fulfilled obligations also includes in the response an obligation with an Open status (18A2).

Expected behavior The obligations returned from requests for Open and Fulfilled obligations should be mutually exclusive.

Screenshots / Requests / Responses See above.

Additional context None

DDCTLS-DEV-TEAM commented 1 year ago

Hello @steve-james-xero

Thank you for reaching out. I can understand the confusion, external test is actually stubbed data so no matter what you call the two endpoints it will return the same data as per the API documentation.

So the responses are correct and actually represent two different calls and two different stub data returns. Unfortunately, this is something we inherited and something to be honest with you we will be looking into.

However, in production calling with a status or a year for example should only return that data, so please reach out again if that is not the case in production.

In the meantime, we will look at what we can do with the stubbed data in the external tests to help with this confusion.

Thank you for flagging this and please reach out if you need more help with this.

Kind regards DDCT Live Service Team

steve-james-xero commented 1 year ago

Hi DDCT team

Thanks for your response. Yes, I understand that your test environment returns canned data that doesn't change. However, I would make the point that the data returned should still "make sense" and be not be self contradictory.

Specifically, a period should not be simultaneously both Open and Fulfilled, and a request for fulfilled obligations should not return any open obligations.

Thanks for looking into this and appreciate your taking the time to put this right.

Regards

Steve

steve-james-xero commented 1 year ago

Hi @scott-goodwin @DDCTLS-DEV-TEAM

Could you provide an explanation as to why this ticket has been closed, please? As of yesterday, the endpoint was still returning that same inconsistent data.

I made a similar comment here a couple of weeks ago but it looks to have been deleted.

A response would be appreciated.

Thanks.

DDCTLS-DEV-TEAM commented 1 year ago

Hello @steve-james-xero

Thank you for reaching out. Apologies for the miss understanding.

In terms of the dates and the period key issue, we have spoken to various teams about the reason this was implemented like this and the overall outcome was not to change it. This is because (though confusing) the data is just stub data and the data is independent of each other.

The first call: https://test-api.service.hmrc.gov.uk/organisations/vat/128780155/obligations?status=O is just an example of an open obligation.

The second call: https://test-api.service.hmrc.gov.uk/organisations/vat/128780155/obligations?from=2021-09-27&to=2022-09-26&status=F is just an example of a fulfilled obligation for a quarter and then an open for the next quarter.

The data in them are just pure stub data and example data to allow for testing purposes.

We do understand the confusion however it was a decision from the team before us along with user research at that time to have these dates.

However, that call should not return the O status obligations as you have asked for status=F. This we have a story for that is ready to pick up and we are looking at implementing a change on the status filtering functionality. So when you ask for O or F etc it will bring back the right data for you.

Thank you for your understanding and we will update here when that status functionality work has been completed.

Kind Regards DDCT LS Dev Team

hmrc / vat-api

Inconsistent VAT obligations in Sandbox environment #935

Bug report