CiviCRM Community Forums (archive)

I've spent years looking for a system like CiviCRM.  I'm a new user and have a good understanding so far.

We currently use MS Access and the importing via CSV is awesome.  Before going too far, though, I'd be grateful for some advice:

1.  Our existing database includes about 4,500 records reflecting (a) individuals, (b) married couples and (c) children's names.  Donation data also is kept on these same records.

2.  It seems like the import strategy should be to (a) first import each and every record as a Contact and (b) having done this, import the donor data and let  CiviCRM automatically match it to the correct Contact.

-- First, does this sound logical?  Am I missing anything obvious?

Second and confusing to me:  I can't figure out if my 4,500 records should be brought in a Households or Individuals?  There does not seem to be a drawback to using Households.  Many of our records will have family member data. Two issues concern me:

-- Is it "okay" to have a Household with one person in it?

-- Is it "okay" to solicit, mail, attribute donations to a *Household* or must these attach at the Individual level?

Finally, many of our Households need to be addressed as "Dear Jane and John" or Dear Smith Family", especially when we solicit or thank them for donations.  The Household record seems to create a "Dear Smith" result (which is incorrect) and assigning to one individual (i.e., Dear Jane) is not correct either.  Options I'm considering:

-- A custom field that creates Dear Smith Family, where Smith is supplied by the appropriate token.

-- A hand-coded field for each record to force records to go out correctly.  We actually have hand-entered this data in the MS Access database. Is it possible to import that field to each new Household record?

I've searched the boards and documentation and have seen some discussion, but am still confused.

Thanks in advance for any help or references.

In my experience, household is used if it makes sense to have and hold data at that level. So for example, a welfare organization offering family care will certainly want to use households as a separate entity because they will be addressed as a household and there will be family specific cases with CiviCase for a household, wilst other cases will be dealing with individual support. So the real question is: do you do anything specific with households in your organization that justifies it being a separate entity? If not, Coleman's household lite might be a good option for you.

Just FYI we have found a multitude of issues using Households and Individuals as intended in Civi when you are dealing with contribution data. Generally having households and relationships works well, but not with contribution data.

Specifically if a contribution is linked to an individual (which is pretty much necessary in Civi, esp. if you are accepting credit cards), then you will have issues, esp. if you are trying to search and mail to people based on giving levels (which most larger organizations do).

In reality a contribution is from/for a household most of the time, but needs to be entered in Civi associated with an individual (don't try to mix and match contribution data in both HHs and individuals). When you search based on contribution data, you will get duplicate data. For example if you have Fred, Julie, and Jason (kid) in a household and Fred donated $250 once, Julie donated $25 once and Jason never donated because he is a kid, you will get the household in all three categories for low donor, high donor, and non-donor after merging into their respective households (which you have to do unless you want to send separate letters to each person in the household). There are soft-credits, but don't always help and only can be attributed to one other person or entity.

Currently to do mailings I have to manually de-dupe lists in Excel after export, which is large time sink. There is also the issue where one can't search by contribution totals for an individual in a set time frame (there is a custom search, but it doesn't work well and lacks all the important fields in advanced search). The ideal solution would be to incorporate in advanced search: being able to total contribution data for a set time frame (being able to choose multiple contribution types is of utmost importance with this), while also having the ability to total by everyone in a household.

There would likely be other issues using an individual to represent a household and just having all records as individuals, but if I had to do it over I may go this route.

Thanks, Lobo. We are still on 4.1.6, but I will test this extension on another install... it sounds quite promising! We will be upgrading to the current version eventually, but will be trying a simultaneous upgrade to Drupal 7, so it's a little scary.

Great news on Soft Credits, because there were other issues with that as well, such as if Personal Campaign Pages (PCP) were being used, Soft Credits could no longer be used on that contribution since it was already being used by the PCP. Glad to hear that has already been changed in 4.4.

In answer to your number 2 question, here are some suggestions (mainly to the Advanced Search page):

1) Include contribution total by date range field in Advanced Search (this is very useful, but less so unless #2 is also implemented). This needs to be able to roll up totals by household as well.
2) Change the Contribution Type field to be a multiple choice selection (like tags or groups). Currently any contribution search's usefulness is severely limited by only being able to choose one.
3) As planned or implemented in the above mentioned extension, have some type of Last Contribution field that is updated every day, which could also roll up the output by everyone in a household.
4) When one does a Contribution Search, make the export functionality include more options (like a contact search), esp. being able to merge individuals into their households for mailings.

Thanks for everyone's work on CiviCRM! Some day when I learn PHP and MySQL I'll try to help more with code improvements.

We'd like to be on Drupal 7, but it sounds like we should consider moving to CiviCRM 4.4 on Drupal 6 for now. Thanks for the advice.