Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2019-11-12T19:26:41Zhttps://lab.civicrm.org/dev/financial/-/issues/101SQL syntax error in getIncomeFinancialType function2019-11-12T19:26:41ZbunderthebridgeSQL syntax error in getIncomeFinancialType functionI recently upgraded from 5.13.1 to 5.18.4 on a CiviCRM Drupal 7 site that's been around for the past 6 or 7 years. Post upgrade, I'm getting a SQL error whenever caches are cleared and when users try to add new price sets.
The issue se...I recently upgraded from 5.13.1 to 5.18.4 on a CiviCRM Drupal 7 site that's been around for the past 6 or 7 years. Post upgrade, I'm getting a SQL error whenever caches are cleared and when users try to add new price sets.
The issue seems to be in public static function getIncomeFinancialType() in FinancialType.php. $relationTypeId seems to be returning empty on line 186.
Here's the error:
~~~
Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -2
[message] => DB Error: syntax error
[mode] => 16
[debug_info] => SELECT id, entity_id
FROM civicrm_entity_financial_account
WHERE ( account_relationship = AND entity_table = 'civicrm_financial_type' )
ORDER BY entity_id
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND entity_table = 'civicrm_financial_type' )
ORDER BY entity_id' at line 4]
[type] => DB_Error
[user_info] => SELECT id, entity_id
FROM civicrm_entity_financial_account
WHERE ( account_relationship = AND entity_table = 'civicrm_financial_type' )
ORDER BY entity_id
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND entity_table = 'civicrm_financial_type' )
ORDER BY entity_id' at line 4]
[to_string] => [db_error: message="DB Error: syntax error" code=-2 mode=callback callback=CRM_Core_Error::handle prefix="" info="SELECT id, entity_id
FROM civicrm_entity_financial_account
WHERE ( account_relationship = AND entity_table = 'civicrm_financial_type' )
ORDER BY entity_id
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND entity_table = 'civicrm_financial_type' )
ORDER BY entity_id' at line 4]"]
)
~~~
Any suggestions for how to fix? I initially thought there was a schema problem, but am relatively sure that's not it. Setting $relationTypeId to '1' seems to keep the error from throwing on cache clear, but doesn't fix the price set problem.https://lab.civicrm.org/dev/financial/-/issues/100Membership form permits creating invalid transactions2019-11-17T19:31:19ZeileenMembership form permits creating invalid transactionsI discovered you can do this... ie choose to add a 'partially paid contribution'
![Screen_Shot_2019-11-07_at_9.21.34_AM](/uploads/a7c343da47e0a01e8c1308a95ba0fc44/Screen_Shot_2019-11-07_at_9.21.34_AM.png)
& all bets are off if you do -...I discovered you can do this... ie choose to add a 'partially paid contribution'
![Screen_Shot_2019-11-07_at_9.21.34_AM](/uploads/a7c343da47e0a01e8c1308a95ba0fc44/Screen_Shot_2019-11-07_at_9.21.34_AM.png)
& all bets are off if you do - certainly in terms of data integrity as no financial_trxn record is created.
We should remove that status - probably the entire field from that screen & just accept 'amount' & maaaayyyybe payment status....5.21.0https://lab.civicrm.org/dev/financial/-/issues/99Confusing text on Refund receipt2019-11-08T21:18:22ZeileenConfusing text on Refund receiptAs pointed out by @magnolia
https://github.com/civicrm/civicrm-core/pull/15705#issuecomment-549041527
----------------------------------------------
A side-catch I discovered is a wrong amount for the amount paid in the notification ma...As pointed out by @magnolia
https://github.com/civicrm/civicrm-core/pull/15705#issuecomment-549041527
----------------------------------------------
A side-catch I discovered is a wrong amount for the amount paid in the notification mail
![Screenshot from 2019-11-02 14-03-02](https://user-images.githubusercontent.com/2195908/68071350-187a0c80-fd7a-11e9-8679-26317701c0e9.png)
This should be:
```
Total amount: 50
You paid: 100
Refund amount: -50
```
I don't think this is a regression - we assign $totalPaid to the template & it is used as
```
{if $isRefund}
<tr>
<th {$headerStyle}>{ts}Refund Details{/ts}</th>
</tr>
<tr>
<td {$labelStyle}>
{ts}Total Amount{/ts}
</td>
<td {$valueStyle}>
{$totalAmount|crmMoney}
</td>
</tr>
<tr>
<td {$labelStyle}>
{ts}You Paid{/ts}
</td>
<td {$valueStyle}>
{$totalPaid|crmMoney}
</td>
</tr>
<tr>
<td {$labelStyle}>
{ts}Refund Amount{/ts}
</td>
<td {$valueStyle}>
{$refundAmount|crmMoney}
<td>
</tr>
{else}
```
@magnolia - perhaps we can tweak the tpl to make more sense without making too much change here? Even a simplification
If we can come up with a simple tpl tweak I'm OK to squeeze it into 5.20 - even if it is branched - due to the general tpl load in there5.20.0https://lab.civicrm.org/dev/financial/-/issues/98Allocation issue Multi Event Registrations with checkboxes2019-11-17T19:26:31ZkcristianoAllocation issue Multi Event Registrations with checkboxesFollow up to #94
Using Existing Database
Registered for event:
Choose Basic Registration
Price set line line items options for Event, Guest Fee, and Extra Meals -- All Checkboxes
Event 820
Guest 100
Meals 225
Total 1,145.00
Edit...Follow up to #94
Using Existing Database
Registered for event:
Choose Basic Registration
Price set line line items options for Event, Guest Fee, and Extra Meals -- All Checkboxes
Event 820
Guest 100
Meals 225
Total 1,145.00
Edited Event
Changed selections
Remove meals (Checkboxes)
Recorded refund $225
Contribution status shows $920
![image](https://user-images.githubusercontent.com/1892544/68250218-6eef8100-ffee-11e9-924c-931998a88bdb.png)
However, Bookkeeping report shows -225
![image](https://user-images.githubusercontent.com/1892544/68250636-4fa52380-ffef-11e9-94e6-6c8e9407af9b.png)
In SQL
The contribution looks as expected:
```
select c.id,c.contact_id,c.total_amount,c.fee_amount,c.net_amount,c.trxn_id,c.receive_date,c.contribution_status_id,cov.name
from civicrm_contribution c
join civicrm_option_value cov on cov.value = c.contribution_status_id and cov.option_group_id = 11 and cov.value = c.contribution_status_id where c.id = 16095
```
![image](https://user-images.githubusercontent.com/1892544/68252348-4918ab00-fff3-11e9-9abb-48fce6d85d50.png)
The Line Items are fine
```
select li.id,li.entity_table,li.entity_id,li.contribution_id,li.label,li.line_total,li.financial_type_id,ft.name
from civicrm_line_item li join civicrm_financial_type ft on ft.id = li.financial_type_id where li.contribution_id = 16095
```
![image](https://user-images.githubusercontent.com/1892544/68251218-a7905a00-fff0-11e9-820e-081e4e30835b.png)
civicrm_financial_trxn appears to be where we start to go off
```
select cft.id,cft.from_financial_account_id, cft.to_financial_account_id,cft.trxn_date,cft.trxn_id, cft.total_amount,cft.status_id
from civicrm_financial_trxn cft
where cft.id >= '18121'
```
![image](https://user-images.githubusercontent.com/1892544/68252153-b5df7580-fff2-11e9-877d-206ff391b428.png)
The issue appears to be in civicrm_entity_financial_trxn
```select eft.* from civicrm_entity_financial_trxn eft
join civicrm_financial_trxn cft on cft.id = eft.financial_trxn_id and cft.trxn_date >= '2019-11-04'
where eft.id >= 77057
order by eft.financial_trxn_id
```
![image](https://user-images.githubusercontent.com/1892544/68251759-cd6a2e80-fff1-11e9-9582-3148b264a3a3.png)
This may be an issue with Data Types (Checkboxes) or an issue with this client Database.
Will comment with Steps to reproduce on a clean d7master/wpmaster
If I cannot reproduce, I will close.kcristianokcristianohttps://lab.civicrm.org/dev/financial/-/issues/97Contribution paid via Stripe as payment processor - no financial transaction ...2023-08-18T09:35:57ZJoachimContribution paid via Stripe as payment processor - no financial transaction for fee amount gets generatedWhen making a contribution (in my case for purchasing a membership), there is a different behavior, whether the Dummy Processor or Stripe gets used as a payment provider - the financial type is in both cases identical:
* The contributi...When making a contribution (in my case for purchasing a membership), there is a different behavior, whether the Dummy Processor or Stripe gets used as a payment provider - the financial type is in both cases identical:
* The contribution via the Dummy Processor does create a separate financial transaction for the processing fee (using the configured expenses account for banking fees).
* The contribution via Stripe does result in the correct fee amount recorded in the contribution details, but no transaction gets created.
When doing a batch export of these contributions, I have trouble doing a reconciliation of the transactions without the transactions for the processing fees. Since the expenses account is configured, I suspect that the intended behavior should be the one of the dummy processor.
I just tested these scenarios on a clean installation of version 5.18.4 under Wordpress with Stripe extension 6.2https://lab.civicrm.org/dev/financial/-/issues/96Unreleased regression - fatal when recording part-payment against a pending c...2019-12-04T05:45:51ZeileenUnreleased regression - fatal when recording part-payment against a pending contribution (conditions apply)Our just-merged fix on line item allocation hits an issue when there are no financial items as it turns out.
Per https://github.com/civicrm/civicrm-dev-docs/issues/712 for historical (and perhaps unwise) reasons there are circumstances ...Our just-merged fix on line item allocation hits an issue when there are no financial items as it turns out.
Per https://github.com/civicrm/civicrm-dev-docs/issues/712 for historical (and perhaps unwise) reasons there are circumstances where line items are created with no financial items. We need to handle that in the payment.create function. I hope to look tomorrow
FYI @kcristianohttps://lab.civicrm.org/dev/financial/-/issues/94Incorrect Allocation of refunded line items on Multi Event Registrations2019-11-11T12:49:53ZkcristianoIncorrect Allocation of refunded line items on Multi Event RegistrationsFollow up to https://lab.civicrm.org/dev/financial/issues/34
See https://github.com/civicrm/civicrm-core/pull/14763
PR 14763 moves the issue forward, adds tests and fixes (for the most part) adding additional items to event registratio...Follow up to https://lab.civicrm.org/dev/financial/issues/34
See https://github.com/civicrm/civicrm-core/pull/14763
PR 14763 moves the issue forward, adds tests and fixes (for the most part) adding additional items to event registrations.
This issue is to track what work needs to be done to correct refunds and other issues we have uncovered.
After PR 14763 is merged the gaps expected are:
- receive date is updated for all line items not just the affected line items
- refunds still need to be handled
- ~~null accounts in bookkeeping report~~
- test with taxes
- test with live Payment processor to reflect fees
This is a ample bookig report that shows the issue with Null Accounts:
![bkkeeping-patch-34-null](/uploads/9bbe92aa8d0130fb096af946f55e84ef/bkkeeping-patch-34-null.jpg)
I have exported and reviewed the data in this spreadsheet:
[Report_20191029-1047.ods](/uploads/250b04c4a3ad6b8eb9fc09ced7c0ecfe/Report_20191029-1047.ods)
I ran an number of sql select statements to review the data after editing the transaction:
[14763-contrb-line-ietems.txt](/uploads/f3829452c0e0adc7152acfd7649a4d5e/14763-contrb-line-ietems.txt)
@eileen Please edit and add any comments.https://lab.civicrm.org/dev/financial/-/issues/89A contribution batch containing transactions of more than one currencies caus...2022-01-09T23:43:19ZkleehkA contribution batch containing transactions of more than one currencies causes fatal errorMy setup: CiviCRM 5.18.3 on Drupal 7.
I created a Contribution batch. At transactions I chose two transactions of difference currencies e.g. HKD and USD and Assign them to the batch.
Then I no longer be able to retrieve the list of bat...My setup: CiviCRM 5.18.3 on Drupal 7.
I created a Contribution batch. At transactions I chose two transactions of difference currencies e.g. HKD and USD and Assign them to the batch.
Then I no longer be able to retrieve the list of batches because of fatal error: Dialog: DataTables warning: table id=crm-batch-selector-2 - Ajax error. For more information about this error, please see http://datatables.net/tn/7
Even I cancel the offending transaction it does not help. I had to delete the transaction in that batch to revive the batch's functioning.
Originally posted at StackExchange
[Link here](https://civicrm.stackexchange.com/questions/33382/a-contribution-batch-containing-transactions-of-more-than-one-currencies-causes)
```
Oct 17 09:53:08 [debug] $backTrace = #0
/var/www/c53/web/sites/all/modules/civicrm/CRM/Core/Error.php(463):
CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/c53/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(55): CRM_Core_Error::handleUnhandledException(Object(CRM_Core_Exception))
#2 /var/www/c53/web/sites/all/modules/civicrm/drupal/civicrm.module(444): CRM_Core_Invoke::invoke((Array:3))
#3 /var/www/c53/web/includes/menu.inc(527): civicrm_invoke("ajax", "batchlist")
#4 /var/www/c53/web/index.php(21): menu_execute_active_handler()
#5 {main}
```
Attached please see the error screen capture![MixedCurrencyError](/uploads/a472c5fec8af87b6b62e8e13342c9c99/MixedCurrencyError.png).5.47.0JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/88Should we add is_deleted to the civicrm_contribution table?2019-10-24T11:38:33ZeileenShould we add is_deleted to the civicrm_contribution table?Despite @JoeMurray's best efforts we DO all contributions to be deleted. We do have precedent on other tables for soft deletions via an is_deleted flag. The difficulty with switching to that is it takes time to filter out possible places...Despite @JoeMurray's best efforts we DO all contributions to be deleted. We do have precedent on other tables for soft deletions via an is_deleted flag. The difficulty with switching to that is it takes time to filter out possible places of leakage.
However, we have just added is_template to the civicrm_contribution table (https://lab.civicrm.org/dev/financial/issues/72) on the understanding we will put the time into filtering out leakage over a few releases before starting to use it (& initially not in core) - which makes me wonder if we should add is_deleted & do the work on that at the same time & perhaps add an extension for soft deleting for those who want to be ahead of the game.
@JoeMurray @BjoernE @mattwire @ejegg @pradeep @monish.deb @ayduns @artfulrobot - any thoughts?https://lab.civicrm.org/dev/financial/-/issues/84Making the poor performance associated with the creditnote_id field opt in r...2021-03-31T02:07:56ZeileenMaking the poor performance associated with the creditnote_id field opt in rather than opt outSometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers pe...Sometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers permitted a prefix & had to be sequential. However, anecdotally most large sites have hacked it out because the performance is so bad.
During the Barcelona sprint a [patch was merged](https://github.com/civicrm/civicrm-core/pull/15232) making it possible to install [an extension](https://github.com/greenpeace-cee/at.greenpeace.creditnope) to opt out of having a credit note sloooowwwly calculated.
However, in the world of Lexim use-case specific functionality should be OPT IN rather than opt out. Ie it should be the case that you need to install an extension to GET the slow behaviour not to NOT get it.
This is also a good test case for the general practice of moving functionality out of core into an extension. Here are the steps I believe are required
1) Determine where the code interacts with core. I did this & determined that all the places where createCreditNoteID is called from other than Contribution.create are not hit & I added a [pr to deprecate them](https://github.com/civicrm/civicrm-core/pull/15492) & fix the one place where it is hit. As a result of this the only interaction required would be in the pre_hook so we don't need to add a hook to generate this field (per https://lab.civicrm.org/dev/core/issues/1308) - this is a good thing as the assumption that credit notes & contributions would not be many to one is flawed & we don't want to bake this into core - we want to get it out of core
2) Create an extension that can be installed to add the credit note id in the pre hook.
3) Get the extension reviewed & approved for automatic installation
4) Add this new extension so it is installed on upgrade for existing sites - this step will require some input from @totten on how to do it & not knowing how is a blocker but probably getting the extension ready is a necessary pre-step & is probably only a couple of hours of work
Also we should consider this proposed performance improvement https://github.com/civicrm/civicrm-core/pull/15235https://lab.civicrm.org/dev/financial/-/issues/80Noisily deprecate transact api2019-10-24T21:16:11ZeileenNoisily deprecate transact apiWe should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/79We should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/795.20.0https://lab.civicrm.org/dev/financial/-/issues/79Deprecate Contribute.transact api2019-10-24T21:15:57ZeileenDeprecate Contribute.transact apiThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussionThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussion5.20.0https://lab.civicrm.org/dev/financial/-/issues/77PaymentProcessor.pay should handle 'invoice_id' & map it to a getter so pro...2019-11-04T23:47:09ZeileenPaymentProcessor.pay should handle 'invoice_id' & map it to a getter so processors can retrieve it5.20.0https://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.2