Absence Eval Config

Version: 2.
0
Date: January 2004
Release: 46B onwards
Author: Gordon Rennie
Absence Evaluation
Configuration
OxP Configuration Explained
History
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version
Status
(starting with 1.0)
(Draft/Review
Released)
[1.0]
[2.0]
[Draft]
[Final]
Version: 2.0
Date: January 2004
Date
copy/
(DD.MM.YY)
[14.12.03]
[26.01.04]
Page 1 of 61
Absence Evaluation Configuration OxP Configuration Explained
Contents
1 Organisation............................................................................................6
1.1 Project Team/Development Team...................................................................6
1.2 Project Plan.....................................................................................................6
1.3 Development Requests...................................................................................6
1.4 Important Note for Readers.............................................................................6
2 Absence Evaluation Terminology.........................................................7

2.1 Absence Evaluation........................................................................................7
2.2 Absence Evaluation Schemes.........................................................................7
2.3 The Reference Period.....................................................................................8
2.4 The Payroll Structure COVER.........................................................................8
3 Absence Evaluation Configuration (The Basics).................................9

3.1 Legislative Rules.............................................................................................9
3.2 Employers Rules............................................................................................9
3.3 SAP Rules......................................................................................................9
4 Absence Evaluation Configuration (The Detail)..................................9

4.1 Scheme Definition.........................................................................................11
4.1.1 Planning the number of schemes that you will need..................................11
4.1.2 When an employees scheme is derived....................................................11
4.1.3 Moving Between Schemes.........................................................................11
4.1.4 Defining your schemes...............................................................................12
4.2 Scheme Attachment......................................................................................15
4.2.1 Feature COVER.........................................................................................15
4.2.2 Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_CVR).........................15
4.2.3 Infotype Absence Scheme Override (0572)..............................................15
4.3 Scheme Rules Based on Age & Seniority.....................................................16
4.3.1 Age Calculation..........................................................................................16
4.3.2 Seniority Calculation..................................................................................16
4.4 Defining your Scheme Rules.........................................................................18
4.4.1 Scheme Rules............................................................................................18
4.4.1.1 Minimise the number of schemes............................................................18
6 23 months Sick 2...............................................................................18

4.4.1.2 No Gaps and No Overlaps......................................................................19
4.4.1.3 Exclusive Range Ends............................................................................19
4.4.1.4 Period of Validity.....................................................................................20
4.4.2 Entitlement Bands......................................................................................21
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 2 of 61
4.4.2.1 Entitlement Amount.................................................................................21

4.4.2.1.1 Entitlement Time Units.........................................................................21
4.4.2.2 Absence Grouping..................................................................................23
4.4.2.2.1 What does Exact Absence Grouping Only mean...............................24
4.4.2.2.2 How is an Absence Grouping attached to an absence subtype?..........24
4.4.2.3 Payment Band........................................................................................24
4.4.2.3.1 Ordering Payment Bands.....................................................................25
4.4.2.4 Reference Period....................................................................................25
4.4.2.5 Non-Qualifying Days...............................................................................25
4.4.2.6 Warning Period.......................................................................................26
4.5 Checking your Scheme Rules.......................................................................27
5 Absence Evaluation Configuration (Part Days).................................28

5.1 Activating Scheme Part-Day Processing ......................................................28
5.1.1 Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_MIN)...........................28
5.2 Activating Absence Subtype Part-Day Processing .......................................28
5.2.1 GPNAB .....................................................................................................28
5.2.2 XNAB ........................................................................................................29
5.3 Part Day Payroll Processing .........................................................................29
5.3.1 XNAB ........................................................................................................29
5.3.2 GPNAB .....................................................................................................29
5.3.3 Complete & Part Day Payment Bands.......................................................29
6 Absence Evaluation Configuration (Activation)................................31

6.1.1 Absence Evaluation via XNAB...................................................................31
6.1.2 Absence Evaluation via GPNAB................................................................31
6.1.3 Why should I use GPNAB, when XNAB is available?................................32
6.2 Absence Evaluation simulation.....................................................................32
6.2.1 Absence Evaluation during payroll.............................................................32
6.2.2 Absence Evaluation during reporting..........................................................32
6.2.3 Absence Evaluation during Master Data....................................................32
6.2.4 MP200000 Screen 2008............................................................................33
6.2.5 Testing your implementation......................................................................33
7 Absence Evaluation Configuration (Payment)...................................34

7.1 Updating Counting Classes...........................................................................34
7.2 Creating Wage Types...................................................................................34
7.3 Part-Period Factoring....................................................................................34
8 Absence Evaluation Configuration (Complexities)...........................35

8.1 Linking Absences..........................................................................................35
8.2 Reference Periods........................................................................................36
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 3 of 61
8.2.1 Normal Definitions......................................................................................36

8.2.2 From Where Rules.....................................................................................37
8.2.2.1 Actual Absence.......................................................................................37
8.2.2.2 Employee Anniversary............................................................................38
8.2.2.3 Calendar Anniversary..............................................................................38
8.2.2.4 Absence Recording.................................................................................39
8.2.2.5 Customer-Specific...................................................................................39
8.2.3 How Far Back/Forward Rules....................................................................39
8.3 Waiting Days.................................................................................................40
8.4 Non-Qualifying Rules....................................................................................41
8.4.1 By Default..................................................................................................41
8.4.2 Employee-Based........................................................................................41
8.5 Entitlement Limits .........................................................................................43
8.5.1 Using the Entitlement Limit Fields..............................................................44
8.5.2 Defining an Entitlement Limit......................................................................44
8.5.3 Overriding an Entitlement Limit..................................................................44
9 Appendix 1.............................................................................................45
9.1 Non-payment Days.......................................................................................45
9.2 Public Holidays.............................................................................................45
9.2.1 Public Holidays that reduce entitlement.....................................................45
9.2.2 Public Holidays that do not reduce entitlement...........................................45
9.3 OxP Processed and Held in Hours................................................................46
9.4 Customer-Specific Time Units.......................................................................46
9.5 Customer-Specific Rollback Methods...........................................................46
9.6 Customer-Specific Linking............................................................................46
9.7 Customer-Specific Entitlements....................................................................46
10 Appendix 2 .........................................................................................48
10.1 OxP Messages............................................................................................48
10.2 Message Class HRPSGB_ABS..................................................................49
11 Appendix 3 ..........................................................................................53
11.1 Dependencies between OxP-delivered table entries...................................53
11.1.1 Payment Bands........................................................................................53
11.1.2 Time Units...............................................................................................53
11.1.3 Absence Groupings..................................................................................53
11.1.4 Reference Periods...................................................................................53
11.1.5 Non-Qualifying Rules...............................................................................53
11.1.6 Schemes..................................................................................................54
11.1.7 Scheme Rules..........................................................................................54
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 4 of 61
11.1.8 Non-Payment Rules.................................................................................54

11.1.9 Entitlement Limit Rules............................................................................54
11.2 OxP delivered table entries.........................................................................54
11.2.1 Payment Bands........................................................................................54
11.2.2 Time Units...............................................................................................57
11.2.3 Absence Groupings..................................................................................59
11.2.4 Reference Periods...................................................................................59
11.2.5 Non-qualifying Rules................................................................................60
11.2.6 Schemes..................................................................................................60
11.2.7 Scheme Rules..........................................................................................61
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 5 of 61
Organisation
1.1
Project Team/Development Team
Name
Company
Project Role(s) / Comments
Gordon Rennie
SAP AG
[Author]
Maureen Gregory
SAP UK
[Product Manager]
Gordon Rennie
SAP AG
[Software Developer]
Lee Roberts-Baldwin
SAP AG
[Information Developer]
1.2
Project Plan
The OxP solution has been delivered in 46B onwards
1.3
Development Requests
There have been no particular Development Requests regarding Absence Payment

documentation or guidance for customising Absence Payments. However, there are an
increasingly substantial number of OSS messages as more customers try to use the new
functionality that made the creation of this document desirable.
1.4
Important Note for Readers
This document is one of a series of three describing statutory (SxP) and occupational (OxP)
absences in greater detail. SAP strongly recommends that you also consult the other
documents in this series:
Absence Evaluation DTO: OxP Data-Take-On
Paying SxP and OxP: Payment and Offsetting Explained
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 6 of 61
Absence Evaluation Terminology
2.1
Absence Evaluation
Absence Evaluation is SAP terminology for a customer operating an Occupational

