Skip to Content
Technical Articles

Of the Quirky and Old – strange and funny ABAP constructs explained 1 – The Fixed Point Arithmetic heritage

Why I started writing a blog

After having explained to one of my younger colleagues why his calculations in a custom condition routine (function group V61A, to be precise) were always a factor 1000 to large, another colleague (thanks René van Mil) of mine came up with the idea to write a series of blogs about old, strange, funny or otherwise quirky ABAP-stuff that most ABAP-programmers will encounter sooner or later. In his opinion, I am the right person for this job, having worked as an ABAP-per since 1989.

So here’s part one (and my first ever blog) about the heritage of ‘fixed point arithmetic’, or rather ‘non-Fixed Point Arithmetic’ code in our current SAP systems. I have some ideas about other subjects, but I’m open to any other idea. Just let me know in your comments.

Calculations in ye olde ABAP days


I started as an ABAP programmer in 1989 with version R/2, 4.2e.  For the first 5 years of my ABAP career, this was the user interface I had to work with.

SAP UI look and feel r2.png

The ABAP language was still in its infancy, with a limited number of statements. For example, the only type of procedure was the subroutine (FORM). Function Modules didn’t exist yet, so the reuse of ABAP code was restricted to the use of external subroutine calls.

Another characteristic of this old ABAP version was that the option ‘ Fixed Point Arithmetic’ was not available yet as an ABAP attribute.  The built-in data type ‘Packed’ already existed. However, multiplying or dividing packed fields with decimals was a little bit cumbersome, because the decimal positions were not taken into account during calculations.

Multiplying and dividing with decimals in a non-Fixed Point Arithmetic ABAP

Just consider the following example that you can still check in your current SAP-system:

DATA: a_packed_field              TYPE P DECIMALS 2 VALUE ‘100.00’,

      another_packed_field        TYPE P DECIMALS 2 VALUE ‘200.00’,

      the_result_field            TYPE P DECIMALS 2.

the_result_field = a_packed_field * another_packed_field.

You would expect the_result_field to contain the value ‘20000.00’. However, without Fixed Point Arithmetic, multiplying both fields results in the value ‘2000000.00’, which is a factor 100 too large.  This is caused by the fact that for the multiplication, the decimal places are actually ignored: the calculation that is executed is:100000 * 20000 = 200000000. 

To solve this problem, dividing the result by the correct number of decimals had to be added to the statement. This is why all calculations with amounts, quantities and other packed fields with decimals looked like this:

the_result_field = a_packed_field * another_packed_field / 100.

When dividing, the reverse problem would occur and the result of the calculation would be a factor 100 too small.

the_result_field = a_packed_field / another_packed_field.

In the division above,the_result_field contains the value ‘0.01’ instead of the expected 0,50. Actually, the result is ‘0.005’, but this is rounded by the system because the_result_field is defined with 2 decimals.

A correct calculation would be:

the_result_field = a_packed_field * 100 / another_packed_field.

It is not hard to imagine that, when calculations got a bit complex, forgetting to multiply or divide by the correct number of decimal places could lead to very large or very small incorrect numbers. Just consider calculations containing both multiplications and divisions using different numbers of decimal positions, where the result field was defined with yet another number of decimals.

The introduction of the fixed point arithmetic option

Fixed Point Arithmetic.png

I’m not really sure in which R/2 version the ABAP-attribute ‘Fixed Point Arithmetic’ was introduced. As a result, the programming of calculations in new programs got a lot easier. Making the existing programs ‘Fixed Point’-proof was not a very complex task, but a bit boring because it involved checking every calculation and delete the ‘ * 1000’  or ‘/ 1000’  part of it. A lot of companies were understandably not eager to start an ABAP-conversion project, because of a business case was lacking. That’s why it was often decided that an ABAP-conversion could wait until it could be combined with a functional change.

Standard SAP programs were also not changed directly or not at all. And even today, in ECC6.0, Enhancement Pack 6, there are still several much used SAP programs for which the Fixed Point Arithmetic attribute hasn’t been set.

ECC6.0 examples of non-Fixed Point Arithmetic programs

In our ECC6.0 system, there are still 5569 reports, module pools and function groups for which the ‘Fixed Point Arithmetic’ attribute has not been set. There are some programs that you may already have encountered or that you are likely to encounter if you are an ABAP-programmer working on an ECC-system.

