support for pledges needed

[lucyp]

This is continuing a conversation I started with Lobo over on General Discussion forum, now moving it here.

My org sorely needs support for pledges... Here is my first attempt to describe what is needed.

- Lucy
Bay Area Nonviolent Communication
www.baynvc.org

*****

Support for Pledges, Requirements

* track one-time pledges
* track pledges of a monthly or yearly amount

Details, one-time pledges
* date the person made the pledge
* amount pledged
* date when the actual money is expected (default to one month after pledge date)
* if money not received by that date, automatically create an "activity" to contact that person

Details, monthly/yearly pledges
* date the person made the pledge
* amount pledged
* monthly or yearly
* until when
* track dates, amounts, of money received
* integrated with automatic recurring charging of credit cards

Details, all pledges
* total amount pledged but not yet received
* track whether a pledge was cancelled, and reason

optional features
* tying pledges to a particular "campaign" or "fund"
* support for matching gifts
* display of progress toward a goal


End-User procedures

1. Data entry by office staff

   a. office staff logs a one-time pledge of a given amount
   b. office staff logs a recurring pledge of a given amount, plus receipt of first installment
   c. office staff logs a recurring pledge of a given amount, but no money received yet

2. Online pledging by supporters

   a. supporter signs up for recurring pledge,
   pays first installment online by credit card,
   authorizes monthly charging of credit card

   b. supporter signs up for recurring pledge,
   promises to send first installment by check,
   selects "bill me" for subsequent installments

   c. supporters can sign up for various volunteer opportunities,
or answer additional questions about interest areas, while pledging online
   (need a way to add custom-built forms/fields into the process for this)

[geilhufe]

Thought I'd jump in an discuss implementation details while the requirements start coming together.

Support for Pledges, Requirements
* track one-time pledges
* track pledges of a monthly or yearly amount

Details, one-time pledges
* date the person made the pledge
* amount pledged
* date when the actual money is expected (default to one month after pledge date)
* if money not received by that date, automatically create an "activity" to contact that person

Details, monthly/yearly pledges
* date the person made the pledge
* amount pledged
* monthly or yearly
* until when
* track dates, amounts, of money received
* integrated with automatic recurring charging of credit cards

1.
Most fund raising systems (Giftworks, Raiser Edge) treat pledges as a "contribution type" in our parlance, and then provide tools to reconcile pledges with donations. We do not have any reserved contribution types currently, so we could create both a "pledge" and a "donation" reserved contribution type.

The only problem we have is that you can no longer use contribution types to track campaigns. You would have to do that via the civicontribute form, which means hand-entered donations could not be put into campaigns.

Not sure how to deal with this issue other than put in some type of support for campaigns.

New fields: Date pledge made, projected donation date, reoccurring Y/N + details (monthly/yearly), active/canceled status, for the pledge contribution type.

2.
Provide a way to relate Contributions.
When a donation is entered for a contact, that donation can be related to an existing pledge.

3.
Provide reporting to see upcoming pledges, unfulfilled pledges, etc. via the contributions search interface. Pref a collapsible box with the pledge fields.

4.
Table the more advanced email notification, integration into civicontribute pages, etc. for a release once the pledge functionality has been out and getting used for a release.

[Donald Lobo]

my 2 cents ...

• Rather than using a contribution type, I suspect we can/should use the contribution status. So for example, a contribution which is of type "donation" is pledged, the status becomes "Pending" (and we probably have a boolean fields called is_pledge) which indicates that this is a "pledge" contribution. (Since Pending could also be a paypal transaction that is not yet completed)
• We will also need another date to record when the pledge is expected to be fulfilled. If not fulfilled by this date, we flip the status to Overdue.
• I dont see the need to integrate a "recurring" pledge with an automatic recurring donation. This is handled by our current recurring donation process (actually paypal does it and informs us)
• Adding a periodic pledge will require some work, since we'll have to pre-create all those contributions based on the parameters. We don't have any code to handle this as yet. The previous points are simple extensions of our current code base
• To some extent, we can/should combine a pledge with a "Pay Later" option (or pay be cheque). They have quite a few things in common

lobo

[geilhufe]

* Rather than using a contribution type, I suspect we can/should use the contribution status. So for example, a contribution which is of type "donation" is pledged, the status becomes "Pending" (and we probably have a boolean fields called is_pledge) which indicates that this is a "pledge" contribution. (Since Pending could also be a paypal transaction that is not yet completed)

