How To Install Your Own SAP Trial System – Free Course

It’s been a busy time over the Christmas period. Wrapping up projects, buying gifts for my kids and even cramming in a few study sessions to learn new skills.

Even though its been busy, I still found time to launch a new FREE SAP course that I want You to get access to.

Free SAP Trial Installation Course

The course shows you Step By Step how to setup your very own SAP Trial system so you can learn new SAP skills, practice ABAP for your exams or just have a tinker around and play in your own SAP system.

You can access the course here.

Please share the course with your friends and colleagues.


Now we are into 2014 let me ask you … What skills are you going to learn or improve on?

For me… I want to learn more about HANA. What do you want?

I know lots of instructors both within the SAP community and outside. If you let me know what you want, I will see if I can get them to give us all a special offer.

How To Find Your First SAP Job

Finding your first job in SAP can be quite difficult because there is so much competition out there that you really have to put in the work to make sure that you stand out from the crowd.

I received an email the other day from somebody looking to get their first job as an ABAP developer. They seemed quite frustrated because they have been searching for a job in this field for a couple of years without much success. Here’s my reply…

.... On the job front, I fully understand how difficult it can be to break into an ABAP role as there are many people looking to do the same making competition quite fierce.
One thing I see over and over again with job applicants is that their resume's are boring boring boring. Your resume has to stand out. This is your sales letter and should make sure that the people reading it see your key strengths and that you will be able to fill their needs.
You have banking experience and you have development experience. Play on these strengths.
When looking for ABAP roles, search out roles that are banking related because having industry knowledge is a massive benefit for employers. Quite often new opportunities do not get advertised. Companies get referrals from existing employees and managers look to their own business network. This means it is really important to make connections. Social media is becoming more important than ever. People are connecting on sites like LinkedIn and discussing new opportunities and I would advise everyone should get involved in the conversation.
But you can't just join the sites and make friend requests. You have to give! You have to give something useful to your contacts so that they appreciate your views and get to know what you are about. How do you do this? You can start by joining in group discussions. Start a blog and write about work related subjects you are knowledgeable on. Help out in forums by answering questions. If you have a different viewpoint on a subject, put it across.
Making connections is very important.
There is lots more that can be done but giving yourself a head start with a good resume and online social profile is good start. Do you know that nearly everyone I speak with regarding new projects have already searched for my profile on LinkedIn? I do the same with them too.
Have you been looking for your start in SAP? Are you struggling to find that first fresher job? Have you finally made the big leap and got your first job? Write a comment below and let's see if we can share our knowledge to help each other out.

How To Build Dynamic Selections And Filters In SAP BW BEx Queries

In this article, we will dig deeper and start having a look at Dynamic Filters. These allow us to present various options to the users to dynamically create selections using a whole range of variable types and variable processing types built into SAP BW.

The following will be covered:

  • OLAP, Text, Hierarchy, Hierarchy Node, Formula, Replacement Path and Authorisation Variables;
  • Processing Types for Variables;
  • Customer Exits and SAP Exits.

By the end of this article you will see just how powerful dynamic selections are to build reports that can be used many different users, and make it so that those using the reports have to understand very little about using BEx Reports – because you will be presenting filter interfaces which will make data selection simple.

OLAP Variables

In a previous article, we saw how to select data in a Query by selecting Filter criteria so an output is reduced to only the records that meet our Filter criteria. In order to make reports selections dynamic, OLAP Variables are used, for Characteristics, Texts, Hierarchies and so on. By using them Queries become a whole lot more flexible.

It is important to keep in mind that OLAP Variables are reusable objects. This means that any variable created on any Characteristic can be used in any other report on any other Infoprovider that also includes that Characteristic. So if an OLAP variable was created for ‘Employee’, any other Infoprovider and query that uses this field would also be able to access the OLAP Variable, making it very flexible and helps to cut down the work required when making Variables – creating it once and making it available everywhere else. Because of this, a SAP BW System can contain hundreds if not thousands of Variables that can be made use of.


