Tax is reapplied when editing a contribution associated with a membership or participant entity unless the status is changed.

Follows from CRM-16833

A client is having issues where trying to edit a membership contribution, eg. to record a cheque number, is causing tax to be reapplied to (the non-editable) amount.
Further testing was needed to file an issue, this has since been done by the client, showing that the effect is constrained to non-priceset membership and participant contributions:

Scenario (steps to reproduce)

1. Enable Sales Tax with amounts shown inclusive of tax.
2. Create Sales Tax liability account ('GST') with 10% rate.
3. Create taxable financial types (membership fee, event fee) with GST referenced as Sales Tax account.
4. Create a new membership or event registration, recording a contribution with default minimum membership fee, or a selected fee from the event record respectively (no price-set used), status of 'Completed', payment instrument 'Cash'. GST will be calculated and a tax-inclusive total amount displayed and recorded correctly in the database.
5. Edit the contribution record and optionally make changes to the record (not the amount) and save it (note: you do not need to make changes for the error to occur).

Result

The contribution record is updated incorrectly to display a new total amount, being the original (tax-inclusive) amount plus a further tax amount calculated by multiplying the original amount by the sales tax rate (i.e. original tax-inclusive total + (tax rate * original tax- inclusive amount)).

The non deductible amount, total amount, and tax amount fields in the contribution table are all updated with new (invalid) amounts.

The value of the (invalid) new tax amount (being the sales tax rate multiplied by the original tax-inclusive total amount) is written in error to each of the corresponding income and tax accounts as new financial items in the financial items table and entity financial transactions table.

A new (invalid) financial transaction for this amount is also written in the financial transactions table.

The corresponding line item is also updated with the new (invalid) unit price and tax amounts in the line items table.
Tables affected, with invalid data:

• civicrm_contribution
• civicrm_entity_financial_trxn
• civicrm_financial_item
• civicrm_financial_trxn
• civicrm_line_item

Testing was performed on a production database running CiviCRM 4.6.9 under Drupal 7.38 with MySQL 5.1.73 and PHP 5.3.3.

The full text they sent including an example and their conclusions is attached along with a spreadsheet with detailed test results for the following use cases:

Contribution Only
Contribution Only + Priceset
Contribution Only + Tax (Contains possibly related issue with Cancelling contributions)
Contribution Only + Tax + Priceset
Membership
Membership + Tax
Membership + Tax + Priceset
Event (Participant) + Tax
Event + Tax + Priceset

As mentioned in the previous ticket, I suspect there may be an issue with the check for a component line 1114 in CRM/Contribute/Form/Contribution.php:

if (!CRM_Utils_Array::value('membership', $componentDetails) || !CRM_Utils_Array::value('participant', $componentDetails))

This looks like a logic error as to fail it requires both a membership and participant component to be present on the contribution, which as far as I can see renders the condition a no-op and goes on to check the contribution status is being updated.

I have the impression conditions should be something along the lines of:

• Is this an UPDATE action, AND
  • is there a membership component, OR
  • is there a participant component

And the actual content of the update should be ignored as there is no opportunity to change the total amount.