invoice create returns error : You cannot validate a non-balanced entry (rounding error)

[Niels Huylebroeck]

After upgrading to 5.0.6 a client now runs into this problem,

Some combinations of products ( with taxes and discounts ) give the error
"Integrity Error ! You can not validate a non-balanced entry !"

Invoicing the products separately never gave an issue either.

After some debugging it turned out that the accumulated rounding error was larger than 0.0001 (see account.py:1024 in stable branch)

-> if abs(amount) < 0.0001:
(Pdb) amount
-0.0099999999999909051

I think this line should be changed to following

if abs(amount) < ( 1.0 / ( int(config['price_accuracy']) * 10 ) ):

*note*: beware the parentheses, it seems python has an issue with 1.0 / 2 * 10 being 5 (so it's not multiplying before dividing)

[Niels Huylebroeck (red15)]

I think the reason it's now happening in 5.0.6 is because in the accounting more changes to honor the config['price_accuracy'] variable, so in various places it's already trying to round more correctly ?

Strangely enough my price_accuracy should have always been 2 as well, so I could be wrong with this hunch.

[Niels Huylebroeck (red15)]

hmm, slight correction, it must be getting late :D

if abs(amount) < ( 1.0 / ( 10 ** int(config['price_accuracy']) ) ):

[Niels Huylebroeck (red15)]

Further testing shows this change allows to write booking where 0.01 difference exists between the credit and debit sides...

So clearly this is not solving my problem it's only allowing me to create bookings with small differences and bypasses the error.

The rounding is still an issue and for this particular case the rounding error becomes so bad these entries fail to validate...

Conclusion a more permanent solution is needed.

[Vinay Rana (OpenERP) (vra-openerp)]

Hello niels - bubbles -it,

When will you face this problem? Actually In current situation account_move_line field debit, credit and tax_amount are by default digits=(16,2) so i think it should be digits=(16, int(tools.config['price_accuracy'])).
But The error ("Integrity Error ! You can not validate a non-balanced entry !")only raise when the debit and credit balance will not be matched.because the move_line debit and credit field are not exactly what user inputs but rounded in 2 decimal point.
May be this issue will solve after setting price accuracy (digits=(16, int(tools.config['price_accuracy'])))in debit,credit and tax_amount field.
Notify me.
If steal you will face similar problem then can you provide me your side situation with example so i can reproduce it my side.
Hope This will help you.

Thanks.

[Niels Huylebroeck (red15)]

I dont see how replacing digits=(16,2) with the config value will help me, as i'm also only using price_accuracy = 2 ...

[Vinay Rana (OpenERP) (vra-openerp)]

Hello,

Can you provide me proper explanation or steps with example so i can check my side because i cannot reproduce your problem at my side.

Thanks.

[Niels Huylebroeck (red15)]

2x products with unit_price 172.62 discount 55%
2x products with unit_price 315.32 discount 63%

Each line has 21% vat and a fixed tax of 10.80 per unit( which should be added to base amount before the vat is applied)

The total sum of the invoice and taxes should be 522.60, but on the affected system its 522.59

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello,

I'm not sure, but isn't that a duplicate of that bug:
https://bugs.launchpad.net/openobject-addons/+bug/328077

In that case, starting the server with --price_accuracy=4 doesn't fix the
issue?
Still, as I said in the bug tracker, I can't understand the default rounding
approach chosen by Tiny, me and a lot of other people would just have chosen
the opposite: round the total and not each line... Can't understand Syleam
here sorry.

So, is it the same or a new one? Does the proposed fix meet your expectation
(it doesn't for me, starting with --price_accuracy just sucks).

Raphaël Valyi
http://www.akretion.com

On Wed, Jan 13, 2010 at 2:28 PM, Niels Huylebroeck <
<email address hidden> <red15nls%<email address hidden>>> wrote:

> 2x products with unit_price 172.62 discount 55%
> 2x products with unit_price 315.32 discount 63%
>
> Each line has 21% vat and a fixed tax of 10.80 per unit( which should be
> added to base amount before the vat is applied)
>
> The total sum of the invoice and taxes should be 522.60, but on the
> affected system its 522.59
>
> --
> invoice create returns error : You cannot validate a non-balanced entry
> (rounding error)
> https://bugs.launchpad.net/bugs/506521
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> After upgrading to 5.0.6 a client now runs into this problem,
>
> Some combinations of products ( with taxes and discounts ) give the error
> "Integrity Error ! You can not validate a non-balanced entry !"
>
> Invoicing the products separately never gave an issue either.
>
> After some debugging it turned out that the accumulated rounding error was
> larger than 0.0001 (see account.py:1024 in stable branch)
>
> -> if abs(amount) < 0.0001:
> (Pdb) amount
> -0.0099999999999909051
>
> I think this line should be changed to following
>
> if abs(amount) < ( 1.0 / ( int(config['price_accuracy']) * 10 ) ):
>
> *note*: beware the parentheses, it seems python has an issue with 1.0 / 2 *
> 10 being 5 (so it's not multiplying before dividing)
>
>
>

[Niels Huylebroeck (red15)]

Following actions seem to have fixed the issue:

ALTER TABLE account_invoice ALTER COLUMN amount_untaxed TYPE numeric(16,2);
ALTER TABLE account_invoice ALTER COLUMN amount_tax TYPE numeric(16,2);
ALTER TABLE account_invoice ALTER COLUMN residual TYPE numeric(16,2);
ALTER TABLE account_invoice ALTER COLUMN amount_total TYPE numeric(16,2);
ALTER TABLE account_invoice_line ALTER COLUMN price_subtotal TYPE numeric(16,2);
ALTER TABLE purchase_order ALTER COLUMN amount_untaxed TYPE numeric(16,2);
ALTER TABLE purchase_order ALTER COLUMN amount_tax TYPE numeric(16,2);
ALTER TABLE purchase_order ALTER COLUMN amount_total TYPE numeric(16,2);
ALTER TABLE sale_order ALTER COLUMN amount_untaxed TYPE numeric(16,2);
ALTER TABLE sale_order ALTER COLUMN amount_tax TYPE numeric(16,2);
ALTER TABLE sale_order ALTER COLUMN amount_total TYPE numeric(16,2);

2 being the number of my price accuracy ofc

[Cristian Salamea (ovnicraft)]

in account_move_line debit and credit file are not with digits=(16, int(tools.config['price_accuracy']) so start server with --price_acurracy=N will not solve, maybe fix all function and float fields in addons with this config could help, and / * has the same priority in python is not an issue.

Cristian,

[julien tanguy (jt-vegeplast)]

I encountered the same bug with price_accuracy=4

I changed floats digits to ['price_accuracy'] in account_move_line (debit, credit and so on)... Works like a charm now.

[vmajor (victor-major)]

I just encountered this bug on version 5.0.14 compiled on Ubuntu 10.04.1 Server using web client 5.0.14.

I am end user so all I can say is that while searching for the explanation for the "You cannot validate a non-balanced entry " message when trying to create invoice delivered me here to this bug submission page.

[Borja López Soilán (NeoPolus) (borjals)]

@vmajor You may want to attach a screen-shot of the invoice being created, or at least provide us the list of product lines you were using, so we can try to reproduce it.

[Lucas (lucasbrosnon)]

please solve this more explanationa bout rounding needed.

[Azazahmed Saiyed (OpenERP) (saz-openerp)]

Hello Lucas,

This is in response to your last comment, If you are reopen the bug from it's previous state to new you should have some proper explanation or steps for reproducing the bug and also specified the version in which you have faced this.

This code is no more active in current branch as we are using the function digits_compute=dp.get_precision('Account') for all accounting transaction.

For now I am closing this bug, If you have some proper information then you can reopen or post a new one.

Thanks for your participation.