The "tax rate" column is reporting a value based on the `uc_order_line_items.data` values which appear to be incorrect or corrupt.
The "county_tax_rate" and "tax_rate" data are offset by a decimal place or 2 and they are represented to about 20 decimal places.
Is there some way this module is contributing data to corrupt these values during the checkout process?

CommentFileSizeAuthor
#3 Screen shot 2012-01-27 at 5.18.34 PM.png24.85 KBdigitalfrontiersmedia

Comments

3cwebdev’s picture

3cwebdev commented

The module is functioning correctly on multiple sites so I suspect the issue you're seeing is not related to this module. If you'd like me to look into it further then I would need more detailed explanation of the symptom and steps that I might be able to perform to reproduce them.

Lowell’s picture

Lowell commented

At some point the data from this module is used to determine the contents of the database values in the `uc_order_line_items.data` field

My question was to determine at what point this data is being used for this purpose by the ubercart system.

Have you looked at the table/field referenced here? Does it even exist on your installation?

I have corrected the values manually for now, only had a few to correct. But I will be investigating/troubleshooting further when I get a chance. It is a glitch I will eventually need to have resolved.

So if you have any insight into the `uc_order_line_items.data` field values and how they are calculated, I might be able to narrow down my search.

Thanks

digitalfrontiersmedia’s picture

digitalfrontiersmedia
Location Sarasota, FL
commented
StatusFileSize
new Screen shot 2012-01-27 at 5.18.34 PM.png24.85 KB

I can verify that something odd seems to be going on (see attached screenshot). In one case, it lists a tax rate of 106% when the tax collected is effectively only 7% ($10.50/$149.99).

We also have an order that has a coupon applied and FL Surtax is not set to tax coupons (yet I see in the code that it's supposed to take into account coupon discount before taxable amount is computed). Yet, it appears that the coupon (-$14.99) is the only thing it taxed (disregarding product at $149.99). It should have been a taxable amount of $135 ($149.99 - $14.99). Not sure if this is related or separate issue.

3cwebdev’s picture

3cwebdev commented

Thank you for the screenshot of the reporting issue. My time is limited so I am not able to do much testing, however I was able to find and fix a bug that was causing inaccurate tax rate reporting. I don't see how the coupon reporting issue could be related, but it may be.

Please test the latest DEV version and let me know if any issues still exist. Any existing inaccurate report info will need to be fixed manually.

digitalfrontiersmedia’s picture

digitalfrontiersmedia
Location Sarasota, FL
commented

Thank you for the update. I'll give it a whirl and report back if I can verify new transactions are reported correctly of if there's still a problem. I, too, am unsure on the coupon but find it odd that I'd be the first to find a bug between uc_coupon and uc_taxes--but who knows. Again, thank you. Will report back after some investigation time.

Lowell’s picture

Lowell commented
Version: 6.x-1.8 » 6.x-1.x-dev
Status: Active » Needs review

your issue, and screenshot, look identical to my issue.

I look forward to testing the latest dev, will update here when I do

thanks

digitalfrontiersmedia’s picture

digitalfrontiersmedia
Location Sarasota, FL
commented

The problem was that tax rates were being saved at the wrong order of magnitude. For example, the Sarasota transaction in the screenshot:
state rate = 0.06 (6%) while surtax was saved as 0.5 instead of 0.005 for 0.5%. When added together for total tax, .5 + .06 = .56 (56%) instead of .065 (6.5%). I'm guessing this is the issue that setfree identified and fixed in dev. I haven't yet checked to see if new transactions are now entered correctly. Will report back when I do.

digitalfrontiersmedia’s picture

digitalfrontiersmedia
Location Sarasota, FL
commented
Status: Needs review » Closed (fixed)

I can confirm that this appears to be fixed based on some recent in-state orders we just had.

Good work. Thanks, Shawn!

Lowell’s picture

Lowell commented

confirmed, Thanks