The reason most systems don't do this is:
(1) There is often a discrepancy between the amount pledged and the actual amount donated. How would you track the original pledge amount vs. the actual donation? This discrepancy is also decision support data for fund raising professionals.
(2) Pledges are often filled over the course of multiple donations. If I start with a pledge of $500 and then make a $50 contribution, how do you track that? Where is that data reported for decision support? How do I differentiate between a $50 donation applied to a pledge and a $50 donation not applied to a pledge?

How would these cases be handled using a status field?

we can/should combine a pledge with a "Pay Later" option

I agree. I would argue these are exactly the same thing as pledges... the only difference is there is a one-to-one correspondence with the pledge and the payment rather than a n to n relationship between pledge and payment in the general case of pledges.

[Donald Lobo]

Well obviously i dont understand enough of pledges Thanx for the tips below

So looks like a pledge is another top level object and could have one or more contributions associated with it which may or may not match the amounts on the pledge. The pledge object has a different set of attributes as compared to a contribution object (since its more high level and no gory details of a transaction).

We'll also need a recurring pledge object which holds one or more pledge objects which may be linked to a contribution object

Given the above, i suspect we'll handle Pay Later for a contribution (or event) with just a status field (pending) and inidicate its an offline payment rather than a pledge.


lobo

[mcsmom]

I think it is important to understand whether there is a difference between a pledge and some other kind of promises to give. I don't know that every promise to give x a month indefinitely is really a pledge or not.

In terms of accounting (at least in the US), pledges have special treatment. For example, a multiyear pledge is counted as a contribution in the year the pledge is made, even though the money does not come in.

[Dave Greenberg]

I think it is important to understand whether there is a difference between a pledge and some other kind of promises to give. I don't know that every promise to give x a month indefinitely is really a pledge or not.

In terms of accounting (at least in the US), pledges have special treatment. For example, a multiyear pledge is counted as a contribution in the year the pledge is made, even though the money does not come in.

Elin - Given your comments above, do you have any thoughts on how (or if) we should differentiate our existing "Recurring Contribution" functionality from a "Pledge" to give $X every month for N months. A "Recurring Contribution" (in our current implementation) is something that happens automatically. I guess a "Pledge" for a recurring amount might OR might not be automatic. Otherwise, not sure I see functional differences (i.e. ones that we can "explain" to folks using these features). ??

[Dave Greenberg]

I've created a draft Requirements page on our wiki and attempted to summarize/consolidate the discussion so far:

http://wiki.civicrm.org/confluence/display/CRM/Pledges

Let's continue fleshing out the requirements on that page. You can edit the body and/or add comments. If I've omitted any ideas from this thread or somehow not presented your ideas clearly - please feel free to modify the page!!

[mcsmom]

SOunds good. I'm not sure if there is a difference, but I think there could be. If I sign up to give $10 / month for 12 months exactly then that seems like a pledge of 120 to me.
But if I say put me down for $10/month until I say stop seems like something different.

[FatherShawn]

What's the status of pledge accounting as a pending feature?

[Donald Lobo]

No progress as yet and none planned by the core team in the near future. If folks need it, someone needs to step up and help design/develop/sponsor it.

lobo

[Masked Marauder]

Has there been any advance on this problem?

It would be very helpful if there was a way to link donations to a pledge. 

For example, someone pledges $1,000.  Then, sometime later, they donate $500.  A few months later they donate another $250.  Etc.

I don't see any way to either log incremental pledge fulfilment, or link particular donations against existing pledges.

[Dave Greenberg]

In recent versions you could create a generic pledge schedule (let's say 1,000 => 4 payments of 250 each) - and then record modified payments as the variable contributions come in my changing the payment amounts and dates on the pre-populated list of scheduled payments. A more flexible "apply this contribution to an existing pledge" patch could be accepted depending on how it's implemented. You'd want to write up the approach - and how you'd deal w/ adjusting an existing payment schedule (pledges always have an "expected" payment schedule).

[Masked Marauder]

I'll look into it. 

The scheduling of payments isn't much of an issue for us at this point.  Its an artifact of the FCC licensing process that we had to obtain pledges 3+ years in advance that need to be redeemed now that the CP has been granted.  Its clearly a different model than that encapsulated in the CiviCRM Pledge functionality.

I'll get back to you if I figure something out.