base of account.invoice.tax is different from amount_untaxed of account.invoice

Hello Eduard Carreras i Nadal,

Would you please apply the patch and notify us.

Thank you.

Well, now base is rounded correctly but the result of base * tax is not rounded correctly.
122.1 * 0.16 = 19.536 => 19.54

This causes that provider invoice is 141.54 and mine is 141.63.

I attached a screenshot.

I've made a patch that works for me, and I feel more appropriate to use line.price_subtotal rather than to recalculate it (note that price_subtotal function already rounds the total with currency object)

Hello Eduard Carreras i Nadal,

I agree, the 'tax_amount' did not get a rounded value.

I have attached a patch which resolves both the issues. Please apply the same and notify us.

Thank you for pointing out to this issue.

I don't understand your patch code:
1. In invoice.py line 1243 val['amount'] is assigned to tax['amount'] IMHO this is the place to round tax['amount'] instead of doing the same operation in each branch of the conditional statement.
2. Why price_subtotal is recalculated every time when passed as a parameter? We have already calculated and rounded it correctly...

Hello Eduard,

It seems if you setting "price_accuracy=6", you want precision upto 6 digits.
Then there seems no need for the rounding to be done as it will report accurate values.

I think this should be the behaviour so I have refined the patch.

Would you please apply the patch and notify us?

Thanks.

JMA, one thing is *price* accuracy which means that products can have an accuracy up to 6 and another thing is my currency which has an accuracy of 2.

Please be carefull on the fact you can have severals taxes on the same product/sale.order.line.

For example, you can have VAT + WEEE (ecotax).

Use this also for checking non regression ;-)
Even with tax included in price, and so on

May be subtotal of line should be rounded according to number of decimal in accouting, because it will be record in account.move.line.

Agree with Claude Brulé

On Thu, Jun 24, 2010 at 8:01 PM, Claude Brulé - http://www.Syleam.fr/ <
<email address hidden>> wrote:

> Please be carefull on the fact you can have severals taxes on the same
> product/sale.order.line.
>
> For example, you can have VAT + WEEE (ecotax).
>
> Use this also for checking non regression ;-)
> Even with tax included in price, and so on
>
> May be subtotal of line should be rounded according to number of decimal
> in accouting, because it will be record in account.move.line.
>
> --
> base of account.invoice.tax is different from amount_untaxed of
> account.invoice
> https://bugs.launchpad.net/bugs/591662
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> I'm using version 5.0.11.
>
> Steps to reproduce the issue:
>
> I've tested this with Spanish and Belgian chart of accounts
>
> 1. Have a database with price_accuracy = 6
> 2. The currency is EURO with round = 0.01
> 3. Create a new invoice (client or provider, it doesn't matter)
> 4. Introduce a line with quantity = 254 price = 0.057035 and choose any
> non-zero tax from the drop-down.
> For example: for Belgium Chart of Accounts I've set "x VAT" and for Spanish
> Chart of Accounts I've set "IVA Soportado 16% (Operaciones corrientes)". It
> doesn't matter which tax you choose, provided you choose one, so the invoice
> view will show the base used for tax calculation differs from the invoice
> base
> 5. Click on the button to calculate the taxes.
>
> The value of base from invoice is different from base of tax.
>
> Workaround and ideas:
> * The subtotal of each invoce's line is rounded to currency precission (in
> this case 0.01, two decimals). When calculating the base for taxes the base
> isn't being rounded.
> * Why the subtotal is recalculated to get the base for tax when we have a
> subtotal calculated field?
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-addons/+bug/591662/+subscribe
>

--
Eduard Carreras i Nadal <email address hidden>
http://ecarreras.blogspot.com
http://ecarreras-tec.blogspot.com

Hi all,

Sorry if we don't have the time to fix all bugs, but this one will be fixed for the next release.

Hi guys,

Does it look like an issue of confusion whether to take accuracy of currency of price_accuracy?

Is the patch in comment #5 approachable?

I am investigating in order to get rid of such a high accuracy precisions.

Thanks.

Hi Jay,
you have my response in #6, I don't understand the patch, seems crappy.

Hello Eduard,

I had a close look at the issue and have come up with a patch.

There's just a slight modification, the amount value which comes is already rounded in tax_grouped values so just the base value had to be passed.

We have undergone sheer tests for all the price_accuracy = 2,3,4,5,6.
The values showed up perfectly.

Please apply the patch and notify us.

I hope this helps.
Thanks.

Thanks experts.

Fixed in : by

Stable : 2868 <email address hidden>
Trunk : 4245 <email address hidden>.

Hi,

do you know that the applied patch does not work? It still fails to calculate the invoice and tax bases, they're different.

I have tested the patch from Eduard and it does work.

Please, can you re-read (and understand!) the whole conversation and apply the patch from Eduard? And I suggest you to test your patches with prices that actually have more than two decimal numbers so you'll see how your patch fails.