Danielle Larocca

I have just returned from celebrating the holidays with my friends and family.  I love watching everyone open their gifts but I can admit that holiday shopping is not fun.  It took dozens of stores/websites to get all my gifts.  If you looked at my Christmas shopping lists you would see things like a camera, train, a phone case, sweaters, ties all the usual stuff.  You would think by looking at the list that a certain superstore with a bull’s-eye logo would meet my needs but it didn’t and that’s what this week’s blog is about.  A single store may meet many of my needs but it certainly does not meet all of my needs.   I feel the same way about SAP’s approach to reporting. 

During the holidays I happened to read an article titled “The Big Squeeze: How Business Analytics Can Help You Extract Every Ounce of Value from Your Business Information” in Insider Profiles magazine. It was a really great article based on interview with SAP’s Steve Lucas that explains SAP’s focus on the future of reporting.  My understanding of the article is that they believe that all reporting information should be stored and accessed all in one place via a module called Business Analytics. 

According to the article “Readers of this publication are certainly familiar with the applications of SAP Business Suite. Financials, HCM, SCM, CRM, and so forth are their “systems of record” where they house their most prized and cherished corporate information. Business analytics solutions are the applications that unleash the value of that information. Such solutions mean that you not only have a place to put your business information, but also a way to actively engage with it and extract every ounce of value therein. That’s what business analytics are all about.”  I think the concept is great, like a BW type solution that houses all data so that it can be strategically reported on regardless of the module.  It would be a great module to leverage to report on integrated information that includes data from HCM, Finance and Supply Chain for example.  There is fantastic value in that.  What challenges me though is the one-size-fits all concept.  Let’s go back to my holiday shopping analogy.  A big superstore is great for many of my holiday gifts and I was able to get a lot of the general gifts without a problem however I still had to go to specialty stores to get the important items on my list.  Remember that camera on my list, sure superstores sell cameras but they do not sell the Nikon D7000 which my best friend wanted.  I could likely find a train at the superstore but not the POW MIA Express Train Collection that my Uncle Frank wanted and that phone case had to be ordered at a specialty store to fit Laurie’s new IPhone 4S. 

What I am trying to say is there is a lot of holiday presents that I could buy at the superstore but there will always be items that I need to get from the specialty stores.  I feel the same way about reporting in SAP.  Sure there are lots of great reports I could get from the new Business Analytics module but anything very detailed and specific to a module (like payroll and HR) still require the use of reporting tools specific to that module.  Additionally the SAP HCM module is largely unique because of the heavy amounts of real-time transactional data that is processed through it and the complex relationship for payroll results etc. 

For me this article reiterated the supercenter direction that SAP is moving towards.  Business Analytics will certainly play a huge role in organizations and provide a large number of SAP HCM reports that I am excited about however I am still concerned that I will still have to go to a bunch of other places in SAP like Wage Type Reporter, Ad Hoc Query, HIS etc. to get at the detailed specific data I need. 

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

spinifex IT is the creator of Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca

When creating reports with SAP Query there may be occasions where you want to highlight or flag certain records for attention, real-world HR examples include:

• Listing all associates and their salaries and flagging those that are over the maximum (or under the minimum) for their pay grade
• Listing all associates and flagging those who are out on a leave
• Listing all associates and their performance scores, flagging those who scored less than “meets Expectations”
• Identify associates who are under (or over) a specified age (such as 18) to assist you in determining which associates are eligible for particular benefit programs or which require review
• Identifying rehires who were previously terminated with a bad termination code

To do this we simply use calculated or local fields within your SAP Query.  I blogged on how to create a calculated field – check it out “Creating calculated fields in your report (How to Eliminate Duplicate Line Reporting in Query Tools)” here on SAPINSIDER. 

To insert a picture, only when certain conditions are met please follow the steps below.   This will insert a flag for associates born earlier than 1989 as shown in picture.