Sickness/Maternity/Adoption/Paternity Scheme (collectively known as OxP) to control the
payment of their employees while they are absent from work due to a Sickness, Maternity,
Adoption or Paternity absence .
2.2
Absence Evaluation Schemes
Absence Evaluation Scheme is SAP terminology for a customers rule set that governs how
an Occupational Sickness/Maternity/Adoption/Paternity Scheme is operated.
In most cases, customers will have similar rules determining how these schemes operate.
Example A:
Sickness Absence Rule
An employee is entitled to three months full sick pay and three months half sick pay in any one
year.
This normally implies that if an employee is sick, the previous 12 months are checked to see
whether the employee has already had three months at Full-Pay and three months at Half-Pay.
If they have, then the employee has exhausted the entitlements to Sick Pay and will move to
Nil-Pay. If the employee has had no sickness in the last 12 months, then the employee will
receive the FULL entitlement.
Example B:
Maternity Absence Rule
An employee is entitled to two months full maternity pay and then three months half maternity
pay for any period of maternity leave related to the same pregnancy.
This normally implies that if an employee takes maternity leave, then only the period related to
their current pregnancy is checked to see whether the employee has already had two months at
Full-Pay and three months at Half-Pay. If they have, then the employee has exhausted the
entitlements to Maternity Pay and will move to Nil-Pay. If the employee has had no maternity
leave related to their current pregnancy, then the employee will receive the FULL entitlement.
Example C
Adoption Absence Rule
An employee is entitled to three months full adoption pay and then three months half adoption
pay for any period of adoption leave related to the same matching certificate.
This normally implies that if an employee takes adoption leave, then only the period related to
their current adoption is checked to see whether the employee has already had three months at
Full-Pay and three months at Half-Pay. If they have, then the employee has exhausted the
entitlements to Adoption Pay and will move to Nil-Pay. If the employee has had no adoption
leave related to their current adoption, then the employee will receive the FULL entitlement.
Example D
Paternity Absence Rule
An employee is entitled to one weeks full paternity pay for any period of paternity leave related
to the same pregnancy.
This normally implies that if an employee take paternity leave, then only the period related to
their current pregnancy is checked to see whether the employee has already had one weeks
Full-Pay If they have, then the employee has exhausted the entitlements to Paternity Pay and
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 7 of 61
will move to Nil-Pay. If the employee has had no paternity leave related to the current
pregnancy, then the employee will receive the FULL entitlement.
2.3
The Reference Period
All the examples above relate, to some degree, to checking a period of history for used
entitlements. This Reference Period can be absence-specific or employee-group-specific, and
will strongly dictate the nature of a customers approach to Absence Evaluation configuration.
2.4
The Payroll Structure COVER
The data that is checked during the Reference Period is located on the Payroll Structure
COVER, which is part of the Payroll Cluster PCL2, which itself is based on, and stored in,
annual calendars.
Therefore, customers must fill the Payroll Structure COVER with the correct information in the
correct manner in the Reference Period. This would be a complex and difficult task, unless
SAP provided some sort of tool and methodology to fill the Payroll Structure COVER in the
Reference Period.
The SAP-delivered tools and methodology for COVER are discussed in greater detail in the
accompanying Absence Evaluation DTO document (see Section 1.4).
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 8 of 61
Absence Evaluation Configuration (The Basics)
3.1
Legislative Rules
There are no legislative rules that govern OxP. Rather, OxP is a collection of business rules that
govern the additional absence payment that employees receive in excess of SxP.
SxP is mandatory, and customers cannot choose to pay less than this statutory minimum
amount. It is rare that customers can categorically say that their OxP solution pays in excess of
SxP in all possible scenarios. The complex rules of SSP linking mean that OSP rules cannot
easily imitate SSP. Therefore, it is sensible for all customers to operate both solutions at the
same time. This is despite the fact that SSP is not recoverable for most of the SAP customer
base, as the Percentage Threshold Scheme only applies to small employers.
3.2
Employers Rules
The employer rules that govern OxP can be very complex. The one year in four rule is a good
example of the complexity of rules for OSP (Note 451821):
183 Full-Pay in a year should be paid, as long as the employee has not had 365 days
Full or Half-Pay in the last 4 years.
182 Half-Pay in a year should be paid, as long as the employee has not had 365 days
Full or Half-Pay in the last 4 years.
This means that the solution has not just one set of entitlements to check, but in fact two.
Currently, the OxP solution can support up to two sets of complex entitlement limits for every
Payment Band.
For this reason, the OxP customising solution can be quite complicated. To make this process
simpler, the IMG is ordered in a Top-Down approach:
a) Most customers will only need to customise the very highest level (Scheme & Scheme
Rules).
b) Some customers will need to customise down to the next level of complexity (Reference
Periods & Payment Bands).
c) Very few customers will need to customise from the very base of the solution (Time
Units & Part Days).
3.3
SAP Rules
The SAP absence component will always calculate the SxP payments due to an employee by
operating the SxP legislation via the payroll function GBSXP. Even if customers were to opt for
SSP Easement, the system will still calculate SSP. Therefore, if the employer were under audit
by the Inland Revenue at any time in the future, then the SSP payment information would be
readily available.
Absence Evaluation Configuration (The Detail)
The only complex part of OxP configuration involves determining your organisations business
rules, so that they can be applied correctly. If you do not have specific business rules, then you
will not be able to apply them during OxP configuration.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 9 of 61
The business rules necessary for absence processing in Payroll GB breakdown as follows:
1) Employee-Group-Specific
i. Employee Groups (Company Code, Location)
ii. Pay Frequency (Calendar days, Working Days, Working Hours)
iii. Contract Type (Permanent, Fixed-Term, Casual)
2) Employee-Specific
i. Age
ii. Seniority
3) Absence-Specific
i. Sickness
1. Monthly, Weekly, Daily or Hourly entitlements
2. Part-Day absences are allowed
ii. Maternity
1. Weekly Entitlements
2. Part-Day absences not allowed
iii. Paternity
iv. Adoption
It is important to realise that although your business rules will usually be broken down into these
three levels, this does not mean that your schemes should be broken down to this level. For
instance, scheme rules will tend to vary as above, but there is no reason to create four different
schemes for the four absences that will apply for one specific employee group. Normally, one
scheme per employee group will suffice.
The rules that are age- or seniority-specific are always catered for within a scheme. There is no
need to differentiate at scheme level when this is possible within a scheme.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 10 of 61
4.1
Scheme Definition
4.1.1
Planning the number of schemes that you will need
It is important that you review your existing scheme rules so that you can get a feel for how
many employee groupings you have and how the different types of employees in those
employee groupings will be handled.
For example, you may have two areas of your business that were historically distinct and so
have radically different rules (they may even have different company codes). This will
immediately mean that you will need two separate schemes.
Inside those two schemes you may have many different types of employees: Monthly, Weekly
and Hourly paid staff (Permanent, Fixed-Term and Casual contracts). This normally means you
will need a total of six separate schemes.
Furthermore, on a technical level, it may also be necessary to split those six schemes even
further if there is the need to attach different settings within those schemes. For example, within
one group of employees there may be two distinct groups of employees; one that should have
pro-ration for part timers and one that should not.
4.1.2
When an employees scheme is derived
An employees scheme is derived on the start date of the absence record that is being
processed. This is not read from the infotype Absences (2001) record, but from the payroll table
AB that is subject to WPBP splits.
If there is a change in an employees scheme (from scheme A to scheme B) due to an
organisational change, then this change will take effect part-way through an absence as the
WPBP split will cause an AB split. But if there is no split in infotype 2001 and WPBP, then the
employees scheme will remain constant for the duration of the payroll period that is being
processed. The only way to make sure that this does not happen is to use the infotype Absence
Scheme Override (0572) to ensure that the employee is subject to the old scheme for the
duration of their absence.
4.1.3
Moving Between Schemes
If an employee has to move from one scheme to another, then whether or not the system will be
able to handle the move automatically depends on how similar the two schemes are:
If the new scheme gives the employee new entitlements to a new absence type,
then this will be handled correctly.
If the new scheme gives more entitlements for a specific payment band than existed
in the old scheme for a specific absence type, and the employee has not already
moved to a lower payment band, then this will be handled correctly.
For all other cases, it is unlikely that the solution will automatically handle the
migration.
The reason for this is that the reference period that is checked for used entitlement was
generated under an incompatible rule set. The new rule set will not take this into account and
the reference period cannot be re-generated using the new rule set because this would mean
the employee would be paid differently during retroactive payroll.
There is no simple solution to this problem.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 11 of 61
The only way to ensure that migration between schemes is handled correctly is to use infotype
Absence Scheme Override (0572), so that the employee receives the correct new entitlements
for the duration of their absence. This must continue until enough history has been used on the
new entitlements to complete a whole Reference Period.
4.1.4
Defining your schemes
Define your scheme identifiers and your scheme names (up to 30 characters). The scheme
name is very important as it will be the main way that users will identify the scheme in infotype
2001 and infotype 0572.
As explained above, the schemes should be identifiable with a specific employee grouping.
Absence specific schemes should not be necessary.
Scheme Definition (T556E) is an international table.
Scheme Constants (T5GPBS29) is an multi-national table (Great Britain and Ireland currently).
The additional Scheme Constants (T5GPBS29) provided for a specific scheme are as follows:
1) Nil-Pay Default
This should be used by ALL customers.
This is the default payment band used when an employee has run out of all their
entitlements. Normally, an employee will move to Nil-Pay when this happens and so
the field has been called Nil-Pay Default. However, any payment band can be used,
as long as it has been customised to be used as a Nil-Pay Default payment band in
table T5GPBS27.
If a Nil Pay Default payment band is not specified, then when the employee runs out
of entitlement, the remainder of the absence will receive the absence payment that
was defined by the absence subtype (T554S).
2) Part-Day Processing
If an employee is absent for less than a whole day, then how should the absence be
treated?
There are several solutions available, but generally there are only two that are
widely used:
a) That Part-Days are not processed.
In this solution, the absence is completely ignored. The part day
absence is not processed and retains the absence payment that was
defined by the absence subtype (T554S).
b) Part-Days are processed and reduce entitlement by half a day if the
absence is for longer than, or equal to, half of the employees planned
working time for that day.
In this solution, the absence is either be completely ignored [the partday absence is not processed and retains the absence payment that
was defined by the absence subtype (T554S)], or the absence reduces
the employees entitlements by half a day.
3) Entitlement Weeks Processing
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 12 of 61
If you have employees who receive payment based on working days (not salaried),
then their payment rates will be based on working days and their part period
factoring will be based on working days.
In this case, their entitlements should only be reduced on working days. This can
easily be achieved via a Non-Qualifying Rule (see below). However, the problem
arises when one group of employees have the same entitlements, based on
working days, but have different working days.
For example, two employees are entitled to 2 weeks absence at full pay. However,
the two employees have different working days. One works for one day per week
and the other works for five days per week. If both are sick for seven days
consecutively, then it is logical that both employees should have one week left at
full pay.
To help with this, SAP has delivered an entitlement unit called Entweek (E11). For
the employees above, if they had been given two weeks entitlement, then both
would receive 14 days payment. But if they had received two Entweeks entitlement,
then one would receive 2 days and the other would receive 10 days.
But how much entitlement does an employee with one Entweek actually have? This
is defined by the options in this table.
There are several solutions available, but generally there are only three that are
widely used:
a) Entitlement Weeks are not used in the scheme.
b) Entitlement Weeks are defined based on the employees infotype Planned
Working Time (0007) data, and specifically on their working days
(WKWDY).
c) Entitlement Weeks are defined based on the employees infotype Planned
Working Time (0007) data, and specifically on their working hours
(WOSTD).
In this way, the number of hours entitlement is defined by the weekly working
hours multiplied by the number of Entweeks entitlement.
This option will be used for employees that are paid on an hourly basis and that
record absences on an hourly basis. If you use this option, then you should also
use the feature GENTT to activate holding and calculating an employees
entitlements in hours (rather than days a would be done normally).
If you use Entitlement Weeks, then changes in the definition of an Entweek at
employee level will imply that the employees entitlements will need to be pro-rated.
This will happen automatically.
4) Part Time Processing
This will be used by only a small percentage of customers.
If two employees have the same terms and conditions, but one works part-time and
the other full-time, then it is possible to reduce the full-time entitlement to obtain the
part timers entitlement equivalent.
The reason that this is normally not necessary is that most part-time employees
work a reduced number of days or hours and so can be handled using the
Entweeks options detailed in the previous section.
However, some customers will have additional needs that can be resolved by the
use of this field. The entitlements of a full-time employees are those that are
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 13 of 61
specified in the main scheme rules. The part-time employees are then identified and
have their entitlements pro-rated, based on this field.
Therefore, this field has two functions, namely: to identify part-time employees and
to pro-rate the full-time entitlements to obtain the part-time entitlements.
There are several solutions available, but generally there are only two that are ever
used:
a) Compare in days and factor in days.
b) Compare in hours and factor in hours.
The base hours/days are taken from table T510I and the employees hours/days
are taken from their infotype Planned Working Time (0007) data.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 14 of 61
4.2
Scheme Attachment
After you have defined all your schemes at the highest level, it is then necessary to attach them
to those employees for which they were created.
4.2.1
Feature COVER
For the majority of employees this will be possible using the decision fields of the Feature
COVER, to correctly identify a scheme with a particular employee. These fields are:
BUKRS
4.2.2
Company Code
WERKS
Personnel Area
BTRTL
Personnel Subarea
PERSG
Employee Group
PERSK
Employee Subgroup
MOLGA
Country Grouping
TRFAR
Pay Scale Type
TRFGB
Pay Scale Area
TRFGR
Pay Scale Group
TRFST
Pay Scale Level
Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_CVR)
Unfortunately, it is also likely that you will have to use the customer exit provide due to
incomplete Personnel Administration groupings you defined during your implementation. The
customer exit overwrites the definition of the feature.
For example, if you have 1000 employees that should be split equally between two schemes,
but they are in the same employee group as far as your Personnel Administration groupings are
concerned, then you can use the feature COVER to give all 1000 the same scheme and the
customer exit will only have to overwrite that definition for the 500 employees that should go into
the other scheme.
4.2.3
Infotype Absence Scheme Override (0572)
The infotype overwrites the definition of the customer exit. As a very last resort, you can use the
infotype Absence Scheme Override (0572) to dictate which scheme an employee is in at start of
an absence.
However, it is far better not to use infotype 0572 if a all possible.
NOTE:
This solution is meant to be automatic, requiring no manual intervention. Defining
employee rules based on an infotype is contradictory to the whole design principle upon
which the solution was developed.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 15 of 61
4.3
Scheme Rules Based on Age & Seniority
The majority of customers will positively discriminate on the basis of how long an employee has
been employed with them. (That is, their entitlements will increase with increased seniority.)
Some customers will positively discriminate on the basis of an employees age and entitlements
increase as employees get older.
Both these types of rules require that the employees age and seniority can be derived
accurately at any given date, normally the absence start date.
However, there are multitude of customer-specific rules that can be related to choosing this
given date and what period of time is considered in the calculation.
4.3.1
Age Calculation
How an employees age is calculated is normally quite simple. The start date of the time period
is always taken from the employees birth date recorded on infotype 0002.
The end date of the time period can be taken from any of the following:
The absence day being processed
The absence start date
An anniversary date in the calendar year derived using the absence start date
An anniversary date in the calendar year derived using the absence day being
processed
These four options are defined using the feature GAGES, but almost all customers should use
the pre-delivered setting of 2, regardless of whether their rules positively discriminate by age
or not.
4.3.2
Seniority Calculation
How an employees seniority is calculated is not normally as simple as for the age calculation
discussed in 4.3.1.
Some customers will have a seniority calculation that is based on type of absence and the type
of employee. There may be special rules for career breaks, suspension/industrial action or reemployment.
The International Seniority Calculation functionality has been incorporated into this solution to
provide a complete and total solution for all cases. However, it is not feasible to describe all
possible seniority scenarios. Instead, this document covers the simpler scenarios of which there
are many.
The start date of the time period can be taken from:
The first hiring action
The most recent hiring action
The hire date according to the International Function Module HR_ENTRY_DATE.
A specific date type recorded on infotype 0041
The end date of the time period can be taken from:
The day of the absence being processed
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 16 of 61
The start of the Maternity Pay Period (MPP) (GB Maternity)
The Expected Date of Birth (GB Maternity)
The Expected Week of Childbirth/Confinement (EWC) (GB Maternity)
The Qualifying Week (QW) (GB Maternity)
A calendar date (DD.MM)
(Absence start date)
A calendar date (DD.MM)
(Absence day being processed)
(exclusive continuous linking)
(continuous linking)
The 11th Week before the EWC (GB Maternity)
The start of the Adoption Pay Period (APP) (GB Adoption)
The Matching Week (MW) (GB Adoption)
The start of the Paternity Pay Period (PPP) (GB Paternity)
The QW/MW (GB Paternity)
The type of calculation used between these two dates can be a simple duration or a
comprehensive Seniority Calculation (See the IMG section under Personnel Administration ->
Evaluation Basis -> Calculation of Employment Period.)
These three sets of options are defined using the feature GLOSS, but the most commonly used
setting will be CBE, as follows:
C: The start date is defined by the international functionality of the feature ENTRY to
derive the employees hire date.
B: The end date is defined by the absence start date.
E: The calculation is simply the number of days, weeks, months & years between the
start and end date.
Example for Feature GLOSS
An employee is hired on 01.06.2003 and takes sickness absence on 24.08.2003. If CBE has
been customised, then the employees seniority is:
0
Years
Months
12
Weeks
84
Days
Note that the 23 days beyond the two month anniversary in August have no effect. The
employee has only been employee for two whole months not three months. (The 2.74 months
are not rounded up.)
So seniority ranges (and age ranges) must be defined as inclusive for the start and exclusive for
the end. So this employee would fall into a 0 2 month seniority range and not the following 3
6 month range.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 17 of 61
4.4
Defining your Scheme Rules
The View Cluster provided to maintain your scheme rules is V_T5GPBS23_CL, accessed via
transaction SM34.
The rules are attached to a scheme at two levels:
1) Scheme Rule
i. Age Range
ii. Seniority Range
iii. Date Range
2) Entitlement Bands
i. Entitlement Amount
ii. Absence Grouping
iii. Payment Band
iv. Reference Period
v. Non-Qualifying Days
4.4.1
Scheme Rules
The first and higher level for attaching rules to your schemes is based on a one-to-many
relationship. The rule number field simply supports the one to many relationship. It does not
imply an order in which the scheme rules must be applied. All rules will be applied, but only the
rule that has the matching Age, Seniority and Date Range will be processed.
Each scheme can have many ranges of seniority and age.
4.4.1.1
Minimise the number of schemes
It is important to realise that these scheme rules will need to incorporate all your various
seniority (and age) ranges for the entire scheme.
Therefore, if your Maternity rules are based on:
0 11 months Mat 1
12 999 months Mat 2,
but your sickness rules are based on:
0 5 months Sick 1
6 23 months Sick 2
24 35 months Sick 3
36 999 months Sick 4,
then you can define one scheme broken down as follows:
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 18 of 61
0 5 months Sick 1 & Mat 1
There is NO need to have two separate schemes.
4.4.1.2
No Gaps and No Overlaps
The available time units are DAYS, WEEKS, MONTHS and YEARS. You can only mix time
units DAYS and WEEKS. You cannot mix MONTHS and YEARS because there are situations
where gaps and overlaps will appear. Therefore, choose one time unit for all your ranges. If you
do have overlapping ranges, then an employee who has an overlap and is absent during that
overlapping period will receive the following error message during infotype 2001 and payroll
processing:
Absence Collision: &1 has more than 1 days entitlement, check absences
This message can also occur if you have overlapping absences, though this will be a much rarer
cause of the problem. The message implies that more than one complete day of entitlement is
being used due to overlapping rules or overlapping absences.
4.4.1.3
Exclusive Range Ends
The seniority and age ranges have a start and an end. The start is very simple to understand,
the end is not so simple. Due to the nature of the seniority/age calculations, the ranges cannot
overlap and should not include the upper limit.
Example
If your rules state in the first 12 months of employment an employee will receive.
Then most people would translate this to a range of 0 12 months and probably the next range
would run from 12 - ??? months. But these two ranges overlap. An employee with 12 months
seniority will receive both sets of entitlements. The range should be defined as:
0 11 months and
12 - ??? months
This will mean that in the first year of service the employee will be in the first range, and from
then on they will be in the second range.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 19 of 61
4.4.1.4
Period of Validity
The start date and end date of a scheme rule will define exactly when a rule comes into effect.
This will not depend on an absence start date or on any other customer specific definition of
when a rule should come into effect.
If the date range split is 01.01.1990 05.04.2003 and 06.04.2003 31.12.9999, then an
absence that overlaps the 5th and 6th of April 2003 will have a different set of rules part-way
through that absence.
This may not be how customers may wish the solution to react, but it is how all of SAPs date
ranges are designed to react.
The only way that the entire absence can continue to receive the old set of rules for the duration
of the absence is to define an Absence Scheme Override infotype for the period of the absence
for every employee that has an absence that overlaps the changeover date. In this way, you
ensure that the correct entitlements are used.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 20 of 61
4.4.2
Entitlement Bands
The second and lower level for attaching rules to your schemes is also based on a one-tomany relationship. The sequence number field simply supports the one-to-many relationship.
It does not imply an order in which the Entitlement Band will be processed.
Each seniority, age and date range can have many entitlement bands. An entitlement band is
an amount of entitlement for a specific type of absence (i.e. Maternity) that will be paid at a
specific payment rate (Full-Pay), that will have a specific reference period that checked for
already used entitlements and may have non-qualifying days. Optionally, a warning period can
also be assigned to each Entitlement Band.
There is also one other type of rule that can be attached to an entitlement band (Entitlement
Limit rules), but this is not widely used and is discussed in Appendix 1.
4.4.2.1
Entitlement Amount
The Entitlement Amount defines the maximum amount of entitlement that can be received
during the reference period.
The amount field is very simple to understand. The time units are not so simple.
4.4.2.1.1
Entitlement Time Units
In some cases, because your business rules state that entitlements should be defined in one
time unit, this does not mean that you should actually use that time unit. Some time units seem
suitable in theory, but are impractical.
The time units used in OxP configuration are defined in table T538A, but are filtered for specific
use during the OxP configuration in table T5GPBS28.
The uses available are;
a) Entitlement
Scheme Rules (V_T5GPBS23_CL)
b) Rollback
How Far Bck/Fwd Rules (V_T5GPBS21)
c) Multiplier
Multipliers (V_T5GPBS24)
The recommended time units used for entitlement are Weeks (011) and Entweeks (E11). The
possible time units are:
1. Weeks (011)
The number of calendar days in a week is a mathematical certainty. This makes comprehension
very simple for the business as whole. It is important that Weeks (011) are used:
1) Without a Non-Qualifying Rule
2) For employees paid on a calendar day basis
If weeks are used with a Non-Qualifying Rule, then the whole principle of what a week stands
for has been changed. A week will become employee-specific, depending on which days qualify
or do not qualify.
EXAMPLE
An employee is given 5 weeks entitlement and their 5 working days per week reduce that
entitlement. If a colleague has the same entitlement, as they do a very similar task, but only
works 4 days a week, then either their entitlement will have to be adjusted using the Part
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 21 of 61
Timer rules in T5GPBS29, or they will need a separate scheme to give then 4 weeks
entitlement, where only their working days reduce that entitlement.
Therefore, using a Non-Qualifying rule with Weeks (011) will naturally imply that more schemes
need to be defined to cater for all the different varieties of Non-Qualifying Days for your
employees. This increases the overhead for initial configuration and on-going maintenance.
2. Entitlement Weeks (E11) defined as the number of working days (IT0007-WKWDY)
The number of entitlement days in an Entweek is dependent on the number of working days in
the employees Work Schedule. This makes comprehension rather complex for the business as
whole. But once the initial idea has sunk in, the concept is very easy to understand and adapt to
the daily processes of the business, far better than any other Entitlement Unit.
It is important that Entweeks are used:
1) With a Non-Qualifying Rule based on the employees non-working days
2) For employees that are paid on a working day basis.
EXAMPLE
An employee is given 5 Entweeks and their 5 working days per week reduce that entitlement.
Therefore, in total, they have 25 working days of entitlement. If a colleague has the same 5
Entweeks, as they do a very similar job, but only works 4 days per week then there is no extra
configuration necessary as that 5 Entweeks will only entitle them to 20 working days
entitlement.
The additional benefit of Entweeks is that they are automatically pro-rated if an employee
changes their work schedule!
3. Entitlement Weeks (E11) defined as the number of working hours (IT0007-WOSTD)
The number of entitlement hours in an Entweek is dependent on the number of working hours in
the employees Work Schedule. Again, this new concept will initially be difficult to grasp.
However, you can also easily adapt it to your business processes.
It is important that Entweeks are used:
1) With a Non-Qualifying Rule based on the employees non-working days
2) For employees that are paid on a working-hours basis
EXAMPLE
An employee is given 5 Entweeks and their 35 working hours per week reduce that entitlement.
Therefore, in total they have 175 working hours worth of entitlement. If a colleague has the
same 5 Entweeks, as they do a very similar job, but only works 25 hours per week, then there is
no extra configuration necessary as that 5 Entweeks will only entitle them to 125 working hours
entitlement.
Again, the additional benefit of Entweeks is that they are automatically pro-rated if an employee
changes their work schedule.
4. Days (010)
Days (010) can be used with minimal side effects as long as you are using Calendar Days for
part period factoring and absence payments for this group of employees in payroll. If you are
using working days for part period factoring and absence payments for this group of employees
in payroll, then Days (010) has exactly the same problem as Weeks (011) (see above).
It is important that Days (010) are used:
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 22 of 61
2) For employees that are paid on a calendar day basis

