This is a known bug in the group and merge processor. Internally it is concatenating all of the merge fields together to form a key. In some case this may cause an incorrect grouping, for example:
which both concatenate to
so would be grouped together.
The workaround is concatenate these attributes with a delimiter character prior to the group and merge processor to create a new key attribute and use this for grouping, or add the delimiter as a new string attribute and include this in the group and merge fields. Either way, the grouping keys from the example above would be [where ^ is the delimiter]:
so would not be grouped together.
I've mailed you the dxi. I've also observed that
Customer 1 with Store No: 42 & Cust No: 65154 is identified as a match with customer 2 with Store No: 426 & Cust No: 5154.
Can this kind of scenarios be handled effectively? These fields are strings here, but how about other datatypes? Is there any data type conversion happening at runtime?