Amount Rounding Issue

I am testing the rounding in Sales Amount (with discount) from 3 decimal places to 2 decimal places. In the GL set-up. amount rounding decimal has been set to 0.01. For an amount of say, 29.5 with a discount of 43% (12.685), system tends to round up the discounted amount first, before the line total. This will result in a decimal difference between 16.81 and 16.82. As a implementor, I would tend to use 16.82 as the correct amount. Is the calculation logic correct in this case??

The simplest logic to follow is that of the program, explain to the customer it rounds the individual amount of the discount first and then works out the amount. If you took your calculation logic (whilst arguably correct) on a step, the price for one is 16.82, therefore the price for two is simply twice that, 33.64, However the 43% discount on 59 is 25.37, giving you an amount of 33.63! Rounding can be a pain, but if you explain how the program works the customer will either be happy with it or ask you to change it, so as an Implementor I suggest you adopt the logic of the program, it will probably save confusion later! Steven Weaver XONITEK Systems (UK) Ltd +44 (0) 23 80641175 (Tel) +44 (0) 23 80641173 (Fax)

quote:


explain to the customer it rounds the individual amount of the discount first and then works out the amount.


There is one strict rule in software-engineering: Never use rounded amounts for calculations! Always use correct amounts and only round the final result or round the amounts you display/print Internally the price in the first example is 16.815. As you mentioned, rounding can be to the advantage or disadvantage of the customer. If you use the internal (correct) amounts for your calculations you end up with the fairest possible result at the final total: Imagine the following invoice: 29.5 → 43% → 16.815 (16.82 printed) 29.5 → 43% → 16.815 (16.82 printed) 29.5 → 43% → 16.815 (16.82 printed) 29.5 → 43% → 16.815 (16.82 printed) 29.5 → 43% → 16.815 (16.82 printed) Total is 529.5 = 147.5 Correct Amount is 516.815 = 84.075 which is equal to 147.5 minus 43% Wrong would be to calculate a total of 5*16.82= 84.1 — Second important rule (the famous “fabian’s law of overhead programming”) states: No idea, what the value of 0.005 Singapore currency unit (dollars?) is. But compare it with the salary of the developer who would have to implement a special rounding routine: “Hey, are these couple of cents worth the effort” ------- With best regards from Switzerland Marcus Fabian Edited by - fabian on 2001 Apr 24 02:47:42

I agree with Marcus, that the developers’ cost of developing the rounding would definitely be higher than the few cents. However,the scenario shown by Marcus of 5 individual lines of the same item would be uncommon unless it is a ‘blanket order’. If the rounding is done on the total amount of that item, we would arrive at the same result if the trounding was done on the total net amount, per line. I guess in these circumstances, we can only advise our consultants/ end-users and change it if desired. How is it practised in Europe, and is the usual feedback with customers over there??

quote:


However,the scenario shown by Marcus of 5 individual lines of the same item would be uncommon unless it is a ‘blanket order’.


I didn’t take the time to create a “realistic” example with different values. Fact is (as the example shows) that each line has a rounding difference of 0.005 which always adds to the same direction giving finally a difference of 0.025 after 5 lines.

quote:


If the rounding is done on the total amount of that item, we would arrive at the same result if the trounding was done on the total net amount, per line.


This is definitely wrong! as I have just prooved! Each rounded line carries forward a rounding error which might sum up to one ore the other direction. This might lead to a couple of dollars difference if you have large orders with some hundred lines.

quote:


How is it practised in Europe, and is the usual feedback with customers over there??


It is accepted that the program always calculates correct results with correct numbers. Users are aware (and accept) that the amounts displaied/printed are rounded ones (for readability) while the program calculates with correct amounts. In other words: If a user would add all the discount-amounts in an invoice he would not end up with the total-discount shown in the food of the report. Once he understood the reason he accepts that fact. ------- With best regards from Switzerland Marcus Fabian

Fabian

quote:


It is accepted that the program always calculates correct results with correct numbers. Users are aware (and accept) that the amounts displaied/printed are rounded ones (for readability) while the program calculates with correct amounts.


I agree with your statement, sorry for the incorrect implementors assumption, and thank you for the correction Steve

We are having a terrible time with rounding concerning Sales Tax. I am constantly entering adjustments for .01 to .05 via the General Journal. I was told that the 2.0 version would correct this yet I currently have 2.6 and it still has a rounding problem concering Sales Tax. Can someone please explain to me how the sales tax works! I have to go through 8-10 pages of open entries every day to clear up these pennies. This is very annoying and time consuming can’t they make it work properly??? Thank you, Kathy Bunk Edited by - bunkkathy on 2001 May 15 16:02:59