CiviCRM Community Forums (archive)

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.

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.

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).

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.

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.