GroupFooter Sum Precision Problem
Polomint
Australia
In a Share Portfolio Report for a client, we have encountered a strange problem which we solved by doing calculations in Delphi "GroupFooterBeforePrint" code**.
But I would like to know why this happens, and how we can avoid it in future [img]style_emoticons/<#EMO_DIR#>/cool.gif" style="vertical-align:middle" emoid="B)" border="0" alt="cool.gif" /> In the attached cut-down report we have: - a[/img]DetailBand which is a TfrxMasterData containing ShareValuePrice, ShareValuesGrossAmount and ShareValuesSumOfCount
- a GroupFooter which is a TfrxGroupFooter containing GroupSumPrice
The fields below are all TfrxMemoView:
- ShareValuePrice gets its data from [ShareValues."Price"]
- ShareValuesGrossAmount gets its data from [ShareValues."Gross Amount"]
- ShareValuesSumOfCount gets its data from [ShareValues."SumOfCount"]
- GroupSumPrice gets its data from [Sum(<ShareValues."Gross Amount">)/Sum(<ShareValues."SumOfCount">)]
The DataSet "ShareValues" is a Query which rolls up trades over a period and groups data into Company and Class of Share values. The GroupFooter should present a summing by Company of all the Class of Share amounts. The prices are "notional" since the "absolute" values are the Gross Amount spent to acquire the Shares, and the Number of Shares held, and therefore not required to be rounded to currency precision.
Regardless of what we do (currently setting DisplayFormat.FormatStr="%6.6n" DisplayFormat.Kind="fkNumeric" for example), the result for the Calculated Price is always rounded to four decimal places, as if it had been processed by FormatCurr. Note that the source data (from the summing in the Query) in the test example is shown at the expected precision (being the result of dividing $54,541.15 by 2,628). It is the Sum in FastReports that seems to cause the issue. I've zeroed the other data items to simplify the data.
I have only recently upgraded our licence from Standard to Professional, so have not had the Source Code long enough to be completely au fait with it. A cursory examination of frxClass.pas showed me nothing that indicated why this was happening, but perhaps I am looking in the wrong place.
Any suggestions?
But I would like to know why this happens, and how we can avoid it in future [img]style_emoticons/<#EMO_DIR#>/cool.gif" style="vertical-align:middle" emoid="B)" border="0" alt="cool.gif" /> In the attached cut-down report we have: - a[/img]DetailBand which is a TfrxMasterData containing ShareValuePrice, ShareValuesGrossAmount and ShareValuesSumOfCount
- a GroupFooter which is a TfrxGroupFooter containing GroupSumPrice
The fields below are all TfrxMemoView:
- ShareValuePrice gets its data from [ShareValues."Price"]
- ShareValuesGrossAmount gets its data from [ShareValues."Gross Amount"]
- ShareValuesSumOfCount gets its data from [ShareValues."SumOfCount"]
- GroupSumPrice gets its data from [Sum(<ShareValues."Gross Amount">)/Sum(<ShareValues."SumOfCount">)]
The DataSet "ShareValues" is a Query which rolls up trades over a period and groups data into Company and Class of Share values. The GroupFooter should present a summing by Company of all the Class of Share amounts. The prices are "notional" since the "absolute" values are the Gross Amount spent to acquire the Shares, and the Number of Shares held, and therefore not required to be rounded to currency precision.
Regardless of what we do (currently setting DisplayFormat.FormatStr="%6.6n" DisplayFormat.Kind="fkNumeric" for example), the result for the Calculated Price is always rounded to four decimal places, as if it had been processed by FormatCurr. Note that the source data (from the summing in the Query) in the test example is shown at the expected precision (being the result of dividing $54,541.15 by 2,628). It is the Sum in FastReports that seems to cause the issue. I've zeroed the other data items to simplify the data.
I have only recently upgraded our licence from Standard to Professional, so have not had the Source Code long enough to be completely au fait with it. A cursory examination of frxClass.pas showed me nothing that indicated why this was happening, but perhaps I am looking in the wrong place.
Any suggestions?
Comments
Sadly, the result is the same, i.e. the value calculated within FastReport is still being rounded to four decimal places.
Done. Results of original report reproduced:
- With BCDtoCurrency = FALSE and also = TRUE
- Within the IDE (i.e. before compilation) and also the executable file
This worked in the test program. All calculated "Prices" are to the expected level of precision.