Great! Thanks for confirming!

@Eileenmcnaughton I thought the gateway was always 'matching gift' since it's a matching gift import? Is there any issue that might be cause by leaving out the transaction ID since we aren't confident that they're unique?

Thanks @Eileenmcnaughton ! Just to confirm:

@Eileenmcnaughton I am on staging in the batch data entry page, but I'm not seeing the new field when I start a new batch for entry - can you share a screenshot of what I'm looking for? Thanks!

@Eileenmcnaughton Got it! These gifts are being pulled form different portals which have their own ID system - since we can't be sure if it's unique or not should we just leave that out if the import is creating its own? I think that might be the move.

That's great! So this will apply to any errors involved with that import, correct?

Ahh ok I see! Maybe @NNichols has some thoughts on what we could do for Benevity.

Ok so the No TY reason = 'sent by portal' is a rule that is on the backend of the import? I'm not sure what that means, but it's not included in either of the data files that gets imported (matching or Engage Org).

@Eileenmcnaughton My test import did have a "Thank You Date" field which I left blank to trigger the TY in Civi. I never saw it come through or add a thank you date to the contribution record after import. Is that still the correct rule that the TY will trigger if that Thank You Date field is blank as well as the No TY reason field?

@Eileenmcnaughton Thanks it seems to be working great! I tested with a gift that would create a new Org record and one where it should have matched the existing record and they were successful.

Background on DAF imports: For the DAF the relationship link isn't through the soft credit, but through the field 'owns the donor advised fund' so it differs from the matching. The soft credit for DAF doesn't need to be linked, it records the bank institution the gift came through. 'Owns the Donor Advised Fund' is a relationship link on the contact record.

Discussion w/ @Eileenmcnaughton "if you create a soft credit that is less than 3 months old on a contact of type workplace giving or matched gift then an employer relationship is created - regardless where you do that from (the 3 months old is just precautionary" "the 3 months old is based on the contribution date - ie the idea was that if you were importing a batch of old contributions for some reason it might not be prudent to change the employer."

Since the error page expired I'm not sure which gifts are the ones that didn't import since now they all have the same error if I try re-importing the file. I did a search and can confirm we are missing about $1,046.20 from those 14 gifts in the batch. I saved the file to the server so you can access it as well: smb://10.149.10.174/Fundraising/Tech/Fr-Ops/Matching Import/Real data import files/Errors/14 errors - EFT Matching gift import - Individual 2.20.24 to 2.26.24 for import.csv

@NNichols Yes, that sounds good! Thanks Eileen!

That sounds great!

Here is the screenshot of the error

Nora has updated this in Civi, so it looks to be fixed! I was able to convert the contact to an Org. This ticket can be closed.

Thanks Eileen for checking that. I also took a look at the ones in the large file you listed and from a quick search it looks like perhaps the data is confusing a sr. with a jr. or those with a similar name? From the obituaries I saw they are sometimes listed in the surviving family. Also they have given fairly recently compared to the obit dates I found. It would be hard to verify such a large volume.

Thanks for the update @Eileenmcnaughton and creating those 3 side phabs for the other fields we want to work on a bit more.

That's right, Engage is no longer entering data into Civi so we wouldn't need this user role.

That's great, thank you!

@Eileenmcnaughton I looked into why you couldn't find the Single: Y/N field in the files and I think wires were crossed at some point and we received the slightly different field of 'CE_Selected_Individual_Marital_Status_Code.' I can update this in the doc linked above, but in Civi it will be labeled Marital Status and the options are: S /M / U (Single/Married/Unknown). Is there a way to update that in the prospect fields? @ERoden-WMF there must have been a miscommunication somewhere, but I think this is close enough to what we were looking for.

Major gifts recently changed their rules to have no threshold for auto TY's from Civi so I'm not sure this is needed anymore. Basically everyone gets an auto thank you if they have an email address. The only gifts we don't send TYs to are matching gifts which all come in on imports (matching check, matching EFT, and Benevity).

Sounds good, will do.

Thanks @Eileenmcnaughton I am happy to monitor this and we can see if this still pops up after those udpates take place. So far this hasn't come up too often, but at least now we know a bit more.

Thanks for looking into it! I can also share an example of an import file. Saved one here: smb://filesrv1/Fundraising/Tech/Fr-Ops/Overflow import/Overflow WMF stock 11124 for import.csv

