Hello,

I tried to Google on PU12 issues and could not find any good help over the internet or even SDN. I see many people posting questions but not many giving answers to them. After I found mane answers to my problems I thought of posting a blog of my work on SDN so that people in future get a good starting point.

This tutorial is for beginners in PU12 who have never used the tool; it is equally beneficial for Functional as well as Technical persons. This is my first blog on SDN and it might lack few technical points, few explanations might not be best, please feel free to post questions and I will try my best to answer those questions.

HR Interface Toolbox (a.k.a. PU12) is used for transferring HR Masterdata and Payroll data. It is a very robust tool and helps cut a lot of coding and testing costs. Even then, it is not widely used in the world the reason is not its limitations, but the learning curve that is involved. Many people do not have expert level skills in HR Interface Toolbox and try to avoid it, but they get involved in a lot of custom coding, bugs, testing and maintaining costs.

There are a lot of customizations and technical details in PU12 that can be found in this 184 pages document from sap. I will try to cut the blog to minimal simplicity. I will just go through the payroll data transfer process, and will discuss the Masterdata transfer process in a little detail.

First, PU12 by default transfers the data in plain text files, but it can be tweaked a little bit to send data through IDOCs. See the ADP interface provided by SAP, which sends data through IDOCs. Also, it does not give any configuration level control to send (pipe or comma) delimited files.

Let’s kick-off. I will strongly suggest going through the document provided by SAP at this link. This will be bible for us, and all answers can be found over there.

Let’s start with transaction code PU12. You will see following screen:

Export tab will be used to execute the interface and read the results.

Export History tab is used to see the log, and the results of previously executed runs.

Configuration tab will contain all of our development; this is where we are going to spend more than 95% of our development/configurations time.

Interface Format: This is the place where we specify the input layout of our interface, what data will be required by interface, we will specify the tables, infotypes and fields, plus we will do the conversions, restrictions, change validations and other configurations to pick the right data for our interface.

File Layout: In File Layout we will specify the output of the interface, we will specify which fields will be on the output, their widths, their order, and their frequency (e.g. for each employee).

Ideally, we need to generate the Interface Format and File Layout every time we do a change in any of them, so that it generates fresh ABAP code for the configuration and we do not get any error.

Let’s start with an interface name ZRAO and hit ‘create’

You will be asked the country grouping, one important thing; one PU12 interface format is only for one country, if you are dealing with many countries, then you will need to create as many interface formats. And, another important thing … this step cannot be undone or changed later on, if you chose a wrong country then you will have to delete the interface and create it again from scratch. File format can be reused for other countries as it does not require country grouping.

Continue, and you will be asked what data you want to include in the export:

In next step include the infotypes that will be required by the interface:

Then it will ask to give names to the programs that it will generate for the interface format, I will suggest to click on suggest values button, or you can chose a name according to your organization’s standards for the main program and then click on suggest values:

Here is how the interface format should look like now:

Choose the fields that will be required by the interface and remove all unwanted fields, this will be useful in the overall runtime of the interface and also reducing the fields will be good in troubleshooting and debugging, as the code generated will fetch data for all the fields that are included here and if you are debugging through the code then anticipate thousands of lines that you will need to run through …

Select the fields by double clicking and click the delete button to remove them:

I have limited the fields to following:

Configurations in Interface Format:

Table Entries: Here we specify which entries to pick, all of them are self explanatory, and we will chose 2^nd option for both infotypes.

Conversions: These are on field level click on the field and then click on the conversions icon, there are three kinds of conversions that we can do.

Constant conversion will give us a way to convert the values in the infotypes to constant values that we will provide in a table format, lets do a constant conversion on FAMST field of infotype 0002.

Table value conversion looks into a database table for and matches values of infotype field mimicking a SELECT statement’s where clause and picks up the corresponding values. Let’s try it on country field of the infotype 0006.

Through above conversion we will pick up the description of the country from table T005U. Very handy.

