Strange Variable Rounding in RV

[clmates]

Hi to all.

I'm having a confusing behaviour of a custom report and I want to know if you have faced a similar "error"

The problem is that I have several custom sections for displaying purposes only (conditional ones), with global RV variables defined over DD items AA and UNCS

in concrete RV_Importe_AA and RV_Coste_UNCS

both variables have changed the display settings to 12 digits, 4 decimals and K formatting type

the estrange is that I assign a value of 0,0056 to RV_Importe_AA variable in a section then call the displaying section and it is sowing fine with all 4 decimal like ,0056

I aso assign the same value to the other RV_Coste_UNCS and then call his displaying section and it is showing like ,01

more annoying is that If I debug step by step in both cases I see the right value assigned = 0,0056 but right after the displaying section ends, the RV is changed to ,01 (I see his value in the calling section)

have you ever faced this?

I have tested also to use both AA types and one is working fine and the other no, and also don't use global RV use global ER instead and assign in the do event of the displaying section, but with the same results.

and as a last note, if I assign the value to a string RV then is showing right with no rounding, Is like the variable is rounding to 2 decimals just before displaying


Thanks to all

 

[clmates]

Hi.

A bit more information.

I have one difference.

the section that is working fine is being called from a level break header (section one)

the section that is rounding the value is being called from a level break footer. (section two)

I have made a test and called the same section one also from the level break footer, and also makes rounding, so the problem seems related to the fact of being called from a level break footer

and also the opposite, If I call both sections from a level break header, it is not rounding

so I think I have to replace my level break footer display variables to all text ones :-(

anyone knows if this is solved in current versions?

Greetings

 

[Zoltan_Gyimesi]

Hi Carlos,

After first read of your issue - it is a Currency Trigger related one.
It can be a bit complicate - inheriting Currency Decimal settings after arithmetic assignments.

We need more information - where come the source values come from (BC, Fetch, etc.)
How you compose output RVs (assignement, division, etc.)

Excuse me, I did not dig more deeper in your issue (it is late, and I am a bit tired after a hard day.)

Waiting for more info & Regards,

Zoltán

 

[JdeInNJ]

I agree with Zoltan. It is most likely related to currency decimals. There is a business function, I believe it is called something like SetCurrencyDecimals, that is supposed to help with this problem, however, I have not had much luck with it.

 

[clmates]

Hi.

I will try to build a small report that reproduce that error and attach event rules here


I have tried :

A)to assign directly from event Event Rule variables to global RV variables, in the do section of the calling section

B) to assign directly from global Event Rules variables to local RV variables, in the do section of the called section

I think that currency has nothing to do because this same section and RV works fine if called from a level break header section instead of being called from a level break footer.

but as said above, I will put here a small example later.

thanks to all

 

[clmates]

Hi Zoltan, Brad.

Wow, seems that you could be in the right direction.

Is a strange thing.

my report fetch from F43121 the Amount Paid to date APTD and Quantity Paid to Date UPTD in report level variables, then assign this report level variables to another report level variables AA for the amount and QTY fro the quantity

and at last he assigns the round((Quantity/Amount),4) to the AA global RV variable.

If I make a direct assignment like RV_cost_AA = 27/5000 or RV_Cost_AA = round(27/5000,4) it is working fine

I'm reporting now to Oracle to see why this happens and how to avoid this

If any of you have any idea I will be glad to try it.

Many Thanks

 

[clmates]

Last update.

the problem happens whenever I assign fetched values to an RV regardless of the variable DD used. ie:

I created two UNCS (4 decimals precision) variables Paid_UNCS and Quantity_UNCS

I fetched APTD and UPTD from F43121 in these two UNCS variables and then

assigned RV_Cost_UNCS = round(([VA rpt_Paid_UNCS]/[VA rpt_Quantity_UNCS]),4)

and this is what happens:

if you debug step by step, after the assignment the RV_Cost_UNCS has the value with 4 decimals

I call the custom section who prints the value

In the do section of this custom section the RV_Cost_UNCS has the value with 4 decimals

In the after last object printed of this custom section the RV_Cost_UNCS has the value with 2 decimals!!!!

so is in the printing where it is losing the precision and rounding the value

