CiviPledges can be set up so that
- a logged in contact can see their upcoming Pledges on their dashboard
- a contribution page can be set up as a self-service payments page
I set one up on the Drupal demo site so it should be there for a few hours before it flushes.
Dashboard is here
Setting up a pledge is here
The self-service payment is here but ...
The API csv Import GUI extension will allow you to import pledges. You can import the pledges and then separately, the contributions marked as pledge payments that correspond to the needed pledges.
Note: When you import the contributions, you will need a column for "pledge payment" that is marked Y for each row. Also, you will need a column with the ...
In simple terms, if the person is planning to pay by an unknown or manual process (check, cash, bookkeeper manually recording payment as they see it on a bank statement) then you will use a pledge in CiviCRM.
If the person is going to pay using a CiviCRM payment processor that offers recurring (such as credit cards/ACH via iATS or Authorize.net, etc) then ...
CiviCRM allows pledges to be recorded for promises of future payments. This is commonly done for future expected donations for capital campaigns. In most cases, 'pledges' are not things that people are obligated to pay, and so they should not be recorded as accounts receivable for bookkeeping purposes. The courts in some US states are starting to recognize ...
Indeed, different workflow. with pledges, you create "expected" contributions for each time the donor said she'd contribute. You can then alter them via the api (eg with the api explorer)
The entity you want to change is pledgePayment. you can update the contribution_id, the amount and the status and it should then be working as expected
I do something very similar with my church. the actual donation is credited to the individual who made it with a soft credit going to the household. This allows us to do reporting by either household or individual.
You can create a membership type called tuition and set the term to be 1 month at the rate for 1 month.
Then create a price set for that membership and include 3 prices and select the term which that price purchases.
price #1 is $100 and pays for 1 term (which is 1 month) and auto renew and ends after 10 months.
Price #2 is $450 and pays ...
I would consider using Membership Types rather than Pledges. You could set up each payment term as its own Membership Type, with different terms (ie 1-month membership that lasts for 10 months; 6-month membership; etc). Then create Membership Contribution pages for each term. You could turn on the auto-renew feature, or make that optional and setup payment ...
If you export your search results to a CSV, you can then import them as pledges with the API csv Import GUI extension. Setting up the columns correctly for the import will presumably take a little trial and error.
Do you mean members donating TO other members or donations to be credited to other members?
You may be able to utilize the built in personal campaign pages for the first question, then your accountant/bookkeeper would write a check. The latter item is accomplished by the Soft Credit feature.
Did you read the manual before asking this question?
As per my reply here
CiviPledges can be set up so that
a logged in contact can see their upcoming Pledges on their dashboard
a contribution page can be set up as a self-service payments page
Setting up a pledge is here
The contacts Dashboard is here
The self-service payment is here but will only ...
Yes thats true, if you update certain parameters of existing pledge than it deletes all pledge payment and recreates it. Below are the parameters when changed deletes all pledge payments.
The "recurring payments" approach will only work if you have a CiviCRM payment processor extension that supports it. Other than iATS and CiviSEPA I'm not sure other extensions support ACH/EFT - though I'm not familiar with the non-US processor extensions.
It could be that CiviBanking could provide a solution for you.
Another possibility is the Offline ...
Click to expand the pledge payment schedule and then click edit on the expected installment set up for next year - you can change the date back to the current year.
Unless you are dealing with multi-year pledges, consider creating them with a single installment to occur every one day - in this way, the system will transfer the remaining balance as being ...
This is a bug. It only happens when you have modified the name of the pledge status "Completed" or "Cancelled". In your case, "Completed" has been modified.
While you could change that label back, the report shouldn't crash regardless. It was easy to fix, so I reported the issue then made the fix.
You literally need to change one word in one file, so if ...
I see this line in CRM_Contribute_BAO_Contribution:
//update pledge and pledge payment, CRM-3961
Looking at CRM_Pledge_BAO_PledgePayment::resetPledgePayment(), I see it calls the DAO method, not the BAO - which is why the hooks (which ARE present) are bypassed.
I think this would be a good ...
Can you check this PR
There seems to be a bug that allows you to change the payment schedule and wiping out the contributions in the process. The above patch will fix the same.
You can give your contacts (who have a user login) access to their Contact Dashboard - and once there they can see Pledges
If you don't have CiviPledge enabled go to Admin > System Settings > Enable components.
If you have enabled it but don't see it you may need to go back to your Permission settings and enable those.
You will also find that when you add ...
For our projects we always use Contributions (instead of pledges); in a nutshell we use: Contributions - with Status Pending - and with a receive date in the future.
Added: when you receive a check for eg 3 of such pending Contributions you can hit Edit -> record the chq payment, update the receive date to the actual one (the one you had was just the '...
If you have two transactions entered that are exactly the same and both pending, but one is cancelled, it may have created a conflict in the system. Try deleting the cancelled transaction and see if that helps.
If you are working with a Payment Processor that can tokenize credit cards then you can do this:
Have people 'register' by Starting a Recurring Series of 2 installments - an initial contribution of $1
Then when you know what $ amounts they owe you (admin) can go in a transact one time against the token (any $amount)!
Cancel the Recurring Series to prevent ...
Unfortunately pledges do not work with online contribution forms the way you'd like without an extension. You can use the framework for partial payments that's available in github and seen at the CiviCon in Denver earlier this year
First you'll need to create the contribution(not a pledge) on the back end. You probably can use the same concept with a ...
I have now reported this bug here; https://issues.civicrm.org/jira/browse/CRM-17651
The bug only shows up when using price fields for a contribution page. There are good reasons for using price sets, however, and there is no reason I can see not to allow pledges when using the price set functionality.
If you have any fixes or workarounds that allow me to ...
Not sure if this question is still relevant, but just in case - the only payment processor that currently allows you to set the charge date is authorize.net, and you would do so by setting up a recurring contribution from the back office for 1 installment to start on the date that you desire the card to be charged - I do not currently see how this ...
Unfortunately there is not a way to assign a pledge to multiple contacts.
In the CiviCRM database, the pledge is assigned to a contact, but the individual pledge payment/installment is related to the pledge and not the contact.
Without a customization, this would not be possible. Sorry
I don't know if a template override can do this, but an extension may be a good option. You'll need logic to filter on specific contribution pages or other business rules, but here's the basic idea of hooking into the post process action and moving the contribution from the current contact to the household. Another option to consider may be to automatically ...