The screenshot above shows a Characteristic Relation with five ‘Personnel Areas’ fixed in the query. I want to make it so the user can select their preferred ‘Personnel Area’ at the time they run the query. Therefore, they need to be replaced.

Select and remove the pre-determined values, and then right click on the Characteristic. Selecting “Restrict” brings up the Select Values for the Personnel Area field. Select “Variables” from the Show drop-down menu. The system will refresh and show any existing Variables that have been set up for this field. To create a new Variable, click the Create New Variable icon clip_image004 and a window appears which contains various fields which are used to define the Variable.


Even though there are many tabs, only a few options are important at this stage. First, give the Variable a Description and a Technical Name. The Global Setting section includes a drop-down to change the Processing nature of the Variable; the default is Manual Input/Default Value, but there are others which will be covered later. The Reference Characteristic should be set to the one you wish to base the Variable on.


The Details tab is where we specify how the selection option appears. Variable Represents gives several options of how the user can interface with the Variable (the choices are Single Value, Multiple Single Values, Interval, Selection Option and Precalculated Value Set).

The most flexible of these is the Selection Option; if you are familiar with SAP selections which give ‘From’ and ‘To’ boxes, with the option to add more values including Single Values and Inclusions/Exclusions, then you will recognise this option. This section will focus on the Single Value option to show what effect making a different selection type has on the Variable.

There is also an option to determine whether using the Variable Is mandatory or not, forcing the user to fill it in. (There is also an option to make the Variable Mandatory, Initial Value Not Allowed, but this is rare.) To make sure the user can use the Variable, always ensure the Variable Is Ready For Input checkbox is checked; it can sometimes be disabled when creating different types of Variables, such as Customer Exits.

These are the two most important tabs here. As for the others: Personalisation gives the option to make a user’s personalised data, if Personalisation’s are turned on in the System, appear in the Variable. Default Value gives the option to add a pre-existing value as the default value, and there are also tabs for Currency Unit and Extended options.

Clicking OK brings a summary window; click OK again and the new Variable will appear. Move to the right hand window (clicking the blue rightward arrow), click OK once more and the Variable will appear under the Characteristic.


Running the Query produces a selection window, generated from the OLAP Variable created in the previous steps. There is the option of selecting a Variant, which a user can save for the Query, and a Common Variable which the user is required to fill out (this is shown by the ‘(*)’ next to the Description). The drop-down menu will produce recently used values from the History, or a value can be typed in.


When a Variable is set to Single Values, clicking the selection button brings the Select Values window to select a value from either the History or the Single Values list. When a value is selected, it will enter the Key into the selection field; clicking the Check button brings up that Key’s Description.


If the Variable has been set to Multiple Single Values, the Selection icon brings up a different window which allows the dragging and dropping of multiple values. These are represented as multiple Keys divided by semi-colons.


A Variable set to Selection Option allows the selection of Value Ranges as well as Single and Multiple Single Values, as well as the ability to Exclude values.

Once the required value has been selected, clicking OK executes the report.

There are limits to what changes can be made to an existing Variable. The Description can be altered, but the Technical Name is fixed, as is the Variable Represents option under the Details tab. Instead, it may be necessary to create a new Variable altogether.

Some types of Variables cannot co-exist within the same field. For instance, if a Selection Option Variable and a Single Value Variable are both in the same report, it will not execute. On the other hand, Variables can be added for any other field in a Query.


As well as dragging a Characteristic into the Restrictions section and creating a Variable that way, it is possible to search for OLAP Variables within the Infoprovider list, under the Characteristic’s Value Variables folder. Dragging and dropping this instead automatically adds both the Variable and its field.

If a Variable is created by dragging a Characteristic into the Restrictions area, it will not be automatically included either as a Free Characteristic or in the report, and needs to be manually added.