Two typical examples of SAP-programs that you might run into are:

  1. RVADOR01 – Print Program for Sales Documents. This program is often copied to a Z-version (why copying SAP standard is a bad practice deserves a discussion of its own!) and then adapted. It is still being used to print SAPscript, SMARTform or ADOBE forms.
  2. Function group ‘V61A’- ‘Functions for Pricing’. This function group contains several types of user-exits and enhancements, and user routines for custom conditions, typically called ‘RV61A9..’.

If you change, enhance or otherwise re-use these ABAP-sources, you have to take into account that the attribute ‘Fixed Point Arithmetic’ is not set. Your calculations must be programmed accordingly. An option to overcome this is to delegate the calculations to new custom classes or functions.


You now know that, if the results of multiplications or divisions in a new or changed program are too large or too small by a factor 100 or 1000 or even more, first check the attributes of this program. Maybe it is suffering from ‘Non-Fixed Point Arithmetic’s.


You must be Logged on to comment or reply to a post.
  • Ben,

    now the screen dates you 😉

    My question is how about overflows/underflows? Are the length of the data types just over sized to avoid problems?


    • Hi Albrecht,

      If I say that I started my ABAP career when I was 5 years old, you probably won't believe me 😉 .

      I don't think the length of the data types are oversized. Sometimes, numbers just get so big you have to use large variables. And in most cases, you can define the length you want for your P, C,N and X field types.



  • Hi Ben,

    Thanks for making us understand the history and reason for Fixed point Arithmetic attribute. It clears lot of confusions and obviously helps in not committing mistakes 🙂 .

    Can we expect lot of such blogs from SAP stalwars like you. I am very much interested.

    Thank you very much.



    • Hi Alok,

      Thanks. I'm pretty sure I will come up with more blogs, but I can't promise a timetable for that. 

  • Hello Ben,

    Thanks for blog. Special thanks for a screenshot for R/2 login screen. That's simply like Mainframes.

    I did start working on SAP with release R/3 3.0F. The user interface was so not user friendly. I still remember the ABAP editor where you press enter and it would make a trip to application server, so you still need to wait.

    Regarding the Fixed Point arithmetic, the reason Pricing still doesn't have Fixed Point arithmetic set is because of the Currency. You would have different currency with different monetary units - Like Japanese Yen doesn't have "cents" (no two decimals), USD has two decimals, USDN has 4 decimals. So, instead of adding conditions everywhere to divide the value with 100 or 1000 or 1, the values are calculated plain. Just before displaying the values they are converted to specific currency format. They are still saved in the DB with 2 decimals but always with associated currency, which makes sure values are converted back properly in document processing.


    Naimesh Patel

    • Regarding the Fixed Point arithmetic, the reason Pricing still doesn't have Fixed Point arithmetic set is because of the Currency.

      Somehow i don't quite appreciate this reasoning. I have worked with FI developments (dealing with multiple currencies often) but have not faced the problem with currency i.e., multiply/divide the value with the currency decimal factor 🙁

      Of course you have to maintain the correct amount-currency linkage for that 😛



  • Hello Ben,

    Thanks for the screenshot. I had heard that the R/2 screens were mainframe-like, but never seen one 😛

    Tbh i have never faced the "fixed-point arithmetic" problem ever & didn't even bother about setting/removing the flag in the object attributes.

    Looking forward to your next "quirky" blog 😉



  • Hi Ben,

    Great to see an old ABAP road warrior picking up blogging and sharing his wisdom (accumulated over the years) with the younger generations. OK, that'll do for referring to your many years of experience 😉 .

    Very nice blog. Not a topic I've ever delved into, and as such it provides valuable information. I'm looking forward to the next gem!

    Cheers, Fred

  • Hello Ben,

    Thanks for the wonderful insight !.I wonder are there any customers , somewhere in some remote corner or nearby too, still using R/2.

    Your blog reminds me of an experience, where i had assumed 'DIV' and '/' to be the same and had a tough time in a FI AP project. 🙁



  • Hi Ben,

    Thanks for this nice blog.
    The the fixed point arithmetic attribute is by default set to false when you create an assistance class for web dynpro with forward navigation from the web dynpro component. This can lead to the problems that you have described in your blog.

    Best regards,

    Robin Vleeschhouwer