Hi Joe,

There is a new setting on the AvaTax configuration page. It is called Commit Tax and the choices are 1) when order is created, and 2) when order is paid.

So the issue report title doesn't accurately reflect this change. If post-order changes are expected, then using the option to commit tax when the order is paid should be used. This gives you the ability to recalculate, make order edits, etc. and the tax transaction sent to Avalara will happen with the order is paid.

The old behavior is the other setting to commit tax when the order is created.

Let me know if you have any questions.

And yes, I haven't had the chance to get this into the documentation yet. Sorry, it's on my to-do list.

But what happens if the order is already paid, and then the order is changed?

Recalculate() is going to get new tax amounts. Now the order total is different. But Recalculate() never updated the existing (committed) transaction in Avalara. So now Avalara is reporting different sales totals and sales tax than what is actually showing in the AC9 order.

Here's a simple scenario:
If someone places an order, pays for the order and then calls to cancel a portion of the order, Avalara will never know. The merchant will edit the line items, and then click the Recalculate() button. The order now gets a much lower tax amount and the shopper is issued a partial refund.

But Avalara doesn't know. The Avalara transaction was never updated when tax was recalculated. so the merchant will pay more sales tax to the tax authority than they actually collected from the shopper.

On a $27.50 order, this isn't much to care about. On a $ 43,000 order this is a serious problem.

If taxes are already committed, and you recalculate. In this case we not only recalculate the tax but also post tax adjustments in Avalara. If taxes are not committed yet and you do recalculate. In this case we just calculate the new tax without any adjustments to Avalara.



Recalculate do post the adjustments if taxes are already committed and you are making updates.

Hi Joe,

Bear with me as I try to dig out some information from our development discussions.

This is what should be happening -

1) We implement the tax adjustments to committed transactions using AdjustTaxRequest whenever changes are made to order.

2) In both cases where items are removed or added we simply create a new adjustment transaction which will override the previous one unless the previous transaction is locked by Avalara.

3) if successfully adjusted we update our local tax details for order.

---

Can you first confirm the transaction is not locked?

Then, if you can look at the transaction details, there should be a line "Adjustment Reason" shown. What do you see there?

Katie try this scenario and see how it works for you:

Place an order, pay it during checkout (I used PO and marked received in admin)
Order is correctly pushed to Avalara and numbers match between Able and Avalara

Now add something to the order. I added another item rather than edit existing item.
Click Recalculate

Tax is now recalculated. And if you check Avalara, it too also shows the new line item you just added.

But the order now has a balance because you added to it. So go add another PO payment and mark it received.

I think that's causing the because the WhenOrderIsPaid() is firing again and wants to create another transaction in Avalara. But that DocId already exists and so Avalara response is error.

At that point, in my testing, now Avalara numbers are different from the Able order totals. The difference is the shipping. When I click Recalculate, Able recalculates taxes AND shipping. But the Avalara gateway isn't pushing the updated shipping charge (you added something to your order). The gateway seems to be only pushing product line items.

So now my Avalara order total is different than my Able order total :(

I have a theory.

The sequence in which things are getting recalculated could be the problem.

If taxes recalculate (and post to Avalara) BEFORE both shipping is recalculated and the order is updated with new shipping charges, that would explain the behavior.

In test # 3, I just fired another recalculate after making a huge change on my test order. Avalara now shows the previous shipping charge from Test #2. Not the first shipping charge.

That tells me it is updating shipping in Avalara, it's just doing it before shipping was recalculated rather than afterwards.

I think it's a sequence-of-events thing.......

Hi Katie,

So much confusion here because all 50 states have different procedures. First let me start by saying, in the state of Florida shipping is not taxable, but it is in other states, so having the order recalculates shipping only and then recalculating taxes will only work in specific states.

That's your first problem.

Your second issue is, an order usually becomes taxable once it is set to complete, complete can have many definitions, it could mean the order was picked up, the order was shipped, and 20,000 other scenarios. Typically, in the state of Florida, it means the customer took possession.

If an order is complete for whatever reason, one should not be adding to a completed order, a new order is better suited for that. Maybe this is not the way a developer thinks, but it's the way accountants think.

Yes, I'm aware that could create issues for the customer, but it creates even more issues if you don't have someone in the accounting department that knows what they're doing.

Everything that Joe is bringing up, could be better handled by someone in accounting that knows what they're doing. You cannot program AbleCommerce with case statements to try to anticipate the will of 50 different states, and then the different cities within those states. The software can only do so much.

So if the software is miscalculating in one state, it's probably working perfectly in another. This is where good reporting comes in, and based on those reports you should have someone in accounting to make adjustments to the proper agencies.

This is why when an order is set to complete, we don't change it unless it gets reviewed by accounting for this very reason. This is also why we lock our orders after a specific time frame, even an administrator cannot manipulate a lock order, unless you go to the database itself and unlock it.

I have over 32 years in accounting, there's only so much software can do, anything after an order gets completed should go to accounting for review. It will eliminate a lot of the concerns being discussed here.

Probably the reason Avalara is having difficulties is that it's following a set of rules known as GAP principles. Good luck trying to work around General Accounting Principles, you will fail.

Not attempting to step on people's toes here, but it is the responsibility of the business owner to have certain procedures in place for situations like this.

Good luck with this, but you're not going to find a solution if you're trying to deviate from GAP.

Hello,

The concern here is that the re-calculation in Able does not match the tax adjustment in AvaTax. It's a bug, and luckily, an easy fix.

I've seen Able used in many different ways, and it's really up to each business to decide how to handle the post-order edits. We allow it with no restrictions, but custom order statuses could be used along with internal business practices to prevent editing once the accounting has been finalized. If you want to take it a step further and modify the code to prevent edits, that works too.

Thanks for the feedback!