This commit introduced many party identifiers. The problem we face is that the list is so long that it is cumbersome to simply choose which one the user needs because in practice only a very small set of types is actually used.
We initially simply added a patch to just leave eu_vat but we’re looking for alternatives that avoid the patch or a module that we end up installing to all customers.
We’ve thought that one improvement over the current core situation would be to allow configuring the default type.
Yet I wonder what others are doing about this and if somebody has a better idea on something that could be implemented in party module itself.
We’ve got similar feedback from our customers. The list is long but explaning that we are an ERP designed globablly and we support all identifiers types they understand it.
I do not think there is a default value that will work for all.
I think we can sort the identifiers to show the most relevant ones first. For example, if I’m creating a Spanish party I want to see the identifiers on this order:
The spanish one’s
The european one’s
All other identifers.
When creating a german customer then it will make sense to include first the German identifers instead of the Spanish one.
This will allow users to easly find the right identifier most of the times on the first options and let the other identifiers available for special cases.
As it is a Selection field, the options (and the order) are common for all the views/record.
I think it could probably be done using a second function field with an on_change_selection but the drawback will be that the method will need to be called very often even for consultation.
we had that feedback from several customers problem and are working in an implementation like Address Subdivision Types on party module to allow to select identifier types depend company country.
I do not really see how it could be. Those values are directly linked to python-stdnum.
Not sure it will be a good solution because for example a company from a specific country could have also a VAT number for another countries. This happens if it does a lot of businesses in that other countries.
I’m wondering if a good solution would not be that the system tries to guess automatically the type when the code is filled.
I agree it should not be loaded by a separate script but I think we could import them using records currencies and countries were loaded in the past.
I see two problems with this:
The type is not required so if the code is wrong, the type would be left blank and we would not warn the user.
It could be slow. In fact, another reason we patched the party module is to made upgrade process from older versions faster as it tries to check if what is the type of the previous vat code.
An alternative solution would be to improve the useability of Selection widgets to be as goo as Many2One widgets. M2o allow users to choose among thousands of records without problems so in fact the problem is not that there are many options but that the widget is not good enough.
I like the idea. And when there is a target model for the identifier type, we can make it sequence ordered and deactivable. Also it would allow custom identifier types like “old customer code” from former systems. The identifier type model should always show all the actual python-stdnum entries, mixed with the preferences of the company (company multi value) like active and sequence. The origin can hold the “python-stdnum” or “custom”: The model could have the following fields:
I had not thought about this but I think you’re right. It may make sense the list of identifier types to depend on the company.
Not sure I like “origin” very much. Maybe it is more something like “Check” (or “Parser” or something like that).
However, I’m not sure the field is really necessary. If data is created using XML files we can check it using the XML ID. So the party module checks if the identifier type has an XML ID created by the “party” module and runs the appropriate checksum.
I’m not sure about company multivalue. A party identifier is not realated to the company. Once the party has an identifier it should be visible to all companies.
We had a discussion on the bug tracker that may be relevant for this topic:
Yes, you are right, the term origin is not good, as it is already a conception of Trytons internal referential data.
I thought we could avoid the XML creation and maintenance step and just read the data into the database like done in country/currency. But maybe having static data with XML-IDS as you propose is much better. We could restrict the modification of the name field and its translation with the usual You are not allowed to modify this record. This record is part of the base configuration but allow the user to modify the active and sequence fields. Of course the name field of manually created records can be modified by the user.
Yes, you are right. Parties (same as products) are shared in multi company environments between the companies. As the companies are usually related in such a setup, it makes not much sense to show different identifier types in different companies.
…
Also, deactivating is not a good option because if you need some identifier on the future the user will think that is not supported by Tryton so will put the data in the wrong place.
…
Yes, there is a risk. But the risk is also true for currencies, unit of measures and countries and all other models which allow the deactivation of records like party, product etc. So IMHO it is not a valid argument to restrict the deactivation of identifier types.
I see no real advantage in using a Many2One because:
it creates a migration
it moves in the database data definition directly linked to the code of python-stdnum
it will not improve the UX as any way it will be displayed a selection (because creation is not possible)
But I think we could have a MultiSelection in the configuration using the same selection list. If not empty it will be used to filter the selection of the type through a class method.
We just be careful to clear the cache view if the configuration is changed and to validate that all stored types are still in the configured selected.