In this blog I would like to introduce a new functionality we offer in Employee Central as of 2111  called “Conditional Defaults” and present a business-oriented view on how to implement it along with some practical tips for customers migrating from SAP ERP HCM. We will be publishing this content later on as an Implementation Design Principle on our official channels and and keep the recommendations up to date with the product.

(You should see this functionality be fully available in preview instances earliest as of Nov. 15th)

1         Introduction

With the release 2111 we introduce in Employee Central the feature called “conditional defaulting” which allows companies to configure default values for different HR masterdata fields according to employee organizational criteria and in combination with their employment classification.

Until now, we have allowed for this configuration to be built using Employee Central Business Rules, however this approach would typically require IT to set up each business rule/condition (as business rules   are rather technical in nature and requires knowledge of entity navigation, data model, rule functions, parameters, etc). Also, the pure usage of “if conditions” on business rules for defaulting elements may easily reach a limit for corporations with a big number of locations and with a complex workforce.

With the introduction of the conditional defaulting we allow for, after an initial “technical” setup, an easier approach for configuring conditions while allowing very complex requirements to be accommodated.

You may be familiar with similar functionality (PE03 features/decision trees/Merkmale) existing in SAP HCM / Employee Central Payroll for specific fields of certain infotypes. SAP HCM customers which are migrating to Employee Central will be able to accommodate via the Employee Central Conditional Defaulting the same business criteria which the company had already configured in SAP HCM by translating the business criteria configured in the feature`s tree into condition groups. It is however not possible to simply perform a 1:1 technical translation of the PE03 decision trees into the conditional defaulting structure, which is not a decision tree-based but rather a group-based structure. At the end of this blog we will provide some tips on “translating” the SAP HCM features for defaulting fields into the employee Central structure.

First, let’s have a pure Employee Central view about the conditional defaulting and then look at migrating from SAP HCM aspects.

The Conditional Defaulting is based on the concept of employee and employer groups plus on a combination thereof. For a given masterdata field to be defaulted, let’s say Pay Group (aka payroll area) and for a given combination of an Employer Group assignment and Employee Group assignment there will be a default “Pay Group” value to be assigned to the employee. An infinite number of groups and combinations can be configured. Then, once the employee masterdata is changed (be it during a hiring process or any other change) the masterdata will be checked against the Employee and Employer Groups in order to determine the default value for each field which needs a defaulting.

An Employer Group represents an organizational grouping of the company/corporation. Typically, this is represented by a combination of Legal Entity(ies) and Location(s) in Employee Central Job Information (or Personnel area + subarea in SAP HCM/ECP). In business language, it represents the local employer of an employee.

An Employee Group represents the employment classification of an employee. Typically, this is represented by the Employee Class and Employment type fields in Employee Central Job Information (or employee Group + subgroup in SAP HCM/ECP). In business language, this represents the classification of the employee according to global and then local working conditions, especially related to working-time and pay aspects.

Every Employee Central implementation must have a clear definition of what are the fields that compose the “employer” (organizational) assignment and what are the fields that represent the employment classification in the “succession data model” and this must be valid for the whole instance globally. In fact, these fields will often act as key fields for job information changes with real impact on time and pay aspects of the employee. Changes in at least one of these fields on the employee masterdata will often represent at a minimum an “internal transfer” and are often triggered by position updates or position assignment changes. The four above-mentioned standard Employee Central fields (Employee Class, Employment Type, Legal Entity and Location) should reflect this criterion, however in practice we see that many customers deviate from these standard fields for mainly two reasons:

1. Many customers migrating from an (or integrating with) SAP HCM system will tend to bring the fields Personnel area and subarea as the “employer” criteria (enterprise structure for HR in SAP HCM, table T001P). These fields are then configured in Employee Central by using custom MDF fields on Job Information and they are often implemented as the “leading fields” for HR transactions, meaning that the “EC Location” is derived from a combination of these two SAP HCM/ECP fields. In Employee Central we do “hard code” certain transactions/wizards to start with the Legal Entity, so in practice, we have technically made mandatory the Legal Entity as a leading field, however the location field remains flexible. Therefore, what you often see on implementations is that the Legal entity will restrict the options of available Personnel area + subarea, and the combination of these two will determine/restrict the location. The location then serves as a secondary, rather informative field and not as a leading field.

2. Customers in general (independently if they are migrating from SAP HCM or integrating with SAP HCM/ECP or a 3^rd Party payroll system) tend to disable the fields Employee Class and Employment type (which are technically based on simple picklists and not on Foundation objects/MDF) and replace those with Custom MDF fields on Job Information so that the associations and restrictions can be set up according to the business and country-specific requirements.

As a first step for implementing the conditional defaulting you must identify what are the leading fields for Employer/Employee classification in the given implementation. Often, the existing business rules on job info, and especially the Position to job synchronization will already reflect those aspects (if they don’t, you should potentially review your implementation).

Here is a recap of the fields you may consider defaulting with this new functionality alongside with the existing defaulting mechanism in SAP HCM/ECP. This is not an exhaustive list, but rather a list of fields which will often depend on more complex combinations of employer vs employee groups for which it is worth to use the conditional defaulting:

Employee Central fields	Equivalent defaulting source in SAP HCM
Pay Scale Type and Area	Feature TARIF, in combination with T001P and org infotype 1005
Administrator Group (Sachbearbeiter für PA, Time and Payroll)	Field SBMOD in IT0001 (Admin group)à  Feature PINCH
Holiday Calendar, Time Profile, Time recording profile	Derived from modifiers in Table T001P, Derived from a combination of modifiers of T001P and T503
Default Weekly Working hours, Default Work-Schedule	Feature SCHKZ
Pay Group (Payroll Area)	Feature ABKRS
Contract type, notice periods (employer/employee), probation period, sick pay supplement, sick pay continuation	Feature CONTR

Table 1

To get familiar with the new configuration objects and functionality, let’s look at a business example:

Example for defaulting the Pay Group field in Country US, Legal Entity ABC with Locations A and B for Employment types: externals, regular hourly, regular salaried:

In both locations there are external contractors, internal (regular) salaried employees and (regular) hourly paid production employees. In Location A, the hourly paid employees are paid on weekly payroll, while in Location B the hourly employees are paid on bi-weekly payroll (and processed together with the salaried employees in the same payroll run)

Existing Pay Groups:

• UB: biweekly payroll inhouse for all locations of legal entity ABC
• 99: non-payroll relevant (outsourced)
• UW: hourly weekly payroll inhouse for all locations of legal entity ABC

Representing the above business requirements in our Conditional Defaulting objects would lead to:

Employee Group	Employer Group	Default Pay Group
Regular salaried	Any location of LE ABC	UB
Regular Hourly	Location A	UW
Regular Hourly	Location B	UB
Externals (any: hourly, salaried, commissioned, etc)	Any location of LE ABC	99

Table 2 – In practice, we have seen that for large corporations with complex workforce, the number of groups may be quite large and conditions very complex in contrast to the example above.

With the above setup, the following are examples of expected system behavior during HR transactions:

1. An employee is hired as hourly worker in location A, the pay group UW gets assigned to him/her.
2. The same employee is later transferred to location B (still as an hourly-paid worker) and the pay group is then automatically changed to UB.
3. The employee is later promoted, still within location B, to a position which is pays him/her a salary instead of an hourly wage, the pay group remains UB.

There is a technical setup required to make the example above work and it involves the setup of a “trigger” business rule for those fields of the succession data model which we identified earlier above as leading fields of employer/employee groups. This technical setup is what we consider to be still the involvement of the IT Consultant. The actual conditions, like shown in table 2 above, can be setup by the customer’s business HR or HR Operations.

The “trigger” business rule has no condition/business criteria encoded in itself, rather it just invokes a rule function which will read the configuration in table 2. To cover the exact example above and the point 2 (employee transfers) the consultant would have to attach the trigger rule on the “on change” event of Legal Entity, Location, Employee Class and Employment Type fields of job information. The rule itself will look like this:

Figure 1

The rule will set the Compensation Information.Pay Group field with the return value of the function Get Generic Object Default Value() based on the  “Pay Group” configuration (first parameter on the right-hand side) and based on the data record being changed which contains the “employer/employee group leading fields” (in this case is Job Information – second parameter on the right-hand side)

The Pay Group parameter represents the conditions we saw in table 2. In business language, this rule reads as follows: set the field Pay Group field based on the current employee job information by using the Pay Group defaults configuration.

The example we are using here “Compensation Information.Pay Group” is a data field in “Comp info” of the type “generic object” (aka MDF). For fields with this data type, the rule function Generic Object Default Value() has to be used. For other fields on the succession data model of different type, you have the following additional rule functions:

• Get Foundation Object Default Value
• Get MDF Picklist Default Value
• Get Legacy Picklist Default Value

It doesn’t matter if the field you want to default is a standard or custom field on succession data model. The conditional defaulting will work with both. Notice that once the proper configuration is in place, you will only get the specific rule function listed on the business rule function dorpdown which matches the data type of the field you want to default. This is a consistency check which the system carries out to prevent misconfiguration.

From now on in this document, lets refer to the leading fields as “Condition fields”.

2         Technical Setup

Before continuing please the documentation regarding permissions here: http://help.sap.com/viewer/b14dd15ca58f43e0856184a740a4b212/2111/en-US/006dbc4fde464054ab5151ea73768653.html

2.1         Technical data model mapping

The first technical setup step is to specify the conditional fields (in our example for the Pay Group: Legal Entity, Location, Employee Class and Employment Type) into the object definition of the MDF objects “Employee Group Item” and “Employer Group Item”. This is done via transaction “Configure Object Definitions”. On the Employer Group Item, we need to add the legal entity and the location as condition fields (technically by listing custom fields as shown below)

The “Data Type” and “valid values source” properties must match the ones of the Succession Data Model:

For the Employee Group Item object, we will have:

 

2.2         Condition fields setup

The second step is to enter each condition field into the new MDF object “Condition Field”.

Basically, the same technical specification entered in “Configure object definitions” for the Employer/Employee Group Item objects is entered as above. The system will validate that the same data type/value source are entered according to the object definition given by employer/employee group (entered in field Group Type).

 

2.3         Default Field setup

The third technical step is to specify which condition fields apply to a given masterdata field subject to defaulting. This is done in the MDF object “Default Field”. For our example it will look like this for the “Pay Group” field:

The “field data type” represents the type of the field on the succession data model (in this case Pay Group on Comp.Info is a MDF/generic object) and “field data source” points to the source of valid values for that field (typically the MDF object itself, or a Foundation Object, or a picklist). The fields listed under “Condition Fields” are those we configured in steps 1 and 2.

IMPORTANT: notice that each field to be defaulted can have its own list of condition fields. For example, for a field such as “Bonus Plan” to be defaulted, the customer might specify that in addition to the 4 condition fields above (or in replacement of the “location field”) the field “Business Unit” or “Department” is to be used as a criteria. In practice, you should always try to use the same 4 fields above (or the equivalent at the implementing customer) across the different masterdata fields to be defaulted, or at least for the great majority of them. The reasoning for this is the above condition fields are strongly tied to the contract / legal employment agreement and don’t change on the employee’s records without a proper HR transaction, while fields like “Business Unit”/ “Department” are rather fictitious representation of parts of the company and can be changed/renamed/regrouped without any legal employment impact. Therefore, be careful choosing the conditional fields. Consider that for decades, in SAP HCM it has been enough to use the 4 above-mentioned fields (their equivalent, if thinking about personnel area/subarea, employee group/subgroup) as the criteria for several master data fields and process modifiers.

 

2.4         Rule triggering on job and position changes

The fourth and final step is to set up the trigger rule and call it for changes on the conditional fields in the succession data model.

Our example, the Pay Group, is a field in Compensation Information and typically not present on the position object (no propagation from position to job info). However, all the condition fields (basically what can trigger the defaulting) are based out of Job Information. That means that if the target (to-be-defaulted) field is in Comp-Info you must trigger a “cross-portlet” rule for a Job Info change into Comp Info.

The following trigger X target combinations are possible:

2.4.1        Within the position object

During position creation or update a change of one of the condition fields triggers a change of a position attribute. Common examples are Pay Scale Type, Pay Scale Area and Standard Working hours which should be defaulted on the position object based on the same 4 condition fields of our Pay Group example. This is triggered with an “OnChange” rule on the MDF Position object by calling the rule on the “onChange” of every Position-attribute conditional field.

2.4.2        Within the employee data:

• During hire:
  • a change in a (Job-Info) conditional field triggers the defaulting of a Job-Info field. An example of this can be the defaulting of the Administrator Group (SBMOD, if implemented by the customer) or Work Schedule and / or time profile/recording parameters. This is triggered with an OnChange rule configured at each conditional field. You should attempt to build a single rule which sets all to-be-defaulted fields (avoid creating one rule per default field) and call this same single rule at the onChange of each conditional field. The base object for the rule should be “Job Information”

• • a change in a (Job-Info) conditional field triggers the defaulting of a Comp-Info field. This is our Pay Group example. Another example could be “Bonus Plan”. As we are talking about the Hire Process, remember that the Hire wizard separates the job-info step (where all the condition fields exist) from the Comp-Info step in a wizard mode. That means once you click “continue” on job-info, the job data is frozen, and the Comp-Info screen gets invoked. In this case the rule event “onInit” gets triggered and you can trigger the defaulting with this event so that the default value already appears once the screen is displayed to the user (which is the ideal experience). For this you will need a separate business rule with base object “Employee Information” so that it can be uniquely configured at the onInit of the Comp-Info entity in “manage business configuration” (and not at the onChange of every conditional field of job-info). The rule will look like this:

• During a job change via MSS / Take Action:
  • a change in a (Job-Info) conditional field triggers the defaulting of a job-Info field. This behaves and is set up identically as explained for the hiring example above (where job-info contains the target field to be defaulted).

• • a change in a (Job-Info) conditional field triggers the defaulting of a Comp-Info field. This will require a business rule for the trigger just like the above point (onChange) but with a “set statement” that points to the field in Comp-info just like in figure 1. In fact, you can remain with the same rule created for the hire scenario above and just add a “set statement” to the comp-info field. This kind of cross-portlet change will only take effect if both job-info and comp-info screens are “merged” during the HR transaction. The merge happens if the user selected both the “change job” checkbox along with “change compensation” checkbox at the initial menu (but we cannot rely on this user action). The merge also happens if you set the “refresh compensation required” for each job info conditional field on the data model, and this is our recommendation. See http://launchpad.support.sap.com/#/notes/0002533954 for more info. This basically refreshes the whole screen and “checks” the checkbox “change compensation data” (while merging both job info and comp info on one screen) in case one of the conditional fields changed — even if the user didn’t check the “change compensation” but performed a job change which will for sure impact compensation, for example changing the location or employment type.

2.4.3        From position to job

A field like pay scale type/area must typically be specified at the position and then simply propagated to Job-Info. Such fields should in principle never differ between position and job, which means if an employee really has a location change or employment type change which would impact the pay scale type/area then the change is made by moving the employee to a different position (which ultimately has the target location, employment type, pay scale area/type etc). This means that for these fields, the defaulting should happen at the position and not during take action/job.info changes. Such fields are typically simply propagated from the position to job with a OnChange rule on the Job-info.Position-ID field. So, whenever the employee changes position, then the position data is copied over to job.

A complicating factor happens for fields such as Pay Scale Area/Type, in case the conditional fields from which these depend are changed (or can be changed) directly on Job-Info without moving the employee to a different position: In case of conditional field changes directly on the Job-Info, then the defaulting must happen during the job change while at the same time, the conditional fields are then propagated back to the position.

There are two common major scenarios involving back-propagation of conditional fields. Please discuss these with your customer/business:

• Location change in same legal entity: for employees who don’t work for example in a production plant (e.g. not a fixed plant-position like a machine operator) but rather work in an office / corporate / IT /sales /virtual /home-office environment, the actual Location of the work’s delivery is not strongly tied to the position object. A production plant will have a specific position for a machine operator, and the supervisor of the machine operator position is often in the same plant/building. But an IT consultant can virtually work from anywhere, and the actual physical location of position is not that important for position management. Of course, the official location of work has a legal impact to the employee (holiday calendar, pay scale area, local tax) but it is common that these desk-based professionals may change location as a contractual change. This contractual change will be typically initiated directly on the Job-info MSS and not on the position, and the company wants the new location to be updated back on the position, nonetheless.

 

• Semi-retirement, early retirement: this is a change in employee class/employment type. In general, such changes should only occur for an employee if the employee moves to a different position. However, in the case of (semi/early) retirement, many companies see a chance to reduce the position headcount permanently, which they could not have done otherwise. Such a change may be initiated on the Job-Info and replicated back to the position. The employee remains working on the position for a couple of years until full-retirement and position deactivation.

In order to implement the defaulting of “position attribute” fields (like Pay Scale Area/type) in job-info for situations like above, you may add an IF condition to the trigger rule, to check if the position ID did not change. This requires separating the trigger rule for those specific position-originated-fields.

 

2.4.4        Cross-portlet Position to comp-info and cross-portlet imports

For example, changing the Business Unit or Division of a position must impact the Bonus Plan field which exists only on employee’s Comp-Info and not on the position.

This can be triggered with a OnSave rule on job info in which the IF condition of the business rule checks if the relevant organizational fields changed.

2.4.5        History portlets

A change in Job-Info which should default another Job-Info field will work as usual in the History Portlet/UI with the same setup described for “during a job change via MSS / Take Action”.

However, we don’t recommend setting up OnSave Rules to achieve the Cross-portlet behavior in case a target field is in Comp-info and the change is done via History UI, since the idea of the History UI is to serve as a technical tool to allow data corrections per portlet by Admin Users (managers/business would not have access to it).

 

3         Business configuration of conditional defaults

To understand the full potential of the conditional defaults, lets expand a bit our Pay Group example to a slightly longer but abstract scenario (so that we don’t get lost in complexity):

A company has legal entities and locations in Japan and Australia as follows:

• Legal Entity cloud engine Australia, locations Sidney, Melbourne and Brisbane
• Legal Entity Cloud Engine Japan, locations Osaka, Tokyo.

And the following employee class/employment type:

• (class) Regular
  • (type) Employee (salaried) (Australia and Japan)
  • (type) Executives (Australia only)
  • (type) Worker (hourly/wage) (Australia only)
• (class) Temporary
  • (type) Worker (hourly/wage) (Australia only)
• (class) Externals
  • (type) Employee (Australia and Japan)
  • (type) Worker (Australia and Japan)
• (class) Expatriates
  • (type) Employee (Australia and Japan)
  • (type) Executives (Australia and Japan)

The customer’s business states that the “Pay Group” follows the following criteria:

Sidney regular employee -> Q1

Melbourne regular employee -> Q2

Brisbane regular employee -> QX

Sidney/Melbourne/Brisbane regular executives-> QX

Sidney/Melbourne/Brisbane regular worker ->Q3

Sidney/Melbourne/Brisbane temporary worker->Q3

Sidney/Melbourne/Brisbane external employee ->99

Sidney/Melbourne/Brisbane external worker ->99

Sidney/Melbourne/Brisbane Expatriates employee -> QX

Sidney/Melbourne/Brisbane Expatriate executives -> QX

Tokyo/Osaka regular employee -> J1

Tokyo/Osaka external employee ->99

Tokyo/Osaka external worker ->99

Tokyo/Osaka Expatriates employee -> JX

Tokyo/Osaka Expatriate executives -> JX

You notice that there are only 7 unique Pay Group values in the example above (Q1, Q2, Q3, QX, J1, JX, 99), therefore, it should be ideally possible to reduce the combinations above to only 7 unique combinations.

This is how the Conditional Defaulting would be configured to cover all above cases with only 7 combinations:

Employer Group	Employee Group	Default Pay Group value
Sidney	Regular employee	Q1
melbourne	Regular employee	Q2
japan any location	Regular employee	J1
japan any location	expat-any	JX
Any location	Reg/temp worker	Q3
Any location	external-any	99
Any location	Any workforce	QX

Table 3

Some elements in the group have “wild cards”: like “any location” or “external-any”. This operates during the “condition evaluation” like an “Any” or like an “Else” depending if there is (or if there isn’t) a group in the combination table which is more specified (specified in more details) than the wildcard group for which the combination pair (employerXemployee group) could not match. We will see detailed examples to understand this later.

The configuration objects (managed in transaction “mange data”) can be seen below. The object “default group” (top-left) represents the table 3. Each line-item (default group item) contains the 3 columns you see in table 3 (employee group, employer group and default(return) value). Each employer/employee group can contain several line-items. The line items contain the actual condition fields (location, legal entity, etc). The line items conditions fields can be left blank/empty to represent a wildcard (any/else). you must start configuring the decision tree from the bottom. The picture below shows the configuration for the “Q1” combination (first row in table 3)

The picture below shows the 3^rd line of the table 3. Notice that a wildcard is used for the location: japan any (the conditional field location is left blank):

The figure below shows the 5^th row on the table 3. Notice that the employee group “worker” has two items, and the “external workers” are not part of that group. Notice also that the “any locations” employer group is represented by a line item with both legal entity and location left blank.

Based on the above pictures, the rest of the configuration of the table 3 example can be guessed. Here is a summary for the rest:

• Employer group Melbourne: one item with legal entity CE-AUS, location Melbourne.
• Employee group Externals: one item with employee class “External” and employment type = blank.
• Employee group Expatriates: one item with employee class “Expatriate” and employment type = blank.
• Employee Group Any Workforce: one item with employee class “= blank and employment type = blank

Based on the above configurations, an employee with the masterdata in each of these test cases will lead to the following default pay group result:

test case number	legal entity	location	employee class	employment type	Resulting default pay group value
#1	CE AUS	Sydney	Regular	employee	Q1
#2	CE AUS	Melbourne	Regular	employee	Q2
#3	CE AUS	Sydney	Temporary	worker	Q3
#4	CE AUS	Sydney	External	worker	99
#5	CE AUS	Sydney	Expatriate	employee	QX
#6	CE JPN	Tokyo	Regular	employee	J1
#7	CE JPN	Tokio	Expatriate	employee	JX

Table 4

Now let’s have a closer look at the any/else behavior of the wildcard groups and categorize the (employer/employee) groups into 3 categories in relation to the match of the condition fields against the group:

• ME: matches explicitly.
• MW1: matches via wildcard (the matching group item had a wildcard), but the match is a primary match (see below what primary match means)
• MW2: matches via wildcard (the matching group item had a wildcard), but the match is not a primary match

The term “primary match” means the match is the best option in terms of “condition pairs” (table 3). It is easier to understand what this means by examining the below table 5, which combines the test cases number of table 4 with the match categories:

Test case number	Employer group match result	Employee group match result
#1 & #2	ME	ME
#6	MW1	ME
#3	MW2	ME
#7	MW1	MW1
#4	MW2	MW1
#5	MW2	MW2

Table 5

The table 5 tells us, that if the employee has data from test case #1:

legal entity	location	employee class	employment type
CE AUS	Sydney	Regular	employee

Then, the resulting employee/employer groups matched “explicitly” criteria and the Q1 value is found. But if the employee has data from test case #4:

CE AUS

Sydney

External

worker

Then the employer group matches as a non-primary match (see line-item 6 of table 3): the only employer group that can be matched (for test combination with employee conditions external-worker) is the “any location” although the location Sidney would be a more explicit match for the employer group alone (if ignoring the employee group). So, Sidney would be a primary match, but can’t be used in combination with external-worker and only the non-primary match “any location” can. On the other hand, the employee group matches as a primary match (with wildcard): again, see line-item 6 of table 3. For the combination of the two mentioned matches, the value 99 is found for the pay group.

 

4         Considerations for SAP ERP HCM customers migrating to Employee Central

In SAP HCM there are a few specific PE03-Features in which the conditions for the defaults are specified. these conditions are rather specified in a decision-tree structure. Perhaps, the easiest way to bring these conditions to Employee Central, is to list the content of the feature in a spreadsheet, while already logically classifying the conditions into employer group, employee group and default value (for each default field / feature) .

for example, the feature ABKRS example we deliver in client 000 would look like the following when converted to logical groups (restricting our example to Germany and Switzerland):

Employer Group	Employee Group	Default Pay Group value
Germany – any location	Monthly wage earner; industrial civ. Serv.	D1
Germany – any location	Any workforce	D2
Germany – any location	Sales personnel	99
Switzerland – any location	Hourly wage; home work station	C1
Switzerland – any location	External employee – no wage	C9
etc	etc	etc

IMPORTANT: if your company is present in many countries, consider using the job-info field “country-of-company” as criteria for the employer group.

The above example is rather simple. You will find more complex situations on existing implementations, especially when inside a “otherwise” node you have a complex sub-tree with different conditions fields. For example, in the above example instead of having “otherwise: D2” we had “otherwise: then for a list of specific locations in Germany, then for each location a complex combination of employee group and subgroup (again with otherwise inside). This makes the exercise of creating the conditional table with employer/employee groups more difficult, as you need take into consideration what was the original “otherwise” (or all otherwise on the way) representing before the more fine-granular and explicit conditions are specified. and translate the condition as a whole.

For very complex existing feature implementations in SAP HCM, it may be a good idea to review the existing decision tree conditions with the business as they may provide a more simplified view of how things should look like and therefore making it easier to adopt the employee and employer groups conditions.

One final aspect worth mentioning is about how the configuration we did in the chapters regarding “technical setup” (especially in employee/er group item, condition field & default field) is represented in SAP HCM. in SAP HCM, each feature (e.g. ABKRS) has a data dictionary structure assigned to it with the list of all possible fields from the employee data model which can be used as a condition. this structure / fields-list is hard-coded and cannot be changed by the customer:

The customer can however restrict which of the fields the structure are eligible for actual usage in the decision tree for a particular feature:

The above is found on the attributes of the feature in transaction PE03 and helps to give you an idea what are possible fields that will be used in conditions (although in many cases, even when they are listed as above, they may not be actually used in the decision trees, so please double-check that).

In general, you will find that all features share the common fields: MOLGA, BUKRS, WERKS, BTRTL, PERSG and PERSK which represents in Employee Central Language those fields that we consider to be employer group (MOLGA, BUKRS, PERSA, BTRTL) and employee group (PERSG and PERSK). Refer to chapter 1 for the equivalents in Employee Central.

In some cases, customers use event reasons (action type, reason) to determine default values in SAP HCM in the features. if that is the case, we recommend to discuss with the business if it is possible to find a logical condition based on employee and employer groups.