[CRM-19538] Tax on Memberships is extremely wrong Created: 19/Oct/16  Updated: 24/Feb/17

Status: Open
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.6.22, 4.7.12
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Agileware Assignee: Yashodha Chaku
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 15 minutes
Original Estimate: Not Specified

Attachments: PNG File edit_pending_membership_contribution.png     PNG File Step-1-Contribution-OK-with-Tax-and-Invoicing-Disabled.png     PNG File Step-2-Enable-Tax-and-Invoicing.png     PNG File Step-3-Contribution-NOT-OK-with-Tax-and-Invoicing-Enabled.png     PNG File Step-4-Contribution-Edit-NOT-OK-with-Tax-and-Invoicing-Enabled.png     PNG File Step-5-Contribution-Status-Change-Pending-Completed-NOT-OK-with-Tax-and-Invoicing-Enabled.png    
Issue Links:
Supplementation
supplements CRM-16228 Tax Math is not correct due to premat... Closed
supplements CRM-17417 Tax is reapplied when editing a contr... Closed
supplements CRM-17418 Cancelling a taxable contribution wri... Closed
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding

 Description   

On the heels of CRM-17417 we've had a couple of clients complaining about tax issues relating to CiviCRM memberships recently.

We've tested issues on 4.7.12 as follows - all tests are using a single tax rate of 10%:

  • Using a contribution page to create an "online" membership seems to work okay - a new membership is created with the correct amount and subsequent offline renewals also work.
  • Adding a membership using the "Add Membership" button and a price set results in an initial contribution that has the tax rate applied twice (e.g. $50 excluding tax becomes $60.50, not $55 as it should); subsequent renewals of this membership have the correct amount.
  • Doing the same without a price set appears to work.
  • Adding the membership with a contribution in Pending state results in a Contribution that when edited exhibits multiple incorrect behaviours - on the contribution edit screen the subtotals have double the tax added (as in 20% instead of 10%), however the contribution total still shows the correct amount - attached edit_pending_membership_contribution.png demonstrates. Saving the contribution results in the total having the tax cumulatively re-applied to the post-tax amount (total is 121% of the tax exclusive amount).
  • (Added 2016-12-13): When adding or renewing a membership through the admin interface ("Add Membership" button or "Renew" on a search result), if the amount is changed, the tax amount is applied from the original amount display instead of being calculated from the new amount - although this is not evident in the interface; it will show a contribution with the correct amount, but if you look at the line items via the API you'll see incorrect tax amounts.

Agileware reference 23973



 Comments   
Comment by Seamus Lee [ 19/Oct/16 ]

Just going to tag Joe Murray into this as Joe and his team have been doing work on similar stuff here. Marc Brazeau Also Marc here as Marc has recently been looking into the Add membership and price set stuff.

Comment by Joe Murray [ 19/Oct/16 ]

Jamie Novick does Compucorp want to take a stab at this?

Comment by Yashodha Chaku [ 18/Nov/16 ]

Rough estimate would be 3 - 5 hours.

Comment by Agileware [ 01/Dec/16 ]

Agileware tracking ref 23973

Comment by Yashodha Chaku [ 01/Dec/16 ]

Agileware Do you want core team to start work on this?

Comment by Agileware [ 13/Dec/16 ]

Added the remaining test case, FYI

Comment by Yashodha Chaku [ 05/Jan/17 ]

Agileware Do you want core team to start work on this issue?

Comment by Joe Murray [ 06/Jan/17 ]

This seems to be a reversion of https://issues.civicrm.org/jira/browse/CRM-16228

Comment by Joe Murray [ 06/Jan/17 ]

JMA is working on this in consultation with KarinG under CRM-16228.

Comment by Pradeep Nayak [ 24/Feb/17 ]

Agileware , I was unable to replicate Adding a membership using the "Add Membership" button and a price set results in an initial contribution that has the tax rate applied twice (e.g. $50 excluding tax becomes $60.50, not $55 as it should); subsequent renewals of this membership have the correct amount. on http://dmaster.demo.civicrm.org/

