Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2019-11-01T12:04:35Zhttps://lab.civicrm.org/dev/financial/-/issues/92Change signature of CRM_Core_Payment::doRefund(&$params) to not receive $para...2019-11-01T12:04:35ZeileenChange signature of CRM_Core_Payment::doRefund(&$params) to not receive $params as a referenceThis is a proposal by @mattwire which is mostly stylistic
pros - we have been moving away from receiving as reference
- less scope for people to try to achieve odd things in there
cons - less consistent with doPayment
- would...This is a proposal by @mattwire which is mostly stylistic
pros - we have been moving away from receiving as reference
- less scope for people to try to achieve odd things in there
cons - less consistent with doPayment
- would need to do a civi universe or whatever that things is of Tims to find what processors might need to be patched to cope
- less opportunity for payment processors to tweak thingshttps://lab.civicrm.org/dev/financial/-/issues/91Discuss / maybe resolve schema issue on changing line items2019-10-25T22:17:31ZeileenDiscuss / maybe resolve schema issue on changing line itemsPer
https://docs.civicrm.org/dev/en/latest/financial/financialentities/
If the line items change then the items financial items have to be updated. Generally the rule is to zero-out the current line items
and reverse their financial ite...Per
https://docs.civicrm.org/dev/en/latest/financial/financialentities/
If the line items change then the items financial items have to be updated. Generally the rule is to zero-out the current line items
and reverse their financial items and create new ones. This is a pretty standard accounting approach.
Unfortunately there are some scenarios where the schema does not permit this which has resulted in
adjustment line items being created in these cases. The issue is that the civicrm_line_item table has a unique index for
entity_table + entity_id + contribution_id + price_field_value_id + price_field_id.
This means that if a line item with no price_field_values (ie a text / enter quantity line item) is altered it is not possible
to create a reversal line a new line within the schema. The same problem occurs when changing a line item with price_field_values
BACK to a price_field_value it previously held. In both these scenarios the work around is to have more than one 'valid' financial_item
against the resulting line item with an 'adjustment' entry - ie an additional financial_item.
I don't have any good answers except maybe add an 'is_current' field & add that to the index. Perhaps the current pain is unavoidable but it feels a bit like an own goal
@JoeMurray @monish.deb @lcdweb @kcristiano @pradeephttps://lab.civicrm.org/dev/financial/-/issues/90Add new api Order functionality to update line items2019-10-25T08:12:07ZeileenAdd new api Order functionality to update line itemsI'm pretty sure that despite @JoeMurray's optimism the current apiv3 Order.create doesn't support this. @monish.deb & I discussed adding it back here
https://github.com/civicrm/civicrm-core/pull/11380
I don't think we should add it o a...I'm pretty sure that despite @JoeMurray's optimism the current apiv3 Order.create doesn't support this. @monish.deb & I discussed adding it back here
https://github.com/civicrm/civicrm-core/pull/11380
I don't think we should add it o apiv3 now - I think we should write a v4 api that does it. I think the object oriented approach will allow us to come up with cleaner methods. I'm kinda keen to try to build those up on a ORDER pseudoBAO class & play a bit before we expose in the api so we can learn about about what works & doesn't before locking it inhttps://lab.civicrm.org/dev/financial/-/issues/87Partial Refunds2022-06-14T18:38:44Zmattwiremjw@mjwconsult.co.ukPartial RefundsStripe supports partial refunds via the Stripe Dashboard. I think other processors support similar.
To record a partial refund in CiviCRM we can record a negative payment on the contribution using API `Payment.create`.
Currently nothin...Stripe supports partial refunds via the Stripe Dashboard. I think other processors support similar.
To record a partial refund in CiviCRM we can record a negative payment on the contribution using API `Payment.create`.
Currently nothing changes on the contribution:
* Total amount still shows the full amount but payments are recorded correctly so the sum of payments does not equal the contribution total amount.
* Contribution status remains Completed.
What should happen(?):
* A partial refund means that the total_amount paid, tax_amount and the fee_amount paid may be reduced.
* The contribution status is no longer "Completed" and should be `Partially refunded` (does not exist)? `Partially paid` (already exists).
* The `Financial Type` should be displayed correctly for the refund payment.
Currently, viewing a contribution, either in the summary or detail gives no indication of the actual amount paid:
![image](/uploads/39a50dd48d946207feda438321850a39/image.png)
![image](/uploads/63cc3abf7df50ac1babcbff85f2d4c86/image.png)
@JoeMurray @eileen @artfulrobot @ayduns Thoughts please?https://lab.civicrm.org/dev/financial/-/issues/85UI in core for processing refunds2019-10-21T21:48:01ZeileenUI in core for processing refundsWe looked at adding the ability to process refunds via the UI at the sprint.
We looked at
1) Changing the existing record refund form (Additional Payment form) to provide the option of processing the refund if offered by the processor ...We looked at adding the ability to process refunds via the UI at the sprint.
We looked at
1) Changing the existing record refund form (Additional Payment form) to provide the option of processing the refund if offered by the processor if a check box was selected
1) Changing the existing record refund form (Additional Payment form) to provide the option of processing the refund if offered by the processor if a differently named button was pressed
1) Having a second action for 'Process Refund' or similar
Opinions at Barcelona were pretty evenly divided between the 3!
A couple of things that might make a difference
1) here is a screen shot of how adding a payment currently looks
![Screen_Shot_2019-10-21_at_7.57.12_PM](/uploads/08d0eb711f4dd11fe0a980b8f92f949c/Screen_Shot_2019-10-21_at_7.57.12_PM.png)
1) @JoeMurray was keen that it be a case of the option showing if ALL payments on a contribution could be refunded. In the edge case of payments from more than one processor the submit refund option would not show
1) @JoeMurray agreed that it is OK to ALWAYS show 'record payment' & 'record refund' as opposed to currently it only shows 'add payment' if there it a balance to pay & add 'record refund' if there is a balance to refund. However, we need to be able to overpay & over refund - I'm going to work on this issue & seeing the UI afterwards (just having the links more often visible) might affect what people think 'makes sense' - issue for that is https://lab.civicrm.org/dev/financial/issues/86https://lab.civicrm.org/dev/financial/-/issues/83Barcelona sprint financials2019-11-01T12:05:38ZeileenBarcelona sprint financialsI'm creating this issue to document & track the discussions we had at the Barcelona sprint.
We had a financial team of @mattwire @JoeMurray @ayduns @artfulrobot @BjoernE @andrei @ejegg present
Main issues
1. Ensuring there were ...I'm creating this issue to document & track the discussions we had at the Barcelona sprint.
We had a financial team of @mattwire @JoeMurray @ayduns @artfulrobot @BjoernE @andrei @ejegg present
Main issues
1. Ensuring there were no blockers to people using the Order.create->PaymentProcessor.pay->Payment.create flow https://lab.civicrm.org/dev/financial/issues/76
1. Making the poor performance associated with the creditnote_id field opt in rather than opt out https://lab.civicrm.org/dev/financial/issues/84
1. Addressing Stripe's need to store some Stripe generated information for which there is no suitable field. We resolved this at the data level by adding the field civicrm_financial_trxn.result_code. However docs pending! https://lab.civicrm.org/dev/financial/issues/57
1. Having a plan to get off our broken contribution.template model https://lab.civicrm.org/dev/financial/issues/6
1. UI for permitting refunds processing for payments. https://lab.civicrm.org/dev/financial/issues/85
Not actually from the sprint but topical from discussions - add getters & setters to payment processor base class https://lab.civicrm.org/dev/financial/issues/82https://lab.civicrm.org/dev/financial/-/issues/81Update Contribution Payment Instrument Id to match first payment when the st...2019-11-01T20:59:49ZeileenUpdate Contribution Payment Instrument Id to match first payment when the status is PendingIf we are asking people to create a pending Order they may not know the payment instrument at that time. We should adjust Payment.Create to update it when a payment comes in & it is the first one.
(Alternatively we could always update ...If we are asking people to create a pending Order they may not know the payment instrument at that time. We should adjust Payment.Create to update it when a payment comes in & it is the first one.
(Alternatively we could always update it so it becomes the latest - probably an edge case)https://lab.civicrm.org/dev/financial/-/issues/78Order api should probably create an invoice ID2020-01-13T09:38:31ZeileenOrder api should probably create an invoice IDCurrently contribute.transact api does this -it makes sense to do it at the order level - for create.Currently contribute.transact api does this -it makes sense to do it at the order level - for create.https://lab.civicrm.org/dev/financial/-/issues/76Metaissue for ensuring our preferred order->pay->createPayment flow is used ...2023-11-23T06:59:31ZeileenMetaissue for ensuring our preferred order->pay->createPayment flow is used everywhere.We have long had the principle (since 4.6 was pre-alpha) that we want to work towards the following flow at a code level.
1. Create a pending Order using Order.create api
1. Optionally process a payment against that order using PaymentP...We have long had the principle (since 4.6 was pre-alpha) that we want to work towards the following flow at a code level.
1. Create a pending Order using Order.create api
1. Optionally process a payment against that order using PaymentProcessor.pay api
1. Create a payment record (either from above or just recording an offline payment) using Payment.create api
The expectation is that the code correctly creates a pending contribution (order) with all the related entities when Order.create is called.
When a payment is added the related entities are updated & if appropriate notification emails are sent out.
(Note an earlier iteration of this was to create a pending contribution always & then update it with contribution.completetransaction - this maps to the above as the Order.create creates the pending contribution and Payment.create calls contribution.completetransaction when the payment completes the order).
This issue is a metaissue to link to & categorise all the things that need to be done to reach this. 'High' Priority are any issues that stand before people adopting the recommended flow.
| Item | Status| Priority| Blockers|Notes|
| ------ | ------ |------ | ------ |------ |
| Document order api / Pseudoentity | In progress|High| - |At the [sprint this was started](https://docs.civicrm.org/dev/en/latest/financial/OrderAPI/)[Current tweak](https://github.com/civicrm/civicrm-dev-docs/pull/704)|
|~~Deprecate creating orders with non-pending status~~|Done|High||||
|~~Order.create should not require total amount~~|Done|High|||https://lab.civicrm.org/dev/financial/issues/73|
|Identify any issues that would block someone moving off a non-preferred flow to our preferred flow|Started|High||This is really what this issue is about|
| Update payment instrument id when adding a payment to a pending order|To discuss| High| Discussion| https://lab.civicrm.org/dev/financial/issues/81 and possibly https://lab.civicrm.org/dev/financial/issues/47|
|~~Support invoice_id in PaymentProcessor.pay~~|done|high||https://lab.civicrm.org/dev/financial/issues/77|
| ~~Support chaining Payment.create from Order~~|PR|High||Needed to ease adaption to us deprecating creating Orders as non-pending [pr](https://github.com/civicrm/civicrm-core/pull/15548)|
|Fix identified core bug on ParticipantPayment creation|To do|High|Tests not yet passing| https://lab.civicrm.org/dev/financial/issues/74|
|~~Make contribution_id mandatory for PaymentProcessor.pay~~|Done|High||[PR](https://github.com/civicrm/civicrm-core/pull/15477) - since we have agreed for policy (not technical) reasons to do this we should try to get a test & merged|
| ~~Document moving off transact api~~| Done | Medium||[PR here](https://github.com/civicrm/civicrm-dev-docs/pull/705)|
| Consider generating default invoice ID in Order.create|To do|Medium|Discussion|https://lab.civicrm.org/dev/financial/issues/78|
|~~Add getters & setters to Payment Class~~|Done - could do more maybe| Medium||https://lab.civicrm.org/dev/financial/issues/82|
| ~~Deprecate transact api from explorer~~ | Done |Medium||https://lab.civicrm.org/dev/financial/issues/79|
|~~Deprecate & remove calls to CRM_Contribute_BAO_Contribution::addPayments~~|To do|Low||This is part of consolidating all payment creation on Payment.create|
|Fix all remaining places in core to create a pending contribution/order & then complete|Needs chipping away at - tacking events at the moment|In progress|Low|https://lab.civicrm.org/dev/financial/issues/53|
| ~~Noisily deprecate transact api~~ |Done| low||https://lab.civicrm.org/dev/financial/issues/80|https://lab.civicrm.org/dev/financial/-/issues/75on order.get, line item has obsoleted contribution_type_id2019-10-19T22:49:23ZJoeMurrayon order.get, line item has obsoleted contribution_type_idThe line item table does not have a contribution_type_id. But when the results of a contribution.get are displayed, the line item fields includes both financial_type_id and contribution_type_id. This seems like an historical artifact tha...The line item table does not have a contribution_type_id. But when the results of a contribution.get are displayed, the line item fields includes both financial_type_id and contribution_type_id. This seems like an historical artifact that should be removed.https://lab.civicrm.org/dev/financial/-/issues/74Order.create - registering multiple Participants (participantPayment records ...2020-03-04T23:10:14ZAndrei Mondocandreimondoc@gmail.comOrder.create - registering multiple Participants (participantPayment records not created properly)Creating an Order to register two (or more) participants creates two (or more) `ParticipantPayment` records, one for each participant line item, registering two participants via an Event page creates only one `ParticipantPayment` record ...Creating an Order to register two (or more) participants creates two (or more) `ParticipantPayment` records, one for each participant line item, registering two participants via an Event page creates only one `ParticipantPayment` record regardless of the number of participants registered.
Which is the correct one/what is expected behaviour?
### Steps to reproduce
Call Order.create with parameters similar to:
``` php
$params = [
'total_amount' => 100.00,
'financial_type_id' => 4,
'contribution_status_id' => 'Pending',
'payment_instrument_id' => 1,
'currency' => 'USD',
'source' => 'Multiple participants (Order.create)',
'contact_id' => 2,
'line_items' => [
1 => [
'line_item' => [
0 => [
'price_field_id' => 3,
'label' => 'Tickets',
'financial_type_id' => 4,
'price_field_value_id' => 3,
'qty' => 1,
'field_title' => '1 Ticket',
'unit_price' => 50.000000000,
'line_total' => 50,
'entity_table' => 'civicrm_participant',
],
],
'params' => [
'contact_id' => 2,
'event_id' => 1,
'role_id' => 1,
'source' => 'Multiple participants (Order.create)',
'price_set_id' => 7,
'fee_level' => '1 Ticket',
'fee_amount' => 50,
],
],
2 => [
'line_item' => [
0 => [
'price_field_id' => 3,
'label' => 'Tickets',
'financial_type_id' => 4,
'price_field_value_id' => 3,
'qty' => 1,
'field_title' => '1 Ticket',
'unit_price' => 50.000000000,
'line_total' => 50,
'entity_table' => 'civicrm_participant',
],
],
'params' => [
'contact_id' => 5,
'event_id' => 1,
'role_id' => 1,
'source' => 'Multiple participants (Order.create)',
'price_set_id' => 7,
'fee_level' => '1 Ticket',
'fee_amount' => 50,
],
],
],
];
$order = civicrm_api3('Order', 'create', $params);
```
This results in two ParticipantPayment records:
``` json
// civicrm_participant_payment
[
{
"id": 5,
"participant_id": 5,
"contribution_id": 18
},
{
"id": 6,
"participant_id": 6,
"contribution_id": 18
}
]
```
Registering two or more participants via an Event page, always creates one ParticipantPayment regardless of the number of participants registered.
``` json
// civicrm_participant_payment
{
"id": 7,
"participant_id": 7,
"contribution_id": 19
}
```https://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/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/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/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/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.https://lab.civicrm.org/dev/financial/-/issues/44Modifying contribution amount records a fake payment for difference2019-06-20T19:11:11ZAndie HuntModifying contribution amount records a fake payment for difference1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has be...1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has been recorded.
There's no way to remove the $20 payment, though you can edit the payment method and so forth.
I suspect this is a consequence of partial payments not being fully implemented for contributions, but the effect is unexpected and undocumented.
Another, more troubling outcome:
1. Create a contribution for $100 on the back end, setting the status as `Pending` and leaving the payment method as `Check`.
2. Record a $90 payment with cash.
3. Edit the contribution amount to be $150.
4. Go back to view the contribution and see that there is now a $50 payment by check with the status "partially paid".
5. Go to record a payment and see that the balance owed is $60. Record that payment with EFT as the payment method.
6. See that the contribution now has three payments, for $90 (Cash), $50 (Check), and $60 (EFT) despite only being for a $150 contribution. A "Record refund" link appears, but clicking it causes an error:
> Sorry but we are not able to provide this at the moment.
Finally, fake negative payments can be recorded:
1. Create a contribution for $100 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new -$30 payment by check has been recorded.https://lab.civicrm.org/dev/financial/-/issues/43Find Contributions searches on inaccurate, redundant payment fields2020-07-09T00:48:18ZAndie HuntFind Contributions searches on inaccurate, redundant payment fieldsThis problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to re...This problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to reflect the payment information. This issue is that the Find Contributions search looks only for the value in the contribution record.
When there are multiple payments by check, the check number field on the contribution is updated to have both numbers, separated by a comma. So, the check number is `111,222` if the first check is `111` and the second is `222`. Searching for a contribution with check numbers `111` or `222` will yield nothing, but searching for `111,222` finds it. Obviously this is a bug, but it might properly be considered a bug in search--the search should look among the payments, not the value on the contribution.
Again, like dev/financial#37, the real solution is to ditch the redundant fields. However, in the meantime we should stop relying upon them.
It appears that card number works properly:
* Record contribution, pending pay later (setting payment method to be `Credit Card` to sidestep the problem in dev/financial#37)
* Record payment for part of the amount, payment method `Credit Card` with the card ending in `1234`
* Record payment for the remainder of the amount, payment method `Credit Card` with the card ending in `6789`
* Find contributions, payment method `Credit Card`, card number `1234`, retrieves the contribution.
* Find contributions, payment method `Credit Card`, card number `6789`, retrieves the contribution.
Since there is no card number on the contribution, the search is forced to work the right way.