Whenever building time off solution it is typically divided into several rules based on each country/time type. What about to find a solution that is easy to manage from end customer and overall simple configuration that covers all possible scenarios.
2. This is how it looks like when adding new entry, as you can see all entries are mandatory but it's easy for customer to fill in these fields:
a) ExternalCode is autonumber so filled automatically
b) country is necessary and it is not possible to continue without country definition
c) seniorityFrom - SeniorityTo are defaulted to 0 and 99
d) create - this is prepared for Recurring/Permanent account - in our scenario we have only recurring accounts so we don't use this
e) ageFrom - ageTo are defaulted to 0 and 99
f) frequence is really important and can be any number, this is used in the rule and will describe there (just keep in mind that you will need it)
g) balance - does it make sense to use it without balance? 😉
3. next step is to change the definition of the Accrual Rule Variables object, for our scenario we need to add another field (age) to use it during the rule definition
4. before going to the rule definition let's prepare the import file for the first use. You can see the data below and how easy/hard is to make some changes or adding new country (it needs additional steps but still easy to configure by the customer). It's easy way to change just one entry or upload more changes at once.
5. Let's focus on the rule
a) first thing we need to is calculation of the seniority
b) next is calculation of the age and storing it in the accrual rule variables object - this is the reason why we added a field in step 3
c) The calculation is based on balance/frequency - this approach allows us to be independent on the periodicity of the time account type e.g. we got and annual accrual rule for Czech Republic (see step 4) and we have balance 25/1 so each year the employee will get 25 days. Another example is for GBR where the calculation is with frequency 12. The GBR time account is with accrual frequency monthly and the calculation will be 22/12 (for seniority 0-2). Simple and easy to understand and very flexible.
d) the lookup table definition is really straightforward, based on the seniority, age and country of the employee (based on JobInfo) we can easily select right balance for each individual.
Is this all? No, it's just an example. What are other topics to cover?
You can build all of them, maybe you will need to make some adjustment to the main lookup table to cover your customer specific requirements but that's all.
Could we use it for different time types other then holidays?
How much time is possible to save with this approach?
We are doing time off for 48 countries and 3 of them have special exceptions that aren't relevant to others at all, what to do?
Any other questions?
- Define custom object with all required customer criteria - for our scenario we need following attributes: Country, seniority, age, frequency and balance
2. This is how it looks like when adding new entry, as you can see all entries are mandatory but it's easy for customer to fill in these fields:
a) ExternalCode is autonumber so filled automatically
b) country is necessary and it is not possible to continue without country definition
c) seniorityFrom - SeniorityTo are defaulted to 0 and 99
d) create - this is prepared for Recurring/Permanent account - in our scenario we have only recurring accounts so we don't use this
e) ageFrom - ageTo are defaulted to 0 and 99
f) frequence is really important and can be any number, this is used in the rule and will describe there (just keep in mind that you will need it)
g) balance - does it make sense to use it without balance? 😉
3. next step is to change the definition of the Accrual Rule Variables object, for our scenario we need to add another field (age) to use it during the rule definition
4. before going to the rule definition let's prepare the import file for the first use. You can see the data below and how easy/hard is to make some changes or adding new country (it needs additional steps but still easy to configure by the customer). It's easy way to change just one entry or upload more changes at once.
5. Let's focus on the rule
a) first thing we need to is calculation of the seniority
b) next is calculation of the age and storing it in the accrual rule variables object - this is the reason why we added a field in step 3
c) The calculation is based on balance/frequency - this approach allows us to be independent on the periodicity of the time account type e.g. we got and annual accrual rule for Czech Republic (see step 4) and we have balance 25/1 so each year the employee will get 25 days. Another example is for GBR where the calculation is with frequency 12. The GBR time account is with accrual frequency monthly and the calculation will be 22/12 (for seniority 0-2). Simple and easy to understand and very flexible.
d) the lookup table definition is really straightforward, based on the seniority, age and country of the employee (based on JobInfo) we can easily select right balance for each individual.
Is this all? No, it's just an example. What are other topics to cover?
- Average FTE
- Rounding of the balance
- Hire rule
- Termination Rule
- PEP rule
- Permanent account 😉
You can build all of them, maybe you will need to make some adjustment to the main lookup table to cover your customer specific requirements but that's all.
Could we use it for different time types other then holidays?
- sure, why not, maybe just add another field with own generic object reference to the time account type
How much time is possible to save with this approach?
- based on the number of countries, if you are implementing 1-2 countries the added value isn't high but when doing more than 10 it has significant positive effect on the delivery of the time off configuration (40 - 70 % less time required)
We are doing time off for 48 countries and 3 of them have special exceptions that aren't relevant to others at all, what to do?
- well, maybe try to incorporate into the rules and if you cannot, you can create second variant of this rule with exceptions
Any other questions?
- SAP Managed Tags:
