EIM will not interfere with Siebel VB code because Siebel VB works at the business component and business object level, and EIM works at the table level.

You can only use EIM to import bulk data from legacy systems into the Siebel database. Only ACT! 2.0 and ACT! 3.0 have File/Import functionality for data import into Siebel. You can use “Exporter for ACT!” to export ACT! 4.0 or 2000 Contacts, Notes/History, Activity, Group, Sales and E-Mail data into commadelimited files. For information on ACT! products, visit their website at http://www.actaddons.com.

Several columns are mandatory. Others are conditionally mandatory, depending on the conditions of your import. Your Siebel application offers two methods for determining mandatory columns. You can use Siebel Tools to view each column in an interface table and its target base table columns. You can also refer to Siebel Interface Tables Reference. By adhering to Siebel’s recommended import sequence, you make sure that the appropriate data dependencies are established.

Yes, EIM supports various case values defined for base table columns in Siebel Tools. EIM will adjust the case value of an interface table column according to the Force Case property of the corresponding base table column.

The S_PARTY table is the parent of many Person or Organization related objects in Siebel. For example, S_CONTACT, S_ORG_EXT, S_POSTN, S_EMP_PER are all child objects of S_PARTY.

Relationship between two different PARTY objects, example: Account and Contact or Employees and Positions is stored in the intersection table S_PARTY_PER. For example, if an Account has three different contacts then there will be 3 records in the S_PARTY_PER table.

The S_PARTY_PER table is mapped to all major interface tables, example: EIM_ACCOUNT, EIM_CONTACT, EIM_EMPLOYEE, EIM_ACCNT_CUT, etc. Thus, when inserting data using EIM and establishing relationship between 2 different PARTY objects all the fields related to S_PARTY_PER must be populated in the interface table.

Since S_PARTY_PER establishes a relationship between two distinct parties, there are 2 sets of key attributes that are required to be populated.

For example, in EIM_ACCOUNT following values are required:

PARTY_UID = <party_uid of the account>
PARTY_TYPE_CD = "Organization"
PP_PARTY_UID = <person_uid of the contact>
PP_PARTY_TYPE_CD = "Person"

However if EIM_CONTACT is used to insert new Contacts then order of these fields will be reversed because S_PARTY now refers to Contacts.

PARTY_UID = < person_uid of the contact >
PARTY_TYPE_CD = " Person"
PP_PARTY_UID = < party_uid of the account >
PP_PARTY_TYPE_CD = " Organization"

Also for EIM_EMPLOYEE table when establishing relationship between Employees and Positions following order is required.

PARTY_UID = < person_uid of the contact associated with the employee>
PARTY_TYPE_CD = " Person"
PP_PARTY_UID = < party_uid of the position>
PP_PARTY_TYPE_CD = "Position"

PARTY_UID:

PARTY_UID is defaulted through the Upgrade and Application (UI) to the ROW_ID of the party record (for example Contact, Position, etc.) that is being created. But its value can be user-defined as long as (PARTY_UID, PARTY_TYPE_CD) combination is unique. PARTY_UID need not be equal to ROW_ID. PARTY_UID is defined as a VARCHAR(100) column.

Integration Manager (EIM) reports the following low-severity error when the foreign key value in the base table does not match with value in the interface table (Note: The following example is based on Siebel version 7.0.4 data model):

EIM_ORDER
------------
BL_ACCNT_BI
BL_ACCNT_LOC
BL_ACCNT_NAME
BL_ADDR_NAME

Base table:
S_ORDER
-----------
BL_ADDR_ID (Position)
This is a foreign key value in the base table and the values in the interface table did not resolve to existing values. Verify that the IF columns correspond to existing base table rows. This failure caused the rows to be eliminated from further processing for this secondary base table. However, processing of the rows WILL continue for other destination base tables.

Resolution:

The essential concept of resolving the foreign key value is to find the user key columns in the foreign key table. Based on multiple columns, user keys are used to uniquely identify a row in a table for EIM processing. The following guideline illustrates how the user key plays a role to identify the base column for corresponding EIM columns based on the above scenario.

Identify the foreign key table, which S_ORDER.BL_ADDR_ID points to. Siebel Tools or Siebel Interface Reference guide can be used to identify the foreign key table.

Using Siebel Tools, in the Object Explorer list, go to Table object and query for S_ORDER table

Navigate to Column object and query for BL_ADDR_ID column

Verify that the foreign key table value is S_ADDR_ORG.

Find the user key columns defined in the S_ADDR_ORG table.

Using Siebel Tools, in the Object Explorer list, go to Table object and query for S_ADDR_ORG table

Navigate to User Key object and select U1 index (S_ADDR_ORG_U1)

Navigate to User Key Column object and verify that the User Key columns for S_ADDR_ORG are ADDR_NAME and OU_ID (FK)

Identify the foreign key table, which S_ADDR_ORG.OU_ID points to using Siebel Tools.
S_ORG_EXT

Find the user key columns defined in the S_ORG_EXT table using Siebel Tools: NAME, LOC, BU_ID (FK)

Identify the foreign key table, which S_ORG_EXT.BU_ID points to using Siebel Tools: S_BU

Find the user key columns defined in the S_BU table using Siebel Tools: NAME

Based on the above result, following interface columns need to be populated correctly to resolve the S_ORDER.BL_ADDR_ID foreign key.

BL_ACCNT_BU: populated with S_BU.NAME value from step 6.
BL_ACCNT_LOC: populated with S_ORG_EXT.LOC value from step 4.
BL_ACCNT_NAME: populated with S_ORG_EXT.NAME value from step 4.
BL_ADDR_NAME: populated with S_ADDR_ORG.ADDR_NAME value from step 2.

PARTY_UID requires users to populate it with a unique value. The PARTY_UID column is used by several users to store a unique legacy system identifier.
The following are benefits to this approach:

a) Allows updating information that tends to change (Name for example)
 

b) Allows greater control of the data manipulation (loading, updating, exporting etc) processes in an automated fashion.

When new records are created through the UI for party, S_PARTY the default is ROW_ID as the calculated unique identification for Party.

S_REVN table was introduced in Siebel version 7.0 which is used to store Revenue data. For example Revenue by an employee on an Opportunity, an Agreement, a Service Request, etc.

S_REVN table replaces S_OPTY_PROD and S_OPTY_POSTN table in Siebel version 6.0.

As of Siebel version 7.0, S_OPTY_PROD is obsolete and S_OPTY_POSTN is no longer used to store revenue records.

S_OPTY_POSTN, just like other similar tables (such as S_ORDER_POSTN), is used to store only the Positions (sales team) on opportunities. For example, an Opportunity may have one or more employees with varying roles working on closing the opportunity. Each employee may be affiliated with a different internal organization. Employees have differing roles on an Opportunities (Primary Sales Representative, Technical Sales Consultant, etc.,) and S_OPTY_POSTN is used to store such data.

The data in S_OPTY_PROD and the relevant data in S_OPTY_POSTN tables from Siebel version 6.0 will be systematically migrated into S_REVN during the Upgrade process . Data Migration will occur as follows:

1. Migrate all primary sales representative records from S_OPTY_POSTN to S_REVN. 

2. Migrate all non-primary sales representative records from S_OPTY_POSTN to S_REVN when the revenue is committed with amount > 0.

 3. Migrate all primary sales representative records from S_OPTY_PROD to S_REVN.