Here is an example of two OLAP Variables within a report. The first Variable, “STHQ_Pers_Area_3” is set to Selection Option, and so several values have been selected. The second, “Nationality” is set to Single Value, and so only the ‘German’ value has been selected. The resulting report is shown below.

I’m sure you’ll agree that the Variables that can be added to Characteristics add another dimension to reports, allowing the user to use dynamic selections instead of hard-coded values, making reports a lot more flexible and easier to use.

Hierarchy Variables

These are used to select hierarchies that can then be used for certain Characteristics.

The hierarchies detailed in one of the previous articles were predetermined by a hierarchy structure which had been setup in BW, taking data from an SAP system. (A Characteristic’s hierarchy is configured in the back-end of a SAP ERP system, and then transferred to BW so it can be reported.)

However, we are not just restricted to one view of the structure of a hierarchy: for instance, with an ‘Organisational Unit’ there would be the choice of the existing view, the view from the year before, a Plan, and so on. We can choose which version of the structure to use in a report by setting up a Hierarchy Variable.


To do this, when choosing a Hierarchy from the tab in the Properties section of a Characteristic, select Hierarchy Variables instead of Name. Click on the button to the right of the drop-down to bring up a window to select a Variable. If there are none available, click Create New, and fill in the fields as when creating an OLAP Variable.


The Default Value can be used here if required; clicking on Change Standard Values allows the choosing of a Hierarchy Name and the version (if multiple versions exist).


Once selected, the Variable’s Technical Name will be visible in the Properties pane (this example: “Z_ORG_HIER”).


After saving and running the Query, the Variable will appear in the Select Values screen (here, as “Org Structure Hierarchy”, with a mandatory * and a default value.) and the desired Hierarchy can be selected from the drop-down menu.

Hierarchy Node Variables

Each level of a hierarchy is called a node. A Variable can be created so that the user can select an ‘Organisational Unit’ using a particular node of the hierarchy.

To do this, after selecting a static Hierarchy Name for the Characteristic you are working on, right click on the field in Characteristic Restrictions and click Restrict. The Select Values window will open. From the Show drop-down, select Variables.


The default view with a normal list of variables should appear; change this by selecting the Type drop-down menu and selecting Hierarchy Node Variables.

You may see one existing Variable in the list, ‘Organisational Unit for a Report User’. This is a standard SAP Variable which uses technical settings (a SAP Exit) and introduces coding aspects of selection variables (which this book does not cover). Instead, click the Create New Variable icon. Give the Variable a Description and Technical Name in the General tab.


Hierarchy Node Variables can represent single values or multiple single values, which allows the selection of multiple levels/nodes of the hierarchy at once.

Once the Variable has been created, click OK and transfer to the Selection section of the Select Values window. Clicking OK will add it to the Query.


When running the Query, clicking the Selection button next to the Variable’s field brings up a Select Values screen with a structural view. (For those working within an SAP system this Organisation structure will be familiar, as it represents the company you are working in.) Either select a level or drill down to find specific values to add, drag them to the Selection side of the window, and click OK. The values will appear in the Variable field as before; clicking OK again refreshes the report.

This type of Variable is a good way of making use of hierarchies within a selection. The user doesn’t need to remember the individual ‘Organisational Units’ when making a selection in a Query – they can make use of the hierarchy, and just by selecting one of the nodes, they can make use of everything underneath.

Replacement Path Variables

This section will discuss Replacement Path processing types for Variables, as well as looking at an example of how to use them within a Query.

A Replacement Path Variable is a simple but powerful feature within the BEx Analyzer and Query Designer. Instead of the user entering a value at run-time to filter the data, these allow automated functionality which replaces values in a selection from a Query with values that are taken from another Query.

Also, values from certain Characteristics and Attributes can be used as Replacements. This is useful for changing the name of a column of data to include a Characteristic or Attribute value, for example: if there was the requirement within a report for one column per calendar month, one for January, one for February and so on. Instead of creating individual columns with fixed names, there is the option to add ‘Number of Employees for January’ followed by some text of the Characteristic as part of the column headings

