SAP System Setup Training Course
Reveals How To Setup A Free SAP Developer System.
Learn SAP & Practice For Certification. Developer Tips Included:

Examples Of Working With Other ABAP Data Types

In this article we will look at some other data types which can be used in ABAP. In previous articles we have seen that numeric fields have been used for performing calculations along with examining character strings and seeing ways these can be used in calculations within ABAP statements too. Now, lets have a look at date and time fields.

Date and Time Fields

Open up your ABAP editor and follow along. Enter the ABAP editor (with transaction SE38) and make a copy of the previous program, alter the comment sections, and remove most of the code:



Date and time fields are not stored as numeric data types, but instead as character data types. Effectively, they are character strings which can be used in calculations. This is made possible by the inbuilt automatic data type conversions which have previously been discussed. Just like any other data type, the DATA statement is used to declare these fields.

For a date field, the data type is referred to with ‘d’, and is limited to 8 characters. The first 4 of these represent the year, the next 2 the month, and the final 2 the day. The VALUE addition is used to specify this, and if it is not used then the value, by default, is assigned as 8 zeros. In the example below, the date is the 1st of January, 2012:


The LIKE statement, of course, can also be used. SY-DATUM is a system variable, which always holds the value of the system’s date. Below, “my_date2” is defined in the same way as this system variable:


Time fields work similarly, but this time are limited to 6 characters. The first 2 refer to the hour, the second 2 the minute, and the final 2 the second. Again, the default value will be 6 zeros. The data type this time is ‘t’. Again, the LIKE statement can be used, here for the system’s time field, referred to with SY-UZEIT:


We can then use the WRITE statement to output the field contents:



Note that in the first row the my_date field has reversed itself to the format DDMMYYYY. In the second, no value was assigned to the field, so the system has output the default zeros. However, as this was defined like the system’s date variable, it has included periods in the formatting. This also applies to the my_time2 field, where colons have appeared between the places where the time values would ordinarily be.

Date Fields in Calculations

Some examples of performing calculations with date and time fields will now be looked at. Using these fields in calculations is common practice within programming business systems, as one will often have to, for example, find the difference between two dates to deliver invoice dates, delivery dates and so on. Here, examples will be looked at so as to find new dates, and find the difference between two dates.

Use the DATA statement to declare a start date for an employee, called “empl_sdate”, and then give this a value of ‘20090515’. Then create another field called “todays_date” and define the value of this as ‘sy-datum’, the system variable, which should then include the date on that particular day:



Next, a calculation will be added, so as to work out this employee’s length of service. Create a new variable named “LOS”, include a DATA statement giving “LOS” a data type ‘i’ and then define LOS as the calculation ‘todays_date – empl_sdate’. Then, add a WRITE statement for this variable, which will include the employee’s length of service in the output. Once this is complete, execute the code:




If one wants to add, for example, 20 days to today’s date, the same value is used for todays_date (the system variable, sy-datum). Create another variable, called “days_count” with an integer value of 20, and another called “fut_date”. This variable’s value should then be defined as ‘todays_date + days_count’, then ad a WRITE statement to output the fut_date. Don’t forget also to add the data types above (‘i’ for days_count and ‘d’ for fut_date). The output should give the date 20 days on from today’s date, which here is the 7th of August, 2012:




Subfields can be used for date fields in exactly the same way as they were used before. In the next example, a date field will be changed to represent the 20th day of the current month. Copy the todays_date variable, then add a new line of code which changes the last two figures of todays_date to the value ‘20’, and a WRITE statement. Also, output the system date so as to compare the two:



In this next example, the last day of the previous month will be established. Use the todays_date variable again, this time using the subfield method above to change this to represent the first day of the current month. Then on a new line of code, subtract one from this, so that the todays_date variable is now the final day of the previous month:



Time Fields in Calculations

Calculations like those above can also be performed with time fields.

In the examples, employees’ clocking in and out times will be used. Use DATA statements to declare the variables “clock_in” and “clock_out” as type ‘t’, along with others seen in the image below, which will be used for calculations to work out the differences between times in seconds, minutes and hours, all of an integer type:


Assign values to clock_in and clock_out of ‘073000’ and ‘160000’ respectively. Then, to work out the difference between the two in seconds, use the calculation ‘clock_out – clock_in’ and assign this value to “seconds_diff”. Then include some WRITE statements to output this information:



To establish the difference in minutes, simply use the seconds_diff value, and divide this by 60, and then to establish the hour’s difference, follow this by dividing minutes_diff by 60:



Note that here, the 510 minutes do not, in fact, equal 9 hours exactly, the system has rounded the number. This is because the hours_diff variable was declared as an integer. If the data type for this is changed to a packed decimal, the value would have been established as the more accurate 8.5 hours:



Quantity and Currency Fields in Calculations

Now, a look will be taken at using quantity and currency fields in calculations. In ABAP, these are treated the same as packed number fields. Currency fields must be declared as data type ‘p’, bearing in mind how many decimal places are required. This is important, as having the right number of decimal places can have a large impact on the accuracy of calculations.

Quite often in a program, one wants to create one’s own variables for quantity and currency fields. It is usually better, however, to associate these fields with the data types of those in a table created in the ABAP dictionary. This is because the ABAP dictionary will already have defined the correct field length and number of decimal places for these. For example, the Salary field in the table created previously had defined two decimal places. If a currency field in a program is declared to match this field but the data type in the program is set manually to 2 decimal places and the number of decimal places in the table was to change, the program would no longer operate properly here. For this reason, it is usually preferable to use the LIKE statement for these fields.

In this example a new variable named “my_salary” has been declared using the LIKE statement:


Because this field in the program is linked to the field in the table, the system will ensure these data types are kept in sync. There are two aspects to this process, the number of decimal places, and the associated currency (or quantity) keys. If you look at the CURR data type in the ABAP dictionary, you will see that this is stored as a decimal – 9 characters and 2 decimal places. You can also see that its internal format is ABAP type p, packed decimal:




Additionally, don’t forget that the salary field and its currency data type always refer to the currency key field, in the table called ECURRENCY. Ultimately, then, when one is declaring fields in ABAP, it is important to reference these to the associated fields in a table, and when working with currencies, the currency key field will always be there and should be taken into account. The same applies to quantity fields. The only difference is their data type is QUAN, and rather than a currency key, will always have a UNIT associated with them.

Now, using calculations from the currency field, an employee’s tax and net pay amounts will be established, so declare two more DATA statements for these fields, again referencing the salary field in the table. Also add a tax percentage variable, of type p with 2 decimals:


Add a TABLES statement so that the program knows to refer to the ZEMPLOYEES2 table, then observe the calculations in the code below:



First, the tax percentage is established. This is in this example 20%, so for the means of the calculations is written as 0.20. Then the code will select records from the ZEMPLOYEES2 table, and write the surnames, salaries and currencies for these. Next, the tax amount is established, by multiplying the tax percentage by the salary. Net pay is equal to the salary, minus the tax amount. Then add a WRITE statement to output the results the end of the SELECT loop. The output should look like this (where salaries and currencies are not present in the table, go back and edit the records in your table to put some values):


The surname, salary and currency for each record are written on the first line, followed by the tax amount and net pay on the following line. To make this look tidier, descriptive text can be added to the WRITE statements in the code:



About the Author:

Pete has been working with SAP technologies for over 10 years. He started out as an ABAP consultant and then moved on to BW where he has worked many different clients covering a wide variety of industries. "I love introducing SAP technology (especially BI) to new clients and showing them how they can go from zero to hero within their business in super fast time". Contact me on twitter @PeterMoxon