[adToAppearHere]

A teaser to begin..

*What would be the output of this write statement.*

1 2 3 4 5 6 |
DATA: v_kwert_n TYPE kwert. v_kwert_n = '1.234'. WRITE:/ 'From Program: ', v_kwert_n. |

Did you think it would be ‘1.234’? Or if you were infront of the system and you happened to look at the data element KWERT and it has 2 decimal. So you thought it would be ‘1.23’.

Let me show what my output was.

*Oopss!!! This is not what you expected. Right?*

Now, you would try to challenge this output by actually, writing the above lines of code in your system. What!!! You get a different output. 🙂

Your output for the same code.

*So, why is it different in yours and mine?* Let me introduce you to the topic of the day, ‘**Fixed Point Arithmetic**‘ (FPA). My program had the Fixed Point Arithmetic (menu->go to->attribute) unchecked. Yours’ must have been checked by default.

**According to SAP, Fixed point arithmetic:**

*If you mark this checkbox, all calculations in the program will use fixed point arithmetic.*

*If you do NOT select this check box, packed numbers (ABAP/4 type P, Dictionary types CURR, DEC or QUAN) will be treated as integers when they are used in assignments, comparisons, and calculations, irrespective of the number of decimal places defined. Intermediate results in arithmetic calculations will also be rounded to the next whole number. The number of decimal places defined is only taken into account when you output the answer using the WRITE statement.*

As a program attribute, the fixed point arithmetics determines whether for numbers of * type p the decimal point is respected by operations or not*.

Now, let us see the behaviour of the below code.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
* In calling Program DATA: v_kwert TYPE kwert, v_kwert_n TYPE kwert. v_kwert_n = ( 1000 * '1.234' ) / 1000. * Calling FM to multiply the same number with 1000 and divide by 1000 CALL FUNCTION 'Z_SAPYARD' IMPORTING xkwert = v_kwert. WRITE:/ 'From Program: ', 20 v_kwert_n. WRITE:/ 'From FM: ', 20 v_kwert. |

1 2 3 4 5 6 7 |
* In FM Z_SAPYARD. FUNCTION z_sapyard. xkwert = ( 1000 * '1.234' ) / 1000. ENDFUNCTION. |

Check, the mathematical expression is exact in the calling program and called FM. But the output is different, because the Program has Fixed Point Arithmetic unchecked while the FM has it checked.

Play around by switching the FPA on and off alternatively in program and FM and see the output.

**SAP strongly recommend not switching off the fixed point arithmetic in any program.**

**Real Project Scenario:** *Check the practical problem, where the user has issue in calculation in VOFM routine where the standard SAP program SAPLV61A does NOT have Fixed Point Arithmetic checked.*

http://scn.sap.com/message/16063743#16063743

In such cases, we should call a custom FM with Fixed Point Arithimetic checked and do the calculation in the FM and pass the final value to the main program (VOFM).

With the above * gyan (sanskrit word for knowledge)*, let us see if we could determine the correct output of the below code (taken from SAP Help documentation)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
CLASS cl_test DEFINITION. PUBLIC SECTION. CLASS-METHODS meth RETURNING value(p) TYPE string. ENDCLASS. CLASS cl_test IMPLEMENTATION. METHOD meth. p = '1000'. ENDMETHOD. ENDCLASS. * Calling in program START-OF-SELECTION. DATA v_pack TYPE p DECIMALS 2. v_pack = cl_test=>meth( ). write:/ v_pack. |

**Today’s Food for thought.**

i) What would be the output value of variable v_pack if the Fixed Point Arithmetic is checked?

ii) What would be the output value of variable v_pack if the Fixed Point Arithmetic is NOT checked?

*If you want to get notification about the newest posts, please subscribe. Your email is safe with us.*

*If you liked it, please share it! Thanks!*

Image source: via Free Stock Photos foter.com

Interesting and very useful too. We generally face the issue for VOFM routine.

Thanks for sharing the background depth.

Thanks Partha for leaving your comment. I remember dividing the final value by 10 to get the result without knowing why we were doing.. With this post, hopefully some of us know why we do it.. 🙂

Regards,

Raju.

Great share Raju. Now I know why we used to divide by 10 or 100 whenever required. 🙂

you have become SAP guru now..keep sharing..take care.

Thanks Arnab for your comment..

No guru.. 🙂 .. Just trying to share small things which I believe other would also benefit..

Raju..

Ans1: 1000

Ans2: 10.00

Good to know that

But I wonder what is the use of unchecking FPA

Nice post about the point which most of the ABAPers were not aware of. We should Thank You for the clear explanation of the topic. 🙂

Dear Naveen – Thank you so much for taking time to go through the post.. Appreciate your comment.

Please keep visiting for such small ABAP tweaks and tips..

Regards,

SAPYard

Thank YOU very very much, I’ve aways wondered what’s up with all the multiplying and dividing by 100, 1000 or even 100000 in the many VOFM formulas that I’ve encountered in various clients. Finally I have a correct way to approach this calculations.

You are welcome Jayme.. Happy that you found answer to the mystery.. 🙂

Regards,

Raju.

Hi Raju,

Thank you very much for sharing this vital information. I was also one of those who was in the dark regarding this issue.

Best wishes,

Siddhartha

You are welcome Sid.. Glad that you liked it.

You are not alone, I am also one of them who learnt it late why we multiplied and divide by some numbers. 🙂

Regards,

Raju