With over 25 years in SAP Human Capital Management, Danielle is a recognized leader in HR technology. She holds the distinguished roles of SAP Mentor and SuccessFactors Confidant, and serves as HXM Chairperson for ASUG (America's SAP User Group). Danielle is a sought-after speaker at international conferences, sharing insights on HR tech trends. She has authored four best-selling books on SAP and holds certifications in both SAP and SuccessFactors technologies.
Over the years, I have visited hundreds of SAP HCM customers and have seen nearly as many different configurations of personnel and employee structures. I pay close attention to these structures because they play a crucial role in SAP HCM and Payroll reporting. If you have created HCM reports or queries in SAP, you understand how the employee and personnel structure configuration can impact report selection criteria (as shown below), and ultimately your ability to produce the reports that you need.
One of the key foundational components of an SAP HCM system is the personnel structure design. The personnel structure in your SAP system defines the organization from an employee’s point of view. It is designed to segregate and delineate different types of employees into categories for uses such as reporting, payroll, benefits, time management, and shift planning. This structure drives the core HR and payroll functionality of each related component of SAP ERP HCM.
As I mentioned above, over the years I have seen many different methods for configuring the key personnel structure elements like employee groups and employee subgroups. In many older SAP HCM implementations, customers felt that the employee group and subgroup fields were the only place to store employee-related descriptors and they would classify employees for reporting. Many used the employee group field to capture the employee’s status with the company (e.g., active, terminated, or on leave) and then used the employee subgroup field to describe the employee (e.g., salaried FT, hourly, or union). This approach limited customers’ classification and reporting options and failed to capitalize on existing SAP functionality designed to capture the employee’s status. SAP recommends the configuration as detailed in the image below.
It’s important to note that for reporting purposes, the employee group and employee subgroup fields are intended to be used in conjunction with the employee status fields delivered by SAP to define all attributes of an employee.
Note: If your system is set up according to the old design method, I am NOT proposing that you change it. There is no harm in using the old methodology and I have worked, quite successfully, at many organizations that use this design. It is also important to note that there are many consequences to changing your personnel structure configuration once you are already using an SAP system. These classifications drive almost every key area of your application and cannot be easily changed midstream.
SAP delivers three standard fields, visible on infotype 0000 Actions, that store the status of an employee. See the image below for an example.
The Customer Specific Status field (P0000-STAT1) is the appropriate place to store each of the status assignments that are unique to your organization. In this field, you designate if an employee is active, on paid leave, terminated, on strike, suspended, etc. This field’s value is updated each time an action is processed for an employee as set in the IMG (for example, new hires are set to ‘active’ and employees on leave are changed to ‘on leave’).
The values for the Employment Status field (P0000-STAT2) are delivered by SAP and should not be modified. The four standard options are 0 Withdrawn, 1 Inactive, 2 Retiree, and 3 Active. This value is also updated each time an action is processed for an employee as set in the IMG (for example, new hires are ‘3 Active’ and employees going through the retirement action are set as ‘2 Retiree’). These classifications serve as a primary payroll driver and should be designed and modified only by the payroll team.
The third status field is called the Special Payment Status and offers three options: 0 No entitlement, 1 Standard wage type, and 2 Special wage type. As an example, processing an employee through a severance action may change their Special Payment Status to ‘2 Special Wage Type’. This ensures the amount calculated for their future pay runs is the severance amount and not the basic pay. These values serve as key drivers of the payroll (whose values and configuration are owned by the payroll team) and, like the Employment Status field, should not be modified.
If you are not currently using the Customer Specific Status field, it is easy to turn it on and it does not have a negative impact on your current processing or payroll. You can define these Customer Specific Status fields via the IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions > Create Customer-Specific Status. The configuration is simply two fields. They are Status Number and Name that you will see when you select the New Entries button (see picture below).
Before diving in, work with senior management at your organization to understand which classifications are most important to them. For example, do you need to easily identify employees:
Some samples of statuses are shown in the configuration screen below.
Now that you know how to add the new field, you may also want to see some best practice design suggestions for configuring your actions and for how to best leverage the Customer Specific Status field outlined here. For more information, please check out my blog titled “How to design your HR Actions better to improve your HCM Reporting”
© 2024 EPI-USE Labs
Trafford House, 11th Floor, Chester Road, Stretford, Manchester, United Kingdom, M32 0RS •Other Office Locations
Leave a Comment: