James McDowell

Before I upgrade to 5.2 and start pulling my hair out . . .

What's the scoop on this "Purchase Sales Tax". PST in Canada typically refers to Provincial Sales Tax which would be the equivalent of a State sales tax.

Taxes on purchases and sales were fine up until now, so could someone please explain the change before I switch our machines over.

[Editor - Please see this posting for the official word on this]

RandyB

James,

We did not change PST. All we did was to include the "Purchase Tax Code" to the total tax calculation. Purchase Tax Code is a tax applied to the cost of an item, and can generate both PST and/or GST taxes depending on which tax code is selected. It is a field associated with each product in your database, just like Sales Tax Code and Labor Sales Tax.

If you do not have Purchase Tax Code assigned in your database, you will not see any differences. If you do, your tax calculations may change. If you are concerned about this, I recommend clearing the Purchase Tax Code ("Canada Purchase Tax" in the list) from all products using the Product Grid in MMPD prior to upgrading.

Bottom line - PST and Purchase Tax Code are not the same thing.

Randy Bownds
Program Manager
D-Tools, Inc

RandyB

Ah, now I see the source of confusion. I mangled that section of the "Noticeable Changes" document and have updated it accordingly. I apologize for the confusion.

http://downloads.d-tools.com/si5/doc...e_Changes.html

Randy Bownds
Program Manager
D-Tools, Inc

James McDowell

Hi Randy:

Still a little confused...

We are already using the Purchase Tax Codes (typically GST only) so what precisely have you changed in the database or the calculations? More directly, how did you change the math?

RandyB

In 5.1, the Purchase Tax Code was not affecting the total tax. You could set it to any value and it had no effect on the bottom line tax. All we did in 5.2 was to include this calculation in the total.

As far as the calculation itself, it is identical to the Sales Tax Code except that it applies to the Cost of items rather than the Price.

Mitchel

This is nuts !
Since 5.2 changed the GST and is now applying (incorrectly BTW) GST purchase tax to the client ASWEL as the regular GST.
This is simply incorrect

our setup is
SI5, lansynk, Server, 4 clients runnign D-tools, Tigerpaw CRM, Quickbooks.
works perfect with accetion to the littel problems that haulf your business some days.

The “purchase GST” is used to apply GST to line items in a “quick-links generated PO into QuickBooks” and to show accurate costing in reports but should not be passed on to the client. That’s what it is being done now with 5.2 – and it’s simply wrong !

After an uphill battle with D-tards Support yesterday and this morning arguing (heatedly) i was told that i need to remove the GST purchase tax form my sku’s in order for it to work correctly and render the correct taxes when you present your client with a proposal.

The concept that any purchase side taxes would be applied to a client’s sales proposal is simply faulty logic.
They are only taxed with PST and GST based on the sell prices of product
At no time should the purchase side taxes even impact the client – THEY PAY THE REG GST on the already marked up value of the good they bought – NOT then also the purchase taxes (which has nothing to do with them). What geniuses came up with that ? if this request came from feedback someone misunderstood that’s certain.

A $100 part has this math when we sell it from Quickbooks (simple estimate for testing) which DAX has no interest in looking at during our discussion for the purpose of simply checking our math. I thought it was a good way to test the numbers. As QB is never wrong with these basic calculation.

In QuickBooks
$100 part
$5 GST
$7 PST
Total = $112 (correct)

In D-tools
$100 Part
$5 GST
$7 PST
$2.50 GST Purchase Tax (WRONG!!)
Total = $114 (which is wrong)

The problem is your applying “purchase tax” to the client when that tax is meant to be presented to the vendor on the PO side instead.
The solution that was offered was to remove the GST Purchase tax from each sku. Although this could be done easily with an sql statement support was unable to provide me with that, and insisted that I post this on the forum. The down side to that is that I expect anyone using QuickBooks will find each time they create a PO there will be no “Purchase GST” assigned to the SKU. So the taxes on each sku would need to be manually set before sending it off to the vendor. There may also be impact to certain reports that offer you analysis information.

If you guys actually bought something in Canada you could see how the math works up here.

I think that we need an sql statement that will make purchase GST tax = null - and then later reverse it with a 2nd sql statement when you need it to work for you in QuickBooks orders properly.

Pointing out these complicated issues out to support is always a challenge.
Getting them to understand the product is no our cost burden it’s dtools cost to carry.

Over the past 4-5 years of working with D-tools i’ve loved and hated the product but the time has come to fix this re we simply need to move on.



Best Regards.
Mitchel Kuijper (Kuyper), CEO

Technology Installed By:

Vortechs Electronics Design LTD
#103 - 1750 Hartley Ave
Coquitlam BC V3K 7A1 Canada
Office 604.519.0800
Fax 604.519.0500
Mobile 604.603.1100

RandyB

Mitchel,

Thank you for helping to clarify the use case. Can anyone else chip in on this? Canadian taxes have always been difficult to understand, and I would like to hear from as many people as possible about how this should work.

At the moment (in 5.2), Purchase Taxes are being passed on to the client since they appear on proposals. Did we get this wrong?

Thanks,

Randy

James McDowell

D-tards! Nice! I am sooooo glad I didn't install this!

You guys need to fix this like yesterday.

I had a rather long conversation with someone in development about a year ago on Canadian taxes. I guess somebody spilled coffee over his notes.

Just put the Canadian taxes back the way they were. It was working correctly before. Who told you guys it was wrong? Even though GST is technically a VAT it does not work the same as England.

If you want a full lesson on Canadian taxes it will take about two days and four bottles of whiskey to get through it.

Just patch this back to the way it was, IMEDIATELY, PLEASE!

RandyB

Below are two alternative definitions of what the Purchase Tax Code is intended to do. Can you guys chime in on which one is correct, or are both of them correct in their own way? This is the source of confusion. I am particularly interested in whether #2 is valid, since #1 seems to be backed up by Quickbooks and the Canadian government site.

Defintion #1 - from Quickbooks and Mitchel

The Purchase Tax Code is a concept that allows users (integrators) to track the tax due to vendors on purchase orders. It is applied to the Cost of an item, and is only shown to vendors (not customers).

How this works: When an integrator purchases items from a vendor, that vendor charges the integrator GST based on the vendor's price for that item (this is the Cost in SI). This tax is included on the purchase order. Thus, the vendor collects the taxes based on the D-Tools Cost of an item and pays this to the government.

Later, when the integrator sells this item to the customer, the customer pays GST and PST to the vendor, based on the sale price of the item (Price in SI). This is determined by the Sales Tax Code. The integrator collects this and sends it, less the Purchase Taxes paid to the vendor, on to the government.

Definition #2 - historical D-Tools definition

The Purchase Tax Code was designed for Products that you do not charge your Client Tax on the Selling Price but on the Cost. These products, by the Tax code, are items the Client cannot take once they leave their House – In-Wall Speakers, Wire, Keypads, etc…You should never set both Purchase Tax Code and Sales Tax Code for an item - use either one or the other.

.

RandyB

Everyone,

After much discussion (thanks Mitchel, James, and Bill), this is definitely a bug in SI5.2. Please take a look at this document which describes it, together with the workaround which is simply to not use this field for the time being.

http://downloads.d-tools.com/SI5/doc...e_tax_code.htm

Note that it will be a while before this gets fixed, so you will have to weigh the benefits of upgrading to 5.2 vs. the cost of the workaround.

I apologize to everyone; this is entirely my mistake for misunderstanding, and if there is anything I can do to help, please let me know.

Best regards,

Randy Bownds
Program Manager
D-Tools, Inc
beta@d-tools.com