Import with No Duplicate Check for Individuals created Organisations too

[petednz]

Hey - did an import of individuals that I had already imported the Orgs for. I knew these had same names as other contacts but were in fact different people, so set import to be Individuals and No Duplicate Check

Was surprised when it told me it had imported 701 rows when i only had 360 or so to bring in! Had added to new group which confirmed 701 and I realised it had created contacts for the Organisations. I don't think is expected when one has set it to be Individuals.

Will have a go on demo and report back.

[petednz]

Bit more info - my file had Organisation Name and I had my mapping set to 'Employee of" "organisation name" - the organisations all already existed, hence my expectation that it would simple add the Individual and include the Relationship to the existing organisation.
Seems it doesn't check for an existing organisation as part of No Duplicate CHeck and therefore sets up new organisation.

This occured on Demo too. See import 'NoDupChk test for demo'.

I would consider this an inconvenience if not a bug.

If this is expected behaviour then I suppose there is a way around it by doing the NoDupChk import without 'employee of' set to import.

Then I will have to reimport with an 'update' setting.

Is that the way to go?

[petednz]

Ok so I meant use Fill not Update - but was surprised that while that added Job Title it did not add the Relationship. Anyone know what I am missing.

I did an import on Demo too (NoDupChk update for demo) - same problem.

[petednz]

So the solution has been to Export the group, do a VLOOKUP then reimport the Employee of data including the Internal Import. Still suspect there is a tweak that would make the Employee for relationship import as outlined earlier.

[Dave Greenberg]

Import of Individuals w/ "related contact info" for Employer (Organization Name) in 2.0 should "simply add the Individual and include the Relationship to the existing organisation." - as you've noted. If the Organization Name was entered exactly the same as the existing ones, it sounds like this is another bug in the import process. (Organization duplicates are detected based strictly on organization name in 2.0 and prior.)

In 2.1, the duplicate matching on contacts has been reworked substantially - and you will be able to configure the "strict" matching rules for organizations - so hopefully this will all work better. Please file an issue for this so we can verify that things are working properly in 2.1 (or fix there if needed).

[petednz]

Rats - looks like i never filed this. http://issues.civicrm.org/jira/browse/CRM-3211 - back to same situation now.

[petednz]

Phew - figured a workaround. Copy file, change all surnames to same unique string - eg names2change - and ensure you have a Unique ID for each record that goes in to a new custom data field if you don't have one already.

Do import (no duplicates do just use Skip) this pulls the records in and creates the relationship to the original Org - ie does not create a duplicate org.

Then Adv Search all Surname=name2change, export Internal ID and the Unique ID.

Use the Unique ID to align the Internal ID with the original dataset

Import Internal ID plus the original Surname using Update.

hey presto - bit of a mission but gets me out of a hole that is holding up other projects.

[Dave Greenberg]

Peter - Re-reading this, I'm thinking that your "expected" behavior is questionable. Import does not provide a way to specify "Duplicate handling" mode for "related contacts" separately from the "main contacts". So... I if select "No Duplicate Checking" - it seems reasonable to expect that this mode applies to ALL contact insert actions for that import session.

It seems like the behavior you're expecting would require two "flags"...

For Duplicate Contacts: Skip, Update, Fill, No Duplicate Checking -> set this to "No Duplicate Checking"
For Related Contacts: Skip, Update, Fill, No Duplicate Checking -> set this to "Update" (which would mean add a relationship)

... and I'm wondering how common a requirement this is ....??

[petednz]

Yep - understood - which is why i worked out a workaround. Anomolies always take the longest time to sort. I guess the issue is still that by doing such an import it creates an organisation with no contact details. As you say, probably a rare situation, so one that just requires an extra step in the import.

[Dave Greenberg]

Ok - I've closed the above issue as Won't Fix...