@Ejegg There is no timestamp in the import file, so that makes me wonder if the 2AM time is some sort of setting in the import template itself? Not the file, but the template we built out in Civi? I don't have those issues with other gifts imported through this page so I'm curious if this is something in the mapped import.

Thanks for that insight Elliot. I'm not sure if there's anything that can be tweaked on the import side, but here is the link if that's helpful: https://civicrm.wikimedia.org/civicrm/import/contribution?reset=1&template_id=878 or it's ID 878 from this page: https://civicrm.wikimedia.org/civicrm/imports/templates

I just retried the import and it did go through, everything looks good with the gift on my end.

@Eileenmcnaughton Yes, I think they are duplicates as well! I can merge them after adding the last name back in of course and reimport, but if this donor pops up again with no last name it will likely happen again. I don't think it's something we can always catch before import so it would be great to find a way to not have it time out if that's the issue! Let me know what you think we can do.

It didn't happen with this round of imports I did this week, so I'm not sure what causes it to happen.

@Eileenmcnaughton I merged those records, but it didn't import that row. All the dupes were merged to CID 9155371. It showed an error still and took a long time to process.

Thanks for the update! Please let me know what you find.

@Eileenmcnaughton Ah ok, yes seems like there is just an issue with lag.

I just checked again and the error from import 1027 is now showing! But the others from import 1032 is not. Is it a timing issue?

Another blank table when trying to view the error results: https://civicrm.wikimedia.org/civicrm/search#/display/Import_1032/Import_1032?_status=ERROR

Here is the import summary screen as well: https://civicrm.wikimedia.org/civicrm/import/contact/summary?user_job_id=1027&reset=1

I think so, but lets check with @RLewis

@JMando Sure! We may need fr-tech's expertise since I am not as informed about the labeling of the fields. We could bring this to the next fortnightly if that works for you?

@Eileenmcnaughton Just tested it and looks good! Thank you!

Ah ok, what I did was on the contact summary page edit and remove the relationship from CID 54859575. I didn't go to the relationship tab and do anything. I didn't realize that information was still saved there if I remove it from the summary page! This makes sense now. I think we are all clear then to move forward with the check imports since the other tests worked.

@Ejegg sorry for the confusion. Yes, that's right the file has the information for that gift and the soft credit organization CID 41176688. I added the relationship back to the record after testing so we don't lose that information. That gift is part of a larger import so I removed it from Civi until will can import the file as a whole.

@Ejegg Ok so I tried the imports with a new donor and it did link them! However when I tested it by using a person who already had been linked to an employer previously, but deleted that relationship before testing the import, the relationship was not created again. That is what I had been testing after the fix. It seems like that might be a separate bug? I can share the file I used: smb://filesrv1/Fundraising/Tech/Fr-Ops/Matching Import/Real data import files/Matching check Individual test import.csv

I think we still have the issue of not seeing Realized Bequest gifts in superset though from my understanding @JMando

I'm not sure what else it could have been, I only remember editing the value and trying to save it, but it looked like it wasn't changing...Sorry everyone!

@Eileenmcnaughton on my end it didn't update anything in Civi so I didn't think anything happened! I had tried to save the value as Realized Bequest since it seemed if they matched that might solve the issue in Superset. Good to know! Do you think that had anything to do with the ticket Jason created? Or still unrelated?

Ok, thanks @Eileenmcnaughton for clarifying - @JMando I think Runjini looped you in on our conversation about viewing Realized Bequest gifts in superset. Let me know if you think this fixes it.

Removing @JAdams since they're unrelated.

@JAdams opened a separate ticket for the issue here T352574

@Ejegg No these are using the import mapping tool. They're check matching gifts processed through Engage not the Benevity gifts that use the other import you mentioned. All of our mapping import templates are here: https://civicrm.wikimedia.org/civicrm/imports/templates

@AKanji-WMF I was just notified by @JAdams that the gift source Realized Bequest is now removed from all gifts that previously had that gift source. Is there work being done related to this ticket where something might have happened? There were ~10+ gifts marked Realized Bequest.

@Eileenmcnaughton the IDs for the check import templates are 830 and 831. For the Individual check import it is creating a soft credit = workplace giving, but no relationship is created. For the Organization check import it creates soft credit = matched gift, but no relationship is created when I look at the contact.

