Depending on the issue, different solutions apply.

Foreign keys or associations does not exist

When setting a foreign key or association, the resources to associate to must already exist. The Import Rule does not create these. (A separate Import Rule can be used beforehand, however, to first create these.) For example, when setting the Location association to a location of New York, this location must exist in Manage > Assets > Organizational Types > Location. If these are not present, the column or row will be skipped. This can affect anything that uses foreign keys or associations, such as locations, cost centers, stock rooms, departments, purchase order line items, cost items, etc.

The Import Rule's mappings were set incorrectly

Use the correct association mapping to successfully set them. Several guidelines apply to this:
 

• A data class association is a SQL JOIN. This then is seen as "JOIN table1.value = table2.value". This is therefore not a direct assignment.
• When an association mapping is first created, after the Lookup key is added by the user, the Key column mappings is automatically set to the same value as what the user picks for the Key mappings. This is generally not going to be the same data class. For example, a Cost Center import rule may be used, which also assigns parent cost centers. The Association mappings section would then appear as the following:
  
  Name: Cost Center Association
  Type: Cost Center --> Cost Center [1:1]
  Lookup key: Cost Center Code
  Key column mappings: Parent Cost Center Code
  
  If the Key column mappings is left as the default, Cost Center Code, this will result in the Cost Center showing that it belongs to its own hierarchy (incorrect) and also throw off viewing this in picker windows and the Organizational View window. Instead, the user must manually change the Key column mappings value to be Parent Cost Center Code.
   
• This works similarly with reverse association mappings. Reverse associations can be optional, depending on what the user wants to achieve, but are generally not required, such as in the above scenario. The following is an excerpt from the user guide that discusses the differences:
  
  "The data association table lets you specify mappings for associated resources. When you import data, the appropriate values can be matched up with the correct associated resource. For example, if you import data for phones, which includes a location, the imported location value can be looked up in the Location resource type, and the correct location value is associated with the phone. If you export data, the associated data can be exported along with the selected resource type and mapped to the correct output field.
  
  You can also specify a reverse association mapping. For example, if you import a location, which is the child resource type of the Contract’s Location association, you have a column in your database containing the name of several contracts. Running the import rule updates those contract resources and associate them with the location." 

Related Articles

How to import data using a Data Connector Import Rule
http://www.symantec.com/business/support/index?page=content&id=HOWTO79380

Data Connector Import Rule fails to set a foreign key correctly
http://www.symantec.com/business/support/index?page=content&id=TECH192860

Orphaned Cost Center Data
http://www.symantec.com/business/support/index?page=content&id=TECH40981

How to create a Data Connector import rule to assign a computer's location
http://www.symantec.com/business/support/index?page=content&id=HOWTO64381How to create a Data Connector import rule to assign a user's department or location
http://www.symantec.com/business/support/index?page=content&id=HOWTO64259

Data Connector Import Rule fails to set a foreign key correctly
http://www.symantec.com/business/support/index?page=content&id=TECH192860

How to troubleshoot import issues when using a Data Connector Import Rule
http://www.symantec.com/business/support/index?page=content&id=TECH195835