Add alternate name to Party

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.


  • 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.


  • 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).


That’s the 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.

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.

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.

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.

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.

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.

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)

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

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

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.

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

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

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.

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.

1 Like

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

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.

+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”.

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.

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

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”