CiviCRM Community Forums (archive)

I was delighted to see pledges added to 2.1, as it would mean one less custom app to maintain alongside CiviCRM for one of my clients. Unfortunately, CiviPledge is missing two main things that may prevent us from using it until a future (hopefully near future) version. I've also found some frightening behavior that might scare me off in any case.

The first and perhaps more minor issue is that multiple nonprofits that I work with accept quarterly pledges, which is not an available frequency. That may even be minor enough to get into 2.1. Every time I've implemented a solution to track pledges, I've stored the frequency with quantity and units (every n months/quarters/years) for maximum flexibility.

The larger issue is that CiviPledge seems designed firmly around the idea of fixed-length pledges. This organization (as well as others I've worked with) are increasingly gathering open-ended pledges. i.e. "charge my credit card $25 every month indefinitely." If only a pledge had a notes field, we might get away with noting which pledges needed to be renewed. Although given the ascendency of open-ended pledges, this would only become increasingly awkward over time. If I can't find a way around this, it may be a deal-breaker.

The frightening behavior I see may center around the fact that we currently deploy CiviCRM for internal use only. Along these lines, the first thing I noticed is that pledges are set to send reminders by default. I haven't played with that much yet, but I assume it means that it will send email reminders. This must have been designed with user-initiated pledges in mind; in our situation, it's a very dangerous default. With a backoffice-only deployment, I would expect CiviCRM to never send email to any contact without explicit direction to do so. Perhaps the default should vary depending on the source of the pledge (internal vs. external)? This may be a larger issue with the tug-of-war between the needs of outward-facing and inward-facing deployments.

The other behavior that makes me nervous is the apparent inability to record pledged contributions even a single day in the past. All of our contributions are recorded manually, generally by a single person. Not necessarily on the exact day that they are made (even the board member doing data entry gets to go on vacation occasionally). On top of which, many of our pledges involve us running the credit cards on a particular day. The charges might actually be made a few days later, depending on schedules, cards being rejected, and any number of other things. I think the rigidity of recording pledged contributions is going to be confusing and awkward. At best, whoever's doing data entry will become very familiar with the "Edit Schedule" link (in a loathing kind of way). At worst, we'll have to choose between conforming to CiviPledge's expectations and recording accurate contribution data. As a general rule, I would submit that recording true and accurate information about a contribution is paramount and everything else needs to be flexible enough to accommodate that.

Thanks for the great work. I hope we can use this someday soon.

Is there a difference between "Every 3 months" and "Every 1 quarter" ?

Nope, that would be fine. I don't see a way to do "n months" in 2.1a2. I'm not missing it, am I?

For the short / medium term you could create a renewal work flow by adding custom field(s) to the Pledge records which indicate whether a pledge should be renewed.

D'oh. Quite right. We use custom fields fairly liberally, but I completely spaced on it in this case. That should do it. Custom field groups for pledges don't seem to work in 2.1a2, but it looks like it's fixed in sandbox.

Quote from: psagers on August 13, 2008, 04:08:03 pm

The other behavior that makes me nervous is the apparent inability to record pledged contributions even a single day in the past.

I'm a bit confused about this comment.

That's my fault; I didn't express that clearly at all. I actually just checked the sandbox site and it looks like the behavior is fixed. The bug I was describing in 2.1a2 can easily be seen by entering a pledge with a start and next payment date of yesterday. If you then go to the payment schedule, there's no link to record the first payment. You're stuck. On the current sandbox site, the payment is marked overdue, but the link is still there, so it's cool.

There is still one oddity on sandbox: the next payment date is still set to yesterday (as it probably should be), but the next payment amount is the amount of two payments. Apparently the Next Payment Amount is actually showing the amount due by the first scheduled payment date in the future, which is a bit different.

I'm feeling much more optimistic about pledges now. I'll do another pass on a3/b1 to make sure I can duplicate the behavior I see in the sandbox.

Thanks!

For user-initiated pledges, we allow the admin to configure the Reminders parameters - so they can be set to 0 reminders. As a longer term solution, I've added a task for the next release to allow "New Pledge" defaults to be configured for back-office recorded pledges.

I didn't realize that user-initiated pledges made it into 2.1.  Where are the configuration pages in the back-end of the sandbox to set that up?

Great job psagers catching the missing "every x period"!!  Since it was there earlier, I just didn't notice it was gone either...

I've been putting a3 through its paces and it looks like everything is fixed. I haven't actually found the cron script to update pledge status, but perhaps it's not in the builds yet.

Cron files is in bin/UpdatePledgeRecord.php.txt, you will have to rename it to UpdatePledgeRecord.php

One usability note: it might be a good idea for someone to look at the default sort orders for pledge-related record lists. In particular, CiviPledge search results (including the main page) are sorted by Pledge Made ASC, whereas it should probably be DESC. This would be much more useful and also more consistent with CiviContribute.

Done. Should be part next alpha.

thanx for the feedback..

kurund

This is all accurate and by design?

yes

Is ACL integration planned for a future release?

not for 2.2. However a code contribution can help make this happen in 2.2

lobo