5. Hours (001)
Hours (001) can be used in conjunction with feature GENTT set to X and the multiplier set to
0.041666. This give a close approximation to an accurate solution, but even this remains
problematic:
a) Minor rounding issues will appear as the multiplier should really be 0.041666 recurring,
not 0.041666 exactly.
b) Using hours necessarily implies that you must set up scheme rules for groups of
employees based on the number of hours that they work in a week. This will necessitate
a very large number of schemes, as you will have to cater for all the different work
schedules that an employee may have.
c) Employees who are substituted by other colleagues with a different work pattern, or
employees who change their work schedule require a complete recalculation of their
entitlements.
Also, hourly entitlements can be catered for accurately by having employees Entweeks
configured as a multiple of the number of Planned Working Hours.
6. Months (012)
Months (012) can be used with the multiplier set to 30.00000 or 31.00000, but even this will
produce problems. The definition of 30 or 31 days in a month is not practical.
How does someone without any technical business knowledge know how many days there are
in a month?
Months (012) can be used with minimal side effects as long as you use Calendar Days for part
period factoring and absence payments in payroll. If you are using working days for part period
factoring and absence payments in payroll, then Months (012) has exactly the same problem as
Weeks (011) (see above).
It is important that Months (012) are used:
2) For employees that are paid on a calendar day basis
4.4.2.2
Absence Grouping
An Absence Grouping defines which absence subtypes will reduce this entitlement band.
The absence groupings are defined in table T5A4P. The SAP-delivered groupings are GG, .M,
MM, PP, .S and SS. The first character is used for SxP and the second character is used for
OxP. For an absence to reduce the entitlement of the same absence grouping, the second
character must exactly match. The Exact Absence Grouping Only checkbox deals with
whether or not the first character has to match as well as the second. This is discussed in the
next section.
If you need to create your own absence groupings, then ensure that you do not use G, M, P or
S as the first character, as this will imply that the absence is subject to SAP, SMP, SPP or SSP
respectively.
The simplest way to check that the Absence Groupings have been set consistently across all
your rules is to use the Scheme Overview pushbutton.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 23 of 61
4.4.2.2.1
What does Exact Absence Grouping Only mean
SAP intends that the GBSXP solution will cater not only for all the statutory absence legislation,
but also for the business requirements surrounding part-day absences and Data-Take-On
(DTO). At that point, the differentiation of absence subtypes as being non-ssp-able or nonsmp-able will become obsolete.
Currently, however, you must load absences using subtypes with .S and .M attached to avoid
problems in the first live payrolls you run. This means that the Sickness Absence grouping
should not only include SS absences, but also .S absences used for DTO. In this case, the
Exact Absence Grouping Only checkbox should be left blank because an exact match checks
both characters, while an inexact match checks the second character only.
4.4.2.2.2
How is an Absence Grouping attached to an absence subtype?
Absence Groupings are attached to absence subtypes as the absence subtype is created (or
copied) in Table T554S. The field ABSTY defines the Absence Grouping.
The view V_T554S_GB_PS can be used to display and change the Absence Groupings of your
absence subtypes.
It is vitally important that the correct Absence Grouping is attached to the correct
absence subtype.
The OxP solution ignores any absence subtypes without an absence grouping or with an
absence grouping that has a space or a full stop ( or .) as the second character of the
grouping.
4.4.2.3
Payment Band
The payment band defines what kind of payment the employee will receive if they receive that
Entitlement Band.
The payment bands are defined in table T554L, but are filtered for specific use during OxP
configuration in table T5GPBS27.
The uses available are:
Complete Payment Day
Scheme Rules
V_T5GPBS23_CL
Part-Payment Day
Part Day Rules
V_T5GPBS25
Non-Qualifying Day
Non-Qualifying Rules
V_T5GPBS22
Waiting Days
From Where Rules
V_T5GPBS20
Non-Payment Days
Non-payment Rules
V_T5GPBS26
Nil-Pay Day
Scheme Constants
V_T5GPBS29
How the payment bands will actually effect payroll is defined in table T554C.
It is important to realise that one Payment Band can be used for many employee groups
( Weekly and Monthly paid). The Absence Modifier (Modifier 0A in table MODIF) can vary the
payroll customising for each specific grouping. The payment band should only be broken down
into Absence type and Payment type.
The simplest way to check that the Payment Bands have been set consistently across all your
rules is to use the Scheme Overview pushbutton.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 24 of 61
4.4.2.3.1
Ordering Payment Bands
The payment bands must be ordered, if an absence grouping contains more than one payment
band.
If Sickness absences are paid at 100% and 50%, then the sequence number is not used to
choose which payment band will take priority. It is the Order of Priority field decides which is
first; where the lowest is first. In this case, 100% should have Order of Priority 1 and 50%
should have Order of Priority 2.
If you do not ensure this occurs, then the payment bands will be processed at best out of
sequence, or in a random sequence if you use the same Order of Priority for all the payment
bands in an absence grouping.
This order restriction does not extend to other Scheme Rules, just to the one that is being
maintained currently.
The simplest way to check that the Order of Priority has been set consistently across all your
4.4.2.4
Reference Period
The reference period defines which period of absence history will be checked for used
entitlements.
The reference period is defined by a From Where rule (T5GPBS20) and a How Far Bck/Fwd
rule (T5GPBS21). The combination of these two will define a window of history that is checked
for used entitlements.
RECOMMENDATIONS
Sickness absences normally have a 12 month reference period ending on the day
before the absence starts, but also include the days of the absence that are being
processed.
The From Where rule defines the point in history as being the absence start date and
the How Far Bck/Fwd rule defines one calendar year. The reference period will include
the current absence and the previous twelve months.
Maternity, Paternity and Adoption processing normally only involves a check for the
current absence as the reference period.
In this case, the From Where rule defines the point in history as being the absence
start date, and the How Far Bck/Fwd rule defines no calendar years. The reference
period simply includes the current absence.
The simplest way to check that the Reference Periods have been set consistently across all
4.4.2.5
Non-Qualifying Days
Non-Qualifying Day Rules define which days during an absence will not reduce entitlement.
None of the days that are identified as non-qualifying days will reduce the employees
entitlement.
However, Non-Qualifying Day Rules can also be used to manipulate the breakdown of the
absence into working and non-working days, to ease your payroll configuration process.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 25 of 61
EXAMPLE
A group of employees may receive maternity pay based on their working days, not the calendar
days in the absence. Therefore, their part period factoring and absence payments are based on
the working days in the payroll period and the working days during the absence.
Normally, maternity absences receive entitlements in weeks (011) and each day qualifies for
reducing entitlement. However, in this case, it would be simpler if maternity receives
entitlements in Entitlement weeks (E11) and only working days qualify for reducing entitlement.
In this way, the absence would be split into working and non-working days, with the working
days receiving a payment rate based on working days.
Where SAP use Non-Qualifying Days and Entitlement Units, SAP recommends that:
Maternity, Paternity and Adoption absence processing should be configured to use

