Name in Party model

[Vincent Bastos]

Hi,

I have a current requirement for the party field to have a first name and a last name. This is going to be especially useful when we send out email to customers. AFAIK in English and French speaking countries most people are addressed to using their first name.

A few software solutions I have seen around usually separate the name as 2 fields, but I suppose this probably depends if the business is dealing with people as customers or business as customers.

I would be interested to hear whether other people have had similar requirements/use cases to have a first name and last name and what their solutions have been?

I know that in Salesforce for example, there are 2 types of "Account" "objects" ( in Tryton this translates to Party models ): a "Person Account" and a "Business Account". The business account only has a name field, but the Person account has a "composite" name field made up of 2 fields ( first name and last name ).

Also all the most popular web based accounting packages have first name and last name field.

I am not saying that they are correct, but I curious to hear people's thoughts around this topic.

Cheers,

[Jean C]

2014-12-30 13:00 GMT+01:00 Vincent Bastos <vin...@lavalab.com.au>:

I am not saying that they are correct, but I curious to hear people's thoughts around this topic.

Names are tough :

http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

That said, we had the same requirements from our (french speaking) clients.

We dealt with it by adding a first_name field, using the name field for the

last name, and overriding get_rec_name to display both if needed.

Jean Cavallo

Coopengo

[Cédric Krier]

On 30 Dec 13:58, Jean C wrote:
> 2014-12-30 13:00 GMT+01:00 Vincent Bastos <vin...@lavalab.com.au>:
>
> > I am not saying that they are correct, but I curious to hear people's
> > thoughts around this topic.
>
>
> Names are tough :
> http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

I even think we should remove the required on the name of Party.
We have code for this case.

> That said, we had the same requirements from our (french speaking) clients.
> We dealt with it by adding a first_name field, using the name field for the
> last name, and overriding get_rec_name to display both if needed.

The best solution is to convince your customer that their requirements
are wrong.

A possible generic solution will be to use a list of type of name (maybe
a Dict field) that could be used to autofill the real name with maybe
some sort of formatting depending on some context like the language, the
primary country etc.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Guillem Barba Domingo]

2014-12-30 14:39 GMT+01:00 Cédric Krier <cedric...@b2ck.com>:

On 30 Dec 13:58, Jean C wrote:
> 2014-12-30 13:00 GMT+01:00 Vincent Bastos <vin...@lavalab.com.au>:
>
> > I am not saying that they are correct, but I curious to hear people's
> > thoughts around this topic.
>
>
> Names are tough :
> http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

I even think we should remove the required on the name of Party.
We have code for this case.

> That said, we had the same requirements from our (french speaking) clients.
> We dealt with it by adding a first_name field, using the name field for the
> last name, and overriding get_rec_name to display both if needed.

The best solution is to convince your customer that their requirements
are wrong.

If you want to integrate Tryton with some official system, for example, you must to manage the names correctly. It is; know each part of name (in Spain, for example, first name, first last name and second last name)

A possible generic solution will be to use a list of type of name (maybe
a Dict field) that could be used to autofill the real name with maybe
some sort of formatting depending on some context like the language, the
primary country etc.

It sounds good. It could be something similar to Gmail contacts (but not limited to the 5 fields that there are in Gmail).

--

Guillem Barba
http://www.guillem.alcarrer.net

[Sergi Almacellas Abellana]

El 30/12/14 a les 14:39, Cédric Krier ha escrit:

> On 30 Dec 13:58, Jean C wrote:
>> >2014-12-30 13:00 GMT+01:00 Vincent Bastos<vin...@lavalab.com.au>:
>> >
>>> > >I am not saying that they are correct, but I curious to hear people's
>>> > >thoughts around this topic.
>> >
>> >
>> >Names are tough :
>> >http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> I even think we should remove the required on the name of Party.
> We have code for this case.
>

Sounds good to me.

>> >That said, we had the same requirements from our (french speaking) clients.
>> >We dealt with it by adding a first_name field, using the name field for the
>> >last name, and overriding get_rec_name to display both if needed.
> The best solution is to convince your customer that their requirements
> are wrong.
>
> A possible generic solution will be to use a list of type of name (maybe
> a Dict field) that could be used to autofill the real name with maybe
> some sort of formatting depending on some context like the language, the
> primary country etc.

