Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2020-06-20T00:50:40Zhttps://lab.civicrm.org/dev/financial/-/issues/136Feature / Bug Cancel all pending contributions linked to a recurring contribu...2020-06-20T00:50:40ZseamusleeFeature / Bug Cancel all pending contributions linked to a recurring contribution when it is cancelledhttps://lab.civicrm.org/dev/financial/-/issues/133Enhancements to Payment PropertyBag2021-04-12T10:46:20Zmattwiremjw@mjwconsult.co.ukEnhancements to Payment PropertyBagPayment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artful...Payment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artfulrobot and others to edit/update this description once we are in agreement.
1. The following parameters should be added:
* trxn_id -> Maps to `transactionID`.
* installments
* recur start/end dates?
2. To support a phased conversion to propertyBag we should allow exporting as an array: https://github.com/civicrm/civicrm-core/pull/17507 or similar. Alternatively we should document using reflection to access the propertyBag array eg.:
```
if ($propertyBag instanceof \Civi\Payment\PropertyBag) {
$reflectionClass = new ReflectionClass($propertyBag);
$reflectionProperty = $reflectionClass->getProperty('props');
$reflectionProperty->setAccessible(TRUE);
$params = $reflectionProperty->getValue($propertyBag)['default'];
}
else {
$params = $propertyBag;
}
```
3. Some parameters should be either be ignored or added to propertyBag in some form during `mergeLegacyInputParams` such as:
* qfKey
* entryURL
* qf_default..
Note that both `qfKey` and `entryURL` can be useful for guessing context though it would be nice if there was a better way to identify the context in which a payment processor was being used.
Eg. see https://lab.civicrm.org/extensions/stripe/-/blob/6.4.1/CRM/Core/Payment/Stripe.php#L1063 for an example of `qfKey` usage which shows that we don't really need `qfKey` but do need a more formal way of obtaining an errorURL or removing the need for it at all.https://lab.civicrm.org/dev/financial/-/issues/132Model best practices in our core processors2021-05-17T20:43:14ZeileenModel best practices in our core processorsSubissue of https://lab.civicrm.org/dev/financial/-/issues/130
~~**Subtasks for this issue**
Throw exceptions, do not return error object~~
https://lab.civicrm.org/dev/financial/-/issues/131
**Implement doPayment, do not implement doTr...Subissue of https://lab.civicrm.org/dev/financial/-/issues/130
~~**Subtasks for this issue**
Throw exceptions, do not return error object~~
https://lab.civicrm.org/dev/financial/-/issues/131
**Implement doPayment, do not implement doTransferPayment, doDirectPayment**
https://lab.civicrm.org/dev/financial/-/issues/135
- this is currently blocked on clarifying return parameters https://lab.civicrm.org/dev/financial/-/issues/141
**Cast $params to a PropertyBag at the start of the function**
- note this is currently blocked on PropertyBag support for the full range of properties - see https://lab.civicrm.org/dev/financial/-/issues/130#note_42912
**Use Guzzle, not Curl**
https://lab.civicrm.org/dev/financial/-/issues/143
**Have tests**
So far the following processors have tests
- Paypal (all versions)
- Authorize.net
- Eway
- Payflow Pro
- Dummyhttps://lab.civicrm.org/dev/financial/-/issues/127Receipts for recurring transactions are missing links to modify future contri...2023-11-23T07:34:12ZEdselopezReceipts for recurring transactions are missing links to modify future contributionsOn a backoffice credit card contribution page, there is text indicating that the email sent for a recurring contribution will contain links to modify/cancel the recurring transaction. The receipt however, does not contain these links.On a backoffice credit card contribution page, there is text indicating that the email sent for a recurring contribution will contain links to modify/cancel the recurring transaction. The receipt however, does not contain these links.seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/126Membership BAO does creepy stuff with line items2020-05-27T12:44:56ZeileenMembership BAO does creepy stuff with line itemsI've finally made sense of the code in the Membership BAO but it kinda scares me. The code is set up to create line items for memberships that do not have contributions.
It seems that a membership with no contribution will wind up creat...I've finally made sense of the code in the Membership BAO but it kinda scares me. The code is set up to create line items for memberships that do not have contributions.
It seems that a membership with no contribution will wind up creating a 'best effort' line item and deleting any line items already related to the membership.
In the code I'm looking at (the renewal form) the contribution is created later & the membership winds up with 2 line items (one with a NULL contribution id).
I used to think that line items had to have a contribution id but I've learnt that participants also support orphan line items. However, in this case they wind up with both.
I'm not clear that it was intentional that ALL memberships have line items - it looks from the code like it might have originally been for non-quick-config-only. However, I guess??? it's the model now - although I suspect it's inconsistent.....
I think we might need to start passing in skipLineItem a bit more.
I can replicate the MembershipRenewal one in a test so can process that onehttps://lab.civicrm.org/dev/financial/-/issues/125Allow individuals to download invoices for their organisation2020-05-20T14:10:48ZbgmAllow individuals to download invoices for their organisationMy use-case is the following:
* Membership is invoiced to the organization;
* A related contact (with view/edit permission) should be able to login and access the dashboard of the organization, download invoices.
Viewing the related or...My use-case is the following:
* Membership is invoiced to the organization;
* A related contact (with view/edit permission) should be able to login and access the dashboard of the organization, download invoices.
Viewing the related org's dashboard works, it displays the list of invoices and a download link, but clicking on the link results in an "Access Denied".https://lab.civicrm.org/dev/financial/-/issues/124Contribution page profile for honoree (db error)2023-11-23T07:33:30ZMartinContribution page profile for honoree (db error)Hi there, we're getting a database error originating from how the profile is used in the honoree section of a contribution page.
No profile is selected here in our admin, so it appears to be using the "Honoree individual" reserved profi...Hi there, we're getting a database error originating from how the profile is used in the honoree section of a contribution page.
No profile is selected here in our admin, so it appears to be using the "Honoree individual" reserved profile, which includes some contact/individual fields. To this we've added a new field that is a custom field on the Contribution object (more specifically we created this field on the contribution so the end user could enter notes relating to why they are honoring this person, so that you have an idea of the use case).
With this configuration, when a user fills out the contribution page with an honoree and enters text in this field, the contribution fails with a database error. This is shown in the Civi log:
[message] => DB Error: constraint violation
[debug_info] => INSERT INTO civicrm_value_honoree_infor_17 ( `note_53`,`entity_id` ) VALUES ( 'my note text',32747 ) ON DUPLICATE KEY UPDATE note_53 = 'my note text' [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`db_name`.`civicrm_value_honoree_infor_17`, CONSTRAINT `FK_civicrm_value_honoree_infor_17_entity_id` FOREIGN KEY (`entity_id`) REFERENCES `civicrm_contribution` (`id`) ON DELETE CASCADE)]
What appears to be happening is that the entity_id that's being passed through to create the custom field value is that for a contact, rather than the contribution's id. In this case 32747 is the ID for a contact that was attempting to be created, not a contribution.https://lab.civicrm.org/dev/financial/-/issues/123Recurring Contributions -> and Sales Taxes2021-08-20T05:38:22ZKarinGRecurring Contributions -> and Sales Taxes**UPDATE - the tldr is contribution_recur.amount = "Amount to be collected (including any sales tax) by payment processor each recurrence."**
Should the amount field in the civicrm_contribution_recur table -> be prior to Sales Tax or s...**UPDATE - the tldr is contribution_recur.amount = "Amount to be collected (including any sales tax) by payment processor each recurrence."**
Should the amount field in the civicrm_contribution_recur table -> be prior to Sales Tax or should it include Sales Tax?
Example:
$10.00 Membership
Sales Tax 5%
A. (recurring) amount = 10 [before Sales Tax]
or
B. (recurring) amount = 10.50 [Sales Tax included]
Context: a payment processor needs to know the amount to transact/authorize. So I'm hoping we can clarify/document what the amount field in the civicrm_contribution_recur table represents.
@eileen
Chat: https://chat.civicrm.org/civicrm/pl/m8i98w31fi8ddfc6hisoqrrm4y
The Comment on the field itself in the Table Structure: "Amount to be contributed or charged each recurrence."https://lab.civicrm.org/dev/financial/-/issues/122Offer api support for failed payments2022-10-16T08:10:45ZeileenOffer api support for failed paymentsCurrently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what w...Currently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what we we want is to support the following in Payment.create api/BAO
- status_id = 'Failed'
- 'is_update_contribution_status' = TRUE/ FALSE
This would add a Failed payment to the contribution and optionally (default yes I think) do all the flow on things that currently happen. If the default for is_update_contribution_status then it is closer to the current expectations.
I realise that not everyone thinks we should fail those things in all scenarios - but they feel kinda baked in & like a bigger change to address.
I also thought about using 'is_fail_contribution' - but then if we have status_id = 'Cancelled' we don't want 'is_cancel_contribution' & is a cancel the same as a fail?
As a follow on thought - we should possibly have a message template that could be sent out when a fail occurs.
@JoeMurray @mattwire @monish.debhttps://lab.civicrm.org/dev/financial/-/issues/121Financial Type ACLs don't work on soft credits2022-08-17T22:07:10ZJonGoldFinancial Type ACLs don't work on soft creditsTo replicate:
* Create a soft credit on any contribution. Note the financial type.
* Enable Financial ACLs.
* Log in as a user who doesn't have permission to view the financial type noted above.
* If you're using `civicrm-buildkit`, an...To replicate:
* Create a soft credit on any contribution. Note the financial type.
* Enable Financial ACLs.
* Log in as a user who doesn't have permission to view the financial type noted above.
* If you're using `civicrm-buildkit`, any non-administrative user who can view CiviCRM (e.g. with `CiviCRM Webtest User` role) qualifies.
* View the contact with the soft credit.
### Expected Result
* The soft credit is not visible.
### Actual Result
* The soft credit is visible. Clicking `View` to view the original contribution returns a "permission denied", which is correct (but bad UX).JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/117Payment edit link cannot be modified2020-02-11T20:07:09Zadrian@roomify.usPayment edit link cannot be modifiedOn the 'View Contribution' page, the payment details edit link is not currently modifiable via hook_civicrm_links. Related issue: https://issues.civicrm.org/jira/browse/CRM-13434
I'll be submitting a PR.On the 'View Contribution' page, the payment details edit link is not currently modifiable via hook_civicrm_links. Related issue: https://issues.civicrm.org/jira/browse/CRM-13434
I'll be submitting a PR.5.24.0https://lab.civicrm.org/dev/financial/-/issues/116Cancelling a payment thru the API2020-02-14T19:24:31ZalicefruminCancelling a payment thru the APIWhen a user updates a Contribution with the status "Completed" to have the status "Cancelled" thru the UI (or the API using Contribution.create and an id) a negative payment is created with a status of "Cancelled" like in the screen shot...When a user updates a Contribution with the status "Completed" to have the status "Cancelled" thru the UI (or the API using Contribution.create and an id) a negative payment is created with a status of "Cancelled" like in the screen shot below:
![cancelled](/uploads/04c0dcd8c7798a42184e2f0a902b1697/cancelled.png)
This works fine if you are cancelling a full contribution however there is now way in the UI or the API to cancel one of multiple payments.
For Example:
+ a user has a $10 contribution with two payments one for $2 and one for $8
+ The user wants to cancel the $2 contribution
If you cancel the contribution it will record a negative payment of $10.
IF you do `Payment.cancel` it will record a negative payment of $2 with a status "Refunded"
Using `FinancialTrxn.create` you can create a payment of -$2 with a status of "Cancelled" but it will not update the contribution status AND when you update the contribution status to "Cancelled" a new negative payment (of -$10) will be created with a status of cancelled.
PROPOSED SOLUTIONS:
+ Update the `Contribution.create` api so that there is a flag to not create new payments.
+ Allow 'status_id' to be passed to the Payment API and update the contribution and payment statuses based on the status_id if providedhttps://lab.civicrm.org/dev/financial/-/issues/114Support use of 'Chargeback Account is'2020-01-14T05:39:52ZJoeMurraySupport use of 'Chargeback Account is'Currently, trying to configure a Account Relationship for 'Chargeback Account is' leads to an error, "This financial account cannot have 'Chargeback Account is' relationship.' It comes from https://github.com/civicrm/civicrm-core/blob/ma...Currently, trying to configure a Account Relationship for 'Chargeback Account is' leads to an error, "This financial account cannot have 'Chargeback Account is' relationship.' It comes from https://github.com/civicrm/civicrm-core/blob/master/CRM/Financial/BAO/FinancialTypeAccount.php#L264. The problem is that https://github.com/civicrm/civicrm-core/edit/master/CRM/Financial/BAO/FinancialAccount.php#L282 does not define this account relationship. The reason for that was core does not support the bookkeeping around that.
Currently, when the Contribution status is changed to 'Chargeback', eg from completed, the bookkeeping transaction that is created uses a reversal transaction with the 'Revenue Account is' financial account for the financial type. The proper way to handle chargebacks would be at the Payment level rather than the Contribution level. The contribution status should only change to Chargeback when all unfailed and unrefunded payments, including partial ones, are in status chargeback. But that is too big a change to work on immediately, and should be left to when we refactor and maybe eliminate the contribution status field.
The current proposal is to better support a financial type with a 'Chargeback Account is' relationship defined as follows:
1) Don't throw an error when trying to define this relationship in the browser. Instead, add the following as L292:
'Chargeback Account is' => 'Revenue', // this is like a contra-revenue account and assumes the chargeback is for a donation rather than creating a bad debt bookkeeping entry for a sale of goods or services that had a chargeback
2) When the status is being changed to 'Chargeback' on a payment or contribution, use the chargeback account rather than a reversal transaction on the financial account with a 'Revenue Account is' relationship. Note that this will be at a line item level, which is okay.
So currently, creating a completed contribution and then changing its status to Chargeback creates the following two accounting entries:
```
Debit Account Credit Account Amount
Deposit Bank Account Donation 100.00
Deposit Bank Account Donation -100.00
```
After the change, the second transaction would be
```
Deposit Bank Account Chargeback -100.00
```Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/113Soft Credits should have pre/post hooks2020-01-12T21:51:57ZJonGoldSoft Credits should have pre/post hooksThe ContributionSoft entity doesn't have pre/post hooks. The use case for having them is to trigger emails or other workflows involving the credited individual.The ContributionSoft entity doesn't have pre/post hooks. The use case for having them is to trigger emails or other workflows involving the credited individual.5.23.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/111Thank-you letter incorrect contribution currency2020-10-09T01:04:37ZkleehkThank-you letter incorrect contribution currencySteps to replicate:
* Enter a contribution with a currency that is not the default.
* Using any method that supports contribution tokens (Thank-you letter print or email, CiviRules, etc.) use one of the following tokens: `{contribution.t...Steps to replicate:
* Enter a contribution with a currency that is not the default.
* Using any method that supports contribution tokens (Thank-you letter print or email, CiviRules, etc.) use one of the following tokens: `{contribution.total_amount} {contribution.fee_amount} {contribution.net_amount}`.
**Expected result**
The token displays the amount formatted to the currency of the contribution.
**Actual result**
The token displays the amount formatted to the default currency.
[Original message follows].
~~~~
My setup: CiviCRM 5.20.0 on Drupal 7.
I entered contributions in different currencies. In Find Contributions, check some entries. At Actions select Thank-you letter print or email.
I put tokens Contributions:
{contribution.currency} {contribution.total_amount} {contribution.fee_amount} {contribution.net_amount}
and it gives me lines like these:
CNY HK$ 1,299.90 HK$ 0.00 HK$ 1,299.90
GBP HK$ 500.00 HK$ 0.00 HK$ 500.00
where CNY and GBP are the currencies of those contributions and HK$ is the symbol of the default currency.
It seems the amounts variables just took the system default, rather than contributions' currencies.
Thank you.
Original post at https://civicrm.stackexchange.com/questions/34031/thank-you-letter-incorrect-contribution-currency5.32.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/109Invoice does not assign/display the contact's country2020-03-01T20:27:10ZbgmInvoice does not assign/display the contact's countryTo reproduce:
* Enable Taxes and Invoicing
* Edit the "Contribution Invoice Receipt" message template to include `{$country}` (other related contact tokens are called `{$street_address}`, `{$email}`, etc.
* Go to a contact, create a con...To reproduce:
* Enable Taxes and Invoicing
* Edit the "Contribution Invoice Receipt" message template to include `{$country}` (other related contact tokens are called `{$street_address}`, `{$email}`, etc.
* Go to a contact, create a contribution, and from "view contribution", click "print PDF invoice" to view an invoice.
The country will be empty.5.24.0https://lab.civicrm.org/dev/financial/-/issues/108Disabling a price option or price field causes to be zeroed out and financial...2019-11-19T09:22:41ZseamusleeDisabling a price option or price field causes to be zeroed out and financial integrity issues when changing fee selectionsTo reproduce this error:
1. Create a Price set with > 1 price fields
2. Register and pay for someone using just 1 of those price fields
3. Now disable the price field that was used in step 2
4. Navigate to change fee selections to now s...To reproduce this error:
1. Create a Price set with > 1 price fields
2. Register and pay for someone using just 1 of those price fields
3. Now disable the price field that was used in step 2
4. Navigate to change fee selections to now select an option from the 2nd price field
5. Notice that the qty for the first price field gets zeroed out and no new financial trxn is created sensibly.
I believe @KarinG replicated this in chat https://chat.civicrm.org/civicrm/pl/ap5bif4gsifeuc57yftbxnmynh a work around is to rather than disabling the price option is to set the visibility to be admin only. The situation we were having is we were offering a catered option and an uncatered option for an event and wanted to stop people registering for the catered option at a point in time.https://lab.civicrm.org/dev/financial/-/issues/107notice errors: undefined index discounted_value, invalid arg for foreach()2020-08-25T15:12:11ZJoeMurraynotice errors: undefined index discounted_value, invalid arg for foreach()On dmaster just now, on Fees tab for Manage Event, click Add Discount Set for Fee Table, result is errors:
Notice: Undefined index: discounted_value in CRM_Event_Form_ManageEvent_Fee->cleanMoneyFields() (line 813 of /srv/buildkit/build/...On dmaster just now, on Fees tab for Manage Event, click Add Discount Set for Fee Table, result is errors:
Notice: Undefined index: discounted_value in CRM_Event_Form_ManageEvent_Fee->cleanMoneyFields() (line 813 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Event/Form/ManageEvent/Fee.php).
Warning: Invalid argument supplied for foreach() in CRM_Event_Form_ManageEvent_Fee->cleanMoneyFields() (line 813 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Event/Form/ManageEvent/Fee.php).5.30.0https://lab.civicrm.org/dev/financial/-/issues/106on Order API test, pass parameters required to create line items, not line items2020-05-28T06:51:36ZJoeMurrayon Order API test, pass parameters required to create line items, not line itemsThe idea of the order api is to provide a wrapper around creating a contribution and all of the line item objects, eg the membership created when buying a membership, or the event registration when buying a ticket.
In the specification ...The idea of the order api is to provide a wrapper around creating a contribution and all of the line item objects, eg the membership created when buying a membership, or the event registration when buying a ticket.
In the specification (https://wiki.civicrm.org/confluence/display/CRM/Order+API), the idea was that there would be array of of the parameters required to create line items. Note that although the entity_table is specified, the entity_id is set to null. Moreover, there is no contribution_id value. Calling the Order API is NOT supposed to require prior calls to create other objects.https://lab.civicrm.org/dev/financial/-/issues/104CRM_Utils_Money::equals should round to monetary values then compare, not do ...2020-02-17T13:10:01ZFrancis (Agileware)CRM_Utils_Money::equals should round to monetary values then compare, not do a difference comparison.When comparing monetary amounts, e.g. via the `Order.create` API call, the `CRM_Utils_Money::equals` function is using a precision level one higher than the currency precision (currently always 2), i.e. instead of requiring the same cent...When comparing monetary amounts, e.g. via the `Order.create` API call, the `CRM_Utils_Money::equals` function is using a precision level one higher than the currency precision (currently always 2), i.e. instead of requiring the same cents value, the amounts must be within 1/10 of a cent.
This uses a calculation with an incorrect premise, and should instead round the values and compare them.
See [the comment for `CRM_Utils_Money::equals`](https://github.com/civicrm/civicrm-core/blob/5.19.1/CRM/Utils/Money.php#L155):
> So, if the currency has precision of 2 decimal points, a difference of more than 0.001 will cause the values to be considered as different.
Which seems like it's an order of magnitude out at first glance, but actually this is the wrong approach, as for example 0.0146 and 0.0154 are less than 0.001 apart, but round with a decimal precision of 2 places to 0.01 and 0.02 respectively. Yes, these two values are unlikely to come up for real, but similar cases could exist.
A practical example where this goes wrong (using Australian tax and currency rules, which are actually pretty simple):
1. We want to create an order with a single taxed line item of $84, including 10% tax.
2. The tax exclusive amount is ~ $76.36 (actually $76.3̅6̅),
3. and the tax amount is calculated to $7.636.
4. The software using the API calculates the total amount as $84.00.
5. Each line item is also added to the Order, using the exclusive and tax amounts.
6. The Order API diligently checks that the line items add up to the total, by checking whether $84 is equal to $76.36 + $7.636
7. `CRM_Utils_Money::equals(84, 83.996, 'AUD')` is called. According to the hard-coded currency precision of 2 decimal places, this should succeed, because $83.996 rounds to a whole dollar value of $84, but
8. The equals function compares to two values with a maximum difference of $0.001, which is less than the $0.004 between to two values.
9. The Order cannot be created.
Agileware ref CIVICRM-13685.24.0