Let’s look at a scenario where a Replacement Path processing type for a Variable can be used in a query.


The first Query is designed to show the ‘Number of Employees’ organised by ‘Personnel Area’ and then by month. A simple Query, but I want to restrict the number of records to the ‘Personnel Areas’ that have the top 3 hiring numbers. To do this, I have created a second Query which will show the top three ‘Personnel Areas’ with the most amount of employees being hired in the whole year.

So, the way this works: Query 1 is executed, and then because it sees the Replacement Path processing type Variable for ‘Personnel Area’ Characteristic, it executes Query 2 first, to get the values necessary to complete Query 1. Query 2 will bring the record showing the top 3 ‘Personnel Areas’ and from there passes these records to Query 1 which then continues running, presenting the data to the user.


To show how this works, we will start by looking at the two Queries.

clip_image042 clip_image044

Query 1’s Rows and Columns are arranged as above: with Rows for each ‘Personnel Area’ and ‘Subarea’, and then Columns that show the Key Figures for ‘Number of Employees’, divided by ‘Calendar Month’.

Under the Filter tab, we can see Restrictions in force. ’Personnel Subarea’ will exclude any records that are equal to ‘#’ (this will remove any blank records from the report), ‘Calendar Year’ will only include 2004’s records, and ‘Personnel Area’ has a new Variable which uses the Replacement Path Processing type.


Removing the Replacement Path Variable and running the Query produces a report that shows ‘Personnel Areas’ divided by ‘Subareas’, and the ‘Number of Employees’ for each calendar month in the columns, with a Subtotal for each Area which contains more than one Subarea. As it currently stands, the report runs quite long and produces every single Personnel Area – instead, what we want is to filter out all but the top 3 ‘Personnel Areas’ according to the number of employees hired.

In order to create a Variable that uses a Replacement Path Processing type, the object that will be used as the filter needs to already exist – therefore, Query 2 needs to be created before a Replacement Path variable can be created in Query 1.

clip_image048 clip_image050

Query 2 is very simple: there is only ‘Personnel Area’ and ‘Number of Starters’ (which is ‘Number of Employees’, but renamed in the Properties pane) in the Rows and Columns section. The Restrictions for ‘Personnel Subarea’ and ‘Calendar Year’ are identical to Query 1, along with another exclusion to remove blank entries from ‘Personnel Area’.

‘Action Types’, in this case, define the Employee new starters in this Query, using HR terms which restrict the data to when the hiring action has taken place.


Running this Query produces a report with the top three ‘Personnel Areas’ ordered by Number of Starters’. We do not have to pay attention to how this Query looks; the end-user will never see it as it is being used in tandem with Query 1.


This Query was restricted to show only the top three ‘Personnel Areas’ by creating a Condition , which tells the Query to only show the records that have the Top 3 values.


Right clicking on the Condition and selecting Edit from the context menu brings up the Change Condition window, where the parameters are set. These will be explored in more detail later in the book.
Now, having shown Query 1 without a Replacement Path Variable, and ensuring Query 2 is ready, it is time to add the Variable which links the two.


After dragging ‘Personnel Area’ to the Characteristic Restrictions section, and selecting Restrict from the context menu, the Select Values windows will appear. Like the previous Variable types, a new one is created by selecting Variables from the Show drop-down and clicking Create New Variable. Type a Description and Technical Name, and then under Processing By, select Replacement Path.


Then, under the Replacement Path tab, there is an option that specifies that we want to replace the Variable with another Query. Click on the icon next to the Query field and select the required Query. This is all that is needed; none of the other tabs need to be altered. Click OK to finish creating, and drag it to the Selection area of the Select Values window.


With the Replacement Path Variable in place, Query 1 now runs Query 2 to find the Top 3 ‘Personnel Area’s. This data is then passed back to Query 1, which restricts the results accordingly.

Text Variables

These use the Replacement Path processing type again, and are used to apply flexibility to descriptions in field names and report titles. For example, we can change the Report title to include Dynamic Text, or change the headings of columns.

