SBL-EAI-04375 - EAI upsert error

Past week I came across an annoying error, lets supose that I have an integration object that generates a schema like this:

   <name>Account Name</name>
   <competitorlist>
      <competitor>
         <name>Name 1</name>
         <type>TYPE</type>
      </competitor>
   </competitorlist>

When I used EAI to upsert this values, it works fine in first execution, but fails in next executions (with same data)
with this error :

"Method 'WriteRecord' of business component 'BC' (integration component 'BC') for record with search specification '[Name]="TYPE" AND [Type]="Name 1"' returned the following error:"The same values for 'Name, Type' already exist.
If you would like to enter a new record, please ensure that the field values are unique.(SBL-DAT-00382)"(SBL-EAI-04375)
--
Error invoking service 'EAI Siebel Adapter',

So, let me explain all scenario for a better explanation:

• Table that supports competitor list have a key for name and type for each account
• BC that supports this IO have a MVG declaration with Type Field = Type and Type Value = TYPE
• By mistake values in CompetitorList came switched...
  

   <name>Account Name</name>
   <competitorlist>
      <competitor>
         <name>TYPE</name>
         <type>Name 1</type>
      </competitor>
   </competitorlist>

So what's really happening? Why first execution works fine (even with switched values)? After strugling with it for a day
I found the answer in siebel sql trace, When EAI process is trying to decide if is an update or an insert in Competitors table, is used MVG restriction to perform the
query, so, because values are switched EAI is looking for a register with type = TYPE, which wasn't found because we are inserting a record with type= Name 1, then when EAI
didn't found any record it will try to insert a new one with values that already exists in db causing this error to happen.

This is a pretty strange situation, that causes a pretty confuse explanation.
So, bottom line is : If any similiar situation happens to you, look in siebel logs for the query that is causing it.