odd Opportunity behavior with Contact Roles

[CarolinaTigerRescue]

We received a donation from (for example's sake) Jane Doe 2 through Click&Pledge. We have 3 Jane Doe's in our system. Jane Doe 2 did have a correct matching email address. Click&Pledge automatically created the Opportunity, and put the additional C&P related records for Jane Doe 2, but the Opportunity was assigned to Jane Doe 1's account and Jane Doe 1 was assigned as primary donor. Jane Doe 2 was also assigned the role of Donor, but was not checked as Primary.

I am sharing this here because it was a Click&Pledge transaction. I did have a similar behavior happen once before, prior to our C&P installation. On this occasion, it was a Membership I had imported. The Contact ID I had provided in the import file was correct , but two donors with the same name ended up with Contact Roles, and the wrong donor was set to primary, so I suspect it may be a problem with NPSP. I have posted the incident to the NPSP group, but was hoping maybe C&P has encountered this before.

Has anyone seen this before?

(if I get a solution from NPSP, I will copy here)

[CnP.Support]

Good day!

We have not seen this behavior before since we do contact matching based on the fields you select to be matched.

I will ask our test team to review this and will get back to you shortly.

[CnP.Support]

Good day!

We have researched this and we feel there is no way we can have anything to do with this behavior. Here is why:

- With NPSP we ask that you set the C&P Settings so it does not create a NEW account for NEW contacts. Knowing this we absolutely have nothing to do with Accounts.
- When a new opportunity is created we associate it with the CONTACT that we identify per C&P Settings.
- Account ID is read from the Contact and will be associated with the OPPORTUNITY

If the Account ID is not correctly associated with the right Contact then naturally what we associate with OPPORTUNITY will be incorrect.

Hope that makes sense. I am interested in learning what you find out. Based on our analysis C&P cannot possibly cause this but there is always a chance that we are overlooking something and missing an undocumented "feature".