Hi, this is a simple one...I hope!
We're on V12.5. The Output Element "customer_lname" brings up first AND last names of couples in a household. This is really annoying for us - it means we can't alphabetize lists by last name, which we often need to do if its for an event and tracking RSVPs and reporting on these, as well as for running mailing lists by our CEO...she just wants to check them in alphabetical order!
Is there something wrong with our Output Element...or is there something I'm missing? Or is the Output Element truly this dysfunctional?? Please help :-)
I can't help on the outputs as I'm still a Tess newbie, but I have a great Excel trick you can use in the interim if you are outputting your list to Excel - if you don't know it already. You can use Text to Columns to split the "Mary Smith" column into two, one with just Mary, one with Smith. It goes a bit wonky if you have anyone with three names, but 99% of the time is great. Here is the step by step: support.office.com/.../split-a-cell-f1804d0c-e180-4ed0-a2ae-973a0b7c6a23
"Customer_lname" will unfortunately pull both names together. We get around this by adding "Sort Name" to your output set though. This will pull an additional column with whatever the A1 constituent's sort name is on the account. In the case of John and Mary Smith, the sort name would be Smith/John, allowing you to alphabetize by the last name.
This is by design; any constituent record that is of a type other than "Individual" (for example, Corporation, Institution, Household, etc.) only uses the lname field. Admittedly, this can be confusing when pulling your first lists, but the intention here is to use Salutation fields when you need information appropriate for merging with a list -- I would say it's actually an antipattern to pull fname, mname, lname at all unless you are trying specifically to see the data as it is stored in the T_CUSTOMER table.
For alphabetization, as Juliane wrote, sort_name is the appropriate element to pull.
It is possible to design custom elements to pull separate name fields for A1 and A2 constituents on a household. We do this for purposes of integrating with a separate database by using a custom view, but you could actually design your own output elements (TR_QUERY_ELEMENT) around the legacy bridge view VB_CUSTOMER, which still exists in the database as of 14.1.7. This view replicates how "household" records looked prior to Tessitura v11, which is what introduced the household model.