Fortuna Features Overview
So many options and possibilities that even we, the creators of Fortuna were blown away by the final result!
Assign Wage Types: In this screen you do much the same as in the first step. In addition you need to link the different wage types to your evaluation wage type. You can also tick the checkbox to indicate that the wage type’s sign should change.
Highlight the wage type where you would like the results to appear – usually 402 to start with. Click on the evaluation assignment icon. Create your entry in the table that appears. Go back to the previous screen, select the infotype and click on the generate icon. You will notice the tick on the “generated” column once this has been done. The infotype should also be active. If you are doing this for the first time, you will need to tick the “acitve” box once you have generated the infotype.
Ensure your infotype exists in this table if you wish to have the infotype updated during the course of a payroll run. If you don’t have any data in this table, you can still run the report RPABRI00 to manually populate the infotypes.
Customers often find the use of these wagetypes as being quite limiting because of the way in which they treat retros. There are numerous OSS notes on these wagetypes and the limitations associated with them.
If you wish to delete one employee at a time you can do so using transaction code PU00. If you wish to delete more than one at a time, you can use the report RPUDELPN. Unfortunately, you can only choose single numbers or a range of numbers. There are not further selection screens as is the case on most standard reports. You would have to enhance the report so that it could do this.
If Sometimes you might not be able to delete an infotype for an employee using the delete button on the infotype screen. Another way of doing this is to use the “delete personnel number” from the main screen of PA30. Once all the Infotypesare brought up you can just select the appropriate infotypes and delete those.
SAP has functionality to deal with this. It is relatively straightforward if the employee has no payroll results.
Use transaction code PA41. Type in the correct employee ID and click on the “execute” button. Once in the screen, you can scroll through the events for the employee and select the one you need to correct. Once you’ve found the correct action then you can click on the “execute info group” button.
If the employee does have payroll results then OSS note 41523, spells out what you need to do.
The actual entry date might be before the entered date – for example in the previous month. In this case, you can change the entry date. You must first delete the field ‘Process up to’ in infotype 0003 (Payroll Status) using the auxiliary function ‘Change payroll status’. The payroll results should NOT be deleted. Now with the auxiliary function ‘Change date of entry’ (‘Correct Actions’) change the date of entry into a date in the past. The valid date of the available infotypes is changed automatically. Retroactive payroll run is initialized on the earlier date of entry and the payroll results are corrected.
The actual entry date is after the entered date, for example on the 15th instead of the 1st of a month and also in the following month. In this case, you CANNOT change the date of entry. Payroll accounting would not perform retroactive accounting on the incorrect entry date. Carry out the customising and source code changes, specified in the OSS note.
If you have old redundant payroll areas which hold no employees – then it is wise to take them out of the ABKRS feature, which assigns an employee to a payroll area. You can also restrict users via security profiles where users can only make changes against certain payroll area.
Remember that you cannot use Personnel Sub-Area as a selection criteria in the feature ABKRS, because the feature gets called at the start of infotype 0001 (Organisation Assignment) and at that point, the personnel sub-area has not yet been entered by the user. If you do want to use personnel sub-area you will need to modify the structure of the feature and/or possibly modify the user exits available to you.
If you wish to delete one or more infotypes from a number of employees, you can do so quite effectively using the program RPUREOPN. Enter the employee numbers and the infotypes and sub-types. In the sub-type field you need to enter the infotype name as well – e.g. sub-type 00149035 for sub-type 9035 on IT 0014.
Please see the appropriate documents elsewhere in the SDS Knowledgebase on working with employee photos in SAP version 4.6 or in SAP version 4.7.
Wanting to change the input characteristics for a particular screen on an infotype. You can do so using the menu path in the IMG:
Personnel Management Personnel Administration Customizing User Interfaces Determine Screen Modification
Each screen is linked to a module pool, which has the naming convention MPnnnn00 where nnnn is the infotype number. It is possible that your screen is not in this table T588M – click on new to add it. Each module pool has a screen and an alternative screen. Some screens are dependent on features and variable keys for the feature. The feature has the same name as the infotype and has the letter P in front. Usually the features are used in cases where countries have different requirements.
Double-click on an entry to see the configuration behind the screen. All the possible fields for the infotype are listed.
The fields can have different statuses. The field can be set to the following status:
Std – the field characteristics correspond to the standard setting
RF – the field is a required field – which means that data has to be entered
OF – the field is an optional field – data may be entered
Outp – the field is output only and is not available for input
Hide – the field is hidden from view and therefore won’t be seen on the infotype screen
Init – the screen field is hidden. In addition, the corresponding field content is initialized when you create or copy an infotype record.
Remember that when you go into the table don’t be concerned if the entry that you are expecting is not there. This is normal for certain entries. SAP inserts most of the commonly used values in the table. Just create a new entry to be inserted into the table. You will then be able to modify the entries for that particular screen.
Generally, the screens are controlled by a feature. The feature is named Pnnnn – where nnnn is the infotype number. The variable key in the feature could either be an “A” for PA, a “B” for Recruitment or the country grouping for your particular country.
If you need to be able to hold more than 8 splits for cost centres on this infotype then you need to activate the screen number 2500. Change the feature P0027 to return a variable key of 01 for your employees and make sure that the screen 2500 is set as the main or alternative screen. This will allow the users to enter more than 8 cost centre splits.
To enable this functionality go to the IMG
Personnel Management Personnel Administration Tools Revision
The SAP standard infotypes which hold data for cars are as follows:
- 0442 Company Cars GB
- 0225 Comp. Car Unavail. GB
- 0442 Company Cars (global)
- 0473 Hire Car Preference
The max number of criteria on IT 0025 is 6. If you wish to use more than 6 then you can use the Japanese screen version (with JP in title) – you would need to change the configuration in for the screen modifications – table T588M. Alternatively you could use this one as a template for creating your own customer-specific infotype.
Another option is to change the time constraint on the inftotype which will allow more than 1 instance of the infotype in the same time period.
This infotype is used less and less as customers switch over to entering appraisals on infotype 0024 (where the integration between PA and PD is turned on for this infotype)
It is possible to store an employee’s old personnel number on IT 0031. This is useful for reference purposes if you are migrating to SAP from an old legacy system.
To carry out an increase in a group of employee’s salaries, you need to run the report RPTIUM00. This program looks at all employees’ IT0008, and if there is any of them with a salary increase date within the selection period, a new IT0008 will be created according to their pay scale group via BDC.
Screen headers are relatively straight forward as long as you follow a few simple rules.
It makes things a lot easier and simpler to configure and keep track of at a later date, if you make sure that the Screen Header and Header Modifier have the same number.
Remember to regenerate the screen headers after making any changes.
You can create a personnel sub-area as ” ” (blank) – with the required name. This would effectively default in this object without having to type it in each time. This is quite useful if the majority of your workforce are in 1 particular personnel sub-area. Not always the best option – but something to remember for that particular instance when it might work for your organisation.
You could also write a very simple ABAP on the user exit in enhancement PBAS0001 (transaction code SMOD) to default any values.
You could also use the position details to default in certain attributes.
To configure the Name Format on IT 0002 do the following:
follow the IMG path:
Personnel Management Personnel Admin Personal Data Name Format Define Name Format
All you need to do is modify or add on to the SAP standard entries.
Copy the above entries.
Format needs to be 01 Prefix needs to be 0002 Name Form: Use the next number i.e. 02 as would be the case in the screen print above. Sequence: Start with 01 and advance Field name: refers to the field names found on IT 0002.
|Anred||Form of address key|
Generally leave as blank – see help for specific entries.
Once the new name format has been configured, go back and change the required employees.
Notice that once you change the name format for an employee, it will change the employees header infotypes on the initial screen for maintain and display master data.
Any new employees when taken on, will have the latest saved name format. That would be fine if you configured it before data take-on. What would happen if the customer decided to change the name format once employees had been taken on.
One could write a CATT procedure or write an ABAP program to update the records.
You can also assign the name format to different programs. The IMG path is the step below the name format configuration path.
if you need to view an employees master data record use the “display master data” option (PA20) rather than the maintain option (PA30). Using PA30 will stop another user from updating the record.
It is possible to trigger notifications from any infotype field. The mail can go to one of the administrators defined in infotype 0001. If this does not meet your requirements then you can create a dynamic action which calls a feature which has been created. You can copy the SAP standard feature M001 which is used. The feature then calls an ABAP routine which creates the mail. For more information, see the standard documentation that is associated with the feature M001.
Feature M0001 and M0002 are used in PA (and Recruitment) to let a user know when data for a particular infotype has changed. The features allow you to control who gets sent the email, under what conditions and what is contained in the mail.
The feature is set off with the assistance of a dynamic action. Search through the dynamic action table T588Z to see SAP standard examples of M0001 being used.
You can configure up to 3 users or user groups using the standard features RCNEW, RCIEV, RCOLD. These features are used to assign the user name or user group name – you can copy these features to create your own if you have more than 4 user groups.
You also need to configure the IDTEXT field where the message it assigned. For example, “MAIL_FOR_IT0001_UserA” could be your text message that you want relayed to the users for group A and this has to be assigned here.
You then need to create a standard text for the mail connection. This is then used by the feature and pushed through to the user. The attributes for the standard text are as follows:
Text Name: MAIL_FOR_I0001_UserA
Text ID: PAMA
Here is some sample text that can be used:
Request for processing records for &P0001-ENAME& : &P0001-UNAME& has just modified the Personnel Administrator assignment for &P0001-PERNR& – &P0001-ENAME& , effective from &P0001-BEGDA&.
You can obviously change the above message to suit your requirements. Standard texts can be created usingtransaction code SO10.
Wanting a quick way to see what infotypes are held for a particular employee?
Run the report RPDINF01 and key in the personnel number. Choose a range of infotypes – don’t leave this blank otherwise all the infotypes in the system are processed.
Click on the “brief overview” icon to get a summary list of infotype records for the employee.
Wishing to modify the search area on the left hand side of the screen (object manager)
You might want to add certain search fields such as “find by”
The configuration for this is held in the IMG under: Personnel Management > Global Settings > Settings for Object Manager. All the information that you require is in this node.
The object manager can easily be turned off if you do not prefer to have it on all the time. The setting is using the menu path: Settings Show Object Manager or Hide Object Manager
SAP HR Features
If your SAP version contains the tree maintenance functionality, then do yourself a favour and make use of it. Whilst it may look quite daunting to use, it is so much easier to use than the old table maintenance functionality. Once you have changed, you will regret not having changed sooner.
|08MEX||Multiple Employment Process Exclusion (PY-GB-PS)|
|08TCE||TPS casual employment|
|08TIE||TPS Irregular Employment|
|08TSG||TPS Safeguarded salary|
|08TSN||TPS School / type of employment number|
|08TSS||TPS Salary scale code|
|27SLE||Sick Leave Entitlement|
|ABKRS||Defaults the payroll area|
|ACTCE||Actions: Default Values for Recognition|
|ADDRS||Set subtype sequence for address formatting|
|ALOAN||Default Value for Company Loans|
|ANLAC||Check number of object on loan and asset number|
|ANSAL||>Wage type for annual salary|
|BENGR||First program grouping|
|BSTAT||Second program grouping|
|CATSX||Profile maintenance for Time Sheet|
|CDCU1||Determine payroll directory|
|CONTR||Default values for contract elements|
|COVER||Rule group feature for coverage history|
|COVGL||Define Date for Production Startup of Absence Ref|
|CSSCR||Screen type country assignment|
|DATAR||Default value for date specifications|
|DFINF||Copies default values for infotypes|
|DTAKT||Sender bank account number for DME|
|EDPDF||ESS Remuneration Statement: Smart Form for Conversion|
|EDTIN||Report Variant for ESS Service ‘Display Remuneration Statement’|
|EECGR||Employee Contribution Grouping|
|ENTRY||Rule for determining entry date|
|ERCGR||Employer Contribution Grouping|
|EXCEP||HR-XX: Exception Reporting – Determine Tolerance|
|GAGES||Feature for the AGE Calculation used in Abs. Evaluation|
|GBACT||Activate new GB solutions|
|GBCHG||Solution Change-Over Date (Great Britain) for GB SxP phase I and II|
|GBENA||Determination of employer name for legal reporting|
|GBQDP||SSP Qualifying Day Pattern|
|GCPAB||Stop payment of tax credit|
|GBPGL||Payroll Go Live Date (Great Britain)|
|GLIVE||Feature for the go-live date used in Abs. Eval.|
|GLOSS||Feature for the seniority (LOS) calculation used in Abs. Eval.|
|GLTXC||Tax code for late payments|
|GMSGD||Termination reason for death|
|GNICD||Default category for NI contributions calculation|
|GNICW||Wage type generation for NI adjustments|
|GOFFA||GB SAP Offsetting against OAP|
|GOFFM||GB SMP Offsetting against OMP|
|GOFFP||GB SPP Offsetting against OPP|
|GOFFS||GB SSP Offsetting against OSP|
|GPRPC||HR-GB: Pro-rating pension contributions|
Dynamic Actions in SAP HR
Dynamic actions are really useful in SAP and allow you to automate certain activities between different infotypes. For example, when one infotype is created, another unrelated infotype can be automatically created at the same time and values can be pre-populated from another infotype.
An example of this is that when a maternity absence is created in infotype 2001 the SMP master record in infotype 0088 can also be created without the user having to manually create the infotype 0088 record separately.
Access to the set-up of Dynamic actions is via the IMG in a number of different application areas – search for the text Dynamic Actions. In addition you can modify the table T588Z using the transaction code SM30 for table maintenance.
Each separate process of the dynamic action is held on a separate line number and has an operation specified for that line e.g. check conditions, maintain an infotype, set the value of field(s) within an infotype etc.
Always place a comment at the start of the dynamic action to identify it. A comment should have no value in the Indicator column and should start with an * in the Variable Function part. This makes it far easier to find a specific dynamic action in the table. This tip will make sense once you have configured many dynamic actions for the same infotype. It can be quite difficult to spot a particular dynamic action amongst the many similar ones. This also gives you an idea of what it is supposed to do when you come back to modify it in 6 months time.
If you want to edit the whole of the dynamic action table – use table T588Z in table maintenance. Use this when you start the configuration for the dynamic action and you need to view other examples of dynamic actions against other infotypes.
If you wish to edit a dynamic action for a specific infotype, you can use the view V_T588Z. Once you click on the “maintain” button, you are asked to enter the infotype you wish to use. This then restricts the number of entries to that infotype only.
You may need to find an example of a similar dynamic action and would like to search through the whole table. On certain versions of SAP, the “find” and “find next” buttons are greyed out. A simple work around is to click on the print icon and this then takes you to an overview screen of the dynamic actions table. You will now be able to make use of the “find” and “find next” buttons. Once you have found the relevant piece that you wish to copy, just make a note of it or copy it onto the clipboard and click on the green “back” arrow to be taken back to the maintain table screen.
If you wish to select a piece of text in SAP, it is often not possible if you are not in a particular field or table view. Use the Ctrl + Y buttons to highlight a piece of text which you can then copy onto the clip board.
When you first start configuring your dynamic action – you may find that it doesn’t work 100% – this is quite common. If the dynamic action is not being called at all, then simply comment out your plausibility checks. Once you have the dynamic action correctly bringing up the infotype screen, then you can take off the comments and turn the plausibility checks back on – one at a time. You will then get a better idea as to where it is failing.
In addition if your dynamic action is to work during an action, then don’t put on the TCODE = ‘PA40’ plausibility check until you are happy that it is working to your satisfaction – otherwise you could be creating a lot of new starters. Just have the dynamic action set to transaction code PA30 and once you have it working, change the transaction code to PA40. This will save you a lot of time.
It is important to provide gaps in the numbering between different dynamic actions. A gap of 10 lines is the minimum you should have between dynamic actions. Remember this is not MS Excel where you can just easily insert a row. All of the rows in a dynamic action table are numbered and it is a real pain to insert rows. It is good practice to leave bigger gaps if you can. Use even or odd numbers for your lines of configuration. Even better use every 3rd line. This allows you to insert the odd line or 2 without having to laboriously copy and move all the lines of the dynamic action, which can be a bit of a pain.
If you are wanting the dynamic action to look at multiple values for the same field on a plausibility check, make use of the “/X” at the end of each line for all of the values.
You may wish the dynamic action to take place in the background and not be visible to the user. It is good practice to only put the “/D” in at the very end once you have thoroughly tested your dynamic action and are happy that it works 100%.
Remember that if you find that your dynamic action is not meeting your requirements, you can always get your dynamic action to call a user programme which will be far more flexible than the functionality offered by standard dynamic actions.
If you are writing away values for infotype 0000 Actions then you need to use P0000-xxxx. This is unlikely to happen often as infotype 0000 is always saved first and will in most cases be used to set off other dynamic actions.
If you are wanting to check a certain action type or action reason, then use the field PSPAR-MASSN (action type) and PSPAR-MASSG (action reason).
SAP HR Multiple (Concurrent) Employments
Multiple Employments, or as they are otherwise also known Concurrent Employments, can often be a bit of an Achilles heel for organisations with SAP. There are some basic facts which have been put forward in this page. In addition there are some tips and tricks which you will find interesting and should make sure that if you want a clean SAP system, users adhere to these basics.
There is an object in SAP called the Central Person (object CP) which is used in Multiple Employments. This object is created as soon as you link two employments together via the infotype 0031.
The first thing you will notice with this infotype is that the start and end dates are greyed out. SAP pre-populates these with a very early start date and uses the “high date” for the end date. There will only ever be one infotype record for an employee with multiple employments.
The other thing you will notice is that there is only one field usually showing on the infotype which is for the linked employee numbers.
After entering the employee numbers for the other linked employments (contracts), SAP gives you a message to let you know the name of each entered employee number and the fact that a reference to employee number nnnnnnnn has been created.
After saving your entries, SAP will tell you that certain wagetypes will be copied between the employments.
If any of the new employees already have payroll results in the system, you will be told that certain infotypes e.g. infotype 0009 bank details, infotype 0065 tax details, cannot be copied. This is due to the employees having a date value in the accounted to field on infotype 0003 (payroll status).
You need to make sure that the tax details are correct on all employments before you process the employees throughpayroll. If the employees are linked they should have the same tax codes for the linked employments. This will prevent them from getting more than one tax allowance.
Typically the infotypes that will be copied are:
Infotype 0001 – Organisation Assignment
Infotype 0002 – Personal Details
Infotype 0003 – Payroll Status and other statutory infotypes relating to tax, social security, national insurance etc.
This infotype is without doubt the most important infotype for Multiple Employments from a SAP point of view. If a user makes a mistake on this infotype, the employees could get processed through payroll incorrectly and it can be a real pain to try and correct the data and the payroll results.
You don’t have to have the highest paying post as the main employment. SAP will still correctly calculate the payroll for both employments. Most users will generally make sure that the highest earning post is in fact down as the primary employment.
The trick is to make sure that you don’t keep switching the priority for an employee. SAP should recalculate the correct payroll results, but it is safer to leave the priority as it is, rather than changing it.
It is important that you minimise the changes that have to be made to this infotype for a set of contracts for an employee. The fewer changes you make, the less likely you are going to get this employee’s data in a muddle.
The dates on infotype 121 are crucial. SAP will generally ensure that this infotype is delimited to reflect the changes to the employee’s other contracts. If an employee has a number of multiple contracts (we have seen them go into double figures) then there could be a number of instances of this infotype with different sets of data on it.
The key is to ensure that the dates accurately reflect the situation and that the order is not changed.
If you are starting a new implementation then try and have your secondary employment number lower than your primary because SAP payroll processes the lower number first. If you don’t have them this way around, it is not a problem, but you will end up with more employees to process in your matchcode W payroll run.
SAP keeps certain infotypes in sync with one another. This ensures that the different employees share the same data for certain areas. In other areas, the infotypes are copied with the assistance of dynamic actions. This usually works fine for data entered in the foreground during updates done by users undertaking their normal work. Any changes to one of the employment’s payroll control record (infotype 0003) will then be copied across to the same infotype for the other employments linked to the employee.
This isn’t the case for updates done in the background. This could be for master data updates done via an interface program or BDC session or perhaps a LSMW upload. Check to see whether the values on the payroll status infotype are indeed being updated.
Payroll Simulation for Multiples – future periods where payroll results don’t yet exist
Remember that if you try and run a payroll simulation for a period in which the payroll results don’t yet exist you need to bear the following in mind. You can run a payroll simulation for all the secondary employments, but you will not be able to run the primary employment successfully, as no payroll results exist for the secondary and this will result in an error message.
You should avoid at all costs trying to link employees who are in different payroll areas which have different period modifiers. Linking a weekly to a monthly or lunar for example is not feasible and will cause inaccurate payroll results. You can, however, link 2 employees if they are on different payroll areas but have the same period modifier.
You will notice that you are unable to find the table for PA0031 if you are using SE16 or SE16N. This is because the data held on this infotype is held in a structure rather than a direct table as is the case with most of the other infotypes.
If you are using infotype 0128 (notifications) and have configured your payslips to ensure that you only print out 1 payslip per person (i.e. all the employments results get amalgamated onto a single payslip) you need to be aware that any messages will be added individually to the payslip. This means that you could end up with 4 messages if a person has 4 employment contracts. The trick is to ensure that you only create a message for one of the employments.
Users should be aware that whilst the home addresses for the employee will be the same for employees with different contracts, the work addresses may be different.