weeks (011), without a Non-Qualifying Day Rule. In this way the OxP configuration
mimics the SxP rules.
Sickness absence processing should be configured to use entitlement weeks (E11) with
a Non-Qualifying Day Rule, meaning working days qualify to reduce entitlement. In this
way, the OSP configuration mimics the SSP rules because normally an employees
SSP Qualifying Day Pattern (QDP) will be derived from their working days.
You should ALWAYS try to keep the OSP and SSP qualifying day patterns synchronised. This
means that:
SSP is only received when OSP is also being paid, and
The amount of OSP is not lessened by being paid over more days, leading to the
potential situation for low earners where OSP is less than SSP but should not be. (That
is, 1/7th of the OxP weekly rate is less than 1/5 th of the SSP weekly rate, whereas 1/5 th of
and OxP weekly rate is actually more than 1/5th of the SSP weekly rate.)
However, the use of these QDPs will depend on how this group of employees will be paid when
they are absent.
Part Period Factoring & Absence Payment based on Calendar Days still implies that all four
absences can be paid exactly as described above. However, it is important ensure that the nonqualifying sick pay days also receive payment (even though they do not reduce entitlements), by
correctly customising the relevant payment band (valuation class) used for non-qualifying sick
pay days.
Part Period Factoring & Absence Payment based on Working Days/Hours implies that all four
absences must be paid in the same way as Sickness (as above), by extending that practice to
Maternity, Paternity and Adoption absences.
Therefore, your payroll configuration will dictate you OxP configuration.
Non-Qualifying Days are defined in table T5GPBS22 and are covered in more detail section 8.4.
The simplest way to check that the Non-Qualifying Days have been set consistently across all
4.4.2.6
Warning Period
A Warning Period is the number of days (up to 99) that are used to decide whether or not an
employee is about to move to the next Entitlement Band, triggering the issue of a message.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 26 of 61
EXAMPLE
An employee has 20 days 100% sick entitlement left (from their 50 day full entitlement) and their
current absence will use 10 of those days. Normally the administrator will be unaware that the
employee only has ten days of entitlement left. The Change of Band message that is
automatically generated if an employee changes band during an absence will not be generated
because the employee does not change their band during this absence.
However, if the scheme has a 10 day warning period set up against the entitlement band, then a
warning message will be issued. As soon as the warning period is less than or equal to the
remaining entitlement left in an Entitlement Band, the warning will be issued.
Warning Periods are only ever displayed during Master Data processing, if the date at which the
warning is issued has not been payrolled. If the warning has not been taken account of by the
time the payroll has been run in live mode and updated the payroll cluster, then there is little
point repeating the warning. Warning Periods are always displayed when the payroll is
processed as the warning may only have been triggered by absences entered in arrears.
The simplest way to check that the Warning Periods have been set consistently across all your
4.5
Checking your Scheme Rules
After each of the options in the previous section, the following statement has been repeated:
The simplest way to check that the ??????????? have been set consistently across all your
This cannot be stressed strongly enough.
There is no point spending weeks/months determining your business rules, if they are then
customised inconsistently. The view cluster (V_T5GPBS23_CL) is not a useful tool for this
purpose. The view cluster only allows you to view the detail of one line at a time.
The Scheme Overview push button (or report RPLABSG0_SCHEME_OVERVIEW) is the best
and the only way to review all of your customising at the same time.
In the delivered ALV view variant, only a small proportion of the available fields are actually
displayed. The rest are hidden to increase screen usability. The hidden fields can be accessed
by changing the view variant, using one of the three available pushbuttons:
1) Change Layout
2) Select Layout
3) Save Layout
Select Change Layout and Position, and all of the hidden fields are displayed for you to select.
Select the specific field(s) that you wish to check and include them in the display variant. If you
wish, you can save your settings to make the process easier next time.
After you have checked the consistency of your schemes and are happy that they reflect your
business rules, transfer each of the schemes, one by one, from the ALV display to an Excel
Spreadsheet or an HTML file. Also make sure that each responsible HR department agrees with
your customising, and obtain ratification from HR for each of your customized screens.
This will not only ensure that the customising meets your business needs, but it will also ensure
that your organisation becomes familiar with the OxP rules defined in that manner. This will then
make the Scheme Overview pushbutton/report and the Entitlements Left pushbutton/report
more understandable.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 27 of 61
Absence Evaluation Configuration (Part Days)
5.1
Activating Scheme Part-Day Processing
In the GPNAB and XNAB solutions, a Part-Day absence will ONLY be processed if Part-Day
processing has been activated for that employees scheme (V_T5GPBS29).
Part Days Not Allowed
1
Half Day if AB [Inc. Breaks] >= (PSP [Inc. Breaks] / 2)
Half Day if AB [Inc. Breaks] >= (PSP [Exc. Breaks] / 2)
Half Day if AB [Exc. Breaks] >= (PSP [Inc. Breaks] / 2)
Half Day if AB [Exc. Breaks] >= (PSP [Exc. Breaks] / 2)
Elapsed Hours AB [Inc. Breaks]
Elapsed Hours AB [Exc. Breaks]
Customer-Specific (Customer Exit)
Part Days Not Allowed will be the option selected by most customers. This implies that the
absence will not be processed by GPNAB or XNAB, but instead will be paid according to the
valuation rule that is attached in table T554S. It is important that you decide (as a default) how
these days should be paid in these cases. Normally, they will not reduce Part Period Factoring
or generate any Payment Wage Types and so will, in fact, be ignored by the payroll for the most
part.
Options 1-4 above are a variation on the same theme. If you are absent for more than a half
day, but less than a whole day, then you will reduce your entitlements by a day and receive
a day payment.
Options 5-6 are for customers wishing to process absences in exact hours. Generally, choosing
the second of these two is more sensible, as this option would only be used for employees paid
on an hourly basis and this would normally be a working hours basis (excluding breaks).
Option C is covered in the next section
5.1.1
Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_MIN)
In the GPNAB and XNAB solutions, it is possible to define how a Part Day should be treated.
There are six pre-delivered options as described in 5.1, but a customer exit has also been
provided to allow customers to provide any solution they wish. If you wish to use the customer
exit provided, then use option C and code the exit as you require.
5.2
Activating Absence Subtype Part-Day Processing
5.2.1
GPNAB
In the GPNAB solution, any absence subtype will be processed if a Part-Day absence has been
entered using that absence subtype. The maximum and minimum duration fields on table
T554S already control whether or not a Part-Day absence can be entered using a specific
subtype.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 28 of 61
5.2.2
XNAB
In the XNAB solution, only absence subtypes that are defined on T556M are processed if a
Part-Day absence has been entered using that absence subtype.
5.3
Part Day Payroll Processing
In the GPNAB and XNAB solutions, a Part-Day absence can be processed by any of the normal
customising solutions available. The customising table T554C, used by payroll function PAB to
process absences, has five possible settings for generating Wage Types:
1) KT Calendar Days,
2) AT Working Days,
3) AH Working Hours,
4) RT Calculated Days
5) RH Calculated Hours
However, PAB supports only three of the above for updating Counting Classes:
1) KT Calendar Days,
2) AT Working Days and
3) AH Working Hours
This implies that if you want to use the Absence Payment solution, then you have to use KT, AT
or AH for updating Counting Classes and making Absence Payments via wage types.
Unfortunately, the most commonly used option, KT Calendar Days, does not support Part-Day
absences. As far as PAB is concerned, KT Calendar Days will always be 0.00 or 1.00. It cannot
be anything in between. So for a Part-Day absence, KT Calendar Days is always set to 0.00.
This implies that if a customer has to use KT for his Part Period Factoring and Absence
Payment, but also wants to process Part-Day absences, then this is not possible, unless the
processing of PAB can be by-passed and calculated correctly as part of a work-around.
5.3.1
XNAB
In the XNAB solution, you cannot use KT Calendar Days to pay Part-Days correctly.
5.3.2
GPNAB
In the GPNAB solution, you can use KT Calendar Days and expect Part Days to be paid
correctly. But the GPNAB work-around implies that some customising must be duplicated.
5.3.3
Complete & Part Day Payment Bands
On a Part-Day (or when a Complete Day is split into two Part-Day entries), the GPNAB solution
changes the standard Complete Day Payment Band in table COVER, to a Part-Day Payment
Band on table AB. Then the standard processing of PAB ignores the Part-Day Payment Band
(as the Part-Day Payment Band has no customising against it in table T554C, except that it calls
the PCR GORD which performs the GPNAB work-around).
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 29 of 61
The GPNAB work-around involves reading the Complete to Part-Day cross-reference table
(T5GPBS25) to find the Complete Day Payment Band for the Part-Day Payment Band that is
being processed by PAB. Then the correct customising is read from the Complete Day Payment
Band (T554C) and all the rules from the Complete Day Payment Band (T554C) entry are used
to derive the values for the Part-Day Payment Band.
Therefore, the only difference between a complete day and a part day are that the values are
factored by the proportion of a Part-Day that is held against the entry in table COVER.
In addition (since the introduction of note 681624) the clock times of the Part-Day are also
updated to correctly reflect the Part-Day fraction.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 30 of 61
Absence Evaluation Configuration (Activation)
The absence evaluation solution is available in release 46B and above, and is identical in all the
releases for which it is available.
However, implementing your OxP rules and actually paying OxP are two different things.
Actually paying OxP implies that you need to have a solution that pays SxP and OxP, but does
not overpay the employee. The offsetting required to be able to do this is provided via the
payroll function GBSXP and is identical in release 46B and above. It has been made mandatory
in release 4.70, whereas it is optional in releases 46B and 46C.
This document does not deal with the offsetting solution, as this is covered with in the
accompanying document Paying SxP and OxP: Payment and Offsetting Explained (see
Section 1.4). As far as this document is concerned, the activation of the Absence Evaluation
solution is identical on release 46B and above.
6.1.1
Absence Evaluation via XNAB
XNAB is the international Absence Evaluation payroll function created in 1999 and redesigned
in 2002. As part of the re-design, XNAB caters for Data-Take-On and Part-Day absences.
To ensure that the new 2002 version of XNAB was available to customers that had previously
been using GPNAB, a switch was delivered to de-activate the GPNAB and activate XNAB in
T77S0. (The switch was not necessary inside the payroll, but was needed outside of payroll, for
example, in the infotype Absences (2001) and OxP reports.)
1) HRPSG
GPNAB
X = Activate GPNAB and Deactivate XNAB
2) Insert XNAB to your copy of payroll subschema GT00 directly before PAB.
3) Make sure that you have followed the Absence Evaluation DTO guide to ensure that XNAB is
active according to the Go-Live Date held in feature COVGL.
6.1.2
Absence Evaluation via GPNAB
GPNAB is a copy of XNAB as of 1999. The copy was taken to add functionality that was missing
in XNAB. In 2002, XNAB was re-designed to include the GPNAB requirements and so now
customers can choose which to use.
To make sure that the new 2002 version of XNAB was available to customers that had
previously been using GPNAB, a switch was delivered to activate the GPNAB and de-activate
XNAB in T77S0. (The switch was not necessary inside the payroll, but was needed outside of
payroll, for example, in the infotype Absences (2001) and OxP reports.)
1) HRPSG
GPNAB
X = Activate GPNAB and Deactivate XNAB
2) Insert GPNAB to your copy of payroll subschema GT00 directly before PAB.
3) Make sure that you have followed the Absence Evaluation DTO guide to ensure that GPNAB
is active according to the Go-Live Date held in feature GLIVE.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 31 of 61
6.1.3
Why should I use GPNAB, when XNAB is available?
As explained above, GPNAB was developed in 1999, specifically for the UK market.
1) GPNAB handles Part-Day absences in calendar days, by by-passing the international
processing in PAB that does not correctly handle Part-Day absences in calendar days.
Although XNAB can handle Part-Day absences correctly, PAB does not, if you wish to
process Part-Day absences in calendar days.
2) GPNAB only creates as many splits in table AB as are strictly necessary. As XNAB
creates splits in table AB on a daily basis, this can lead to rounding issues.
If you intend to use the Absence Payment solution where OxP payments are actually made to
the employee, then GPNAB should be used to reduce the risk of rounding issues in those
payments.
If you intend to process absences in calendar days and your employees reduce entitlement
when they are absent for less than a whole day, then GPNAB should be used to make sure that
the offsetting wage types and part period factoring are handled correctly.
6.2
Absence Evaluation simulation
The absence evaluation solution uses payroll cluster buffering techniques that mean the
solution can be identical when used as part of
6.2.1
Payroll,
Reporting,
Master Data (PA30)
Absence Evaluation during payroll
The absence evaluation solution works on a payroll period-by-payroll period basis that uses
Start Date and End Date of the Payroll Period to decide how much absence history needs to be
re-processed. This means that the employees Master Data Change (RRDAT) date on their
infotype Payroll Control Record (0003) can be used to drive how much absence history will be
re-calculated.
6.2.2
Absence Evaluation during reporting
The absence evaluation solution processes the specific amount of history that is necessary
based on the selection parameters input by the user.
This period of absence history may or may not already exist on the payroll cluster. This fact is
derived from the employees Master Data Change (RRDAT) date and Payroll Accounted To
date (ABRDT) on their infotype Payroll Status (0003) record. Only data that is not static on the
payroll cluster (that is, will be recalculated during the next payroll) is simulated.
6.2.3
Absence Evaluation during Master Data
The absence evaluation solution processes the specific amount of history that is necessary
based on the absence record that is being processed by the user.
This period of absence history may or may not already exist on the payroll cluster. This fact is
derived from the employees Master Data Change (RRDAT) date and Payroll Accounted To
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 32 of 61
date (ABRDT) on their infotype Payroll Status (0003) record. Only data that is not static on the
payroll cluster is simulated.
6.2.4
MP200000 Screen 2008
The international screen for absences is screen 2008. This screen has country exits available to
implement additional country-specific functionality. Screen 2008 has the following features:
1) The Absence Scheme is displayed
2) The Entitlements Left push button shows the entitlements left as of the start of the
absence
3) The Absence Breakdown push button shows how the absence will be processed during
payroll
4) The Band Change & Warning Period messages can be displayed as the absence is
entered
The exits are not processed in Display Mode, so a user without Change access is unable to
access this additional functionality directly, and instead will need to use the reports available
(RPLABSG0_ABSENCE_HISTORY,
RPLABSG0_ENTITLEMENT_DETAILS
&
RPLABSG0_SCHEME_OVERVIEW).
Features 1), 2) and 3) above can be controlled by either displaying the fields or not, depending
on the settings of table T588M. The kind of Absence Breakdown provided in feature 3) can be
controlled via a tableT77S0 constant:
HRPSG
ABSRP
F = Full, C = Condensed & S = Summary Report
Feature 4) can be activated or de-activated by a table T77S0 constant:

