Ivanildo Buarque wrote:load id , start Date , min ( End date ) , sum ( Amount ) from table
You mean this?
[Charges]: LOAD "Tenant" ,"Start Date" ,min("End Date") as "End Date" ,sum("Amount") as "Amount" RESIDENT [Raw Data] GROUP BY "Tenant" ,"Start Date" ;
That doesn't work because some of the service and miscellaneous charges are supposed to apply to more than one base rental period. This approach only applies them to the first base rental period.
According to QlikView's documentation, you should get 12345.56, but the documentation doesn't always match reality due to the limitations of binary floating point for representing decimal numbers.
One possible explanation (for which I have almost no evidence) would be if QlikView uses more than one numeric format internally. My understanding was that it was using IEEE double precision binary floating point for all numbers, but Rob Wunderlich's memory usage analysis indicated that shorter numbers took less memory, perhaps indicating a second numeric format. Perhaps the second format is IEEE single precision binary floating point. That allows for 24 binary digits, which in general can only store seven decimal digits, but your eight-digit number can technically squeeze in since it is small. So my theory is that when you use 12345.555 individually in a table or text box, it gets represented with single-precision, but when you combine it in a table with 211.3213123, that has enough digits to require double-precision for the column, resulting internally in a slightly-different approximation, one which rounds up instead of down.
It should be easy to gather some evidence for or against this theory. I need to leave this open in a tab and do that later today.
Edit: Well, that theory's already out the window. I see that you put them in separate columns instead of rows, which should give QlikView the ability to use different formats for each number. I'll need to think of another theory.
