CRM-17140 Get rid of contribution financial type

Toby Lounsbury at Botanical Society of America has written an extension which addresses this. It was 90% complete at the Colorado sprint, and he had to complete it for his organization's use in May.

Tobias Lounsbury please share your extension when you can

I'm glad to hear about Toby's extension. That'll definitely be helpful for a bunch of folks.

However, I still can't find any reason for the contribution to have a financial type. I would actually suggest that nobody reporting on or searching on financial type is actually looking for the contribution's financial type. Whether they realize it or not, they are looking for the line item's financial type; it just happens to be the same most of the time.

I renamed the issue and am reopening it to clarify the issue. I'm obviously not expecting the column to go away for 4.7, and it's nobody's priority at this point to fund it, but I think it would be good to aim in that direction.

This also would be good to have the issue out there in case someone has a good reason to keep the field.

Related issue: In the event configuration you can choose a price set but also select a financial type.
As stated above, there should be no overall financial type, the financial types if the line items should be used to avoid confusion.
So, it applies also to events...

I strongly support fixing this. Ideally there will be no contribution.financial_type_id. An interim solution would be to populate it only when all line items have the same financial type, and set to null otherwise (including when updates are made to line items). Changing searches and reports to use financial_type from line item is a good place to start.

Remember that not everyone uses price sets (although I always do). Contribution.financial_type_id is used for contributions that don’t use a price set, so you would have to force everyone to use price sets or provide for setting the financial types separately for the “other amounts” (if enabled) and the Fixed Contribution Options.

Then you have a similar situation with Event registrations and also with Memberships where the financial type is set where the membership is defined (Some of us have different accounts for new memberships and for renewals, so again you can have a contribution with financial type ‘New member’ yet the only line item for that contribution has financial type ‘Renewing member’.)

I agree with Joanne on this. Would not suggest presupposing how folks manage their recordkeeping so please do not deprecate existing conventions unless there is a survey of users showing a desire to do so. People get very set in their ways and have an expectation that whether it is GAAP or something unique to CiviCRM it is something they have woven into their recordkeeping. If Intuit ever did this with Quickbooks people would be screaming (it has happened to Intuit before and they quickly reversed their decision to save market fluctuations of their stock).

I propose the following:

1) in all templates where 'Financial type' is used to refer to a contribution financial type we replace it with a smarty var $contributionFinancialTypeLabel
2) assign if from all php files where is is called ie
$smarty->assign('contributionFinancialTypeLabel', ts('Financial Type'));
3) from here we have options

• override in an extension
• override by setting

I'm inclined to the latter because I feel like we should migrate towards 'Contribution Type' being used due to the current confusion.

