Added estimated points (4) from today's standup but there was a call for more detail as to what is requested.

If possible, could you expand the description of the task to give more information on what is needed?

@NNichols can you add more info to the description? Thanks!

We will also need to create a new benevity import for the Endowment as well. The total number of gift coming through that are much smaller but it could grow in the future

Leaving this task in the queue for "next" right now; several other imports are currently higher in priority.

Based on https://docs.google.com/document/d/1K5gkJLdbz94QOpBMgVrmSyJrCUZYPQrbdVhuO38GDqc/edit#heading=h.imcqenob3nky we are pushing this to Q3

Change #1138141 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Switch contact creates to apiv4 in Benevity Test

https://gerrit.wikimedia.org/r/1138141

Change #1138477 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] port date patch

https://gerrit.wikimedia.org/r/1138477

The current Benevity files have not been imported yet. You can see them here:

Fundraising/Development/Benevity/FY24-25/April 2025

Change #1138141 merged by Eileen:

[wikimedia/fundraising/crm@master] Switch contact creates to apiv4 in Benevity Test

https://gerrit.wikimedia.org/r/1138141

Change #1139203 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Convert getUserJob and getGatway to be non-static

https://gerrit.wikimedia.org/r/1139203

Change #1139204 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Make SetTimeOfDayIfStockDonation non-static

https://gerrit.wikimedia.org/r/1139204

Change #1139206 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Benevity import feature 1 - filter not-shared-info

https://gerrit.wikimedia.org/r/1139206

Change #1139208 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Benevity feature 2 - field transformations on Gift Sourc

https://gerrit.wikimedia.org/r/1139208

Change #1138477 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] port date patch

https://gerrit.wikimedia.org/r/1138477

Change #1139586 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Extract & remove ensureTrxnIdentifiersSet

https://gerrit.wikimedia.org/r/1139586

Change #1139587 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Wait until end to transfer contact_id to the contribution

https://gerrit.wikimedia.org/r/1139587

Change #1139203 merged by Eileen:

[wikimedia/fundraising/crm@master] Convert getUserJob and getGatway to be non-static

https://gerrit.wikimedia.org/r/1139203

Change #1139204 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Make SetTimeOfDayIfStockDonation non-static

https://gerrit.wikimedia.org/r/1139204

Change #1139206 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Benevity import feature 1 - filter not-shared-info

https://gerrit.wikimedia.org/r/1139206

Change #1139208 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Benevity feature 2 - field transformations on Gift Sourc

https://gerrit.wikimedia.org/r/1139208

Change #1139586 merged by Eileen:

[wikimedia/fundraising/crm@master] Extract & remove ensureTrxnIdentifiersSet

https://gerrit.wikimedia.org/r/1139586

Change #1139587 merged by Eileen:

[wikimedia/fundraising/crm@master] Wait until end to transfer contact_id to the contribution

https://gerrit.wikimedia.org/r/1139587

@MDemosWMF The benevity import is now on prod based on the legacy import - maybe you could throw a one-row file at it & see what comes up

@Eileenmcnaughton I just ran a test import #2455 using your template and I think it's looking good! I made some updates to add additional data fields as well. Overall it seems really close, but I think there is one thing that may be off:

• You can see on contribution ID 123723896 the soft credit type is 'matched gift,' but I think it should be 'workplace giving' since this is the record for the employee's donation. It's showing that the donor made this gift through x company where as when the company is making the matching contribution the soft credit to the individual is 'matched gift.' Maybe there is a way to set it up so that when gift type in the benevity import is = Individual Gift or Payroll Deduction the soft credit type is set to 'workplace giving' and when gift type = Matching gift the soft credit type = 'matched gift?'

*Also when I went to test the import file some of the mapping looked slightly off so I did my best to correct, but hopefully didn't throw anything off that I'm not catching!

@Elbar53 Can you also look at the import results linked above and let me know if you see anything that isn't right?

I haven't tested an international currency benevity import yet, but will do that next week! Will I be able to use the same import template or do you think we need a separate one? @Eileenmcnaughton

Hi Melanie - I think you can just update the soft credit type - or are you saying we need to update it on the fly - I guess the latter huh?

The same import should work for other currencies - it's just a mapping

@Eileenmcnaughton I think since all of the different types are mixed together in the files we would want to look for a way for it to detect which SC to use in each situation if possible.

Good to know about other currencies, I will test that out this week!

Change #1141993 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Benevity use workplace soft credit type for org gifts

https://gerrit.wikimedia.org/r/1141993

Change #1141993 merged by Eileen:

[wikimedia/fundraising/crm@master] Benevity use workplace soft credit type for org gifts

https://gerrit.wikimedia.org/r/1141993

Ok @MDemosWMF I pushed in a fix for the soft credit type handling

@Eileenmcnaughton Did another test for the soft credit fix, but it looks like it might be off. Some examples:

Contact ID 123972543 should be SC type = matching, but is workplace giving
Contact ID 123972545 should be SC type = workplace giving, but is matched gift

Looks like it's doing the opposite, so maybe the fix you did just has to be flipped?

Test import 2480

Change #1143977 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm@master] Reverse workplace/match_gift types in Benevity import

https://gerrit.wikimedia.org/r/1143977

I've just pushed up a patch to flip them - am hoping I can get it reviewed & deployed before you get together to test the import

Change #1143977 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Reverse workplace/match_gift types in Benevity import

https://gerrit.wikimedia.org/r/1143977

I looked over the test import. It looks good. The "workplace giving" and "matched Gift" in the soft credit field are flipped. The matched gift should be on the company donation, and workplace giving should be on the individual.