@Eileenmcnaughton thank you! The WMF stock TY email looks good, but the Endowment one has a slight issue with the formatting. There is a line break dividing the spacing:
"Thank you for

Thanks Elliott! I have deleted all of the duplicate records as well.

@AKanji-WMF @Eileenmcnaughton This is a part of this task that was closed, which I didn't realize T349858. We needed the EFT matching import fixed as well as the matching check import. The matching check need is still outstanding as I tested it and it does not link employer/employee. I would make another task, but I do not want it to get closed out as a duplicate. Can you let me know how to proceed?

@Ejegg Ah sorry about that! If you search that CIDs last name, first name in Civi you will see a bunch of duplicates. Just a couple examples: 61640326, 61640324

@Ejegg We have been notified of a new issue - there are multiple dupes being created in Civi with recent gift dates. So the gifts are somehow still finding a way in: https://civicrm.wikimedia.org/civicrm/contact/search/advanced?_qf_Advanced_display=true&qfKey=CRMContactControllerSearch1tzbvq9tqf9c4ss8kgsgk4w8cokgskg48cwk8sk4csscok4o8g_7468

Here is the link to the import results, which for some reason aren't showing up for me: https://civicrm.wikimedia.org/civicrm/search#/display/Import_904/Import_904

@Eileenmcnaughton Thanks for taking a look at this. I found an example of one that imported the gift, but did not link the person. Since it's real data I have saved the example file here: smb://filesrv1/Fundraising/Tech/Fr-Ops/Matching Import/Real data import files/Errors/Matching Org test file EFT.csv

@Eileenmcnaughton Looks good! Just want to make sure this is updated for the Endowment version as well - the bottom portion with the PO Box address and Tax ID will have the END information.

New template:

Yes, I was just told by @RLewis. She has confirmed this update for stock but will be following up regarding other gift types.

@Eileenmcnaughton MG team is changing some of their TY rules and they have told me there is no need to add any TY suppression. They would like an auto TY to go to all who have an email listed upon import.

@Eileenmcnaughton It looks like my WMF Stock import template is good now - all mapping fields are saving as well as the rules at the top of the mapping page. I tested this one with fake data and it worked! We just have to figure out the civi auto TYL suppression rules so it doesn't send a TY for gifts $10K and up. At the moment I think it is just suppressing all until we do that.

@Eileenmcnaughton I also want to make sure the stock email template is triggered even if financial type is Endowment Gift. I think right now the stock template only triggers if financial type is Stock. Maybe we can have the template for stock be triggered by payment method? Payment method = stock is consistent across all stock gifts.

@Eileenmcnaughton I've got WMF and END stock import templates saved in Civi. There area few things I've noticed:

Adding an update that we do not need DAF imports, only stock. Overflow just initiates the gift so we will use our already existing imports to process the DAFs. This cuts down on some of the work needed!

Related work happening here for stock import

Note: the attached sample file above includes bitcoin and cash transactions which we will not be doing. Please note only the layout of the stock gifts. Once I have the sample DAF file I will share that here as well. I can get started on creating import templates, but it looks like there may need to be some coding on fr-tech's end - similar to Fidelity import.

The only two I'm not sure of are:
(TS) Capacity Range
(TS) Estimated Capacity

@Eileenmcnaughton New DA fields look good! I see the TS 401K/IRA decile is labeled, but I think we want to label the other TS fields as well. I have this list:

Hi @Eileenmcnaughton - thanks for the questions! I reviewed some of our previous notes based on past discussions and I think we had settled on the below:

@Damilare This import has gone smoothly as well - thanks!

@Damilare This seems to be fixed as well! No issues with the DAF imports.

@Damilare Engage imports are importing with no errors now - thanks!

Thanks @Damilare - I will run the Engage imports tomorrow and see how it goes! The DAF and matching will likely come later in the week and I will test them as well when they are available.

Thanks @Damilare ! I wonder why this is happening all of a sudden when we have never had issues with it before. I believe the import was originally setup knowing there will be duplicate check numbers, but if they are from different individuals they are not duplicates. Thanks for looking into a way to fix this!

@Damilare checking in to see how this is going. thanks!

Hi @Damilare, how do I find the import ID? I only see the import log:

FYI added a new file of 28 duplicates that came from this week's import file: smb://filesrv1/Fundraising/Tech/Fr-Ops/Engage import/Wiki Individual TY 092523 for import_skipped.1212.csv