Steps tried to replicate:
Create Financial Account "Sales Tax" with tax rate as 10% and assigned it to Member Dues Financial Type
Create price set with a radio html type and used Student Membership type
On Add Membership form i selected Student Radio Button from the price set option. The amount was calculated correctly as $55.

Am i missing anything?

Comment by Agileware [ 24/Feb/17 ]

Pradeep Nayak you missed a crucial step in your testing, you did not enable: CiviContribute Component Settings: Tax and Invoicing

With the CiviContribute Component Settings: Tax and Invoicing enabled you can see the various problems which are still present in CiviCRM 4.7.17.

Attached are screenshots which highlight the issue and here's some notes for each step:

  1. Step-1-Contribution-OK-with-Tax-and-Invoicing-Disabled - Appears to be working correctly, as you also noted
  2. Step-2-Enable-Tax-and-Invoicing - So let's enable CiviContribute Component Settings: Tax and Invoicing and see what happens next
  3. Step-3-Contribution-NOT-OK-with-Tax-and-Invoicing-Enabled - Wow, the same contribution from the previous screenshot is now different. Why would that be? That's really odd.
    1. Total amount is now $60. Should be $55.
  4. Step-4-Contribution-Edit-NOT-OK-with-Tax-and-Invoicing-Enabled - Editing the same contribution shows the same results. Why?
    1. Total amount is now $60. Should be $55.
  5. Step-5-Contribution-Status-Change-Pending-Completed-NOT-OK-with-Tax-and-Invoicing-Enabled - Payment has been received for this contribution, so let's edit it and change the contribution status from Pending to Completed and save. Looking at the contribution listing, we see a new total and different amounts again. Why?
    1. Total amount is now $60.50. Should be $55.

Let us know if you still cannot reproduce this problem, happy to help out.





[CRM-20172] "Separate Membership Payment" with Memberships enabled and additional contribution causes incorrect authorize.net transactions Created: 23/Feb/17  Updated: 23/Feb/17

Status: Open
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.7.16
Fix Version/s: None

Type: Bug Priority: Important
Reporter: Thomas Bacon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File amounts.png     PNG File authorize.net.png     PNG File contact-contribution-record.png     PNG File memberships.png     PNG File success-page.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

Using the following clean/vanilla setup:
1. WordPress 4.7.2
2. CiviCRM 4.7.16
3. PHP7
4. Authorize.net

If you create contribution page with the following options:
1. Contribution Amounts section enabled
2. Memberships enabled
3. Separate Membership Payment

Authorize.net processes two transactions, but BOTH are for the contribution amount. The membership amount is not processed, and the contribution is set to "Pending (Incomplete Transaction)" in CiviCRM.

I've attached screenshots of one complete transaction and configuration for reference.

Let me know if you need any more info!






[CRM-12500] Membership dashboard numbers are wrong Created: 02/May/13  Updated: 22/Feb/17  Resolved: 17/Jul/13

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.2.9, 4.3.1
Fix Version/s: 4.4.0

Type: Bug Priority: Major
Reporter: Andrew Hunt Assignee: Yashodha Chaku
Resolution: Fixed/Completed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Stoob noticed that the counts of new and renewing members were very wrong in the membership dashboard. The issue is that a "new" membership was one with the start date and join date in the given period, and a "renewing" membership was one with the start date in the period and an earlier join date. Since implementing membership upgrades, this has been incorrect.

For now, this fix relies on the "Membership Signup" and "Membership Renewal" activities. civicrm_membership_log may be a good long-run solution, but it doesn't distinguish between a renewal increasing the end date versus an upgrade increasing the end date. Upgrading from a 1-year membership to a 2-year membership isn't a renewal.

The links to the membership search won't generally return accurate results, so they have been either disabled or replaced by links to an activity search. (Activity search is able to look at new or renewing memberships in a time period, but not filter by membership type.)

There should be an effort to get this working correctly in 4.4; this is a stopgap to at least make sure we're displaying accurate information.



 Comments   
Comment by Andrew Hunt [ 02/May/13 ]

https://github.com/civicrm/civicrm-core/pull/622

Comment by Donald A. Lobo [ 02/May/13 ]

yashi: can u please review this PR

Comment by Yashodha Chaku [ 17/May/13 ]

A couple of things that I noticed :

1. Links for all the columns except Current # and row Totals are not showing

2. Count for current month and last month is incorrect.

3. On clicking Total links, the result count doesn't match (listing shows activities instead of memberships)

4. Last month column is not right (shows Dec instead of Apr)

Comment by Kurund Jalmi [ 29/May/13 ]

Andrew,

Any progress on this?

Comment by Andrew Hunt [ 30/May/13 ]

some progress:

  • links not showing is intentional (see the original description)
  • the last month column label is fixed

working now on the count discrepancies

Comment by Andrew Hunt [ 30/May/13 ]

https://github.com/civicrm/civicrm-core/pull/911

This fixes the membership dashboard counts for CRM-12500. However, in doing so, it removes all links to searches. The rationale is that no existing search accurately displays the number of new or renewing members in a given period. The membership search shows the original join date and the start date of the contiguous membership period. The activity search should theoretically work for displaying membership signup and membership renewal activities, but it isn't working for that, even in a plain vanilla search (this may be a separate problem).

Long run, there should be a search on the membership log table, presumably from the membership search. In the meantime, I think it's preferable to give accurate counts without links than to give inaccurate counts with links to inaccurate search results.

Comment by Yashodha Chaku [ 30/May/13 ]

Hey Andrew :

I did a quick test for membership dashboard count and seems like the counts for New/Total for last month /this month and this year are NOT calculated properly.

  1. Created a membership for 2009 for which the count is reflected in 2013,
  1. Created a membership for Apr but the count is NOT reflected in (Last Month) column

Above seems to be working fine without the patch

Comment by Andrew Hunt [ 30/May/13 ]

