In Australia we do not use VAT numbers - we use other numbers. I would like to know what would be the correct way to provide a module to the community to allow the Australian numbers and not VAT as Tax identifier types.
I remember reading that Tryton was avoiding using “localisation modules”, yet I noticed that modules exist for some specific European countries.
We normally use python-stdnum for validating the vat numbers. First of all you should check if this library supports the Australian VAT numbers. If it does not support the first step is to create a pull request on this library to validate this numbers.
Once you have the number validation you can add a new type identifier on the party.identifier selection model to include the Australian VaT numbers and validate them.
What I’m not sure if it’s best to have the new identifier as a separate module or as part of standard party module.
If you are concerned about the tul2003 talk about localization modules the idea is that instead of doing custom modules to solve localization problem it is better to have a generic way of solving the problem that each country can extend to fit their needs. In this case we’ve designed the party.identifier model to be generic enough to fit all the countries so each one can implement their needs, so the standard part have already been done.
The idea about this talk is that instead of creating a custom module for something that should be done on all countries, you should first try to find a single way to do it that works for all country allowing each country to implement its specific cases.
I think it makes sense to include in party module because we have the tax_identifier notion that is reused in other modules.
Indeed I’m wondering if the best will not be to include all tax identifiers of python-stdnum.
Yes: ABN, ACN, and TFN are included.
OK, I didn’t think everyone would want to have all the tax identifiers. I wonder if we should have a separate module just for the rest of the tax identifiers.
What do you call “the rest”? From which base do you consider that tax identifier is standard or separate?
For me, a company can have customers from any country so it should be possible to enter the tax identifier if needed. Of course the current design allow to encode any number as generic identifier but it does not work well with other modules like account_invoice who is using only identifier defined as tax.
I thought only VAT was the base.
Why would VAT be the only base?
Because Tryton has mostly been European and vat is currently the only base. It was only my perception. I’m not suggesting that vat should be the only base.
Do you think that we should load all the identifiers of stdnum in the selection list value?
I think we should add only the ones that are as used tax identifiers.
So when receiving/issuing an invoice to any country in the world tryton is able to validate the tax number of the supplier/customer.
Agreed, I wonder how hard it would be to patch stdnum to have a flag for tax identifiers.
This will be the best for us, as new identifiers will be added automatically.
You should ask the python-stdnum maintainer to see if they wan’t to support this feature.
I have sent the mailing list an email and submitted an issue on Github [1]
[1] Adding a type or catogory flag · Issue #73 · arthurdejong/python-stdnum · GitHub
I’m not sure because we may not have the same definition of what is a tax identifier. As it is closely linked to the business, I think I would prefer to manage it in Tryton which will allow customization.
OK, so you would have a set manually updated with the list of tax number types?
We have already it: modules/party: 0261c9296cac party.py
I’m just saying that we should not create new modules to fill it but just improve party module for unambiguous cases.
This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.