webERP Forum

Full Version: Tax Rates Do Not Add Up - SOLVED?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
When using a one-to-many relationship for tax rates the total tax rate is not concatenating.

Looking at PDFQuotation.php It appears as if the SQL only uses one associated record and it should use associated records.

I built a Tax Group of 7% by concatenating Tax Authorities and applicable rates but i only end up with 4% as the Tax Rate.

The idea is to be able to build Tax Rates similar to building a binary number in that it is simply combinations of Tax Rates.




The logic shown above results in a Tax rate of 4% instead of 7% and I believe that is due to the 4th SQL loop being outside of the 3rd SQL loop.

My fixes are attached so can somebody please verify my work, especially with respect to tax upon tax flag.
I cannot verify, for I don't have any of that data in my system, but if someone else can at least try/verify the files, I do NOT mind committing the files to SVN.
Is this only true for quotations or does the error transfer through to the order as well? In many locales (the UK for instance) it is not normal to include the tax on a quotation, and it wasn't initially included in the quotation report. If I recall correctly Rafael added this in a while back and it maybe he made the mistake then.

The tax rate was already on the quotation so I can only assume it should be included.

However... I do understand that it is not necessary for bid purposes.
Hi Paul yes it is included but it wasn't till a few years ago when Rafael wrote the tax code into the quotation. My point was that it wasn't included as part of the initial tax code and so doesn't seem to follow the same rules. It obviously needs correcting though I would like to see it being optional on the quotation anyway.

I agree that it could be optional. I have been involved in estimate/proposal/quotation generation for many decades and we never included sales tax data.

To be honest, it is often painful to determine sales tax so it is a non-value-added task at time of estimate/proposal/quotation. It is something best left to accounting at time of billing.

If a PO from a customer must include total amount (i.e., plus tax) then it becomes useful but, again, that can be done at time of Sales Confirmation.

In any case, and to your point, rules, consistency, and predictability are always helpful.
Tim, are these changes for commit, or a "hold for now" matter?
Whether or not you want tax to be shown on a quotation seems to be very much dependent on your location. For my EU customers it makes no sense, whereas in Africa they want it. So for me the only way is to make it an option in the configuration, but I haven't had time to look at the code, so am not sure how much is involved in doing that.

Ok Tim, based on the "should be configurable", then I'll classify this as "hold for now" to minimize impact.

I need to get back to the pick list matter, as I got off on a tangent ensuring that I was committing Paul's, yours (as well as other user's) proposed changes (or fixes to reported bugs) back through November. (I started committing around Dec. 11th)

Phil has mentioned that there may be a release soon, and Exson is investigating a BOM-related bug. (not sure of the specifics)

I *believe* that I have caught-up with all the *known* matters at this time (at least from Nov. to now, some others before then appear to have been covered by others)

After the pick list, I can look back at this issue to see what might be necessary to include this "feature" in the configuration too.
As well as Exson's BOM bu I have reported two other bugs that have been committed to the developers who committed them and these need to be fixed before any release is done.

Pages: 1 2
Reference URL's