Published
Saturday, December 6, 2014 - 05:10
Written by

I recently had a requirement to allow for export of Accounting Batches to a format that AccountEdge can use. The good news was AccountEdge has many CSV import wizards for many different types of data. The bad news was the layout of the accounting batch export CSV file from CiviCRM did not match what AccountEdge expected.  So I set about creating a new export format for CiviCRM which is compatible with the "File ... Import Data ... General Journal Entries" wizard in AccountEdge.

What I had to do:

Step 1:  Update list of export options to include the new choice "CSV for AccountEdge"

1a) I edited the file: civicrm/CRM/Financial/Form/Export.php
 option choices need to be updated in 2 places: in "buildQuickForm" and "preprocess" functions
1b) I edited the file: civicrm/templates/CRM/Financial/Form/Search.tpl
  option choices need to be updated in function "editRecords"
 
 
Step 2:  Modify class load stuff for new option
 I edited the file civicrm/CRM/Batch/BAO/Batch.php 
 where I updated the function  "exportFinancialBatch"  to handle new export format
 
 
Step 3:  Add new class to implement new export format
Class must exist in the folder "civicrm/CRM/Financial/BAO/ExportFormat"  
I copied the CSV export file as a starting point. 
 
---------------------------------------

During development, I had to export the same batch several times to verify my code was working the way I wanted.  Normally in a production environment, its impossible to re-export the same batch again.  So what I did to re-export:

1) Using the CiviCRM back office, I deleted the activity "exported accounting batch" that was associated with my batch

2) Using SQL, I changed the batch status back to "closed"   my SQL:  " Update civicrm_batch  set  batch_status_id = 2  where id = xxx " 

Some thoughts on how this could be improved:

My first (failed) attempt to do this was to create a new CiviCRM extension using civix, since I figured other people are using AccountEdge and may want this new export format.   However, I discovered that an extension will not work for this situation, and I had to change core files. (I tried overriding the core files in my extension, but then the classloading failed for the core export formats)

Some steps that could improve this:

1) The options for "export formats" should be stored in the database.  This should include the mapping to which class implements each option. (Like what is already in place for custom report templates)  Ideally, one choice could be set as default, or other choices disabled (If an organization is using AccountEdge, its confusing to the bookkeeper to be defaulted to IIF when exporting batches) 

2) Allow the implementation classes to be packaged in an extension. Ideally this would mean a new "mgd" file that allows the extension author to declare the new export option and label, and not have to manually update the database where the options are stored. (ie like what is already possible in Extensions for report templates) 

-Sarah Gladstone 

sarah@pogstone.com

Comments

Thanks for this.

We need to include names in the exported file so this saves me a lot of digging.

Great ideas