HRPSG
ABSCH
X = Errors & Band Changes (W = X + Warnings)
As part of GBSXP phase II, open-ended absences will be possible. However, during the
processing of OxP is it sensible that an open-ended absence is not processed indefinitely. For
this reason, a limit to the processing (in months) can be defined by a table T77S0 constant:
HRPSG
6.2.5
ABSMN
12
N = Processing limit in months
Testing your implementation
During testing, if the absence evaluation solution derives that no history needs to be generated,
then subsequent changes in customising will not be reflected in Master Data or Reporting,
unless RRDAT has been set to ensure that the entire period of history is generated.
So, once the payroll has been run for a period, that period will be deemed as static by the
solution (not regenerated automatically during Master Data or Reporting) unless RRDAT is set
to include that payroll period. This will mean that your customising changes may seem to have
no effect on a specific employee, but this is due simply to the fact that the employees ABRDT
and RRDAT dates imply that no history needs regenerating.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 33 of 61
Absence Evaluation Configuration (Payment)
The OxP payment solution is based on the international customising that is available in table
T554C.
Using this table, customers can choose how different groups of employees can be paid
differently using the SAME Payment Bands (absence valuation classes T554L). The first key
field MODIF is defined during payroll by the PCR CMOD (or GMOD in 4.7). The simplest and
most obvious interpretation is to use the same definition as you use for your Employee
Subgroup Groupings for Payroll (ABART) (3 for monthly-, 2 for weekly- and 1 for hourly-paid).
7.1
Updating Counting Classes
The settings in table T554C will imply that absence counting classes are updated. Regardless of
the settings, the Calendar Days, Working Days and Working Hours counting classes are all
updated.
If you are using the new payment solution, then ALL of your counting classes will be 100%
unpaid. (100% OxP will be 100% unpaid and 50% OxP will be 100% unpaid). In this case, the
employee receives no basic pay when they are absent. The only payments they will receive will
be the payments generated from the wage types in the second half of the table T554C
customising.
If you are using the old notional solution, then ALL (except for your Nil Pay valuation classes)
of your counting classes will be partly or wholly paid (100% OxP will be 100% paid and 50%
OxP will be 50% paid). In this case, the employee receives basic pay when they are absent and
not OxP. The payments they will receive that have been generated from the wage types in the
second half of the T554C customising will be treated as notional.
7.2
Creating Wage Types
The settings in table T554C imply that absence payment wage types (notional) are generated
based on the employee group that the employee belongs to. So the number and unit field
against the wage type will be decided by the customising in T554C.
Make sure that the Basic Pay Split indicator is set, so that each wage types is identifiable with a
specific WPBP split.
The rate and amount fields will be left empty. During the valuation of PCR G015, the valuation
base for that wage type will be identified (10, 11, 12 or 13) and the payment rate will be derived
from the corresponding wage type (/010, /011, /012 or /013).
The payment rates used in wagetypes /010, /011, /012 or /013 will directly correspond to how
that employee should be paid. The payment rates are derived during the processing of G010
and G013. During the processing of G013, the payment rates can be factored up by the payroll
constant GENAU (T511K). The Time Unit field can also be added using the operation GBZNH
(001 for hourly-, 010 for daily- and 011 for weekly-paid).
7.3
Part-Period Factoring
The counting classes updated during the processing of PAB are processed during the PCR
GPPF. The part-period factors (/801 - /810) are generated as fractions of a whole pay period
(factored up by GENAU). The PCR GVAL then applies the part period factors (/801 - /810) to
any payment wage types that are affected during part-period factoring.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 34 of 61
Absence Evaluation Configuration (Complexities)
8.1
Linking Absences
The OxP solution supports many kinds of absence linking. Where it can be specified as a field
on a table, then the full range of options can be applied, (T5GPBS20 and T5GPBS21). Where
the linking option has to be specified as part of another option (for example, feature GLOSS),
the options have been split to include the various options that were thought desirable. If the five
options listed below do not include your required linking option, then raise a development
request stating the kind of linking you wish to use and in which circumstances. The five linking
options are:

No Linking
00
Continuous Linking
01 99
Interval of 1 99 days allowed
GM
GB Maternity: Link if from the same MATB1
Exclude Absence.
The first three options are self-explanatory.

Option GM ensures that OMP entitlements are not renewed if a female employee has to return
to work at the request of her employer and so has a break in her maternity absence. This type
of linking must only be used for Where From rules. This rule has not been extended to
Adoption and Paternity absences, as linking via infotype 0088 is currently still under discussion.
Linking by a number of arbitrary number days (for example, 60) is just as effective.
Option X is a very unusual type of linking rule. If the start of the reference period overlaps a
related absence, then the whole of that related absence should be excluded from the reference
period. This type of linking must only be used for How Far Bck/Fwd rules. It implies that
absences that overlap the start of a reference period are not included in that reference period.
This can help customers to implement an Entitlement Year as used for Public Sector Teachers
(01.04.YYYY 31.03.YYYY). However, this can also be handled using a very specific Where
From method. See Section 8.2. for more details.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 35 of 61
8.2
Reference Periods
A reference period is a period that is checked for used entitlements. If an absence does not
have a reference period, then the employee would never run out of entitlement.
In SAP terms, this is defined by a window of history that is checked for used entitlement. So
there is a start and an end to the check window.
The end of the check window is defined in T5GPBS20 and is known as a From Where rule,
as it specifies a point in time where the window should start.
The start of the check window is defined in T5GPBS21 and is known as a How far Bck/Fwd
rule, as it specifies how big the window is.
8.2.1
Normal Definitions
For Maternity, Paternity and Adoption absences, the reference period is normally very simple. It
is simply the absence itself.
The From Where rule defines the start of the window to be the absence start date. The How
far Bck/Fwd rule says that the window is empty, because no additional history is checked
further back into history, so only the current absence is checked.
The only exception to this rule will depend on your business rules that cover an employee
returning to work part-way through a period of Maternity, Paternity or Adoption Leave. Three
possibilities in this situation are outlined:
1) An employee is not entitled to further OMP, OAP, OPP payments after the first time that
they return to work voluntarily. The Maternity, Paternity or Adoption Leave stops as
soon as they return to work and a separate subtype would be used if the employee
were to choose to go back on Maternity, Paternity or Adoption Leave to ensure that they
employee did not receive additional entitlements or the employee would be changed to
a scheme without entitlements (0572).
2) An employee is entitled to further OMP, OAP, OPP payments after the first time that
they return to work if they have been asked to do so by the business. The Maternity,
Paternity or Adoption Leave continues uninterrupted by the period that they work. This
would normally be handled by using a linking rule on the From Where rule, so that
absences that are linked by 60 day interval (or whatever the business chooses as
suitable) will be included in the reference period.
3) An employee is entitled to further OMP, OAP, OPP payments after the first time that
they return to work as long as the separate absence pertains to the same MPP, APP or
PPP. The Maternity, Paternity or Adoption Leave continues uninterrupted by any period
that they work. This would normally be handled by using a linking rule on the From
Where rule, so that absences that overlap the same infotype 0088 records will be
included in the reference period.
This third scenario needs to be reviewed as part of GBSXP Phase II, as the end date of
infotype 0088 is not suitable, as the end date cannot be modified by the user. When this
has been delivered and can actually replace option 2, then the GM (Maternity) option
will be extended to GG (Adoption) and GP (Paternity) too.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 36 of 61
8.2.2
From Where Rules
There are ten supported methods for defining Where From rules. Each can have a parameter
set that will further determine how the method will actually define the end of the check window:
1) Actual Absence
a. 1
Absence Start
b. 2
Day-by-Day Through Absence
2) Employee Anniversary (Public Sector)

a. EH
Earliest Hire
b. LH
Latest Hire (before absence)
c.
Employee Date Infotype 0041
01 ... 12.
3) Calendar Anniversary (Public Sector 1)

a. DD.MM
(Day.Month)
4) Absence Recording
a. DD.MM.YYYY (Day.Month.Year)
5) Employee Start Date
a. EH
Earliest Hire
b. LH
c.
01 ... 12.
6) Calendar Anniversary
a. DD.MM
(Day.Month)
7) Employee Anniversary
a. EH
Earliest Hire
b. LH
c.
01 ... 12.
8) Calendar Anniversary (Public Sector 2)

a. DD.MM
(Day.Month)
There are major differences between these options, but the most widely used option is Actual
Absence (1/1).
8.2.2.1
Actual Absence
The check window is defined by the current absence that is being processed.
Parameter set to 1
The check window includes all the days in the current absence up to the day that is
currently being processed. In this way, the check window is a fixed length on the first
day of the absence (defined by the How Far Bck/Fwd rule), but increases one day at a
time as the next day is processed.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 37 of 61
Parameter set to 2
The check window only includes the days in the current absence up to the day (if a How
Far Bck/Fwd rule goes back that far). In this way, the check window is a fixed length, but
moves forward one day at a time as the next day is processed. (This option should only be
used if your rules require a moving/rolling check window where the employee will receive
additional entitlements as earlier absences drop out of the check window as it moves
forward.)
8.2.2.2
Employee Anniversary
The employee anniversary date (DD.MM.YYYY) can be defined for the employee based on their
first hiring action, their most recent hiring action or by a specific date type stored on their
infotype 0041 record. This means that the DD.MM can be defined quite simply, but the YYYY
still needs to be defined.
Normally, there is no need to have a How Far Bck/Fwd rule that extends the check window as
the window will start on the anniversary date and end on the day of the absence that is being
processed. This is the simplest way to define an Entitlement Year based on the employees
specific hire date to define when the Entitlement Year starts and ends.
There are two ways to choose which employee anniversary date to use:
1) Use the start date of the absence
The entitlement year is fixed using the start date of the absence.
For example, if an absence starts on 01.01.2003 and the employee anniversary is on
01.05.2003, then even if the absence lasts for five months, the entitlement year will still
start from 01.05.2002 and run until the end of the absence.
2) Use the day of the absence that is being processed
The entitlement year is fixed using the day of the absence that is being processed.
For example, if an absence starts on 01.01.2003 and the employee anniversary is on
01.05.2003 then for the days of the absence before 01.05.2003, then the entitlement
year will still start from 01.05.2002. However, if the absence lasts for five months, then
for the days of the absence on or after 01.05.2003, the entitlement year will still start
from 01.05.2003 and run until the end of the absence.
8.2.2.3
Calendar Anniversary
The calendar anniversary date (DD.MM.YYYY) is defined using the parameter, so the DD.MM
can be decided quite simply, but the YYYY still needs to be decided.
Normally, there is no need to have a How Far Bck/Fwd rule that extends the check window as
the window will start on the anniversary date and end on the day of the absence that is being
processed. This is the simplest way to define an Entitlement Year based on a specific calendar
date to define when the Entitlement Year starts and ends.
There are three ways to choose which calendar anniversary date to use:
For example, if an absence starts on 01.01.2003 and the calendar anniversary is on
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 38 of 61
2) Use the day of the absence that is being processed