One use for Text Variables is to change the title of a Query, for when you want to replace the default title (which may appear as ‘STHQ_Pers_Area’ and you would prefer something more descriptive) and include some dynamic Variable text which comes from a filter.

The following steps will create a title which will dynamically change according to the ‘Calendar’ year filter in the Query.



Clicking on the Query Properties button in the toolbar brings up the option to change the title in the Properties section. Here, you can change the title and add a Variable. Click the button to the right of the Description field to either Select a Value, or create a new Variable, which brings up the Change Variable screen.


In the General tab, after entering a Description and Technical Name, change Processing By to Replacement Path and select the Characteristic to reference (in this case, ‘Calendar Year’).


For this example, the Replacement Path tab doesn’t need to be altered. The Replace With option would be changed if using an ‘Organisational Unit’ where the Label would be more useful than the Key. Numerical values won’t have these, so leaving as Key will be fine. There is also an option for Offset Start and Length, which determines positioning of the text its formatting. All the other tabs can be left as they are.

Choose OK, confirm and select from the Select Values list. Click OK and the value will be inserted into the Description field, with the Technical Name surrounded by ‘&’ characters. “Personnel Type for &Z_YEAR&” will then be shown as “Personnel Type for [the year]” when running the Query.

One thing to keep in mind at this point is that Text Variables can only work correctly with unique values. With the title example above, the ‘Calendar’ value was being filtered on only one value; if there were more than one, the Variable would not know which value to choose, and the Variable title will appear instead indicating that the filter isn’t unique enough to be used as a specific name.


Another use for Text Variables is to change columns in the same manner. The process for adding a Text Variable to a column is very similar to a title: when a Column Key Figure is selected, there will be a Description field in the Properties section, with the same Variable Selection icon.

A good thing to remember is that wherever this icon is visible, it indicates that Text Variables can be inserted into the field it is next to, throughout the BEx Query Designer.


This Table shows the result of adding a Text Variable to the ‘Number of Employees’ column, here adding the year as filtered in ‘Calendar’ (2004).


Text Variables can also be added to Restricted Key Figures (these will be covered in a separate section). In this case, the Variable can be added within the Change Selection window when creating a Restricted Key Figure.

If a Variable is added in this way, and it contains mixed data, then it will not display the data in the report, just the Variable’s Technical Name. For example, a Variable for ‘Calendar Month’ is added, and a specific month is not filtered, then it will just show the Technical Name instead of ‘January’.

One more thing to note is that drilling across will not bring unique values; the BEx Query Designer and Analyzer cannot dynamically determine a title with restrictions or drilldowns because they don’t form part of the Restricted Key Figure itself.


To work, the Characteristic would have to be within the Restricted Key Figure, which means it will need its own filter that will only be applied to that specific Figure, by Restricting within the Change Selection window. The above window shows filters not only for the ‘Number of Employees’ Key Figure, but also for the ‘Calendar month’, restricting the data to January. This will ensure that the Text Attribute will work correctly.

This has the side-effect of removing the drilldown functionality for monthly data; this would be solved by creating a Restricted Key Figure for each month. Copy and paste, and just change the month for each one.

Formula Variables

These are very similar to Text Variables and can be used wherever there is a numeric input in the Query design, such as a calculated Key Figure, Conditions or Exceptions.

To demonstrate, this section will show a Formula Variable used in a Calculated Key Figure, which itself will be explained further later in the book.


To create a Formula Variable, double-click on a Formula to enter the Change Formula window, and right-click on the Formula Variable folder within the Available Operands section. A new Variable will appear; right-click that and select Edit. As before, enter a Description and Technical Name, and then change Processing By to Replacement Path Variable.


Then, select a Characteristic that has a numerical value. Here, we are choosing ‘Calendar Year/Month’, as this will list months and years as numerical values instead of using text. (Also, this will factor the number of days in a leap year.)