User Exit conversion This is where a developer will be involved and code the custom logic, if above two methods cannot give the required conversion. We will need to create a Z program with a subroutine in it, it is important to specify the type of the program as ‘subroutine pool’.

Looks like a funny example, but just for the sake of learning ….

Here is the code inside that user exit:

FORM CHANGE_CITY USING VALUE(P0006) STRUCTURE P0006

CHANGING VALUE(RESULT).

  IF P0006-ORT01 = ‘My City’.

    RESULT = ‘Detroit’.

  ELSE.

    RESULT = P0006-ORT01.

  ENDIF.

ENDFORM.                    “CHANGE_CITY

Restrictions : Here we restrict the records that out interface will fetch from infotypes, it is like a where clause of select statement and only constant restrictions are allowed, we can specify only values here, lets do a restriction on infotype 0006 to get the specific subtype ‘1’. Here is how we do it:

Attributes: A very important place where we specify the general behaviors of the interface:

Few important things to note are … we should select the Interface without payroll if we intend to not include the payroll data in the interface. And … we can change the report category that will be displayed when we run our interface. For details of each option please refer to the SAP documentation.

Change Validation: This is where we will specify the change validations, Interface Toolbox will look for the changes only on the fields specified here and will only export the whole record.

Single Field Validation: This option can be applied at infotype or table level and it verifies that only the changed items are exported instead of whole record. The changed data that is unchanged is replaced with ‘#’ signs and the changed data is replaced with new values.

Delimited: This option will allow specifying if the data is still valid for the current period or not. Interface toolbox will put ‘<” sign for the invalid data for current period.

Key fields: Here we can define a composite key by selecting multiple or single fields of infotypes, which will make it a key and the key fields will be only exported once. This will help us in case we want to export the data for some specific key values just once.

Relationships : If we want to export some fields depending on if we are exporting some other fields then we define relationships, for example click on NACHN and then click on  then select VORNA, and do same for VORNA then click  and select NACHN. This will ensure that whenever NACHN is exported then VORNA will be forcefully exported and when VORNA is exported then NACHN will be forcefully exported.

User Defined Change Validation: Here we can put a user exit and do some logic before we approve the change validation, this subroutine will contain only one parameter which will be used by Interface Toolbox to determine if change validation should be enabled or disabled. A return value of ‘1’ will make it active and ‘0’ will make is disabled and no change validation will be carried out.

Here old data for an infotype is available in OLD_xxxx table and new changed data will be available in NEW_xxxx table and we can put a custom logic to decide on change validation.

This is how our change validation will look after above exercise:

Let’s call it enough configurations on Interface format and let’s go to File Format.

Before that, remember to save the changes in change validations and go to the initial screen of PU12 without saving the changes in Interface Format, sometimes if you save twice, once change validation and then interface format then it will erase the changes in change validation, so I would recommend to save changes only for change validation and then without saving the changes in interface format, generate the Interface Format.

File Layout:

The default output for PU12 is text files and we will need to define a file layout of our exported data.

Give a custom name for the file layout, as a standard I will use the Interface format name and _OUT for file layout name. Hit Create.

Save it, and generate the programs same as we did in Interface Format by clicking the  icon and then suggest values, and then save and generate the file layout.

In file layout we need to understand a following hierarchy:

Blocks are at the top level of the hierarchy and they do not contain any data by them selves, they contain further structures which also do not contain any data, each structure can contain fields which actually contain data in them. It is important to use these as per our logic for the requirement.

First create a Block by hitting  icon.

Give it a name; this block will be processed after processing of employee data. This is another important step to consider, if we go with default value i.e. ‘During processing of employee data’ then multiple lines will be output for each employee. If you want to give the file a header line then select the option that says “begin of file”. It will be repeated once, and the output will be exported into the main export file, we can choose additional 4 files to send the output in, but we will limit our exercise to the most common scenarios i.e. one export file.

Next create a structure:

And then a field lets say EMP_NUMBER