Thanks @Elbar53! Yep, Eileen just pushed out a fix for that so as long as everything else looks good we can do our test import with the real files today.

@Eileenmcnaughton Ellen and I just ran another test but found that all of the soft credit types came through as 'matched gift' which for some of the gifts it should be 'workplace giving' - so it seems like the new patch didn't work or might have caused a new error. We also noticed that for line 1 and 2 (contribution IDs 124240620 / 124240621) the gift type was 'employee giving' but based on our coding rules these should be 'individual gift' like line line 7 / contribution ID 124240628. From what I can see in the docs Nora left the three gift type options for matching gifts are: Individual Gift/Payroll Deduction/Matching Gift

Here is the import: https://civicrm.wikimedia.org/civicrm/search#/display/Import_2504/Import_2504

Actually I was able to find this in other documentation - "Employee giving = Employees are giving a predetermined amount of money by their employer to designate to their chosen charity. A good example of this is the Google Gives Program. Google employees receive $400 from Google in the fall to donate. The money used in these programs is earmarked for this by the employer and is not considered a personal donation or generally matched."

Do you know how we are differentiating between companies like this in the benevity file? This may be specific to Benevity from what I can tell by searching in Civi for gift type = employee giving. Unsure how this was set up originally.

@MDemosWMF I realise that the 'normal' soft credit type is configured in the UI and I only updated the soft credit type that is assigned by code - so you can probably update the type in the mapping screen to work place giving.

I'm just trying to see what the other issue is

@MDemosWMF - if you check the import source for those records they are "My Rewards" - we have this coded list from Nora of what the values in that field map to (it applies to all imports but in practice only Benevity has these values). It is the same list that has been applied via the legacy Benevity imports

{
  "Gift_Data.Campaign": {
    "BlueSnap": "Individual Gift",
    "Payroll": "Payroll Deduction",
    "Donation": "Matching Gift",
    "My Rewards": "Employee Giving",
    "BlueSnap (Apple Pay)": "Individual Gift",
    "Volunteer": "Volunteer Match",
    "Corporate Direct Donation": "Corporate Gift",
    "Company Gift Card Anonymous Donation" : "Employee Giving",
    "PAC Match": "Matching Gift",
    "": "Individual Gift"
  }
}

@Eileenmcnaughton That list for the coding is very helpful! We can keep that logic is since I'm not sure if this was supposed to be changed or stay the same.

For the soft credit type issue, I believe if I change it in the mapping it will apply that SC type to all of the gifts which we don't want since they are mixed together. Maybe there is a way to set it up so that when gift type in the benevity import is = Individual Gift, Payroll Deduction, Employee Giving, Corporate Gift the soft credit type is set to 'workplace giving' and when gift type = Matching Gift, Volunteer Match the soft credit type = 'matched gift?' Could this be detected to automatically happen during the import?

We want to avoid having to do any manual divvying up of the import into separate files. Thanks!

@MDemosWMF I think part of the flip between which was workplace giving & which is matched includes flipping the default - the overrides are fixed in code but the default is in the UI

@Eileenmcnaughton Ah ok, so I should test with the default soft credit type for the mapping template set to 'Workplace giving' instead of 'Matched Gift'?

@MDemosWMF yep!

@Eileenmcnaughton Ok great, will do that tomorrow and let you know how it goes!

@Eileenmcnaughton Looks like the mapping for the Benevity import is wiped. This one is a little more complex and I don't want to mess with anything so if you are able to re-map it before I do the test that would be great!

I have done some work on figuring out why the mappings got messed up on upgrade & fixing them - I have a script (submitted upstream at https://github.com/civicrm/civicrm-core/pull/32909 ) - which I have run on staging & which seems to be working on Staging - ( I think you made some updates on prod that are not on staging so it's not quite the same) - if you have a chance to check it would be great

@Eileenmcnaughton Do you mean checking all of the imports on staging or just certain ones? I hadn't added any updates to Benevity since you created it so I think we should be good there. I just have to update the SC to 'workplace giving' and run the tests on production.

Well they should all be fixed on Staging now...

@Eileenmcnaughton Ok I can try and click through all of our import templates and check them. If I find a discrepancy do you want me to update the template on staging? Or will that not transfer over to production so no point?

Just let me know - you don't have to check everything - just spot check - since I will run the same script on prod rather than copy them over

@MDemosWMF I ran the update on live - so cross fingers things are looking good now....

@Eileenmcnaughton Thanks! I will do some spot checking on prod and report back.

I made that change to the benevity import template, ran a test, and it looks like it is now allocating the right soft credit type! Template has been updated for future use. @Elbar53 you can go ahead and run the outstanding Benevity imports - maybe start with just a few lines and review to be safe, then import the rest.

@Eileenmcnaughton We got back quite a few errors on possible matching contacts when we ran the most recent files: https://civicrm.wikimedia.org/civicrm/search#/display/Import_2666/Import_2666?_status=ERROR

We ran into this in the past with other imports - do you know how we can avoid these front-end errors? Similar to ticket T374063, but I can't remember where we landed on a fix.

@MDemosWMF I think the process of manually cleaning up the dupes (e.g ) https://civicrm.wikimedia.org/civicrm/contact/merge?reset=1&cid=20553879&oid=29153702 has been maintained up until now for the Benevity import - on the basis they mostly DO need cleaning up & the volume has been not been too high

@Eileenmcnaughton I agree these do need cleanup, but could we funnel these into some sort of dedupe group which I think is what we did for Engage imports (I see that in this old ticket T374063) ? I don't think our team has the capacity to go through that many dedupes manually.