Under the Replacement Path tab, be sure to change the value of Replace With to ‘Attrib Value’. This will allow you to select from the following list of the Characteristic’s Attributes in the field immediately below.


After one has been selected (we will use ‘Number of Days’ here), click OK, and drag the new Formula Variable into the Detail View, where the formula is built. Once happy with the formula, click OK to close the window.


Here, we can see the column with the Formula Variable in action, drilled across by ‘Calendar Month’ – the first month has 31 days, second by 29 and so on. We can then use these figures in a calculation by bringing in another Key Figure, such as ‘Number of Actions’ and then dividing them by the Variable, which could produce an ‘Average Actions per Day’ column.

Authorisation Exit Variables

Suppose you work in a company, and you have responsibility for managing a team of employees in your finance department. There can be many BEx reports to help carry out management work, but because of issues like HR security, permission would be given to see data for only the specific employees each section manages, locking out other departments’ data.

This is where Authorisation Variables come in; when added to a Query the system will carry out authorisation checks on the data the Query is trying to access, displaying only the data that the user has permission to see. Normally, a company’s back-end security team would set these up, and in an SAP implementation there will be security specialists who will set up security rules which will determine who can access what data.

BW makes use of these rules by using Authorisation Exits. To implement these into a Query, the Restrict menu option is used; instead of selecting an individual Value, the Variables section is used. A new Authorisation Variable is created in a similar way to other Variables, except Processing By is set to Authorisation in the General tab.

The other setting to determine is Variable Represents under the Details tab. If there is just one security code, then Single Values is sufficient, although many ‘Organisational Units’ have multiple sections, and so there is also the option for Multiple Single Values or Selection Options.

The SAP security team will have already set up the security rules that relate to the Characteristic that is being referenced by the Variable; usually they are set up once for every user and so creating these is somewhat rare. This also means that creating an Authorisation Variable on its own is not sufficient; the security rules need to be in place for it to be effective.

SAP Exit Variables

These are processing types for Variables that have been delivered by SAP, and have non-standard functionality. These are defined in the Variable list by having ‘(SAP Exit)’ in the name. An example would be a Variable which would automatically select a period of six months and present them as a dynamic selection in the Query, using ABAP code which would determine the selection values, passing along to the Query a filter value for the required time period as a selection.

These can be used just like any other type of Variable, and there are many SAP Exit Variables available, particularly in financial applications.

Customer Exit Variables

Unlike SAP Exits, which cannot be modified and are developed by SAP, Customer Exits give the facility to write custom ABAP code to make complicated selections without input from the user. So, a Customer Exit selection Variable could be created for a ‘Calendar Year/Month’ Characteristic, which would only include this month and last month in the selection range. To do this, a Customer Exit would have to be created.

Creating a Customer Exit is similar to other Variables; under Processing By, select Customer Exit and ensure the right Characteristic is referenced, as well as the preferred type of Variable Representation. Choosing ‘Ready for Input’ gives the opportunity to code some initial selections that will be presented to the user on the screen before the Query runs, so that they can amend the selection made by the code.


After creating the Customer Exit in the BEx Query Designer, it would be accessible to developers using ABAP, and the code would be put into place, filling a structure which would be passed through to the Variable and used for dynamic selection in the Query.

This is an advanced technique that would usually only be used by developers, but it is good to know that the functionality exists, so that Customer Exits could be requested for certain tasks.

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:


The Value of Being Self-Sufficient

“I love deadlines. I love the whooshing noise they make as they go by.” So said Douglas Adams, the famed author of such hits as Hitchhiker’s Guide to the Galaxy.

Self Sufficient SAP Developer

Unfortunately for the rest of us, we are not famous authors and most of us don’t have the luxury of letting our deadlines lapse. Our deadlines are implementation deadlines, by which our whole company could become stagnate until implementation succeeds. Our deadlines are product release dates that are essential to our business’ bottom line. We have to complete projects for our bosses to keep them from firing us, and to keep their bosses from firing them, and so on. In general, we’re a deadline driven world.

