Gregory Stark wrote: I agree to a point. just went through this with our application and had total fits with compound rounding errors as one table stored 4 other stored 6 and 8 and the general ledger table stored 2. when it came time to balance the transactions to the General Ledger Entries we where off thousands of dollars in different accounts as the GL almost always was higher due to rounding and it was wrong to the detail side.justin <justin@xxxxxxxxxxxxxxx> writes:special note do not use only 2 decimal points in the accounting tables. If your application uses 10 decimal places somewhere then every table in the database that has decimals needs to have the same precision. Nothing is more annoying where a transaction says 1.01 and the other side says 1.02 due to rounding.FWIW I think this is wrong. You need to use precisely the number of decimal places that each datum needs. If you use extra it's just as wrong as if you use too few. For example, when you buy gas/petrol at $1.999/gallon and buy 4 gallons you get charged $8.00 not $7.996. If you fail to round at that point you'll find that your totals don't agree with the amount of money in your actual bank account. The entire database uses the same precession as a whole then rounded on the display side. In our Case we make parts that consume .000113 lbs of a metal that sales for 25.76 a pound = 0.002911. When the transaction to remove the value from the inventory account in the Generial ledger table has an entry 0.00 not 0.002911. We just had to big discussion on this thread about rounding and precession which i kicked off. |