Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2023-09-06T14:38:37Zhttps://lab.civicrm.org/dev/financial/-/issues/215Incorrect membership status on payment failure2023-09-06T14:38:37ZMonish DebIncorrect membership status on payment failureOverview
----------------------------------------
If there is an active membership A and the user selects & renews for a different membership B, then on payment failure membership B retain the old membership status (current/new) instead ...Overview
----------------------------------------
If there is an active membership A and the user selects & renews for a different membership B, then on payment failure membership B retain the old membership status (current/new) instead of pending.
Reproduction steps
----------------------------------------
1. A user has active membership A
1. User made a live donation for membership B (that belongs to the same membership org)
1. Payment fails due to some reason.
Current behaviour
----------------------------------------
The user has an active membership B linked with a Pending (Incomplete transaction) contribution.
Expected behaviour
----------------------------------------
The membership status should be set to Pending
Environment information
----------------------------------------
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master_
* __PHP:__ __8.0_
* __CMS:__ _Drupal 8_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/212Why does lineitem.financial_type_id have a db constraint ON DELETE SET NULL2022-11-11T08:00:35ZDaveDWhy does lineitem.financial_type_id have a db constraint ON DELETE SET NULLThe UI won't let you delete financial types that have records that use them. And I can't see a reason why if somebody were to go into the database and try to delete a financial type that you would want to allow this if it has records tha...The UI won't let you delete financial types that have records that use them. And I can't see a reason why if somebody were to go into the database and try to delete a financial type that you would want to allow this if it has records that use it.
The default action for foreign key constraints is to allow deletion if not in use, prevent it if it is in use, which seems exactly right for this field. To make it explicit can use ON DELETE RESTRICT.https://lab.civicrm.org/dev/financial/-/issues/211Sending receipt auto when editing a payment (editing financial trx payment)2023-01-18T20:26:40Zlevi.kSending receipt auto when editing a payment (editing financial trx payment)@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial...@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial type on the contribution eventhough it effects a plus and minus transaction (when the account is different))
3. The system will then send a unwanted email receipt (think its using the payment receipt (not contribution receipt)
Drupal 7
civicrm 5.53.0Monish DebMonish Debhttps://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/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 Debhttps://lab.civicrm.org/dev/financial/-/issues/203False-positive duplicate detection caused by webform not passing correct par...2024-01-16T19:36:50ZAllenShawFalse-positive duplicate detection caused by webform not passing correct parameters to Authorize.net - it needs to pass contributionID(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment proces...(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment processors. Here's one area where this effort seems incomplete and easily improved:
There are a few places in `CRM_Core_Payment_AuthorizeNet::doPayment()` where directly accessing `$params` could (and does) cause problems; it seems right to switch these to `$propertybag`. (BTW I think that usage of `propertybag` in the context of alterPaymentProcessorParams hook is still not appropriate, so I'm not suggesting changes to that usage within this method.)
**Specific observable problem:**
(I can create a more detailed and stripped-down recipe if needed, but hoping to avoid the effort.)
- On a site with: D7, civicrm 5.49.5, webform_civicrm.module, and contributiontransactlegacy extension
- We have a webform which accepts membership signups, payable through the core Authorize.net payment processor.
- Payments made through this webform are actually transacted in Authorize.net, but the user is given the error, 'It appears that this transaction is a duplicate. Have you already submitted the form once? If so there may have been a connection problem. Check your email for a receipt from Authorize.net. If you do not receive a receipt within 2 hours you can try your transaction again. If you continue to have problems please contact the site administrator.'
- FWIW I have observed that the below corrective measure fixes this problem for this site.
**Why this error happens:**
- `CRM_Core_Payment_AuthorizeNet::doPayment()` calls `$this->checkDupe($authorizeNetFields['x_invoice_num'], $params['contributionID'] ?? NULL)` (see [line 171](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L171)) to detect a duplicate transaction.
- However, `$params['contributionID']` is undefined. (On the other hand, `$params['contribution_id']` is defined, as is `$propertyBag->getContributionID( )`).
- Since `checkDup()` gets a NULL value for `$contributionId`, it always thinks the contribution is a duplicate, so we get the above error message.
**Corrective measueres**
1. Seems like the intent of `propertybag` is to clear up exctly this kind of naming inconsistency. I suggest changing Line 171 to use `$propertyBag->getContributionID( )` instaed of `$params['contributionID']`.
2. [Line 146](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L146), which tries to read `$params['is_recur']` and `$params['contributionRecurID']`, is probably also a good candidate for similar cleanup?
Should I go head with a PR or is more discussion needed?https://lab.civicrm.org/dev/financial/-/issues/202Unable to update recurring amount when using Sales Tax2022-08-03T15:19:05ZKarinGUnable to update recurring amount when using Sales TaxHitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/...Hitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/uploads/8280ff94ddb4e66ba1368e64c1d4b72a/image.png)https://lab.civicrm.org/dev/financial/-/issues/201Stop adding 'In Progress' and 'Overdue' statuses to civicrm_contribution.cont...2022-09-15T21:47:08ZeileenStop adding 'In Progress' and 'Overdue' statuses to civicrm_contribution.contribution_status_id option groupThis has been around as a back burner project for a while but didn't have it's own gitlab ... tada
A long long time ago contribution, contribution recur, payments, pledges and pledge payments shared the same option group for their statu...This has been around as a back burner project for a while but didn't have it's own gitlab ... tada
A long long time ago contribution, contribution recur, payments, pledges and pledge payments shared the same option group for their status & some nasty magic massaged values in and out. Overdue and In progress 'leaked' from these other entities onto the contribution in a long-ago regression but was never intended as a contribution status option value in core.
The plan is to stop adding those statuses on NEW installs. (We might add a message on non-new installs that have them but we don't really want to remove them).
Unfortunately this has been a slow-burner as the tests found code places referencing the wrong option group list in many cases - I've slowly been whittling these down & as of writing three tests are failing
https://github.com/civicrm/civicrm-core/pull/23074
Note that this was notified in a long-ago dev-digest and steps have been taken in the Sepa extension (the only one identified as using these statuses) to ensure they are presenthttps://lab.civicrm.org/dev/financial/-/issues/200Contribution status’s are ambiguous (WIP)2022-09-10T05:42:18ZJamie Novick - CompucoContribution status’s are ambiguous (WIP)**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of prob...**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of problems about what the intention of the user really is in a number of scenarios when they change the contribution status.
Examples:
| Example | Narrative | Video |
| ------ | ------ | ------ |
| Example 1a: Overpayment / pending refund | A contribution which is created for $100 donation, but pending. We then record an overpayment of $120. Hypothetically the contribution is overpaid by $20 and should be pending refund. This is not shown in CiviCRM. There is nothing showing the user that there is an overpayment of $20.| ![1-Overpayment](/uploads/74eca492a8d044aa17033dd681922c4a/1-Overpayment.webm)
| Example 1b: Change contribution status to refunded | We can further demonstrate this by taking the same contribution and then changing the status of the contribution to refunded. This raises the question of what this means? Does this reflect the users intention to: Cancel the original debt of $100 (i.e. to credit note the original amounts owed and clear the balance Or reflect the fact a refund was made for the payment of $120, but that they are still owed the original $100 Or both? CiviCRM has refunded the original value of the invoice, i.e. $100, even though the payment of $120 was received. As such we still owe $20 but this is not shown in CiviCRM.|![2-Change_status_to_refunded](/uploads/bf9eae010687771d440b4baa0d528d1e/2-Change_status_to_refunded.webm)
| Example 2: A typo entered in the wrong contribution amount | Add a contribution for $100 and set as completed. Realised that actually the contribution was $120. System will automatically add the additional $20 payment. Note: If this was a change in the line items of an invoice, it would not be safe to assume we received the additional payment. The aim of the user might be to state the obligation to pay was $120. Also it probably wasn’t 2 separate payments and hence we should reverse out the first payment (-100) and then make a second payment for the full amount (+120) | ![Updating_a_contribution_amount_error](/uploads/bda0cc37c9c5911b54bb429367bdffbf/Updating_a_contribution_amount_error.webm)
Much of this stems from the contribution status field being both be the driver of changes to the contribution (i.e. by changing the status to completed or refunded) or changed itself (i.e. the result of changes to the position of the contribution) by recording payments or refunds.
As such this is a proposal to simplify this workflow so that the the contribution status is only the result of the status of the contribution, and can no longer be used to change the status of the contribution.
We would retain the ability to make changes to the contribution status via the API for backwards compatibility until extensions can adopt the new model.
**Further ramblings (feel free to skip this part if you are not too interested in accounting principles)**
Accounting has simple and sounds principles for dealing with all of this.
“Obligations” are managed by 2 documents: Invoices and Credit notes. An invoice would stipulate what is obligated. This can be reduced by creating a credit note, which would then reduce the obligated amount.
It’s worth noting that for sales tax (for example VAT) purposes invoices should be sequentially numbered and should not be edited once they are generated. Hence usually you would not just simply delete an invoice to reduce the obligated amount, you would create a credit note for some or all of the amount, apply it to the invoice and send that to the customer to show the reduce in their balance owed to you.
As such I think in CiviCRM we need to fully enforce the split of concepts of the “obligation” and the actual payments (or refunded) amounts. Currently we have started on the journey towards that where Contributions (and line items on them) represent the obligations in most cases, and payments (or financial transactions of type payment) are the payments.
The contribution status should be a reflection of the net of that position. Does the customer owe us money (= pending or partially paid*) or is the balance settled (= completed) or do we owe them money (= pending refund)?
</details>
**Proposed changes:**
1. Recalculate the contribution status whenever a contribution is created or updated
We should recalculate the contribution status whenever a contribution is created or updated based on the following rules:
| Ref | Calculation | Status |
| ------ | ------ | ------ |
| 1 | If there are no payments or refunds | Pending (arguably there would be a better label for this but in order to avoid making actual changes to the contribution status options this would seem to be the best fit) |
| 2 | If the sum of the line items (including any tax line items) > (sum of payments received - sum of refunds paid out) | Partially paid |
| 3 | If the sum of the line items (including any tax line items) < (sum of payments received - sum of refunds paid out) | Pending refund |
| 4 | If the sum of the line items (including any tax line items) = (sum of payments received - sum of refunds paid out) | Completed |
2. Changes to the User interface:
| Screen | How it looks currently | How it will work | Changes required |
| ------ | ------ | ------ |------ |
| New contribution screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![Create_new_contribution](/uploads/cb028a89f3c3cc2c3798128efaa4e0d6/Create_new_contribution.png) | We split the "obligation" with the "payment". As such we remove the contribution status field from this screen and instead allow people to decide whether they want to record the "payment" at the same time as recording the "obligation" by checking the "Record payment" checkbox. The contribution status would then be calculated using the logic above. i. |
| View contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.26.55](/uploads/02854f20d41d8ffec5159fa1977627e0/Screenshot_2022-08-29_at_11.26.55.png) | | No Changes |
| View contribution screen (multiple line items) || | |
| Edit contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.30.42](/uploads/6faaed62b313698c1a4346956f48e719/Screenshot_2022-08-29_at_11.30.42.png)| ![Screenshot_2022-08-29_at_11.37.56](/uploads/68293bdc8d48c548606793c6a64d159d/Screenshot_2022-08-29_at_11.37.56.png)| Status field becomes read only and we introduce a button to cancel the contribution. See below for new screen for cancelling a contribution|
| Edit contribution screen (multiple line items) || | |
| New membership screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | cell | ------ |
| View membership screen (one line item) | | ||
| View membership screen (multiple line items) | | ||
| Edit membership screen (one line item) | | ||
| Edit membership screen (multiple line items) | | ||
| New event participant screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![New_participant](/uploads/7837cf2271b10bb5824d11483221037a/New_participant.png) | Change the checkbox "Record Payment" to "Record Contribution" OR have a toggle to allow the admin to decide whether they are recording a "Paid" or "Free ticket". We only need the financial type and contribution date if we are only recording the contribution (note in https://lab.civicrm.org/dev/core/-/issues/1403 we have agreed to change label of contribution received date to contribution date). The amounts / lines should come from above. |
| View event participant screen (one line item) | | ||
| View event participant screen (multiple line items) | | ||
| Edit event participant screen (one line item) | | ||
| Edit event participant screen (multiple line items) | | ||
- Removehttps://lab.civicrm.org/dev/financial/-/issues/196Proposal: Account for new Mastercard regulations for recurring contributions2022-09-20T17:19:38ZJonGoldProposal: Account for new Mastercard regulations for recurring contributionsThere's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of en...There's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of enrollment that includes the terms of the subscription and instructions on how to cancel the subscription
* Send a receipt after every successful billing attempt that includes instructions for how to cancel this subscription (this can be instructions to call customer service)
* Provide an online cancellation method (similar to unsubscribing from emails) – that can be instructions to call customer service
* For any subscription/recurring payment plan that bills a cardholder less frequently than every six months, the merchant must send a notification at least seven days prior to the billing date that includes the terms of the subscription and instructions on how to cancel the subscription
* Merchants have until Sept 21, 2022, to meet this requirement.
It seems like `civicrm_contribution_recur.is_email_receipt` should be ignored if the card type is Mastercard. It also seems like a new Scheduled Job is necessary for folks who have recurring contributions that are less frequent than six months.https://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/188Financial Items incorrectly recorded when using Payment API2021-10-27T16:53:49ZhaystackFinancial Items incorrectly recorded when using Payment APIFinally found the time to return to the Order & Payment API and test the changes that @eileen and @KarinG have worked on. So much better now that I can update a contribution without the tax amounts being recalculated!
Warning, this is g...Finally found the time to return to the Order & Payment API and test the changes that @eileen and @KarinG have worked on. So much better now that I can update a contribution without the tax amounts being recalculated!
Warning, this is going to be a long issue because it seems to involve two (maybe overlapping) issues which I haven't been able to separate. So... the scenario that I'm testing is where:
* I create multiple Line Items in an Order that are a mix of taxable and non-taxable.
* They are also a mix of Participant and Membership Line Items.
* The Line Items can be in any sequence when the Order is created.
To tease out what's going on, I tested the following:
1. Taxable Participant ($25) followed by Non-taxable Membership ($50)
2. Non-taxable Membership ($50) followed by Taxable Participant ($25)
3. Taxable Participant ($50) followed by Non-taxable Membership ($50)
4. Non-taxable Membership ($50) followed by Taxable Participant ($50)
These happen to be for Events ("Summer Solstice Festival Day Concert" and "Fall Fundraiser Dinner") and Membership Types (Student) in the CiviCRM Sample Data - though if you want to use those to replicate then it should be noted that "Summer Solstice Festival Day Concert" is incorrectly set to the "Member Dues" Financial Type. @kcristiano was invaluable in setting up CiviCRM's Sample Data with correct Financial Types and I assume there's nothing amiss in that regard.
## Taxable Participant ($25) followed by Non-taxable Membership ($50)
The procedure is commented upon in full for this first test. I'll just post the annotated logs for the subsequent tests since the procedure is identical.
![civicrm-E25-M50-order](/uploads/74c5bdb91fb8ee46d73a0f525a7552ad/civicrm-E25-M50-order.png)
The params for Order.create are as follows:
```
[params] => Array
(
[contact_id] => 210
[financial_type_id] => 1 <-- Non-taxable Financial Type
[payment_instrument_id] => 4
[trxn_id] => WooCommerce Order - 2247
[invoice_id] => 2247_woocommerce
[receive_date] => 2021-10-11 11:28:21
[contribution_status_id] => Pending
[is_pay_later] => 1
[total_amount] => 79.84 <-- Note: Total Amount has 2 decimal places
[source] => Shop
[campaign_id] => 3
[note] => Solstice Ticket x 1, Student Membership x 1
[line_items] => Array
(
[17] => Array
(
[params] => Array
(
[event_id] => 2
[contact_id] => 210
[role_id] => 1
[source] => Shop: Solstice Ticket
[status_id] => Pending from pay later
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 1
[unit_price] => 25.00
[qty] => 1
[line_total] => 25.00
[tax_amount] => 4.84 <-- Note: Tax Amount has 2 decimal places
[label] => Solstice Ticket
[entity_table] => civicrm_participant
[financial_type_id] => 5 <-- Taxable Financial Type
)
)
)
[18] => Array
(
[params] => Array
(
[membership_type_id] => 2
[source] => Shop
[contact_id] => 210
[skipStatusCal] => 1
[status_id] => Pending
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 1
[unit_price] => 50.00
[qty] => 1
[line_total] => 50.00
[tax_amount] => 0.00
[label] => Student Membership
[entity_table] => civicrm_membership
[financial_type_id] => 2 <-- Non-taxable Financial Type
[membership_type_id] => 2
)
)
)
)
)
```
The CiviCRM API (yeah, I know I should convert to API4 but that's another story) returns:
```
[result] => Array
(
[is_error] => 0
[version] => 3
[count] => 1
[id] => 103
[values] => Array
(
[103] => Array
(
[id] => 103
[contact_id] => 210
[financial_type_id] => 1
[contribution_page_id] =>
[payment_instrument_id] => 4
[receive_date] => 20211011112821
[non_deductible_amount] =>
[total_amount] => 79.844775 <-- Note: Total has 6 decimal places
[fee_amount] => 0
[net_amount] => 79.844775 <-- Note: Net Amount has 6 decimal places
[trxn_id] => WooCommerce Order - 2247
[invoice_id] => 2247_woocommerce
[invoice_number] => INV_103
[currency] => USD
[cancel_date] =>
[cancel_reason] =>
[receipt_date] =>
[thankyou_date] =>
[source] => Shop
[amount_level] =>
[contribution_recur_id] =>
[is_test] =>
[is_pay_later] => 1
[contribution_status_id] => 2
[address_id] =>
[check_number] =>
[campaign_id] => 3
[creditnote_id] =>
[tax_amount] => 4.84 <-- Note: Tax Amount has 2 decimal places
[revenue_recognition_date] =>
[is_template] =>
[contribution_type_id] => 1
[line_item] => Array
(
[0] => Array
(
[qty] => 1
[price_field_id] => 1
[price_field_value_id] => 1
[entity_table] => civicrm_participant
[unit_price] => 25.00
[label] => Solstice Ticket
[line_total] => 25.00
[tax_amount] => 4.844775 <-- Note: Tax Amount has 6 decimal places
[financial_type_id] => 5
[entity_id] => 56
)
[1] => Array
(
[qty] => 1
[price_field_id] => 1
[price_field_value_id] => 1
[entity_table] => civicrm_membership
[unit_price] => 50.00
[label] => Student Membership
[line_total] => 50.00
[tax_amount] => 0
[financial_type_id] => 2
[membership_type_id] => 2
[entity_id] => 35
)
)
)
)
)
```
So far so good - though it seems odd that the Total Amount, Net Amount and Tax Amount are reported as having 6 decimal places given that a pre-calculated Tax Amount to 2 decimal places was passed in.
Let's have a look at the Bookkeeping Report at this stage:
![civicrm-E25-M50-pre](/uploads/0fa2ceec4ca463ce50a38bb0ff8b96ae/civicrm-E25-M50-pre.png)
Looks good. The database looks good too:
```
SELECT id, total_amount, fee_amount, net_amount, tax_amount FROM `civicrm_contribution` WHERE id = '103';
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 79.84 | 0.00 | 79.84 | 4.84 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_participant | 1.00 | 25.00 | 25.00 | 5 | 4.84 |
| 108 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 11:28:23 | 2021-10-11 11:28:21 | 210 | Solstice Ticket | 25.00 | USD | 15 | 3 | civicrm_line_item | 107 |
| 105 | 2021-10-11 11:28:23 | 2021-10-11 11:28:21 | 210 | Sales Tax | 4.84 | USD | 17 | 3 | civicrm_line_item | 107 |
| 106 | 2021-10-11 11:28:23 | 2021-10-11 11:28:21 | 210 | Student Membership | 50.00 | USD | 2 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 11:28:21 | 79.84 | 79.84 | 0 | 2 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 79.84 | <-- Correct Entity ID.
| 204 | civicrm_financial_item | 104 | 101 | 25.00 | <-- Correct Entity ID.
| 205 | civicrm_financial_item | 105 | 101 | 4.84 | <-- Correct Entity ID.
| 206 | civicrm_financial_item | 106 | 101 | 50.00 | <-- Correct Entity ID.
+-----+------------------------+-----------+-------------------+--------+
```
Submit the `Payment.create` with:
```
[params] => Array
(
[contribution_id] => 103
[total_amount] => 79.84
[trxn_date] => 2021-10-11 11:30:58
[trxn_id] => WooCommerce Order - 2247
[payment_instrument_id] => 4
)
```
And the logs show:
```
PHP Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in /Users/interactivist/Sites/civicrm/civicrm.events.tec.latest/httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution.php on line 2724
PHP Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in /Users/interactivist/Sites/civicrm/civicrm.events.tec.latest/httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution.php on line 2724
```
The API result is:
```
[result] => Array
(
[is_error] => 0
[version] => 3
[count] => 1
[id] => 102
[values] => Array
(
[102] => Array
(
[id] => 102
[from_financial_account_id] => 7
[to_financial_account_id] => 6
[trxn_date] => 2021-10-11 11:30:58
[total_amount] => 79.84
[fee_amount] => 0.00
[net_amount] => 79.84
[currency] => USD
[is_payment] => 1
[trxn_id] => WooCommerce Order - 2247
[trxn_result_code] =>
[status_id] => 1
[payment_processor_id] =>
)
)
)
```
Nice. So what's in the database?
```
SELECT id, total_amount, fee_amount, net_amount, tax_amount FROM `civicrm_contribution` WHERE id = '103';
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 79.84 | 0.00 | 79.84 | 4.84 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_participant | 1.00 | 25.00 | 25.00 | 5 | 4.84 |
| 108 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 11:28:23 | 2021-10-11 11:28:21 | 210 | Solstice Ticket | 25.00 | USD | 15 | 1 | civicrm_line_item | 107 |
| 105 | 2021-10-11 11:28:23 | 2021-10-11 11:28:21 | 210 | Sales Tax | 4.84 | USD | 17 | 3 | civicrm_line_item | 107 |
| 106 | 2021-10-11 11:28:23 | 2021-10-11 11:28:21 | 210 | Student Membership | 50.00 | USD | 2 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 11:28:21 | 79.84 | 79.84 | 0 | 2 | 4 |
| 102 | 7 | 6 | 2021-10-11 11:30:58 | 79.84 | 79.84 | 1 | 1 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 79.84 |
| 204 | civicrm_financial_item | 104 | 101 | 25.00 |
| 205 | civicrm_financial_item | 105 | 101 | 4.84 |
| 206 | civicrm_financial_item | 106 | 101 | 50.00 |
| 207 | civicrm_contribution | 103 | 102 | 79.84 | <-- Correct Entity ID.
| 208 | civicrm_financial_item | 104 | 102 | 25.00 | <-- Correct Entity ID.
| 209 | civicrm_financial_item | 105 | 102 | 4.84 | <-- Duplicated in 211?
| 210 | civicrm_financial_item | 104 | 102 | 50.00 | <-- Wrong Entity ID.
| 211 | civicrm_financial_item | 105 | 102 | 4.84 | <-- Duplicate of 209?
+-----+------------------------+-----------+-------------------+--------+
```
The Bookkeeping Report seems to reflect the odd assignment of Financial Items:
![civicrm-E25-M50-post](/uploads/2e550b6a4893a9d8960ec4b0a2bcff14/civicrm-E25-M50-post.png)
As you can see, it lists all of the `1100` entries as "Event Fee Taxable". The "Member Dues" item seems to have been switched to "Event Fee Taxable". There also seems to be a duplicate Tax Amount entry. This may be important below when the Financial Item amounts are identical.
## Non-taxable Membership ($50) followed by Taxable Participant ($25)
Sequence of Line Items is reversed:
![civicrm-M50-E25-order](/uploads/3fb49ce43318c51ba2da2f6cd8be3470/civicrm-M50-E25-order.png)
Order API params:
```
[params] => Array
(
[contact_id] => 210
[financial_type_id] => 1 <-- Non-taxable Financial Type
[payment_instrument_id] => 4
[trxn_id] => WooCommerce Order - 2247
[invoice_id] => 2247_woocommerce
[receive_date] => 2021-10-11 11:36:49
[contribution_status_id] => Pending
[is_pay_later] => 1
[total_amount] => 79.84 <-- Note: Total Amount has 2 decimal places
[source] => Shop
[campaign_id] => 3
[note] => Student Membership x 1, Solstice Ticket x 1
[line_items] => Array
(
[17] => Array
(
[params] => Array
(
[membership_type_id] => 2
[source] => Shop
[contact_id] => 210
[skipStatusCal] => 1
[status_id] => Pending
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 1
[unit_price] => 50.00
[qty] => 1
[line_total] => 50.00
[tax_amount] => 0.00
[label] => Student Membership
[entity_table] => civicrm_membership
[financial_type_id] => 2 <-- Non-taxable Financial Type
[membership_type_id] => 2
)
)
)
[18] => Array
(
[params] => Array
(
[event_id] => 2
[contact_id] => 210
[role_id] => 1
[source] => Shop: Solstice Ticket
[status_id] => Pending from pay later
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 1
[unit_price] => 25.00
[qty] => 1
[line_total] => 25.00
[tax_amount] => 4.84 <-- Note: Tax Amount has 2 decimal places
[label] => Solstice Ticket
[entity_table] => civicrm_participant
[financial_type_id] => 5 <-- Taxable Financial Type
)
)
)
)
)
```
API returns:
```
[result] => Array
(
[is_error] => 0
[version] => 3
[count] => 1
[id] => 103
[values] => Array
(
[103] => Array
(
[id] => 103
[contact_id] => 210
[financial_type_id] => 1
[contribution_page_id] =>
[payment_instrument_id] => 4
[receive_date] => 20211011113649
[non_deductible_amount] =>
[total_amount] => 79.844775 <-- Note: Total has 6 decimal places
[fee_amount] => 0
[net_amount] => 79.844775 <-- Note: Net Amount has 6 decimal places
[trxn_id] => WooCommerce Order - 2247
[invoice_id] => 2247_woocommerce
[invoice_number] => INV_103
[currency] => USD
[cancel_date] =>
[cancel_reason] =>
[receipt_date] =>
[thankyou_date] =>
[source] => Shop
[amount_level] =>
[contribution_recur_id] =>
[is_test] =>
[is_pay_later] => 1
[contribution_status_id] => 2
[address_id] =>
[check_number] =>
[campaign_id] => 3
[creditnote_id] =>
[tax_amount] => 4.84 <-- Note: Tax Amount has 2 decimal places
[revenue_recognition_date] =>
[is_template] =>
[contribution_type_id] => 1
[line_item] => Array
(
[0] => Array
(
[qty] => 1
[price_field_id] => 1
[price_field_value_id] => 1
[entity_table] => civicrm_membership
[unit_price] => 50.00
[label] => Student Membership
[line_total] => 50.00
[tax_amount] => 0
[financial_type_id] => 2
[membership_type_id] => 2
[entity_id] => 35
)
[1] => Array
(
[qty] => 1
[price_field_id] => 1
[price_field_value_id] => 1
[entity_table] => civicrm_participant
[unit_price] => 25.00
[label] => Solstice Ticket
[line_total] => 25.00
[tax_amount] => 4.844775 <-- Note: Tax Amount has 6 decimal places
[financial_type_id] => 5
[entity_id] => 56
)
)
)
)
)
```
Database looks good:
```
SELECT id, total_amount, fee_amount, net_amount, tax_amount FROM `civicrm_contribution` WHERE id = '103';
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 79.84 | 0.00 | 79.84 | 4.84 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
| 108 | civicrm_participant | 1.00 | 25.00 | 25.00 | 5 | 4.84 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 11:36:51 | 2021-10-11 11:36:49 | 210 | Student Membership | 50.00 | USD | 2 | 3 | civicrm_line_item | 107 |
| 105 | 2021-10-11 11:36:51 | 2021-10-11 11:36:49 | 210 | Solstice Ticket | 25.00 | USD | 15 | 3 | civicrm_line_item | 108 |
| 106 | 2021-10-11 11:36:51 | 2021-10-11 11:36:49 | 210 | Sales Tax | 4.84 | USD | 17 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 11:36:49 | 79.84 | 79.84 | 0 | 2 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 79.84 | <-- Correct Entity ID.
| 204 | civicrm_financial_item | 104 | 101 | 50.00 | <-- Correct Entity ID.
| 205 | civicrm_financial_item | 105 | 101 | 25.00 | <-- Correct Entity ID.
| 206 | civicrm_financial_item | 106 | 101 | 4.84 | <-- Correct Entity ID.
+-----+------------------------+-----------+-------------------+--------+
```
Bookkeeping confirms this:
![civicrm-M50-E25-pre](/uploads/87857b96e6fb0b8b2379c29e832da746/civicrm-M50-E25-pre.png)
Submit the `Payment.create` with:
```
[params] => Array
(
[contribution_id] => 103
[total_amount] => 79.84
[trxn_date] => 2021-10-11 11:38:59
[trxn_id] => WooCommerce Order - 2247
[payment_instrument_id] => 4
)
```
Logs again show:
```
[11-Oct-2021 10:39:00 UTC] PHP Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in /Users/interactivist/Sites/civicrm/civicrm.events.tec.latest/httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution.php on line 2724
[11-Oct-2021 10:39:01 UTC] PHP Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in /Users/interactivist/Sites/civicrm/civicrm.events.tec.latest/httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution.php on line 2724
```
API result:
```
[result] => Array
(
[is_error] => 0
[version] => 3
[count] => 1
[id] => 102
[values] => Array
(
[102] => Array
(
[id] => 102
[from_financial_account_id] => 7
[to_financial_account_id] => 6
[trxn_date] => 2021-10-11 11:38:59
[total_amount] => 79.84
[fee_amount] => 0.00
[net_amount] => 79.84
[currency] => USD
[is_payment] => 1
[trxn_id] => WooCommerce Order - 2247
[trxn_result_code] =>
[status_id] => 1
[payment_processor_id] =>
)
)
)
```
Database again shows the wrongly assigned Financial Items:
```
SELECT id, total_amount, fee_amount, net_amount, tax_amount FROM `civicrm_contribution` WHERE id = '103';
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 79.84 | 0.00 | 79.84 | 4.84 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
| 108 | civicrm_participant | 1.00 | 25.00 | 25.00 | 5 | 4.84 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 11:36:51 | 2021-10-11 11:36:49 | 210 | Student Membership | 50.00 | USD | 2 | 1 | civicrm_line_item | 107 |
| 105 | 2021-10-11 11:36:51 | 2021-10-11 11:36:49 | 210 | Solstice Ticket | 25.00 | USD | 15 | 3 | civicrm_line_item | 108 |
| 106 | 2021-10-11 11:36:51 | 2021-10-11 11:36:49 | 210 | Sales Tax | 4.84 | USD | 17 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 11:36:49 | 79.84 | 79.84 | 0 | 2 | 4 |
| 102 | 7 | 6 | 2021-10-11 11:38:59 | 79.84 | 79.84 | 1 | 1 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 79.84 |
| 204 | civicrm_financial_item | 104 | 101 | 50.00 |
| 205 | civicrm_financial_item | 105 | 101 | 25.00 |
| 206 | civicrm_financial_item | 106 | 101 | 4.84 |
| 207 | civicrm_contribution | 103 | 102 | 79.84 | <-- Correct Entity ID.
| 208 | civicrm_financial_item | 104 | 102 | 50.00 | <-- Correct Entity ID.
| 209 | civicrm_financial_item | 106 | 102 | 4.84 | <-- Duplicated in 211?
| 210 | civicrm_financial_item | 104 | 102 | 25.00 | <-- Wrong Entity ID.
| 211 | civicrm_financial_item | 106 | 102 | 4.84 | <-- Duplicate of 209?
+-----+------------------------+-----------+-------------------+--------+
```
Again, there also seems to be a duplicate Tax Amount entry.
Bookkeeping Report confirmation of the odd assignment:
![civicrm-M50-E25-post](/uploads/7124d730e050f3f288de87ed29bfeb1b/civicrm-M50-E25-post.png)
The "Event Fee Taxable" item seems to have been switched to "Member Dues".
## Taxable Participant ($50) followed by Non-taxable Membership ($50)
Sequence as per first test:
![civicrm-E50-M50-order](/uploads/3cadc61cf6ecceeb570c7298ae0aafb5/civicrm-E50-M50-order.png)
Order API params:
```
[params] => Array
(
[contact_id] => 210
[financial_type_id] => 1 <-- Non-taxable Financial Type
[payment_instrument_id] => 4
[trxn_id] => WooCommerce Order - 2247
[invoice_id] => 2247_woocommerce
[receive_date] => 2021-10-11 12:01:02
[contribution_status_id] => Pending
[is_pay_later] => 1
[total_amount] => 109.69 <-- Note: Total Amount has 2 decimal places
[source] => Shop
[campaign_id] => 3
[note] => Fundraiser Dinner Ticket x 1, Student Membership x 1
[line_items] => Array
(
[17] => Array
(
[params] => Array
(
[event_id] => 1
[contact_id] => 210
[role_id] => 1
[source] => Shop: Fundraiser Dinner Ticket
[status_id] => Pending from pay later
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 1
[unit_price] => 50.00
[qty] => 1
[line_total] => 50.00
[tax_amount] => 9.69 <-- Note: Tax Amount has 2 decimal places
[label] => Fundraiser Dinner Ticket
[entity_table] => civicrm_participant
[financial_type_id] => 5 <-- Taxable Financial Type
)
)
)
[18] => Array
(
[params] => Array
(
[membership_type_id] => 2
[source] => Shop
[contact_id] => 210
[skipStatusCal] => 1
[status_id] => Pending
)
[line_item] => Array
(
[0] => Array
(
[price_field_id] => 1
[unit_price] => 50.00
[qty] => 1
[line_total] => 50.00
[tax_amount] => 0.00
[label] => Student Membership
[entity_table] => civicrm_membership
[financial_type_id] => 2 <-- Non-taxable Financial Type
[membership_type_id] => 2
)
)
)
)
)
```
API return:
```
[result] => Array
(
[is_error] => 0
[version] => 3
[count] => 1
[id] => 103
[values] => Array
(
[103] => Array
(
[id] => 103
[contact_id] => 210
[financial_type_id] => 1
[contribution_page_id] =>
[payment_instrument_id] => 4
[receive_date] => 20211011120102
[non_deductible_amount] =>
[total_amount] => 109.68955 <-- Note: Total has 6 decimal places
[fee_amount] => 0
[net_amount] => 109.68955 <-- Note: Net Amount has 6 decimal places
[trxn_id] => WooCommerce Order - 2247
[invoice_id] => 2247_woocommerce
[invoice_number] => INV_103
[currency] => USD
[cancel_date] =>
[cancel_reason] =>
[receipt_date] =>
[thankyou_date] =>
[source] => Shop
[amount_level] =>
[contribution_recur_id] =>
[is_test] =>
[is_pay_later] => 1
[contribution_status_id] => 2
[address_id] =>
[check_number] =>
[campaign_id] => 3
[creditnote_id] =>
[tax_amount] => 9.69 <-- Note: Tax Amount has 2 decimal places
[revenue_recognition_date] =>
[is_template] =>
[contribution_type_id] => 1
[line_item] => Array
(
[0] => Array
(
[qty] => 1
[price_field_id] => 1
[price_field_value_id] => 1
[entity_table] => civicrm_participant
[unit_price] => 50.00
[label] => Fundraiser Dinner Ticket
[line_total] => 50.00
[tax_amount] => 9.68955 <-- Note: Tax Amount has 6 decimal places
[financial_type_id] => 5
[entity_id] => 56
)
[1] => Array
(
[qty] => 1
[price_field_id] => 1
[price_field_value_id] => 1
[entity_table] => civicrm_membership
[unit_price] => 50.00
[label] => Student Membership
[line_total] => 50.00
[tax_amount] => 0
[financial_type_id] => 2
[membership_type_id] => 2
[entity_id] => 35
)
)
)
)
)
```
Again, database looks good:
```
SELECT id, total_amount, fee_amount, net_amount, tax_amount FROM `civicrm_contribution` WHERE id = '103';
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 109.69 | 0.00 | 109.69 | 9.69 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_participant | 1.00 | 50.00 | 50.00 | 5 | 9.69 |
| 108 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 12:01:04 | 2021-10-11 12:01:02 | 210 | Fundraiser Dinner Ticket | 50.00 | USD | 15 | 3 | civicrm_line_item | 107 |
| 105 | 2021-10-11 12:01:04 | 2021-10-11 12:01:02 | 210 | Sales Tax | 9.69 | USD | 17 | 3 | civicrm_line_item | 107 |
| 106 | 2021-10-11 12:01:04 | 2021-10-11 12:01:02 | 210 | Student Membership | 50.00 | USD | 2 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 12:01:02 | 109.69 | 109.69 | 0 | 2 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 109.69 | <-- Correct Entity ID.
| 204 | civicrm_financial_item | 104 | 101 | 50.00 | <-- Correct Entity ID.
| 205 | civicrm_financial_item | 105 | 101 | 9.69 | <-- Correct Entity ID.
| 206 | civicrm_financial_item | 106 | 101 | 50.00 | <-- Correct Entity ID.
+-----+------------------------+-----------+-------------------+--------+
```
Bookkeeping Report confirms:
![civicrm-E50-M50-pre](/uploads/728d5845348f0f8bf289f5a7fbcb84f6/civicrm-E50-M50-pre.png)
This is where things get a bit weird(er).
Call `Payment.create` with:
```
[params] => Array
(
[contribution_id] => 103
[total_amount] => 109.69
[trxn_date] => 2021-10-11 12:04:49
[trxn_id] => WooCommerce Order - 2247
[payment_instrument_id] => 4
)
```
Logs (as usual) show:
```
[11-Oct-2021 11:04:50 UTC] PHP Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in /Users/interactivist/Sites/civicrm/civicrm.events.tec.latest/httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution.php on line 2724
[11-Oct-2021 11:04:51 UTC] PHP Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in /Users/interactivist/Sites/civicrm/civicrm.events.tec.latest/httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution.php on line 2724
```
API result is:
```
[result] => Array
(
[is_error] => 0
[version] => 3
[count] => 1
[id] => 102
[values] => Array
(
[102] => Array
(
[id] => 102
[from_financial_account_id] => 7
[to_financial_account_id] => 6
[trxn_date] => 2021-10-11 12:04:49
[total_amount] => 109.69
[fee_amount] => 0.00
[net_amount] => 109.69
[currency] => USD
[is_payment] => 1
[trxn_id] => WooCommerce Order - 2247
[trxn_result_code] =>
[status_id] => 1
[payment_processor_id] =>
)
)
)
```
Database has the same pattern of mis-assignment:
```
SELECT id, total_amount, fee_amount, net_amount, tax_amount FROM `civicrm_contribution` WHERE id = '103';
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 109.69 | 0.00 | 109.69 | 9.69 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_participant | 1.00 | 50.00 | 50.00 | 5 | 9.69 |
| 108 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 12:01:04 | 2021-10-11 12:01:02 | 210 | Fundraiser Dinner Ticket | 50.00 | USD | 15 | 1 | civicrm_line_item | 107 |
| 105 | 2021-10-11 12:01:04 | 2021-10-11 12:01:02 | 210 | Sales Tax | 9.69 | USD | 17 | 3 | civicrm_line_item | 107 |
| 106 | 2021-10-11 12:01:04 | 2021-10-11 12:01:02 | 210 | Student Membership | 50.00 | USD | 2 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 12:01:02 | 109.69 | 109.69 | 0 | 2 | 4 |
| 102 | 7 | 6 | 2021-10-11 12:04:49 | 109.69 | 109.69 | 1 | 1 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 109.69 |
| 204 | civicrm_financial_item | 104 | 101 | 50.00 |
| 205 | civicrm_financial_item | 105 | 101 | 9.69 |
| 206 | civicrm_financial_item | 106 | 101 | 50.00 |
| 207 | civicrm_contribution | 103 | 102 | 109.69 | <-- Correct Entity ID.
| 208 | civicrm_financial_item | 104 | 102 | 50.00 | <-- Correct Entity ID.
| 209 | civicrm_financial_item | 105 | 102 | 9.69 | <-- Duplicated in 211?
| 210 | civicrm_financial_item | 104 | 102 | 50.00 | <-- Wrong Entity ID.
| 211 | civicrm_financial_item | 105 | 102 | 9.69 | <-- Duplicate of 209?
+-----+------------------------+-----------+-------------------+--------+
```
However, this time the consequences of this combination of mismatch and duplicate entry gives a different result in the Bookkeeping Report:
![civicrm-E50-M50-post](/uploads/afb612896bb51e3db2afd7b67b176c9d/civicrm-E50-M50-post.png)
This time, it seems, there are only 5 Financial Items visible.
## Non-taxable Membership ($50) followed by Taxable Participant ($50)
![civicrm-M50-E50-order](/uploads/0f34a882ab9bfb12322254183951b89a/civicrm-M50-E50-order.png)
I'll skip the API calls for this one - if you want them, I'm happy to provide.
The `Order.create` process goes fine, but we're left with the following in the database:
```
+-----+--------------+------------+------------+------------+
| id | total_amount | fee_amount | net_amount | tax_amount |
+-----+--------------+------------+------------+------------+
| 103 | 109.69 | 0.00 | 109.69 | 9.69 |
+-----+--------------+------------+------------+------------+
SELECT id, entity_table, qty, unit_price, line_total, financial_type_id, tax_amount FROM `civicrm_line_item` WHERE contribution_id = '103';
+-----+---------------------+------+------------+------------+-------------------+------------+
| id | entity_table | qty | unit_price | line_total | financial_type_id | tax_amount |
+-----+---------------------+------+------------+------------+-------------------+------------+
| 107 | civicrm_membership | 1.00 | 50.00 | 50.00 | 2 | 0.00 |
| 108 | civicrm_participant | 1.00 | 50.00 | 50.00 | 5 | 9.69 |
+-----+---------------------+------+------------+------------+-------------------+------------+
SELECT * FROM `civicrm_financial_item` WHERE contact_id = '210';
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| id | created_date | transaction_date | contact_id | description | amount | currency | financial_account_id | status_id | entity_table | entity_id |
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
| 104 | 2021-10-11 12:21:33 | 2021-10-11 12:21:31 | 210 | Student Membership | 50.00 | USD | 2 | 1 | civicrm_line_item | 107 |
| 105 | 2021-10-11 12:21:33 | 2021-10-11 12:21:31 | 210 | Fundraiser Dinner Ticket | 50.00 | USD | 15 | 3 | civicrm_line_item | 108 |
| 106 | 2021-10-11 12:21:33 | 2021-10-11 12:21:31 | 210 | Sales Tax | 9.69 | USD | 17 | 3 | civicrm_line_item | 108 |
+-----+---------------------+---------------------+------------+--------------------------+--------+----------+----------------------+-----------+-------------------+-----------+
SELECT id, from_financial_account_id, to_financial_account_id, trxn_date, total_amount, net_amount, is_payment, status_id, payment_instrument_id FROM `civicrm_financial_trxn` WHERE id > '100';
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| id | from_financial_account_id | to_financial_account_id | trxn_date | total_amount | net_amount | is_payment | status_id | payment_instrument_id |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
| 101 | NULL | 7 | 2021-10-11 12:21:31 | 109.69 | 109.69 | 0 | 2 | 4 |
| 102 | 7 | 6 | 2021-10-11 12:25:19 | 109.69 | 109.69 | 1 | 1 | 4 |
+-----+---------------------------+-------------------------+---------------------+--------------+------------+------------+-----------+-----------------------+
SELECT * FROM `civicrm_entity_financial_trxn` WHERE financial_trxn_id > '100';
+-----+------------------------+-----------+-------------------+--------+
| id | entity_table | entity_id | financial_trxn_id | amount |
+-----+------------------------+-----------+-------------------+--------+
| 203 | civicrm_contribution | 103 | 101 | 109.69 |
| 204 | civicrm_financial_item | 104 | 101 | 50.00 |
| 205 | civicrm_financial_item | 105 | 101 | 50.00 |
| 206 | civicrm_financial_item | 106 | 101 | 9.69 |
| 207 | civicrm_contribution | 103 | 102 | 109.69 | <-- Correct Entity ID.
| 208 | civicrm_financial_item | 104 | 102 | 50.00 | <-- Correct Entity ID.
| 209 | civicrm_financial_item | 106 | 102 | 9.69 | <-- Duplicated in 211?
| 210 | civicrm_financial_item | 104 | 102 | 50.00 | <-- Wrong Entity ID.
| 211 | civicrm_financial_item | 106 | 102 | 9.69 | <-- Duplicate of 209?
+-----+------------------------+-----------+-------------------+--------+
```
The Bookkeeping Report shows the end result:
![civicrm-M50-E50-post](/uploads/4cefa4c34c1b02956fdc9ac3e62c8d4c/civicrm-M50-E50-post.png)
## Final thought
My best guess at the moment is that the combination of the mis-assigned `entity_id`s for the Financial Items _plus_ the effect of the extra entry in the `civicrm_entity_financial_trxn` table leads to the mix of 5 or 6 Items visible in the Bookkeeping Report.
If you've got to here, thanks for reading! Hope this helps fix what seemed to be mind-bending symptoms.https://lab.civicrm.org/dev/financial/-/issues/186Accounting entries incorrect in a number of cases... especially with pending ...2023-05-01T17:18:33ZJamie Novick - CompucoAccounting entries incorrect in a number of cases... especially with pending refunds and overpaymentsFirstly - sorry for the wall of text. This has ended up being a much longer piece of analysis than expected but I thought I should share it so that we can agree a way ahead.
This all started as we were looking at the best way to impleme...Firstly - sorry for the wall of text. This has ended up being a much longer piece of analysis than expected but I thought I should share it so that we can agree a way ahead.
This all started as we were looking at the best way to implement refunds for a payment processor. Some work was done here to discuss this: https://lab.civicrm.org/dev/financial/-/issues/87 but I can see this stalled somewhat - probably due to some of the issues I'm going to discuss here.
# Background: The problems with the contribution status field
Just for complete disclosure I hate the CiviCRM contribution status field. Hopefully everyone already knows that. I've probably started discussions on getting rid of it at every CiviCON and documented this on every financial gitlab ticket. It is the biggest blocker we have to reaching an accounting implementation that aligns to standard concepts of accounting.
Why is that?
We appear to have 2 use cases for it, both of which are undocumented.
1. For users to quickly change whether the amounts owed are
a) expected to be paid or
b) are paid.
2. To reflect the payment status of the contribution
i.e. whether the total sum of the line items is >, < or = to the net amount paid in or refunded on that contribution (this is important and I’ll come back to it)
This is a bit of a problem as it’s all a bit chicken and egg! If the user changes the status we need to understand whether we should be creating payments or not (or creating refund payments or not), and if the user records payments or refund payments we need to update the status to something meaningful and consistent.
The following is an analysis of the allowed contribution status changes from and to that a user can perform:
**Table 1:**
- Black = Option hidden
- X - Val = Option shown but user cannot change to it as we have a validation message
- Y (black) = Option shown, user can select this and I don’t see issues with accounting that occurs
- N/A = Couldn’t test
- Y (red) = Option shown, user can select this and there are issues with accounting that occurs
![Screenshot_2021-09-15_at_15.33.12](/uploads/8db825597f091f0bf34d590b38b2ed2f/Screenshot_2021-09-15_at_15.33.12.png)
I’d note that it’s a bit confusing to users to see a value in the dropdown they can’t use. I think we should just hide values they cannot select as this would be much clearer for them.
We end up with some very strange and in some cases incorrect behaviour when allowing users to change the status in a "partially paid" and "pending refund" scenarios:
**Table 2:**
![Screenshot_2021-09-15_at_15.47.11](/uploads/827aafd531d7dbe54866b8237758ce42/Screenshot_2021-09-15_at_15.47.11.png)
# Ground Rules
As such I would like to suggest some ground rules to work towards:
1. The only time a user can change the status of a contribution should be when it has no payments or refunds attached to it.
2. Once a payment has been received we manage everything through either the line item editor or the “change selections” on the event form or "record payment” or “record refund”. If any changes to each are made to any of these we recalculate the contribution status based on one set of rules:
The rules to calculate the contribution status should be:
**Table 3:**
![Screenshot_2021-09-15_at_15.38.43](/uploads/b77e518446862474f4e6823e045e11a3/Screenshot_2021-09-15_at_15.38.43.png)
Delving deeper, there are a number of situations within CiviCRM that do not confirm to this currently and instead we end up with a status this is confusing for the user:
(Note this is not be a comprehensive list - just to give some examples).
**Table 4:**
![Screenshot_2021-09-15_at_15.39.45](/uploads/3a9e238f9ec1071de6b056c543c68522/Screenshot_2021-09-15_at_15.39.45.png)
# Specific Scenarios
This all said there are some specific use cases that we need to consider and have appropriate workflows for:
Table 5:![Screenshot_2021-09-15_at_15.40.49](/uploads/a922e2c0f5a52b92adba895c5fd89654/Screenshot_2021-09-15_at_15.40.49.png)
# Actions:
As such I think the actions could be:
1. Agree to the "ground rules" for the contribution status field above so we are all working towards a common goal.
1. I think we should hide values they cannot select as this would be much clearer for them. i.e. all items that are marked as “X-val” in the table above. Perhaps we can refactor the code that show/hides the options to a central place.
1. I think we should change the way the status field is calculated to use the business logic suggested in Table 3 above in all cases. This shouldn’t be something that extensions should take care of but should be calculated any time a contribution haas it’s line items / financial transactions changed. Obviously I don’t know what this means from a code perspective and I assume this would be a significant refactor but I think we could clear up a lot of business logic by doing so.
1. Discuss and agree which of the options from table 5.1 are suitable and then agree the UX for this.
1. So that we can then remove the option to make the status changes as per table 1: 3f, 4e, 4f without degrading users ability to do the things they need.
I actually think if we do these things we can consider CiviCRM’s accounting to be “correct” if not completely intuitive (at least for now).
@mattwire @eileen @KarinG @JoeMurrayhttps://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/182Possible regression - civicrm_line_item.line_total is incorrectly tax inclusi...2023-11-23T07:17:29ZeileenPossible regression - civicrm_line_item.line_total is incorrectly tax inclusive - potentially 5.39+In 5.39 there was a fix to stop the situation where the contribution.total_amount was recalculated on edit when tax was involved. However this fix had a bug and civicrm_line_item.line_total [stored the tax INCLUSIVE amount](see https://...In 5.39 there was a fix to stop the situation where the contribution.total_amount was recalculated on edit when tax was involved. However this fix had a bug and civicrm_line_item.line_total [stored the tax INCLUSIVE amount](see https://github.com/civicrm/civicrm-core/commit/e967ce8fe2b58b94e2163dde395542e55599da13#diff-4c9d0b1abe07057a4eea2b47bc627eecb95face8ed8d86c1c005312a52cca811L4026-L4035) We [have merged a fix to the rc](https://github.com/civicrm/civicrm-core/pull/21212) but I opened this to try to determine if any released versions are affected. This rose to a bigger issue in the rc because of changes on top of it - which assumed it was right.
The reason this went awol is largely because we had too behaviours - if the contribution bao didn't receive tax_amount it treated total_amount as exclusive and if it did it treated it as inclusive. The former was locked in by tests & not the latter leading to confusion (I'm still confused)
At this stage I'm unsure about real-world issues with this as
1) it didn't affect any core forms that I'm aware of as they pass in 'line_item' or 'skipLineItem'
2) this was the 'correct' behaviour historically for Contribution.create api calls that should have tax_amount passed in, but didn't
3) we have a [deprecation notice](https://github.com/civicrm/civicrm-core/commit/e967ce8fe2b58b94e2163dde395542e55599da13#diff-4c9d0b1abe07057a4eea2b47bc627eecb95face8ed8d86c1c005312a52cca811R193) in the code that would likely have been triggered if line item tax totals did not add up to contribution totals & it's unlikely people would miss wrong contribution totals.
However, my head breaks a bit when I try to think through this
I *think* this would pick up any wrong rows
```
SELECT
SUM(li.line_total + li.tax_amount) as lines_total,
count(li.id) as c,
SUM(c.total_amount) as total_amount
FROM civicrm_contribution c LEFT JOIN civicrm_line_item li ON li.contribution_id = c.id
GROUP BY c.id
HAVING c > 1
AND lines_total <> total_amount
```https://lab.civicrm.org/dev/financial/-/issues/181Update billing details fails when no State/Province entered2022-09-16T21:08:32ZlarsssandergreenUpdate billing details fails when no State/Province enteredUpdate billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This...Update billing details gives "Page could not be loaded" on submit if the user has not entered a State/Province. In some cases, it is valid for a user to not enter a State/Province if they live in a country that does not have states. This works as expected on contribution pages, etc, but not on the update billing details page. Tested on 5.35.2.
I will have a look at how this is handled for contribution pages and port the solution to update billing details, at some point.https://lab.civicrm.org/dev/financial/-/issues/179Search kit bugs2021-08-04T22:27:21ZeileenSearch kit bugs@colemanw I hit a couple of things writing up about [how to do a payments search](https://docs.google.com/document/d/1OM8T-HsqFQDVGMB83iXx6CkC4mtRh4dA0hNK0MIX4hc/edit#)
I figured I'd just stick them in one ticket for now
1) The amount...@colemanw I hit a couple of things writing up about [how to do a payments search](https://docs.google.com/document/d/1OM8T-HsqFQDVGMB83iXx6CkC4mtRh4dA0hNK0MIX4hc/edit#)
I figured I'd just stick them in one ticket for now
1) The amount column from the financial_trxn table was not available to add as an afform filter
![image](/uploads/3608db6fc7f5c8289b4f276d40396927/image.png)
2) It 'looked' like I could make check_number 'edit-in-placeable' on the financial_trxn table - but it didn't work - note that check_number IS a field that should be editable as a data entry issue with no financial transaction implications (if we were editing payment method I think we would to be sure that the edit-in-place is calling v3 Payment.create not v4 FinancialTrxn.create - the former is a wrapper for the latter with more logic)
![image](/uploads/67ed36272f37bbc2fe9bdeacbe199c5d/image.png)
![image](/uploads/58fab89fd8ca820dfb2f17a0a4ffa726/image.png)https://lab.civicrm.org/dev/financial/-/issues/177Batch Transactions: Search cannot filter by Soft-Credit2023-07-21T17:13:51ZmhowisonBatch Transactions: Search cannot filter by Soft-CreditI'm trying to create a batch of existing contacts who have all made a contribution via Donor-Advised Fund (DAF).
When I use the Find Contributions search feature, I'm able to produce a list of contacts who gave through Donor-Advised Fun...I'm trying to create a batch of existing contacts who have all made a contribution via Donor-Advised Fund (DAF).
When I use the Find Contributions search feature, I'm able to produce a list of contacts who gave through Donor-Advised Funds in FY21 (Date Received=Previous Fiscal Year, Contributions AND Their Soft Credits, Soft Credit Type=Donor-Advised Fund).
However, when I run this same query through the search feature in the 'add existing transactions to a batch' screen, the results are incorrect. It filters for previous fiscal year contributions, but it returns all contributions rather than just contributions with a soft credit type of DAF.
The Soft Credit Type criteria doesn't seem to be registering. This shows you the 'add existing transactions to a batch' screen I'm referring to: (https://docs.civicrm.org/user/en/latest/contributions/accounting-integration/#create-a-new-batch-from-existing-transactions.)https://lab.civicrm.org/dev/financial/-/issues/176Billing fields aren't hidden even when they can2024-02-19T16:44:11ZcapoBilling fields aren't hidden even when they canThe **assignAddressField** function, implemented in [CRM/Core/BAO/UFField.php#L785](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFField.php#L785), is meant to return a boolean that tells if:
> Can the address block ...The **assignAddressField** function, implemented in [CRM/Core/BAO/UFField.php#L785](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFField.php#L785), is meant to return a boolean that tells if:
> Can the address block be hidden safe in the knowledge all fields are elsewhere collected (see CRM-15118)
But it only has one return statement when that covers some of the cases in which the fields can't be hidden. In other words, the function never returns true. It can let JavaScript know that all the necessary fields are present but it can't let know other PHP functions.
This issue might be related with #129.https://lab.civicrm.org/dev/financial/-/issues/175Can't remove previously-added currencies2021-07-01T18:10:13Zmegaphonetech-dennisCan't remove previously-added currenciesOverview
----------------------------------------
When I remove previously-added currencies from the list of available currencies under *Language and Currency* and hit the **Save** button, the currencies are still listed among the avail...Overview
----------------------------------------
When I remove previously-added currencies from the list of available currencies under *Language and Currency* and hit the **Save** button, the currencies are still listed among the available currencies when I return to that page.
Reproduction steps
----------------------------------------
1. Go to **Administer** >> **Localization** >> **Languages, Currency, Locations**
1. Next to *Available Currencies* add some currencies. I used CLP and TWD. Click on the **Save** button located at the bottom of the page.
1. Return to **Administer** >> **Localization** >> **Languages, Currency, Locations**
1. Next to *Available Currencies* remove previously-added currencies, and click on the **Save** button located at the bottom of the page.
1. Return to **Administer** >> **Localization** >> **Languages, Currency, Locations** and find those currencies still listed next to *Available Currencies*.
Current behaviour
----------------------------------------
There are no error messages or any indication that something has gone wrong.
Expected behaviour
----------------------------------------
I expected the currencies I removed from this page to no longer be listed as *Available Currencies* when I returned to this page.
Environment information
----------------------------------------
Replicable on the demo server.