Ad Blocker Detected
Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker.
Key fields to note when modifying an infotype are:
- Time Constraints
- Sub types obligatory
- Text allowed
- Retro Accounting Relevant
- Available for Recruitment
- Assign infotypes to countries
- Infotype, subtype (* or 0010), country grouping (08)
- Permitted, not permitted or warning (radio buttons)
It is useful to place the infotype number in the text. E.g. Organisation Assignment becomes Organisation Assignment 0001 or 0001 Organisation Assignment
The reason for this is that it helps users get to know the infotype number as well as their names. Some users will prefer to work with the numbers or the text but it generally makes it much more efficient if users get to work with both. It may seem like a lot for users to remember, but users will tend to use certain infotypes far more frequently than others and tend to remember all the details about these quite easily.
Menus and user groups – you can have different ones for different user groups in your company. User dependency must be ticked in this case.
Reference – default user group which is used if the user does not have the UGR parameter set in his/her user parameters.
User group set to infotype with sequence of infotypes to display. – It is worthwhile configuring only 10 infotypes per tab otherwise you have to scroll down to the 11th one – it is hidden from the initial view.
As is the case with infotype menus, you can set up actions to behave differently for different sets of users. This you can do so by using different user groups.
Menu, infogroup modifier, infogroup, user group – It is good practice to ensure that the Action Type and Infogroup have the same name. This makes it generally easier to track and modify during the configuration set up and for ongoing maintenance.
Always make sure that the flag to update infotype 0000 (U0000) is ticked, unless of course you specifically dont want to update infotype 0000.
As with other pieces of configuration in PA, the user group used in this area is crucial to the way in which the system is configured.
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 doesnt work 100% (he he). 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.
In addition if your dynamic action is to work during an action, then dont 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.
When maintaining dynamic actions make sure that you always put in a comment or two at the start of the dynamic action, so that you will have an idea of what it is supposed to do when you come back to modify it in 6 months time.
It is important to provide gaps in the numbering between different dynamic actions. A gap of 10 lines is the minimum you will need to 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 you lines of configuration. Even better use every 3rd line.
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.
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.
You can use the report RHINTE00 to update the Org Mgt data from PA records. It is possible for a data migration exercise to update the employees PA data without updating the necessary information in Org Mgt. This report will allow you to make the necessary updates.
Choose the employees and the necessary objects to create. Run it in Test mode first. Click on the Selection icon. This creates a batch input session which you then need to run.
All of the RHINTE… programs are quite useful in maintaining the integration between PA and OM. See the reports section to get an idea of all the RHINTE programs and their use.
If you can only remember part of a table name or the text relating to a table name – then go to table maintenance viatransaction code SM30 and click on the pull-down (F4). The first 500 entries (defaulted) are shown. Click on the down arrow found above the list and fill in the search variables. Remember to use the wildcard * as a search variable. Remember that some searches in SAP are case sensitive, so if you are unsure as to whether the first letter is uppercase of lowercase, just leave that letter out of your search parameters.
If you are unsure of the table name, go to the screen holding the data. Right-click the field and then click on the Technical Info icon. Double-click on the Structure field – you should be able to see which “check table” is associated with the field.
If you know the table that has to be configured, go to table maintenance area (SM30/SM31) and click on the “customising” icon – after inserting the table name. This takes you to the IMG and to the step where the actual piece of configuration is carried out. You can select a project or just choose the skip option if you are unsure.
It is wise to check the overall view on the tables summarising the above groupings. You should easily see whether any values have been omitted. This is good practice once you have created any new groups or areas.
Personnel Sub-Area: Complete View – V_001P_ALL
Employee Group/Sub Group: Complete View – V_503_ALL
When entering the personnel number in any of the PA… transaction codes, you can use the following shortcuts in the personnel number field. Each of the letters corresponds with a different search help. There are normally only 4 that get defaulted as search helps for PA. To get to see the others choose any of the letters e.g. =h. and hit enter. You will be given an output of possible values. Click on the white/yellow icon with small lines to see all the possible search methods. Each letter corresponds to a different search method. The first one on the list corresponds to “a”, the second to “b” etc etc.
- =a.900 offers any employees whose personnel number begins with 900
- =n.smi offers any employees whose surnames begin with smi
- =n.smith.ca offers any employees whose surname is Smith and whose first name begins with Ca.
- =g.1980 offers any employees born in 1980
- =k.xxx offers any employees in personnel area xxx
- =r.xxx offers any applicants with applicant number xxx
Standard SAP only allows you to link a loan type to payroll areas with the same period parameter. So if you have different period parameters, you may have to create more loan types. You can modify the standard SAP program RPCERL00 to get around this problem.
Feature DFINF controls this input. The feature has either a X or a blank returned against each infotype listed. The X ensures that a new infotype created, uses the customised settings, whilst a blank entry implies that certain values are defaulted from the infotype copied.
The infotypes for which this feature can be used are:
- Actions (0000) – treated differently to the remaining infotypes
- Organizational Assignment (0001)
- Planned Working Time (0007)
- Basic Pay (0008)
- DUEVO (0020)
- C.Pay: Funds Procedure (0189)
- C.Pay: Assignment (0192)
- DA/DS Statistics DK (0204)
- Time Sheet Defaults (0315)
If you wish to change the name of an infotype, you can do so using the following path. In the IMG follow the path:
Personnel Management Personnel Administration Setting up Procedures Infotypes Set up Infotypes
The required table is T582A. The changes will result in a warning message “Please do not make any changes: This is SAP data”. You can, however, save the changes.
You can access the fast entry screen for data input using transaction code PA70. The menu path is: Personnel Administration HR Master Data Fast Entry
You can enter data using the fast entry screens for the following infotypes:
- Recurring Payments and Deductions (0014)
- Additional Payments (0015)
- Notifications (128)
- Company Car Unavailability (225)
- Absences (2001)
- Attendances (2002)
- Substitutions (2003)
- Availability (2004)
- Overtime (2005)
- Absence Quotas
- Atttendance Quotas
- Employee Remuneration Information (2010)
When entering the data, you can choose one of 4 methods to select the data:
1. Entering the personnel numbers in the fast entry screen
2. Manual pre-selection
3. Pre-select using the report RPLFST00 which offers the usual SAP standard selection screen
4. Pre-selection using Ad Hoc Query
You can save the records directly or save them as a batch input session. The number of records should indicate which method you use. Having chosen the batch input method, you would need to use transaction code SM35 to progress the batch input session. You can create the entries with or without a proposal. Creating entries without a proposal will result in you having to type in all the required data (amount, number and rate) for each individual employee. If you use the create with proposal option, you enter the start and end dates, the wage type and the amount, number and rate. On the next screen, you will notice that the data you entered, has been populated on each row for all the personnel numbers selected.
You can also use the fast entry screen to delete, change and lock any number of records.
You can hold payroll results in infotypes 402. You can either create entries in table T52IF which will then allow infotype 402 to be updated for each employee after the payroll run. Alternatively you can run the report RPABRI00 to the write the payroll data to the infotype. Should you wish to delete the payroll results from this infotype, you can do so using report RPABRIDD.
Before you can populate these infotypes, you need to carry out some config. Look in the IMG under the menu path:
Personnel Admin Personnel Management HRIS Payroll Results
The evaluation wage type is the name of the field – note it is not the actual wage type. The cumulation can be either M (Monthly cumulation), Q (Quarterly cumulation) and Y (Annual cumulation). If you are wanting to save the results on IT 0402 then you can leave this blank. These 3 values probably relate to infotypes 0458 (Accounting infotype), 0459 (Quarterly Cumulation) and 0460 (Annual cumulation). The text you enter in the field “Evaluation WTT Text” will be seen on the infotype. Choose either an amount or a number for the wage type.
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 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).
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.