1. Navigate to the Select Field screen (#2) of SAP Query
2. Add a short name for the Year of Birth field from infotype 0002 and give it a short name (YBIRTH)
3. Follow menu path Edit > Local field > Create and a dialog box will appear
4. Give your new local calculated field a short name, field description, and heading
5. Define the attributes of your new field by selecting icon
6. Select the Complex calculation button
7. In the Condition line, specify the expected value. You first list the short name you gave to the reference field (in the first step) followed by an operator and then followed by the value in single quotation marks.

Condition:  YBIRTH >  ‘1989’

8.  In the Formula line, specify what value you want to output. In this case you want to output a icon, so you select the icon button to select the picture you want. The Formula line is then updated with the name of that icon (A flag in this example is called ICON_DEFECT)

9. Basically, you are saying that if the year of birth is greater than 1989, output a red flag for that record

10. To check your logic, select the Check icon

11.  If no errors in your logic are found, select the green check mark icon to return to the Field definition dialog box

12. Select the green check mark icon to return to the Select Field (#2) screen

13. On the Basic List Line Structure screen (#5) be sure to add your new calculated field so that the field is included in your report output

14. Press F8 to execute your report to see your flagged records!  :)

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

spinifex IT is the creator of Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca

This weeks’ blog is a continuation from last weeks’ blog which was in response to a question about “How to Eliminate Duplicate Line Reporting in Query Tools“.  You can accomplish single-line reporting in SAP query-based tools such as Ad Hoc and SAP Query in three different ways:

1. By specifying parameters upon selection (see Dec 1, 2011 blog)
2. Creating calculated fields in your report (see Dec 7, 2011 blog)
3. Creating calculated fields in your data source (InfoSet)

This is the final blog in this series and it’s fair to say that this is the most complex solution to the question above.  The available Query based tools for SAP HCM are quite limited in the data that you can report on.  However they can be used to successfully report off of master data infotypes. 

The challenge is that some of the data on the infotypes is either not available or not available in single line reporting.  A real world example is infotype 41, Date Specifications.  This screen stores approximately a dozen different dates for an employee.  It is configured by each company to store whatever dates they wish.  These dates can be reported using a Query tool and have 1 line per date per employee for only ONE DATE AT A TIME (by specifying the sub type on the selection screen).  If you tried to output multiple dates you would get multiple lines per employee.  This is explained in greater detail in the 12/1/2011 blog. 

The option to fix this and allow for multiple date types (or other infotypes) to be output along a single line is to customize the data source itself that houses all the fields.  And here is where this gets technical.  This solution requires a trained ABAP programmer to implement.  This data source is called an InfoSet, in earlier versions of SAP it used to be called a Functional Area.  This InfoSet is setup initially when you begin using the Query tools.  If you follow best practices your InfoSet would be set up by a technical person in your Development environment and transported through to your production client.  In most cases it would be set up based on SAP’s pre-delivered logical database pnpCE.  This logical database provides access to all of the Master Data infotypes. 

Because the InfoSet is not designed for the some infotypes that cause multiple line reporting – you can customize it using a call out to an ABAP program so that you can essentially create new fields in your data source to store the data you want to output on a single line.  In the Infotype 41, Date Specifications example you would use an ABAP program to create a field to store a field for each of your date types so that in your reports in the future you can simply drag the new fields on and you can report as many date types as you wish and still get only one line per employee!

Creating an ABAP program and integrating it into your existing InfoSet is an activity that should be performed only by a trained ABAP programmer.  Here is a sample of code that can be used that can be called from your InfoSet to create a field for each date type on infotype 41.

INFOTYPES: 0041 NAME I0041.

TABLES: PA0167.

DATA: DAR LIKE PA0041-DAR01,

      DAT LIKE PA0041-DAT01,

      HIREDATE LIKE PA0041-DAT01,

      REHIREDATE LIKE PA0041-DAT01,

      LASTHIREDATE LIKE PA0041-DAT01,

      ADJSVCDATE LIKE PA0041-DAT01,  

      TERMDATE LIKE PA0041-DAT01,

      SEPARATIONDATE LIKE PA0041-DAT01,

      BENTERMDATE LIKE PA0041-DAT01,

      KEY_DATE1 TYPE D.

FORM GET_DATE USING VALUE(PERNR)

                    VALUE(DATUM)

                    VALUE(TYPE)

           CHANGING RESULT.

CLEAR RESULT.

  PERFORM READ_INFOTYPE(SAPFP50P) USING

    PERNR '0041' SPACE SPACE SPACE DATUM DATUM '0' 'NOP' I0041.

  IF SY-SUBRC EQ 0.

    DO 20 TIMES

       VARYING dar FROM I0041-dar01 NEXT I0041-dar02

      VARYING dat FROM I0041-dat01 NEXT I0041-dat02.

      IF dar IS INITIAL.

        EXIT.

      ENDIF.

      IF DAR EQ TYPE.

        RESULT = DAT.

        exit.

      ENDIF.

    ENDDO.

  ENDIF.

ENDFORM.

The picture included in this blog will show you how to refer to the custom program from the InfoSet.

Next week’s blog I will share the ABAP Code that you can use to get at the most popular fields not available in Query tools including Previous position title, Hourly Rate of Pay and Manager name which you can use as a reference to create even more fields.

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

spinifex IT is the creator of Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca

This weeks’ blog is a continuation from last weeks’ blog which was in response to a question about “How to Eliminate Duplicate Line Reporting in Query Tools“.  You can accomplish single-line reporting in SAP query-based tools such as Ad Hoc and SAP Query in three different ways:

1. By specifying parameters upon selection (see last week’s blog)

2. Creating calculated fields in your report

3. Creating calculated fields in your data source (InfoSet) (in next weeks’ blog)

When I first learned how to use the SAP Query, transaction code SQ01, I did not know you could create calculations directly in the reports themselves.  It’s actually quite easy and does not require any programming skills.  You can create calculated fields to do basic mathematical equations or even more complex if…then type logic.  You can also use it for the scenario where you want to eliminate duplicate or multiple line reporting. 

I refer to them as calculated fields but SAP calls them Local fields.  Local fields are new fields added to your existing reports in SAP.  Local fields allow you to generate new information from the fields that are already available to you for reporting.  You can create local fields from the Select Fields screen (screen #2) of SAP Query.

Often, when you want to perform calculations in SAP Query, you do so using existing fields. For example, you want to create a new calculated field that takes a person’s annual salary and increases it by a number or fixed percentage.  If you were doing this through traditional ABAP code reporting, you would need to write an ABAP program that references the technical table and field names and also be familiar with the relationships behind-the-scenes inside SAP tables.  Because SAP Query is an end-user reporting tool - no ABAP skills required, you can create your own short names for your fields so that you can easily reference them in your calculations. 

Creating a Calculated (Local) Field in SAP Query

Start by creating an SAP Query report and include a handful of fields like Personnel No, Name, Annual Salary etc. Let’s use the example of taking the Annual Salary and adding a fixed amount to it.  Because many of the calculated fields that you will create will be based on existing fields, you often start the process of creating a calculated field by giving short names to some of the fields already in your query – you do this on the Select Fields screen (screen #2) of SAP Query.

1. Navigate to the Select Field screen (#2) of SAP Query
2. Place your cursor in the box for the field that you want to give a short name to and follow the menu path Edit > Short names > Switch on/off
3. A new column, labeled “Short name,” appears. Enter a short name for the field you want to use in the calculation formula.  I will give the Annual Salary field a short name of SALARY that I will use later in the calculation.
4. Next follow menu path Edit > Local field > Create and a dialog box will appear
5. Give your new local calculated field a short name, field description, and heading
6. Define the attributes of your new field by selecting it from the list of buttons or by saying your field has the same attributes as another field already in your report.  Using the dropdown box I will select the SALARY field which means that my new field will be a currency field just like the Annual salary field on Infotype 0008.
7. For the line that says Calculation Formula, use your short name and any math you want. In my example, I will take the Annual salary field short name SALARY and add 1000.
8. Select the green check mark icon to proceed and return to the Select Fields screen
9. Navigate to the Basic List Line Structure screen (#5) and add your new calculated field to your Basic List Line Structure screen (#5) so that the field is included in your report output
10. Press F8 to execute your report and your report will now have a new column that displays each employee’s Annual Salary + 1000.

That same process can be used to specify certain date types or wage types to eliminate duplicate lines in your report.  The calculated fields that you create will exist only in that report/query.  In next week’s blog I will show the most advanced version which is to customize your Infoset (SQ02) with an ABAP program so that the calculated fields are available in the data source so the fields are available for all reports. 

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

spinifex IT is the creator of Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca

This weeks’ blog is based on an Ask The Expert Question

Dear HR Expert,

I have read a lot of the documentation in the HR Expert publication and there are often great tips on Ad Hoc and SAP Query reporting. However, one question continues to be an issue in regard to both. Is there any way to eliminate the issue of duplicate line reporting in Ad Hoc or SAP Query? A specific example would be on a basic report of current data (reporting period set to Today) of personnel number, last name, first name, annual salary, and annual bonus (a wage type) from IT0015. The output of this query would result in two records for each employee who has an annual salary stored and an annual bonus on IT0015. Another example would be pulling a rehire date and an original date of hire from IT0041. Wage types, date types, and certain subtypes always produce multiple lines per person. This causes much frustration in the HR department.

— Senior Programmer Analyst

Thanks for the question, which is a common one about HR reporting. The answer is that you can accomplish single-line reporting in SAP query-based tools such as Ad Hoc and SAP Query in three different ways:

1.  By specifying parameters upon selection
2. Creating calculated fields in your report
3. Creating calculated fields in your data source (InfoSet)

Option 1 will be covered in this blog and I will cover options 2 and 3 in subsequent blogs. 

Let’s start by making sure that you have correctly input your parameters these include the date settings.  The most common date parameter for reporting in R/3 is to the date selection period Today. Selecting Today ensures that the data you retrieve from the database is valid as of today. One thing to note is that if you have any future-dated records (for example, increases or organizational changes) they are not included in your report output because technically they do not exist yet. Most users complain of duplicate record results when selecting Other or Person Selection Period date parameters. That is because multiple records may exist for that employee during the date range specified.

Now, to get to the heart of your question regarding retrieving duplicate records when selecting Today on your selection screen. This is specific to certain infotypes that have multiple values in a single or table-based storage space. That sounds pretty technical, but basically what it means is that the database pulls all the records meeting your criteria. This issue of duplicate records does not occur with some infotypes, such as infotype0002. This is because infotype 0002 (personal data) stores each piece of information as a single identifiable field (the first name is stored in the P0002-VORNA field for example). To see the technical details, place your cursor into the field, press F1, and then click on the technical information button.  That is the only information that can be stored in that field. Let’s compare that to an infotype that does produce duplicate records, such as infotype 0041 (date specifications). Date Specifications does not have a single field identified for only a single piece of data. Rather, the data that can be stored in each field is variable.

Infotype 0041 permits storage of customer-specific dates. During your initial system configuration you determine the date types. For example an employee may have three different date types stored as Date type 30, 36, and 66, listed in numerical order.  However, unlike infotype 0002, in which the fields store only certain objects (for example, the first name field only stores first names in the P0002-VORNA field), the fields on this screen can store variable data. Date type 30 could appear in the first box or the last, depending on how many date types are on the screen. When I look at the technical details of the first Date type 30 date, I see the field name is P0041-DAT01. If I look at the details of the second date it would be P0041-DAT02, which refers to the second date box on the screen. The date type field next to it would be P0041- DAT02, and the next one would be P0041-DAT03, etc.  However, that value of DAT01 is assigned because the date is stored in the first position on that screen. If I added a new date type for the associate, such as Date type 23, that would become P0041-DAT01 because it would then be in the first numerical position. If I created a query-based report containing a specific field such as First name (P0002-VORNA), it would output on a single line. However, if I created a query-based report to output the date field (Date for Date type), behind the scenes the system would read through all of the P0041-DAT01 to P0041-DAT12 fields and output a line in the report for each date stored.

To fix this and accomplish single-line reporting in SAP query-based tools such as Ad Hoc and SAP Query you have three options the first and easiest is by specifying parameters upon selection.  This solution can work for any infotype that either stores variable data like infotype 0041 or that has sub types like infotype 0006 or wage types like infotypes 0014, 0015, and 0267.  The first workaround is the quick and dirty limited version. For example, if I wanted to create a basic query-based report that would include an associate’s hire date (using my example Date type 36), all I would need to do is to include the Date type field on my reports selection screen. Using that method I can, upon report execution, specify that I only want that one date type in my report output, thus ensuring I get only a single line. This same method works on the wage type-based infotypes.   For example, if I wanted to create a report that listed the employee’s name, position title, and hourly rate (i.e., wage type 3005) I could do so by including the wage type field on my reports selection screen. Upon report execution I can specify that I only want that one wage type 3005 in my report output, thus again ensuring I get only a single line.

I mentioned that this is a limited workaround because of the way a selection screen works. It only includes data in your report that meets the criteria entered on the selection screen. If I were to produce a report of everyone and their hire date on a single line as I mentioned previously, my single line report output would only include those associates who have that date type. Similarly, the output of the hourly rate report would be limited to only those associates who have an hourly rate using wage type 3005. If some folks were missing it, they would be excluded. I refer to this first workaround as the quick and dirty limited option as it is helpful when you are sure all associates meet the criteria entered on the election screen (so you get complete output) or if you want your report output to only include those associates. Because most companies require a date of hire, it would work for that example. Another downside here is that you are limited to reporting off only one date type. If you wanted to include hire date and service date from the above example, you would still get two lines for each associate.

The details of your second two options will be covered in next week’s blog.  Stay tuned….

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

spinifex IT is the creator of Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca

You can create three types of reports with the SAP Query tool: basic lists, statistics lists, and ranked lists. The most common type of SAP Query report is a basic list report that displays individual line-item data across the columns of the report. The data displayed in a basic list report may contain an overall total at the bottom but is often not auto summarized to display summary detail only. Generally speaking, the system displays data as it appears in the R/3 database. In contrast to basic lists, the data in statistics lists is output in a compressed, summarized format. A ranked list places items in order and ranks them in terms of highest to lowest or vice versa.

SAP Query is most widely known for its basic list style of reporting. However, it can do more than create basic lists. I will explain how you can use it to produce statistics lists, including summary analyses of data with totals and averages. The only technical requirement for creating statistics lists in SAP is using SAP Query.

SAP Query statistics lists are ideal for analyzing average rate of pay for all associates by cost center. Instead of viewing a list of all associates in the cost center and their rates of pay, you can use statistics lists to view the averages by cost center. It is also helpful to view the total number of new hires in a yearly comparison.  In other words, you can make a simple report that compares the total number of associates hired in 2009, 2010, and 2011.

I’ll explain the steps to create your own statistics lists in SAP Query. If you have already been using SAP Query to create basic lists, then creating statistics lists requires no extra configuration.

Step 1. Navigate to the Maintain Queries Initial screen by using transaction /nSQ01.

Step 2. In the Query field, enter a name for the query you are creating and then click on the Create button. The InfoSets of User Group dialog box appears listing all the available data sources that within your selected query group.

Step 3. Select the appropriate InfoSet that you use for your HR reporting and then press Enter. Most likely, this InfoSet is based on logical database PnPCE.

The Title, Format screen appears, allowing you to save the basic formatting specifications for your query, including the name (title) and any notes you want to store for the query. The only required field is Title.

Step 4. Enter a meaningful title and then select the save icon on the application toolbar.

Step 5. Click on the white arrow next screen icon on the application toolbar to navigate to the Select Field screen. This screen lists all the field groups available in your InfoSet.

Step 6. Place a check mark next to each field group whose fields you want to include in your report.

Click on the next screen icon and the Select Field screen appears with a list of all the available fields within the selected field groups.

Step 7. Place a check mark next to each field that you want to include in your report. You can use the page up and down icons to navigate among all the fields.

Step 8. Click on the Statistics button on the application toolbar to create a statistics list in SAP Query. The Statistic Structure screen appears, giving you an opportunity to define your compressed list report.

Step 9. Enter a title at the top of the screen.

Step 10. Specify the sequence in which you want to output the fields and state whether you want R/3 to sort them in ascending or descending order.

After you create a statistics list, the toolbar has a Statistic button that allows you to create multiple statistics. The ability to create multiple statistics gives you an easy mechanism by which you can define more than one summary in a single SAP Query. However, single statistics lists are most popular for HR reporting.

Step 11. Press F8 or click on the execute icon to execute the report. As with almost all other reports in SAP, you see the report’s selection screen upon execution. The selection screen gives you an opportunity to specify any criteria for the output of your report.

Step 12. Press F8 or click on the execute icon a second time to display your finished statistics list report.

You can learn more about statistics via SAP Help. 

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

Spinifex IT is the creator of  Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca

Today’s blog is in response to a question from Lynn White, Senior Business Analyst.  Lynn writes, Dear HR Expert, How do you add custom infotype fields or even standard SAP infotypes such as date specifications to the Ad Hoc Query?

Thanks for the question. The most common data source that is used for Human Resources query based reporting in SAP is an InfoSet.  InfoSets were formerly known as Functional Areas in versions earlier than 4.6.  The InfoSet is often made up of a Logical database containing all of the infotypes that you would like to report on.  Three common logical databases for SAP Human resources include: 

•             PaP - HR (Recruitment) Applicant master data

•             PnPCE - HR (PA) Personnel administration master data

•             PcH - HR (PD) Personnel development organizational data

The most common query reporting is accomplished using the PnPCE logical database because it includes the most frequently used Personnel Administartion infotypes like 0000 (Actions), 0001 (Organizational data),0002 (Personal data),7 (Work schedule), 0008 (Basic pay) etc.  

To add basic infotypes to an already existing InfoSet for use with a query based reporting tool like the SAP Query or the Ad Hoc Query you can do the following:

1.            Go to transaction code SQ02 (InfoSet initial screen)

2.            Select your existing data source that you use for your queries and select the Change button.

3.            Follow the menu path Edit > Change info type selection

4.            A box will appear that lists all of the infotypes available within the logical database from which you can select which new ones to include.

5.            For example your question mentions infotype 41 Date specifications.  This can be added by selecting it in the dialog box.

 6.           After placing a checkmark next to the infotype that you wish to include, select the check mark Enter button to proceed.

7.            When you return to the main screen that infotype will now be listed at the very bottom on the left hand side of the screen under Data fields. 

8.            It will also be listed at the very bottom of the Field group/data fields section on the right of the screen.

9.            By default only some of the fields on the infotype will be included and will be made available for reporting.  To see which ones are included look at the Field group/data fields part of the screen.

10.         By default only two fields were added, Date type and Date for date type. 

To add additional fields to be available from this infotype (or any infotype included in your InfoSet) follow the steps outlined below.

1.            In the right hand side of the window in the Date type and Date for date type side of the window position your cursor on the Field group (infotype) that you would like to add fields to.  For this example I will select with my cursor the 0041 – date Specifications infotype. It will appear highlighted.

2.            Next return to the left hand side of the window in the Field group/data fields part of the screen and view the fields that are available for the selected infotype. 

3.            When you see a field that you wish to include (and make available for query reporting) right click on it and select Add field to field group.

4.            That field will then appear on the right hand side of the screen under the selected infotype and is now available for reporting.

6.            Be sure only to add fields to the appropriate infotype.

Now to the other part of your question regarding the addition of custom infotypes to your queries.  The same steps that are outlined above can be used to add custom infotypes.  All custom infotypes that you create will be available in the Data fields window under the grouping Further infotypes.  They will be listed in numerical order.  So it is most likely that your custom infotypes are available at the very bottom of the list of infotypes in that section.  You add them to your queries following the same procedure outlined above.

The most important thing to note is after making any change to an InfoSet is that you have to Save and Generate the InfoSet before exiting.  The Save button is available on the application toolbar.  The Generate button looks like a red and white beach ball and is used to check the consistency of the InfoSet.  After saving and generating the infotype you can now use these additional infotypes and fields in your new and existing SAP Query and Ad Hoc Queries that use this InfoSet as the data source.

Danielle Larocca, SpinifexIT

Connect with me on Linked In at www.linkedin.com/in/daniellelaroccasap

Spinifex IT is the creator of  Easy Reporter, the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting. Check it out for yourself online at www.spinifexit.com/easy-reporter/ or contact me for a live WebEx demonstration.

Danielle Larocca, SpinifexIT

Hello and greetings from Viva Las Vegas.  I am here speaking at the Reporting and Analytics 2011 conference at the Mirage hotel.  As usual the SAPINSIDER team is putting on a wonderful show.

Last night I participated in the Ask the Experts forum in the Solution Showcase.  The forum takes all the experts from different areas and gives them a round table then any conference attendee can come and meet with them and ask as many questions as they like.  I was listed as an expert on SAP HR and Payroll configuration and reporting. 

The most popular question I get is “Is there one tool that can be used for all SAP HR & Payroll Reporting?”   Pre-delivered and for free?  The answer is no.  The truth is there are a handful of free tools inside SAP each satisfying a different area.  For example the Wage Type Reporter is good for Payroll reporting the SAP Query or Ad Hoc Query tools are good for Master data reporting, SAP Netweaver BI (BW) is good for strategic high level reporting or reporting off of multiple modules like HCM and Finance.

I met a few SAP Netweaver BI (BW) experts here at the conference who would say that BI can be used for all your SAP HR and Payroll reporting.  I challenge that with the following considerations.  For starters BI is not real-time reporting in SAP.  The data available in your BI data warehouse is only as current as your last scheduled download from SAP.  And about the downloads - there are a handful of pre-delivered ones in BI that extract key summary data for HR and Payroll.  You need to configure these extractors to pull data and save it in your warehouse.  It is my opinion that these extractors retrieve more summarized data that only gets to a certain level.  For example with BI I can create a headcount report and drill in to see how many employees in each location and how many are male and female.  To me that is summary data.  I want what is so important for HR and Payroll reporting which is transactional level data.  I still want the headcount and the breakdown but I also want to know how many hours each employee worked in each location (their clock and out times) the rate of pay for each hour worked and where it was costed to.  Standard BI is not designed for this.  Can it be configured by a BI expert to get some transactional level data – sure anything is possible but it’s not the standard practice.

I’ve been doing this whole SAP HR and Payroll reporting thing for 14 years now and I have only once seen a tool that does everything in one place – live inside SAP and that’s the Easy Reporter.  I saw it a conference liked it so much that I joined the company and I now manage the operations for North America.

I’ve never been much of a salesperson but I will say this.  There is only one YES to that question “Is there one tool that can be used for all SAP HR & Payroll Reporting?” and that is the Easy Reporter.  Easy Reporter is the only SAP certified solution that runs live inside SAP for real time HR and Payroll reporting.  Don’t take my word for it check it out for yourself online at www.spinifexit.com/easy-reporter/ or email me and I can show you a live WebEx demonstration.

And even though my career long search for the perfect answer to that question is over - I will continue to be a presence at conferences and write for the SAP Professional Journal and HR Expert Magazines on SAP HR and Payroll reporting.  My conference sessions almost always focus on “work-arounds” for trying to report on the HR and Payroll data you need and I am always happy to share what I have learned with others so feel free to reach out and share your opinions.   

Connect with me on Linked at www.linkedin.com/in/daniellelaroccasap

Email me to get an Adobe pdf graph showing all the SAP HCM solutions in a comparison chart.

Danielle Larocca, Spinifex IT  

This blog is in response to the question shown below.

Dear HR Expert,

At my company we are running SAP HR Organizational Management (OM) 4.6C. We think it is difficult to handle the control of all positions. My concern is that we have a lot of open positions that are not really open. Let me give an example. The production department hires 30 employees as temporary staff for a period of three months. We create 30 positions. After the three months, we terminate the 30 people and do not know if they are to be rehired later. This means that we first run the termination action for each employee and afterwards have to go to OM and delimit the 30 positions.

Otherwise, they show up as open positions. Here’s another example: An employee decides to leave the company and it has not been determined if his position is to be replaced. We run the termination action and have to go into OM and delimit the position. Is there a better way of doing this, or shall I just leave these positions as open? Thank you,

Martin Ringive, Application Consultant

Thanks for the question. It’s a common one for SAP HR customers who have integration turned on between Personnel Administration (PA) and Organizational Management (OM). In a nutshell, positions in SAP are objects within the Organizational Management component. OM has several different types of objects: organizational units are object type O, jobs are object type C, and positions are object type S. These objects exist in  Organizational Management regardless of whether or not they are used on the PA side. That is the source of a common misunderstanding – thinking that when you terminate someone the position is also delimited.

Let’s look at an actual scenario. Company X has a new hire named John Smith. The first step is to create a position or to find an existing one in the organizational management component in SAP. For this example, you create the position (object number 5252000, object description Shipping Clerk). Next, you initiate a hiring event on the PA side and create a personnel number for John Smith (PERNR = 12345). During that hiring event, you create a relationship between the two existing objects, so that personnel number 12345 is related to position number 5252000 (in other words, John Smith is a shipping clerk). During a hiring event, when a relationship is created between a person (P) and a position (S), the person inherits all the other relationships tied to that position, which in my example includes the cost center name, the cost center number, and the job code, all of which appear on the employee’s infotype 0001.

Now back to your question. When you terminate an employee in R/3, the only thing the system does is delimit (put an end date on) the A 008 (holder) relationship between the person (P) and the position (S). That is why the position object still exists after the employee has been terminated. A popular practice is to use vacancy processing in OM (infotype 1007) so that during the termination event a dialog box appears asking you if you wish to create a vacancy for the position.

If you select YES, the position is deemed “vacant” and appears on the standard SAP-delivered vacancy report.  If you select NO, then the position does not have a vacancy attached to it. This distinguishes a vacant position that will be filled from one that will not.

You inquired about leaving positions out there as open forever. You can do that, but if you are like me and want a clean system, you can routinely clean them up. A popular solution is to create an ABAP program that locates and identifies any position that does not have a holder attached to it (A 008 relationship between an S and a P objects) and that also does not have the vacancy flag set as vacant on infotype 1007 and delimits it.

Note! If your company does not distinguish between vacant and unoccupied positions – that is, you consider all unoccupied positions to be vacant – you can set an indicator rather than maintain the vacancy infotype. It is not mandatory that you utilize vacancy processing in SAP. You should, however, use vacancy processing if you install the following HR components: Personnel Cost Planning, Performance Management, Succession Planning, or E-Recruitment.  For these sub modules, reuse of positions when they become vacant makes your processing easier. In the case of Succession Planning, if you create successor relationships from a person to a position and the position becomes vacant, you can easily identify who the successor to that position is and fill it accordingly.

Danielle Larocca recommends the Easy Reporter tool for all SAP HCM reporting.

Danielle Larocca, Spinifex IT

Companies always want to know counts of employees — how many are active, how many on leave, how many termed, etc.  Many organizations have only the SAP
pre-delivered employment status field (values shown below) on infotype 0000 to
use to try and figure this out. 

•           0: Employee
not with company (used for termination actions)

•           1: Employee
with company, but inactive (used for unpaid leaves)

•           2: Employee
with company, but as retiree (used for retiree actions)

•           3: Employee
active in company (hire/rehire and non-status change organizational actions).

These classifications, however, do not provide much info.  They are essentially the payroll classifications that drive who gets paid and who doesn’t.  For example, by using just these status types you can’t tell how many employees are on leave or how many are suspended, for example. 

I also see companies try to use the actions themselves for count based reporting.  For example, the company may have two actions to record leave one for paid and another for unpaid, each assigning the appropriate employment status.  Then they would create a report that searches for anyone who has undergone a certain action AND for those who have a certain employment status. 

Using the traditional pre-delivered SAP Query and Ad Hoc Query tools for action based reporting (infotype 0000) is a bit like looking for a piece of hay in a haystack.  You will get multiple rows per person, with some back dated and others future dated. This approach will not get what you want.

What if I told you that SAP already knew all this and made a single field for you to assign status that you just didn’t know about?  Too good to be true?  Not this time.  SAP delivers a standard field on the Infotype 0000 called Customer Specific Status.  The Customer Specific status field is in addition to the standard status fields,
such as Employment and Special Payment, which are available in every employee’s
infotype 0000.  The Customer Specific Status field is designed to hold any level of detail that your organization wishes to store on employee status, including active, on paid leave, unpaid leave, severance, on strike, suspension, etc. The options are almost endless.

Why didn’t you know about it?  In the very early versions of the SAP system the Customer Specific status field was not visible on infotype 0000 by default. You actually had to make it visible, so many people didn’t know that it was the appropriate place to store the status and, mistakenly, they used another field
like the employee group field instead. Well now you know.  The great part is you can start to use it immediately, and it’s very easy to setup.  It works exactly like the other two status fields in that it gets updated with each action and has no impact on payroll or time or other areas. It’s exclusively for reporting!

How to Configure the Customer Specific Status Field

You can define each personnel structure and status item via the IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions. Each action in the IMG contains a column in its configuration for the assignment of the three types of status — Customer-specific, Employment and Special Payment.  Doing it is easy, but before getting started, be sure to ask your senior leadership team which status types are important for your organization.  They could be as simple as active, paid leave, unpaid leave, terminated or retired.
Or they could be as complex as on new hire probation, paid FLMA leave, unpaid personal leave, military, jury duty, suspended, on strike, walk out, avoidable termination, unavoidable termination, etc.

If you want to see more tricks on how to better classify your employees, check out the HR Expert Articles:

Best Practice Design for HCM Personnel Structure and Employee Status Fields and  Configure HR Actions/Events to Improve Your Reports .

Danielle Larocca recommends the Easy Reporter for all SAP HCM Reporting.