Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2022-09-16T21:08:32Zhttps://lab.civicrm.org/dev/financial/-/issues/181Update billing details fails when no State/Province entered2022-09-16T21:08:32ZlarsssandergreenUpdate billing details fails when no State/Province enteredUpdate billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This...Update billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This works as expected on contribution pages, etc, but not on the update billing details page. Tested on 5.35.2.
I will have a look at how this is handled for contribution pages and port the solution to update billing details, at some point.https://lab.civicrm.org/dev/financial/-/issues/165Specify text for backend recurring receipts, also cc's and bcc's2022-12-19T03:45:27ZJoeMurraySpecify text for backend recurring receipts, also cc's and bcc'sIf a front end recurring donation is made, then the page's receipt text is added to every recurring receipt (from https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionPage.xml#L326).
If a back end recurr...If a front end recurring donation is made, then the page's receipt text is added to every recurring receipt (from https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionPage.xml#L326).
If a back end recurring donation is made, then the message template Contributions - Receipt (on-line) doesn't output anything from
```
{if $receipt_text}
<p>{$receipt_text|htmlize}</p>
{/if}
```
I think it it would make sense to have this additional text that is added at the top of the receipt specified for backend recurring contributions in core. It would involve a schema change to add a receipt_text field in civicrm_contributioin_recur after https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionRecur.xml#L432 , and change the template above to use it.
(Could this be done in an extension, apart from the question of whether it is functionality that completes a feature? The hook at https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterMailContent/ allows the text of a template to be altered. But there is no tooling for modifying a specific part of a template similar to how we've come to use js to modify a page's DOM rather than override its tpl. As a result, it's quite difficult to manage changes to the contents of core templates from extensions as I don't think there is a good way to 'modify its DOM' prior to sending. I suppose a regex every time a receipt is sent to insert the desired text is possible if a bit ugly.)
Simiilarly, there is no ability to cc or bcc these receipts for backend recurring contributions like there is for frontend ones. I'd add fields for this into civicrm_contribution_recur similar to those from civicrm_contribution_page.
I don't believe the is_email_receipt field on civicrm_contribution_recur is exposed on the backend contribution form (anymore). I think it could make sense to add it and the new receipt_text field just under the Receipt Date field on https://dmaster.demo.civicrm.org/civicrm/contact/view/contribution?reset=1&action=add&context=standalone&mode=live. A better approach if we are going to expose them, I think, is to hide these fields in a receipt fieldset, perhaps above Additional Details.
It's likely that many folks would prefer to just specify this once for all backend recurring donations, as it will include text similar to that on the manage contribution page settings for all front end recurring donations through that page. An alternative to adding these fields to the schema for civicrm_contribution_recur, and exposing them for each backend contribution, would be to make them into settings that could be set at Administer > CiviContribute > CiviContribute Component Settings.
Thoughts? Upvotes or even downvotes appreciated if you don't have time for a comment.
Cheers.seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/155Incorrect deductible shown in contribution summary report2020-11-09T13:37:51ZMonish DebIncorrect deductible shown in contribution summary reportSteps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-d...Steps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-deductible amount is incorrect against each month
On closer look, group function (- SUM) is not applied on non-deductible amount, thus the report column show random amount.
Here's a screencast that explains the issue, where I added two contributions this month w/o non-deductible amount respectively, but the Contribution summary report shows incorrect value:
![yhv](/uploads/e851d5c3b56e46c1de049d12d1f977ff/yhv.gif)
ping @JoeMurray @eileen @mattwire @EdselopezMonish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/150civicrm/payment/form url got empty currency argument in backoffice live CC form2021-07-07T08:47:08ZMonish Debcivicrm/payment/form url got empty currency argument in backoffice live CC formThis affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayme...This affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayments.civicrm)
2. Add and configure an iATS Payments ACH/EFT payment type payment processor.
3. Enable USD and CAD currencies
4. Go to 'Submit Credit Card Contribution' backoffice form
5. Choose payment processor created at step 2
Issue:
1. Payment block renders payment block with check template
2. Switching currency doesn't update the payment block.
For more detail discussion on MM - https://chat.civicrm.org/civicrm/pl/ixxrxhxs43r4mfyjpnf6tnwnnc
ping @KarinG @eileen @JoeMurray @seamuslee5.31.0Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/146alterPaymentProcessorParams hook and propertyBag2020-09-15T15:35:00Zmattwiremjw@mjwconsult.co.ukalterPaymentProcessorParams hook and propertyBagSee https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all t...See https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all the quirks of checking different array keys for one thing.
> - ✔ any setting the hook does in a prop bag ensures forward consistency for the next process in the chain (another hook or the main process)
> - ✖ It's possible that the reason for a hook is something pretty darn weird needs doing; in which case the raw array may be more useful.
>
> 2. pass the original array to the hook
>
> - ✖ hook has to do all work arounds
> - ✖ hook is free to implement bad practise in altering the array
> - ✔ hook can do whatever it likes.
>
> I think (1).
And example from Stripe where we're currently passing an array for compatibility (but this should not be used as a model as Stripe ignores the return values from the hook anyway).
https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/Stripe.php#L484-489
// @fixme DO NOT SET ANYTHING ON $propertyBag or $params BELOW THIS LINE (we are reading from both)
$params = $this->getPropertyBagAsArray($propertyBag);
// We don't actually use this hook with Stripe, but useful to trigger so listeners can see raw params
$newParams = [];
CRM_Utils_Hook::alterPaymentProcessorParams($this, $params, $newParams);https://lab.civicrm.org/dev/financial/-/issues/143Convert core processors to use Guzzle and bring them under CI2020-09-05T01:27:07ZeileenConvert core processors to use Guzzle and bring them under CISubtask of https://lab.civicrm.org/dev/financial/-/issues/132Subtask of https://lab.civicrm.org/dev/financial/-/issues/132https://lab.civicrm.org/dev/financial/-/issues/142Order api proposal - require less line item parameters2020-12-03T10:37:27ZeileenOrder api proposal - require less line item parametersI'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technica...I'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technical analysis of dealing with multiple price sets, more complex config) - so this is just for that common use case
2) qty - if not set, default to 1
This would make the minimum required params for a 'quick config' (I hate that usage but I think we know what it means) order
```
$this->callAPISuccess('Order', 'create', [
'financial_type_id' => 'Donation',
'contact_id' => $contact1,
'line_items' => [
['line_item' => [
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Donation'),
'line_total' => 40,
],
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Member Dues'),
'line_total' => 50,
],
]],
]
]);
```
Ideally we would also accept
```
'financial_type_id' =>'Donation',
```https://lab.civicrm.org/dev/financial/-/issues/137Billing Address params on propertyBag2020-09-14T16:45:36Zmattwiremjw@mjwconsult.co.ukBilling Address params on propertyBagWe currently have a set of `billingXxx` fields on propertyBag but they have no mappings to what actually gets passed in.
Because of `CRM_Core_Form::prepareParamsForPaymentProcessor` we can be pretty certain that fields will be available ...We currently have a set of `billingXxx` fields on propertyBag but they have no mappings to what actually gets passed in.
Because of `CRM_Core_Form::prepareParamsForPaymentProcessor` we can be pretty certain that fields will be available in the format without the `billing_` prefix.
But the mapping is still not completely clear:
```
'billingStreetAddress' => TRUE,
'street_address' => 'billingStreetAddress',
'billingSupplementalAddress1' => TRUE,
'billingSupplementalAddress2' => TRUE,
'billingSupplementalAddress3' => TRUE,
'billingCity' => TRUE,
'city' => 'billingCity',
'billingPostalCode' => TRUE,
'postal_code' => 'billingPostalCode',
'billingCounty' => TRUE,
'state_province' => 'billingCounty',
'billingCountry' => TRUE,
'country' => 'billingCountry',
```
In particular:
1) "County" has various meanings and we should probably standardise on `stateProvince` with `County` being the next level down.
2) Should the params be prefixed with `billingXxx` at all in propertyBag? Or `addressXxx` or just `xxx`.
3) Do we need the supplementalAddress params at all - I don't think anything (payments) uses them?
Ping @eileen @artfulrobot @KarinGhttps://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/129"billing address is the same as above" doesn't show/hide billing address fields2023-11-23T07:37:19ZJonGold"billing address is the same as above" doesn't show/hide billing address fieldsTo replicate on the demo server:
* Add a profile to a contribution page that has all the required fields to expose the "billing address is the same as above" checkbox ("Name and Address" works).
* Load the page.
* Click the checkbox.
Ex...To replicate on the demo server:
* Add a profile to a contribution page that has all the required fields to expose the "billing address is the same as above" checkbox ("Name and Address" works).
* Load the page.
* Click the checkbox.
Expected behavior:
* Checking/unchecking the box should show/hide the billing fields.
Actual behavior:
* No change.
It's not a JS error because JS is still firing.https://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/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/53Always create contribution before processing payment2023-11-23T07:09:31Zmattwiremjw@mjwconsult.co.ukAlways create contribution before processing paymentCurrently there are various different workflows within CiviCRM that handle the creation of contributions in different ways. Sometimes a contribution is created before calling the payment processor BUT sometimes a contribution is only cr...Currently there are various different workflows within CiviCRM that handle the creation of contributions in different ways. Sometimes a contribution is created before calling the payment processor BUT sometimes a contribution is only created after the call to the payment processor - leaving no trace if the payment fails. It is agreed that the *correct* process is to always create a contribution *before* calling the payment processor but it will take some time before CiviCRM core actually does this in all cases.
To process a payment we call `doPayment()` on the payment processor. Any processor that still implements `doTransferCheckout()` or `doDirectPayment()` should be updated to use `doPayment()`.
doPayment
---------
Payment processors should set `payment_status_id` (which is really `contribution_status_id`) in the returned array. The default is assumed to be Pending. In some cases the IPN will set the payment to "Completed" some time later.
This function adds some historical defaults ie. the assumption that if a 'doDirectPayment' processors comes back it completed the transaction & in fact doTransferCheckout would not traditionally come back.
Payment processors should throw exceptions and not return Error objects as they may have done with the old functions.
Contribution Records
---------
Creating a contribution record is inconsistent! We should always create a contribution BEFORE calling doPayment. However currently:
* Contribution Pages: Creates a contribution before calling doPayment.
* Contribution Pages with Membership: Does NOT create a contribution. UNLESS auto-renew=TRUE in which case both a recurring contribution and a contribution is created before calling doPayment.
* Event Registration: Creates a contribution before calling doPayment from CiviCRM 5.14 (see https://github.com/civicrm/civicrm-core/pull/13763, https://github.com/civicrm/civicrm-core/pull/13837 and https://github.com/civicrm/civicrm-core/pull/14435)
* Contribution.transact API - is a mess! And does NOT create a contribution before doPayment, also does NOT use/save the parameters returned from doPayment - see https://github.com/civicrm/civicrm-core/pull/15340 for a proposed patch.
* If we DO have a contribution ID, then the payment processor can (and should) update parameters on the contribution record as necessary.
* `$params['payment_status_id']` (alias for 'contribution_status_id') should be set to the ID (via pseudoconstant getkey) of Pending/Failed/Completed depending on the outcome of the payment.
*Warning*: Anything other than Pending/Completed may not get handled correctly.
* If we DO NOT have a contribution ID, then the payment processor should return a $params array containing:
```
$params[
'payment_status_id' => {as above}
'trxn_id' => {trxn ref to link to record at payment processor}
'fee_amount' => {optional fee charged by processor}
'net_amount' => {optional / discouraged net amount (ie. amount minus fee))}
];
```https://lab.civicrm.org/dev/financial/-/issues/52Rounding differences between Contribution and Bookkeeping reports2023-06-18T23:49:12ZmfuggleRounding differences between Contribution and Bookkeeping reportsThere is a small difference between the total of a Contribution report and a Bookkeeping report using the same filters and therefore intended to produce an identical result. However under certain circumstances there are small rounding er...There is a small difference between the total of a Contribution report and a Bookkeeping report using the same filters and therefore intended to produce an identical result. However under certain circumstances there are small rounding errors between the two reports.
Take the following example. A payment of $155.00 is paid via a payment gateway in three monthly instalments. The first instalment is $51.68 and shown in the contribution report correctly (as an aside the next two payments will be $51.66).
However in the Bookkeeping report the first payment is shown as $51.67 which is the rounded up value of $155.00 divided by three which gives $51.66 recurring. In the following month the contribution report will no doubt show the payment to be $51.66 and the Bookkeeping report will display $51.67.
This error also finds its way into the Extended Reports extension. I realise that this is not a big issue but it would be nice if the reports displayed identical totals.Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/39Authorize.net doesn't support MD5 hashing at the end of the month2019-07-02T14:40:29ZJonGoldAuthorize.net doesn't support MD5 hashing at the end of the monthI just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Ex...I just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Exchange.
> Authorize.Net is phasing out the MD5 based transHash element in favor
> of the SHA-256 based transHashSHA2. The setting in the Merchant
> Interface which controls the MD5 Hash option will be removed by the
> end of January 2019, and the transHash element will stop returning
> values at a later date to be determined.
>
> Merchants utilizing this feature will need to work with their web
> developer or solutions provider to verify if they are still utilizing
> MD5 based hash and if still needed to move to SHA-256 hash via
> Signature Key.https://lab.civicrm.org/dev/financial/-/issues/38Support paying refunds2020-12-05T20:23:27ZJoeMurraySupport paying refundsSee https://lab.civicrm.org/dev/financial/wikis/Refunds-via-payment-processorsSee https://lab.civicrm.org/dev/financial/wikis/Refunds-via-payment-processorsJoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/20Online PayNow 'overcharges' partially paid contributions2023-06-16T09:30:23ZMonish DebOnline PayNow 'overcharges' partially paid contributionsJust noticed that when using the Pay Now functionality from the contact dashboard it does NOT take in account partially paid contributions.
Instead, a payment screen for the full contribution is shown. This can lead to overcharging peop...Just noticed that when using the Pay Now functionality from the contact dashboard it does NOT take in account partially paid contributions.
Instead, a payment screen for the full contribution is shown. This can lead to overcharging people and does not add to the fragile trust relationship we (and many non-profits) have with their donors & participants. Therefor I qualified it as a major issue.
I think the desired behavior is that the payment screen would show the build up of the total like now (it uses the price set where applicable) and under all that the required (remaining) payment should be shown (and used for the payment).
Online Pay Now functionality was introduced here:
https://issues.civicrm.org/jira/browse/CRM-19263
We use it by mailing the constructed link to our users with outstanding contributions, like:
https://mysite/civicrm/contribute/transact?reset=1&id=7&ccid=1234&cs=355345fdgda60b2d1a89f22fc643b&cid=4321
I added a screenshot of the contribution that was partially paid (20 paid out of a total of 50), and the corresponding Pay Now screen showing and charging 50, and a mockup of how it should be shown (or at least it should charge the remaining 30 and not the full 50)
Original JIRA ticket : https://issues.civicrm.org/jira/browse/CRM-21700jitendrajitendra