I don't know if this could help but here in spain online stores could work
with or without tax include prices (oscommerce standar feature)

But for product lines on order, I'm always downloading prices without tax
taking price from product table.

For subtotal lines. I just download all subtotal lines that are not VAT,
subtotal or total (like shipping cost or discounts or coupons) as a product
on sales order line on OpenERP. I calculate this lines price without tax
before downloading.

Accuracy is 2 in all test cases and all orders are downloaded with exact
price shown on shop. ... my customers have not reported this kind of problem
to me. Our VAT tax is 16%. I don't know if this could be because of that.
Maybe with this tax there is less rounding problems, I don't know.

On addition, I totally agree with kn dati... we are on similar situation on
a steel manufacturing company.
They manage Tons to buy and sale, but prices have to be on kg because you
can't set 0,525€/ton. So you have to set 525€/tm
We would need accuracy=3 to manage this situation.

Thank you:

Ana


2010/3/10 Sébastien BEAU - http://www.akretion.com <
<email address hidden>>

> Hello guys,
>
> Here is a patch that seems working for us (more than 900 invoices imported
> from ecommerce successfully, with balanced entries with price_accuracy= 3 or
> 4).
> Now it deals only with the mono-currency case and we do not consider it
> clean code, but we wonder if OpenERP 5.0 would allow anything cleaner than
> that (not sure).
>
> What we do here is we explicitly make the sum of the tax be the the sum
> of the rounded line tax values (what we call method 2) in our expert
> list message), as they are rounded to 2 digits in the account move line
> (by legal requirements) and as we need to match that VAT total to match
> it in the accounting too.
>
> link expert team : http://n3.nabble.com/Floating-point-precisions-
> balanced-entries-and-VAT-included-reflexions-td430873.html#a433465<http://n3.nabble.com/Floating-point-precisions-%0Abalanced-entries-and-VAT-included-reflexions-td430873.html#a433465>
>
> The issue is that this VAT total and untaxed total amount seem to be
> computed at several places for reasons that do not look obvious at all,
> that's why we had to force rounding to 2 digits at several places:
> 1) at the end of the patch, we make the "VAT base" and "VAT total" from the
> down left tax panel widget be correct
> 2) in the middle, we get the the VAT included total of the customer account
> move line to be computed properly
> 3) on the top of the patch, we get the total untaxed displayed on the down
> right side invoice panel computed properly
>
> Please notice, from our expert team discussion, it seems that the 2
> decimal digits accounting accuracy shouldn't be hardcoded in general
> because some countries might require something different. Now, in our
> case, we didn't want to take the responsibility to introduce a new
> config param that would not be used properly by the rest of the code, so
> this is a general remark for 5.2, for now, we just hard-coded 2 digits
> in that patch.
>
>
> You can test the patch with this exemple :
> Price_accuracy = 3
> Taxe rate : 19,6%
> Product 1 : untaxed = 3,854
> Product 2 : untaxed = 5,301
>
> Total untaxed amount will be 9,15
> Total taxe amount will be 1,80
> Total amount will be 10,95
> And the invoice can be validaded without problem
>
> So what do you think about that proposal?
>
>
> ** Attachment added: "patch-taxe"
>   http://launchpadlibrarian.net/40721645/patch-taxe
>
> --
> Cannot validate invoices with foreign currency or price_accuracy=3
> https://bugs.launchpad.net/bugs/452854
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: In Progress
>
> Bug description:
> Hello,
> have stumbled upon interesting problem. Latvian Lats (LVL) is the base
> currency for Accounting. Try to issue (or encode received from supplier)
> invoice in Euros(EUR). The same would happen between any other currencies
> too.
>
> Invoice totals:
> Total w/o VAT (Untaxed): 1158,00 EUR
> Tax VAT 21% : 243,18 EUR
> Total: 1401,18 EUR
>
> Try to Confirm invoice and you will get "You can not validate a non
> balanced entry !"
>
> Made some investigation what is wrong, and have found that the problem is.
>
> Obviously the totals are calculated perfectly right, but as the base
> currency for accounting is different from the currency we are issuing
> invoice the accounting moves are done in the base currency, in this case
> LVL.
>
> So goes the currency exchange
>
> Total w/o VAT (Untaxed): 1158,00 EUR ->(813,8470320 ~813,85 LVL)
> Tax VAT 21% : 243,18 EUR ->(170,9078767 ~170,91 LVL)
> Total: 1401,18 EUR ->(984,7549087 ~984,75 LVL)
>
> Which again are technically right, with one difference, that the totals for
> posting are now not dependent on each other anymore. They are being rounded
> before posting.
>
> If you would issue invoice in a base currency the difference is in 0.01LVL,
> which is lost during rounding process. Notice the Total sum.
> Example:
> Total w/o VAT (Untaxed): 813,85 LVL
> Tax VAT 21% : 170,91 LVL (VO_VAT * 21% = 170,9085000)
> Total: 984,76 LVL (VO_VAT + VAT_21)
>
> To deal around floating point storage in Python (as well as other
> programming languages), allowed difference between sums are allowed 0.0001.
> This is the place where postings do not pass validate(...) function in
> "account.py".
>
> This is right as balance between credit and debit should be equal. What
> should be done - accountant would probably create write-off entry for the
> missing sum to make the balance right. This functionality is missing in
> OpenERP, and is fundamental for foreign trade.
>
> Any ideas?
>
> P.S. version 5.0.6.
>
> Kaspars
>
>
>


-- 
Ana Juaristi Olalde
Consultor Freelance OpenERP
www.anajuaristi.com
www.openerpsite.com
www.avanzosc.com
677 93 42 59 - 943 85 06 25