Use a combination of smart groups, tags, CiviRules, and CiviReports.
A. Create a Smart Group
Use Search Builder to search for Contact :: Envelope # :: Not Empty OR Not Null OR > 0
From search results, create new smart group (called "Has Envelope #")
B. Create a tag called "Update External Address"
C. Setup a CiviRule
Create a Rule with the Linked Event ...
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 ...
As a member of the CiviCRM documentation team I will follow up on that quote, as I am not sure what it means myself. It may be left over from earlier times and no-one has been brave enough to modify or delete it.
From experience I can tell you that you can create the new financial types for income that you need.
My organisation also uses different ...
With respect to the overpayments, I don't know whether this will fit standard British accounting practices but I'd be inclined to create a separate financial type for the overages - a holding fund, if you will - and record one payment for the membership fee and one for the overage. They could then add an adjustment transaction the following year to move ...
We built some integration for Xero which is an online accounting system. The code isn't quite 'plug and play' but once set up it does the synch between contacts and transactions in both systems. Read more about Xero here https://www.xero.com/ and a blog about the integration here http://www.fuzion.co.nz/blogs/civicrm-integration-xero
There has been some integration work undertaken by Fuzion and is available in this extension. General functionality:
create contacts in Xero based on them being created (or having had a contribution or recurring contribution) created in CiviCRM. You can configure which of those 3 will cause them to be created in Xero
update contacts in Xero based on the ...
I am not if anyone has done this before but you can use combination of hook_civicrm_batchItems and hook_civicrm_batchQuery to add columns in csv files. I don't think there is any easy solution to add column in iif export file.
I found the solution by changing two lines of PHP for the Contribution Detail report (CRM\Report\Form\Contribute\Detail.php) and putting it in our Custom PHP directory.
The filters section for the batch name field reads by default (Civi 4.6.20) as follows:
$this->_columns['civicrm_batch']['filters']['bid'] = array(
'name' => 'id',
There is a batch export in csv that works for many packages, a .iif that works for QuickBooks desktop, an extension that integrates with QuickBooks online Australia, and an extension that supports Microsoft Dynamics.
You can create an extension that would export in your format. Here is an example of similar requirement.
You can use this extension to create a new export format through UI and copy paste CSV file and edit the columns code that you would not require in export.
I think an extension is a good idea, but a quick glance at the aplos API and it looks like aplos wants each transaction mapped to an aplos contact id. This seems like a lot of work that is not necessary. My advice is to see if you can upload a batch at a time through CiviCRM export (maybe a custom search or report) and see how that works first. the ...
You could add a custom field for the donors to effectively pick the campaigns they wish to donate to, then you could reallocate behind the scenes is one option.
Another is to use shop items, these could result in separate contributions being created in CiviCRM for each item.
Either approach would need a bit more then just config so to speak.
A few points:
The system creates a financial account automatically when you create a financial account, so there's not much extra effort. You will want to edit the financial account to put in the QuickBooks chart of account information.
The general advice regarding Chart of Accounts (in QuickBooks or similar software - it's actually an accounting best ...
Great use of campaigns. We've had similar situations and we've generally either written a custom search or a custom view(if you're using Drupal). I don't believe there is any built in functionality. It would be great to write a custom search and make it available in GitHub if you can make it generic enough.
The quote from the documentation is perhaps alluding to the fact that you can create a price set where the various options can be allocated to different financial types, but I don't believe it is relevant for your situation where you already have a contribution record for the membership.
I agree with Lesley's suggestion of a separate financial type for ...
The big thing you need is a way to associate line items with campaigns. This would be fairly simple to do with an additional table in an extension. Then, so long as campaigns were appropriately named, the extension could provide a drop-down on each line in a price set allowing the donor to specify the campaign. I'd suggest we also add a new field for ...
We have built an integration package with Xero which is available and explained here. Xero is available in Australia.
The integration means that both Contacts and Transactions can be pushed or pulled to civicrm, and the civi Financial Types can be set to match the Chart of Accounts in civicrm.
[Old question, but may still be relevant]
A quick but hacky option would be to comment out the IIF line in $optionTypes in CRM_Financial_Form_Export::buildQuickForm()
A better option would be create a setting and use that to set $optionTypes which would be a straightforward enhancement. Since a site probably wants the same type for every batch, a setting ...
Trying to provide some answers:
Depends on what you mean by support for accounting, can you define that in a little more detail? CiviCRM can store contributions, event fees and membership fees and will store them with a specific financial type, linked to a financial account. For each of those contributions, event fees and member dues it will also generate ...
Thought of a few more important things:
I would map the BigCartel transaction ID to invoice ID and the payment processor transaction ID to the transaction ID field in Civi - this will preserve consistency of data and facilitate reconciliation
Sometimes communications get disrupted and your hook might miss a few transactions unless you add some kind of a ...
Thanks for your clarification. Since you will be importing historical data and using an IPN to capture future sales information, I don't think you need to use price sets at all.
Again, you should touch base with the powers that be to understand what level of detail they wish to preserve in Civi, but my guess is that at the ...
We use Civi & QuickBooks. Our QBs is only used for accounting. If we need to see donation details, we look in Civi. We do not record contribution detail in Quickbooks. We do not see a need to have that data stored in two places.
We just record the deposit in QBs. We use Class in QB for our Functional Expense allocations (Program, Restricted, and ...
Once can find payments for contribution by clicking on Amount from Contribution result. The section which appears after clicking on amount shows all the payments against the contribution.
I believe its not possible to turn off 'Record Payment' link from contribution through UI. But you can implement hook_links() in your extension and unset the record ...
CiviCRM 4.7 have accrual integration where you can specify Revenue recognition for a contribution. You can enable the 'Enable Deferred Revenue' setting by navigating to CiviCRM >> Administer >> CiviContribute >> CiviContribute Component settings.
Once you have enabled the setting you will need to create 'Deferred Revenue' relationship between Financial type ...
Date Received as in date on the cheque (i.e. the date that someone started giving you the funds) works just fine.
All our larger organizations/clients do just that. I would recommend against making things more complicated by adding in additional / new / not much used functionality that you really don’t need to solve this problem.