SEPA stands for “Single Euro Payment Area”: Mix in a little bit of Standardisation, a pinch of Europe and a truck load of Bank processes; add a bit of XML, stir for decades and don't forget to pour in copious amounts of meetings full of white middle aged men all wearing grey suits. What you get is a scrumptious recipe guaranteed to insure that almost no one in the NGO community is going to be remotely involved or interested.

Until now that is. Because SEPA might be the solution you are looking for:

• allows your members to automatically pay their fees on time

• get more donors contributing small monthly amounts

• makes it easy to let donors give an extra contribution when they like

• makes it easier to raise money from supporters in other European countries (more than 30 countries use it)

All the while you are paying much lower fees to the credit card providers and spending less of your precious admin time on dealing with payments.

With SEPA, it's so cheap to set up a direct debit that you can afford to do it even for an amount as low as a few euros per month.

Four providers in Germany, France and Belgium have teamed up to integrate SEPA into CiviCRM and we have already found enough users to cover the cost of most of the development.

Project60, as our group is called, is working on:

• Creating a new SEPA Payment Processor (allowing both single and recurring contributions)

• Generating the SEPA mandate (the document that your supporter needs to sign to authorise the direct debit)

• Storing all the needed information (IBAN, BIC...)

• Generating the needed files in the proper format to transmit to the bank to process the debits.

In short, all you need to benefit from cheap direct debit.

Detlev Sieber from digitalcourage told me than more than 80% of all member fees and donations come through the existing EVL Direct Debit System in Germany. This system is extremely easy to handle and associated with very low fees - for non-profits, most german banks even process the regular transactions free of any charge. By February 2014, the current system will be replaced by SEPA Direct Debit. This will extend the advantages of Direct Debit all over Europe, but forces many german organisations to upgrade their fundraising systems... or would give them the opportunity to switch to CiviCRM.

German users have a deadline to migrate to SEPA but banks all around Europe are ready to use it today. If you are a CiviCRM user, you should consider contributing financially to the make it happen to fund its integration with CiviCRM.

In order to get their CiviCRM implementations ready for this change, the association "Software für Engagierte", which was founded by 7 German NGO's, takes part in the implementation of the CiviCRM extensions for SEPA DD and banking import. Their president, Ronald Pabst from Democracy International “If enough additional funding comes in, we want to create a solution which not only fits for our special requirements, but can be published as an extension usable for any CiviCRM user“

We have started to work on it already, we will have a first version ready before the summer and if enough of you contribute, a fully fledged extension and a handbook to make it easier for you to set up all the complete SEPA Direct Process with your bank and civicrm will be available on Q4.

Sebastian Baijard explained "At wikimedia France, we contributed to fund SEPA integration with civicrm to be able to offer our supporters an option to contribute monthly. Beside a more sustainable and predictable income, the processing costs are going to be vastly reduced. If you are in Europe and do fundraising, you should contribute to this make it happen too".

I suggest you to estimate how much monthly donations of a few euros you could get and add that to how much you spend processing your membership fees. That's how much money your organisation isn't getting.

Each year.

Consider giving a small percentage of this amount to the make it happen so you can finally handle in a cost efficient way these contributions. You'll make civicrm stronger in Europe, not to mention making your organisation more sustainable.

With the introduction of CiviAccounts in CiviCRM 4.3 the ground work to allow CiviCRM to cater for Tax against contributions has been laid.

During the week-long sprint in northern California following CiviCon, we've been working through the design and amendments required to complete the implementation of Tax within CiviCRM.

The specification can be found on the wiki

In short we've tried to ensure basic but powerful tax rules are to be built into CiviCRM Core, with additional hooks for users who need to implment specific rules.

Core functionality will include

• Different tax rules per financial type
• Multiple Taxes being applied to a single transaction e.g. State Tax and City Tax
• Ledger lines produced representing the break down in tax charged

So out of the box you'll be able to

• Charge Tax(s) on memberships
• Charge Tax(s) on Events
• Control Tax(s) at item level i.e. Event Fee 20% Tax, Meal for event 10% Tax, Child Care for event 0% Tax
• Export Liability ledger transactions to your finance system

