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

VAT API address #388

Closed
icougil opened this issue Feb 12, 2018 · 7 comments
Closed

VAT API address #388

icougil opened this issue Feb 12, 2018 · 7 comments
Assignees
Labels

Comments

@icougil
Copy link

icougil commented Feb 12, 2018

Hi!

We've having some issues with the validation of the VAT. Basically what it is happening is after setting the EU VAT API Address, the user can check the VAT, but it does not work.

What it is happening is after the user press "Validate the VAT number", the system returns to the same page, the VAT is not validated at all and also the checkbox for the invoice it is not selected.

We've verified that the Serverless Lambda function is working properly (making some raw curls adding the country & VAT number) so we can imagine that it is something that it is not working properly with the setup between alf.io <> VAT API endpoint.

Once we've deployed the function we received a response like the next one, so we suppose that the endpoint of the GET is the URL we have to use in alf.io:


serverless deploy --aws-profile jug
Serverless: Packaging service...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
.....
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.................................
Serverless: Stack update finished...
Service Information
service: aws-java-maven
stage: dev
region: us-east-1
stack: aws-java-maven-dev
api keys:
  None
endpoints:
  GET - https://XXXX.execute-api.us-east-1.amazonaws.com/dev/vatNumber/isValid
functions:
  vatChecker: aws-java-maven-dev-vatChecker

It is correct? What we are doing wrong? Should we include the /isValid or not?

Best,

@cbellone
Copy link
Member

cbellone commented Feb 13, 2018

Yes, you must include the isValid in the configuration. Which btw looks good to me.

I have been able to reproduce your issue. It happens when the country of business of the organizer and the one of the ticket buyer are the same, and the EU reverse charge mechanism is enabled.

This is clearly a bug on our side: since both entities have their business in the same country, alf.io cannot apply the "reverse charge" and doesn't do anything.
Instead, it should at least save the VAT Number and the result of the call to the EU VAT service.

We'll fix this asap on the "stable" branch and do a patch release.

Thanks for pointing it out!

@cbellone cbellone self-assigned this Feb 13, 2018
@cbellone cbellone added the bug label Feb 13, 2018
@icougil
Copy link
Author

icougil commented Feb 13, 2018

Ok cool, thx for sharing! ;-)
Please, let me know once you have something to use it as a fix.
Best,

cbellone added a commit that referenced this issue Feb 13, 2018
… business of the organizer and ticket buyer are the same
cbellone added a commit that referenced this issue Feb 13, 2018
… business of the organizer and ticket buyer are the same

(cherry picked from commit 9557cce)
@cbellone
Copy link
Member

cbellone commented Feb 13, 2018

Hi @cougil,
the bug should be fixed. Could you please test it and confirm that everything is working as expected now?

After your confirmation we'll release the new version (1.13.3)

Thanks!

@icougil
Copy link
Author

icougil commented Feb 13, 2018

Hi @cbellone

I've checked and it seems that now the VAT mechanism does not fail, so the user can continue asking for their ticket while paying and requesting the invoice.

The only problem that I've seen is that what will happen if the lambda does not return proper information. For example, I've tried with an existing company with a confirmed valid VAT number, and the result we received it is not correct, because it is retrieved an empty address (----). Here you can see an screenshot:

image

Of course the invoice created does not include info about the company, so from the legal point of view it is not correct :-/ Do you think it make more sense to have the field of the retrieved information enabled just in case if the user wants to change some data received from the lambda function?

Best,

cbellone added a commit that referenced this issue Feb 14, 2018
…e can sometimes return incomplete results

- always display VAT Number on Invoice, if present
cbellone added a commit that referenced this issue Feb 14, 2018
…e can sometimes return incomplete results

- always display VAT Number on Invoice, if present

(cherry picked from commit adec050)
@cbellone
Copy link
Member

cbellone commented Feb 14, 2018

@cougil yes, I agree. It doesn't make sense to generate an invoice without a valid billing address.
BTW now you should be able to modify the billing address, even after a successful VAT validation.
Could you please re-test it?
Thank you very much for your help!

@icougil
Copy link
Author

icougil commented Feb 14, 2018

@cbellone yep, that's it.
I've checked that with the master version right now even the lambda function does not return a valid information at least the user can fill this data and the invoice is created properly.
Btw, I'd suggest to change the "Billing address" to something more general ("Billing information/Company information?"), because it should include the name of the company, etc
Best,

cbellone added a commit that referenced this issue Feb 15, 2018
@cbellone
Copy link
Member

Btw, I'd suggest to change the "Billing address" to something more general ("Billing information/Company information?"), because it should include the name of the company, etc

OK, done.

I think we're good to go now. Thanks for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants