VATIN tweaks by unho · Pull Request #316 · arthurdejong/python-stdnum
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.