Handling Household/Individuals Upon Initial Install

[Shai]

I'm doing a Civi/Drupal install for a new client.

I've got 2000 records that I'll be importing from a csv file. 1600 records are individuals and 400 records are households. The individual members of the households do not, in the csv, have their own individual rows.

The use case is pretty typical... small non-profit that will want to communicate via snail mail and email, solicit contributions, etc.

I'm aware of this new thread about thinking of new data structures for households:
http://civicrm.org/node/558

The csv I'm working with for import has a "First name field." In the case of a joint record it has "George and Jane". There is also a full name field which comes out to, "George and Jane Jetson".

Here is what I'm thinking for the records that cover two people in the household:

• Boning up on my regular expression chops... manipulate the csv I've got so that there is one row for each individual. I would import all the rows as "individuals,"  thus not initially using Civi's "Household" functionality at all.
• Use the current first name field for the "custom greeting field" (e.g. "Dear George and Jane")
• Mark one of the two records in each case "do not mail, do not e-mail"
• I would add a special tag to all these folks for easy retrieval later

Since it looks like major changes are in the works for data architecture in Civi around Households, seems like keeping it simpler and avoiding that functionality could be helpful to avoid what might be tough upgrade issues later.

Please let me know if I'm on the right track or if you have a better idea of how I should proceed.

Shai

[Donald Lobo]

I dont think that blog proposal calls for any radical changes. The biggest change is to basically use the greeting field in a more intuitive manner. As such i do think using household might make sense for your use case.

You might want to use your regex chops and import the household along with the individual using the relationship import feature

Tony or some other folks might chime in with their recommendations.

lobo

[dharmatech]

Hi Shai. I agree with lobo that all we're really proposing is improving CiviCRM's greeting/address features and extending the shared address concept to all contacts. And making the HH contact type optional for groups that don't need it.

In your case, I would actually disagree with lobo and suggest you go ahead with your plan to not use HH's. That's what I would do if I were you I think it is very similar to our clients where the HH contact type doesn't serve any real purpose other than allowing for shared addresses and maybe tracking joint contributions.  Those purposes are not worth the headache, IMO, of trying to manage HH contact types.

A few other questions/notes you should ask yourself in making your decision:

• Do any of your contacts share email addresses? If so, you should consider using two greeting fields (postal & email) as we suggest in the blog post.
• Is the current soft-credit functionality currently enough to meet your needs as far as tracking contributions from HH's? You may need to create a custom report to find those with soft credits, for example.
• For your data-entry staff you may want to make your greeting fields mandatory. This ensures that field is always entered but also allows the staff to do your mail merge for CiviMail or snail mail off of the same field for all records in your DB.

I hope this helps
tony

[petednz]

In case it helps when you come to chopping up your combined text fields - http://office.microsoft.com/en-us/excel/HA101023411033.aspx?pid=CH100793501033