Add alternate name to Party

[josesalvador (José Salvador)]

When we as users of Tryton are searching for a party we want to find out by the name which party is known.

I mean, in the case of companies it is very common to know them by its trade name and not by its tax name.

Example:

• Trade name: Scaleway
• Tax name (aka party name): Online SAS

In the case of people many times we do not refer them by its full name else by a composition or minified version of it.

Example:

• Minified: Juanjo Pérez
• Full name (aka party name): Juan José Pérez Roldán

So I would like to propose to add an Alternate name to Party to set these kinds of values in order to find out the right party searching for the party name (actual behavior) or alternate party name (proposed behavior).

Thoughts?

[ced (Cédric Krier)]

That’s the goal of identifier list.

[pokoli (Sergi Almacellas Abellana)]

@ced

goal of identifier list.

Should we add a new type called alternative name to make it clear?

As we only store validated identifiers (aka vat numbers) this usage is hidden.

[semarie (Sebastien Marie)]

I am unsure if it is an abuse or not, but usually I am using “Party name” (the field of Address) for the “official name” and use “Name” (field of Party) for “usual name” (often something like “Scaleway - SAS Online” if I take your example, so it is searchable with both names).

the “Party name” is used for formatting the address, so invoice are properly done, and users are happy to find it with the usual name.

[josesalvador (José Salvador)]

@ced

That’s the goal of identifier list.

Indeed, I didn’t know that…

I had to take a look to the code to find the search_rec_name function in order to understand why I can search for a party by its identifier (alternate name) without setting any field to look for.

Taking that in account I agree the behavior is good for me and I don’t see any reason to add a new field.

@pokoli

Should we add a new type called alternative name to make it clear?

As we only store validated identifiers (aka vat numbers) this usage is hidden.

However, I would look with good eyes the proposal @pokoli did in order to self document the feature and I would propose to give more visibility to that alternate name adding it to the party tree view.

[lukio (Luciano Rossi)]

@josesalvador

@ced

That’s the goal of identifier list.

Indeed, I didn’t know that…

I had to take a look to the code to find the search_rec_name function in order to understand why I can search for a party by its identifier (alternate name) without setting any field to look for.

Taking that in account I agree the behavior is good for me and I don’t see any reason to add a new field.

@pokoli

Should we add a new type called alternative name to make it clear?

As we only store validated identifiers (aka vat numbers) this usage is hidden.

However, I would look with good eyes the proposal @pokoli did in order to self document the feature and I would propose to give more visibility to that alternate name adding it name to the party tree view.

As @pokoli mentioned I also believe it should be explicit (“explicit better an implicit”) to add a new type called alternate name or business name[0]

• [0] Trade name - Wikipedia

Cheers!

[josesalvador (José Salvador)]

@lukio

As @pokoli mentioned I also believe it should be explicit (“explicit better an implicit”) to add a new type called alternate name or business name [0]

Alternate name will serve for both people and companies.

[pokoli (Sergi Almacellas Abellana)]

@josesalvador

I would propose to give more visibility to that alternate name adding it to the party tree view.

I do not think this should be part of standard but done as customization.

[josesalvador (José Salvador)]

@pokoli

I do not think this should be part of standard but done as customization

I don’t know why.

I believe the most of the users know parties by its alternate name as the examples I posted before, so I think the users will expect to match the party when they are searching it.

I mean, as a user searching for scaleway in the party tree view is weird to match a party with name Online SAS.

[pokoli (Sergi Almacellas Abellana)]

@josesalvador

I don’t know why.

Try to get the party view as simple as possible.
The party_tradename is something that may be used optionally so if the users does not set the field it get a blank column for all of the records. That’s why I sugested to add as customization (only for the ones how need it)

@josesalvador

I believe the most of the users know parties by its alternate name as the examples I posted before, so I think the users will expect to match the party when they are searching it.

Agree but there is people that may not be interested to see this information on the list.

@josesalvador

as a user searching for scaleway in the party tree view is weird to match a party with name Online SAS .

When you search using rec_name is expected to match using more fields than seen. Normally the rec_name is used from many2one where you only have the rec_name. Currently we search including the following field that are not on the tree view:

• Contact mechanism
• Identifiers code
• Bank account number

[ced (Cédric Krier)]

@pokoli

Should we add a new type called alternative name to make it clear?

I do not think as you can fill identifier without type.
Also identifier type is enforced when it has a usage in the code.
We can not add an identifier type for all possible usage by default but this can be done a customization.

@semarie

I am unsure if it is an abuse or not, but usually I am using “Party name” (the field of Address) for the “official name” and use “Name” (field of Party) for “usual name” (often something like “Scaleway - SAS Online” if I take your example, so it is searchable with both names).

I think it is an abuse because the “Party Name” on address is to match the name on the postal box.

[pokoli (Sergi Almacellas Abellana)]

@ced

@pokoli

Should we add a new type called alternative name to make it clear?

I do not think as you can fill identifier without type.

Mmm, I was not aware of this. I thought the user was forced to use the “Other” identifier type but you are right.

@ced

We can not add an identifier type for all possible usage by default but this can be done a customization.

Makes sense for me.

I’ve just tested adding a the Tradename as identifier without type and it works great for searching.

But I think we have a problem with naming as we currently have a “Code” field on identifier, which should be probably named to “Value” to make clear that non code identifiers can be used.

[ced (Cédric Krier)]

@pokoli

But I think we have a problem with naming as we currently have a “Code” field on identifier, which should be probably named to “Value” to make clear that non code identifiers can be used.

Maybe it could even be “Name”?

[pokoli (Sergi Almacellas Abellana)]

@ced

Maybe it could even be “Name”?

But then it does not fit very well for numbers/codes.
That’s why I suggested value which is more natural and we use the same term for contact mechanisms.

[josesalvador (José Salvador)]

@pokoli

The party_tradename is something that may be used optionally so if the users does not set the field it gets a blank column for all of the records

I agree I don’t like to see a blank column too

@pokoli

When you search using rec_name is expected to match using more fields than seen

Would it be possible to show this information as a tooltip in the entry box for searches in a generic way?

i.e. Perhaps we can document every search_rec_name function and show this as the tooltip of the entry box.

@pokoli

That’s why I suggested value

+1 to value as the name. Also, maybe would be a good idea to set help to value field (aka code at this moment) of the party.identifier with something like: “If no type is assigned this field can be used to set the trade name of the company, the alternate name of the contact and similar use cases like these”.

[albert (Albert Cervera i Areny)]

@josesalvador

I agree I don’t like to see a blank column too

We could consider replacing the current “name” field by “rec_name” and make the default rec_name include the name + the alternative name.

[pokoli (Sergi Almacellas Abellana)]

@albert

We could consider replacing the current “name” field by “rec_name” and make the default rec_name include the name + the alternative name

Not sure if it’s worth it’s effort because it will also require coding to include the alternate_name on the field. So for me it’s better to decide case by case if the alternate name should be shown and where should be shown.

@josesalvador

i.e. Perhaps we can document every search_rec_name function and show this as the tooltip of the entry box.

We currently do not have any mechanism to document functions to the User.

@josesalvador

Also, maybe would be a good idea to set help to value field (aka code at this moment) of the party.identifier with something like: “If no type is assigned this field can be used to set the trade name of the company, the alternate name of the contact and similar use cases like these” .

I find this too much specific but we may add a help to the type: “The type used to validate the value, leave empty to use any additional name”