Long Form Column Names are useful when you need to import multiple instances of the same data type, when you want to be more specific about where it should be stored, and when there is no Short Form Column Name available. A Long Form Column Name consists of the import path (the name of the Andar database table that will store the imported data), an index to identify the instance, and the field name. For example:

Individuals[1].addresses[1].addressType

Click on the following for more instructions on how to use Long Form Column Names:

• Why Using Long Form Column Names
• Format of Long Form Column Names
• What Can Be Imported Using Long Form Column Names
  • Account Dates
  • Addresses
  • Analytics
  • Annotations
  • Billing Schedules
  • Bill Schedule Details
  • Designations
  • Donor Choice Structure
  • Demographics
  • Employee Relationships
  • Individual Information
  • Leadership Information
  • Names
  • Numerical Information
  • Organization Information
  • Phone/Fax Numbers
  • Transactions
  • Tracking Parameters
• Formatting the Values in the CSV File
• Long Form Column Name Notation
• Table Hierarchy
• Default Index Number
• Known Limitations
• Error Messages

Why Using Long Form Column Names

• You need to use the import path (Long Form Column Name) whenever there is not a Short Form Column Name set up in the cross reference file called CIEAliasDtl. The list of Short Form Column Names can be found in A List of Short Form Column Names for Data Imports.

The following information can only be imported using Long Form Column Names:

• Donor Choice Structure
• Tracking Parameters

For some tables, a limited number of fields can be used as Short Form Column Names. Other fields are importable only by Long Form Column Names. For example, supported Short Form Column Names for Annotations are ExtDocumentFilename1, ExtDocumentFilename2, ExtDocumentRefOnly while many more fields in Annotations are importable using Long Form Column Names.

• You need to import multiple instances of the same data type into Andar.
• There may be other times when you either want to or actually need to use the import path and field (Long Form Column Name) instead of the Short Form Column Names. These are generally any time you want or need to be more specific about what you are importing. For example, the short name "ADDRESSLINE1" maps to the import path and field "'IndOrg.Addresses.ADDRESSLINE1". Since it is an IndOrg rooted path, whether it is for an Organization or Individual account depends on the rest of the CSV record. If only one of the two account types is present, the result is obvious. But if both ORG and IND accounts are present, the field will be applied to the IND account, and this may not be what you actually want to do. The remedy for this is to use the import path and field "Organizations.Addresses.ADDRESSLINE1" in order to guarantee that the field will be applied to the Organization Account. The import path and field names also make it possible to specify BOTH an Organization and an Individual account address (or phone number, or transaction, or ...) in the same CSV record. Short Form Column Names do not provide this capability.

Format of Long Form Column Names

A Long Form Column Name consists of the import path (the name of the Andar database table that will store the imported data, for example, Individuals), an index to identify the instance (for example, Individuals[1]), and the field name. The table names must be the exact table names found in the Andar database (as shown below). The field name must be the exact field name found in the corresponding table (for example, ACCOUNTNUMBER). Table names and field names are not case-sensitive. When a table depends on another table, the entire table tree must be present.

Examples of Long Form Column Names:

The simple Column Header for an individual account:

Individuals[1].accountNumber
Individuals[1].firstName
Individuals[1].lastName

Column Headers for the address of an individual:

Individuals[1].addresses[1].addressType
Individuals[1].addresses[1].addressLine1
Individuals[1].addresses[1].zipPostalCode
etc.

In the same CSV file, you can have multiple instances of the same data type. For example, you can have multiple addresses for the same individual. Just give a different index number in the Column Header to the data type (for example, Addresses[2]) to allow multiple instances to be imported.

Individuals[1].Addresses[2].addressType
Individuals[1].Addresses[2].addressLine1
Individuals[1].Addresses[2].zipPostalCode

This also applies to more complex database tables, for instance:

Individuals[1].Transactions[1].DCDetails[1].DCWriteIn.Name1
Individuals[1].Transactions[1].DCDetails[1].DCWriteIn.Name2
Individuals[1].Transactions[1].DCDetails[2].DCWriteIn.Name1
Individuals[1].Transactions[1].DCDetails[2].DCWriteIn.Name2

DC Write-Ins

Andar Connector reserves the DCDetails[1] to DCDetails[13]fields for the 12 designations and the one write-in inherited from Lockbox. Do not use DCDetails [1] to [13]for user-defined write-ins.

Andar Connector allows unlimited number of designations. You can use any index number higher than 13 (for example, DCDetails[14], DCDetails[15],DCDetails[500])for the user-defined write-ins. The index number does not have to follow a particular numerical order (for example, they can be DCDetails[15],DCDetails[500],etc. ).

Only one write-in is allowed per DCDetail. Therefore, DCWriteIn does not require the index number. Simply use DCWriteIn.Name1,DCWriteIn.Name2, etc. to add separate columns for each field of the DCWriteIn.

Individuals[1].Transactions[5].DCDetails[50].DCWriteIn.Name1
Individuals[1].Transactions[5].DCDetails[50].DCWriteIn.Name2

