Names and dates/times always seem to present the most challenges don't they?
On 30 Dec 2014 05:20, "Vincent Bastos" <[email protected]> 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,