The entitlement year is fixed using the day of the absence that is being processed.
01.05.2003, then for the days of the absence before 01.05.2003, the entitlement year
will still start from 01.05.2002. However, if the absence lasts for five months, then for the
days of the absence on or after 01.05.2003, the entitlement year will still start from
01.05.2003 and run until the end of the absence.
The only difference between options 1) and 3) is that in 1), the absence days that overlap the
entitlement year start date and are in the new year will not only reduce the old entitlement, but
will also reduce the new entitlement year as well. This option will not include those days in the
new year. Thus, this definition is identical to the linking option for the How Far Bck/Fwd rule
that excluded the days that overlap the start of the reference period.
8.2.2.4
Absence Recording
Some kinds of illness may have a fixed amount of entitlement regardless of when they are taken
during the employees period of employment. In this way, the reference period is unlimited and
includes any historical data that is in the system
8.2.2.5
Customer-Specific
There are two customer-specific methods provided and these can be stretched even further as
there is no check on the parameter field for these methods. The Customer Exit
EXIT_SAPLHRGPBS_OSP_OMP_MTD allows any definition.
8.2.3
How Far Back/Forward Rules
The How Far Bck/Fwd rules are defined in T5GPBS21.

The only complex part of this solution is defining the How Far Bck/Fwd Time Unit for how far
back/forward should be checked.
There are three pre-delivered Time Units based on calendar dates, not calendar days:
EXAMPLE
1) Calendar Years (R13)
One year before 01.04.XXXX is 01.04.YYYY, regardless of whether YYYY is a leap year or not
2) Calendar Months (R12)
One month before 31.03.YYYY is 28.02.YYYY, if YYYY is not a leap year
One month before 31.03.YYYY is 29.02.YYYY, if YYYY is a leap year
3) Calendar Days (R10)
30 days before 11.03.YYYY is 09.02.YYYY, if YYYY is not a leap year
30 days before 11.03.YYYY is 10.02.YYYY, if YYYY is a leap year
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 39 of 61
8.3
Waiting Days
Waiting Days are designed in exactly the same way as SSP waiting days and are defined in
table T5GPBS20.
Waiting days in the OxP solution do not reduce entitlement. Effectively, they are similar to a type
of non-qualifying day, except that they can have their own payment band and linking rules.
WAITING DAYS THAT REDUCE ENTITLEMENT
If your scheme rules are such that there are a number of days at the start of every absence that
are known as waiting days, but reduce entitlement, then these cannot be handled using
waiting days in T5GPBS20.
SOLUTION
This rare requirement would be better handled using a separate payment band that provides
entitlement for the waiting days and has the required reference period (with linking if
necessary). Then, the following main entitlement should have an entitlement limit rule attached
that includes the waiting days and the main entitlement in the total of its entitlements. In this
way, the total amount of entitlement will not be exceeded.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 40 of 61
8.4
Non-Qualifying Rules
Non-Qualifying Days do not reduce entitlement.

If you intend to use a Non-Qualifying rule and process those Non-Qualifying days as actually
receiving payment, then you will need a non-qualifying rule per payment band to ensure that the
employees payment changes when their band changes.
EXAMPLE
If your business rules are such that Public Holidays do not reduce entitlement, but do receive
payment, then the By Default option can be used to implement these rules exactly. It is
important to have a rule per entitlement payment band (For example, 100% and 50%).
Non-Qualifying Days are defined at two possible levels (T5GPBS22):
1) By Default: Non-Qualifying days for all employees in the scheme
2) Employee-Based: Non-Qualifying days for just one employee
8.4.1
By Default
These Non-Qualifying Days are based on a Period Work Schedule rule.

The Period Work Schedule rule should not be attached to any employee via infotype 0007,
although obviously it could be. However, it is designed to be used by the scheme and not for
any individual employee.
1) Any Public Holiday will be a Non-Qualifying day
2) Any Non-Public Holiday will be a Non-Qualifying day if it is a non-working day (that is,
there are no planned start or end times).
8.4.2
Employee-Based
These Non-Qualifying Days can be based on any of the following options:

1) Non-Working Days
2) Days before MMP Start Date
3) Non-Working Days or Holidays (All Classes)
4) Non-Working Days or Holidays (Class 1)
9) Days before APP Start Date
0) Days before PPP Start Date
A) MatWeek 1: Non-Payment days in OMP week
B) MatWeek 2: Non-Payment days in SMP week
C) AdpWeek 1: Non-Payment days in OAP week
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 41 of 61
D) AdpWeek 2: Non-Payment days in SAP week

