Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2023-11-15T18:37:43Zhttps://lab.civicrm.org/dev/financial/-/issues/220With tax enabled Total Amount is confusing in online receipt and tax amount l...2023-11-15T18:37:43ZDaveDWith tax enabled Total Amount is confusing in online receipt and tax amount line is wrongIt used to show the amount before tax and the tax amount. But now it looks like this. There was $2 tax.
![untitled3](/uploads/2d19419c080ae6f6f009d1e6f7eff44d/untitled3.png)
This is the same as https://lab.civicrm.org/dev/financial/-/i...It used to show the amount before tax and the tax amount. But now it looks like this. There was $2 tax.
![untitled3](/uploads/2d19419c080ae6f6f009d1e6f7eff44d/untitled3.png)
This is the same as https://lab.civicrm.org/dev/financial/-/issues/206 just in the interim changes have caused the problem to shift.
Also the confirm and thankyou pages make no mention of the tax and there's now a php warning about a missing tax var on those pages.
![untitled7](/uploads/8fcb99238d074a7dd4a53ec000bf51b1/untitled7.png)
![untitled8](/uploads/ebb164e557d99a76bb0f90381b0525c9/untitled8.png)
One way to reproduce:
1. Turn on tax and invoicing. https://docs.civicrm.org/user/en/latest/contributions/sales-tax-and-vat/
* In my case I set up a non-deductible financial type called t-shirts and a corresponding sales tax account that has 5% tax.
2. Create a price set for it.
* There's one price field. I used type text/quantity. Field is required although that's not relevant just makes sense here. Financial type t-shirts.
3. Set up the dummy payment processor.
4. Create a contribution page with that processor and financial type t-shirts and use the price set. Set it to send a receipt.
5. Buy a t-shirt.5.68.0https://lab.civicrm.org/dev/financial/-/issues/216Financial Batches: remove the creation of activities for New/Edit2023-08-09T18:28:27ZbgmFinancial Batches: remove the creation of activities for New/EditI fell down a rabbit hole while testing the New Financial Batch form, and noticed that it creates an activity whenever a batch is created or edited. It also creates an activity when the batch is exported, but not when closed or deleted.
...I fell down a rabbit hole while testing the New Financial Batch form, and noticed that it creates an activity whenever a batch is created or edited. It also creates an activity when the batch is exported, but not when closed or deleted.
The "Create Batch" and "Edit Batch" activities do not seem useful to me. I would leave the "Export Accounting Batch" activity for now.
Any objections to removing?
(I'm creating this issue for visibility, but will send a PR that might be more clear)
cc @JoeMurray5.66.0https://lab.civicrm.org/dev/financial/-/issues/214Link to record payment from within participant change selections links it to ...2023-05-27T14:08:26ZDaveDLink to record payment from within participant change selections links it to wrong contribution, or crashes if that doesn't exist1. Register an event participant for a paid event.
2. In the record payment section of the registration, change the amount to less than the total so it's just a partial payment.
3. Save.
4. View/edit the participant record. Note the id i...1. Register an event participant for a paid event.
2. In the record payment section of the registration, change the amount to less than the total so it's just a partial payment.
3. Save.
4. View/edit the participant record. Note the id in the url.
5. Click Change Selections.
6. Click View Payments.
7. Click Record Payment. Note the id in the url. It's the participant id not the contribution id. If a contribution with that id doesn't exist then at this point it crashes.
8. If it does exist, note now at this point the balance owed displayed may be incorrect because it's from an unrelated contribution.
9. Fill it out and save.
10. Note it takes you to a different contact and has applied the payment to the unrelated contribution.
This is only from the Change Selections section. The other Record Payment link found at the bottom of the participant record when you expand the triangle is correct.
Can reproduce on dmaster. I doubt this is recent.5.63.0https://lab.civicrm.org/dev/financial/-/issues/213Imported has completed successfully, but that's not true2023-01-15T21:04:15ZKarinGImported has completed successfully, but that's not trueCiviCRM 5.56.2
Contributions -> Import via UI ->
Client also noted (and I confirmed) that Contact Type appears to be no longer relevant/required.
Previous behaviour: CiviCRM generates an import_error file noting the contributions which...CiviCRM 5.56.2
Contributions -> Import via UI ->
Client also noted (and I confirmed) that Contact Type appears to be no longer relevant/required.
Previous behaviour: CiviCRM generates an import_error file noting the contributions which could not be imported and the reason - in this case Contact ID does not exist.
Screenshots (really awesome client report):
![image](/uploads/e569fd7fac5fb380e64318731aab5925/image.png)
![image](/uploads/713ee8a4cb0112b052a82fac53fe98e7/image.png)
![image](/uploads/736818ab47519bee7944120f5d577097/image.png)
![image](/uploads/1162ab9a29299db21546bf2e295a3d22/image.png)
![image](/uploads/9e3a4cf72ead03397d48542c24baa751/image.png)
![image](/uploads/60a57e3362cadf8710e9a194331a4159/image.png)5.57.0https://lab.civicrm.org/dev/financial/-/issues/210Changing contribution financial type from non-deductible to deductible does n...2023-07-05T23:48:38ZlarsssandergreenChanging contribution financial type from non-deductible to deductible does not change non-deductible amount, resulting in inability to issue tax receiptsSuppose someone enters a donation with an event fee financial type by mistake. The non-deductible amount is set to the full amount of the contribution. If they then change the financial type to a donation type, the non-deductible amount ...Suppose someone enters a donation with an event fee financial type by mistake. The non-deductible amount is set to the full amount of the contribution. If they then change the financial type to a donation type, the non-deductible amount remains the full amount of the contribution, so no tax receipt can be issued for the donation. Since most people probably don't use non-deductible amount regularly, if at all, they aren't likely to check this. Not a big deal if you then try to issue a tax receipt for the single contribution as it will be obvious that something is wrong (though perhaps frustrating because it isn't clear what), but if you are issuing them in bulk, you may not notice this at all, resulting in a donor not getting their tax receipt — a pretty bad outcome from a donor stewardship perspective.
We probably don't want to change non-deductible amounts in the background for existing contributions, but how about a warning that pops up when the financial type is changed from non-deductible to deductible, advising the user to check the non-deductible amount? Perhaps this wouldn't matter to some users, who don't care at all about deductible versus non-deductible, but this does seem worth warning about because it can produce unexpected results in the background.
Something like:
```You've changed the financial type for this $NNN contribution from non-tax deductible to tax deductible, but the non-deductible amount of $NNN has not been changed. This could prevent a tax receipt from being issued. You may want to edit the non-deductible amount.```https://lab.civicrm.org/dev/financial/-/issues/209Disabled Financial Types are listed when creating a Price Field2022-11-02T00:34:40ZpetednzDisabled Financial Types are listed when creating a Price FieldReplicated on dmaster.
1/ create a new Financial Type - set it as disabled.
2/ create new price set / field and note that the disabled Type is showing
3/ try to save - spinny spin spin if using pop ups - if not using pop-up get
4/ Finan...Replicated on dmaster.
1/ create a new Financial Type - set it as disabled.
2/ create new price set / field and note that the disabled Type is showing
3/ try to save - spinny spin spin if using pop ups - if not using pop-up get
4/ Financial Type for Price Field Option is either disabled or does not exist
is there a logic for showing disabled fields in this interface - can't personally think of one esp the pain of users sitting for 10 mins waiting for things to save.
Possibly related to https://lab.civicrm.org/dev/financial/-/issues/198 though that seems the other end of the problem, ie a Price Field is using a Fin Type that has since been set to be disabled5.56.0colemanwcolemanwhttps://lab.civicrm.org/dev/financial/-/issues/195Using the line item editor on a contribution template does not update the mat...2022-07-07T07:51:33ZAlanDixonUsing the line item editor on a contribution template does not update the matching recurring contribution total amountThis is a follow up issue to https://lab.civicrm.org/dev/financial/-/issues/194
as per: https://lab.civicrm.org/dev/financial/-/issues/194#note_75215
It's a similar issue to this one: https://github.com/civicrm/civicrm-core/pull/21473
...This is a follow up issue to https://lab.civicrm.org/dev/financial/-/issues/194
as per: https://lab.civicrm.org/dev/financial/-/issues/194#note_75215
It's a similar issue to this one: https://github.com/civicrm/civicrm-core/pull/21473
Note that if you go back and just save the contribution template, then the issue can be worked around as an administrator!
i.e. part of the problem is that the line item editor is assuming it's living in an isolated world that it knows everything instead of behaving like a responsible citizen.https://lab.civicrm.org/dev/financial/-/issues/193After import of contribution: User deprecated function: Deprecated function C...2022-06-10T09:05:04ZTobias KrauseAfter import of contribution: User deprecated function: Deprecated function CRM_Core_OptionGroup::getValueWe get the above warning after the import of contributions on CiviCRM 5.48.2 with Drupal 9. The full message is:
`User deprecated function: Deprecated function CRM_Core_OptionGroup::getValue, use CRM_Core_PseudoConstant::getKey. in CRM_...We get the above warning after the import of contributions on CiviCRM 5.48.2 with Drupal 9. The full message is:
`User deprecated function: Deprecated function CRM_Core_OptionGroup::getValue, use CRM_Core_PseudoConstant::getKey. in CRM_Core_Error::deprecatedFunctionWarning() (line 1043 of /vendor/civicrm/civicrm-core/CRM/Core/Error.php).`5.51.0https://lab.civicrm.org/dev/financial/-/issues/192CiviCRM crashes when I select ZMK as default currency2022-09-09T13:10:06ZmitoworksCiviCRM crashes when I select ZMK as default currencyA clean install of CiviCRM on Wordpress crashes whenever I select ZMK as default currency. My installation details are:
> WordPress version 5.9.2
> Current theme: Twenty Twenty-Two (version 1.1)
> Current plugin: CiviCRM (version 5.4...A clean install of CiviCRM on Wordpress crashes whenever I select ZMK as default currency. My installation details are:
> WordPress version 5.9.2
> Current theme: Twenty Twenty-Two (version 1.1)
> Current plugin: CiviCRM (version 5.47.2)
> PHP version 8.0.16
```
Error Details
=============
An error of type E_ERROR was caused in line 19 of the file /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php. Error message: Uncaught Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: ZMK in /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php:19
Stack trace:
#0 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/ISOCurrencyProvider.php(120): Brick\Money\Exception\UnknownCurrencyException::unknownCurrency()
#1 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Currency.php(91): Brick\Money\ISOCurrencyProvider->getCurrency()
#2 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Money.php(189): Brick\Money\Currency::of()
#3 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Utils/Money.php(209): Brick\Money\Money::of()
#4 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Utils/Money.php(88): CRM_Utils_Money::formatUSLocaleNumericRounded()
#5 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources/Common.php(219): CRM_Utils_Money::format()
#6 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources/Common.php(128): CRM_Core_Resources_Common::coreResourceList()
#7 /home/monkey/public_html/civic/wp-content/uploads/civicrm/templates_c/CachedCiviContainer.a02b080bd0d8fdf7053d123f1aecc5d2.php(807): CRM_Core_Resources_Common::createFullBundle()
#8 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/symfony/dependency-injection/Container.php(306): CachedCiviContainer->getBundle_CoreResourcesService()
#9 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/Civi.php(174): Symfony\Component\DependencyInjection\Container->get()
#10 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources.php(214): Civi::service()
#11 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources.php(382): CRM_Core_Resources->addBundle()
#12 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm.php(1087): CRM_Core_Resources->addCoreResources()
#13 /home/monkey/public_html/civic/wp-content/plugins/civicrm/includes/civicrm.admin.php(761): CiviCRM_For_WordPress->add_core_resources()
#14 /home/monkey/public_html/civic/wp-includes/class-wp-hook.php(307): CiviCRM_For_WordPress_Admin->admin_page_load()
#15 /home/monkey/public_html/civic/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#16 /home/monkey/public_html/civic/wp-includes/plugin.php(474): WP_Hook->do_action()
#17 /home/monkey/public_html/civic/wp-admin/admin.php(237): do_action()
#18 {main}
thrown
```
After this, I can't do anything else under the CiviCRM menu
It looks like a change in currency to ZMW in 2013 is causing the issue.5.54.0https://lab.civicrm.org/dev/financial/-/issues/184Using GHC as a default currency causes a fatal error with Brick/Money2022-08-31T15:25:46ZbgmUsing GHC as a default currency causes a fatal error with Brick/MoneyTo reproduce:
* Go to dmaster
* Admin > Localisation > Language etc
* Set the default currency to "GHC"
Result:
> Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: GHC in Brick\Money\Exception\UnknownCurrencyExcep...To reproduce:
* Go to dmaster
* Admin > Localisation > Language etc
* Set the default currency to "GHC"
Result:
> Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: GHC in Brick\Money\Exception\UnknownCurrencyException::unknownCurrency() (line 19 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php).
And CiviCRM is ironically bricked, i.e. CiviCRM will systematically fatal.
The ISO code for Ghana is "GHS", which is what Brick/Money uses.
https://en.wikipedia.org/wiki/Ghanaian_cedi5.45.0https://lab.civicrm.org/dev/financial/-/issues/183Order API is not Order AI2021-09-06T19:14:49ZKarinGOrder API is not Order AI[copied notes from Mattermost]
Towards 'making this sane' and could be implemented immediately -> for example - one would be to immediately start returning ->
````a notice -> 'warning: incompatible set of input params - Order API can ...[copied notes from Mattermost]
Towards 'making this sane' and could be implemented immediately -> for example - one would be to immediately start returning ->
````a notice -> 'warning: incompatible set of input params - Order API can not create coherent line-item(s)'.````
When being presented with incompatible data -> e.g. if
total_amount = 10;
tax_amount = 0.25;
financial_type_id = 1;
That's an impossible set of input params. Yes - they are still being handled right now - but results will be unpredictable b/c it is simply impossible to create a co-herent line_item with those input params.
I have some more notes in 21187 - will park them in my own atrium for now. Key one is that one 👆
Another one could be that if presented with line_items and a total_amount at the Contribution level - then that all better be adding up or else ->
````a notice -> 'warning: incompatible set of input params - Order API can not create coherent line-item(s)'.````
At this stage the API can still attempt - but alerting people would be a first step towards to no longer accept incoherent input. Order API is not Order AI :-)https://lab.civicrm.org/dev/financial/-/issues/1805.41 rc - order api stores totals incorrectly when line items not passed in2021-08-27T05:28:36ZKarinG5.41 rc - order api stores totals incorrectly when line items not passed inReproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!Reproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!5.41.0https://lab.civicrm.org/dev/financial/-/issues/171False positive message about missing INTL PHP extension on membership type form2021-03-31T23:26:43ZDaveDFalse positive message about missing INTL PHP extension on membership type formHappens on dmaster.demo too so it's not windows or anything weird.
1. Click add membership type.
2. Click cancel. It happens if you fill it out too but this is quicker and is enough to see it.
There might be a couple things here.
One ...Happens on dmaster.demo too so it's not windows or anything weird.
1. Click add membership type.
2. Click cancel. It happens if you fill it out too but this is quicker and is enough to see it.
There might be a couple things here.
One is that the message is tied partly to whether the value is numeric, which doesn't really have anything to do with the missing php extension.
The second is that for whatever reason the $amount value is being passed in as `<input size="6" maxlength="14" name="minimum_fee" type="text" id="minimum_fee" class="six crm-form-text" />`. I'm not sure yet what the mismatch is there.
It's kind of a regression because of the numeric part, but the form value might be old.5.37.0https://lab.civicrm.org/dev/financial/-/issues/170Minor buttonrama issue with Cancel button after exporting financial batch2021-03-19T19:29:58ZDaveDMinor buttonrama issue with Cancel button after exporting financial batchOn the non-modal screen after you choose the export format and export the batch, what's supposed to happen is the Cancel button text should change to say "Done". Since it's no longer an `<input>` element the current method used to do tha...On the non-modal screen after you choose the export format and export the batch, what's supposed to happen is the Cancel button text should change to say "Done". Since it's no longer an `<input>` element the current method used to do that doesn't work anymore.
It's this line in templates/CRM/Financial/Form/Export.tpl:
`$('#_qf_Export_cancel').val('{/literal}{ts}Done{/ts}{literal}');`
It's a little tricky with the button because you need to replace the text without also replacing the `<i>` element which is inside the button, so you can't just change `val` to `text`. This might do it as long as the translation doesn't have special chars in it, but that would have been a problem before too:
`$('#_qf_Export_cancel').html($('#_qf_Export_cancel').html().replace('{/literal}{ts}Cancel{/ts}{literal}', '{/literal}{ts}Done{/ts}{literal}'));`
Or since the icon shouldn't be an X anymore anyway, maybe it's ok to just use text().5.37.0https://lab.civicrm.org/dev/financial/-/issues/169"Export" from Batch Edit screen no longer works on D82021-03-11T19:14:54ZJonGold"Export" from Batch Edit screen no longer works on D8#### To replicate on d8master:
* Click **Contributions » Accounting Batches » New Batch**.
* Click **Save**.
* Assign at least one transaction to the batch.
* Go to **Contributions » Accounting Batches » Open Batches**.
* Attempt to expo...#### To replicate on d8master:
* Click **Contributions » Accounting Batches » New Batch**.
* Click **Save**.
* Assign at least one transaction to the batch.
* Go to **Contributions » Accounting Batches » Open Batches**.
* Attempt to export, either from the *Actions* menu, or by clicking **More » Export**.
* A pop-up will appear allowing you to select the export format. Click **OK**
#### Expected result
Batch export proceeds.
#### Actual result
Nada.
The Dev console shows the error - "jquery.redirect.min.js" can't be found. This has to do with how the Resource URLs are split into `core` and `packages` inside `<webroot>/libraries/civicrm`. It's impossible to call `jquery.redirect.min.js`.
Moreover, this UI has always been a bit flaky. If you click **Transactions** on the *Open Batches* screen, the **Export** button will bring you to the next screen. The two methods I outlined above bring up an extra modal dialog, the options of which are repeated on the next screen. So rather than fix the bug, I think we should remove the modal altogether.5.37.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/166Account IIF Export Amount Format improper2021-03-01T02:27:36ZLoganBearAccount IIF Export Amount Format improperBatches created before 5.34 export simple value amounts:
```
12.00
-12.00
```
Batches after the upgrade to 5.34 adds a dollar sign to the amount:
```
$12.00
-$12.00
```
I can't get these files imported without loading them into Excel...Batches created before 5.34 export simple value amounts:
```
12.00
-12.00
```
Batches after the upgrade to 5.34 adds a dollar sign to the amount:
```
$12.00
-$12.00
```
I can't get these files imported without loading them into Excel and changing the formatting.5.35.0https://lab.civicrm.org/dev/financial/-/issues/163Fully remove contributionTypeID2020-12-23T11:07:08ZeileenFully remove contributionTypeIDThere are few remaining references in the code to very-old-legacy contributionTypeID
This seems to be passed out to payment processors and assigned to the templates in some cases
I feel like we could remove these in 5.34 and simply com...There are few remaining references in the code to very-old-legacy contributionTypeID
This seems to be passed out to payment processors and assigned to the templates in some cases
I feel like we could remove these in 5.34 and simply communicate the fact via the dev-digest and release notes.5.34.0https://lab.civicrm.org/dev/financial/-/issues/162Simplify decision as to whether to use a pdf on emails2023-09-05T04:20:10ZeileenSimplify decision as to whether to use a pdf on emailsCurrently the code that determines whether to attach a pdf for membership emails only attaches it as a pdf if the tax amount is non-zero
This seems both confusing and pointless - the proposal here is to send as a pdf as long as
1) is_...Currently the code that determines whether to attach a pdf for membership emails only attaches it as a pdf if the tax amount is non-zero
This seems both confusing and pointless - the proposal here is to send as a pdf as long as
1) is_email_pdf is true and
2) invoicing is enabled
I feel like 1 and 2 could be separated but they are currently linked so I would suggest any proposals to change that are a follow uphttps://lab.civicrm.org/dev/financial/-/issues/160Allocation of "fee amount" is incorrect if fee is added after contribution is...2020-12-11T17:11:37ZJonGoldAllocation of "fee amount" is incorrect if fee is added after contribution is created#### Steps to replicate:
* Go to **Administer » CiviContribute » Payment Methods**. Note the default payment method.
* Also note a payment method that doesn't have the same financial account.
On a clean install, "Check" is the default ...#### Steps to replicate:
* Go to **Administer » CiviContribute » Payment Methods**. Note the default payment method.
* Also note a payment method that doesn't have the same financial account.
On a clean install, "Check" is the default method, and "Credit Card" has a different financial account. I'll use those in my example below.
* Create a contribution with payment method of credit card. Enter a fee amount, save, and note the contribution ID.
* Run the following SQL to view the financial account IDs of the transaction (my contribution ID is 96 below):
```sql
mysql> SELECT entity_id, amount, from_financial_account_id, to_financial_account_id, total_amount, fee_amount FROM civicrm_entity_financial_trxn ceft JOIN civicrm_financial_trxn cft ON ceft.financial_trxn_id = cft.id WHERE entity_table = 'civicrm_contribution' AND entity_id = 96;
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| entity_id | amount | from_financial_account_id | to_financial_account_id | total_amount | fee_amount |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| 96 | 18.00 | NULL | 12 | 18.00 | 4.00 |
| 96 | 4.00 | 12 | 5 | 4.00 | 0.00 |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
```
* The above is correct - the `from_financial_account_id` of the fee trxn matches the `to_financial_account_id` of the main trxn.
* Create a second contribution with payment method of credit card, but do *not* enter the fee.
* Save the contribution, then immediately edit it to add the fee.
* When you run the SQL above, it will look like this:
```sql
mysql> SELECT entity_id, amount, from_financial_account_id, to_financial_account_id, total_amount, fee_amount FROM civicrm_entity_financial_trxn ceft JOIN civicrm_financial_trxn cft ON ceft.financial_trxn_id = cft.id WHERE entity_table = 'civicrm_contribution' AND entity_id = 95;
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| entity_id | amount | from_financial_account_id | to_financial_account_id | total_amount | fee_amount |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| 95 | 11.00 | NULL | 12 | 11.00 | 0.00 |
| 95 | 3.00 | 6 | 5 | 3.00 | 0.00 |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
```
Note that the fee's `from_financial_account_id` no longer matches the account of the main transaction - it matches the financial account ID of the **default** payment method, not the payment method of this contribution.
**tl;dr:** The financial transaction for a fee amount is calculated incorrectly if you edit the fee after the contribution is saved.
I haven't written a patch/test yet, but I intend to in the next day or two.5.34.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/159Line items are added from default price set on recurring contributions for fi...2022-12-14T00:35:14ZFrancis (Agileware)Line items are added from default price set on recurring contributions for financial types with tax accounts.# Steps to reproduce, verified on dmaster.demo.civicrm.org
1. Create a Membership type with required autorenewal
2. Enable Tax & Invoicing
3. Create a Sales Tax account, at any rate, and assign it to the "Member Dues" Financial type.
4....# Steps to reproduce, verified on dmaster.demo.civicrm.org
1. Create a Membership type with required autorenewal
2. Enable Tax & Invoicing
3. Create a Sales Tax account, at any rate, and assign it to the "Member Dues" Financial type.
4. Configure a Contribution Page to sign up for the membership, using the "Member Dues" Financial type.
5. Sign up for a membership using the Contribution page.
6. Using the created recurring contribution id, call the Contribution.repeattransaction API to simulate the membership autorenewal like a payment processor supporting recurring contributions
7. Inspect the resulting contribution records using the Order.get API
# Expected Results
Two orders that are identical apart from dates and IDs
# Actual Results
The second order has two line items. The second line item will be for the price field in the default price set (field 1 / set 1 unless you've somehow changed it), and will be for the same amount as the total of the contribution.
On additional attempts to repeat the transaction, the system crashes due to a DB constraint violation and *rolls back the database transaction, losing the records of any contributions processed so far.*
# Why does this happen?
When `CRM_Contribute_BAO_Contribution::add` calls `CRM_Contribute_BAO_Contribution::checkTaxAmount`, this method checks if the financial type has tax applied and calls `CRM_Price_BAO_LineItem::getLineItemArray` if so, regardless of whether there are any line items already.
# Proposed Solution
Move the calls to `CRM_Price_BAO_LineItem::getLineItemArray` out of `CRM_Contribute_BAO_Contribution::checkTaxAmount` and into `CRM_Contribute_BAO_Contribution::add`, and **only** call it if there's no line_item array present already. See discussion at https://chat.civicrm.org/civicrm/pl/9iuqyx9fp3dexnupuxfefsj4ke
Agileware Ref: CIVICRM-16175.34.0