Editing contribution created an additional line item instead of editing the old.

[flug]

9. Now (still in contact screen under the contributions tab) click 'edit' that contribution.
10.  Don't change anything, just click 'save'.
11. Now re-check the line_item table and it shows qty=1, unit_price=2.00, line_total=2.00

OK, here is a clue I believe: It has to do with the comma in 2,000 (and 1,000, 5,000, 10,000, etc).

FYI I'm set up as the U.S. system for numbers, with ',' as the thousands delimiter, '.' as the cents delimiter, and USD as the currency.

So when you edit the contribution, it automatically brings up the amounts with the ',' thousands delimiter.  So "1,000", "2,000", "5,000", "20,000" etc.

When you save the form with that comma in the amounts field, the contribution is saved correctly whereas the line item isn't.  So there must be some processing step or formatting step or setting that is missed when the amount is saved to line_item.

The comma is the cause of the problem, not re-editing the field per se.  Re-editing the contribution only exposes the problem because it happens to automatically include the comma delimiter for thousands.

So you can get at the bug in a more direct method like this:

1. Go to the contact page
2. Click on the 'contribution' tab
3. Click 'record contribution (cash, check, eft . . . )
4. Select our first contribution type in the list (we have 10-12 in the list), USD, "1,000".  Make sure to include the comma. "Choose price set" is an option but we don't select it.
5. Paid by check & enter check number 1000
6. Leave everything else as default.
7. Click save.
8. Check line_item table, the row in civicrm_line_item for this contribution (entity_id) lists qty=1, unit_price=1000.00, line_total=1.00.


In step 4 you can use any number with a comma, like 2,000, 3,000, 10,000, 5,255, etc. and you'll get the same type of error.

[Dave Greenberg]

Tried these exact steps on my local 4.2 install - but not seeing the error. My line_item unit_price and line_total both have the expected values (e.g. 5000.00 when 5,000 entered on contribution form).

[flug]

Dave,

Thanks for investigating.  Now that I realized the problem is the comma I searched on JIRA and found this, which appears to be the cause of the problem and also has the solution:

 http://issues.civicrm.org/jira/browse/CRM-10974

Just in case anyone else is having this problem the fix seems to be adding these lines in CRM/Price/BAO/LineItem.php, around line 204:


                204         // lets clean the price in case it is not yet cleant
                205         // CRM-10974
                206         $price = CRM_Utils_Rule::cleanMoney($price);
                207   

See https://fisheye2.atlassian.com/browse/CiviCRM/branches/v4.2/CRM/Price/BAO/LineItem.php?r2=42734&r1=42579

[flug]

OK, looking further, CRM-10974 solved the problem of 2,000 - > 2 on initial entry of the contribution.

However, the problem still crops up on editing the contribution.  2,000 appears and when saved, it turns to 2.

The problem appears to be in function postProcess() of CRM/Contribute/Form/Contribution.php, starting around line 1165.

On initial submission of the form, even without selecting a price set, it has a price set ID, which corresponds to the default price set ID for contributions.  (It is ID 15 in my case, but that probably varies by system.)   Since it has a valid price set ID it is processed by the "if ($priceSetId) {" code section which sends the values through CRM_Price_BAO_Set::processAmount, which eventually calls CRM_Price_BAO_LineItem->format, where the cleanMoney() fix from CRM-10974 is.

However . . . on re-editing the contribution it is submitted WITHOUT a price set ID and so it goes through a different bit of code in CRM_Contribute_Form_Contribution->postProcess() that never sends $submittedValues['total_amount'] through cleanMoney() to remove the commas.

There are a lot of different issues there and I'm not sure why the contribution doesn't have a price set when it is re-edited or why CRM_Price_BAO_Set::processAmount is never called in case there is no price set.  (It seems to me the re-edited contribution should have the same default price set it did on initial entry, and CRM_Price_BAO_Set::processAmount should be called to clean everything up & get it in the right format regardless of price set or no, but I haven't looked at all the code to see if there are any nasty side effects of either of those actions that might cause problems.)

Also in case there is no price_set, the $submittedValues['total_amount'] is sent to $participantParams['fee_amount'] without ever being cleaned (see line 1172 here) & I'm guessing that will cause problems in cases where that value includes a comma.  (A problem that has never been exposed only because no one has events where the entry fee is in the thousands?).

At any rate, this fix cleans all that up--though--I'm not sure if it is the best or right way to fix it:

   

Code: [Select]

if (!$priceSetId && CRM_Utils_Array::value('total_amount', $submittedValues) && $this->_id) {

++  //cleaning the total amount to solve the 2,000 - > 2 problem
++  $submittedValues['total_amount'] = CRM_Utils_Rule::cleanMoney($submittedValues['total_amount']);

This goes in CRM/Contribute/Form/Contribution.php around line 1166.

If someone could confirm whether or not this problem still happens in the latest version or on the demo cite I'll submit a bug report (I'm still on 4.2.2).  Note that this bug happens only when you RE-edit a contribution with a comma in the total amount and you'll have to check in the line_item table to see if the amount is saved incorrectly.

[Dave Greenberg]

I'm still not able to replicate this bug on my 4.2 site. :-(

However, examining the code when I save a contribution - IF it's associated with a participant event registration - this line:

CRM_Event_BAO_Participant::add($participantParams);

... passes 'fee_amount' to the add method. But that method seems to be expecting 'participant_fee_amount' (which is passed thru cleanMoney if present).

I've filed an issue for this at:
http://issues.civicrm.org/jira/browse/CRM-11584

[Kurund Jalmi]

This may be related to this bug: http://issues.civicrm.org/jira/browse/CRM-11024, it was fixed in 4.2.3

Can you try this patch: https://fisheye2.atlassian.com/changelog/CiviCRM?cs=42849

If possible I would recommend upgrading to latest stable 4.2.7

Hth
Kurund

[Dave Greenberg]

Kurund fixed an apparent typo in CRM/Event/BAO/Participant.php add() which was preventing 'fee_amount' from being passed through cleanMoney function. I was still not able to replicate the behavior reported on the forum post prior to this fix - but it is clear the fix was needed.

This fix will be part of 4.2.8 - but your can grab a simple patch from here to see if it helps in your environment:
https://fisheye2.atlassian.com/viewrep/CiviCRM/branches/v4.2/CRM/Event/BAO/Participant.php?r1=41385&r2=44668