CiviCRM Community Forums (archive)

I began using Civi for my previous congregation beginning with version 1.6/1.7.  We used it for all the things that you mention, plus online registration for events, both paid events such as conferences, and unpaid events like picnics & potlucks.  We also tracked membership status: active, inactive and such.

Civi strives to be agnostic about the CMS but there are some differences because of differences between Joomla and Drupal.  I built my last solution on Joomla as that was the platform we were already using.  The biggest difference is that Joomla does not have fine grained access control built in and Drupal does.  All three Joomla roles that have access to the backend have complete access to Civi.  Joomla has announced ACL for ver. 1.6 and I would expect Civi will take advantage of this once it's released.  If it's critical for you to restrict access to donation records, or membership, or any sub-component of Civi to a certain user role, then you should use Drupal.  If that's not important, then look at the CMS - they do have different approaches and cultures, and choose based on the differences between CMS.

If pledges are a part of your church's stewardship model, you should know that you'll likely need to workaround CiviCRM's limitations regarding pledges for a bit.  The pledge model is scheduled for update in the next version, 3.2.

1. the pledge model is not scheduled for an update in 3.2  If folks are interested in seeing this happen, they need to step up and help make it happen (either by contributing development resources and/or sponsoring the core team)

Thanks for the clarity, Don.  On a closer read, I see I missed the Candidate part of the 3.2 Roadmap.  

Maybe there is someone with resources or skills who will sponsor a fix a some point.  In the meantime, I'm happy to help anyone with the workaround that we developed by exporting to another database for reporting and tracking pledges.

you might want to be a bit/lot more specific and add details and potential solutions / alternatives to the way civi does pledges on the pledge roadmap:

http://wiki.civicrm.org/confluence/display/CRM/CiviPledge+Roadmap

Phase 2 will probably be implemented when someone from the community steps up and makes a code contribution / sponsorship

lobo

I'll have go at explaining the workflow and relationship, Eileen.

The two largest groups of non-profits that I know of which use a pledge model here in the U.S. are churches and public radio and television stations.  The process has two phases, pledging and contributing.

During the pledge phase, supporters make a pledge, a commitment to contribute a certain amount over a certain period.  Pledges are typically collected toward the end of a fiscal year for the next fiscal year.  How "hard" the commitment is probably varies from one organizational culture to the next.  The organization though relies on the pledge commitments in creating a budget for the coming fiscal year.  A similar process might also be used in a campaign to raise capital funds.  Capital campaigns often involve pledges over 3 to 5 years.

After the pledging process is concluded the donor makes contributions to satisfy the pledge. There is then an implicit relational structure between the original pledge and the collection of payments made to satisfy the pledge.

It is in contribution or pledge collection phase that CiviCRM falls short because the data model is inflexible.  Civi creates a schedule for pledge payments when the pledge is created, so if one pledges 12 payments of $20, one can only record 12 payments and they all must be $20.  I expect that any organization funded by voluntary contributions would say "Thank you" to a contribution of $15 made against the pledge.  So I have been advocating for some time that connection between Pledges and Contributions made to satisfy the pledge should be relational and that the Pledge Balance be calculated as the difference between the sum of the related Contributions and the Pledge Amount. 

Please fire back a questions or several if any part of this explanation doesn't make sense

I took a look at the roadmap and I think that its really headed the right direction - Here is what I think might be a simple solution (realizing simple doesn't necessarily mean easy)

If pledges were simply configurable by the amount a person has "promised" without worrying about a schedule of payments - perhaps that's an option people could employ but would not be required.  Payments would be recorded as normal contributions - which is in fact what they usually are - this would make reporting easier because you aren't pulling together multiple tables etc.  When making a contribution entry if a person has an outstanding pledge the system would allow the entry to be entered against that pledge (many payments to one pledge) or split over multiple pledges (i.e. one person has a pledge to the building fund and to the operating budget and they send in a check for 500 to be split 50/50 between the pledges - this is a pretty common occurance) - the outstanding pledge balance then is just a calculated field between the sum of all payments made with that pledge marked, and the initial promised amount.  Web forms would present a logged in user with a list of their oustanding pledge balances, with the ability to make payments to any or all of them or to make a normal non pledge contribution. 

Yes!  Very similar.  So long as an initial payment is only an option, then the data model and process abstract to the same archetype!

the sql schema is your best bet. Check for tables with pledge

civicrm_pledge
civicrm_pledge_block
civicrm_pledge_payment

lobo