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/86Make 'Record Payment' & 'Record Refund' visible regardless of whether the bal...2020-09-16T00:27:09ZeileenMake 'Record Payment' & 'Record Refund' visible regardless of whether the balance 'requires' onePer https://lab.civicrm.org/dev/financial/issues/85
@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'...Per https://lab.civicrm.org/dev/financial/issues/85
@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'
I did start on this but discovered a regression when I started writing my preliminary test so it's on hold while that gets merged through to masterhttps://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/82Develop getter & setter structure for Payment classes2021-05-31T22:31:04ZeileenDevelop getter & setter structure for Payment classesI don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.
This has caused us issues with inconsistencies arou...I don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.
This has caused us issues with inconsistencies around how payment processors determine variables. It also makes it really hard to clean up the code that interacts with payment processors as the code spends a lot of time buying arrays which go off into the void.
I'm pretty sure that if we were designing from scratch we would make it look much more like
```
$paymentObject = $this->getPaymentObject();
$paymentObject
->setContributionID(5)
->setContactID->(6)
->setAmount(50)
->setInvoiceID('xyz')
->setRecurringFrequency(1)
->setRecurringUnit('week')
....
->doPayment();
$feeAmount = $paymentObject->getFeeAmount();
```
We might provide some helpers etc but that seems much more inline with modern coding conventions and with our desire for standardisation.
I believe we should start adding getters & setters & encouraging payment processors to use them. The getters would do any normalisation of parameters (I'm looking at you currency vs currencyID).
It would be quite some time before this usage has 'flowed through the system' & we switch to relying on it when making payments but I think that adding this structure sets us up well for the future.
See PR for proposed change - which will not ACTUALLY change anything other than make these methods available in the first instance
https://github.com/civicrm/civicrm-core/pull/15509
@artfulrobot @KarinG @adixon @mattwire @andrewhunt
(Payment\PropertyBag)https://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/64Authorize.net - support future dated transactions via contribution page2019-09-10T17:28:18ZlcdwebAuthorize.net - support future dated transactions via contribution pageProvide an option to allow contribution pages implementing Authorize.net to expose a field where the user can select a future date for the transaction. This would be patterned after the iATS future date implementation.
* add A.net conf...Provide an option to allow contribution pages implementing Authorize.net to expose a field where the user can select a future date for the transaction. This would be patterned after the iATS future date implementation.
* add A.net config settings page where future date option can be enabled/disabled
* add config setting to select specific days of the month where the future date can be implemented. this is important for recurring payments, where the org may only want recurring payments to be triggered on specific days of the month
* expose a Contribution Transaction Date field to the contribution form (when option is enabled)
* modify processing to account for this field if active and used
Contrib page screenshot attached for reference.
![anet-futuredate](/uploads/94fefd56c909114e8758f367cbb6c1b2/anet-futuredate.png)
I'd like to see this included in core, and am looking for concept approval.lcdweblcdwebhttps://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/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.JonGoldJonGold