What Can Be Imported Using Long Form Column Names

Information can be imported into Andar using the importable fields in the following tables. The table names and the field names will be part of the Long Form Column Names. Table names and field names are not case-sensitive.

• AccountDates
• Addresses
• Analytics
• Annotations
• BillingSched
• BillSchedDtl
• ContactRelationships
• DCDetails
• DCParameters
• DCStructure
• Demographics
• EmployeeRelationships
• EnvelopeMaster
• Individuals
• LSIndiv
• Names
• NumericalInformation
• Organizations
• PhoneNumbers
• Transactions
• TrackParm

Table: AccountDates

Fields:

Column Header Notation

The notation is simply:

TableName[index].{TableName[index].}fieldname

Where:

• TableName is a database table name (also called FileName) in the Andar database.
• index is a integer >= 1 and [index]is optional if only one instance of its TableName is present in the import CSV file.
• Anything between "{" and "}" can be present zero or more times.

Special Table Name: IndOrg

Transactions, Addresses, e-Mails, Phone Numbers, and other information can be associated with both Individuals and Organizations. To allow binding the information to either the individual or the organization at processing time a special table name IndOrg is accepted and will be replaced by Individuals or Organizations during processing. For example, the follow table hierarchies are allowed (this is not a complete list):

IndOrg.AccountDates
IndOrg.Addresses
IndOrg.EMails
IndOrg.Names
IndOrg.PhoneNumbers
IndOrg.Transactions
IndOrg.Transactions.Annotations
IndOrg.Transactions.BillingSched
IndOrg.Transactions.DCDetails
IndOrg.Transactions.DCDetails.DCWriteIn

How IndOrg is interpreted by Andar when importing data

When data is imported, the following rules are used to determine whether a specific IndOrg column will be converted to Individuals or Organizations.

1. If only individual account information (e.g. account number) is present in the import record, use Individuals.
2. If only organization account information is present, use Organizations.
3. If both individual and organization account information is present, use Individuals.
4. For transactions, if the transaction type is for organizations only, use Organizations.
5. For transactions, if the transaction type is for individuals only use Individuals.
6. For transactions, if the transaction type can be for Individuals or Organizations, follow rules 1, 2, and 3.

When to use IndOrg instead of Individuals or Organizations

Using IndOrg is not recommended. IndOrg exists only for legacy reasons to enable importing a particular type of information for either individuals or organizations at the same time within the same import CSV file. However, under this scenario it is now advisable to use discrete Long Form Column Names for the individuals and organizations information rather than the legacy IndOrg format names. Always use Individuals or Organizations whenever you know that the data you are importing is specifically for an individual or an organization account. This is especially important when it is for an organization account since in many cases Individuals will take precedence over Organizations when using IndOrg. Using discrete columns will eliminate confusion and avoid potential mistakes caused by the presence of both individual and organization account information in the import record. It can also decrease the amount of time required to process the import file because no conversion from IndOrg to Individuals or Organizations needs to be performed on each record.

An example of this would be names information. Your import CSV file may have columns for both individual account and organization account, as well as columns for the name information (name type, line 1, line 2 etc.) Some records in the import CSV file will have an individual account and some will have an organization account, but never both.

Using IndOrg will allow the names information for both the individuals and the organizations to share the same columns. If a particular record has an individual account, the names information will be applied to the individual. Otherwise if the record has an organization account it will be applied to the organization. The CSV file would look something like this:

Using Individuals and Organizations will allow this same information to be imported using a single record instead of two records. This can also improve processing speed, especially for large import files. The improved CSV file would look something like this:

As a general rule, be sure to always use discrete Individuals and Organizations columns instead of IndOrg columns.

Table Hierarchy

The correct table hierarchy must be respected. For instance, an Address must always be associated with an Individual, an Organization, or an IndOrg; a Designation must always be associated with a Transaction, which must itself be associated with an Individual, an Organization, or an IndOrg.

Current valid hierarchy is:

Individuals
Individuals.EmployeeRelationships
Individuals.LSIndiv
Organizations
IndOrg.AccountDates
IndOrg.Addresses
IndOrg.EMails
IndOrg.Names
IndOrg.PhoneNumbers
IndOrg.Transactions
IndOrg.Transactions.Annotations
IndOrg.Transactions.BillingSched
IndOrg.Transactions.DCDetails
IndOrg.Transactions.DCDetails.DCWriteIn

Where IndOrg can be replaced by an Individual or an Organization.

Information Passed from Parent Table to Child Table

All the necessary information contained in the parent database table will be passed to a child database table. For example, the Account Numbers will be passed to Transactions when required and the Transaction Type will be passed to the Billing Schedule.

For instance, an address will require an Individual or Organization account number. That account number should be identified in the parent table of the address (Individuals,Organizations, or IndOrg) not in the ACCOUNTNUMBER field in the Addresses table.

Default Index Number

If the index number is omitted, “1” will be used. That means that Individuals[1].firstName is equivalent to Individuals.firstName.