I worry that changing the label but keeping the options as the same financial types would confuse people. (I know this isn't what Eileen's directly proposing to do, but it's what the change is facilitating.) A couple of reasons why:

1. If I see an option called "contribution type", I'll expect to be able to change it on an admin form called "contribution types". Unless I knew the context of this and past changes, I wouldn't expect that "financial types" are the same.
2. I would expect that contribution types are similar to event types--and would therefore have little or no relationship to financial types

Instead, I feel it would make more sense to have contribution types be a whole separate thing, as the categorization of contributions (and what custom fields show up) won't always align directly with accounting decisions. I think a natural upgrade path would be to have the contribution types start out as the same options as the financial types, but you could add new ones of each separately.

• Custom data sets can specify a contribution type
• Contribution types have a default financial type--the workflow should remain about the same as it is currently.
• Events come with a contribution type, so the transactions on a simple registration would pick up the default financial type for that contribution type.
• On upgrade, all financial types get copied to contribution types, with the same values, and the default financial type for each contribution type is the financial type it came from

Or scratch all that....

We got talking about this in the office, and Mika wondered whether this was more complex than needed and it would really be better to just ditch financial type on the contribution:

• When there's a listing of contributions, the financial type could just say "mixed" if there are line items with different financial types.
• Custom data sets could appear/disappear based upon the line items' financial type(s)
• As discussed above, search and report filters would just use the financial type of the line item(s)

The thought is that the separation of fundraising categorization from accounting categorization occurs already between financial type and financial account. Adding a separate contribution type would be yet another layer, and it wouldn't add much that you can't already do with setting up your financial types.

Finally, in talking about this at the office, we came up with a few useful scenarios to think about:

• Someone makes a regular donation by check
• Someone donates an old printer plus a check. (Free IT Athens would require a cash donation if you brought a printer or CRT monitor because they're probably going straight to the recyclers.) You have a custom data set for donations of fixed assets.
• Someone leaves you part of their estate, which includes a car and a bunch of books. In addition to the fixed asset custom fields, you have a separate custom data set for vehicle donations to track the make, model, and VIN number.

In the latter two, it would be very useful to have the custom data driven by the line items rather than the contribution financial type, and in the simple scenario, it wouldn't hurt. We just keep coming back to the feeling that there's no need to have a contribution/financial type on the contribution when you can have it on the line items.

A bit of background: this problem is due to Dave Greenberg wanting backward compatibility from new Financial Type to old Contribution Type. IIRC he was reluctant to remove this field from civicrm_contribution, there were no problems when existing functionality based on Quick Price Sets were used since this too was backward compatible, and he thought it best for those who wanted to use complex price sets with multiple financial types to work on a solution later to their reporting needs (this may have been when we cutting scope after re-architecting how civiaccounts code would be merged back around 3.4 - 4.3 or so...can't quite remember).

The use of Financial Types in the UI for contribution pages and event pages is misleading to say the least. It serves to provide the default financial type for lower level configurations, but is not actually used for the accounting entries. Unfortunately, civicrm_contribution.financial_type_id is used in a number of reports. civicrm_financial_item.financial_account_id, civicrm_financial_trxn.from_financial_account_id and civicrm_financial_trxn.to_financial_account_id are the accounting entries. civicrm_line_item.financial_type_id should be accurate with respect to the financial types. But actual financial accounts for financial_items and related sales tax accounts for financial items are crystallized based on the configuration of the relationships between the financial_type and financial accounts at the time the transaction is recorded. In general, we shouldn't allow the system to give a different impression at one level compared to another with regard to financial reporting. It should be consistent up and down and backwards.

It is feasible to remove civicrm_contribution.financial_type_id from the schema. I think we should follow the suggestion from Eileen, that I would describe somewhat differently. We would implement a calculated multi-select value for civicrm_contribution.financial_type_id based on the financial types of line items at the time of the search or report being run. This multi-select value could be used for display, filtering, and with a bit of thought, grouping.

In addition, I think we need to refactor a number of our reports so that they correctly handle transactions where there are line items with different financial types. Instead of contribution as the lowest level, indivisible financial object, we need to recognize that line items are that lowest level. And on the payment side of things, instead of having a single status for each contribution, we need to split that up into the notion of payments each with their own status and refunds each with their own status, as we are now having partial payments and very soon, partial refunds, supported.

If people are okay with this approach, I'll undertake to spec out all of the ways that a calculated contribution financial type would be implemented, providing good backwards compatibility for UX. [Kevin Cristiano] has agreed to work through each report and develop a spec for how it can be refactored to work with line items by mid-November.

I guess I was trying to figure out how we could leap this by extension - we want new people to basically not see the value of the civicrm_contribution.financial_type_id field but to see a concatenation of the line items or whatever (I'm really thinking of screens like search results etc here) but we don't want to impose a big change on people - especially since we can't implement it quickly across all the various screens in all the nuances. If it's an opt-in / leap then we can get away with changing things a bit more 'as we can' but the problem is that our hooks are not great for doing that. However, if we make the way that field is represented in smarty really consistent throughout that gives us a path for changing through an extension - that pretty much requires us to change instances of

Contribution Type

to

{$financialTypeLabel}

And

ensure that references to financial type itself are really consistent.

Happen to run into this. While looking for another possible defect. Certainly would have made life easier for my adaptation. One thought, is that bringing in over some of Eileen's "line-item" reporting features into core might slowly evolve users to use this, and make future removal easier.

If I understand the original question correctly, it is already answered with an existing extension. nz.co.fuzion.extendedreport

We use price sets because we have several of donors that give to several different funds in the same donation. Civi handled everything with this in an AWESOME way up until about 4.7.19 and then it broke for recurring donations with a single line item (with multiple line items it still works).

You can do accounting detail reports with the way it is. https://civicrm.stackexchange.com/questions/16819/bookkeeping-report-that-includes-grouping-by-deposit-and-line-item-totals/18822#18822

@Andrew Hunt's "just ditch financial type on the contribution"  We use the contribution.financialz_type_id as a Master Financial Type. So we can search for Contributions, Event Fees, Tuition. We use the line_item.financial_type_id for our fund giving sorting.

My suggestion to the above issue is to integrate Extended Reports into Core. And come up with a different label for the two financial types. Keep Financial Type for Price Sets and Contribution Pages not using Price Sets. Come up with new name (Fund Type or ???) for Price Fields. This would help with some of the confusion of them being the same name but different use.

Carl Miller the issue is that the accounting entries take no notice of the contribution.financial_type as they are not part of any bookkeeping entries.

The issue you report on single line item recurring donations starting in 4.7.19 should be reported separately if it has not been already.

People who find the Extended Reports useful, and there are many of them, are not hindered by them being in an extension rather than core. As a project we have discussed and agreed to aim to add new functionality as much as possible through extensions rather than to core, and where feasible to refactor functionality OUT of core and INTO extensions. This will make the project more maintainable.

Under the hood in the code, 'Contribution Page not using Price Sets' actually use price sets, though the UI to configure them quickly is simpler. 

The terminology is tricky and confusing between financial type and financial account. I like your suggestion of potentially using Fund in here somewhere since it is used in the US for some revenue accounts. 

I still think it would be better to remove the contribution.financial_type field and wherever it is used have it replaced by the line item financial_type (if there is only one line item, or if all line items use the same financial type) or financial_types where line items use different ones. Search and reporting should allow finding contributions with a specific financial type in the list of one or more financial types. Either later or as an initial additional feature we could allow searches and reports to filter for contributions that had financial type 1 AND financial type 2, but I see that as a lower priority than supporting OR operations.  

Just a quick note because I know Carl Miller isn't the only one who uses financial types on the contribution to record something about the contribution as a whole, separate from the financial types for line items.  In this scenario, the contribution's financial type is just being used as a label, not for all of the accounting features that are tied to financial types.  A custom field (you could actually call it "Master Financial Type") would be better suited for this.

I agree with Andrew Hunt's suggestion about a custom Master Financial Type field.

Joe Murray, I understand what you are saying about keeping it as an Extension. It makes total sense with the way you described it. Keeps Civi more modular--people can add components to suit their needs. And I can see how this would be easier to maintain.

I have no argument about removing or leaving  contribution.financial_type as long as we still maintain the ability for folks to make one contribution that is divided among multiple funds. I have found it to be workable for our scenario as it was. But we do not use the accounting features so I understand why some people want this change. For accounting we just use the big picture details (the deposit total divided by fund account). We do not import each individual contribution detail in our accounting program.