Contribution Import Utility error

The import utilities are so finicky. Does your last field in the XML files have the /r/n operator at the end?

Hi Ann,

Yes these are finicky and the errors don't always help to pinpoint the problem.  I do have the /r/n at the end.  We don't run it often, but it's worked in the past for us.  Feel like I'm grasping at straws trying to figure out why it's not working now.

Thanks.

T.C.

When the bulk import tool returns errors I do the following:

1. Make a copy of the file and alter the copy so that only one row of data and headers is in the file.
2. Run the import using this pared-down copy.
3. If it imports successfully, then the issue lies in the data. You can eyeball the data and see if there are any glaring issues, but if you don't see any, try adding half of the data back into the pared-down copy and then try the import again. If it fails, then the data is in that section (at least), so you can keep stripping down the file contents in half until you find the offending row(s).
4. If Step 2 did not import successfully, then the problem is most likely with your XML file. Using the same idea as Step 3, look over your header and XML contents for glaring issues. If none are found, create a new XML file with only the one half of the columns you want to import and alter your data file correspondingly. Try importing this. If it fails, then the problem is with the columns in this section of the XML, and you can keep repeating the process until you find the offending column(s). If the import is successful, then try with the other half of the columns until you find the culprit.

I like to use NotePad++ when altering these files.

Good luck!

Hi Katie,

Thanks for the suggestions.  I already cut the xml file to look at just 3 columns (the minimum it could be) and the data file had 3 rows for testing, but I made it only 1 row.  It continues to fail.  We didn't change anything from a year ago when it worked fine.  Thought maybe something had changed with a version update that affected the import and I missed--we are currently on V 15.2.39--forgot to add that before.

The data set is basically the same as last year, with a different contribution date, the current campaign, and since i have been playing around with the xml file, i updated that to look at the one I'm testing with.

Thanks again.

T.C.

Just trying to think of anything that might be the culprit -- are the dates in the correct format? Do they match what you had last year?

Hi there,

We'e having a very similar issue in that we are trying to import Giving Tuesday contributions using a format that has worked before. TN Support did suggest that it could be down to a known defect where the utility fails if the state is blank despite blank states being allowable in TR_COUNTRY. I tried adding that in as a column but it didn't help. I could only get it to work if I put a customer number in the data file, but not all of them had a record, and of course it should be able to match up to the existing record and import anyway. I have a call with them for next week so will let you know if I have a breakthrough, but hopefully you will have sorted it out before that!

I sympathise!

All best, Katie

Ugh, sorry, TC! That sounds so odd! I'd be happy to glance over it if you want to send it to me, but I'm sure a TN ticket would get to the bottom of this.

Hi Anne,

I have reduced it down to 3 fields (customer_no, cont_amt, recd_amt), and the only think I update in the import set was the campaign and contribution date all the same as previous year.

I guess it's time to open a ticket.

Thanks.

T.C.

Yes, I'm at that point of opening a ticket.  

Thanks.

Hi Katie,

Thanks for responding.  Keep me posted.  It sounds like you can get it to work with a customer number.  (All of the ones I am trying to import have a customer number.)  

Best,

T.C.