topic IS CIM appending characters to my customerID in Customer Profiles to avoid duplicate error? in Integration and Testing

IS CIM appending characters to my customerID in Customer Profiles to avoid duplicate error?

jbschwartz — Mon, 05 Aug 2013 16:51:50 GMT

Hello,

I am trying to understand how our CIM database on Auth.net has ended up with duplicate Profiles where the CustomerID has the likeness of a legitimate ID that we have provided, but has appended characters to the end of the ID string.

For example, if we have supplied the unique ID of 12345 for Customer ID (aka Customer Merchant ID), I see the following listings in the CIM when CustomerID = 12345 is searched:

12345

12345a

12345b

12345c

...

12345aa

I have noticed this situation when searching for the ID I used during development and testing. Regardless, I have noticed how these additional records were generated versus being rejected when duplicates requests were probably generated. I have no mechanism that would append characters like this. I have to assume that CIM is doing it....but why? I t should have returned a Code 000039 error instead of (apparently) chagning the ID to avoid the error.

For reference, we are only supplying this one field (of three) during the Customer Profile creation request.

Can someone shed some light on this?

Thanks

Jonathan

Re: IS CIM appending characters to my customerID in Customer Profiles to avoid duplicate error?

RaynorC1emen7 — Mon, 05 Aug 2013 17:58:17 GMT

I tried it on the test site and it didn't do that. Are you100% sure, it is not appending in your code?

Re: IS CIM appending characters to my customerID in Customer Profiles to avoid duplicate error?

jbschwartz — Mon, 05 Aug 2013 18:32:52 GMT

Thanks for the reply.

Here's some additional information which might provide a clue...

The 30 or so affected Customer Profile records have Token numbers in the range 1689XXXX. We are now in the 7XXXXXXX range. I could not find a timetamp on these records within CIM, but it had to be a long, long, long time ago.

I'm going to declare "false alarm" on this one and thank you for helping me clear the cobwebs from my memory. It is very well possible that I might have purposefully generated this set of records for some reason, perhaps for a throughput experiment.

This is the best answer possible. ;-)

Jonathan