Having deadlines is both a good thing and a bad thing. On the positive side, they drive productivity. They give projects a certain start and end date so they do not simply stagnate and drone to a halt. Deadlines have a psychological effect on people that often causes them to produce some of their best work while under pressure.

On the other hand, they can also cause stress and worry, particularly when you’re working under a deadline and some members of your team are not particularly reliable.

In the IT world, one or two unreliable team members can often make a huge difference in how quickly a project gets done and how well it’s completed. Given the field’s propensity for specializing, there are often few, if any, individuals who can step in and take over if one person isn’t performing.

This propensity can result in some rather unfair outcomes, though. What if you’re suddenly held accountable for the work your teammate failed to perform? It doesn’t matter if you aren’t the accounting specialist in charge of implementing the accounting processes on your new SAP system – your boss wants to know why it isn’t done on-time, and you’re the one in his line of sight. You asked your team member to do it, but he appears to be AWOL for the day. What do you do?

My Recommendation: Learn Accounting

This response may come as a surprise. After all, shouldn’t you be able to delegate to certain people so you don’t have to worry about everything yourself? And the answer to that is yes – you should. But, if you’re an SAP system consultant, you should also be able to step in when needed to areas that are not your specialty in order to ensure it all gets done. If you’re just the “ABAP guy,” and someone is having a problem tied to the FI module that is supposed to be running without any issues, the excuse rings pretty hollow that you’re unable to help out if no one else is available. You’re a consultant in IT, and you work for a medium- or large-sized company. You’re now a “SAP guy.”

It may sound like I’m advocating you taking the weight of the SAP world on your shoulders. In some ways, I am. The fact is, in order to survive and thrive, you must be self-sufficient in many ways in order to avoid layoffs and out-sourcing. That means knowing not only your area, but also the systems that impact your area, so that you can troubleshoot in more ways than just one. Your vision, then, is not through the lens of a microscope. Rather, you must be the one at the top of the ladder looking down at all of the components laid out before you and how they must fit together to function smoothly.

“But I’m just the one responsible for developing ABAP programs,” you might protest. “That’s all I want to do.” Chances are, most of the time, that is what you will do. But if you have a deadline looming and the functional area your ABAP programs are working on is malfunctioning, do you really want to have to wait for outside help to get up and going?

New Opportunities

Many employees aren’t working with the thought that they’ll be at the same job for the rest of their lives anymore. It’s understood that you’ll seek other opportunities with other companies, or seek to advance within your existing company. If you’re in IT, chances are, you want the opportunity to grow your career rather than be at a stalemate once you hit some plateau at the peak of your current skill set. Who is in a better position to achieve growth, transitions, and advancement: the one who took the extra time to learn other functions that directly impact his or her particular “specialty,” or the one who operates in a vacuum and relies on others to rescue them when things to go wrong?

This need to develop a broad skill set extends to more than just technology; it also extends to the underlying business for which you work. Just to use an example: there is an accountant who is responsible for preparing tax returns each year for his clients. Rather than being an all-purpose accountant who files taxes for a broad range of people each year, he focuses his practice on preparing returns for law firms. This may seem like a very narrow niche; however, specializing like this has proven exceptionally lucrative for his accounting practice.

In order to grow his practice, what steps do you think he took? He knows more about how to run a law practice than most lawyers. Rather than simply concerning himself with learning general business deductions applicable in virtually any industry, he knows those that are specific to lawyers. He understands how lawyers bill for their time, what kinds of expenses are attributable to clients, and how to handle anticipated income from contingency agreements. Is he planning to open a law firm? No. But he has taken the time to learn the ins and outs of the legal industry so he can better serve his clients.

If you were serving this particular accountant with IT solutions, what would you do in order to serve his practice better? Would you content yourself with a crash course in FI-CO? Or would you take the time to develop some knowledge in the area of taxes and law practices to come up with a deeper understanding of his business and how to serve it best?