General

The data held within the Recruitment module is held in a separate database, as is the data contained within PA and OM. The master data for Recruitment is held in tables (PBxxxx) where xxxx is the infotype number. You can can get the infotype number by using the menu path: System –> Status. You will see the program number which contains the infotype number in the notation.

The Recruitment module within SAP is probably its weakest HR module. Our advice is to only introduce bespoke developments when it is either essential for your business or going to involve very little risk to other parts of SAP. Development items such as bespoke infotypes are fine. Just be wary of modifying SAP standard objects. You may well find that this affects another part of SAP – at some point in the future.

Probably one of the strongest pieces of advice SDS can offer, is to recommend that you get your business processes clearly defined for Recruitment. This should take place as a matter of course during your implementation. These processes which will include both SAP and non-SAP activities should be available to all on an Intranet. It is great to have them on a file server somewhere, but does everyone know where they are stored and does everyone have access to this drive?

The fast entry screen within Recruitment is very inflexible. You can’t use screen modifications on it, as you can with other Recruitment and PA screens. One thing you can do is make use of Transaction and Screen Variants. The transaction code to activate this is SHD0. It is a very useful piece of functionality within SAP. With it you can hide fields, provide defaults, make fields mandatory etc. There is some very useful information on it, just click on the “I” button on the screen at transaction code SHD0.

If you wish to have the email address on the fast entry screen, then you need to ensure that the parameter for MOLGA is set to “00”. This is difficult for many of you who naturally wish to set this value to your own country versions.

You have to have the “vacancy” option turned on if you are using Org Mgt on your SAP system.

Many customers have a key requirement whereby vacancy or position effectively is the central object around which the recruitment process is driven. SAP has some serious limitations in this regard.

The first problem is that everything is geared around the advert. Most of the reports have advert as a selection criteria, but most do not have vacancy or position included as a selection criteria. You can insert vacancy or position as a selection field in the relevant reports. This will involve some additional ABAP development work.

SAP does not provide a typical object type for advert, as it does for org unit, job, position etc. This becomes a problem if you need to bespoke anything within the Recruitment module in SAP. The module does tend to just hang together in a manner which is different to the rest of HR.

If you publish your advert in more than one advertising recruitment instrument, then you have to create a separate advert for each one. This is because the time constraint on advert will only allow one recruitment medium per advert. The fact that advert is not an object in SAP means that to change the time constraint, you would effectively have to modify the relevant programs – which is going down the high-risk road.

You can also not use advert altogether. Make use of the Unsolicited Application Groups on PB10 to channel all your applications through. The downside to this is that you will have to write your own cost per applicant reports.

You can use the transaction code OOPS to default the personnel area and sub-area for recruitment. This would also affect PA as well.

Tip on Configuration for Actions

Remember that when you go into the main configuration screen for Actions in Recruitment called “Change applicant actions”, you don’t see all the columns and values on the screen at the same time. You need to scroll along to the right to see the other columns. One of the most important columns holds the value for the Info Group. This is often missed by users and consultants when configuring the Recruitment module.

Check on Previous Applicants

When entering the initial data for an applicant, the system does a check on first name and surname only. Once you hit the return button it does the check even if you haven’t clicked on the “check previous employee” icon at the top LHS of the screen. It looks for unique matches.

If for example the previous applicant’s name is Sarah Jones:

• Sarah Jones – Will find the match
• Sara Jones – Will find the match
• S J – Will find the match
• Sar Jons – Won’t find the match

The check is only done once you have changed the input fields for both first name and last name and then clicked the return button.

Applicant Groups and Ranges

These pieces of configuration are used essentially to group the different types of applicants in the system. They can be used very effectively in decisions for features and for report selection and output. Many customers are not able to come up with meaningful entries for both fields. It is worth spending a fair amount of time in deciding the values for these fields. They are integral to the Recruitment module and its successful implementation.

Dynamic Actions

Remember that there are a number of SAP standard dynamic actions which are there to assist you. Remember to add to them if you add in, for example, additional action types for Recruitment.

Transaction and Screen Variants

These are very useful in the Recruitment solution for making changes to the screen fields where you either can’t use “screen mods” (table T588M) or else find that the screen is also used by PA which has different requirements. Remember that the feature for each infotype will generally allow you to select on either Applicants(B) or Employees(A).

Default Settings

The transaction code OOPS allows you to set various fields. Try it out, it is quite useful. Remember that setting Personnel Area and Sub-area will set it for your user settings on that client.

Remember that these can also be set in your user parameters. See the document we have in the Knowledge Base on User Parameters. For information, the common fields and parameter settings are:

Personnel Area = PBR
Personnel Sub-area = PBS
Applicant Group = APG
Applicant Range = APR
Country = LND

Transfer of Additional Data for Internal Applicants

If you would like to transfer additional infotypes for internal applicants (PA to Rec) then you can do so by enhancing the user exit ZPAP4CUS. You also need to modify the feature IGMOA. See OSS note 314184 for more information.

Mail Functionality

Mail – Changes to Infotypes

The feature M0001 sends a mail to a user based on specific changes to different infotypes. Refer to the documentation under Personnel Administration which provides more details on how to configure this.

Mail sent after update to Applicant Activity

The feature MAILS can be used to send out an email to various recipients based on changes to different Applicant Activities in Recruitment.

Infotypes available for Recruitment

The following table shows a list of infotypes which are available as standard in the Recruitment module