also note that I'm using a RV with DD UNCS 4 decimals precision so it is a very strange behaviour

I have reported this to Oracle under SR 3-3442359651:

I will put here the results

 

[clmates]

Strange Variable Rounding in RV - Currency Environment

Hi.

Problem detected and reported to Oracle

The error is that Oracle is rounding any kind of variable to currency rounding if this variable get value from any "currency type" field with table IO

this is a bit weird as you can be calculating any non currency value like rotation of stocks or any other value but if you used any currency data in the calculation and then deposit the final calculated value in a RV variable this one will get rounded to currency decimals despite of his DD type

ie:

you cold read amount paid in a voucher (with table IO) and then make a calculus of Stock / amount paid

then use this value and apply any kind of operation and deposit the final result in a UNCS variable (4 decimals) ant this will get rounded to currency decimals because you used a currency data as one of the originating values!!!!!

I don't know how they track this but is that what is happening

If you make the same calculations but in the data there is no currency type field the final UNCS variable get it 4 decimals in place ....

So be cautious.

I'm claiming that they should make the rounding based on the DD of the final variable if is a currency one or not

 

[Zoltan_Gyimesi]

Hi Carlos,

I have read today your thread again - tell the, not so focusing for all detail, but please, consider or try the following:

For division use us B000190 Math Divide Controlled BSFN instead Experrison Manager in an assignment. The use of the BSFN is easy to figure out.

As I wrote, inheriting Currency decimal settings via arithmetic operation is mostly useful, but sometimes cause problems - mostly on divisioon. For exampla AA had been fetched from a table, on witch has Currency Trigger - let say wit 2 decimals (EUR, USD) or without decimals, as on our HUF (Hungarian Forint).
You fetch or compose a QTY and you need an UNCS or UPRC as:
UNCS = AA / QTY
In this case UNCS will inherit the currency decimals from AA (2 or none as I mentioned for USD, EUR or our HUF) - instead 4 decimals of UNCS/UPRC.

The mentioned BSFN can deal with problem. If you have problem to use this BSFN, then let us know - but fiorst make a try and let us know your result.

Waiting for your update and Regards,

Zoltán

 

[clmates]

Hi Zoltan.

Thanks for the info, I will try this also

This also can be solved by using B0000164 - Currency Decimals Set, just on the end of the Do Section.

But the point is that how they apply this concept is not logical, the rounding should be done based on the kind of the variable (being or not being a currency one) if the developer wants currency rounding he should use a currency variable, if not, he should use a not currency one.

Sometimes I wonder who takes this kind of decisions .....

Thanks again for the info I will add this to the list of my "need to known functions"

Best Regards

 

[Zoltan_Gyimesi]

Hi Carlos,

Thanks for your reply.

[ QUOTE ]
This also can be solved by using B0000164 - Currency Decimals Set, just on the end of the Do Section.

[/ QUOTE ]

As far as I can remember, this didn't solve my problem in the past - but I can not remember for the details.

[ QUOTE ]
if the developer wants currency rounding he should use a currency variable, if not, he should use a not currency one.

[/ QUOTE ]

CURRENCY is just a Class in Data Dictionary, which dictates, to be identical in more attributes (data type, length, decimals, etc.).

Just using Currency Variable is not enough info, for rounding - it requires the Currency Code and its Decimals (I just not remember in wich table is it declared).

Not currency DD items also inherits currency decimals after an assignment (simple or expression), like UNCS with 4 decimals get 2 decimals after

UNCS = AA / QTY

If AA is alredady Table Triggered on Fetch or by ER BSFN or by also derived value on Currency variable, so it will have 2 - in our case 0 decimals.

Inheriting Currency behaviour in arihmetic operation is not too bad. Without this, we can have much more problems.

By the way, Currency or not - Display Decimals, etc. - I suspect, that the precision of the variable in arithmetic is not the same as the display precision and this can make problems mainly on totals. Tell the truth, I have never made deeper test on it, but sometimes I suppose, it caused problem for us.

My practice generally in ER retrieve the decimals by a BSFN call, round the right-hand values for this decimals, before use it in arithmetic.

Maybe somebodíy other will have other addition to this issue.

Regards,

Zoltán