[13.0][14.0] account_avatax,account_avatax_sale : wrong calculation for sales taxes with small amounts

[metaminux]

Module

• account_avatax
• account_avatax_sale

Describe the bug

When dealing with small amounts, sales taxes are rounded and Avatax is sending different tax calculation for the same original price.
This gives strange but accurate amounts in sale order lines
Then, when creating the invoice, first amounts computed by Odoo are wrong.
Using the Compute tax button or posting the invoice is giving wrong amounts on lines, wrong total amount due and wrong journal entries
Finally, amounts declared to Avalara and amounts in Odoo are different, and documents issued to customers lead to wrong payment.

To Reproduce

• Odoo v13
• account_avatax v13.0.3.4.4
• account_avatax_sale v13.0.2.4.4

Steps to reproduce the behavior:

1. Install a brand new Odoo v13 database with demo data
2. Install account_avatax and account_avatax_sale
3. Configure Avatax API with tax calculation enabled
4. Configure Lines Subtotals Tax Display as Tax-Included in Accounting settings
5. Create a customer from Denver, CO
6. Validate the address through Avatax
7. Create a sale order for this customer with 10 lines of the same product (for example DESK005, qty = 1) at $0.45 for unit price
8. Confirm the SO
9. Here, tax amounts per line are different, but comes from Avalara (see confirmed SO and Avalara transaction screenshots below)
10. Deliver all goods to be able to invoice the SO
11. Create the invoice
12. Here, tax amount computed by Odoo are wrong (see Draft invoice screenshot below)
13. Post the invoice
14. Here, tax amount are wrong per line and total amount due is wrong too (see Posted invoice and Journal entries screenshots below)
15. Journal entries are also wrong
16. Finally, when registering payment, the wrong amount due (see Register payment screenshot below)

Expected behavior

• Subtotal amount tax-included in each invoice line should be the one returned by Avalara
• Journal entry amount for total tax should the one returned by Avalara

Screenshots

Confirmed SO

Avalara transaction

Draft Invoice

Posted Invoice

Journal entries

Register payment

[dreispt]

When creating the Invoice from the SO, I believe the Avatax calculated amounts are not copied in to Invoice, so the tax calculation is done by Odoo and might have small differences.
Maybe it would be a good idea to have them copied over to the Invoice, to minimize this.

But when the Invoice is to be Posted, Avatax recomputation is triggered, and the tax amount should be set to be the same as the ones returned by the API. So the described behavior is unexpected an incorrect.

[metaminux]

Hi @dreispt

I just installed a brand new Odoo v14 database with demo data and experienced the same bug.

The only difference is that tax rates are now different on each line, due to 97f17d7

Screenshot v14.0

[metaminux]

It seems there are 2 bugs here after posting the invoice :

• Tax included total (price_total) on each line is not the one returned by Avalara
• Credit computed on journal entries for taxes are wrong

The second one is due to the way compute_all is looking for invoice lines.

• for v13, see

  account-fiscal-rule/account_avatax/models/account_tax.py

  Lines 46 to 61 in d5e7693

  	def compute_all(
  	self,
  	price_unit,
  	currency=None,
  	quantity=1.0,
  	product=None,
  	partner=None,
  	is_refund=False,
  	handle_price_include=True,
  	):
  	"""
  	Adopted as the central point to inject custom tax computations.
  	Avatax logic is triggered if the "avatax_invoice" is set in the context.
  	To find the Avatax amount, we search an Invoice line with the same
  	quantity, price and product.
  	"""

• for v14, see

  account-fiscal-rule/account_avatax/models/account_tax.py

  Lines 55 to 70 in 8362c2f

  	def compute_all(
  	self,
  	price_unit,
  	currency=None,
  	quantity=1.0,
  	product=None,
  	partner=None,
  	is_refund=False,
  	handle_price_include=True,
  	):
  	"""
  	Adopted as the central point to inject custom tax computations.
  	Avatax logic is triggered if the "avatax_invoice" is set in the context.
  	To find the Avatax amount, we search an Invoice line with the same
  	quantity, price and product.
  	"""

As stated,

To find the Avatax amount, we search an Invoice line with the same quantity, price and product

But here, all lines have the same quantity, price and product...

[dreispt]

Hi @metaminux, the connector has not been tested for the Tax Included setting. Work may be needed to support that.

For "the way compute_all is looking for invoice lines", yes, I agree the heuristic used there does not work for these cases, and must be improved.

[metaminux]

Thanks @dreispt for the reply,

I already have some work done for the Tax Included part, I'll send a PR quickly, I hope.

I also tried to copy the Avatax amounts from the SO when creating the invoice (as you suggested earlier), but amounts are recomputed automatically, so I need to work a bit more...

For the "compute_all" part, I'm really struggling here for quite a moment and don't see any clean heuristic to improve the present one... I'll dig further

[dreispt]

I already have some work done for the Tax Included part, I'll send a PR quickly, I hope.

Great!

I also tried to copy the Avatax amounts from the SO when creating the invoice (as you suggested earlier), but amounts are recomputed automatically, so I need to work a bit more...

The point for the Avatax Amount field is for their value to be forced as a result, overriding the automatic computation.
So if the amounts are being carried from SO to INV, the Ivoice should use them and not recompute taxes.
Could #313 be related?

For the "compute_all" part, I'm really struggling here for quite a moment and don't see any clean heuristic to improve the present one... I'll dig further

I'm not totally happy with it either, and will happily replace it if I come up with something better.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.