For me it's better to create specific fields on custom module (and
override rec_name and full name if needed). For example:

https://bitbucket.org/zikzakmedia/trytond-party_type/src/28d0479d00511c05ffa00171e91785ad23a8da19/party.py?at=default

--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Cédric Krier]

On 30 Dec 15:13, Sergi Almacellas Abellana wrote:
> >A possible generic solution will be to use a list of type of name (maybe
> >a Dict field) that could be used to autofill the real name with maybe
> >some sort of formatting depending on some context like the language, the
> >primary country etc.
>
> For me it's better to create specific fields on custom module (and override
> rec_name and full name if needed).

I don't think so. Fixed number of field will not make it generic.
Also as Nicolas tells me, you could also have different format of the
name for different usage mail, email, reporting etc.
Being able to create new type will be a better design.

[Vincent Bastos]

Cedric,

Could you elaborate what you mean by creating a new type?

[Cédric Krier]

On 11 Jan 15:32, Vincent Bastos wrote:
> Cedric,

>
> On Wednesday, December 31, 2014 at 12:55:03 AM UTC+10, Cédric Krier wrote:
> >
> > On 30 Dec 15:13, Sergi Almacellas Abellana wrote:
> > > >A possible generic solution will be to use a list of type of name
> > (maybe
> > > >a Dict field) that could be used to autofill the real name with maybe
> > > >some sort of formatting depending on some context like the language,
> > the
> > > >primary country etc.
> > >
> > > For me it's better to create specific fields on custom module (and
> > override
> > > rec_name and full name if needed).
> >
> > I don't think so. Fixed number of field will not make it generic.
> > Also as Nicolas tells me, you could also have different format of the
> > name for different usage mail, email, reporting etc.
> > Being able to create new type will be a better design.
>
> Could you elaborate what you mean by creating a new type?

You can look at the name of party as plurial depending on the usage.
So instead of having a field, we could have a list of field with each
one a type.
Possible types:

- Firstname
- Lastname
- Middle anme
- Nickname
- Fullname
- Signature
etc.


PS: Please don't top-post on this mailing list, see
http://groups.tryton.org/netiquette

[Mark Hayden]

Names and dates/times always seem to present the most challenges don't they?

On 30 Dec 2014 05:20, "Vincent Bastos" <vin...@lavalab.com.au> wrote:
>
> Hi,
>
> I have a current requirement for the party field to have a first name and a last name. This is going to be especially useful when we send out email to customers. AFAIK in English and French speaking countries most people are addressed to using their first name.

That is true I think for most western languages. Asian seems to be the one with most exceptions here.

> A few software solutions I have seen around usually separate the name as 2 fields, but I suppose this probably depends if the business is dealing with people as customers or business as customers.
>

I think Tryton's approach is the simplest, however there are cased where businesses have entrenched the practice of filing things by last name for people, and just the party name for businesses.

> I would be interested to hear whether other people have had similar requirements/use cases to have a first name and last name and what their solutions have been?

I have played with extending party module to add an optional second name field to handle first/given names of people, just like addresses have the optional address-bis line. Then the original name field is used for the whole name of companies/non-people parties and for people it is the last/surnname.

I did a "full name" function field with searcher that joined the two fields and served as the display name of the party record. If you wanted to get sophisticated you could have a boolean field to indicate reverse order required so Asian names properly and a salutation field with selections for Mr, Mrs, Ms etc.

I also wrote a searcher function so search on full name works just like search on the existing single field.

This seems to cover enough to make everyone happy.  If you want i can show the code to do the above.

> I know that in Salesforce for example, there are 2 types of "Account" "objects" ( in Tryton this translates to Party models ): a "Person Account" and a "Business Account". The business account only has a name field, but the Person account has a "composite" name field made up of 2 fields ( first name and last name ).
>

I don't like that sales force solution-tryton is simpler and better with its model ;-) also Tryton has ways to classify or group parties and special models would complicate and be redundant.

