
< Read the previous blog (prerequisite)
Before you start to load contact data into SAP S/4HANA Marketing/SAP Hybris Marketing, you should have set up customizing of the ID Origins as this has a wide impact on the mapping and merging logic between contacts. So, it’s really important to know what kind of data you get from the connected source systems. This blog should help you to understand what can go wrong and why – and most importantly - how to prevent undesirable behavior.
In addition to the Priority parameter, whose function I’ve described in my previous post, there are two more key parameters. Since it should be possible for several contacts to share the same facet - for example a landline phone number shared by all family members in the household - the Shareable parameter was introduced in release 1602.
Furthermore, a One Per Contact parameter was introduced, which specifies whether contacts can have more than one ID of the same origin or not. Therefore this parameter can prevent the system from merging contacts that would otherwise be merged because of matching IDs. For example, if we think of a social security number or a personal identification number (mainly for taxation purposes), it is clear that every person can have only one ID of these origins.
In the worst case, the system creates…
if the One Per Contact parameter for an ID Origin of a source is set to true and the data coming from this source contains real duplicates.
Let’s assume there is a customer who has two accounts in a web shop and has given the same mobile number for both. If we import this data into S/4HANA Marketing/SAP Hybris Marketing using standard customizing (Web Shop - One Per Contact = true; Mobile - non-Shareable), the mobile facets would match, but the configuration of the ID Origin Web Shop would not allow a merge. So, the ID Origin Web Shop is treated similarly to a social security number and the system regards both of these imported records as two distinctly different contacts.
Two source records with the same mobile facet – whose ID Origin is defined as non-Shareable - are imported from the two connected source systems, web shop and ERP.
The source records match via the mobile facet and are merged to one resulting contact record which gets the two main facets of the ID Origin Web Shop and ERP with the corresponding mobile facet.
Two source records, corresponding to two accounts from a web shop, with the same mobile facet are imported.
The source records match via the mobile facet - whose ID Origin is defined as non-Shareable – but, the One Per Contact = true configuration of the ID Origin Web Shop prevents the system from merging them. The resulting contact records don’t have the mobile number any more, instead an additional container record is created with that mobile number and a corresponding facet.
Two source records, corresponding to two accounts from a web shop, with the same mobile facet are imported.
The source records match via the mobile facet - whose ID Origin is defined as non-Shareable – but, the One Per Contact = true configuration of the ID Origin Web Shop prevents the system from merging them. The resulting contact records still keep the mobile number. On another contact import which includes this mobile number, the corresponding mobile facet is considered as a Shareable facet although its ID Origin is still configured as non-Shareable.
Two source records with the same email facet – whose ID Origin is defined as Shareable - are imported from the two connected source systems ERP and CRM.
The source records match via the email facet but the second matching criterion (based on full name) is not fulfilled. Each of the resulting contacts has this email facet due to its Shareable setting.
The behavior described here is valid for the default logic without the implementation of further Business-Add-Ins (BAdIs). Via the implementation of the map/merge BAdI method (IMP_IA_IC_MERGE_BY_FACET) you can merge contacts even if customizing settings would be violated and you can also prevent the merging of contacts, which the system would normally merge (due to matching criteria).
I hope this post provided you an understanding of the ID Origin customizing in order to set up the ID Origins appropriate to your scenario with regard to the data coming from the connected source systems.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |