Answers.Body: <p>I have an extension we developed for a client with simple needs in Quebec that is not yet ready for general use - <a href="https://github.com/JMAConsulting/biz.jmaconsulting.cdntaxcalculator" rel="nofollow">https://github.com/JMAConsulting/biz.jmaconsulting.cdntaxcalculator</a> . I just looked at it now and removed a bit of custom code to support shipping fees for physical items. I seem to recall that we used custom templates for the messages for purchases. I would love to talk to you about doing this in a more general way as another organization is currently interested in this as well. </p>
  
  <p>Background: The extension uses billing address to determine province of buyer and use that to determine which taxes should apply. A more general solution would handle place of supply (the tax term for place which determines which sales taxes apply) for events based on venue location. For online events it would be buyer's location. </p>
  
  <p>Unfortunately there are some complications in handling two taxes as this affects the display on contribution/membership pages, their confirmation pages, and a fair number of system message templates. </p>
  
  <p>A longer specification is available at <a href="https://wiki.civicrm.org/confluence/display/CRM/Canadian+Sales+Tax+Extension" rel="nofollow">https://wiki.civicrm.org/confluence/display/CRM/Canadian+Sales+Tax+Extension</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-19T17:13:51.617Z
Answers.Text: I did say I'd get back, and so I am.  Ultimately, we'll be handling this via Javascript which sets a "tax" contribution field, with a dedicated financial type & account.  Welcomed to thoughts on this.  But it seemed the least work, and still fairly forward compatible (& easy enough to maintain).
Answers.UserDisplayName: Marc Brazeau
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-19T18:56:47.717Z
Answers.Text: If you are pulling the financial accounts for the taxes on each line item from the api based on the financial type of the line item, inserting civicrm_financial_item and civicrm_entity_financial_trxn records, and have adjusted the system message templates for contributions, memberships, and events, ensured the view contribution form can handle multiple taxes, and reviewed reports and Find Contributions and Advanced Search contribution tab, and the Contact dashboard contributions section for any relevant needed changes I'd say you are good.
Answers.UserDisplayName: Joe Murray
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-22T01:42:02.780Z
Answers.Text: Simpler than that (though we are getting off topic a bit).  Think of it more as a forced contribution calculated via Javascript.  As far as CiviCRM knows, there is no tax.  Customer is happy (and prefers) to show taxes as such, as well as the ensuing reporting.
  
  Although ultimately, we're not using it, your answer is the best, and I suspect will prove valuable to others, so glad to accept it.
Answers.UserDisplayName: Marc Brazeau
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-29T15:36:41.150Z
Answers.Text: Curious - I see this is noted for 4.5 in the info file - has anyone tried this extension in a 4.6?
Answers.UserDisplayName: Alex Katayama
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-14T16:06:03.930Z
Answers.Text: @AlexKatayama the extension is hardcoded for a specific priceset of a specific client. A general solution would need a large investment.
Answers.UserDisplayName: Joe Murray
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-29T21:42:21.310Z
Answers.Text: Tied up with some other work.  I'll need a bit of time to get back to you on this, but it does look promising.
Answers.UserDisplayName: Marc Brazeau
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-28T20:05:52.893Z
Answers.LastActivityDate: 2016-06-28T20:26:42.280Z
Answers.LastEditDate: 2016-06-28T20:26:42.280Z
Answers.UserDisplayName: Joe Murray
Body: <p>In a country, where each province has its own tax rate, where some provinces have multiple tax rates (provincial and feral), how would one go about configuring so that:</p>
  
  <ul>
  <li>Tax rate can be derived based on a member's province</li>
  <li>Invoices / Receipts show both itemized taxes</li>
  <li>Taxes are collected in appropriate financial accounts</li>
  <li>Membership types are associated to their respective financial types.</li>
  </ul>
  
  <p><strong>For example:</strong>
  Imagine two membership types.  Student Membership.  Regular Membership. There are financial types for each, based on a business requirement to track revenues based on membership types. Specifically, revenues for student memberships are tracked against financial account 4000, and for regular memberships against financial account 4100. So far, easy enough.  Now throw in Canadian taxes, where tax rate (and financial accounts) should be derived off on member's province, and it gets complicated pretty quickly!  Even more so if there are 10 provinces, 3 territories, and a dozen or so membership types.</p>
  
  <p>It seems that the best recourse would be a "Canadian Tax" module.  A quick search doesn't reveal anything.  Surely there are lots of Canadian users with similar issues.  How is this being handled elsewhere?</p>
  
Tags: <civicontribute><civimember><taxes>
Title: Handling variable tax rates based on member's province
ThreadText: # Handling variable tax rates based on member's province
  
  (Asked by: username_0 on 2016-06-25)
  
  In a country, where each province has its own tax rate, where some provinces have multiple tax rates (provincial and feral), how would one go about configuring so that:
  
  * Tax rate can be derived based on a member's province
  * Invoices / Receipts show both itemized taxes
  * Taxes are collected in appropriate financial accounts
  * Membership types are associated to their respective financial types.
  
  **For example:**
  Imagine two membership types. Student Membership. Regular Membership. There are financial types for each, based on a business requirement to track revenues based on membership types. Specifically, revenues for student memberships are tracked against financial account 4000, and for regular memberships against financial account 4100. So far, easy enough. Now throw in Canadian taxes, where tax rate (and financial accounts) should be derived off on member's province, and it gets complicated pretty quickly! Even more so if there are 10 provinces, 3 territories, and a dozen or so membership types.
  
  It seems that the best recourse would be a "Canadian Tax" module. A quick search doesn't reveal anything. Surely there are lots of Canadian users with similar issues. How is this being handled elsewhere?
  
  **Tags:** civicontribute, civimember, taxes
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-06-28. Score: 0 | Accepted answer
  
  I have an extension we developed for a client with simple needs in Quebec that is not yet ready for general use - <https://github.com/JMAConsulting/biz.jmaconsulting.cdntaxcalculator> . I just looked at it now and removed a bit of custom code to support shipping fees for physical items. I seem to recall that we used custom templates for the messages for purchases. I would love to talk to you about doing this in a more general way as another organization is currently interested in this as well.
  
  Background: The extension uses billing address to determine province of buyer and use that to determine which taxes should apply. A more general solution would handle place of supply (the tax term for place which determines which sales taxes apply) for events based on venue location. For online events it would be buyer's location.
  
  Unfortunately there are some complications in handling two taxes as this affects the display on contribution/membership pages, their confirmation pages, and a fair number of system message templates.
  
  A longer specification is available at <https://wiki.civicrm.org/confluence/display/CRM/Canadian+Sales+Tax+Extension>
  
  > **Comments:**
  > **username_0**: Tied up with some other work.  I'll need a bit of time to get back to you on this, but it does look promising.  
  > **username_0**: I did say I'd get back, and so I am.  Ultimately, we'll be handling this via Javascript which sets a "tax" contribution field, with a dedicated financial type & account.  Welcomed to thoughts on this.  But it seemed the least work, and still fairly forward compatible (& easy enough to maintain).  
  > **username_1**: If you are pulling the financial accounts for the taxes on each line item from the api based on the financial type of the line item, inserting civicrm_financial_item and civicrm_entity_financial_trxn records, and have adjusted the system message templates for contributions, memberships, and events, ensured the view contribution form can handle multiple taxes, and reviewed reports and Find Contributions and Advanced Search contribution tab, and the Contact dashboard contributions section for any relevant needed changes I'd say you are good.  
  > **username_0**: Simpler than that (though we are getting off topic a bit).  Think of it more as a forced contribution calculated via Javascript.  As far as CiviCRM knows, there is no tax.  Customer is happy (and prefers) to show taxes as such, as well as the ensuing reporting.  Although ultimately, we're not using it, your answer is the best, and I suspect will prove valuable to others, so glad to accept it.  
  > **username_2**: Curious - I see this is noted for 4.5 in the info file - has anyone tried this extension in a 4.6?  
  > **username_1**: @username_2 the extension is hardcoded for a specific priceset of a specific client. A general solution would need a large investment.  
  
  ---
  
  