Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-01T16:29:50Zhttps://lab.civicrm.org/dev/core/-/issues/1Allow to search for "in progress" contributions2024-03-01T16:29:50ZxavierAllow to search for "in progress" contributionsThe search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on s...The search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on status "in progress". Worse case scenario, no contributions have this status, and it will return an empty list4.7.31https://lab.civicrm.org/dev/core/-/issues/310Incorrect allocation of payment on an edited multi-line item event registration2018-10-23T15:30:07ZJoeMurrayIncorrect allocation of payment on an edited multi-line item event registrationOn default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
1. Create event ...On default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
1. Create event with priceset with two fields, first with financial Type Event fees, second with FT of Event Fees 2.
2. Register in event with payment of say $25 for first ticket (Event Fees) and $10 for second ticket (Event fees 2), total $35.
3. Edit Event registration. Click Change selections. Change quantity for second field from 1 to 5, line item total of $50, contribution total of $75, total paid $35. Save. Balance is $40.
4. Click Record Payment.
To review the database records that would be sent to accounting applications, you can:
5. Navigation to Contributions > Accounting Batches > New Batch, create a batch, assign the relevant transactions of $35 (original payment), $40 (edit with implied purchase with pay later) and $40 (payment of outstanding balance) to the new batch and export to csv.
6. At Contributions > Accounting Batches > Open Batches, select the batch just created and export as csv, open and view the resulting transactions:
[Financial_Transactions_3_20180807210702.csv](/uploads/cd4c2989ca42cff4e7f6bba22b8ddfa1/Financial_Transactions_3_20180807210702.csv)
The initial purchase (first two lines) and the edit of the order to increase the number of event fees from $10 to $50 are (the third line) are all correct. However, the payment of the outstanding balance is incorrect. Instead of a single line with a $40 payment (Debit Bank Account 1150, Credit Accounts Receivable 1200), there are two lines:
Debit Bank Account 1150, Credit Accounts Receivable 1200: $16.67, Item description: Member
Debit Bank Account 1150, Credit Accounts Receivable 1200: $23.33, Item description: Guest
It seems the payment is being equally allocated to the two line items in proportion to their current line item total. If there had been a simple partial payment, this would be correct. The algorithm for determining the allocation should not be based on the line item totals (or more accurately, their corresponding financial_item.amount), but on the amount of each financial item that has been paid so far (entity_financial_trxn.amount for the entries linking financial_trxn records to these financial_item records.
We should first verify that the entity_financial_trxn.amount fields are being properly recorded. Then it will be apparent that sum(entity_financial_trxn.amount) pointing to first financial_item is $25, the same as its financial_item.amount, while sum(entity_financial_trxn.amount) pointing to second financial_item is $10, which is $40 less than the financial_item.amount. So all of the second payment would be allocated to a single new entity_financial_trxn.amount of $40 pointing to the second financial_item.
This is not a high priority since the two entries add up to the same as the proposed single entry from an accounting perspective. Having two general journal entries is confusing, and the item description of one is inaccurate, so a fix would be good.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/366Showing Line Items for Contributions with Default Price Sets2022-08-28T05:03:35ZCamilo RodríguezShowing Line Items for Contributions with Default Price Sets## Overview
In scenarios like data migration, multiple membership lines might be added to a contribution via the default priceset. The current mechanism prevents these lines from being shown when looking at a contributions detail view (C...## Overview
In scenarios like data migration, multiple membership lines might be added to a contribution via the default priceset. The current mechanism prevents these lines from being shown when looking at a contributions detail view (CRM_Contribute_Form_ContributionView). It makes sense that quick config priceset do not show up in the priceset configuration pages but there are more cons than pros to not show the lines on the actual contributions.
## How it Works Currently
To decide if line items should be shown for the contribution, line items are fetched, ordered by their price field's weight. Then, the price set for the first line item is checked. If the price set's `quick_config` flag is set, then the line items are NOT shown. If the falg is NOT set, the list of line items is shown.
## How it Should Work
List of line items should always be shown, especially if there is more than one of them, even if they're added using the default price set. Not sure what the logic is behind having the list of line items depend on the price set, but it could be better to have the contribution say if it should be shown with line items or not, by adding a new flag, `show_line_items` to the Contribution entity.guanhuanguanhuanhttps://lab.civicrm.org/dev/core/-/issues/473Unable to select Default invoice payment page on CiviContribute Settings Page2018-10-29T07:09:37ZkcristianoUnable to select Default invoice payment page on CiviContribute Settings PageOn current master, on CiviContribute Settings Page you are unable to select the Default Invoice Payment Page. The only recent change https://github.com/civicrm/civicrm-core/pull/12940 does not appear to be the issue, as reverting it do...On current master, on CiviContribute Settings Page you are unable to select the Default Invoice Payment Page. The only recent change https://github.com/civicrm/civicrm-core/pull/12940 does not appear to be the issue, as reverting it does not fix the error.
![image](/uploads/4205564931d8e92f5cdfb65c3cea407b/image.png)
5.8https://lab.civicrm.org/dev/core/-/issues/706Edit contribution : wrong decimal separator on total_amount for participant(s)2019-03-18T01:07:09ZwouterhEdit contribution : wrong decimal separator on total_amount for participant(s)When I want to register a participant payment, I can not save it because the amount is not in a valid format. There should be a comma instead of a point sign.
This does work for membership payments.![problem_participant_contribution](/u...When I want to register a participant payment, I can not save it because the amount is not in a valid format. There should be a comma instead of a point sign.
This does work for membership payments.![problem_participant_contribution](/uploads/40e1cc7f95b63593d554a5cda946db14/problem_participant_contribution.png)5.13.0https://lab.civicrm.org/dev/core/-/issues/762Financial transaction does not respect Payment Method when marking a contribu...2022-10-12T05:04:02ZguanhuanFinancial transaction does not respect Payment Method when marking a contribution as Completed**How it currently works**
Tested in the latest CiviCRM.
When marking a contribution to "Completed", a financial transaction is created. The transaction picks the default financial account as its debit account rather than taking the as...**How it currently works**
Tested in the latest CiviCRM.
When marking a contribution to "Completed", a financial transaction is created. The transaction picks the default financial account as its debit account rather than taking the asset account assigned to the payment method specified in the contribution.
For example:
- payment method **Credit Card** has **1210 Credit Card Bank** assigned to it
- CiviCRM has **1200 Payment Processor Account** set as default account
- A pending contribution has payment method set to **Credit Card**
When editing the contribution and changing its status to **Completed**, a payment financial transaction is created and its debit account is **1200 Payment Processor Account**.
**How is should work**
When a contribution is marked as "Completed" in the back office forms without using a payment processor, the financial transaction should use the account assigned to the contribution payment method as its debit account.
For example:
- payment method **Credit Card** has **1210 Credit Card Bank** assigned to it
- CiviCRM has **1200 Payment Processor Account** set as default account
- A pending contribution has payment method set to **Credit Card**
When editing the contribution and changing its status to **Completed**, a payment financial transaction is created and its debit account should be **1210 Credit Card Bank**.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/860Incorrect line item created for back-end membership sign-up using price set a...2022-05-05T06:27:07ZdavejIncorrect line item created for back-end membership sign-up using price set and CiviDiscountWhen doing a back-end membership sign-up using a price set, with an additional item e.g. donation and with a CiviDiscount code applying to the membership, the line item created for the membership does not reflect the discount but the con...When doing a back-end membership sign-up using a price set, with an additional item e.g. donation and with a CiviDiscount code applying to the membership, the line item created for the membership does not reflect the discount but the contribution total does. The problem does not occur without the additional item.
**Steps to replicate**
1. Create a CiviDiscount code for e.g. 25% off General membership.
2. Create a membership price set with 2 fields: Membership with options General & Student; Donation text field.
3. Create a contribution page using the price set (we don't use this here but in my testing, the discount did not work on back-end sign-ups until I did this step.)
4. Go to a contact's summary -> Memberships tab and click Add Membership.
5. Enter the discount code & Apply.
6. Choose price set -> select the above price set.
7. You may need to click Apply again to get the discount to show for General membership.
8. Select "General (Includes applied discount: 25% Test for General membership) - $ 75.00".
9. Enter a donation amount, e.g. $5.
10. Leave "Record Membership Payment?" ticked, leave other fields as default.
11. Click Save.
**Expected result**
Contribution created with total amount $80 and 2 line items:
* entity_table: civicrm_membership, line total $75.00
* entity_table: civicrm_contribution, line total $5.00
**Actual result**
Contribution created with total amount $80 and 2 line items:
* entity_table: civicrm_membership, line total $100.00
* entity_table: civicrm_contribution, line total $5.00
Note that the membership line item has the wrong amount and the sum of the line items is not equal to the contribution amount.
Replicated on 5.10.3 and current local civibuild dmaster.https://lab.civicrm.org/dev/core/-/issues/865Result filter criteria doesn't show IS NULL/IS NOT NULL for operations2019-04-15T05:32:20ZyashodhaResult filter criteria doesn't show IS NULL/IS NOT NULL for operationsWe can not search all contributions that are not associated with a campaign currently in report. We should expose IS NULL/IS NOT NULL for other operators as wellWe can not search all contributions that are not associated with a campaign currently in report. We should expose IS NULL/IS NOT NULL for other operators as well5.13.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/867Expose line item name on search2023-04-30T05:03:21ZmaduraExpose line item name on search## Problem
On Advanced Search and Find Contributions there is currently no field to search for the line items. If an admin wants to be able to search for the contacts or contributions based on line items information there is no other se...## Problem
On Advanced Search and Find Contributions there is currently no field to search for the line items. If an admin wants to be able to search for the contacts or contributions based on line items information there is no other search parameters available.
## Proposed Solution
Introduce the "line item name" field in search.
Technical Steps:
- Add a new field to contribution search form and in postprocess, handle it and add suitable where clauses using existing fields as reference.
- Add a new textfield for line item search in CRM_Contribute_BAO_Query::buildSearchForm()
- In CRM_Contribute_BAO_Query::whereClauseSingle add logic for including condition for line item name.https://lab.civicrm.org/dev/core/-/issues/868Contribution summary misleading results when filter cuts through a group2022-10-24T05:03:35ZJKingsnorthContribution summary misleading results when filter cuts through a groupWhen combining a grouping and a filter on the contribution summary report, the results are misleading. Because it cuts of donations that are before the filter, even though they are part of the group being displayed.
For example (on dmas...When combining a grouping and a filter on the contribution summary report, the results are misleading. Because it cuts of donations that are before the filter, even though they are part of the group being displayed.
For example (on dmaster):
Create a contribution on 7 Feb 2017
Create a contribution on 9 Feb 2017
(Two contributions in the same week).
Contribution summary, add a grouping by frequency: Week, view results:
![image](/uploads/9408ab7cdb3d9439ee7558ae5506a126/image.png)
Note - w/c 6 Feb 2017 has 2 donations (correct)
Add a filter for date received 'after' 8 Feb 2017, view results.
![image](/uploads/45d57dbfef1c1b83af0778933817bc09/image.png)
The contribution count is listed as 1 now.
Although this is correct in terms of the filter, it is misleading in the context of the report.
Suggestion solution:
Where a grouping (week, month, fiscalyear, anything) is 'cut' by a filter - extend the filter so that it goes to the start of that grouping. ie: in the example above, all of the values from w/c 6 Feb would still be included in the report.https://lab.civicrm.org/dev/core/-/issues/869Contribution summary report graphs do not work2020-10-07T23:51:43ZJKingsnorthContribution summary report graphs do not workWhen viewing the Contribution Summary report, with its default settings, neither of the 'graph' displays work (Bar Chart, Pie Chart):
![image](/uploads/242c9edabc604e8511114af6cc31fe3b/image.png)When viewing the Contribution Summary report, with its default settings, neither of the 'graph' displays work (Bar Chart, Pie Chart):
![image](/uploads/242c9edabc604e8511114af6cc31fe3b/image.png)https://lab.civicrm.org/dev/core/-/issues/886Contribution gets saved with wrong financial type2019-04-25T07:00:42Zrita_compucorpContribution gets saved with wrong financial typeHi all!
There is a small issue when you have a membership type with 'financial type A' and having a membership price set with 'financial type B', and the contribution page is using the price set.
Steps:
1. I have a membership called ‘...Hi all!
There is a small issue when you have a membership type with 'financial type A' and having a membership price set with 'financial type B', and the contribution page is using the price set.
Steps:
1. I have a membership called ‘General’
2. I have 2 membership financial types: ‘member dues’ and ‘member dues 20% discount’
3. The ‘General’ membership type is using ‘member dues’ financial type
4. I create a membership price set, adding the ‘General’ membership type with the other financial type (‘member dues 20% discount’) and save it
5. Then I set up a contribution page using financial type ‘member dues 20% discount’
- enable the member processing on the contribution page
- and select the previously created member price set
6. Then I sign up to this membership
- --> and the created contribution is using the ‘member dues’ financial type - **Incorrect** https://nimb.ws/nf8wlZ
- --> the contribution’s line item is using the ‘member dues 20% discount’ financial type - **Correct**
- --> the contribution's transaction item is using the ‘member dues 20% discount’ financial type - **Correct**
I would have expected for the main contribution to use the ‘member dues 20% discount’ too, but apparently its using the Membership Type’s financial type. I have checked on the latest civicrm demo (5.14) site as well and the behaviour is the same.
One of our clients reported this.
Thanks,
Ritahttps://lab.civicrm.org/dev/core/-/issues/890Multiple line item shown on view contribution if participant is transferred t...2023-03-30T05:03:41ZjitendraMultiple line item shown on view contribution if participant is transferred to another contact.To replicate -
- Create a priceset for an event with `Text / Numeric Quantity` field type. Amount = $10.
- Register contact A to the event using the above price option.
- Transfer the event participation to another contact B.
- View con...To replicate -
- Create a priceset for an event with `Text / Numeric Quantity` field type. Amount = $10.
- Register contact A to the event using the above price option.
- Transfer the event participation to another contact B.
- View contribution on the main contact, it displays double line items for the participation.
![image](/uploads/86637f21b6b327fc15888b92e8a86bac/image.png)
I think the older participant status is set to "transferred" so it should remove the contribution link from the line item table.jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/899PCP is still active after contribution page is disabled.2023-11-15T05:03:17ZjitendraPCP is still active after contribution page is disabled.To replicate -
- Create a contribution page and enable PCP.
- User makes a donation from the live page and creates a PCP of his own.
- When an admin approves the PCP, a notification email is sent to the creator.
- Disable the Contributi...To replicate -
- Create a contribution page and enable PCP.
- User makes a donation from the live page and creates a PCP of his own.
- When an admin approves the PCP, a notification email is sent to the creator.
- Disable the Contribution page.
- PCP is kept as it is.
- When the live page is visited by the promoter or the user from the PCP link, a yellow message is displayed on the page
![image](/uploads/0b1710ed1f37bcce8b9b4d9c1779ee85/image.png)
Real problem seems to be - you have someone who has made a P2P contribution page who might have no clue the page has been disabled by a site admin and is out promoting the page!
Thoughts on expected behavior? @eileen @KarinG...
- Disable PCP when CP is disabled.
- Keep PCP as it is and change the error message on PCP load.
- Disable the PCP and send an email notification to the creator.
- The current error is perhaps the correct and enough response to be shown to the user :shrug:jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/900Unselecting Premium doesn't hide Minimum Contribution Amount2022-10-26T05:03:43ZyashodhaUnselecting Premium doesn't hide Minimum Contribution AmountSteps to replicate :
* Go to Contribution form.
* Select *Premium* and *Minimum Contribution Amount* will appear.
* Unselect the *Premium* and Minimum Contribution Amount element is still showing on the form.
Suppress *Minimum Contribu...Steps to replicate :
* Go to Contribution form.
* Select *Premium* and *Minimum Contribution Amount* will appear.
* Unselect the *Premium* and Minimum Contribution Amount element is still showing on the form.
Suppress *Minimum Contribution Amount* when Premium has been un-selectedyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/901On Behalf Contributions should soft credit individual2022-10-28T05:03:33ZtommyboboOn Behalf Contributions should soft credit individualCurrently the only connections between a Individual and the Organization in an On Behalf Contribution is a permissioned relationship is created. This is difficult to track and report on especially when Organization have multiple relation...Currently the only connections between a Individual and the Organization in an On Behalf Contribution is a permissioned relationship is created. This is difficult to track and report on especially when Organization have multiple relationships.
A soft credit to the individual is the best way aid in reporting on who initiated the contribution.https://lab.civicrm.org/dev/core/-/issues/905Better support in core for token payment processing2023-02-16T05:03:39ZeileenBetter support in core for token payment processingOver time token payments have become the preferred way of handling recurring payments. A while back we added the payment_token table for storage but we still have a situation where various processor extensions are solving the same proble...Over time token payments have become the preferred way of handling recurring payments. A while back we added the payment_token table for storage but we still have a situation where various processor extensions are solving the same problems separately (with varying degrees of maintainability). If we can converge on some improvements in core to better support this we can add tests in core & make the whole thing more reliable. Use of new methods would be recommended rather than required.
The focus here is on the regular scheduled job that finds recurring contributions that need to be charged, charges them and updates them in CiviCRM. I'm imagining we would add additional functions to the CRM_Core_Payment class that can be used and overridden by the various processors. We might visually separate them into a trait but I think it would be 'used' by CRM_Core_Payment.
The basic flow is
- getDuePayments
- preProcessDuePayments
- submitDuePaymentsToGateway
- updateSuccessfulPayments OR updateFailedPayments
Potentially status reporting - e.g emailing an administrator or logging to system log fits in at the end - I'm gonna leave that out of scope for now.
**Get Due Payments**
There are 2 types of payments here - those that are naturally due and those that are due to be retried due to previous failure. I think we should have 2 methods
- getDueScheduledPayments &
- getDueFailureRetryPayments
**Preprocess due payments**
Generally we create a pending contribution here (repeattransaction, status-pending)
We also attempt to 'lock' the recurring contribution so that it won't be retried the same day if the script fails or if there is a concurrent process. I'm imagining the functions to be
- createPendingTokenPayment
- lockRecurringContribution (more on this down below)
** Submit payments to gateway***
This generally uses 'doPayment'
** Update Successful Payments Update Failed Payment**
We call completetransaction for success & unlock the recurring contribution. Fails is the area we are trying to converge on
**Locking recurrings**
The main ways currently in use for 'locking recurrings' are to
- change the status on the recurring contribution
- add a pending contribution (& use the presence of that in a pending state as a blocker to further processing)
- push out the next_sched_contribution_date and failure_retry_date before starting so it won't be retried again before the schedule is due
After some thought I think we should do more with the status on the recurring contribution. My main reservation at the moment is that processors that use that method are overloading the 'Pending' status which actually means 'no payment yet received' - but I think that stems back to another design decision that I think was a mistake. Originally contribution, contribution_recur, pledge & pledge status were set up to share an option group. This causes a bunch of issues & hacky handling & as of now only contribution & contribution recur share statuses. I think we should separate them out into 2 option groups & then have some extra statuses that reflect the lock situation e.g
- 'Processing' - this would be our 'locked' status & nothing more would happen until that is resolved
- 'Failing' - this would mean one or more fails have happened but we haven't given up yet
This would mean that to be processed the next_sched_contribution_date needs to be now AND the status needs to not be 'Processing' OR the status needs to be 'Failing' and the failure_retry_date needs to be now.
Note that separating out the option group also addresses some other issues so I will likely do it in a 'numbers are all still the same' way sooner rather than later and we will be in a better position later.
**Unlocking recurring**
Success is easy - we just complete the transaction & push next_sched_contribution_date & null our failure_count & failure_retry_date
Failure is hard. The fails could be
- script does not complete. In this case the contribution is left in the 'Processing' status - in some cases people will manually intervene here and in some cases audit information from the processor will update the recurring. However, if, after a month it is still in Processing then it should be tried again. This feels like the case for pushing out next_sched_contribution_date BEFORE attempting payment
- payment fails with a temporary error related to the server (server says come back later)
- payment fails with a temporary error related to the user (card is overdrawn)
- payment fails with a permanent error (card is cancelled, stolen)
- payment fails with a permanent user error because they have cancelled the token at the gateway
Generally in a temporary error we will try again (using the failure_retry_date) and in a permanent error we will cancel the recurring contribution, in the case of the user-cancel it might make more sense for some sites to set it to completed....
**Next steps**
Overall I think if we start to get to some agreed additional functionality to support in core / add to the interface & keep tested that is a good thing. I feel like I need to ponder it for a bit & this will be an ongoing thing. But there are 2 things I think are worth doing now
1) add 4 new exception classes to core (all extending PaymentProcessorException)
- PermanentTokenPaymentException
- TemporaryServerTokenPaymentException
- TemporaryUserTokenPaymentException
- TokenCancelledByUserException
2) create a new contribution_recur_status_id option group - ensure the values exactly match the contribution option group & chip away at updating the various code places to use it (they should still work if using the old one as the numbers will be the same - this is how we managed it on pledges)
Initial discussion at https://github.com/iATSPayments/com.iatspayments.civicrm/pull/273
"Related" issues:
* https://lab.civicrm.org/dev/financial/issues/57
* https://lab.civicrm.org/dev/financial/issues/53
EDIT NOTE - 'Being processed' has been updated in this test to 'Processing' - since that was what was agreed. Comments below may be confusing without realising the text used to refer to Being Processedhttps://lab.civicrm.org/dev/core/-/issues/909Ability to find contribution using Billing name2022-10-27T05:03:46ZsunilAbility to find contribution using Billing nameOnline registration process, Billing Contact details may differ with Primary contact information. (Billing Name is stored in civicrm_address table.)
There is no way to Search contribution using Billing Name and Also Billing Name is not ...Online registration process, Billing Contact details may differ with Primary contact information. (Billing Name is stored in civicrm_address table.)
There is no way to Search contribution using Billing Name and Also Billing Name is not exportable Field.
we can add these field Contribution Search form and make Billing Name field available in Export List.
I will Provide PR for this shortly.https://lab.civicrm.org/dev/core/-/issues/910Ability to Search contribution record using Transaction Date vs Date Received2022-11-08T05:03:39ZsunilAbility to Search contribution record using Transaction Date vs Date ReceivedRight now we can search contribution using 'Date Received' Field, But when Payment is received via check/ or paid through offline credit card (after few days) then the Transaction Date and Date Received may not be same.
During the Recor...Right now we can search contribution using 'Date Received' Field, But when Payment is received via check/ or paid through offline credit card (after few days) then the Transaction Date and Date Received may not be same.
During the Record your payment process, We keep old Receive Date as it is and add new entry in 'civicrm_financial_trxn' table with 'trxn_date' as current date.
If we want to search record when actual Transaction date then expected contribution record does not show in result.
e.g. cross check the payment processor transaction date and civicrm contribution record. transaction date will get matched with processor record and receive date is quite old (when record is created).https://lab.civicrm.org/dev/core/-/issues/912change payment instrument when pending payment paid through credit card2020-09-11T05:41:51Zsunilchange payment instrument when pending payment paid through credit cardCreate Pending Record through online form. (civicrm_contribution: payment_instrument_id : check)
then visit contact and make Record payment using credit card (offline mode).
'civicrm_contribution': payment_instrument_id and 'civicrm_fin...Create Pending Record through online form. (civicrm_contribution: payment_instrument_id : check)
then visit contact and make Record payment using credit card (offline mode).
'civicrm_contribution': payment_instrument_id and 'civicrm_financial_trxn': payment_instrument_id value should change to 'Credit Card' from 'Check'
After paying amount and if expand contribution record for details, you will see 'Payment Method' as 'Check (Visa: 1111)'5.31.0