> Also all the most popular web based accounting packages have first name and last name field.
>

This is true. Mostly because of the somewhat irrational insistence to file by last name, though the valid reasons for doing so such as keeping family records together and making filing and searching easier are more and more obsolete in the age of computers and electronic information management.

> I am not saying that they are correct, but I curious to hear people's thoughts around this topic.

As i said mostly the reasons to separate names are obsolete, though there is one good reason to do so, which is for correspondence. For example:

John Smith might be shown as Mr. John Smith on a mailing label. In a letter they may be greeted as "Dear John," or for formal letters "To Mr. Smith:". If he is in a report listing overdue accounts receivable it might be shown as "Smith, John". Making multiple name fields makes it more flexible for this.

The other suggestion of having a plural field something like contact mechanisms works now would work too but i think it is too complex, especially when a party changes her name, which still happens a lot when a woman gets married. You might have to change multiple name entries and deal with more potential inconsistent use of the multiple key/value entries.

My proposal would be to leave Party as it is but establish a "party.names" module to extend the party to handle names as above, or possibly the way contact mechanisms work if the complexity is not a turn off.

Should we set up a blueprint?

>
> Cheers,

[M. Murray]

In GNU Health, they have boolean fields on the party to select :

• is_person,
• is_patient
• is_pharmacy
• is_institution (e.g. hospital, doctor's office)

They then add a "Lastname" field that holds the surname for the parties with is_person=True

We have extended this model a little by adding firstname and middlename fields that are invisible for all parties that are not is_person. We then make the name field readonly when you check "is_person" and generate a name as surname, firstname m. or surname, firstname if there's no middlename.

[Vincent Bastos]

On Monday, January 12, 2015 at 10:10:04 AM UTC+10, Cédric Krier wrote:

You can look at the name of party as plurial depending on the usage.
So instead of having a field, we could have a list of field with each
one a type.
Possible types:

    - Firstname
    - Lastname
    - Middle anme
    - Nickname
    - Fullname
    - Signature
    etc.

I am interested in this, but I have no idea how to actually implement this. I found the field type "dict" in the documentation, but no idea how to use it. Can you point to an example?

As mentioned in an earlier email of this thread; the idea is that when you send an email you don't necessarily want to use the full name, but just the first name.

[Cédric Krier]

On 2015-07-04 22:16, Vincent Bastos wrote:
>
>
> On Monday, January 12, 2015 at 10:10:04 AM UTC+10, Cédric Krier wrote:
> >
> >
> > You can look at the name of party as plurial depending on the usage.
> > So instead of having a field, we could have a list of field with each
> > one a type.
> > Possible types:
> >
> > - Firstname
> > - Lastname
> > - Middle anme
> > - Nickname
> > - Fullname
> > - Signature
> > etc.
> >
>
> I am interested in this, but I have no idea how to actually implement this.
> I found the field type "dict" in the documentation, but no idea how to use
> it. Can you point to an example?

You could use a Dict field but I get in mind a One2Many.
You can look at product_attribute about how to use Dict field.

[Raimon Esteve]

2015-07-05 9:21 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 2015-07-04 22:16, Vincent Bastos wrote:
>>
>>
>> On Monday, January 12, 2015 at 10:10:04 AM UTC+10, Cédric Krier wrote:
>> >
>> >
>> > You can look at the name of party as plurial depending on the usage.
>> > So instead of having a field, we could have a list of field with each
>> > one a type.
>> > Possible types:
>> >
>> > - Firstname
>> > - Lastname
>> > - Middle anme
>> > - Nickname
>> > - Fullname
>> > - Signature
>> > etc.
>> >
>>
>> I am interested in this, but I have no idea how to actually implement this.
>> I found the field type "dict" in the documentation, but no idea how to use
>> it. Can you point to an example?
>
> You could use a Dict field but I get in mind a One2Many.
> You can look at product_attribute about how to use Dict field.

About party + dict, you could read code from party attributes module
(idea similar than product attributes)

https://bitbucket.org/zikzakmedia/trytond-party_attribute

Regards

Raimon