Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Credits/Overpayments/Prepayments dates differ depending on how individual invoice is requested from API #266

Closed
timwiel opened this issue Aug 18, 2020 · 2 comments
Assignees
Labels
Status: Completed Describe solution, include code snippets, link, indicate version # Type: API not Specification This issue can not be solved via the specifications Type: Bug - Confirmed

Comments

@timwiel
Copy link

timwiel commented Aug 18, 2020

It seems that when using the Invoices endpoint the applied credit/overpayments/credits date returned via JSON and XML is different based on how the an individual invoice is requested.

A direct invoice request returns the "allocation" date as the invoice date whereas other type of querystring request (which is what the https://github.com/XeroAPI/xero-php-oauth2 uses as it's uri request type) returns the date the "creditnote / prepayment or overpayment was originally created not allocated.

Is this on purpose for any reason?

For example:
https://api.xero.com/api.xro/2.0/invoices/4766401f-5957-4a0e-9e55-54b79bc543bb
results in the "allocations" being returned with each date being the same as the invoice date

image

however https://api.xero.com/api.xro/2.0/Invoices?IDs=4766401f-5957-4a0e-9e55-54b79bc543bb returns the "allocations" with their original creation date.
image

@SidneyAllen SidneyAllen self-assigned this Aug 25, 2020
@SidneyAllen SidneyAllen added Status: On Hold Provide an explanation in the comments Type: API not Specification This issue can not be solved via the specifications Type: Bug - Confirmed labels Aug 25, 2020
@SidneyAllen
Copy link
Contributor

@timwiel Thank you for reporting this.

We've confirmed this is an issue with the API and a bug report has been created APIB-1814.

This can not be resolved through our OpenAPI specifications, so I'll be closing this case and updating it once the bug has been resolved.

@wobinb
Copy link
Contributor

wobinb commented Nov 9, 2020

This has now been resolved at API level. The dates will now be correct no matter what format the request is in.

@wobinb wobinb added Status: Completed Describe solution, include code snippets, link, indicate version # and removed Status: On Hold Provide an explanation in the comments labels Nov 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Completed Describe solution, include code snippets, link, indicate version # Type: API not Specification This issue can not be solved via the specifications Type: Bug - Confirmed
Projects
None yet
Development

No branches or pull requests

3 participants