Using Hooks you'll be able to

• Change the tax rules based on contact region
• Change the tax rules based on any other information

Please take a look at the wiki page and provide any feedback.

Thanks

Parvez

I have previously blogged (http://civicrm.org/blogs/sarahgladstone/fun-and-joy-authorizenet-code-attached) and chatted about (http://forum.civicrm.org/index.php/topic,29234.0.html)  about the fun and joy related to supporting automated recurring transactions in a production environment, and started the process of restructuring that portion of the code.   I have made much more progress and have been using the code attached on production for about 2 weeks now.   I think this approach (which I have implemented for Authorize.net) makes a good model for any payment processor that offers automated recurring contributions.  You can download the code (works with version 4.3.4) HERE

My primary goals were as follows:

1) Auditability.   In a production environement it is essential to have a history of all key communication with a third-party system.  This should be easily searchable by an administrator or other authorized person.  

2) Testability.  It must be possible to test the core functionality without involving the third-party payment processing system or a web browser. 

3) Repeatable, For example: If a message gets handled improperly (such as a bug in the API, some other issue that messes up the resulting contribution) it should be possible to delete the generated contribution record, and re-create it based on the data from the payment processor message log table. 

My secondary goals:

4) Standardize core behavior accross various payment processors that offer automated recurring payments.  Simpilfy creation of new payment processors. 

