openerp-expert-accounting team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Hi everyone,


I post again here because we still need a solution :) !

If I agree with most aspect of what you spoke about (the way to properly handle it, OFBiz specs, and so ...), 
this is only possible on the next coming version 5.2. I already write a blueprint to centralize every one's ideas here :

https://blueprints.launchpad.net/openobject-addons/+spec/generic-accuracy-improvement

So please, post your advice and though here, so will try to find a "community" solution for that !

But for now, we still have a big trouble : Depending on currency exchange rate, we still can't confirm some invoices !!!!

I'll suggest to handle it the following:

When the balance isn't respected on the invoice confirmation (raising an error), OpenERP automatically add the difference 
on the line with the greatest amount. That means, in my example, OpenERP will add 0,01 CHF.- on the 1144.0.- Line.

Doing that will avoid the error, and allow the user to confirm the invoice. I know this is not perfect, but as we saw, I
can't suggest a better solution, or my merge proposal will be refuse... Saying it's too much for a stable version... And the
worst is that I'll agree on that. 

Implementing a good write-off system per currency AND implementing Decimal should be the good one in my own opinion...

Are-you ok if I start with that ?

Kind regards,


Joël

P.S. As a proof/reminder, I put my Scenario test case to let you reproduce and understand things:


  Background:
      Given I am loged as admin user with password admin used
      And the company currency is set to EUR 
      And the following currency rate settings are:
      |code|rate|name|
      |EUR|1.000|01-01-2009|
      |CHF|1.644|01-01-2009|
      |CHF|1.500|09-09-2009|
      |CHF|0.6547|10-10-2009|
      |USD|1.3785|01-01-2009|
      And a cash journal in USD exists
      And a cash journal in CHF exists
      And a cash journal in EUR exists

  Scenario: check_rounding_diff_multi_line_inv
    Given I have recorded on the 11 oct 2009 a supplier invoice (in_invoice) of 1144.0 CHF without tax called MySupplierInvoiceRounding
    And I add a line on the last created invoice of 91.73
    And I add a line on the last created invoice of 63.00
    And correct the total amount of the invoice according to changes
    When I press the validate button
    Then I should see the invoice MySupplierInvoiceRounding open
    And the total credit amount must be equal to the total debit amount
	# Here we check the rounding to see if sum(rounded lines) == total invoice amount * current currency rate
    And the total amount convert into company currency must be same amount than the credit line on the payable/receivable account




Le 20 janv. 2010 à 15:17, Ferdinand Gassauer a écrit :

> Am Mittwoch 20 Januar 2010 09:20:40 schrieb Jan Verlaan - Veritos:
> > OFBiz was in the same position we are now, I guess.
> ...snip
> > If you need numbers which would be multiplied to arrive at the final
> >  result, you should preserve as many decimal places as possible.  Ratios
> >  and unit costs, for example, should not be rounded.  After the
> >  multiplication, you should round your final result.
> > 
> for ratios and unit costs see 
> branch chricar_price_unit 
> We always store quantity and value (NEW field) in all records (stock_move) and calculate value/quantity if display of price is needed
> as both values are defined as numeric we think that rounding problems ( at least caused by stored values) can be excluded.
> My python knowledge is to limited to judge exactly what happens, but most sums are SQL statements - select sum(value) - and should be so for performance reasons (IMHO) so no prob here.
> for initial calculation of SO/PO value we use 
> quantity * price / factor of price unit (new field) to get sufficient precision and comply to specs of partners.
> Example 
> gasoline is quoted in cents here, lets say 134¢/liter
> so the value of 5.33 liters is
> 5.33 * 134 / 100 = 7.1422 - which is rounded to 7.14 as we uses 2 decimal digits which is defined by price_accuracy = 2 - these 7.14 are stored and used for all calculations.
> -- 
> Best Regards
> ChriCar Beteiligungs- und Beratungs- GmbH
> http://www.chricar.at/ChriCar/index.html
> Dr. Ferdinand Gassauer
> Official Tiny Partner
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp

-- 

Joël Grand-Guillaume 
OpenERP Consultant
Business Solutions

Camptocamp SA
PSE A, CH-1015 Lausanne
 www.camptocamp.com 

Phone: +41 21 619 10 28
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
Email: joel.grandguillaume@xxxxxxxxxxxxxx
http://www.camptocamp.com/fr/business-solutions/formations