CiviCRM Community Forums (archive)

I just recently upgraded to Civi 1.8.  What happened to the ability to export Contribution fields?  1.6 had the ability to select Contribution record type from the "-select record type-" dropdown on the export field mapping interface, along with the ability to select all the individual Contribution fields, like Amount, etc.  It is not there now.   Did that ability get moved somewhere else?  Any information would be much appreciated.

Thanks,
Mike

Donald,

Thanks for the reply.  In the meantime I came across this: http://issues.civicrm.org/jira/browse/CRM-1788.  Unfortunately, the ability to select a combination of Contact and Contribution fields for customized export mappings was a main feature used by my client.  The new Contribution Export (which I've now tested) is okay, but not great.  You have no ability to select which fields you want to export.  Additionally, it combines Contact names into single fields (Sort Name and Display Name), as opposed to breaking out Prefix, First, Last, and Suffix into separate fields.  Also, the Contribution export doesn't work for custom contact data fields.  Do you know if there are any plans to improve the Contribution export to be more robust like the Contact export feature?

Thanks,
Mike

I just want to say that this is very important since you want to be able to export the contributions to run a mail merge for printed thank you notes.

Thanks for everyone’s comments on this subject!

Just to clarify, here are my specific problems with the current Contribution export:

• Our contact profile includes Prefix, First Name, Last Name, and Suffix.  The contribution export only prints out the Sort Name (combined First Name and Last Name) and Display Name (combined Prefix, First Name, Last Name, and Suffix).  The problem is my client is trying to export the contribution records and import them into a legacy donation accounting system which requires the fields to all be in separate columns.
• Our custom profile also includes a custom field called Donation Name Recognition.  It would be great if the export would automatically pick up any custom fields that had been added to the contact profile.  The other standard contact fields, including address, email, phone, are fine.  NOTE: I’m considering moving this custom field from the contact profile to the contribution, so that is one way to fix my issue, since the contribution custom fields are included in the export (with the exception of the next problem).
• Our contributions have some custom fields also.  Most are exported just fine, except for one of them is a State.  The export only exports the ID of the state, rather than a lookup on the state abbreviation like the contact address state field does.

So as you can see, the export is very close, but not close enough for my client to use it the way they need it.  I suppose there are couple of possible outcomes here:

• Modify the export code myself to get this extra data exported, and submit back to the project if the team felt it was needed
• Write a BIRT report that extracts the data exactly as the client needs it.  We actually looked into this after Donald’s post, but we can’t find the BIRT .rptdesign files that are supposedly included in the 1.8 release.  Am I missing something?
• Wait for a future release of Civi to make the contribution export more robust to allow users to create field mappings (for all record types!) like the Contact export– This is perhaps the best long term solution.

Dave, I’m happy to proceed in any of these directions, but am curious what your thoughts are.

Thanks very much,
Mike
Phase2 Technology

• Modify the export code myself to get this extra data exported, and submit back to the project if the team felt it was needed

This might be a bit more complex depending on the number of custom fields you want etc. Adding the name components is a relatively trivial hack. (CRM/Contribute/Form/Task/Export.php)

• Write a BIRT report that extracts the data exactly as the client needs it.  We actually looked into this after Donald’s post, but we can’t find the BIRT .rptdesign files that are supposedly included in the 1.8 release.  Am I missing something?

I just checked the distribution and seems like we forgot to package it as part of the 1.8 distro. We'll have this fixed in the next 1.8 release. In the meantime, you can retrieve it from:  http://svn.civicrm.org/branches/v1.8/Reports/

I would vote for it to be done this way, primarily since this is so much more flexible and powerful in the long term.

• Wait for a future release of Civi to make the contribution export more robust to allow users to create field mappings (for all record types!) like the Contact export– This is perhaps the best long term solution.

I think this is my least favorite option We really would like people to start "scratching their own itch" rather than waiting for a solution. You could potentially do this as part of point 1 above, rather than hacking the code, make the export more robust and full featured

lobo

Dave, I also wanted to add that I haven't yet found a Joomla! + Civicrm + tomcat host that is close to affordable. Actually, I haven't found one period. I think it is pretty unlikely that most small non profits will be able to use it. Even joomla.org, which is a huge site on a high end host is not going to have tomcat. Everyone I have asked has said no. 

You need to use your powers of persuasion. 

But seriously, for me as I try to get staff to be in charge of our site I would really like a host that I feel confident would know what they are doing with Joomla! specifically and civicrm if possible because I will not always be there to do upgrades for them.

Plus CSOD--you need Joomla! as an option!!

Off topic, my company, Phase2 Technology (http://www.phase2technology.com), has built a payment processor (using http://www.payjunction.com) for CiviCRM and we'd like to contribute it back to the project.  I've been looking around for info on that, but I haven't found anything concrete.  How should I proceed?  Should I just send you guys the files?  Or can I check them into the dev baseline?  You can respond to me at mmorris at phase2technology dot com.

Mike - That's exciting news regarding Payjunction. Hopefully the code is written for 1.8 - since the payment processor "architecture" changed quite a bit from 1.7.

Regarding code contributions ... your query prompted us to post a draft set of "guidelines/steps"  on the wiki. Take a look and get back to us with questions or comments.

http://wiki.civicrm.org/confluence/display/CRMDOC/Code+Contribution+Guidelines