Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2024-02-27T01:17:44Zhttps://lab.civicrm.org/dev/financial/-/issues/154Sales Tax not added to total when memberships include donations that are sepa...2024-02-27T01:17:44ZeileenSales Tax not added to total when memberships include donations that are separate transactionshttps://civicrm.stackexchange.com/questions/37923/sales-tax-not-added-to-total-when-memberships-include-donations-that-are-separathttps://civicrm.stackexchange.com/questions/37923/sales-tax-not-added-to-total-when-memberships-include-donations-that-are-separathttps://lab.civicrm.org/dev/financial/-/issues/220With tax enabled Total Amount is confusing in online receipt and tax amount l...2023-11-15T18:37:43ZDaveDWith tax enabled Total Amount is confusing in online receipt and tax amount line is wrongIt used to show the amount before tax and the tax amount. But now it looks like this. There was $2 tax.
![untitled3](/uploads/2d19419c080ae6f6f009d1e6f7eff44d/untitled3.png)
This is the same as https://lab.civicrm.org/dev/financial/-/i...It used to show the amount before tax and the tax amount. But now it looks like this. There was $2 tax.
![untitled3](/uploads/2d19419c080ae6f6f009d1e6f7eff44d/untitled3.png)
This is the same as https://lab.civicrm.org/dev/financial/-/issues/206 just in the interim changes have caused the problem to shift.
Also the confirm and thankyou pages make no mention of the tax and there's now a php warning about a missing tax var on those pages.
![untitled7](/uploads/8fcb99238d074a7dd4a53ec000bf51b1/untitled7.png)
![untitled8](/uploads/ebb164e557d99a76bb0f90381b0525c9/untitled8.png)
One way to reproduce:
1. Turn on tax and invoicing. https://docs.civicrm.org/user/en/latest/contributions/sales-tax-and-vat/
* In my case I set up a non-deductible financial type called t-shirts and a corresponding sales tax account that has 5% tax.
2. Create a price set for it.
* There's one price field. I used type text/quantity. Field is required although that's not relevant just makes sense here. Financial type t-shirts.
3. Set up the dummy payment processor.
4. Create a contribution page with that processor and financial type t-shirts and use the price set. Set it to send a receipt.
5. Buy a t-shirt.5.68.0https://lab.civicrm.org/dev/financial/-/issues/210Changing contribution financial type from non-deductible to deductible does n...2023-07-05T23:48:38ZlarsssandergreenChanging contribution financial type from non-deductible to deductible does not change non-deductible amount, resulting in inability to issue tax receiptsSuppose someone enters a donation with an event fee financial type by mistake. The non-deductible amount is set to the full amount of the contribution. If they then change the financial type to a donation type, the non-deductible amount ...Suppose someone enters a donation with an event fee financial type by mistake. The non-deductible amount is set to the full amount of the contribution. If they then change the financial type to a donation type, the non-deductible amount remains the full amount of the contribution, so no tax receipt can be issued for the donation. Since most people probably don't use non-deductible amount regularly, if at all, they aren't likely to check this. Not a big deal if you then try to issue a tax receipt for the single contribution as it will be obvious that something is wrong (though perhaps frustrating because it isn't clear what), but if you are issuing them in bulk, you may not notice this at all, resulting in a donor not getting their tax receipt — a pretty bad outcome from a donor stewardship perspective.
We probably don't want to change non-deductible amounts in the background for existing contributions, but how about a warning that pops up when the financial type is changed from non-deductible to deductible, advising the user to check the non-deductible amount? Perhaps this wouldn't matter to some users, who don't care at all about deductible versus non-deductible, but this does seem worth warning about because it can produce unexpected results in the background.
Something like:
```You've changed the financial type for this $NNN contribution from non-tax deductible to tax deductible, but the non-deductible amount of $NNN has not been changed. This could prevent a tax receipt from being issued. You may want to edit the non-deductible amount.```https://lab.civicrm.org/dev/financial/-/issues/159Line items are added from default price set on recurring contributions for fi...2022-12-14T00:35:14ZFrancis (Agileware)Line items are added from default price set on recurring contributions for financial types with tax accounts.# Steps to reproduce, verified on dmaster.demo.civicrm.org
1. Create a Membership type with required autorenewal
2. Enable Tax & Invoicing
3. Create a Sales Tax account, at any rate, and assign it to the "Member Dues" Financial type.
4....# Steps to reproduce, verified on dmaster.demo.civicrm.org
1. Create a Membership type with required autorenewal
2. Enable Tax & Invoicing
3. Create a Sales Tax account, at any rate, and assign it to the "Member Dues" Financial type.
4. Configure a Contribution Page to sign up for the membership, using the "Member Dues" Financial type.
5. Sign up for a membership using the Contribution page.
6. Using the created recurring contribution id, call the Contribution.repeattransaction API to simulate the membership autorenewal like a payment processor supporting recurring contributions
7. Inspect the resulting contribution records using the Order.get API
# Expected Results
Two orders that are identical apart from dates and IDs
# Actual Results
The second order has two line items. The second line item will be for the price field in the default price set (field 1 / set 1 unless you've somehow changed it), and will be for the same amount as the total of the contribution.
On additional attempts to repeat the transaction, the system crashes due to a DB constraint violation and *rolls back the database transaction, losing the records of any contributions processed so far.*
# Why does this happen?
When `CRM_Contribute_BAO_Contribution::add` calls `CRM_Contribute_BAO_Contribution::checkTaxAmount`, this method checks if the financial type has tax applied and calls `CRM_Price_BAO_LineItem::getLineItemArray` if so, regardless of whether there are any line items already.
# Proposed Solution
Move the calls to `CRM_Price_BAO_LineItem::getLineItemArray` out of `CRM_Contribute_BAO_Contribution::checkTaxAmount` and into `CRM_Contribute_BAO_Contribution::add`, and **only** call it if there's no line_item array present already. See discussion at https://chat.civicrm.org/civicrm/pl/9iuqyx9fp3dexnupuxfefsj4ke
Agileware Ref: CIVICRM-16175.34.0https://lab.civicrm.org/dev/financial/-/issues/184Using GHC as a default currency causes a fatal error with Brick/Money2022-08-31T15:25:46ZbgmUsing GHC as a default currency causes a fatal error with Brick/MoneyTo reproduce:
* Go to dmaster
* Admin > Localisation > Language etc
* Set the default currency to "GHC"
Result:
> Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: GHC in Brick\Money\Exception\UnknownCurrencyExcep...To reproduce:
* Go to dmaster
* Admin > Localisation > Language etc
* Set the default currency to "GHC"
Result:
> Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: GHC in Brick\Money\Exception\UnknownCurrencyException::unknownCurrency() (line 19 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php).
And CiviCRM is ironically bricked, i.e. CiviCRM will systematically fatal.
The ISO code for Ghana is "GHS", which is what Brick/Money uses.
https://en.wikipedia.org/wiki/Ghanaian_cedi5.45.0https://lab.civicrm.org/dev/financial/-/issues/183Order API is not Order AI2021-09-06T19:14:49ZKarinGOrder API is not Order AI[copied notes from Mattermost]
Towards 'making this sane' and could be implemented immediately -> for example - one would be to immediately start returning ->
````a notice -> 'warning: incompatible set of input params - Order API can ...[copied notes from Mattermost]
Towards 'making this sane' and could be implemented immediately -> for example - one would be to immediately start returning ->
````a notice -> 'warning: incompatible set of input params - Order API can not create coherent line-item(s)'.````
When being presented with incompatible data -> e.g. if
total_amount = 10;
tax_amount = 0.25;
financial_type_id = 1;
That's an impossible set of input params. Yes - they are still being handled right now - but results will be unpredictable b/c it is simply impossible to create a co-herent line_item with those input params.
I have some more notes in 21187 - will park them in my own atrium for now. Key one is that one 👆
Another one could be that if presented with line_items and a total_amount at the Contribution level - then that all better be adding up or else ->
````a notice -> 'warning: incompatible set of input params - Order API can not create coherent line-item(s)'.````
At this stage the API can still attempt - but alerting people would be a first step towards to no longer accept incoherent input. Order API is not Order AI :-)https://lab.civicrm.org/dev/financial/-/issues/1805.41 rc - order api stores totals incorrectly when line items not passed in2021-08-27T05:28:36ZKarinG5.41 rc - order api stores totals incorrectly when line items not passed inReproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!Reproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!5.41.0https://lab.civicrm.org/dev/financial/-/issues/123Recurring Contributions -> and Sales Taxes2021-08-20T05:38:22ZKarinGRecurring Contributions -> and Sales Taxes**UPDATE - the tldr is contribution_recur.amount = "Amount to be collected (including any sales tax) by payment processor each recurrence."**
Should the amount field in the civicrm_contribution_recur table -> be prior to Sales Tax or s...**UPDATE - the tldr is contribution_recur.amount = "Amount to be collected (including any sales tax) by payment processor each recurrence."**
Should the amount field in the civicrm_contribution_recur table -> be prior to Sales Tax or should it include Sales Tax?
Example:
$10.00 Membership
Sales Tax 5%
A. (recurring) amount = 10 [before Sales Tax]
or
B. (recurring) amount = 10.50 [Sales Tax included]
Context: a payment processor needs to know the amount to transact/authorize. So I'm hoping we can clarify/document what the amount field in the civicrm_contribution_recur table represents.
@eileen
Chat: https://chat.civicrm.org/civicrm/pl/m8i98w31fi8ddfc6hisoqrrm4y
The Comment on the field itself in the Table Structure: "Amount to be contributed or charged each recurrence."https://lab.civicrm.org/dev/financial/-/issues/169"Export" from Batch Edit screen no longer works on D82021-03-11T19:14:54ZJonGold"Export" from Batch Edit screen no longer works on D8#### To replicate on d8master:
* Click **Contributions » Accounting Batches » New Batch**.
* Click **Save**.
* Assign at least one transaction to the batch.
* Go to **Contributions » Accounting Batches » Open Batches**.
* Attempt to expo...#### To replicate on d8master:
* Click **Contributions » Accounting Batches » New Batch**.
* Click **Save**.
* Assign at least one transaction to the batch.
* Go to **Contributions » Accounting Batches » Open Batches**.
* Attempt to export, either from the *Actions* menu, or by clicking **More » Export**.
* A pop-up will appear allowing you to select the export format. Click **OK**
#### Expected result
Batch export proceeds.
#### Actual result
Nada.
The Dev console shows the error - "jquery.redirect.min.js" can't be found. This has to do with how the Resource URLs are split into `core` and `packages` inside `<webroot>/libraries/civicrm`. It's impossible to call `jquery.redirect.min.js`.
Moreover, this UI has always been a bit flaky. If you click **Transactions** on the *Open Batches* screen, the **Export** button will bring you to the next screen. The two methods I outlined above bring up an extra modal dialog, the options of which are repeated on the next screen. So rather than fix the bug, I think we should remove the modal altogether.5.37.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/163Fully remove contributionTypeID2020-12-23T11:07:08ZeileenFully remove contributionTypeIDThere are few remaining references in the code to very-old-legacy contributionTypeID
This seems to be passed out to payment processors and assigned to the templates in some cases
I feel like we could remove these in 5.34 and simply com...There are few remaining references in the code to very-old-legacy contributionTypeID
This seems to be passed out to payment processors and assigned to the templates in some cases
I feel like we could remove these in 5.34 and simply communicate the fact via the dev-digest and release notes.5.34.0https://lab.civicrm.org/dev/financial/-/issues/158Wording change - change UI parts of contribution soft schema to soft credit2020-12-12T00:21:24ZeileenWording change - change UI parts of contribution soft schema to soft creditThrough out the ContributionSoft.xml fields are referred to as 'Contribution Soft x' but in the UI we normally use 'Soft Credit'
When exposing these fields through Search Kit/ Afform / Metadata based functions I believe 'Soft Credit' is...Through out the ContributionSoft.xml fields are referred to as 'Contribution Soft x' but in the UI we normally use 'Soft Credit'
When exposing these fields through Search Kit/ Afform / Metadata based functions I believe 'Soft Credit' is more meaningful5.34.0https://lab.civicrm.org/dev/financial/-/issues/140Order API - Participant Status2020-12-09T15:25:34Zmattwiremjw@mjwconsult.co.ukOrder API - Participant StatusCurrently Order API does not allow setting participant or membership status. It is hardcoded to `Pending from incomplete transaction` for participant and `Pending` for Membership.
This is a problem for event cart which will use Order A...Currently Order API does not allow setting participant or membership status. It is hardcoded to `Pending from incomplete transaction` for participant and `Pending` for Membership.
This is a problem for event cart which will use Order API per https://github.com/civicrm/civicrm-core/pull/17886 and needs to set `Pending from cart` as status.
All other parameters for participant/membership can be passed through and will be set to whatever you set them to (or defaults if not set).
My view is that we don't need to put any restrictions in place on what the status can be set to.
We are not talking about contribution status here - the two are independent. Any flow that "completes" a contribution will also complete any linked participants/memberships if they are not already "completed" but we hope to separate this logic more in the future as it doesn't work for everyone.
Over the last couple of years we've been progressively removing more and more restrictions within core about what can/can't be done (with memberships mostly) but also participants because any restriction in core restricts what can be done via extension/third-party integrations.
My proposal here is to remove the restriction on participant status when created/updated using Order API per: https://github.com/civicrm/civicrm-core/pull/18096 Note that you *can* pass a participant/membership ID in here but it will still get overwritten with the hardcoded status (so eg. a "completed" membership would get set to Pending and a "On waitlist" participant would get set to "pending from incomplete transaction").
I don't think we are going to run into the same issues that we do with contributions when changing statuses because the participant/membership entities don't have a whole set of financial accounting behind them.
Thoughts please @eileen @artfulrobot @KarinG (webform_civicrm will need converting to Order API at some point) @wmortada @bgm
Also note that, according to the docs here https://docs.civicrm.org/dev/en/latest/financial/orderAPI/#sample-ordercreate-for-single-event-registration until 5.20 the Order API created participants as `Registered` by default.5.34.0https://lab.civicrm.org/dev/financial/-/issues/156Refund status not set correctly when cancelled_payment_id is set2020-11-09T14:28:28ZJonGoldRefund status not set correctly when cancelled_payment_id is setThis is the same as https://lab.civicrm.org/extensions/stripe/-/issues/260, but the issue lies in core.
### Steps to Replicate
* Create a contribution.
* Refund the entire contribution via `Payment.create`. Set the `cancelled_payment_i...This is the same as https://lab.civicrm.org/extensions/stripe/-/issues/260, but the issue lies in core.
### Steps to Replicate
* Create a contribution.
* Refund the entire contribution via `Payment.create`. Set the `cancelled_payment_id`.
### Expected Result
The contribution's status should be "Refunded".
### Actual Result
The contribution's status remains "Completed".
PR [16148](https://github.com/civicrm/civicrm-core/pull/16148)'s purpose is to set a contribution's status to "Refunded" when the refund's total equals the contribution's total (in `CRM_Financial_BAO_Payment::create()`.
However, this function [returns early](https://github.com/civicrm/civicrm-core/blob/0b44c58f8d6abea7e0be266d89e0100a0e871f60/CRM/Financial/BAO/Payment.php#L99-L102) if the `cancelled_payment_id` is set. Stripe 6.5 [sets that value](https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/StripeIPN.php#L318) (as it should). So that code never runs.
Moreover, the test on PR 16148 doesn't set this value, so the bug isn't caught.5.32.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/111Thank-you letter incorrect contribution currency2020-10-09T01:04:37ZkleehkThank-you letter incorrect contribution currencySteps to replicate:
* Enter a contribution with a currency that is not the default.
* Using any method that supports contribution tokens (Thank-you letter print or email, CiviRules, etc.) use one of the following tokens: `{contribution.t...Steps to replicate:
* Enter a contribution with a currency that is not the default.
* Using any method that supports contribution tokens (Thank-you letter print or email, CiviRules, etc.) use one of the following tokens: `{contribution.total_amount} {contribution.fee_amount} {contribution.net_amount}`.
**Expected result**
The token displays the amount formatted to the currency of the contribution.
**Actual result**
The token displays the amount formatted to the default currency.
[Original message follows].
~~~~
My setup: CiviCRM 5.20.0 on Drupal 7.
I entered contributions in different currencies. In Find Contributions, check some entries. At Actions select Thank-you letter print or email.
I put tokens Contributions:
{contribution.currency} {contribution.total_amount} {contribution.fee_amount} {contribution.net_amount}
and it gives me lines like these:
CNY HK$ 1,299.90 HK$ 0.00 HK$ 1,299.90
GBP HK$ 500.00 HK$ 0.00 HK$ 500.00
where CNY and GBP are the currencies of those contributions and HK$ is the symbol of the default currency.
It seems the amounts variables just took the system default, rather than contributions' currencies.
Thank you.
Original post at https://civicrm.stackexchange.com/questions/34031/thank-you-letter-incorrect-contribution-currency5.32.0JonGoldJonGoldhttps://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/118Proposal - move source & received date to near the top on ContributionView form2020-08-31T02:50:30ZeileenProposal - move source & received date to near the top on ContributionView formI realise that any UI changes generally fall apart on discussion / scope creep so I want to keep this proposal very specific & I'll either procede with it or not based on up & down votes - the Proposal is to move the Source & Received da...I realise that any UI changes generally fall apart on discussion / scope creep so I want to keep this proposal very specific & I'll either procede with it or not based on up & down votes - the Proposal is to move the Source & Received date fields to the top on the contribution view screen
**Proposed location**
(note moving the payment summary into where Total Amount sites is is in the screenshot out of scope for this proposal)
![Screen_Shot_2020-02-15_at_2.45.54_PM](/uploads/8d5c9f99236ba679e7c550986dc764c1/Screen_Shot_2020-02-15_at_2.45.54_PM.png)
**Current location**
(note the double Total Amount is a bug which I will look at once https://github.com/civicrm/civicrm-core/pull/16531 is resolved as the technique will be part of the solution if agreed)
![Screen_Shot_2020-02-15_at_2.26.31_PM](/uploads/14d9e729c34efe642d66bffa26568b68/Screen_Shot_2020-02-15_at_2.26.31_PM.png)
Rationale - I think the 'what & when' about a contribution is key at-a-glance information & it should be near the top (possibly above financial type too). The other detail is increasingly weedsy payment information - & I feel further down makes sensehttps://lab.civicrm.org/dev/financial/-/issues/125Allow individuals to download invoices for their organisation2020-05-20T14:10:48ZbgmAllow individuals to download invoices for their organisationMy use-case is the following:
* Membership is invoiced to the organization;
* A related contact (with view/edit permission) should be able to login and access the dashboard of the organization, download invoices.
Viewing the related or...My use-case is the following:
* Membership is invoiced to the organization;
* A related contact (with view/edit permission) should be able to login and access the dashboard of the organization, download invoices.
Viewing the related org's dashboard works, it displays the list of invoices and a download link, but clicking on the link results in an "Access Denied".https://lab.civicrm.org/dev/financial/-/issues/109Invoice does not assign/display the contact's country2020-03-01T20:27:10ZbgmInvoice does not assign/display the contact's countryTo reproduce:
* Enable Taxes and Invoicing
* Edit the "Contribution Invoice Receipt" message template to include `{$country}` (other related contact tokens are called `{$street_address}`, `{$email}`, etc.
* Go to a contact, create a con...To reproduce:
* Enable Taxes and Invoicing
* Edit the "Contribution Invoice Receipt" message template to include `{$country}` (other related contact tokens are called `{$street_address}`, `{$email}`, etc.
* Go to a contact, create a contribution, and from "view contribution", click "print PDF invoice" to view an invoice.
The country will be empty.5.24.0https://lab.civicrm.org/dev/financial/-/issues/116Cancelling a payment thru the API2020-02-14T19:24:31ZalicefruminCancelling a payment thru the APIWhen a user updates a Contribution with the status "Completed" to have the status "Cancelled" thru the UI (or the API using Contribution.create and an id) a negative payment is created with a status of "Cancelled" like in the screen shot...When a user updates a Contribution with the status "Completed" to have the status "Cancelled" thru the UI (or the API using Contribution.create and an id) a negative payment is created with a status of "Cancelled" like in the screen shot below:
![cancelled](/uploads/04c0dcd8c7798a42184e2f0a902b1697/cancelled.png)
This works fine if you are cancelling a full contribution however there is now way in the UI or the API to cancel one of multiple payments.
For Example:
+ a user has a $10 contribution with two payments one for $2 and one for $8
+ The user wants to cancel the $2 contribution
If you cancel the contribution it will record a negative payment of $10.
IF you do `Payment.cancel` it will record a negative payment of $2 with a status "Refunded"
Using `FinancialTrxn.create` you can create a payment of -$2 with a status of "Cancelled" but it will not update the contribution status AND when you update the contribution status to "Cancelled" a new negative payment (of -$10) will be created with a status of cancelled.
PROPOSED SOLUTIONS:
+ Update the `Contribution.create` api so that there is a flag to not create new payments.
+ Allow 'status_id' to be passed to the Payment API and update the contribution and payment statuses based on the status_id if providedhttps://lab.civicrm.org/dev/financial/-/issues/117Payment edit link cannot be modified2020-02-11T20:07:09Zadrian@roomify.usPayment edit link cannot be modifiedOn the 'View Contribution' page, the payment details edit link is not currently modifiable via hook_civicrm_links. Related issue: https://issues.civicrm.org/jira/browse/CRM-13434
I'll be submitting a PR.On the 'View Contribution' page, the payment details edit link is not currently modifiable via hook_civicrm_links. Related issue: https://issues.civicrm.org/jira/browse/CRM-13434
I'll be submitting a PR.5.24.0