Hello All, Finally after two days of digging i have found the good, bad and the ugly answers that solves my rounding problem.
Good: Its not a rounding issue. (Not that i am ready to believe float is a solution. We need Decimals !!) Bad: The source of the problem is scarier. The production system had an account move with one draft line and a valid line. (The move as a whole was not validated if that is any useful info. I have no idea how this could happen. If i can recreate the situation i shall update the list/file a bug again.) Ugly: There are innumerous design issues in accounts which could cause more dangerous issues. This inference is from my attempts to recreate the same problem i faced in different ways and of course i did succeed. The most notable is the use of active field: The implicit discard of inactive rows could lead to a situation where the account may not get displayed in the chart of accounts despite having a balance. Same could happen to parent rows as well. It will hide all child rows in COA, if its active=False This is one issue that can be easily fixed. Thanks for the concern and time. Sharoon On 17 Aug 2010, at 15:23, P. Christeas wrote: > On Monday 16 August 2010, Raphaël Valyi wrote: >> Hello, >> >> we while ago we debated here the usage of Floats vs Decimals in Python. >> ... > > When talking money, decimals (+ numeric, in SQL) are supposed to yield better > precision at calculations, than floats[1]. > > However, I feel that this is not our problem. IMHO the error is not at the > choice of arithmetic /storage/, but at the interface of data to and from the > db. > Every time we fetch sth from the db, or store something in it, we may lose a > little bit of information, here, some decimal digits. We spend resources to > do > that, too. > > So, my counter-proposal is that we let the database do more, instead of > writting those loops in Python (or Java, or Python over Java, or Java over > Ruby over Python over Java etc.). Let SQL do what it is good at: Sums. > > I do appreciate that some developers are allergic at SQL and would write > anything else instead. But here, Python with its metaprogramming would allow > us to write some intelligent framework to abstract over some complex SQL > query > building. Let us try to go to that direction[2]. > > This means it will definitely be a post-v6.0 thing. > > > [1] which, may even be a myth, because floats /do/ have the necessary > precision > to always round up to the correct value. > [2] see line 37 at: > http://git.hellug.gr/?p=xrg/a2blib;a=blob;f=a2blib/Form/Class.SumMultiView.inc.php;h=4a0d9b562958c8739a2735c > > > -- > Say NO to spam and viruses. Stop using Microsoft Windows! > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
