8 replies to this topic

[Amy]

Hi. I am working in SL version 5.5 (513). I have an issue that I haven't been able to ignore!

My invoices and reports are displaying amounts with 2 decimals. When I flag the column to add in the control break the total does not always equal the sum of the lines above. I want the column to ignore the numbers after the second decimal (just chop off the rest... not round it). I have fields set up in the file as 2 decimal, but the system defaults to 6 ... what am I missing.... the problem is caused by the rounding of the numbers after the second decimal.

I'd appreciate any help. I have a feeling this is an easy fix...?

Amy

[Mike Peterson]

Before storing the number in the file perhaps you could use the PRECISION(2) command.

PRECISION(2)
Filevariable *= 1

If you wish to keep the actual 6 decimal value in the file but need to display and total 2 decimal places, use the PRECISION(2) to manipulate after reading the file.

[Amy]

Before storing the number in the file perhaps you could use the PRECISION(2) command.

PRECISION(2)
Filevariable *= 1

If you wish to keep the actual 6 decimal value in the file but need to display and total 2 decimal places, use the PRECISION(2) to manipulate after reading the file.

Hi Mike - I looked in code and had put the PRECISION(2) in the logic at beginning of code. From the book it appears I might need to retype it in every logic that I do a calculation (do you know if this is true?). I assumed that because I had the variable set at 9,2 the system would not store numbers after the 2 decimal (wrong assumption, I guess) now with the "invoice amt" stored in file I was hoping to just ignore the other characters - I don't want the number to round up because it won't equal the amout on the invoice that the customer received... I am thinking of writing an update function to read all records and writing them back without the other numbers after second decimal...then when I use the print column total in control break it should work....?

do you set precision in every logic?

thanks, Amy

[Amy]

Hi Amy

By default the precision if to 6 decimal places

Hi Steve. I know the default is to 6 but I didn't realize I needed to write Precision(2) in every logic that calculates. I was putting it once in the beginning of the function. Can you confirm--- do I need to put it in every single logic that I calculate a number (example invoice amt = unit price times lbs...) ? I thought the Precision would stay until another precision statement was made.

thanks, Amy

[Glenn Meyers]

My understanding is that the precision command is only good for that logic.
By definition ProIv will store the number to as many places as the container will allow reguardless of the display code you specify.

[Lewis Mccabe]

I would go ahead and write the update to strip any digits to the right of the second digit now. This way you won't have to mess with this issue in other functions which access this file. Sounds as if the function which creates the records in the 1st place needs some work as well. And yes, PRECISION is only good for the logic you are executing. If you call a global logic, that has to have PRECISION set in it as well.

Lew

[Donald Miller]

Hi Amy

I seem to remember a problem similar to this from way back (and it was Native not SL) but it was totals determined by the use of the flag in reports. It never seemed to give me the results required. Control Breaks and header printing also never quite matched the criteria. And why is there always a blank line under the header before the data?

So years ago a new approach was adopted where all the reporting was done in the fields and manipulation was coded to achieve the requirements (to the letter). It was long ago and I don't rememebr exactly - but totalling is ringing a feint bell. Do it yourself in the code. That way you can be sure if it's something you coded or not.

Good Luck.

Donald

[Richard Bassett]

> just chop off the rest... not round it

Amy, PRECISION rounds just like ROUND so if truncation was important it's nopt what you want. Using it to deal with one data field is also using a sledgehammer on a nut and it affects all arithmetic operations which is frequently not what you want.

I would second Lewis's suggestion to clean up the data and prevent it happening in future if the data is stored wrong.