You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I apologize for the vagueness of this, but that's essentially problem: I can't figure out why something isn't happening.
We have an existing production site current running Solidus 1.4 with solidus_avatax_certified v1.1.0. Taxes are recalculated at all the expected times, provided an address is on the order:
Whenever an item is added or removed
Whenever discounts are applied or removed
Whenever the ship address is changed
etc...
After a long upgrade process culminating in Solidus 2.6 + solidus_avatax_certified 3.0.0, taxes are no longer being calculated in many of these situations. The most confusing part is that sometimes they are calculated.
It's not a simple Avatax configuration issue. Our license key and account have not changed, and when the solidus_avatax_certified actually calls the Avatax API everything works. I can see the calls via the Avatax logs, specifically tracing to order_decorator.rb#avalara_capture:
This method just doesn't get called at all many of the times we expect it to. Sometimes when I proceed from delivery to payment states, avalara_capture fires, sometimes it doesn't. Sometimes when I add or remove a line item avalara_capture fires, sometimes it doesn't.
I can see that new functionality in solidus_avatax_certified introduced since v1.1.0 would explicitly avoid recalculating taxes in cart, address, or delivery state:
...but I don't know if this is actually what is preventing the taxes from being calculated, or whether this is functionality we even want.
So, have others reported similar challenges updating from earlier Solidus and solidus_avatax_certified versions?
In short, I expect taxes to always be recalculated when any applicable change to the order occurs, but observed behavior is that they are only calculated sporadically.
The text was updated successfully, but these errors were encountered:
@joshua-honig did you figure out the root cause? I'm seeing similar issues with tax calculation not being triggered in some situations and working fine in others
I apologize for the vagueness of this, but that's essentially problem: I can't figure out why something isn't happening.
We have an existing production site current running Solidus 1.4 with
solidus_avatax_certified
v1.1.0. Taxes are recalculated at all the expected times, provided an address is on the order:After a long upgrade process culminating in Solidus 2.6 +
solidus_avatax_certified
3.0.0, taxes are no longer being calculated in many of these situations. The most confusing part is that sometimes they are calculated.It's not a simple Avatax configuration issue. Our license key and account have not changed, and when the
solidus_avatax_certified
actually calls the Avatax API everything works. I can see the calls via the Avatax logs, specifically tracing toorder_decorator.rb#avalara_capture
:solidus_avatax_certified/app/models/spree/order_decorator.rb
Lines 21 to 28 in 9ae4b29
This method just doesn't get called at all many of the times we expect it to. Sometimes when I proceed from
delivery
topayment
states,avalara_capture
fires, sometimes it doesn't. Sometimes when I add or remove a line itemavalara_capture
fires, sometimes it doesn't.I can see that new functionality in
solidus_avatax_certified
introduced since v1.1.0 would explicitly avoid recalculating taxes incart
,address
, ordelivery
state:solidus_avatax_certified/app/models/solidus_avatax_certified/order_adjuster.rb
Lines 1 to 12 in 9ae4b29
solidus_avatax_certified/app/models/spree/calculator/avalara_transaction.rb
Lines 39 to 52 in 9ae4b29
...but I don't know if this is actually what is preventing the taxes from being calculated, or whether this is functionality we even want.
So, have others reported similar challenges updating from earlier Solidus and
solidus_avatax_certified
versions?In short, I expect taxes to always be recalculated when any applicable change to the order occurs, but observed behavior is that they are only calculated sporadically.
The text was updated successfully, but these errors were encountered: