Rank: Advanced Member
Groups: HelpDesk, Developers
Joined: 11/9/2018(UTC)
Posts: 564
Thanks: 122 times
Was thanked: 26 time(s) in 25 post(s)
|
When Avalara calculates a basket, it pulls in the user.PrimaryAddress.Email as the Avalara Customer Code. Just like it should.
When Avalara commits an existing order, it uses the order.BillToEmail as the Avalara Customer Code. Just like it should.
However, when you recalculate an existing order via public override Recalculate(Order order), the routine doesn't use the order bill-to email as the customer code. It pulls in the user.PrimaryAddress.Email.
This becomes a problem if the order bill-to is changed after the order is placed, but before taxes are committed. Changing the bill-to email on the order does not update the user.PrimaryAddress.Email field. And worse, there is no way to see or edit that user.PrimaryAddress.Email field on the customer profile Addresses tab. It's not part of the page view.
So in situations where order bill-to is changed after the order is placed, taxes will now calculate based on the original user.PrimaryAddress.Email regardless of what you have set on the order bill-to email. If the PrimaryAddress.Email is taxable but the order bill-to is not taxable, you can never get taxes to come off no matter what you change on the order. Because the customer code being sent to avalara is never the order bill-to email value.
|
|
|
|
|
|
Rank: Advanced Member
Groups: System, Administrators, Developers, Registered, HelpDesk
Joined: 10/29/2018(UTC)
Posts: 429
Thanks: 4 times
Was thanked: 34 time(s) in 33 post(s)
|
Hi Joe, I'm having some trouble trying to reproduce the issue. I will go through the steps that I'm taking, but first, I wanted to address a few things you mentioned. Quote:This becomes a problem if the order bill-to is changed after the order is placed, but before taxes are committed. Changing the bill-to email on the order does not update the user.PrimaryAddress.Email field. Changing the order email will not update the user account email. This is by design. Quote:And worse, there is no way to see or edit that user.PrimaryAddress.Email field on the customer profile Addresses tab. It's not part of the page view. The email for the user account can be changed from the first tab "Account" in admin. Here are the steps I'm taking to reproduce. For AvaTax, I am using the setting "Commit Tax when order is paid" and my order is in an authorized state. 1. Placed an order where Billing and Shipping address are both in Washington state. 2. Changed order email and billing address to Florida. (Recalculate, no change in tax as expected) 3. Changed the shipping address to Florida. (Recalculate, the tax was changed to FL as expected) 4. Apply payment to the order so the tax will be committed to Avalara. 5. So now I login to AvaTax and view the transaction. - The order's updated email address is correct (matches order billing email) - The shipping address and taxes for Florida are correct as well. - New tax on the adjusted order is 3.21 - Orig tax on the order was 3.57 I must be missing something. If you can help me figure it out where I've gone wrong, I would appreciate it. Thanks Joe! |
Thanks for your support!
Katie
Secure eCommerce Software and Hosting |
|
|
|
|
|
Rank: Advanced Member
Groups: HelpDesk, Developers
Joined: 11/9/2018(UTC)
Posts: 564
Thanks: 122 times
Was thanked: 26 time(s) in 25 post(s)
|
OK, let's try a less-complex explanation.
Place an order with an email you know is taxable. You should get sales tax on the order.
Now change the order's bill-to email on that order to an email you know is tax exempt in Avalara.
Now recalculate the order.
Sales tax will still be on the order. Taxes should have come off because you changed the email on the order, right?
But the Avalara Calculate() routine is still using user.PrimaryAddress.Email as the customer code. So in reality, you as the admin cannot change the Customer Code being sent to Avalara once the order is generated. No matter what order.BillToEmail says, Avalara only knows the customer as the value of user.PrimaryAddress.Email.
If the customer changes their own email, or the admin changes the user's email address...the user.PrimaryAddress.Email is now changed. Great except.......
At that point, if a Calculate() is ever fired on that user's order you have the problem: You could now see taxes on an order that was not taxable before and the order suddenly has a mystery balance. Or, taxes disappear and the order now has a mystery credit.
|
|
|
|
|
|
Rank: Advanced Member
Groups: System, Administrators, Developers, Registered, HelpDesk
Joined: 10/29/2018(UTC)
Posts: 429
Thanks: 4 times
Was thanked: 34 time(s) in 33 post(s)
|
Got it. Thanks for explaining in terms I can understand. :)
For Avalara to use an email address for the customer ID doesn't seem like the smartest idea. Emails change.
Anyway, I'll get it reported. |
Thanks for your support!
Katie
Secure eCommerce Software and Hosting |
 1 user thanked Katie S for this useful post.
|
|
|
|
Rank: Advanced Member
Groups: HelpDesk, Developers
Joined: 11/9/2018(UTC)
Posts: 564
Thanks: 122 times
Was thanked: 26 time(s) in 25 post(s)
|
Technically, it's the Avalara gateway programming that decides the Customer Code value. Avalara can use anything in that field. The UserId value would have been more accurate from a design standpoint.
But, then you couldn't search in the Avalara Dashboard for a customer unless you knew the user ID. Searching by email is vastly easier for store admins. So in the end using email is the better route.
Sorry for the initially poor explanation.
|
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The AbleCommerce Forums uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
