Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2024-02-27T01:17:44Zhttps://lab.civicrm.org/dev/financial/-/issues/154Sales Tax not added to total when memberships include donations that are sepa...2024-02-27T01:17:44ZeileenSales Tax not added to total when memberships include donations that are separate transactionshttps://civicrm.stackexchange.com/questions/37923/sales-tax-not-added-to-total-when-memberships-include-donations-that-are-separathttps://civicrm.stackexchange.com/questions/37923/sales-tax-not-added-to-total-when-memberships-include-donations-that-are-separathttps://lab.civicrm.org/dev/financial/-/issues/51Proposal: "Administer CiviContribute" and "Administer CiviMail" permissions.2024-01-29T10:05:24ZJonGoldProposal: "Administer CiviContribute" and "Administer CiviMail" permissions.Over the years, we've added permissions such that no menu option outside of the "Administer" menu needs the "Administer CiviCRM" permission. There's a valid use case for allowing a fundraising staffer to administer contribution pages wi...Over the years, we've added permissions such that no menu option outside of the "Administer" menu needs the "Administer CiviCRM" permission. There's a valid use case for allowing a fundraising staffer to administer contribution pages without giving them access to administer all of CiviCRM, particularly in a multi-site configuration. Likewise, a communications staffer shouldn't need administrative permissions to edit headers/footers.
I ran the following SQL to identify menu items outside of the Administer menu that require Administer CiviCRM (`110` is the id for the "Administer CiviCRM" menu):
```sql
SELECT label
FROM civicrm_navigation WHERE NOT (
parent_id = 110
OR parent_id IN (SELECT id from civicrm_navigation WHERE parent_id = 110)
OR parent_id IN (SELECT id from civicrm_navigation WHERE parent_id IN (select id from civicrm_navigation WHERE parent_id = 110))
)
AND permission LIKE '%administer CiviCRM%';
```
This yields:
```
+------------------------------------------+
| label |
+------------------------------------------+
| New Contribution Page |
| Manage Contribution Pages |
| Personal Campaign Pages |
| Premiums (Thank-you Gifts) |
| New Price Set |
| Manage Price Sets |
| Personal Campaign Pages |
| Headers, Footers, and Automated Messages |
| From Email Addresses |
| New Price Set |
| Manage Price Sets |
| Developer |
| Api Explorer v3 |
| Developer Docs |
| Contact Reports |
| Api Explorer v4 |
+------------------------------------------+
```
The **Support » Developer** items are fine as-is.
"New Contribution Page", "Manage Contribution Pages", "Personal Campaign Pages", "Premiums", "New Price Set", and "Manage Price Sets" should all be granted under "Administer CiviContribute". "Headers, Footers and Automated Messages" and "From Email Addresses" should be granted with "Administer CiviCRM".
The only question I have is how to deal with PCPs and price sets being applicable to both events and contributions. Rather than make things overly complicated, perhaps "Administer CiviContribute" should be "Administer online payment pages" instead.
If this gets approval, I can submit the work.https://lab.civicrm.org/dev/financial/-/issues/221Contribution date no longer has a time on the form2023-11-21T03:45:45ZDaveDContribution date no longer has a time on the formhttps://chat.civicrm.org/civicrm/pl/sgxqjrxq6pyaxftxftwtexf56a
The field itself still stores a time, but it's the "current" time which may or may not make sense.
If I remove this line it comes back: https://github.com/civicrm/civicrm-c...https://chat.civicrm.org/civicrm/pl/sgxqjrxq6pyaxftxftwtexf56a
The field itself still stores a time, but it's the "current" time which may or may not make sense.
If I remove this line it comes back: https://github.com/civicrm/civicrm-core/blob/9eaef13ef15da8bac6b73148d570fd989529789d/CRM/Utils/Date.php#L1990
Seems to be from https://github.com/civicrm/civicrm-core/pull/27003, so works in 5.65 but not 5.66.
Also receipt date, so it probably affects any date field that isn't somehow specified as TIMESTAMP. I'm not sure where it gets that "metadata" and whether datetime and timestamp here mean the same thing as they do for db fields.5.67.2https://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/206"Amount before tax" is wrong on online contribution receipt2023-11-08T15:33:16ZDaveD"Amount before tax" is wrong on online contribution receiptIt's because totalTaxAmount seems to have gone missing, so the amount before tax ends up the same as after tax. The total is correct though.
To reproduce:
1. Turn on and set up taxes: https://docs.civicrm.org/user/en/latest/contribution...It's because totalTaxAmount seems to have gone missing, so the amount before tax ends up the same as after tax. The total is correct though.
To reproduce:
1. Turn on and set up taxes: https://docs.civicrm.org/user/en/latest/contributions/sales-tax-and-vat/
2. Create a price set using that financial type.
3. Create an online donation for it where it's set up to send a receipt. It also happens if you use the send receipt action later from find contributions, since this also uses the online template (as opposed to editing the contribution and checking the box to send receipt, which uses the offline template).
I don't know exactly when it started. It's not working in 5.52 or master.5.69.0https://lab.civicrm.org/dev/financial/-/issues/219the Price Set labels are showing html2023-11-02T00:23:16ZJoeMurraythe Price Set labels are showing htmlDmaster issue reported by @petednz at https://chat.civicrm.org/civicrm/pl/r95fm7gwqtnddc8umph8hqrtrh
![image](/uploads/691ef07d945339396267b24937e190c7/image.png)Dmaster issue reported by @petednz at https://chat.civicrm.org/civicrm/pl/r95fm7gwqtnddc8umph8hqrtrh
![image](/uploads/691ef07d945339396267b24937e190c7/image.png)5.68.0eileeneileenhttps://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/97Contribution paid via Stripe as payment processor - no financial transaction ...2023-08-18T09:35:57ZJoachimContribution paid via Stripe as payment processor - no financial transaction for fee amount gets generatedWhen making a contribution (in my case for purchasing a membership), there is a different behavior, whether the Dummy Processor or Stripe gets used as a payment provider - the financial type is in both cases identical:
* The contributi...When making a contribution (in my case for purchasing a membership), there is a different behavior, whether the Dummy Processor or Stripe gets used as a payment provider - the financial type is in both cases identical:
* The contribution via the Dummy Processor does create a separate financial transaction for the processing fee (using the configured expenses account for banking fees).
* The contribution via Stripe does result in the correct fee amount recorded in the contribution details, but no transaction gets created.
When doing a batch export of these contributions, I have trouble doing a reconciliation of the transactions without the transactions for the processing fees. Since the expenses account is configured, I suspect that the intended behavior should be the one of the dummy processor.
I just tested these scenarios on a clean installation of version 5.18.4 under Wordpress with Stripe extension 6.2https://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/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/6Proposal - make future recurring contribution instances modifiable & not fail...2023-06-18T23:41:41ZeileenProposal - make future recurring contribution instances modifiable & not fail if the only contribution is deleted.Currently each contribution in a recurring contribution series is generated based on the most recent completed contribution in that series. In some cases there is a desire to alter it as time goes on - with requests to change
- line item...Currently each contribution in a recurring contribution series is generated based on the most recent completed contribution in that series. In some cases there is a desire to alter it as time goes on - with requests to change
- line items
- custom fields
- soft credits
- link to the contribution page
- campaign
We also see issues where the only contribution stored against it is deleted & the contribution fails - either by a site users or in Sepa's case an attempt to change the workings.
At Barcelona we discussed this and decided that from a data model point of view we would
* [X] Add an is_template field to the civicrm_contribution table - added in 5.20
* [X] Update CRM_Contribute_BAO_ContributionRecur::getTemplateContribution (with test) to attempt to first attempt to retrieve the latest template contribution associated with a recurring contribution and failing that to default back to the latest contribution done in 5.20
* [X] Update apiv4 to not return is_template entities (for any entity) by default~~ done with test in 5.20
* [X] update apiv3 to not return is_template contributions by default [PR](https://github.com/civicrm/civicrm-core/pull/15550) in 5.20
* [x] update civicrm search to not return is_template contributions by default (todo)
* [ ] update civicrm reports to not return is_template contributions by default (todo)
* [X] to reduce risk of leakage ALSO add a new contribution status 'TEMPLATE' so that places that do not implement one of the above are still unlikely to get them. Added in [this pr](https://github.com/civicrm/civicrm-core/pull/15431)
* [X] filter the new status from the various forms so people can't change status to it in [this PR](https://github.com/civicrm/civicrm-core/pull/15472) and [this PR](https://github.com/civicrm/civicrm-core/pull/15470)
* [ ] UI testing to make sure the new status doesn't leak
* [ ] Add code in CRM_Contribute_BAO_Contribution that makes is so setting is_template on a contribution ALSO sets the status
* [ ] Consider adding code (in an extension - in the first instance) so that if the only contribution on a recurring contribution is deleted it is converted to a template instead.
* [ ] More UI testing to ensure template contributions don't leak
* [ ] Look at accepting template_id or similar as a parameter to Order.create, move to make it the replacement for Contribution.repeattransaction
* [ ] Consider whether we should respect recur overrides for template contributions. I think a case could be made for template overrides (those stored in civicrm_contribution_recur) to be ignored if a template contribution exists as they are really a work around not having a template contribution & the code is new at the moment so we can make new rules
* [ ] Look at a way to clone & save a contribution to a template contribution (this is kind of out of scope in round one but might not be that hard using copyGeneric - it would be an apiv4 feature)
Things we considered when evaluating the approach
1) there is already precedent for is_template on events
2) there is no move initially to create any is_template contributions in core - this gives us time for people to use it in an opt-in manner & to find & eliminate any leakage.
3) there was some discussion about whether the loss of sequentiality matters but it was decided the presence of is_test already denoted that as not being an intended architectural feature of the table and that the invoice_number field had already been added to allow sites to manage this. Jamie pointed out (below) that the status of Void / Cancelled could be used to exclude is_test so we just have another status to exclude here.
4) the key challenge was tracking custom data to copy - there was really no reasonable way of getting around tracking this without the entity_id being for a row in the civicrm_contribution table.
5) a phased approach - we wanted to set up the ground work but not impose any change in this phase.
6) it might be that we also need to add the field to other tables or to suppress entities related to an is_template contribution - probably an open investigation / discussion
7) potentially this could supercede permitting template overrides in civicrm_contribution_recur
8) the reason we've always backed out of this approach before is that it would be hugely risky to create the data structure AND start creating template contributions at once. In Barcelona we agreed NOT to start putting data in it in core in the short term & dig out all the leakage before we consider using it in core - e.g any UI features, allowing save as template. Unless extension writers take action no template contributions will exist
Previous JIRA CRM-13839https://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/72New methodology for storing template contributions2023-03-18T05:06:58ZeileenNew methodology for storing template contributionsRecurring contributions create new contributions based on a template.
Currently the template is the most recent contribution with a value in contribution_recur_id field equivalent to the recurring contribution.
The main issue with this...Recurring contributions create new contributions based on a template.
Currently the template is the most recent contribution with a value in contribution_recur_id field equivalent to the recurring contribution.
The main issue with this is that if the contribution is deleted (e.g because it's far in the future & confusing) there is no way to create contributions against the recurring profile.
From a data model this idea of an 'implicit template' is far from ideal. However, a key challenge is that the template contribution holds references to custom data which is keyed by entity_id so using a table other than civicrm_contribution to store the template is highly fraught
At the sprint we concluded that the correct approach is to have the ability to store template contributions in a non-exposed way. To identify them we want to do BOTH
- create a new contribution status 'Template-only'
- add a new field is_template to the table
The reason for both is that we think is_template is the correct maintainable approach. However we think that many existing things won't search on it but WILL filter on contribution_status_id.
We will mitigate any impacts further by
1) making is_template=0 a default criteria on apiv3, apiv4, BAO_Query
2) not actually starting to create template transactions in core processes initially - processors that use it can drive the next stage of development
3) BAO_Contribution::create() will ensure is_template & status are in sync.
4) not permitting any UI editing of this field/ template contributions (until we build a specific UI)
The way this field WILL be initially usable is that the BAO_Contribution::getTemplateContribution function will attempt
1) get contribution with is_template = 1 AND contribution_recur_id = x
2) failing that fall back on existing latest contribution with contribution_recur_id = xhttps://lab.civicrm.org/dev/financial/-/issues/141Define return parameters for doPayment2023-03-11T00:09:20Zmattwiremjw@mjwconsult.co.ukDefine return parameters for doPaymentSee #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it'...See #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it's not defined anywhere.
My proposal:
* `doPayment($params)` returns an array.
* It must contain:
* **`payment_status_id`**: **(deprecated)** Numeric value of `Contribution Status` option value Completed or Pending. Eg. 1. Must be set but make sure you set `payment_status` as well because this value will be ignored in the future.
* **`payment_status`**: Text field - Either `Completed` or `Pending`.
* It may contain (and the code that calls `doPayment()` will update these values on the contribution/payment:
* **`trxn_id`**: The transaction ID from the payment processor. This will be recorded in the `Contribution.trxn_id` field and the `Payment.trxn_id` field. We do not return `order_reference` here because that is usually filled in by an IPN callback from the payment processor if required.
* **`fee_amount`**: The amount (in same currency as contribution) of the fee taken by the payment processor for processing the payment.
Historically `$params` was passed by reference. This is deprecated and only the return values should be used.
Ping @eileen @artfulrobot @KarinG5.49.0https://lab.civicrm.org/dev/financial/-/issues/63Something wrong when a pending contribution is changed manually to completed2023-03-05T19:42:49ZfrancescbassasSomething wrong when a pending contribution is changed manually to completedWe usually offer the possibility to pay with credit card or with pay later via cash or EFT.
Pay later contributions are registered as pending. Then when we receive the payment in some cases we modify the status of the payment to complet...We usually offer the possibility to pay with credit card or with pay later via cash or EFT.
Pay later contributions are registered as pending. Then when we receive the payment in some cases we modify the status of the payment to completed (also date received). This creates a payment with the amount of the contribution but without the payment method. Then if we try to update the payment method the process crashes with a 500 (the update screen remains with the logo of CiviCRM turning indefinitely).
```
Sorry, due to an error, we are unable to fulfill your request at the moment.
You may want to contact your administrator or service provider with more details
about what action you were performing when this occurred.
Mandatory key(s) missing from params array: payment_instrument_id
Return to home page.
```
The error can be reproduced at dmaster.
![edit-contribution](/uploads/86f4e384800d6ac895cca6fb33ecdc80/edit-contribution.gif)
Note that if instead of changing contribution status we record the payment, this works well.
![record-payment](/uploads/8a59f82b67f434bb5737dcf3fb9e13ee/record-payment.gif)5.18.2https://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/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.0https://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/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/208Download invoice button on contribution view gives fatal error2022-09-02T00:36:12ZDaveDDownload invoice button on contribution view gives fatal errorMy guess is it happened here: https://github.com/civicrm/civicrm-core/commit/f436aaf2501fbf20ed411e5976d2dd14c588d1b6#diff-b96eb626cc73750f3b681bd12d980236b7062d1633e9d067d3d00d07cdb37a98R243
TypeError: Argument 3 passed to CRM_Contribu...My guess is it happened here: https://github.com/civicrm/civicrm-core/commit/f436aaf2501fbf20ed411e5976d2dd14c588d1b6#diff-b96eb626cc73750f3b681bd12d980236b7062d1633e9d067d3d00d07cdb37a98R243
TypeError: Argument 3 passed to CRM_Contribute_Form_Task_PDF::getElements() must be of the type array, int given, called in .../CRM/Contribute/Form/Task/Invoice.php on line 225 in CRM_Contribute_Form_Task_PDF::getElements() (line 243 in .../CRM/Contribute/Form/Task/PDF.php).
Probably it needs to be more tolerant that it could sometimes receive a single contact id not an array?5.54.0