Here is my change price rule. I have tried moving it infront of the update discount rule to check if that would help but does not.
Apreciate your comments kendash.
Furtheur tinkering and its nothing to do with the automation of changing price.
If I do the following it still happens;
Add 1 order
Add another order
Change price of seccond order to 0
Cancel first order
CRASH
Looks like it’s trying to still calculate something. Notice the balance even though ticket is zero.
The error specifily mentions tax…
So unmap taxes see if it does it.
Ok, will try tomorrow.
Unmapped tax and doesnt happen anymore…
What do you suggest?
I suggest figuring out why tax is not recalculating when you change price to 0. Under most circumstances it does so something is blocking that. I am thinking its the way you are changing price… there is a hardcoded element to it that I think taxes are tied too.
Im pretty confident the issue is the combination of discounts and tax.
It only does it with discounts applied and tax active.
Think maybe whatever catches issue normally hasnt been applied when discount part calculated.
If I I set the calculation type to ‘include tax’ which actually would make more sence as exclude tax as its still calculated on the total before discount it doesnt happen.
I would say @emre could you look at this but probably not going to help.
How are you doing discounts?
Calculation though math and update calculation.
If I set calculation to ‘include tax’ (aka exclude tax) it doesnt crash.
Unmap tax no crash.
Tax mapped and no calculation no crash.
Pretty confident its the tax part of the calculation causing the crash.
Origionally though it might be the math for working out the calculation
[=Math.floor((TN('{TICKET ORDER TOTAL EXP:(OS.NewBook GLA=2101)&&(ODI=True)&&(OS.GStatus= )}')*0.1)/0.05)*0.05]
Since there was a divide in here and it would be dividing 0 product price however changing to this;
[=Math.floor(((TN('{TICKET ORDER TOTAL EXP:(OS.NewBook GLA=2101)&&(ODI=True)&&(OS.GStatus= )}')+0.01)*0.1)/0.05)*0.05]
To prevent a 0 order total still crashes.
So are you actually using that expression in a Calculation Type?? I am confused what you mean by Calculation through math?
Im using update calculation action with a [=calculation] to work out the value.
I said maths rather than say using calculation to update calculation lol
So you probably need to clear the calculation before you change price to 0. Since your using automation for it, it is probably trying to calculate on 0 which causes the crash.
But no tax stops crash.
And adding 0.01 in the calculation to prevent 0/0.05 (the rounding maths)
Pretty sure its not the calculation update thats causing the divide by 0 issue but the tax coding doesnt have a exemption when discounts are involved.
I cant forse calculation to update before tax as tax automation is hardcoded.
If I add expressions to only update if orders have a value and clear calculation if not (using actions in place for if discount type is removed/changed it doesnt help;
Can you please post a “pseudo” calculation that you believe is being performed when the divide by zero “with Tax and Discount [calculation]” error occurs?
Walk us through it step-by-step using small formulas with known values instead of all the Report/Expression junk in there.
For example, if I were to Calculate Tax on something:
taxAmount = price * (tax / 100)
totalPrice = price + taxAmount
… or shorter:
totalPrice = price + ( price * (tax / 100) )
Given:
price = 10
tax = 25
… then:
totalPrice = 10 + ( 10 * (25 / 100) )
totalPrice = 10 + ( 2.5 )
so...
totalPrice == 12.5
I see no opportunity for “divide by zero”…
Given:
price = 0
tax = 25
… then:
totalPrice = 0 + ( 0 * (25 / 100) )
totalPrice = 0 + ( 0 )
so...
totalPrice == 0
… that’s what I would expect.
How does the Discount calculation come into play that might cause this?
I’m not sure…
0 total with tax setup is fine
Non 0 total with discount applied and tax setup is fine
0 total with discount setup but no tax mapped is fine
But 0 total with discounts and tax setup causes crash…
If iscount is set to not include tax it’s ok
I think it’s calculating tax on plain total and the tax on the discount and that’s causing issue somewhere in the flow.
Kendash said to push the removal of the discount when it changes to 0 to top/first but since we can’t choose where tax is calculated in automation order I think it’s updating the tax before automation has had chance to run.
I can’t say for sure but there is an issue somewhere.
Either that for it doesn’t like calculating tax on a 0 total (0 divided by rather than divided by 0 perhaps but maybe there is a exception/catch code which prevents the crash.
I’m sure I remember an issue with crashing related to 0 total or tax before and it got fixed.
I hoping emre does some work on discounts in v6 as the reset ticket option of apply callculation is a ball ache, it interfered with autoselect and other automation and if you don’t reset it doesn’t refresh on screen or changing portion/selecting tag unselects order. What should be simple automation becomes hard on a more built up system.
I read the entire Topic. I understand all that. Please provide a sample of what you think might be happening, in the sequence in which you think it happens.
Show your Calculation Type configuration.
Possibly there could be a workaround using calculation set to “Custom”, or using a Calc Processor, but the problem must be fully understood first.
For example, we know that Tax is Product-based, and Calcs are Ticket-based, and Calcs can operate with or without Tax consideration.
I prevented “divide by zero” crash but I’m not sure if it calculates tax as expected in your case. I’ll be glad to know if you notice something related after next update.
1 Like