Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2021-09-15T13:25:34Zhttps://lab.civicrm.org/dev/financial/-/issues/185Contributions created as pending can be later completed in test mode, behavin...2021-09-15T13:25:34ZFrancis (Agileware)Contributions created as pending can be later completed in test mode, behaving like live contributionsContributions created as pending can be later completed in test mode using the `civicrm/contribute/transact` path, behaving like live contributions.
e.g. linked Memberships are moved from Pending to New
1. As an admin, create a Contrib...Contributions created as pending can be later completed in test mode using the `civicrm/contribute/transact` path, behaving like live contributions.
e.g. linked Memberships are moved from Pending to New
1. As an admin, create a Contribution Page that performs "real-time transactions" allows the end user to leave a Contribution in Pending state (either pay later or with a payment processor that defers payment with "incomplete transaction"). For complete coverage, include membership sign up configuration.
2. As a normal user, visit the Contribution Page in live mode and submit details, but do not complete the transaction
3. As the same user, reload the Contribution Page in test mode with the relevant contribution id as URL parameter
4. Complete the transaction using test credit card details
5. As an admin, observe that the contribution has been updated as though it were completed in live mode including relevant changes to any linked entities.
Suggest that this page should probably refuse access in test mode if it attempts to load an existing contribution that is not marked `is_test`https://lab.civicrm.org/dev/financial/-/issues/143Convert core processors to use Guzzle and bring them under CI2020-09-05T01:27:07ZeileenConvert core processors to use Guzzle and bring them under CISubtask of https://lab.civicrm.org/dev/financial/-/issues/132Subtask of https://lab.civicrm.org/dev/financial/-/issues/132https://lab.civicrm.org/dev/financial/-/issues/189Creating an Order fails with `Line item total doesn't match total amount` due...2023-06-19T09:18:26ZhaystackCreating an Order fails with `Line item total doesn't match total amount` due to the mismatch of 2 vs 6 decimal placesOpening this instead of conflating two issues in #188 - specifically referring to [this thread](https://lab.civicrm.org/dev/financial/-/issues/188#note_66286). As the subject says, creating an Order can fail with the error `Line item tot...Opening this instead of conflating two issues in #188 - specifically referring to [this thread](https://lab.civicrm.org/dev/financial/-/issues/188#note_66286). As the subject says, creating an Order can fail with the error `Line item total doesn't match total amount` because of the mismatch of 2 vs 6 decimal places when calculating the Order total from the amounts and tax amounts in the Line Items.
Say, for example, I have two Taxable Line Items in an Order both of which have had their Tax Amount pre-calculated - in this case by WooCommerce but I assume this could equally be the result from any external Payment Processor. All the amounts in the following params are correct as far as WooCommerce is concerned. Both CiviCRM and WooCommerce have `19.37910000` configured as the relevant Tax Rate.
```
[params] => Array
(
[contact_id] => 210
[financial_type_id] => 5
[payment_instrument_id] => 4
[trxn_id] => WooCommerce Order - 2250
[invoice_id] => 2250_woocommerce
[receive_date] => 2021-10-13 19:34:30
[contribution_status_id] => Pending
[is_pay_later] => 1
[total_amount] => 77.59 <-- The pre-calculated Total Amount
[tax_amount] => 12.59 <-- The pre-calculated Total Tax Amount
[source] => Shop
[campaign_id] => 3
[note] => Solstice Ticket (Bass) x 1, Solstice Ticket (Tenor) x 1
[line_items] => Array
(
[17] => Array
(
[params] => Array
(
[event_id] => 2
[contact_id] => 210
[role_id] => 1
[price_set_id] => 8
[fee_level] => Bass
[fee_amount] => 29.84
[source] => Shop: Solstice Ticket (Bass)
[status_id] => Pending from pay later
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 9
[unit_price] => 25.00
[qty] => 1
[line_total] => 25.00 <-- The Line Total
[tax_amount] => 4.84 <-- The pre-calculated Tax Amount
[label] => Bass
[entity_table] => civicrm_participant
[financial_type_id] => 5
[price_field_value_id] => 19
)
)
)
[18] => Array
(
[params] => Array
(
[event_id] => 2
[contact_id] => 210
[role_id] => 1
[price_set_id] => 8
[fee_level] => Tenor
[fee_amount] => 47.75
[source] => Shop: Solstice Ticket (Tenor)
[status_id] => Pending from pay later
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 9
[unit_price] => 40.00
[qty] => 1
[line_total] => 40.00 <-- The Line Total
[tax_amount] => 7.75 <-- The pre-calculated Tax Amount
[label] => Tenor
[entity_table] => civicrm_participant
[financial_type_id] => 5
[price_field_value_id] => 20
)
)
)
)
)
```
The Order API recalculates `$order->getTotalAmount()` and [then compares it with what's passed in via the API](https://github.com/civicrm/civicrm-core/blob/f73d3ac9a9979d8a616b0e2df53a459f7e6a84d7/api/v3/Order.php#L113). However, the rounding to 6 decimal places (rather than 2) triggers `CRM_Contribute_Exception_CheckLineItemsException` because `$params['total_amount'] = 77.59` does not equal `$order->getTotalAmount() = 77.596415`.
WooCommerce appears to _round_ the Line Items before _summing_ them, so:
* Line Item 1: `1.193791 * 25 = 29.844775 => 29.84`
* Line Item 2: `1.193791 * 40 = 47.75164 => 47.75`
* Total of rounded Line Items: `77.59`
CiviCRM, appears to _sum_ the Line Items before _rounding_ them, so:
* Line Item 1: `1.193791 * 25 = 29.844775`
* Line Item 2: `1.193791 * 40 = 47.75164`
* Total of summed Line Items: `77.596415`
`CRM_Utils_Money::equals()` then rounds _up_ not _down_ because of the extra precision and :boom: the above params cannot successfully create an Order.
My suggestion is that CiviCRM should:
* Verify the amount in each Line Item to the number of decimal places for the given currency.
* Keep a running total of those amounts.
* Compare the final running total with the `total_amount`.https://lab.civicrm.org/dev/financial/-/issues/102CRM_Event_BAO_AdditionalPaymentTest::testAddPartialPayment should have status...2020-02-18T02:14:42ZeileenCRM_Event_BAO_AdditionalPaymentTest::testAddPartialPayment should have status transition checks fixed & enabledI've commented out the lines because what they tested wasn't valid but they should be fixed & re-enabledI've commented out the lines because what they tested wasn't valid but they should be fixed & re-enabled5.24.0https://lab.civicrm.org/dev/financial/-/issues/104CRM_Utils_Money::equals should round to monetary values then compare, not do ...2020-02-17T13:10:01ZFrancis (Agileware)CRM_Utils_Money::equals should round to monetary values then compare, not do a difference comparison.When comparing monetary amounts, e.g. via the `Order.create` API call, the `CRM_Utils_Money::equals` function is using a precision level one higher than the currency precision (currently always 2), i.e. instead of requiring the same cent...When comparing monetary amounts, e.g. via the `Order.create` API call, the `CRM_Utils_Money::equals` function is using a precision level one higher than the currency precision (currently always 2), i.e. instead of requiring the same cents value, the amounts must be within 1/10 of a cent.
This uses a calculation with an incorrect premise, and should instead round the values and compare them.
See [the comment for `CRM_Utils_Money::equals`](https://github.com/civicrm/civicrm-core/blob/5.19.1/CRM/Utils/Money.php#L155):
> So, if the currency has precision of 2 decimal points, a difference of more than 0.001 will cause the values to be considered as different.
Which seems like it's an order of magnitude out at first glance, but actually this is the wrong approach, as for example 0.0146 and 0.0154 are less than 0.001 apart, but round with a decimal precision of 2 places to 0.01 and 0.02 respectively. Yes, these two values are unlikely to come up for real, but similar cases could exist.
A practical example where this goes wrong (using Australian tax and currency rules, which are actually pretty simple):
1. We want to create an order with a single taxed line item of $84, including 10% tax.
2. The tax exclusive amount is ~ $76.36 (actually $76.3̅6̅),
3. and the tax amount is calculated to $7.636.
4. The software using the API calculates the total amount as $84.00.
5. Each line item is also added to the Order, using the exclusive and tax amounts.
6. The Order API diligently checks that the line items add up to the total, by checking whether $84 is equal to $76.36 + $7.636
7. `CRM_Utils_Money::equals(84, 83.996, 'AUD')` is called. According to the hard-coded currency precision of 2 decimal places, this should succeed, because $83.996 rounds to a whole dollar value of $84, but
8. The equals function compares to two values with a maximum difference of $0.001, which is less than the $0.004 between to two values.
9. The Order cannot be created.
Agileware ref CIVICRM-13685.24.0https://lab.civicrm.org/dev/financial/-/issues/207Currency codes for São Tome and Principe Dobra, Zambian Kwacha and Zimbabwe D...2022-09-09T10:17:04ZBradley TaylorCurrency codes for São Tome and Principe Dobra, Zambian Kwacha and Zimbabwe Dollar incorrectEsentially the same issue as dev/financial#184.
- São Tome and Principe Dobra: STN since 1 January 2018
- Zambian Kwacha: ZMW since December 31, 2012
- Zimbabwe Dollar: ZWL since June 2009
I think we need to copy what we did for https:...Esentially the same issue as dev/financial#184.
- São Tome and Principe Dobra: STN since 1 January 2018
- Zambian Kwacha: ZMW since December 31, 2012
- Zimbabwe Dollar: ZWL since June 2009
I think we need to copy what we did for https://github.com/civicrm/civicrm-core/pull/21751/files, but for these 3 additional currencies:
- Update the SQL files for new installs
- Add a migration to update any historical payments.
These is possibly an argument for not migrating the data for old transactions (as in all cases the ISO code changed to reflect some change to the currency, for example a redenomination). Doing the migration fits with what happened last time, and probably saves headaches with needing to support old currency codes, which will no longer exist in libraries like Brick\Money. However, as the data _was_ migrated for Ghana and Belarus I think it probably makes sense to continue with that pattern this time around.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/19Customise button text on contribution pages2018-11-09T22:30:54ZMichael McAndrewCustomise button text on contribution pagesIt is not currently possible to customise the text on contribution pages. This seems like core functionality. [This branch adds that functionality for the majority of use cases](https://github.com/michaelmcandrew/civicrm-core/tree/custom...It is not currently possible to customise the text on contribution pages. This seems like core functionality. [This branch adds that functionality for the majority of use cases](https://github.com/michaelmcandrew/civicrm-core/tree/customise-contribution-form-buttons).
There is some stuff I would appreciate some feedback on, for example [these lines that sometimes decide to use different terminology for the button. Background on why they are there would be good. And thoughts on if they should they be configurable options as well](https://github.com/michaelmcandrew/civicrm-core/blob/b906b7d368b2c76d6955ba45baa2319095fd560b/CRM/Contribute/Form/Contribution/Confirm.php#L609-L623).
Yes, I appreciate that Contribution pages are critical to CiviCRM and we cannot afford mistakes here. And yes I could have done this as an extension but
1) this seems very core (feels like one of those things that would be an extension first and then ported to core if popular)
2) LEXIM says 'Leap by extension, iterate by month' and this felt like an iteration to me (of course it would :smile:)
So I decided to see what the impact of putting it in core would be.
The code is hot of the press and not tested.
Thoughts appreciated.https://lab.civicrm.org/dev/financial/-/issues/30Date filter on searching personal campaign pages2018-10-12T07:26:46ZmvuDate filter on searching personal campaign pagesWhen searching for personal campaign pages, we implemented a date filter, where you can search for any active personal campaign pages, that were active during this period of time:
![image](/uploads/6fe01b3760b06d8c847aea1186a6e9cc/imag...When searching for personal campaign pages, we implemented a date filter, where you can search for any active personal campaign pages, that were active during this period of time:
![image](/uploads/6fe01b3760b06d8c847aea1186a6e9cc/image.png)
Can we make a PR into core?https://lab.civicrm.org/dev/financial/-/issues/141Define return parameters for doPayment2023-03-11T00:09:20Zmattwiremjw@mjwconsult.co.ukDefine return parameters for doPaymentSee #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it'...See #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it's not defined anywhere.
My proposal:
* `doPayment($params)` returns an array.
* It must contain:
* **`payment_status_id`**: **(deprecated)** Numeric value of `Contribution Status` option value Completed or Pending. Eg. 1. Must be set but make sure you set `payment_status` as well because this value will be ignored in the future.
* **`payment_status`**: Text field - Either `Completed` or `Pending`.
* It may contain (and the code that calls `doPayment()` will update these values on the contribution/payment:
* **`trxn_id`**: The transaction ID from the payment processor. This will be recorded in the `Contribution.trxn_id` field and the `Payment.trxn_id` field. We do not return `order_reference` here because that is usually filled in by an IPN callback from the payment processor if required.
* **`fee_amount`**: The amount (in same currency as contribution) of the fee taken by the payment processor for processing the payment.
Historically `$params` was passed by reference. This is deprecated and only the return values should be used.
Ping @eileen @artfulrobot @KarinG5.49.0https://lab.civicrm.org/dev/financial/-/issues/139Define the logic that sets (or not) contribution receive_date in relation to ...2020-09-03T19:54:46ZRichDefine the logic that sets (or not) contribution receive_date in relation to paymentsWe discovered that Payment.create that completed a contribution was having a side-effect of updating the contribution's `receive_date` to today's date.
The PR at https://github.com/civicrm/civicrm-core/pull/17688 corrected that by ensur...We discovered that Payment.create that completed a contribution was having a side-effect of updating the contribution's `receive_date` to today's date.
The PR at https://github.com/civicrm/civicrm-core/pull/17688 corrected that by ensuring the payment's date is properly passed through into the underlying BAO code that does the updates and now tests that the `receive_date` is set to the `trxn_date` of the new payment.
However it raised questions: why *should* a payment update the contribution's `receive_date`?
Rather than hold up a PR which was around fixing a definitely-not-what-we-want behaviour, we started this issue to have the discussion. It is referenced in the docblock of the new test in tests/phpunit/api/v3/PaymentTest.php called `testPaymentCreateTrxnIdAndDates`
Before we jump in about one field, let's consider the whole picture (which I may or may not describe properly here)
1. A contribution is created in Pending state, which generates:
- a contribution record, which has a `receive_date`, but also `revenue_recognition_date` (and less importantly: cancel, receipt and thankyou dates)
- a "financial item" for each line item. This has a `transaction_date` field, as well as a `create_date` field.
- depending on config (and [possible bugs](https://lab.civicrm.org/dev/financial/-/issues/138)), a financial transaction record transferring the total amount from the line items' financial types' configured income accounts to Accounts Receivable account, and this table (`civicrm_financial_trxn`) has a `trxn_date` field.
2. A contribution may receive various "payments" (in API speak, but it's really about financial transactions). Typically this represents the full payment for the whole contribution, and in which case it "completes" the contribution. But it also seems to cover various changes, cancellations, refunds, partial payments... For the 90% case where it completes the contribution, this generate:
- a(nother) `civicrm_financial_trxn` row which has a `trxn_date`, and transferrs the funds into (Dr) the payment instrument's configured account from (Cr) the Accounts Receivable account.
- Currently, it will update the `receive_date` for the contribution, too.
So, dates-wise we have:
|Reference | date | observed current behaviour |
|----|-------| -------|
|➊ | contribution `receive_date` | Shown in lists. Create date, then updated. |
|➋| contribution `revenue_recognition_date` | NULL - don't know when/if this gets set |
|➌| financial item 1's `create_date` | Date contribution was created |
|➍| financial item 1's `transaction_date` | Date completing (or latest?) payment made |
|➎| financial trxn 1's `trxn_date` | Could not observe; is not created (think this is a bug see link above) |
|➏| financial trxn 2's `trxn_date` | Date of the completing payment |
I can see that there are situations where it makes sense to update the receive date: for most payments that are made in a single lump, it's probably the most important date: when did we get the money (not just the promise/hope/intent of money)? But as soon as you get into partial payments, refunds etc. then that's only going to be an approximation.
CiviContribute sets up pending contributions willy-nilly which can also represent abandoned baskets, but there's the case when this is set up before midnight and the payment comes a minute later but after midnight. Direct Debit processors may set them up for future payments, or initial payments, but the receive dates may differ due to local banking rules (e.g. bank/public holidays, lack of funds...).
So, what should we do? Leave `receive_date` alone instead of updating it to the completion date? Do the other dates have enough exposure to do this (ie. is it clear to users what the dates mean)? Set it as the date the first funds were received? The latest funds (completing or not) received? Do we update it for cancelled/refunded/partially refunded?
Enjoy the discussion! (not sure if I need to @ people about this, but in case I do, here's an incomplete list: @eileen @JoeMurray @mattwire @KarinG )https://lab.civicrm.org/dev/financial/-/issues/148Deprecate BaseIPN functions validateData & LoadObject2021-01-22T20:28:33ZeileenDeprecate BaseIPN functions validateData & LoadObjectWe've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it...We've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it
1) loads a couple of things - one of which is needed - contribution
2) it checks a couple of things
3) it calls loadObjects which in turn does very little over & above calling
```
$contribution->loadRelatedObjects($input, $ids)
```
Most of the things thus-loaded are unused - except in some specific ways within the processor classes & the stuff around $ids['paymentProcessor'] = $paymentProcessorID; could go if we just passed that as an input to the other functions.
In the past sometimes we have duplicated functions in order to unravel them. On a number of occasions this has worked out well. On others I think we are still paying the price. In particular I think it works when you duplicate code & then keep actively cleaning it up. The mess in the batch update task feels like a case where the code was probably duplicated but then left for a looooonnnnggg time.
In this case I think we can duplicate the contents back with a 'light clean' - since we've already gotten it down to fairly minimal code chunk.5.35.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/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/209Disabled Financial Types are listed when creating a Price Field2022-11-02T00:34:40ZpetednzDisabled Financial Types are listed when creating a Price FieldReplicated on dmaster.
1/ create a new Financial Type - set it as disabled.
2/ create new price set / field and note that the disabled Type is showing
3/ try to save - spinny spin spin if using pop ups - if not using pop-up get
4/ Finan...Replicated on dmaster.
1/ create a new Financial Type - set it as disabled.
2/ create new price set / field and note that the disabled Type is showing
3/ try to save - spinny spin spin if using pop ups - if not using pop-up get
4/ Financial Type for Price Field Option is either disabled or does not exist
is there a logic for showing disabled fields in this interface - can't personally think of one esp the pain of users sitting for 10 mins waiting for things to save.
Possibly related to https://lab.civicrm.org/dev/financial/-/issues/198 though that seems the other end of the problem, ie a Price Field is using a Fin Type that has since been set to be disabled5.56.0colemanwcolemanwhttps://lab.civicrm.org/dev/financial/-/issues/108Disabling a price option or price field causes to be zeroed out and financial...2019-11-19T09:22:41ZseamusleeDisabling a price option or price field causes to be zeroed out and financial integrity issues when changing fee selectionsTo reproduce this error:
1. Create a Price set with > 1 price fields
2. Register and pay for someone using just 1 of those price fields
3. Now disable the price field that was used in step 2
4. Navigate to change fee selections to now s...To reproduce this error:
1. Create a Price set with > 1 price fields
2. Register and pay for someone using just 1 of those price fields
3. Now disable the price field that was used in step 2
4. Navigate to change fee selections to now select an option from the 2nd price field
5. Notice that the qty for the first price field gets zeroed out and no new financial trxn is created sensibly.
I believe @KarinG replicated this in chat https://chat.civicrm.org/civicrm/pl/ap5bif4gsifeuc57yftbxnmynh a work around is to rather than disabling the price option is to set the visibility to be admin only. The situation we were having is we were offering a catered option and an uncatered option for an event and wanted to stop people registering for the catered option at a point in time.https://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/110Discussion: Should you be able to edit a cancelled or completed Contribution ...2019-12-19T08:38:28ZseamusleeDiscussion: Should you be able to edit a cancelled or completed Contribution RecurAt present if someone cancels the contribution recur object or is cancelled for them (in the chris chilla eway extension this happens if the payment fails and the card file details that are retreived indicate the card has expired) you ca...At present if someone cancels the contribution recur object or is cancelled for them (in the chris chilla eway extension this happens if the payment fails and the card file details that are retreived indicate the card has expired) you cannot edit them as they are in the inactive section, I'm curious if people think its correct that those recur objects can't be edited say to re-activeate them etchttps://lab.civicrm.org/dev/financial/-/issues/167Document Support for CiviCRM from payment processors2024-03-07T16:39:04ZJoeMurrayDocument Support for CiviCRM from payment processorsDocument appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partn...Document appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partner detail pages
- [ ] Update the extension readme.md on extensions in gitlab
- [ ] Update extension pages on c.o (for as long as these will exist)
Josh has started on first two tasks as of Feb 22, 2021.
----
Original description
Document appropriately (after determining what that means ;) ) the support that CiviCRM receives from a variety of payment processors.
This might mean putting something into the info.xml or README.md of each extension, as well as adding something somewhere on c.o.
See https://github.com/agileware/cf-stripe/issues/1
@mattwire any sense of Stripe's compensation arrangements being different in Australia compared to other countries? I like the policy thrust of @justinfreeman 's comment but don't believe it is industry practice.joshjosh@civicrm.orgjoshjosh@civicrm.orghttps://lab.civicrm.org/dev/financial/-/issues/204Editing a line item on a membership extends the term of the membership2022-10-11T12:27:28ZkcristianoEditing a line item on a membership extends the term of the membershipCiviCRM 5.50+
Tested on WP Master
Required Line item editor extension and membership created from a price set.
wpcvmaster - 5.53
Steps to reproduce:
- Add a recurring membership
![image](/uploads/6bcad85c842288f49b37d665d4cf02a3...CiviCRM 5.50+
Tested on WP Master
Required Line item editor extension and membership created from a price set.
wpcvmaster - 5.53
Steps to reproduce:
- Add a recurring membership
![image](/uploads/6bcad85c842288f49b37d665d4cf02a3/image.png)
![image](/uploads/79381fa3d7cc4976f3df819fdb79c54e/image.png)
* Need to update rate for the next recurring membership payment
- click more on the recurring transaction that is in progress
![image](/uploads/3b1e39119d0eeb3ccd63ff6da8a72e67/image.png)
* view template
* then edit at bottom of screen
![image](/uploads/0c67dab579f9fd714b9fe3c7517e9750/image.png)
* edit line item
![image](/uploads/9eb56bec0334d8f389db8f5b68f0c33b/image.png)
* change amount
![image](/uploads/512f88dde2200e18efb8771bb3b73b7c/image.png)
- recurring is now updated:
![image](/uploads/4ffaae2bf8207c6b14f3f02d11e8f9aa/image.png)
Unintended consequence: Membership extended:
![image](/uploads/da6e71e2d4d2fbc7f9de4c2709691931/image.png)
cc @seamuslee @JoeMurray This _may_ be related to the 2.5 releaseMonish DebMonish Deb