VATIN tweaks

[unho]

No description provided.

[arthurdejong]

It might be a better idea to provide a stdnum.tin module that transparently supports multiple international tax identification numbers instead of using the stdnum.vatin module for that. VAT numbers are often not general tax identification numbers and sometimes are only relevant for VAT and not for other taxes.

A problem is that it is pretty difficult to categorise all personal and company identification numbers into one scheme. For example sometimes you may want to validate that a number is any kind of identifier of sorts, sometimes you may want to ensure that it is assigned to a company in some country or instead identifies some individual and sometimes you may accept one number over another (e.g. a drivers license number may not be sufficient but a ID-card number might be). Companies may have various numbers (e.g. VAT number, income tax number, chamber of commerce number) all of which may be different and appropriate for different circumstances.

I'm also thinking about reviewing the existing module to check that the countries that currently provide a "vat" alias are countries that actually have a VAT-based tax system.

Ideas on clarifying the use cases are very welcome.

[unho]

I do realize all of that. Please let me explain the rationale behind stdnum.vatin.

Time ago there was this Python package called vatnumber. This provided validation for VAT numbers, which in a lot of countries is the same as the TIN number. In fact for plenty of countries it relied on python-stdnum. vatnumber was being used by plenty of other software.

In my particular case I discovered it through Odoo (formerly OpenERP), exactly when I had to fix the validation for some country. At that moment I discovered that vatnumber was not being actively maintained anymore, so I couldn't contribute the fix. After some research I also noticed that python-stdnum was being maintained, and that not only already had some of the fixes I wanted to contribute, but that it also had validation for several other countries. At that moment I started contributing, and also creating tickets for expanding the functionality.

Some time after Odoo replaced vatnumber with python-stdnum. In fact its code tries to use any vat module located within any country package within python-stdnum (https://github.com/odoo/odoo/blob/16.0/addons/base_vat/models/res_partner.py#L99). I believe that in part this happens because in Odoo they called this the vat field, and in part they don't realize that in some countries the VAT number is a different one.

I in fact noticed this differentiation when I looked into the TIN for United States, where I found out that the don't have the concept of VAT number, and that their TIN number is not even "universal". To my dismay, the further I looked into other countries, the more difficult it became to differentiate which number to use. Then I stumbled upon https://en.wikipedia.org/wiki/VAT_identification_number in which they kinda mix these two concepts.

That happened more or less at the moment when I really wanted python-stdnum to actually provide a simple method where you can provide for validation a "VAT number", in the way Odoo stores it, and that vatnumber actually had. And since nobody kinda agreed on having a proper TIN number, or a VAT number, then I kinda acquiesced on using "VATIN". Thus stdnum.vatin.

So answering your question, sure we can add a stdnum.tin module. But what happens if any country doesn't have a proper TIN? And even if we go this route, we will kinda have to verify again that the number we had is the proper TIN, in order to untangle the modules and their aliases.

Alternatively we can undo some of the vat aliases and use something like vatin. This will certainly break Odoo's code, but is more semantic, and we don't have to worry so much about it being TIN or VAT number, like for cases like United States or maybe India.

Or try to convince those countries to use a single unified number as identifier for the companies/people/etc for all purposes. But I don't see that happening 😄. In fact even countries like Spain have a different company registration number, that in fact is nearly useless since we do use NIF for everything, but that it still exists.

[unho]

Another thing @arthurdejong, whether we do keep this module unchanged, or it gets renamed, I still think this particular PR should be merged 😄

[arthurdejong]

Thanks for providing the detailed response. I will really have to give this some more thought into how to get to some kind of longer-term solution. For now I would think it would be reasonable for any number that is listed on https://en.wikipedia.org/wiki/VAT_identification_number or there is any other source that says the number is used for VAT purposes in the country to be accepted by the vatin module.

Btw, I merged one of the commits in this PR as 7348c7a. I'll have to look at the others in more detail (sorry it is taking so long). I'll have to check but I thought Python's regex module automatically kept a cache of compiled regexes and I'm not too happy with the validate() function returning exceptions that are not a subclass of ValidationError because that is the documented API (see https://arthurdejong.org/python-stdnum/doc/).

[arthurdejong]

The validate() function should only raise one of the exceptions listed in stdnum.exceptions.