E) PatWeek 1: Non-Payment days in OPP week
F) PatWeek 2: Non-Payment days in SPP week
Option 1 must be used in conjunction with Entitlement Weeks.
Options 3 8 can be used to help implement the Teachers OSP solutions for Local
Authorities, by defining Teachers Non-Term-Time that does not reduce entitlement. Your
chosen option depends on how you have customised your Holiday Classes and Employee Work
Schedule Rules.
An alternative is to use the By Default grouping discussed in 8.4.1, but that may become
difficult to control as it will probably mean implementing one scheme per school. Whereas, if
school holidays have been customised using a separate Holiday Class from the one used for
Public Holidays, then options 4 8 are a much simpler solution.
Options 2, 9 and 0 can be used to keep OxP weekly payments in line with SxP payments if an
employee chooses to start their absence before the start of the relevant SxP week. Obviously,
these can only be used for Maternity, Paternity and Adoption absences and cannot be used in
conjunction with Entitlement Weeks as Option 1 must be used in conjunction with Entitlement
Weeks.
Options A, B, C, D, E and F are used to ensure that only one day per week will reduce
entitlement and therefore receive the weekly payment amount.
The difference between options A and B is that A is based on a seven-day rotating pattern that
starts from the continuously linked absence start date from infotype 2001 (so A will be affected
by employees returning to work part way through the absence), and B is based on a seven-day
rotating pattern that starts from the start of the MPP (so B will not be affected by employees
returning to work part way through the absence). There are similar differences between options
C and D and E and F.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 42 of 61
8.5
Entitlement Limits
The Entitlement Bands (View Cluster V_T5GPBS23_CL) customising includes two other options
that allow complex interdependencies to exist between the current Entitlement Band that is
being customised and other Entitlement Bands or even groups of Entitlement Bands.
These additional fields have been provided to help customers cater for their own particular
requirements.
EXAMPLE
The one year in four rule
The one year in four rule is relevant for customers that have (or had) some affiliation with
Central Government (For example, Public Utilities or Services). The rule is as follows:
183 Entitlement to Full-Pay in a year - as long as employees have not had 365 days Full- or
Half-Pay in the last 4 years.
182 Entitlement to Half Pay in a year - as long as employees have not had 365 days Full- or
Half-Pay in the last 4 years.
This rule can be interpreted in one of two ways:
Interpretation 1
183 Full Pay in a year :
1) If employee has not had any days of Half-or Nil-Pay in the current absence,
AND
2) If employee has not had 365 days of Full- or Half-Pay in the last 4 years.
182 Half Pay in a year :
1) If employee has not had any days of Nil-Pay in the current absence,
AND
2) If employee has not had 365 days Full or Half-Pay in the last 4 years.
For both Full- and Half-Pay, the interpretation of the one year in four rule is that an
employee cannot return to a higher level of pay part-way through an absence, even if
according to the implicit rules they would be allowed to.
Interpretation 2
183 Full Pay in a year, if employee has not had 365 days Full- or Half-Pay in the last 4
years.
182 Half Pay in a year, if employee has not had 365 days Full- or Half-Pay in the last 4
years.
For both Full- and Half-Pay, the interpretation of the one year in four rule is that an
employee can return to a higher level of pay part way through an absence, if according
to the implicit rules they would be allowed to.
Under interpretation 1, there are two sets of complex interdependencies for each
Entitlement Band.
Under interpretation 2, there is only one set of complex interdependencies for each
Entitlement Band.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 43 of 61
8.5.1
Using the Entitlement Limit Fields
The two Entitlement Limit rules available for each band allow for both interpretations of the One
Year in Four rule.
Under interpretation 1, the first Entitlement Limit field is used to define the lesser rule
concerning not returning to a higher payment band during an absence. The first Entitlement
Limit field will cause an Entitlement Band to be limited far more regularly than the second, and
so if a limit is hit using this rule, then no message is issued.
Under interpretations 1 and 2, the second Entitlement Limit field is used to define the main
rule. The second Entitlement Limit field will cause an Entitlement Band to be limited far more
rarely and so if a limit is hit using this rule, then a warning message is issued.
8.5.2
Defining an Entitlement Limit
Entitlement Limit rules are defined in T5GPBS30. The limit has to be for the SAME Absence
Grouping as the Entitlement Band that it is attached to.
8.5.3
Overriding an Entitlement Limit
Although Entitlement Limit rules override an employees normal entitlement bands, it still must
be possible to use a manual override to change entitlements in any circumstance. Therefore, if
an extension or reduction to entitlement exists on infotype Absence Scheme Override (0572),
then the Entitlement Limits rules are by-passed.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 44 of 61
Appendix 1
This first appendix covers all the additional features added into the OXP functionality. In most
cases, it will be possible to implement any customer-specific requirements you may have.
However, Appendix 1 details the more rare requirements you may have.
9.1
Non-payment Days
The Non-Payment Day rules do not affect the way that an employees entitlement is calculated
and stored in COVER. The Non-Payment Day rules are an ad-hoc variation that only occurs in
table AB, meaning that the payment rules can be amended for a group of employees for a
specific absence.
The idea is that specific days in the calendar year can receive an alternative payment solution
from others, but still reduce entitlement in exact the same way. For example, employees that
are sick on a public holiday reduce entitlement and receive their normal OSP Full- or Half-Pay
payment, but receive an additional one-off payment to compensate for the loss of a public
holiday, instead of receiving Time Off In Lieu.
This functionality can also be used by customers who wish to keep OMP/OAP/OPP weeks in
line with the employees SMP/SAP/SPP weeks. Thus, payments for OxP are always made in
the period where the SxP payment is made. Therefore, the days after the last SxP payment
date in the period do not receive OxP, and are offset, but are recognised as not actually being
paid yet.
This requirement can also be satisfied by the introduction of the use for Matweeks (M11),
Patweeks (P11) and Adoption Weeks (A11) and only paying OMP, OPP & OAP one day per
week, but always on the same day as the SxP payment.
9.2
Public Holidays
Public Holidays can be handled in various ways throughout the whole range of OxP
configuration. The first and most important factor is whether Public Holidays will reduce
entitlements or not.
9.2.1
Public Holidays that reduce entitlement
If Public Holidays reduce entitlements, then they cannot be handled via a non-qualifying rule
(using the By Default options). Instead, they simply need special processing during payroll.
This can either be achieved using a specific Non-payment rule that will allow you to differentiate
Bank Holidays from normal days in table AB, or you can use the same entry in table AB, but
have separate processing using Day Rules attached to your T554C rules.
If you do use Day Rules, then they must be mutually exclusive and attached to each counting
class/wage type.
9.2.2
Public Holidays that do not reduce entitlement
If Public Holidays do not reduce entitlements, then they can be handled via a non-qualifying rule
(using the By Default options).
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 45 of 61
9.3
OxP Processed and Held in Hours
The feature GENTT can be activated to ensure that the history of used entitlements is not held
on the basis of a 24-hour clock (that is, 1440 minutes per day), but instead is held on the basis
of the employees working hours (PSP-STDAZ).
Non-Qualifying days will still be processed using a 24-hour clock, but days that reduce
entitlement hold the number of minutes that would normally be worked (PSP-STDAZ x 60).
9.4
Customer-Specific Time Units
The use of customer-specific Time Units is not recommended. The section on Entitlement Units
(4.4.2.1.1) outlines the strengths and weaknesses of the Time Units that SAP already provides.
Creating your own Time Units may well not be as successful as you may hope, but can be
useful in some areas.
For some customers, the reference period will not be a simple 12 month period (or similar). It
may instead be a very complex period depending on previous absences and so on. In this case,
a customer-specific rollback time unit may be very useful. In this situation, you should proceed
as follows:
1) Define the time unit in T538A
2) Make the time unit applicable to rollback units only in T5GPBS28
3) Do not give it a time unit multiplier (it must not exist as an entry in T5GPBS24)
4) Code and Activate the Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_LEN) to
derive how the Time Unit should be used.
9.5
Customer-Specific Rollback Methods
The use of customer-specific Rollback Methods can be very useful. So creating your own will
probably allow any customer-specific requirements to be met.
For some customers, the reference period will not be a simple 12 month period (or similar). It
may instead be a very complex period depending on previous absences and so on. In this case,
a customer-specific rollback method may be very useful. In this situation, you should proceed as
follows:
1) Use one of the two available customer-specific rollback methods (Y or Z).
2) Code and Activate the Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_MTD) to
derive how the Rollback Method should be used.
9.6
Customer-Specific Linking
Currently, customer-specific linking of absences is not supported. If you have any requirements
for customer-specific linking options, then you must raise a development request.
9.7
Customer-Specific Entitlements
The use of customer-specific Entitlement Rules should only be very rarely handled by the
Customer Exit provided.
Any customer-specific attachment rules can be handled in the Customer Exit provided
(EXIT_SAPLHRGPBS_OSP_OMP_CVR).
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 46 of 61
However, for some customers, the only solution will be to apply customer-specific rules in the
Customer Exit provided. However, in this situation, it may still be simpler to use the infotype
Absence Scheme Override (0572), rather than use this exit, as infotype 0572 provides complete
flexibility and clarity, whereas the rules of the Customer Exit are inflexible and hidden to the
user.
If the OxP Entitlement Rules for one group of employee are not definitively customisable using
the Schemes and Scheme Rules:
1) Code and Activate the Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_ENT) to
derive how an employees Entitlements should be defined.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 47 of 61
10
Appendix 2
10.1
OxP Messages
The payroll function GPNAB will issue the following messages for the reasons outlined below:
a) GPNAB will issue an error message if it cannot correctly process an employees
absence evaluation.
This accounts for the bulk of the 130 different messages in message class
HRPSGB_ABS (see Section 10.2). These are created due to missing Master Data or
incorrect customising.
b) GPNAB will issue warning messages if it finds a situation that should not really occur,
but which is not critical to paying the employee.
For instance, non-qualifying days for a maternity Entitlement Band have been
customised based on excluding the days before the MPP, but the employee does have
an infotype 0088 record existing from the start of the MPP. In this case, the days before
the MPP will issue the following warning and be processed as non-qualifying days, but
that is not necessarily a problem as this could be completely correct:
Employee has no Maternity Details between &1 and &2 (Infotype 0088)
c) GPNAB will issue warning messages when the employee moves from one entitlement
band to another:
Payment Band Changed from '&1' to '&2' on &3 for '&4' absence
d) GPNAB will issue warning messages when entitlements will be used within the
customised warning period:
Entitlement Used (issued on &1): &2 of '&3' for '&4' absence
The payroll function XNAB also issues the majority of these messages, as there is very little
difference between the two solutions, and in fact, most of the messages are issued during the
GB country exits which are identical in both solutions.
Note: There is one message which seems to be generated very frequently:
Absence Collision: &1 has more than 1 day's entitlement, check absences
This message will be issued for one of two reasons, either:
Overlapping absences have forced the solution to try to process more that one day
of entitlement on a day, or
Overlapping scheme rules (via overlapping seniority/age bands) have forced the
solution to try to process more that one day of entitlement on a day.
The rest of the messages are generated during the implementation phase, but rarely during the
normal day-to-day processing as they are mostly created for customising inconsistencies.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 48 of 61
10.2
Message Class HRPSGB_ABS
001
Rollback Method 1 only supports Parameters 1, 2
002
Rollback Methods 2 and 5 only support Parameters EH, LH and IT0041 Dates
003
Rollback Method 3 only supports Parameters for the format DD.MM
004
Rollback Method 4 only supports Parameters for the format DD.MM.YYYY
005
Checking Linking for 'Related Absences Only' MUST have a Linking Method
006
Waiting Days to 'serve' must have a Valuation Rule for Waiting Days
007
Valuation Rule for Waiting Days must have Waiting Days to 'serve'
008
Linking Method for Waiting Days must have Waiting Days to 'serve'
009
Enter all four fields to attach a Period Work Schedule Rule (or none)
010
Specify Non-Qualifying Days with a 'PWS rule' OR 'Emp Rel days' NOT both
011
Valuation rule is required, if Non-Qualifying days are specified
012
Valuation rule is NOT allowed, if Non-Qualifying days are NOT specified
013
Waiting Day val. rule does not exist in customising (Table T5GPBS27)
014
Absence evaluation scheme does not exist in customising (Table T556E)
015
Absence subtype category does not exist in customising (Table T5A4P)
016
Enter BOTH absence subtype category and valuation rule (or neither)
017
Fill whole line correctly (absence category and valuation class empty).
018
Fill only one of 'extension in days' or 'reduction in days'.
019
Fill either of 'extension in days' or 'reduction in days'.
020
Valuation rule is required, if Non-Payment days are specified
021
Valuation rule is NOT allowed, if Non-Payment days are NOT specified
022
Personnel Work Schedule rule does not exist in customising (Table T508A)
023
Abs. Eval. Scheme rule does not exist in customising (Table T556G)
024
Time Unit/Measurement does not exist in customising (Table T538A)
025
How Far Bck/Fwd rule does not exist in customising (Table T5GPBS21)
026
From Where rule does not exist in customising (Table T5GPBS20)
027
Non-qualifying Days rule does not exist in customising (Table T5GPBS22)
028
Rollback Time Unit does not exist in customising (Table T5GPBS28)
029
Entitlement Time Unit does not exist in customising (Table T5GPBS28)
030
Multiplier Time Unit does not exist in customising (Table T5GPBS28)
031
First character of an absence grouping must be an 'S', 'M', or '.'
032
Offsetting Wage Type is ONLY for SMP-able or SSP-able abs. grouping
034
Valuation rule does not exist in customising (Table T554L)
035
Complete Day val. rule does not exist in customising (Table T5GPBS27)
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 49 of 61
036
Part Day val. rule does not exist in customising (Table T5GPBS27)
037
Non-Qualifying val. rule does not exist in customising (Table T5GPBS27)
038
Non-Payment val. rule does not exist in customising (Table T5GPBS27)
039
Nil Pay Day val. rule does not exist in customising (Table T5GPBS27)
040
Lieu Days processing is NOT allowed unless 'Working Days Only' qualify
041
Enter both fields for Lieu Days processing or neither.
042
Limiting rule does not exist in customising (Table T5GPBS30)
043
Override the Scheme or an extend/reduce an Absence Payment Band.
050
Part Day Valuation Rule &2 not in customising (T5GPBS25) ( &1 )
051
Error in Customer Exit 'LEN' for Time Unit &1
052
Non-Qualifying Day Rule &2 not in customising (T5GPBS22) ( &1 / &3 )
053
Non-Qualifying Day Rule &2 customising incomplete (T5GPBS22) ( &1 / &3 )
054
Personnel Work Schedule Rule not valid during absence ( &1 &2 &3 &4 )
055
Employee's Personnel Shift Plan is invalid on &1
056
Check Window End Rule &2 not in customising (T5GPBS20) ( &1 / &3 )
057
Unsupported Combination Of Rollback Method &1 and Parameter &2
058
Insufficient Employee Data for Rollback Method &1 with Parameter &2
059
Check Window Start Rule &2 not in customising (T5GPBS21) ( &1 / &3 )
060
Absence Collision: &1 has more than 1 day's entitlement, check absences
061
Error in Customer Exit 'ENT' for Check Period &1 to &2 on &3
062
Valuation Rule &1 has no offsetting Wage Type at &2 (Table T554C)
063
Error in Customer Exit 'NIL' for Absence Subtype &1
064
Part Day processing failed. Absence record '&1' missing from table AB
065
Part Day processing failed. NOT a part day Valuation Rule &2 ( AB &1 )
066
Part Day Valuation Rule &2 not in customising (T5GPBS25) (AB &1 )
067
Non-Payment Day Rule customising incomplete (T5GPBS26) ( &1 &2 &3 &4 )
068
Rollback Period Units 'R??' are reserved by SAP, use 'Z??' instead of &1
069
Entitlement Units 'E??' are reserved by SAP, use 'Z??' instead of &1
070
Error in Customer Exit 'MTH' for Rollback Method &1 & Parameter &2
071
No record exists for &1 and &2 in Personnel Area/Subarea (Table T001P)
072
No record exists for &1 and &2 in Employee Groups/Subgroups (Table T503)
073
No record exists for &1 &2 and &3 in Attendance and Absence Types (T554S)
074
Employee has no Org. Assignment on &1 (Infotype 0001)
075
Employee has no Planned Working Time on &1 (Infotype 0007)
076
No customising exists for End Rules (T5GPBS20)
077
No customising exists for Start Rules (T5GPBS21)
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 50 of 61
078
No customising exists for Non-Qualifying Day Rules (T5GPBS22)
079
No customising exists for Absence Evaluation Scheme Rules (T5GPBS23)
080
Maximum part day absence splits exceeded on &1 ( caused by Part Day &2 )
081
Maximum part day absence splits reach on &1 ( data lost for Part Day &2 )
082
Entitlement Used (issued on &1): &2 of '&3' for '&4' absence
083
The feature GLOSS passes back &1 which is not supported (1-8 only)
084
Checking AUTOMATIC absence splitting in Payroll (Re: Abs. Eval. Scheme)
085
Checking MANUAL absence splitting in Absence Entry (Re:Abs. Eval. Scheme)
086
Checking MANUAL absence splitting in Absence Entry (Re: Bespoke Report)
087
No AUTOMATIC splitting of this absence will occur in Payroll
088
No MANUAL splitting of this absence is necessary (Re: Abs. Eval. Scheme)
089
No MANUAL splitting of this absence is necessary (Re: Bespoke Report)
090
Employee &1 is not attached to a scheme.
091
Employee has no Basic Payments on &1 (Infotype 0008)
092
No Employee Group/Subgroup exist for &1 &2 (Table T503)
093
No Standard Working Hours exist for &1 &2 &3 &4 (Table T510I)
094
No Scheme Switches exist for &1 &2 &3 (Table T5GPBS29)
095
Employee has no Maternity Details between &1 and &2 (Infotype 0088)
096
Shift Worker requires EntWeek Time Unit indicator set (Table T5GPBS29)
097
Seniority Time Unit &1 is NOT defined in customising (Table T5GPBS24)
098
Previous Service from Date Specifications (IT041) requires a Date Type.
099
Date Type &1, to calculate Previous Service, does not exist (Table T548Y)
100
Employee has no Date Specification in Infotype 0041 for Date Type &1
101
Limit Rule &2 not in customising (T5GPBS30) ( &1 / &3 )
102
Payment Band Changed from '&1' to '&2' on &3 for '&4' absence
103
Val. Rule &1 ( &2 / &3 ) is not allowed a Counting Class or a Wage Type
104
The employee's PS Grouping changes from &1 to &2 on &3.
105
Seniority/Age "As At Date" is missing. Feature GLOSS or GAGES incorrect
106
Seniority/Age "As At Date" &1 must be in the format "DD.MM"
107
Employee has no Date of Birth at &1 (Infotype 0002)
108
Age Calculation Type &1 is NOT supported (Check FEATURE GAGES)
109
Employee changes Absence Scheme during absence (on &1 from &2 to &3)
110
Offsetting wage type &1 not in payroll table &2, check customising in IMG
111
Offsetting Wage Type &1 does not have the correct valuation basis on &2
112
Employee has many Go Live dates; The Latest &1 will be used.
113
Employee has absences overlapping their LATEST Go Live date &1.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 51 of 61
114
Go Live date &1 is NOT in the date range selected &2 - &3
115
BOTH Absence Grouping & Payment Band are MANDATORY (T5GPBS31 &1 &2 &3 )
116
Non-Payment Rule has no UNPAID Valuation Cls for &1 on &2. (&3)
117
Activate Unpaid OMP Dates to enter Paid Payment Band/Unpaid Payment Band
118
Enter BOTH Paid Payment Band 1 and Unpaid Payment Band 1
119
Enter BOTH Paid Payment Band &1 and Unpaid Payment Band &1 (or neither)
120
Fill earlier gaps before Paid Payment Band &1 and Unpaid Payment Band &1
121
Entitlement Amount, &1 days, exceeds possible expected life span!
122
Entitlement Limit rules 1 and 2 cannot be the same.
123
Go Live Date &1 is not in the format YYYYMMDD (Feature GLIVE)
124
Conversion not possible; GPNAB still active (T77S0: HRPSG/GPNAB)
125
Conversion not necessary; Part Day processing is not active (T5GPBS29)
126
MPP Start Date not entered yet; Earliest MPP Start Date used (IT0088)
127
Internal Error: During generation of payroll structure COVER on &1
128
ENTWEEKS must have a rule specified in T5GPBS29 (See Note 541144)
129
EXACT Part Day Processing is obsolete T5GPBS29 (See Note 541144)
130
Scheme &1 has overlapping scheme rules (View Cluster V_T5GPBS23_CL)
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 52 of 61
11
Appendix 3
The pre-delivered OxP customising is only delivered to client 000 as most of the tables involved
are C tables.
11.1
Dependencies between OxP-delivered table entries
This section describes the order in which tables should be copied from client 000 to avoid
interdependencies. This is also the order in which these tables need to be created, if you wish to
create your own entries.
11.1.1 Payment Bands

Via transaction SM31, copy payment bands from client 000 in the following order:
T554L
T5GPBS27
T5GPBS25 (if necessary for Part-Day processing)
T554E
T554R (if necessary for Public Holiday processing)
T554C
11.1.2
Time Units
Via transaction SM31, copy time units from client 000 in the following order:
T538A
T5GPBS28
T5GPBS24
11.1.3 Absence Groupings