Length of a referenced field will ask in later step a field name to limit the output length to that referenced field. Because of Dynamic value we will chose a field that will populate the data in this field.

In above screenshot you can see I have chosen the field P0002-PERNR so the field width will be picked same as field width or P0002-PERNR field.

In above screenshot I have chosen the global variable &VAR_PERNR which will contain the pernr value of the currently processed PERNR. Current entry makes sure that the record is active.

Field contents can be set using following methods:

A constant value, as it says will replace the contents with a constant value, irrespective of the contents of the infotype.

Dynamic value will get the data from the infotype or the global variables, there are many global variables available, that are available by hitting F4).

A user exit will execute a custom routine and the returned value will be placed in the contents.

Scroll up and this is how it should look like right now:

You can notice that there are a number of places where we can place our custom logic to be processed before and after some steps. Here is a list of their rank for each block.

1. User Exit before (Block)
2. User Exit before (Structure)
3. User Exit (field 1)
4. User Exit (field 2)
5. User Exit (field n)
6. User Exit after (Structure)
7. User Exit after (Block)

All these user exits have common layout and parameters; they can all be programmed in same program file.

Here is an example user exit called from the field level. I have created a field that will contain the weekday of P0002-BEGDA and it will be placed in the field.

I have also shown how to pass an infotype field in user exit. Also another thing to note is that the subroutine has to have 16 parameters, out of which first 15 are input parameters to the form and the 16^th is the return parameter which will replace the contents of the field in file layout.

The first, last and current value columns specify which record of the infotype to pick to pass value for P0002-BEGDA, the first, last or current active record.

Here is the code snippet in the subroutine:

FORM GET_DAY USING P01 P02 P03 P04 P05 P06 P07 P08 P09 P10 P11

                                              P12 P13 P14 P15 P16.

  DATA: L_WEEKDAY LIKE DTRESR-WEEKDAY.

  CALL FUNCTION ‘DATE_TO_DAY’

    EXPORTING

      DATE    = P01

    IMPORTING

      WEEKDAY = L_WEEKDAY.

  P16 = L_WEEKDAY.

ENDFORM.                    “GET_DAY

Create few more fields as displayed in the screenshot below:

Save the File Layout, go back and generate again. It might ask to give program names if you have not done so, click  and click on suggest values.

Now our File Layout configurations are complete, but a real time business requirement might be far complex and involve multiple user exits and configurations. It is time to see the output!

Export Tab

Go to export tab, select first option and provide the interface format name ZRAO in our case, and execute. Give the payroll area and File Layout that should be run right after the Interface format gathers data, in our case ZRAO_OUT.

Export Options:

Very important to consider!

Only Original Periods: This option will suppress the retroactive accounting and the results will be only from original payroll period. If you want to take care of retro changes then un-check this checkbox.

Repeat: If you want to repeat the result of the previous run of interface format then select this option.

Update: This option will update the change log and create the text file on server, if you un-check this option then nothing will change and no file will be generated, useful before doing actual runs.

Display Log: If you want to see the log of the changes done/or to be done then check this option.

Results Analysis:

In first run, notice following, one page down:

See everything coming through, now run the interface again with same parameters

See first name and last name are all hashes, that’s because we have them in change validation and they were not changed since last run and they are replaced with ‘#’. This is change validation in life.

There are many other results that will be self explanatory in the log.

At the bottom of the log there will be statistics:

One pernr was locked so that is not included in the output.

Now go back to initial screen on PU12, select the last option:

Download from TemSe, i.e. Temporary Sequential File:

In TemSe Object, hit F4 and if asked select this option:

Select the latest TemSe file

Give a path to save the file on your system, like c:Results.txt

And execute it …

This will create a text file on your system, which will contain all the results. This is what can be exported to any third party later on through FTP, email or what ever your company wants.

Export History Tab

This is where you can see what was exported in past for any interface format or pernr, this is also a good place to start over … By deleting all results of an interface format you can run the baseline again as if it never happened.