Order Line Totals Causing Strange (but repeatable) Crashing

[NormanRouxel]

Note that many of the the SD PHP files are loaded once when SD starts up. So changes made to them won't take effect until you restart SD.

[Dealec]

Please try the following:

- Find the file Taxmodule.php (normally in C:\Program Files (x86)\SellerDeck\SellerDeck 2016\PHPModules, or whatever is your SellerDeck 2016 install path)
- Take a backup copy of the file
- Open the file in Notepad or a similar application
- Search for
$oNode->SetAttributeValue('ordertax1rounded', $this->m_fOrderTax1Rounded);
- Replace with
$oNode->SetAttributeValue('ordertax1rounded', intval($this->m_fOrderTax1Rounded));

I can't reproduce you crash in v16.0.1 adding a £72.56 product to a MOTO order. But the above fix resolved a very similar crash that was reported to support in v16.0.0 and the cause is very likely to be the same.

Let me know here how you get on.

I tried that, and sadly it had no effect.

It did lead me to play around with the PHP by commenting out chunks of code, and retrying.

it's not until i uncomment this line: $this->WalkOrderTree($oNode); i get the crash.

if i leave this one line commented out i get no problems (although i also get no tax added)

[brucet]

Please try the following:

- Find the file Taxmodule.php (normally in C:\Program Files (x86)\SellerDeck\SellerDeck 2016\PHPModules, or whatever is your SellerDeck 2016 install path)
- Take a backup copy of the file
- Open the file in Notepad or a similar application
- Search for
$oNode->SetAttributeValue('ordertax1rounded', $this->m_fOrderTax1Rounded);
- Replace with
$oNode->SetAttributeValue('ordertax1rounded', intval($this->m_fOrderTax1Rounded));
- Restart SellerDeck Desktop

I can't reproduce you crash in v16.0.1 adding a £72.56 product to a MOTO order. But the above fix resolved a very similar crash that was reported to support in v16.0.0 and the cause is very likely to be the same.

Let me know here how you get on.

[Andy@codepath]

I didn't get to the bottom of the exact criteria to cause a failure as there is a lot of variance in the results, although as Andrew suggested earlier, VAT calculations ending in 1p do seem to be a common factor amongst values known to fail.

Adjusting the rounding method appears to have no effect.

[Andy@codepath]

I've asked for this to be investigated ASAP. Which version of SellerDeck are you using, please?

16.01 here Bruce. As per earlier post, 14.03 does not seem to be affected.

[Dealec]

I'm using 16.0.0 multiuser.

[Dealec]

The £105.05 product gives you exactly £21.01 in tax, so shouldn't cause any rounding.

At least things are starting to look less random compared to what i had yesterday

[brucet]

I've asked for this to be investigated ASAP. Which version of SellerDeck are you using, please?

[Andy@codepath]

So it could be a bug in the rounding algorithm sellerdeck are using for tax.

I wonder if using a different rounding type works as a temporary work around.

Could well be so, Mike. I'm just running some numbers to see if the error is specific to which direction the rounding takes, or if it's a specific offset from zero. Hope to know more soon.

[Andy@codepath]

i couldn't replicate the problem with a 5p product, and that gave me exactly 1p VAT, but if i use a 105.05 product i get the crash.

Yeah I can't seem to leave this alone :-) I've written a bit of code that generates a batch of products which all result in a xxx1 pence of VAT many work, many don't. Looking like it has to be in the higher range as well but still playing about with it.

[Dealec]

i couldn't replicate the problem with a 5p product, and that gave me exactly 1p VAT, but if i use a 105.05 product i get the crash.

[Mike Hughes]

However it does not fail with 87.07 with Tax disabled entirely. It can be safely assumed that it's a bug in the tax calculation.

Working out the VAT for each problem number you get a number ending in 1 (after rounding).

So it could be a bug in the rounding algorithm sellerdeck are using for tax.

I wonder if using a different rounding type works as a temporary work around.

[Andy@codepath]

if you can make an order total reach £427.26 inc VAT you'll get the same problem.

Working out the VAT for each problem number you get a number ending in 1 (after rounding). No idea if that's relevant, but might be worth checking.

I'd say that's too coincidental to ignore so possibly at the root of it. I've made SD aware of this so I doubt there's much more to be done until someone there has had a look at the code.

[Dealec]

if you can make an order total reach £427.26 inc VAT you'll get the same problem.

Working out the VAT for each problem number you get a number ending in 1 (after rounding). No idea if that's relevant, but might be worth checking.

[Andy@codepath]

Well this sounded too strange not to give it a try and I was fully expecting it to work and that the problem was something very specific to your situation.

Er, no. £72.56 on a clean 16.01 demo site (MOTO order) crashes Sellerdeck here too!

I'm currently juggling that number in any way I can think of to see how it might break a field constraint or something.

Findings so far:

1) It's not shipping related as switching off shipping charges entirely does not resolve it.

2) It also fails on 87.07 with a tax inclusive setting (i.e. the same line price as your 72.56 tax exclusive product); this is the case for both Simple and Advanced tax models. However it does not fail with 87.07 with Tax disabled entirely. It can be safely assumed that it's a bug in the tax calculation.

3) This behavior is not evident in v14.03