Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-21003

Support multiple payments on contribution.payment_instrument_id and contribution.financial_type_id

    Details

    • Versioning Impact:
      Major (incompatible API change)
    • Documentation Required?:
      None
    • Funding Source:
      Needs Funding
    • Verified?:
      No

      Description

      Historically there was only one payment per contribution, so the schema only had a single field for payment instrument on the contribution object. Also historically, there was only financial type (previously called contribution type) per contribution, but with multiple line items more than one can be configured. Although the payment information and line item information is correctly reported at a detail level for accounting purposes, it is not presented properly for reporting and search and certain view and edit form operations. Backward compatibility concerns for simple use cases as well as scope concerns took precedence over presenting complete and correct information in all contexts.

      We should use the same pattern to address the erroneous display, search, and reporting on these two fields.

      At a high level we want to have these fields display all of the relevant details for the payments and line items. So we will change each field from an int lookup to varchar(255) in tarball and on upgrade, and put a concatenation of the labels for multiple values into the text field, with oldest first and most recent last. Upgrade will need to fill in the concatenated value for all records.

      We will need to grep for all places in the codebase affected by this change. Here are some to start:

      1. Make the fields view only / frozen on contribution edit form.
      2. Check that the field displays nicely (or at least adequately) with multiple values wherever it appears.
      3. Make sure on line item add, edit, cancel, delete and payment add, edit (and cancel and delete when they are supported) that on save the underlying contribution tab, etc gets a refresh.
      4. On searches and reports, the widgets allow multiple values to be selected. Semantically, we want a match to be any selected value against any value present for a contribution, NOT that the list of the selected value(s) has to match exactly with the value(s) present for a contribution. Please consider refactoring search and report queries to stop using the civicrm_contribution table for these fields and instead start to use the civicrm_financial_trxn.payment_instrument_id and civicrm_line_item.financial_type_id fields.

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                monish.deb Monish Deb
                Reporter:
                joemurray Joe Murray
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: