openerp-expert-accounting team mailing list archive

[Ferdinand Gassauer <office@xxxxxxxxxx>]

> I do not agree we have 2 possibilities. We have 3 actually. :-)
Jan - I think suggestion 3 works well in an "isolated" world
storing and adding non - rounded values will mandatory lead to non equal sums 
ad different aggregate levels - 
to be audit proof crosschecking of all aggregates on all levels must be 
possible.
Example: to accomplish this I have introduced a stock_move.value which is used 
also for account.move.line debit/credit hence the same in stock accounting and 
financial accounting. all stock reports will report same values for all 
periods and accounts. 
rounding as you described will result in 
sum(all moves) != sum(product sums) - at least at "visual" level
that's also the reason why values must be stored as BCD (numeric and not 
float)
may be I miss something
> With respect to the named possibilities, I still believe these are 
> solving a erroneous visible behavior, not the bug itself.
> Like all rounding issues in Open ERP,  the problem is that rounding is 
> done to early and to often (read in every stage of storing into the 
> database) and using different styles/types of rounding in the whole 
> application. Result is rounding on a previous rounding, on a 
> pre-previous rounding, on a .......... where the error is cumulating itself.
> 
> When all data is stored in the database without rounding and only, only 
> then rounding is done in, always in the same manner, at the end of a 
> workflow e.g. the final invoice, no problem would occur.
> Still you can display on the fly rounded values on screen and reports 
> abstracted from the non-rounded values in database.
> 
> So in my opinion the only best solution would be to tackle the 
> rounding-issue in general by storing non-rounded values in the database 
> before reaching the end of a workflow.
> But i also see this would be a enormous rewrite to do. OpenERP should 
> have 2 rounding functions defined, one for specific financials and one 
> for general purpose like logistic and production. Only those 2 rounding 
> functions should be used everywhere in the application.
> In the mean time option 1 in Luc's email is my preferred solution. One 
> would need a write-off also when the rounding problem is solved, due to 
> the currency rate changes that will occur.
> 
> ------------------------------------------------------------------------
> Met vriendelijke groet,
> 
> *Veritos - Open Source Business Solutions
> Jan Verlaan CPIM*
> 
> 
-- 
regards
Ferdinand Gassauer
ChriCar Beteiligungs- und Beratungs- GmbH
Official OpenERP Partner