Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2019-10-19T23:49:21Zhttps://lab.civicrm.org/dev/financial/-/issues/73Order.create should not require total amount2019-10-19T23:49:21ZJoeMurrayOrder.create should not require total amountThe spec for Order API create indicates that the total_amount is not required. If it is not provided then the total is calculated for the line item totals. However, https://dmaster.demo.civicrm.org/civicrm/api#explorer shows that total_a...The spec for Order API create indicates that the total_amount is not required. If it is not provided then the total is calculated for the line item totals. However, https://dmaster.demo.civicrm.org/civicrm/api#explorer shows that total_amount is a required parameter. Please fix the implementation of the order api create functionality to not require total_amount.5.20.0Monish DebMonish Debhttps://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/70Enabling more than one payment methods for checks2019-10-09T12:32:48ZJoeMurrayEnabling more than one payment methods for checksSome organizations have more than one bank account that they deposit checks into. It would be appropriate to configure one payment method / payment instrument for each of these bank accounts so that a different Financial Account can be c...Some organizations have more than one bank account that they deposit checks into. It would be appropriate to configure one payment method / payment instrument for each of these bank accounts so that a different Financial Account can be created for each.
Unfortunately, there are a number of places in core that bake in the idea that there is only ever a single payment method for checks. While we have worked around this with an extension that uses an override (specifically of this line: https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/Manual.php#L95), JMA would like to remove this deficiency, or at least limitation, or core.
Here are some notes from Monish on implementation ideas. We'd like to get approval here, potentially after refinement, before we start.
1. Add hook to add/override payment fields against respective payment instrument.
https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L609 this would be the place to add the new hook say:
CRM_Utils_Hook::extendPaymentFields($paymentInstrumentID, &$paymentFields);
Another place to extend metadata via hook https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L724
2. Change the hardcoded name ‘Check’ in various places, on basis of which check number information is fetched. In order to generalise it, we need to have a UI where we can define payment fields against each payment instrument. In that way it will be easy to gather payment information for a given payment instrument otherwise it will be a problem when the existing PI (payment instrument) name or value is changed like it occurred in case of Check PI whose name was changed to cheque.
Places where Check name was explicitly called (found using grep -irn "'Check'" CRM/ ):
`
CRM//Financial/Page/AJAX.php:371: if ($row[$financialItem->id][$columnKey] == 'Check') {
CRM//Financial/Form/PaymentEdit.php:178: elseif ($paymentInstrumentName == 'Check') {
CRM//Contribute/BAO/Contribution.php:4140: if ($paidByName == 'Check') {
CRM//Contribute/Form/Contribution.php:649: $checkPaymentID = array_search('Check', CRM_Contribute_PseudoConstant::paymentInstrument('name'));
CRM//Contribute/BAO/Contribution.php:185: if ($params['payment_instrument_id'] != array_search('Check', $paymentInstruments)) {
And there are various other places (that hard to find using grep) which have an exclusive condition on payment instrument type where that is using in fetching particular payment field(s) for them.
In order to generalise the flow, we should have
2.1. a separate UI to say 'New Payment Instrument' form
2.2. This UI should have basic payment instrument fields, label, value and a section called payment fields where one can add multiple payment fields against that payment instrument and also select the html type. Say for CC, pan_truncation and card_type_id is text and select field respectively. It could be pretty much similar to the 'New Custom field' form where we can choose name, html type and data type.
3. Upon submission it will save the data in uf_join.module_data as
INSERT INTO `civicrm_uf_join` ( `is_active`, `module`, `entity_table`, `entity_id`, `weight`, `uf_group_id`, `module_data`)
VALUES ( '1', 'payment_instrument', 'civicrm_option_value', '17', '1', '', {"check_number":"ABC123"})
4. After declaring the payment fields, it will render them in backoffice contribution/membership/event forms when the appropriate payment method is selected.
5. To avoid a schema change, on submit the payment information could be stored in civicrm_financial_trxn.payment_data in serialised format. Obviously there are alternatives, such as doing the work to support custom fields on civicrm_financial_trxn, even though much of the existing custom field code would be problematic when applied to a table never exposed through search or directly through forms (closest is payments).
6. Handle install and upgrade to adapt this new change
7. Make changes across financial core files to fetch payment field
8. Add UTs
So main objective: enable more than one payment method to be of type check, and thus prompt the display on view and create/edit of the check number field.
@eileen @monish.debhttps://lab.civicrm.org/dev/financial/-/issues/69Recording one payment against a "Pending (Incomplete Transaction)" results in...2019-10-15T06:15:33ZJonGoldRecording one payment against a "Pending (Incomplete Transaction)" results in two paymentsTo replicate:
* Create a pending contribution (via API, more on this below).
* Record a payment against the contribution.
* Note that two payments are created - one for the full amount, one for the partial amount.
I investigated why thi...To replicate:
* Create a pending contribution (via API, more on this below).
* Record a payment against the contribution.
* Note that two payments are created - one for the full amount, one for the partial amount.
I investigated why this didn't happen via the UI, and it's because the UI creates "Pending (Pay Later)" records. If you pass `is_pay_later = 1` via API, this bug doesn't occur.
The "Pending (Incomplete Transaction)" generates a record in `civicrm_financial_trxn`, which seems odd if the payment didn't happen - but if that IS correct, it should be consistent about whether it appears when you view payments in the UI.5.18.3https://lab.civicrm.org/dev/financial/-/issues/68Check number doesn't get stored in associated financial_trxn record, if the c...2019-09-12T03:27:05ZMonish DebCheck number doesn't get stored in associated financial_trxn record, if the contribution is made using 'Contribution/Membership batch data Entry' formSteps to replicate:
1. Create a Contribution or Membership Batch Data entry with any number of records.
2. Enter the check number and save the contribution(s).
3. Go to the contribution view page.
Result: Check number is missing under...Steps to replicate:
1. Create a Contribution or Membership Batch Data entry with any number of records.
2. Enter the check number and save the contribution(s).
3. Go to the contribution view page.
Result: Check number is missing under payment details section. Although contribution's check number is correctly set.5.18.0Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/67Check number doesn't show up if payment method name - Check changed to Cheque2019-09-12T03:26:19ZMonish DebCheck number doesn't show up if payment method name - Check changed to ChequeSteps to replicate:
1. Edit the existing check payment method name to 'Check' to 'Cheque'
2. Do a contribution and enter a check number.
3. Then view the contribution page.
Result : Check number doesn't show up in Contribution view pa...Steps to replicate:
1. Edit the existing check payment method name to 'Check' to 'Cheque'
2. Do a contribution and enter a check number.
3. Then view the contribution page.
Result : Check number doesn't show up in Contribution view page:
![before](/uploads/7eef36f661eb0c087396143b1c2dd09f/before.gif)5.18.0Monish DebMonish Debhttps://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/62PayPal Pro IPN doesn't record failed recurring payments2020-01-18T22:29:49ZJonGoldPayPal Pro IPN doesn't record failed recurring paymentsOnce upon a time, some payment processors recorded failed recurring payments, others didn't, based on the preference of the author.
These days, we've settled on "failed recurring payments should create a failed contribution entry" acros...Once upon a time, some payment processors recorded failed recurring payments, others didn't, based on the preference of the author.
These days, we've settled on "failed recurring payments should create a failed contribution entry" across the board, except PayPal Pro, which has the note "[// Also consider accepting 'Failed' like other processors.](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L248)".
I wrote a patch for this years ago, but at the time it wasn't settled that this was correct behavior. I recently had another client request this functionality, so I'm going to modernize the patch, put it in production, and submit it upstream if it looks good.JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/60Transaction IDs for a contribution that are initially null are always null2021-08-06T13:19:57ZfrancescbassasTransaction IDs for a contribution that are initially null are always nullThis ticket is the result of the inquiry in this other https://lab.civicrm.org/dev/core/issues/468
**"Normal behaviour"**
1. Create a contribution with transaction ID
![normal-1](/uploads/4208ac1852698fdf61e003d500174d31/normal-1.png...This ticket is the result of the inquiry in this other https://lab.civicrm.org/dev/core/issues/468
**"Normal behaviour"**
1. Create a contribution with transaction ID
![normal-1](/uploads/4208ac1852698fdf61e003d500174d31/normal-1.png)
2. Visualize contribution, transaction ID is present
![normal-2](/uploads/37bab7a87afad68b094dfa5eba16ee9b/normal-2.png)
3. Edit payment details and set a different transaction ID
![normal-3](/uploads/e04d3ed2b91215f593e403310c48b9ad/normal-3.png)
4. Visualize contribution, new transaction ID is appended to the old transaction ID
![normal-4](/uploads/19308ed662e8920da29e234c49c69608/normal-4.png)
**Buggy behaviour**
1. Create a contribution with transaction ID null
![null-1](/uploads/38cd6b38e9ccd16e852c5c7e0c51c3d6/null-1.png)
2. Edit payment details and set a transaction ID value
![null-2](/uploads/25f183f29ced11ae4398cfa8611ec31b/null-2.png)
3. Visualize contribution, transaction ID isn't present
![null-3](/uploads/de18a6e9656acbd6d29029b3c84023db/null-3.png)https://lab.civicrm.org/dev/financial/-/issues/58Batch payment page breaks when an exported activity has no file to download2019-08-23T22:27:09ZJonGoldBatch payment page breaks when an exported activity has no file to downloadI had a batch export fail because `max_execution_time` failed. This left me with an exported batch without an export file - which causes the View Batches page to fail with the backtrace below.
My patch will prevent the page from crashi...I had a batch export fail because `max_execution_time` failed. This left me with an exported batch without an export file - which causes the View Batches page to fail with the backtrace below.
My patch will prevent the page from crashing so it's possible to view the batch page,
```
May 28 20:13:12 [info] $backTrace = #0 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Core/Error.php(385): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1196): CRM_Core_Error::fatal()
#2 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Batch/BAO/Batch.php(337): CRM_Core_DAO::getFieldValue("CRM_Core_DAO_EntityFile", NULL, "file_id", "entity_id")
#3 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Batch/BAO/Batch.php(172): CRM_Batch_BAO_Batch::getBatchList((Array:31))
#4 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Batch/Page/AJAX.php(100): CRM_Batch_BAO_Batch::getBatchListSelector((Array:31))
#5 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(277): CRM_Batch_Page_AJAX::getBatchList()
#6 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(85): CRM_Core_Invoke::runItem((Array:12))
#7 /home/jon/local/agbud8/htdocs/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#8 /home/jon/local/agbud8/htdocs/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:3))
#9 /home/jon/local/agbud8/htdocs/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(75): Drupal\civicrm\Civicrm->invoke((Array:3))
#10 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:3), "")
#11 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#12 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#13 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#14 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#15 /home/jon/local/agbud8/htdocs/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#16 /home/jon/local/agbud8/htdocs/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#17 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#18 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#19 /home/jon/local/agbud8/htdocs/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#20 /home/jon/local/agbud8/htdocs/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#21 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#22 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#23 /home/jon/local/agbud8/htdocs/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#24 /home/jon/local/agbud8/htdocs/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#25 /home/jon/local/agbud8/htdocs/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#26 {main}
```5.18.0https://lab.civicrm.org/dev/financial/-/issues/57Payments - Where do we store IDs from payment processor?2022-01-04T06:27:07Zmattwiremjw@mjwconsult.co.ukPayments - Where do we store IDs from payment processor?On contributions there are two fields that can be used to store unique values - trxn_id and invoice_id. trxn_id is the only one that we can actually because the workflows ignore invoice_id in various places. For recurring contributions...On contributions there are two fields that can be used to store unique values - trxn_id and invoice_id. trxn_id is the only one that we can actually because the workflows ignore invoice_id in various places. For recurring contributions we have trxn_id and processor_id and here we have to set both to the same value because they are used inconsistently in the code. Then there are the individual payments which can store their own trxn_id.
Looking at Stripe we have:
* `charge_id` - changes each time a payment is attempted - matches best to `civicrm_financial_trxn.trxn_id` (but currently we save on civicrm_contribution.trxn_id).
* `invoice_id` - may have multiple charge_id's for example if a payment attempt fails and is retried. So this should really be the trxn_id on the contribution (we don't currently store it).
* `subscription_id` - for a recurring contribution this represents the plan so maps directly to `civicrm_contribution_recur` and could be saved in either `civicrm_contribution_recur.trxn_id` or `civicrm_contribution_recur.processor_id`.
The problem is that the way CiviCRM works internally (and API functions such as Contribution.completetransaction don't really allow us to work in the way we'd like).
UPDATE - the resolution here has been to
1) Add a field order_reference to the civicrm_financial_trxn table. The reason for adding is to this table even though it 'represents' the contribution / order is that it's possible not all payments on one contribution are by the same processor - hence it's up to the processor to manage this field
2) Matt felt that civicrm_financial_trxn.result_code met his needs for a descriptionmattwiremjw@mjwconsult.co.ukmattwiremjw@mjwconsult.co.ukhttps://lab.civicrm.org/dev/financial/-/issues/55Support storing IPNs in `civicrm_system_log` for processors that send JSON data2019-10-24T19:14:29ZJonGoldSupport storing IPNs in `civicrm_system_log` for processors that send JSON dataCurrently, `CRM_Core_Payment::logPaymentNotification()`, the method which logs to `civicrm_system_log` uses `$_REQUEST` to grab the POST data. However, `$_REQUEST` doesn't handle raw POST data, it assumes it's form-encoded. This patch ...Currently, `CRM_Core_Payment::logPaymentNotification()`, the method which logs to `civicrm_system_log` uses `$_REQUEST` to grab the POST data. However, `$_REQUEST` doesn't handle raw POST data, it assumes it's form-encoded. This patch handles JSON-encrypted POST requests, notably Stripe, so they can be stored in `civicrm_system_log`.5.16.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/54Bug in storing settings for CiviContribute component2019-05-22T21:08:07ZJoachimBug in storing settings for CiviContribute component**Problem**
The two settings of the CiviContribute component
* Always post to Accounts Receivable?
* Enable Deferred Revenue?
do not have any effect on how financial transactions are created, although they apparently should.
**Probab...**Problem**
The two settings of the CiviContribute component
* Always post to Accounts Receivable?
* Enable Deferred Revenue?
do not have any effect on how financial transactions are created, although they apparently should.
**Probable Cause**
In general, settings are stored in the table civicrm_setting, one setting per row. There is one exception: All settings for the CiviContribute component are stored combined within one single row.
The storing of the settings for the two checkboxes mentioned above deviates from this principle: Two distinct rows are generated for the settings. These rows are also accessed to display their respective values within the settings form (i.e. once checked, the checkboxes remain checked at a later display of the settings page).
HOWEVER, when reading from the settings table within the program code, just the combined row gets accessed for all CiviComponent related settings (e.g. for 'deferred_revenue_enabled'). (See function checkContributeSettings($name = NULL, $checkInvoicing = FALSE) in file Contribution.php).
Therefore the settings get de facto ignored, when they should control how transactions get generated based on their values.
I tried to manually change the combined data row in the database, which actually made the settings work as expected. See also this [StackExchange entry](https://civicrm.stackexchange.com/questions/30559/bug-in-settings-for-civicontribute-component) .5.15.0https://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/50New contribution may overwrite other contribution if it's opened in other tab2020-01-15T09:10:47ZPatrick Figelpfigel@greenpeace.orgNew contribution may overwrite other contribution if it's opened in other tabWhen creating new contributions, existing ones may be overwritten if they were opened in a separate tab at some point after opening the "Record Contribution" form.
This was reproduced against master and 5.7.
**Steps to reproduce:**
1. ...When creating new contributions, existing ones may be overwritten if they were opened in a separate tab at some point after opening the "Record Contribution" form.
This was reproduced against master and 5.7.
**Steps to reproduce:**
1. Open Contact A and open the "Record Contribution" form.
2. Open Contact B in a new tab and click on "View" or "Edit" on one of their contributions.
3. Go back to the first tab
4. Fill in the form and save the contribution.
**Expected result:**
Contact A should have a new contribution.
**Actual result:**
Contact A does not have a new contribution, and the contribution from step 2 was overwritten with values from the "Record Contribution" form.
---
I'd guess session variables are used in a place where you don't really want to use session variables.5.16.0https://lab.civicrm.org/dev/financial/-/issues/49No way to customize contribution receipt based on individual entering data wh...2021-11-23T17:28:26ZJonGoldNo way to customize contribution receipt based on individual entering data when giving "On behalf of" an organizationWhen giving on behalf of an organization, we don't store the contact ID of the person who actually entered the contribution, nor do we pass it to the receipt in `$tplParams`. My PR will resolve the latter issue, since it's a safe fix th...When giving on behalf of an organization, we don't store the contact ID of the person who actually entered the contribution, nor do we pass it to the receipt in `$tplParams`. My PR will resolve the latter issue, since it's a safe fix that doesn't affect folks who don't choose to use its functionality.JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/48Recording a contribution that completes a pending payment should update Date ...2019-03-29T18:03:39ZJonGoldRecording a contribution that completes a pending payment should update Date ReceivedI know the long-term solution is #43 - remove redundant fields from the Contribution entity - but this seems worthwhile as a short-term fix.
Pending payments require a "Date Received" - which is a bit counterintuitive but necessary beca...I know the long-term solution is #43 - remove redundant fields from the Contribution entity - but this seems worthwhile as a short-term fix.
Pending payments require a "Date Received" - which is a bit counterintuitive but necessary because of the pre-Civi 4.3 data model. However, recording a payment to complete a contribution should update the Date Received.
Posting here to get concept approval before moving forward.https://lab.civicrm.org/dev/financial/-/issues/47Payment Instrument not set on Pending Contributions' payments when marked "Co...2019-12-17T22:10:48ZJonGoldPayment Instrument not set on Pending Contributions' payments when marked "Completed".There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment b...There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **More » Record Payment** and entering the payment.
* Click the **pencil** to edit the resulting payment. Everything looks fine.
#### Scenario 2
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **Edit** and changing the contribution status to **Completed**.
* Click the **pencil** to edit the resulting payment. The payment instrument is blank. Moreover, any attempt to change the payment instrument results in a fatal error (similar to core#264). See below.
The backtrace below seems like a symptom of the root cause, which is in the second step (changing the contribution status) not the third step.
```
CiviCRM_API3_Exception: "Mandatory key(s) missing from params array: payment_instrument_id"
#0 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(213): civicrm_api3("FinancialTrxn", "create", (Array:9))
#1 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(181): CRM_Financial_Form_PaymentEdit->submit((Array:5))
#2 /example.org/sites/all/modules/civicrm/CRM/Core/Form.php(489): CRM_Financial_Form_PaymentEdit->postProcess()
#3 /example.org/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Submit.php(74): CRM_Core_Form->mainProcess()
#4 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Submit->perform(Object(CRM_Financial_Form_PaymentEdit), "submit")
#5 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Financial_Form_PaymentEdit), "submit")
#6 /example.org/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("submit")
#7 /example.org/sites/all/modules/civicrm/CRM/Utils/Wrapper.php(113): CRM_Core_Controller->run()
#8 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(283): CRM_Utils_Wrapper->run("CRM_Financial_Form_PaymentEdit", NULL, NULL)
#9 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:14))
#10 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#11 /example.org/sites/all/modules/civicrm/drupal/civicrm.module(345): CRM_Core_Invoke::invoke((Array:3))
#12 [internal function](): civicrm_invoke("payment", "edit")
#13 /example.org/includes/menu.inc(350): call_user_func_array("civicrm_invoke", (Array:2))
#14 /example.org/index.php(22): menu_execute_active_handler()
#15 {main}
```https://lab.civicrm.org/dev/financial/-/issues/45Custom fields ignored when searching in "Accounting Batch" mode2019-02-11T21:15:55ZJonGoldCustom fields ignored when searching in "Accounting Batch" modeSteps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
...Steps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
* Go to **Contributions » Accounting Batches » New Batch**. Perform the same search. The custom field criterium is ignored.