VAT rates

[kvdb]

I'm looking to replace the no longer maintained package https://github.com/al45tair/vat with python-stdnum. I've been using the functionality that returns the current VAT rates from each EU member country. Data is obtained from vrws (seems to be an official EU API). Is python-stdnum the place to adopt such functionality?

[arthurdejong]

I don't think the current code works:

>>> from vat import vrws
>>> vrws.get_rates('NL')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/v27/lib/python2.7/site-packages/vat/vrws.py", line 260, in get_rates
    return parse_response(send_message(message), 'ratesResponse')
  File "/tmp/v27/lib/python2.7/site-packages/vat/vrws.py", line 160, in send_message
    faultactor, detail)
vat.vrws.VRWSSOAPException: soap:Server - The given SOAPAction urn:ec.europa.eu:taxud:tic:services:VatRateWebService does not match an operation. (None)

Also, the WSDL at https://ec.europa.eu/taxation_customs/tic/VatRateWebService.wsdl seems to be invalid and I can't seem to find any documentation for it.

Since getting the VAT rates is not really within the original scope of python-stdnum I want to include it only if the code does not get too big. If someone can provide some working code, I'll consider it.

[kvdb]

I'm not familiar with either project, but I took a look in vat/rates.py and it seems to provide a fallback:

        try:
            rates = vrws.get_rates(member_state, date=today)
        except vrws.VRWSException:
            rates = tic.get_rates(member_state, date=today)

So perhaps the useful implementation is: https://github.com/al45tair/vat/blob/master/vat/tic.py If that also won't work, it seems the library also provides a static list of rates.

[arthurdejong]

That code seems to use scraping of https://ec.europa.eu/taxation_customs/tic/public/vatRates/vatrates.html which is even more fragile and error prone. It also doesn't work for me right now:

>>> from vat import tic
>>> tic.get_rates('NL')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/v27/lib/python2.7/site-packages/vat/tic.py", line 84, in get_rates
    f = urllib.request.urlopen(req)
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 435, in open
    response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 467, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 633, in http_error_302
    new = self.redirect_request(req, fp, code, msg, headers, newurl)
  File "/usr/lib/python2.7/urllib2.py", line 594, in redirect_request
    raise HTTPError(req.get_full_url(), code, msg, headers, fp)
urllib2.HTTPError: HTTP Error 307: Temporary Redirect

[kvdb]

I would still need to check if no other python package exists that maintains a static list of VAT rates that's well maintained (basically the table on https://ec.europa.eu/taxation_customs/sites/taxation/files/resources/documents/taxation/vat/how_vat_works/rates/vat_rates_en.pdf) Would maintaining such table fit within the scope of python-stdnum?

[arthurdejong]

I don't want to maintain a table of VAT rates within python-stdnum. If there is a remote API that we can check I'm fine for adding code for that but the changes to VAT rates are much too frequent for the normal release schedule for python-stdnum (best effort mostly). VAT laws also can get pretty complex and determining which products or services fall in which VAT rater is pretty far outside the scope of coding.

[ex5]

@kvdb for what it's worth, there a VAT-rates table available here: https://github.com/kdeldycke/vat-rates/blob/main/vat_rates.csv, which appears to be carefully maintained.

[kvdb]

Thanks for your comment. I'm also considering https://pypi.org/project/pyvat/

[kvdb]

I suppose there's no reason to keep this issue open anymore? I'll close it.