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.
Step 1: Update list of export options to include the new choice "CSV for AccountEdge"
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 "
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)