Okay, I think I got to the bottom of this, even though I have no good solution. The issue is that the only thing distinguishing signups from renewals is the activity that gets created. For better or worse, the activity is dated for when the signup or renewal is entered, not the start date of the current term. The only place the membership term start date is recorded is the membership log (which doesn't have the new/renew information).

We could join the membership log in the dashboard, but I think that it's preferable to have the date be that of the renewal action, not the start of the renewal term.

Case 1: Member joins in 2009, renews annually, including last month.
In the current dashboard, their renewals will never appear, because it compares the start date with the join date, and since the implementation of membership upgrades, they'll stay the same unless there's a lapsed period.
With the changes, their renewals will appear in the month they're entered.

Case 2: Member joins in April for a year, really likes being a member, and renews in May.
Current: new signup appears in April, nothing appears in May or ever again unless they lapse.
Changes: new signup appears in April, renewal appears in May (nothing appears next April when the new term starts, unless they happen to enter yet another renewal then, a year early).

Case 3: Member joins in April for a year, really likes being a member, and renews the next day (also in April).
Current: new signup appears in April, nothing appears ever again unless they lapse.
Changes: new signup appears in April, renewal appears in April, and the April total is less than the sum of new signups and renewals (because the membership is only counted once--I consider this a good thing, though it could be confusing).

Case 4: Member joined in 2009 as a one-year member, but the check got lost under the filing cabinet until we rearranged the office. We want to start the membership in 2009 and have it be expired in 2010 for whatever reason.
Current: new signup doesn't appear unless we set the dashboard date back to 2009.
Changes: new signup doesn't appear because the query filters for only current membership statuses.

Case 5: Member joined in 2009 as a lifetime member, but the check got lost under the filing cabinet until we rearranged the office. We want to start the membership in 2009 to show his long-term commitment.
Current: new signup doesn't appear unless we set the dashboard date back to 2009.
Changes: new signup appears this month because that's when it was entered and it's still a current membership.

Case 6: Member joins in April, but we don't get around to entering it until May.
Current: new signup appears in April.
Changes: new signup appears in May.

The reason this came up was Case 1: Stoob had clients with regularly-renewing members, and the counts were all wrong. I think that first and foremost, that has to be correct. Cases 2 and 3 are corollaries of that, and at the sprint, we felt that it would be preferable to have the renewal show up when they renew rather than months later when their new membership term starts. Cases 5 and 6 are consequences of that decision, but I think the result is something that organizations are more likely to understand than the other way around. (One alternative might be to use whichever comes earliest.) Case 4 is highly unlikely, and if someone understands that the dashboard reflects when things were entered, they'll know why this happens.

I agree that this is not ideal, but it's more closely aligned with what users would expect than the status quo, which doesn't show non-lapsed renewals at all.

Comment by Andrew Hunt [ 30/May/13 ]

Another quick thing I noticed that's a separate bug that may be contributing to the problem:

  • renew a current member and set the renewal date to sometime last month
  • look in the activity table, and the date is today
  • look in the membership log table, and the date is today

There's no way to back-date a renewal.

Comment by Stoob [ 02/Jun/13 ]

Andrew's comment above "There's no way to back-date a renewal. " Yes, back dated memberships do occur but in my experience it is far more common that people renew prior to (in advance) of their end date.

Comment by Yashodha Chaku [ 04/Jun/13 ]

checked all the above cases, works fine

Comment by Andrew Hunt [ 04/Jun/13 ]

To recreate the core problem:
1. create a new student membership for today
2. go in the database and change the year to 2012 for the records that were created in civicrm_membership, civicrm_membership_log, and civicrm_activity
3. go to the membership dashboard and see how many renewals there are this month
4. renew the membership
5. go back to the membership dashboard--it shows no additional renewal

Comment by Yashodha Chaku [ 07/Jun/13 ]

Andrew :
Regarding your last comment, I couldn't replicate it.

1. I created new student membership today and back-dated all the dates by 1 year (in all the said tables).
2. I renewed the membership for today.
3. I can see the count in the renew column for this month.

Let me know if I am missing anything.

Comment by Peter Davis [ 22/Feb/17 ]

I will open a new ticket, but am just flagging on here (first and most relevant post i found yet) that the Membership Dashboard shows wrong numbers if Memberships get created via an Import. I guess the issue there is that Membership Imports create a Membership Signup Activity with the date of the import, rather than the date of the Start Date





[CRM-19443] date tokens not using format settings when doing print/merge Created: 02/Oct/16  Updated: 19/Feb/17  Resolved: 14/Oct/16

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.11
Fix Version/s: 4.7.13

Type: Bug Priority: Trivial
Reporter: Franky Van Liedekerke Assignee: Monish Deb
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted, tokens
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Core Team Funds

 Description   

When searching for members, the end date is correctly shown according to the defined format settings in the admin part. But when selecting some members and use "print/merge" to send info, the token

{membership.end_date}

is replaced by the end date but not according to own format settings (so always YYYY-MM-DD).



 Comments   
Comment by Monish Deb [ 14/Oct/16 ]

Franky Van Liedekerke I have tested and merged https://github.com/civicrm/civicrm-core/pull/9239 and it works for me. Have look and feel free to reopen the ticket if you still find any bug !!

Comment by Monish Deb [ 14/Oct/16 ]

NOTE: the changes will be available in 4.7.13 rc to test

Comment by Agileware [ 19/Feb/17 ]

We've submitted a backport of this for 4.6 as the functionality is broken there too.

Agileware ref #24973





Generated at Sun Feb 26 06:12:54 UTC 2017 using JIRA 6.2#6252-sha1:aa343257d4ce030d9cb8c531be520be9fac1c996.