Technical Articles
EC – ECP – integration of PayScale Structure.
We have been using PayScale structure in SAP payroll for many years; you cannot create IT0008 basic pay records without PayScale structure. In the following blog post, I will explore the options of integrating and replicating Payscale Structure from EC to ECP.
Background
SAP’s definition (can be found here) of pay scale structure is that it covers pay aspects which are dependent, for example, on regional, industrial-specific, financial, and time-related factors. It also takes into account the differences between industrial workers and salaried employee’s, as well as circumstances related to pay scale changes.
There are four elements related to the pay scale structure:
- Pay scale type
- Pay scale area
- Pay scale group
- Pay scale level
In Employee Central Payscale Area and Type is created with a suffix of the country it has been created for
Example:
Pay Scale Group is created with a combination of Country, Pay Scale Area and Pay Scale Type
Whereas Payscale level is created with a combination of Country, PS Area, PS Type and PS Group
In ECP we have a restriction of characters and these codes cannot be replicated from EC to ECP directly. Mapping is needed.
Area – 2 characters
Type – 2 characters
Group – 8 characters
Level – 2 characters
Since the values in EC and ECP are not same data will not replicate directly. Instead the values are mapped.
- In Table – T77SFEC_CVPROPS set PAY_SCALE_AREA, PAY_SCALE_TYPE, PAY_SCALE_GROUP and PAY_SCALE_LEVEL to mapping via customer table or identical.
2. Usually, the PS Area and Type are limited in numbers and hence they can be mapped via mapping table T77SFEC_CVMAPC
3. If PS group and level are also limited in numbers then the mapping table can be used similar to PS Area and Type. However, if you have a large number of groups and level then extensibility is an option.
Extensibility allows us to map the custom fields from EC to standard fields in ECP. Instead of replicating values from standard PS group and level field in EC we will use custom fields. These custom fields will hold only the code; excluding the suffix.
Example –
Standard PS group – AUS/QM/Q1/SALARY
Custom PS group – SALARY
Standard PS group – ‘AUS/QM/Q1/SALARY/SA
Custom PS group – SA
Note – Custom PS group and level fields will co-exist with standard PS group and level in job info.
This part of the solution is divided into 4 steps
- Creating a Custom field in PayScale group and Pay Scale level data object
- Creating custom fields in Job Info
- Creating and assigning business rules
- Mapping of custom fields in ECP using the extensibility
Let’s get going
- Creating a Custom field in the PayScale group and PayScale level MDF object.
Pay Scale group-
Configure Object Definition – Pay Scale Group – Add a new field with
- Maximum length – 8 character
- datatype – string
- Required – yes
- visibility – editable
- I have named it as ‘ECP Payscale Group’
- When the PS Group is created update the custom field with exact value used in ECP (Table T510)
PayScale Level – Similar to PS group add a new field with
- Maximum length – 2 character
- datatype – string
- Required – yes
- visibility – editable
- Named is ECP Payscale Level
- When the PS level is created update the field with exact ECP PS level code (Table T510)
2. Creating custom fields in Job Info – add 2 custom fields in job info for ECP codes
Manage business configuration -> HRIS Element -> job info
I have used custom-string4 & custom-string5 as shown above.
Ideally, both these fields should not be editable by end-users; rather the values in these fields will be updated by the business rule. The value of the field can be visible by the HR admin and system admin. Avoid displaying values to employees and managers as it does not serve any purpose. (RBP will have to be updated accordingly)
3. Creating and assigning business rules
I am creating a business rule to update the values in the custom fields based on the Payscale group and level field used in job info. The rule will trigger onChange (can be added for onIT onSave also).
The above rule is for onChange event to be assigned to standard Pay scale group and Level fields in Job info so that whenever the values in the standard field are changed it will update the custom field. A similar rule will be needed for onIt. Make sure the rules are tested.
4. Mapping of custom fields in ECP using the extensibility
The final part of config is to map these custom fields to IT0008 – TRFGR (pay scale Group) & TRFST (Payscale level)
Table – V_HRSFEC_EXTMAP
The last part is to run the replication program for a few employees to see the values replicated correctly in Infotype 0008. If data has been replicated successfully then well done 🙂
To sum it up; there are ways to replicate the payscale structure from EC to ECP. You can either map each value or you can use the extensibility option as covered above. Or you can explore replication BADI also (HRSFEC_B_CE_CHANGE_IT0008); it depends upon the scale of work and how often payscale is added/amended.
If you have any questions; let me know. happy to help.
Regards
Sanjay
Appreciate you for your valuable post ?
Nice ?
Hi Sanjay,
Nice blog.
Apart from avoidance of mapping do you see any other benefits with this approach.
Regards,
Umesh Chaudhari.
Thanks Umesh,
Apart from mapping, I do not see any benefit of these fields.
Based on the business scenario you can use the values in these fields to default pay component or set certain values using business rules. Look at note # 2675587.
regards
Sanjay
Thank for sharing!