5) Eliminate what my clients consider odd accounting for automated recurring payments in light of 4.3.x.   In 4.3, any "pending/pay later" status contributions  show as a tranaction in the "Accounts Receivable" Financial Account. When this contribution status is updated to "completed" another transaction is created to represent the movement from Accounts Receivable to the Asset Financial Account. (In this case the Payment Proccessing Account).   With a one-off contribution,this is the proper and expected behavior.  However, with automated recurring contributions this creates oddness for the bookkeeper. For example: They set up an automated recurring contribution of $200 per month for 12 months. (From the bookkeeper's point of view, the person "owes" $2400. ) After the first 6 payments are completed, the bookkeeper will observe that the first installment of $200. was handled as a "receivable" (because of the result of it switching from pending to completed) but none of the other installments are treated that way.  So in the code I wrote ALL installments are treated uniformly: As a contribution that started out in the "completed" status. What I do is create a brand-new completed contribution for the first installment, then delete the original pending contribution.  ( The other option I thought about was treating the entire $2400 as a receivable, then reducing the Accounts Receivable by $200 each month. But this idea seemed much more complex to implement) 

Looking forward to getting feedback on the code and ideas here. 

Pencil and squared paper at the ready CiviCRM is about to get a little more boring...

Yes thats right, over the past few months Compucorp have been working with Web Access, JMA consulting and the Core Team to beef up Civi's accounting integration by providing support for Sales Taxes for CiviCRM. But wait there's more...

Now with full support for Sales taxes it made sense to go the whole hog and produce legally valid invoices and tax receipts. That means, Civi now understands more accounting concepts and can provide better support for organisations with more complex Accounting, Sales Tax and Invoicing needs. No more tracking invoices over in your accounting system and then manually updating your CRM, now all of this is integrated into one neat Civi shaped package simplifying (or removing the need for) costly accounting integrations or manual data imports.

Of course you can optionally turn all this off and keep using Civi and your existing accounting system if none of this is for you.

So what will it do?

CiviCRM now supports percentage based sales taxes on sales. Each line item (field) can now be subject to a different sales tax percentage. Sales tax amounts are automatically applied to a Sales tax creditor account. Sales tax amounts can be exported using the usual accounting export and reporting functions. Contributions, Events tickets, Memberships and Price sets for each are all supported.

And the invoicing?

That means that optionally you can allow Civi to produce legal invoices for purchases. Invoices are automatically generated for each Contribution and sequentially numbered. Invoices can be automatically emailed after purchase and are also neatly integrated with the contact dashboard allowing your supporters to download a tax invoice (or legal tax receipt) for payments that they have made or are due. The administrator can download an invoice, email an invoice to a contact or do both of these in bulk from the search actions. In any case a record is kept of the invoice as an activity against the contact. Pending payment, refunds and cancellations of contributions are all supported with appropriate invoices and credit notes being created.

Support for Sales Taxes and invoices will be coming to a CiviCRM near you very soon... sorry you may need to give your accountant a call!

Direct debit is vital for donations in continental Europe. It's widely available, reliable, and now it could be for free! SEPA -the "Single Euro Payments Area"- harmonized money transfers throughout the EURozone, allowing for easy direct debit payments between any of the 18 EUR countries.

Making SEPA accessible for CiviCRM could be a real money saver for us: No more paying the expensive fees of the bureaus. Not to mention the outrageous costs and delays of credit card payments. Plus, you could have all the donor's information right where it belongs - in your CiviCRM.

Project60 started out more than a 18 months ago to seize this opportunity and (among other things) develop CiviSEPA - the SEPA direct debit integration into CiviCRM. We already released a very basic version some 10 months ago, but it was very hard to adapt to your individual workflows. Since then, we greatly improved the algorithms, the user interface and the reliability. We now believe, that with the upcoming 1.0 version, anyone can use it.

CiviSEPA has been in productive use since Febuary 2014 at organisations like WikiMedia France, muslimehelfen e.V., RobinWood, Bergwaldprojekt - and many more joining. At the moment, it safely processes thousands of payments each month.

In order to make CiviSEPA work with your organization, your donors, your workflow, we want you to test it. We just released CiviSEPA-1.0beta2, and in the next two weeks we will try to fix all bugs and inconveninces that would prevent you from using CiviSEPA. Test it, and let us know!

Find more information on the Project60 page, and come and talk to us at CiviCon London!

Best winds!

You know what they say… there are only two certainties in life - death and taxes. Well, we’ve been working to teach Civi to help make the latter a bit easier. We’re very pleased to announce that Web Access and core team have collaborated to ensure that CiviCRM 4.6 will fully support Sales Tax ( VAT). As of the conclusion of the Edale London sprint we’ve merged this functionality into the master branch.

Not only will CiviCRM understand Sales Tax, it can actually allow users generate Sales Tax invoices right in the back office. This will eliminate the need to track invoices separately in your accounting software and manually upload transaction data.

Key Features

• Fully supports percentage-based sales tax
• Each line item can be subject to a different sales tax percentage
• Sales Tax amounts are automatically applied to a Sales tax creditor account
• Supported: Events, Contributions, Memberships including price sets
• Create Sales Tax Invoices and Credit Notes
• Search actions will allow tax invoices to be emailed/downloaded in bulk
• Ability to make billing block required or optional for pay later option

How are variable tax rates handled?

Variable tax rates can be configured by creating separate “Financial Accounts” for each. We modified core to use “Is Tax?”, the financial account type must be “Liability” and will require that a “Tax Rate” be specified. Tax exemption is supported by setting the percentage tax rate to 0%. Then create “Financial Type” and link it to above financial accounts.

For more details: https://issues.civicrm.org/jira/browse/CRM-15409

Screenshots

Financial Accounts Configuration.

Create Financial Type.

View Contributions with Sales Tax.

Contribution Page.

Event Registration Page

Tax Invoice.

We need your help!

• Please test Sales Tax functionality on CiviCRM sandbox: http://dmaster.demo.civicrm.org

Special Thanks

We would like to thank Jamie Novick for his contributions to the wiki and assistance in planning and testing this functionality. We would also like to thank Joe Murray who was a consultant on the project.

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"

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

Do you use CiviCRM for contributions, pledges, and related financial data? Does your organization use the financial reports in CiviCRM? Does your organization export data from CiviCRM to your general ledger? Or do you want to start doing some of these things?  If so, your input is needed on CiviAccounts.  (You do not need to be a CPA to give input, but having a general understanding of how CiviCRM financial areas work currently is helpful)  

Give your input via the survey at: http://pogstone.com/civicrm/petition/sign?sid=15&reset=1    

(Thanks to the CiviCampaign component, I am using CiviPetition to handle my online surveys)

Background: One of the bigger structural changes to CiviCRM in the last few versions has been CiviAccounts. CiviAccounts includes many things you may use day-to-day, such as using multiple financial types within a single priceset, partial payments for events, sending relevent data to your general ledger software like QuickBooks, and more. Other parts of CiviAccounts are more structural: Such as the configuration areas for financial accounts, mapping payment instruments to asset accounts, and many core tables that were added or changed, bookkeeping records that get generated whenever a contibution is edited, and more.

Like any major area of CiviCRM, there are things that work well and other things that could be improved.  To try to organize the priorities and possible changes for CiviAccounts, I have started a wiki document at: http://wiki.civicrm.org/confluence/display/CRMDOC/CiviAccounts+Roadmap

That area already summarizes the feedback on the survey I have already analyzed. 

One key concern is what is the best path forward for maintaining CiviAccounts. Should some portions of it be moved from core into extensions? what should remain in core? What is the maintenance strategy of the CiviCRM core team for the CiviAccounts area? 

Another concern is what is the best way for people to share their processes, best practices, and new functionality with others in the CiviCRM community?  For example, I created a new batch export format for AccountEdge, but there is no way for me to package it as an extension and share it with other AccountEdge users. 

Also, how are these CRM CiviAccount features helping or hurting adoption of CiviCRM by organizations that are trying to decide on a CRM system. If word of mouth is that getting accounting data from CiviCRM into common general ledger software is difficult out of the box, or requires a lot of manual effort every month, etc. that could prevent an organization from even adopting CiviCRM in the first place. 

I am looking forward to everyone's input on this important topic. 

-Sarah Gladstone

sarah@pogstone.com

I’ve been spending a lot of time the past few weeks working with alpha versions of our upcoming 4.6 release, and I’m excited to share some of the cool new features and improvements. This release includes contributions of vision and code from a wide variety of end-users and implementers. The fact that our entire community reaps the benefits reminds me once again of the awesome power of open source collaboration.

I know how easy it is to miss some new feature in a release that you or your client could really benefit from - so I’ll try to dig down a bit and cover some of the smaller improvements. But first, a shout out to the continuing momentum in improvements to the overall user experience through the addition of short-cuts, more inline editing capabilities, more usable widgets, increased consistency,  and overall responsiveness. As both an end-user and an active tester, I’m really enjoying these improvements and I hope you are too. Kudos to Coleman Watts for leading the charge!

So what’s new and cool in 4.6?

CiviMail UI overhaul - The need to streamline and simplify the bulk mailing user interface has been on the radar for a few years. Thanks to excellent work by Siddhant Rajagopalan - one of our Google Summer of Code (GSOC) participants - a prototype for a new more flexible UI. Following on this work, Tim Otten took things to another level - with a design that will allow different organizations to select a workflow that best meets their needs for balancing efficiency and control. Thumbs up to Google, Progressive Technology Project, Palentetech, Center for Constitutional Rights, and the New York State Senate for funding this major project.

CiviMail A/B testing - The ability to compare success rates for multiple versions of an email campaign was a ‘missing feature’ in CiviMail for a while (which led to some organizations using 3rd party bulk mailing tools). This project got a kickstart from another GSOC student - Aditya Nambiar - and then was ‘driven home’ by Tim.  I’m excited to hear feedback from folks using this tool over the coming months.

Recurring Events and Activities - Do you want to use CiviEvent to handle courses that re-occur every month? Do you want to record a weekly or monthly staff or volunteer meeting as an activity without re-entering it every time? These and many similar requirements can now be handled easily. In addition, a ‘recursion engine’ which will make it possible to have other types of recurrence is now part of the core codebase. Thanks to Lindsey Mansfield (passionate evangelist), Zing (generous funder), Deepak Srivastava (implementor at Veda Consulting), and smart group of ‘code sprinters’ who all collaborated to make this a reality.

Sales Tax (VAT) and Invoices - Starting with this release, organizations can set tax rates for any items being ‘sold’ - including memberships, event fees and related products. CiviCRM can display tax amounts in a variety of formats and will track taxes for output to accounting systems. In addition, staff can create invoices with tax details (learn more ...). Thanks to CompuCorp, JMA Consulting and Web Access for getting this done.
 
Wordpress integration improvements - Thanks to a ton of hard work by Christian Wach, the CiviCRM - WordPress integration is taking a big leap forward in 4.6. The changes affect both site administrators - who can now include CiviCRM pages and forms via shortcodes more flexibly, as well as developers - who now have greatly expanded abilities to create plugins which extend CiviCRM for WordPress.

Personal Campaign Page Owner Notifications - Previously folks who created personal campaign pages had to keep checking their page to track progress toward their goals and see who was contributing. Now, they can opt to get automatic notifications when folks support their campaign. This is a ‘late-breaking’ make it happen thanks to sponsorship by the Vestibular Disorders Association and pro-bono work by Web Access.
    
But wait, there’s even more …

• Improved Scheduled Reminders for membership renewals - flexibly handle reminders for renewing memberships over multiple terms without worrying about ‘repeat configurations’.
• Steamlined Report Layouts - a slick new tab-based user interface for all reports (another tip of the hat to Deepak @ Veda).
• Batch entry for pledge payments - quickly record a stack of check-based pledge payments using the same tool that you already know how to use to record regular contributions and membership payments (give Web Access and thumbs up if you like this one).
• Recurring Contributions’ report - a key ‘missing report’ is now available (yay - Jamie McClelland and Progressive Technology Project)
• Allow decimal amounts in ‘Other Amount’ price fields (previously restricted to whole dollar values).
• Make it easy for users to see which event options are ‘sold out’
• Add contacts to groups from the Find Participants screen.
• Filters to narrow your search when entering a contact on a form via autocomplete.

… phew - I’m running out ink, but for the detail freaks out there you can see the complete list here.

… and behind the scenes there’s a raft of developer-oriented improvements which make writing code for core AND creating new extensions easier (and easier to understand). But we’ll save that for a separate post.

Hopefully there’s several things in this list that you can’t wait to get your hands on, and that inspire you to spend some time trying out the release on the public sandbox AND (even better) by doing a test upgrade on your site(s). Please give feedback here. Huge thanks to all of you who’ve contributed to designing, implementing, testing and documenting the release - it’s amazing what we can accomplish together.
 

Odoo is an open source accounting software. With much more features than only accounting, such as warehouse management, project management, HR management etc.

CiviCRM is an open source software for non-profit and is great in membership management, donor management etc.

For one of our clients we have been working in integrating both CiviCRM and Odoo where Odoo is leading in the financial data and CiviCRM is leading in the contact and membership data.

Meaning that in CiviCRM we create memberships and memberships contributions. Those contributions are synced to Odoo as invoices. In Odoo the invoices marked as direct debits are exported and send to the bank and in Odoo we read and reconcile the bank statements and marking the invoices as paid. As soon as an invoice is marked as paid the contribution in CiviCRM is also marked as completed. In addition when an invoice is created in Odoo this invoice is also created as a contribution in CiviCRM.

The financial department could also remind people of unpaid contribution from within Odoo. This comminication with the members is logged as an activity in CiviCRM. So the membership department could see that the financial department has contacted this member about unpaid contributions.

At this moment the synchronisation between Odoo and CiviCRM is in a testing phase.

On last year's CiviCon in London we presented the first stable release of CiviSEPA 1.0 - a fully integrated solution for direct debit payments in the Single Euro Payments Area.

Since then, many organisations have processed millions of euros in donations, membership and participant fees without having to spend a single cent on payment processor or buero fees.

What you will get with the current stable version

In March 2015, based on our client's feedback, we released CiviSEPA 1.1. This version now features an easy configuration UI and lets you manage multiple creditors with individual settings. Furthermore, the Update provides a nice integration with CiviCRM's online contribution and event registration pages, as well as the Little BIC Extension. It also includes many minor improvements and bugfixes.

Please find more information on CiviSEPA on this Wiki-Page: http://wiki.civicrm.org/confluence/display/CRM/CiviSEPA. It is compatible with 4.4. and 4.5 - so far we didn't have the opportunity for extensive 4.6 tests but we don't expect too many issues.

CiviSEPA is also nicely integrated with the extension CiviBanking which offers a very sophisticated framework for importing bank account statements and matching the enclosed payments with contributions and contacts in CiviCRM. 

Start using and supporting CiviSEPA now!

For your basic SEPA requirements, simply download and install the extension from within CiviCRM or from a GitHub release, read the documentation and you should be good to go. Of course, feel free to work on the code yourself or contact us for professional support if you need to adapt or enhance CiviSEPA for your organisation's need.

We have a number of nice features, enhancements and improvements planned for version 1.2 and/or later versions, including:

• Compatibility with 4.6 and 4.7
• UI to import mandates
• filter options for SEPA-groups UI
• manual adaption of mandate reference numbers

Please support us to implement those features, to keep CiviSEPA well maintained and DD payments free! We'd like to encourage you to share your experiences, share your documentation, and share your code modifications! And please understand that we can't do all improvements and bug fixes for free.

So far we've put more than 130 days into the development and testing of CiviSEPA - only about half of that was paid for. If you consider sponsoring a feature or supporting us in any other way, please contact us via GitHub, email or phone (+49 228 96104990).

greetinx

The SYSTOPIA Team

I am Tahir Ramzan, pursuing Masters in Computer Science at Virtual University of Pakistan. I am working on refunds, partial refunds and partial payments development for CiviCRM. Parvez Saleh and Joe Murray are mentoring this project.

Refunds and Partial Refunds:

Often, we need to tackle situation where one needs to make partial or full refunds. After this project users will be able to make refunds with friendly user interface and proper database records.

Concerns:

• How to represent an administrative fee for refund? Who will pay this, buyer or seller?
• How to link the refund with the original contribution?
• Which method to use for processing refunds?  Check, payment processor or both.

Partial Payments:

Partial payments on the other hand need to be done when someone pays a part of payment contribution in installments. This will be very useful for CiviCRM users for multi-purpose tasks. By developing this project, not only the users of CiviCRM but also the end users will be benefited and CiviCRM contributions will witness a significant increase.

Concerns:

• How to represent an administrative fee for the partial payment? Who will pay this, buyer or seller?
• Pre-defined amount installments and buyer defined installments/ variable amounts
• Handling taxes, penalties, markup and administration fees

Key deliverables:

• Refunds API
• Partial Payments API
• Refunds UI Extension
• Partial Payments UI Extension

Community Feedback:

I am looking for valuable feedback form community which is vital to make this project successful and useful. Here are links to Forum Thread and Wiki Page of the project. Kindly share your thoughts.

During the past year, I've been working with a number of medium and larger organizations using CiviCRM, and have found a few gaps in CiviCRM's CiviContribute functionality, particularly around the management of recurring donors, which are often a really important part of a larger organizations' donor base.

To this end, I'm happy to share a couple of extensions that I've been developing to fill these holes, detailed below.

Feedback and patches welcome, as usual. 

Also a side note -- if you're using our iATS Payments extension, we've just released a new 1.4.0 release, which is CiviCRM 4.6.x compatible.

1. CiviContribute Recur Extra

Until I put together an official release, use this page: https://github.com/adixon/ca.civicrm.contributionrecur which describes what it does in more detail.

The key things it does are:

a. Backport the new recurring contribution reports in 4.6 for earlier civi versions.

b. Add a system job for handling more complex recurring membership functionality.

c. Configure fixed days of the month for recurring contributions (this is really only a starting point of this functionality, and will depend on your payment processor).

d. Add more editable and viewable fields when managing your recurring contribution records (sometimes called the "schedule").

2. CiviContribute Extra https://github.com/adixon/ca.civicrm.contributextra

This extension provides two other useful things that aren't specific to recurring contributions.

a. Administrative use of front end contributions forms. If you find that the backend credit card contribution forms are too complex for your standard administrative data input of credit card donations, for example, then you can use a streamlined form that you create just like your front end forms (or rather, you use a front end form that's been specifically identified for admin use). This is a spin off of a requirment we had for ACH/EFT backend data entry that found another use for phone bank fundraising, to simplify the phone bank volunteer job.

b. Extended contributions report. The idea of this report is that it generates a bookkeeping report total based on a set of filters you define, and a set of headers your report on, and then every other dimension of data is totalled. In other words, an income report summarized by arbitrary fields.