Solved Round( ) not correct

67philb

New member
Local time
Today, 21:52
Joined
Oct 1, 2024
Messages
6
I am trying to create an invoice using an access report that shows subtotals of grouped products (with a rounded subtotal) which works perfectly, and then I want to sum these grouped rounded figures as a grand total in the report footer.
The problem is when I manually add the subtotal figures it doesn’t match to the grand total, I know it’s due to the rounding’s the grand total is calculating but I can’t figure out how to get around this.
Any help would be much appreciated.
 
Welcome to Access World! We're so happy to have you join us as a member of our community. As the most active Microsoft Access discussion forum on the internet, with posts dating back more than 20 years, we have a wealth of knowledge and experience to share with you.

We're a friendly and helpful community, so don't hesitate to ask any questions you have or share your own experiences with Access. We're here to support you and help you get the most out of this powerful database program.

To get started, we recommend reading the post linked below. It contains important information for all new users of the forum:

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We hope you have a great time participating in the discussion and learning from other Access enthusiasts. We look forward to having you around!
 
sorry, how do I post on the correct page?
 
I would consider rounding in the report’s record source. Then try total the rounded values in the footers.
 
I can’t figure out how to get around this.

1. Don't round.
2. Don't round until the end.
3. Round at the record level in the query the report is based.

You've got 3 levels--1. Record level, 2. Subtotal level, 3. Total level. You can't round the middle independent of the others. Either that total level needs to add up the rounded values of level 2, or you need to round at level 1 and base level 2 and level 3 on those rounded values.
 
Hi Pat, thanks very much for the reply, and moving my thread (sorry).

You are right, normally I wouldn’t have checked the figures on a calculator but knowing it was for a main customer I wanted to make sure all the boxes were ticked.

“Have the grand total total the subtotals” how do I go about this? Because what I thought hasn’t worked, I know it will be something simple I’ve overlooked.
 
normally I wouldn’t have checked the figures on a calculator
I would have always done that.
 
You could try use a running sum on the subgroup totals. I’m not entirely sure this would work and not sure you even want to do it this way since it isn’t going to have the maximum accuracy.
 
You could try use a running sum on the subgroup totals. I’m not entirely sure this would work and not sure you even want to do it this way since it isn’t going to have the maximum accuracy.
never thought of a running sum, that might actually work for what I need. Thank you!!
 
Let's start by understanding that ROUND() has TWO purposes.

First, you round off things because you want to provide an approximation, or perhaps an order of magnitude number to represent the results of a larger data grouping. When used this way, ROUND is a FORMATTING function and you would do better to use the FORMAT( x, template ) method to limit what you show.

Second, you round off because you have fractions that you don't want to keep at ANY level of computation. For example, an interest or tax computation that works on dollars and cents even though the math would produce another couple of digits (fractional dollars x fraction tax rate = even smaller amounts of useless fractions). Here, you run into a couple of issues. First, is there a regulatory limit on what you can track? Second, is the data type you are using a reasonable method for tracking what you track?

If you have regulatory limits, you might have to apply ROUND() after each computation where such action is appropriate. But then there is the matter that DOUBLE data type retains as many fractional digits as will fit, even if those digits lose meaning (or the more proper term, "lose significance.") Sometimes you do better using a CURRENCY data type, which involves a scaled integer that keeps a fixed decimal point (at 4 places) and provides 15 digits to the left of the decimal. This data type takes up the same amount of space as DOUBLE (8 bytes) but is less likely to have a worrisome rounding.
 
Hi all, just wanted to say thank you for your replies. It’s really helped me out, I’m not 100% there, but a lot closer than I had been.

Thanks again Phil
 

Users who are viewing this thread

Back
Top Bottom