Via transaction SM31, copy absence groupings from client 000 in the following order:
T5A4P
T554S
11.1.4 Reference Periods

Via transaction SM31, copy reference periods from client 000 in the following order:
T5GPBS20
T5GPBS21
11.1.5 Non-Qualifying Rules

Via transaction SM31, copy non-qualifying rules from client 000:
T5GPBS22
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 53 of 61
11.1.6 Schemes
Via transaction SM31, copy schemes from client 000 in the following order:
T556E
T5GPBS29
11.1.7 Scheme Rules

Via transaction SM34, copy scheme rules from client 000 in the following order:
T556G & T5GPBS23
11.1.8 Non-Payment Rules

There are no pre-delivered Non-Payment rules.
11.1.9 Entitlement Limit Rules

There are no pre-delivered Entitlement Limit Rules.
11.2
OxP delivered table entries
This section describes the actual entries that should exist in client 000. These entries are based
only on release 4.70 where the entries used in earlier releases were consolidated and organised
in a slightly different manner.
11.2.1 Payment Bands

Via transaction SM31, copy payment bands from client 000 in the following order:
T554L
11
100% Sickness
12
50% Sickness
13
100% Maternity
14
50% Maternity
15
100% Paternity
16
100% Adoption
17
100% Ind. Injury
18
Non Qual Sickness
19
Non Qual Maternity
20
Non Qual Ind. Injury
21
Non Pay Sickness
22
Non Pay Maternity
23
Non Pay Ind. Injury
24
Waiting Sickness
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 54 of 61
25
Nil Pay (Default)
26
100% Sickness
PRT
27
50% Sickness
PRT
28
100% Ind. Injury PRT
29
Nil Pay (Default)PRT
T5GPBS27
11
100% Sickness
1 Complete Payment Day
12
50% Sickness
13
100% Maternity
14
50% Maternity
15
100% Paternity
16
100% Adoption
17
100% Ind. Injury
18
Non Qual Sickness
2 Non Qualifying Day
19
Non Qual Maternity
20
21
Non Pay Sickness
5 Non Payment Day
22
Non Pay Maternity
5 Non Payment Day
23
Non Pay Ind. Injury
5 Non Payment Day
24
Waiting Sickness
3 Waiting Day
25
Nil-Pay (Default)
25
Nil-Pay (Default)
6 Nil Pay Day
26
100% Sickness
PRT 4 Part Payment Day
27
50% Sickness
PRT 4 Part Payment Day
28
100% Ind. Injury PRT 4 Part Payment Day
29
Nil-Pay (Default) PRT 4 Part Payment Day
T5GPBS25 (if necessary for Part Day processing)

11 100% Sickness
26 100% Sickness
PRT
12 50% Sickness
27 50% Sickness
17 100% Ind. Injury
28 100% Ind. Injury PRT
25 Nil Pay (Default)
29 Nil Pay (Default)PRT
PRT
T554E
10
Paid Absences
20
Unpaid Absences
21
Unpaid Sickness
22
Unpaid Maternity
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 55 of 61
23
Unpaid Industrial Injury
T554R (none pre-delivered for OxP)

T554C
MODIF 03 (Monthlies) as MODIF 01 (Hourlies) but defined in KT
MODIF 02 (Weeklies) as MODIF 01 (Hourlies) but defined in AT
MODIF 01 (Hourlies) defined in AH
11
100% Sickness
10
Paid Absences
OSFL OSP 100%

12
Paid Absences
Unpaid 50,00
21
Unpaid Sickness
Unpaid 50,00
Paid Absences
22
Unpaid Maternity
Unpaid 50,00
100,00 AH BPsplit
100% Paternity
Paid Absences
Unpaid 100,00
I
100,00 AH BPsplit
100% Adoption
Paid Absences
OAFL OAP 100%
20
100,00 AH BPsplit
Unpaid 50,00
10
19
Paid Absences
OPFL OPP 100%
18
Unpaid 100,00
10
10
17
100,00 AH BPsplit
50% Maternity
OMHF OMP 50%
16
100% Maternity
OMFL OMP 100%
15
100,00 AH BPsplit
10
10
14
50% Sickness
OSHF OSP 50%

13
Unpaid 100,00
Unpaid 100,00
I
100,00 AH BPsplit
100% Ind. Injury

10
Paid Absences
OIFL
OIP 100%
Unpaid 100,00
I
100,00 AH Bpsplit
Non Qual Sickness

21
Unpaid Sickness
Unpaid 100,00
ONIL
Nil Pay
100,00 AH BPsplit
Non Qual Maternity

22
Unpaid Maternity
Unpaid 100,00
ONIL
Nil Pay
100,00 AH BPsplit
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 56 of 61
23
21
Non Pay Sickness

21
22
Unpaid Maternity
Unpaid Industrial Injury Unpaid 100,00

Unpaid Sickness
OSWT OSP Waiting Day
26
Unpaid 100,00
ONIL
Nil Pay
100,00 AH BPsplit
100% Sickness
PRT
Time I
50% Sickness
PRT
Time I
100% Ind. Injury PRT

Time I
Nil Pay (Default)PRT

PCR GORD
11.2.2
100,00 AH BPsplit
Unpaid Absences
PCR GORD
29
20
PCR GORD
28
Unpaid 100,00
Nil Pay (Default)
PCR GORD
27
Unpaid 100,00
Waiting Sickness
21
25
Unpaid 100,00
Non Pay Ind. Injury

23
24
Unpaid Sickness
Non Pay Maternity

22
23
Unpaid Industrial Injury Unpaid 100,00
Time I
Time Units
Via transaction SM31, copy time units from client 000 in the following order:
T538A
001
Hours
010
Days
011
Weeks
012
Months
013
Years
A11
Ado week
E11
Ent week
M11
Mat week
P11
Pat week
R10
Cal Day
R12
Cal Mth
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 57 of 61
R13
Cal Year
S10
Sen Day
S11
Sen Week
S12
Sen Mth
S13
Sen Year
T5GPBS28
001
Hours
Entitlement
Multiplier
010
Days
Entitlement
Multiplier
011
Weeks
Entitlement
Multiplier
012
Months
Entitlement
Multiplier
013
Years
Entitlement
Multiplier
A11
Ado week
Entitlement
Multiplier
E11
Ent week
Entitlement
M11
Mat week
Entitlement
Multiplier
P11
Pat week
Entitlement
Multiplier
R10
Cal Day
Rollback
R12
Cal Mth
Rollback
R13
Cal Year
Rollback
S10
Sen Day
Multiplier
S11
Sen Week
Multiplier
S12
Sen Mth
Multiplier
S13
Sen Year
Multiplier
T5GPBS24
001
Hours
1/8 of a day in an "Hour"
0.125000
010
Days
1 day in an "Day"
1.000000
011
Weeks
7 days in a "Week"
7.000000
012
Months
30 Days in a "Month"
30.000000
013
Years
365 Days in a "Year"
365.000000
A11
Ado week
Payment Days in a "Adp Week"
1.000000
M11
Mat week
Payment Days in a "Mat Week"
1.000000
P11
Pat week
Payment Days in a "Pat Week"
1.000000
S10
Sen Day
Seniority Band for "Days"
1.000000
S11
Sen Week
Seniority Band for "Weeks"
7.000000
S12
Sen Mth
Seniority Band for "Months"
30.000000
S13
Sen Year
Seniority Band for "Years"
365.000000
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 58 of 61
11.2.3 Absence Groupings

Via transaction SM31, copy absence groupings from client 000 in the following order:
T5A4P
08
GG
SAP & OAP
08
MM
SMP & OMP
08
PP
SPP & OPP
08
SI
SSP & IIP
08
SS
SSP & OSP
0200
Illness
T554S
08
Screen 2008
08
0250
Industrial accident
Screen 2008
08
0600
0610
0620
Valuation Rule 02
Absence Category MM Valuation Rule 02
Paternity leave
Screen 2008
08
Absence Category SI
Maternity leave
Screen 2008
08
Absence Category SS Valuation Rule 02
Absence Category PP Valuation Rule 02
Adoption leave
Screen 2008
Absence Category GG Valuation Rule 02
11.2.4 Reference Periods

Via transaction SM31, copy reference periods from client 000 in the following order:
T5GPBS20
1
Absence Start Date

Method 1
2
3
Parameter LH
Parameter 01.01
Go Live Date 1989

Method 4
Parameter EH
Calendar Date Jan 1st (No Lnk)

Method 3
Parameter 2
Anniversary:Last Hire(No Lnk)

Method 2
(No Lnk)
Anniversary:First Hire(No Lnk)

Method 2
Parameter 1
Absence Day-By-Day
Method 1
(No Lnk)
(No Lnk)
Parameter 01.01.1990
Start Date:First Hire (No Lnk)
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 59 of 61
Method 5
8
Parameter EH
Start Date:Last Hire (No Lnk)

Method 5
Parameter LH
T5GPBS21
1
1 Calendar Year
Amount 1
Rollback Unit
2 Calendar Years
Amount 2
3 Calendar Years
Amount 4
5
Amount 5
6
Amount 6
7
Calendar Years
(No Lnk)
Rollback Unit
6 Calendar Years
Calendar Years
(No Lnk)
Rollback Unit
5 Calendar Years
Calendar Years
(No Lnk)
Rollback Unit
4 Calendar Years
Calendar Years
(No Lnk)
Rollback Unit
Amount 3
4
(No Lnk)
Calendar Years
(No Lnk)
Rollback Unit
Calendar Years
Period Not Extended (No Lnk)

Amount 0
Rollback Unit
Calendar Days
11.2.5 Non-qualifying Rules

Via transaction SM31, copy non-qualifying rules from client 000:
T5GPBS22
1
Non-Working(Sick)
Employee
Before MPP(Mat.)
Employee
Payment Band 18
Payment Band 19
Non-Working(Ind.)
Employee
Payment Band 20
11.2.6 Schemes
Via transaction SM31, copy schemes from client 000 in the following order:
T556E
08CASUAL
Employees paid casual payments
08NOSCHEME No Entitlements
08SALARY
Employees paid salaries
08WAGES
Employees paid wages
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 60 of 61
T5GPBS29
08CASUAL
Employees paid casual payments
Entweeks
Nil Pay 25
No Part Days or Part Timers
Nil Pay 25
08NOSCHEME No Entitlements
Entweeks
08SALARY
Employees paid salaries
Entweeks
08WAGES
Nil Pay 25
Employees paid wages
Entweeks
Nil Pay 25
11.2.7 Scheme Rules

Via transaction SM34, copy scheme rules from client 000 in the following order:
T556G & T5GPBS23
The following screenshot is derived from the Scheme Overview push button, but split into four
sections to make the files more manageable, and then amalgamated again.
2004 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version: 2.0
Date: January 2004
Page 61 of 61

Absence Eval Config

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Absence Eval Config

Diunggah oleh

Hak Cipta:

Format Tersedia

Version: 2.

(starting with 1.0)

Absence Evaluation Configuration OxP Configuration Explained

2 Absence Evaluation Terminology.........................................................7

3 Absence Evaluation Configuration (The Basics).................................9

4 Absence Evaluation Configuration (The Detail)..................................9

6 23 months Sick 2...............................................................................18

Absence Evaluation Configuration OxP Configuration Explained

4.4.2.1 Entitlement Amount.................................................................................21

5 Absence Evaluation Configuration (Part Days).................................28

6 Absence Evaluation Configuration (Activation)................................31

7 Absence Evaluation Configuration (Payment)...................................34

8 Absence Evaluation Configuration (Complexities)...........................35

Absence Evaluation Configuration OxP Configuration Explained

8.2.1 Normal Definitions......................................................................................36

Absence Evaluation Configuration OxP Configuration Explained

11.1.8 Non-Payment Rules.................................................................................54

Absence Evaluation Configuration OxP Configuration Explained

Project Team/Development Team

Project Role(s) / Comments

The OxP solution has been delivered in 46B onwards

There have been no particular Development Requests regarding Absence Payment

Important Note for Readers

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Terminology

Absence Evaluation is SAP terminology for a customer operating an Occupational

Absence Evaluation Schemes

Sickness Absence Rule

Maternity Absence Rule

Adoption Absence Rule

Paternity Absence Rule

Absence Evaluation Configuration OxP Configuration Explained

The Reference Period

The Payroll Structure COVER

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Configuration (The Basics)

Absence Evaluation Configuration (The Detail)

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Configuration OxP Configuration Explained

Planning the number of schemes that you will need

When an employees scheme is derived

Moving Between Schemes

Absence Evaluation Configuration OxP Configuration Explained

Defining your schemes

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Configuration OxP Configuration Explained

Pay Scale Type

Pay Scale Area

Pay Scale Group

Pay Scale Level

Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_CVR)

Infotype Absence Scheme Override (0572)

Absence Evaluation Configuration OxP Configuration Explained

Scheme Rules Based on Age & Seniority

The absence day being processed

The absence start date

The first hiring action

The most recent hiring action

The hire date according to the International Function Module HR_ENTRY_DATE.

A specific date type recorded on infotype 0041

The end date of the time period can be taken from:

The day of the absence being processed

Absence Evaluation Configuration OxP Configuration Explained