Siebel LIC LOV Value Is Not Being Passed To EDQ In An MLOV (Multilingual LOV) Enabled Environment (Doc ID 1928369.1)

Last updated on FEBRUARY 22, 2016

Applies to:

Siebel Universal Customer Master - Version 8.1.1.11.7 [IP2013] and later
Siebel CRM - Version 8.1.1.11 [IP2013] and later
Information in this document applies to any platform.
*** Checked for currency on 22-FEB-2016 ***

Symptoms

SIEBEL VERSION:
---------------
Siebel 8.1.1.11

ISSUE STATEMENT:
----------------
Customer is using Siebel 8.1.1.11 with EDQ for Siebel DQ integration. Customer is also using Siebel in 2 different language versions for the client UI AOM: ENU and FRA.

Customer has changed the EDQ Account BC Field Mappings to have only these (they want to send the Account Type field to EDQ eid1):

BC Field Mapped               Field

Id                                    entityid
Main Phone Number          phone
Name name
Type                                eid1

Customer is testing specifically with Account [Type] field, which is mapped:

BC: Account
BC Field: Type
Table: S_ORG_EXT
Column: OU_TYPE_CD

LOV Type: ACCOUNT_TYPE
LIC: Company
Display Value: Company
Language: ENU

LOV Type: ACCOUNT_TYPE
LIC: Company
Display Value: Société
Language: FRA

Customer enabled this LOV for MLOV (by setting table/column S_ORG_EXT.OU_TYPE_CD Translation Table Name property to 'S_LST_OF_VAL', compile changes into the srf file), it is working correctly for the Siebel ENU and FRA UI:

- When logging into ENU UI > Account Type shows the ENU display value: Company

- When logging into FRA UI > Account Type shows the FRA display value: Société

At the underlying table column for the record, the column is storing the LIC value as follows:

select ROW_ID, NAME, OU_TYPE_CD from S_ORG_EXT where ROW_ID = '1-TX4';

ROW_ID NAME OU_TYPE_CD

1-TX4 CISCO Company

However, when the record is sent to EDQ, the Display Value is always sent over to EDQ for edq1 field instead of the LIC value.

Customer requirement is to use the Siebel Account BC [Type] field to allow same account names with different type values.

- Account Name 'Account1' with Type = 'Business' is one unique account

- Account Name 'Account1' with Type = 'Customer' is one unique account

This can be done in Siebel using user key set up, etc.

However, the two are not duplicates and are not (should not be) considered as duplicates in EDQ because of the way customer did the mapping of Account Type field to the eid1 field, to use the Account Type (eid1) as an exclusion, such that EDQ side should not trigger a match to avoid a user potentially selecting a match to merge the record into it.


WHERE IT HAPPENED:
-------------------------------
The issue happens in customer's test environment.

STEPS TO REPRODUCE:
-------------------------------
The behaviour occurs as follows:

1. Enable the Account Type field for MLOV (by setting table/column S_ORG_EXT.OU_TYPE_CD Translation Table Name property to 'S_LST_OF_VAL', compile changes into the srf file)

2. When logging into ENU UI > Account Type shows the ENU display value: Company

3. When logging into FRA UI > Account Type shows the FRA display value: Société

4. At the underlying table column for the record, the column is storing the LIC value as follows:

select ROW_ID, NAME, OU_TYPE_CD from S_ORG_EXT where ROW_ID = '1-TX4';

ROW_ID NAME OU_TYPE_CD

1-TX4 CISCO Company

5. Use the FRA client UI to update the account phone number, this triggers a call to DQ which Siebel passes a message with the eid1 field, the message sent by Siebel passes the eid1 field with Display Value instead of LIC value as follows:

FINE: 03-Sep-2014 13:59:18: new WS conduit with URL http://ucelsvp1401.us.oracle.com:9002/dndirector/webservices/EDQ-CDS:EntityCluster
FINEST: 03-Sep-2014 13:59:18: get dedup keys in=#000-000-0000 name=CISCO eid1=Société>
FINEST: 03-Sep-2014 13:59:18: POSTing
  
LOSS OF FUNCTIONALITY / BUSINESS IMPACT:
------------------------------
Due to the incorrect value being passed from Siebel EDQ, EDQ is not able to find the duplicate record for matching.

ERROR MESSAGE:
-------------------
There are no error messages that occurs with this issue, just the unexpected/undesired results being observed.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms