AbsenceEvalConfig - Doc-Sap Time Managment

Version: 2.
0 Date: January 2004 Release: 46B onwards Author: Gordon Rennie
Absence Evaluation Configuration

OxP Configuration Explained
History Version
(starting with 1.0)
Status
(Draft/Review Released) copy/
Date
(DD.MM.YY)
[1.0] [2.0]
[Draft] [Final]
[14.12.03] [26.01.04]
2004 SAP AG Neurottstr. 16 D-69190 Walldorf
Version: 2.0 Date: January 2004
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
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
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
Page 5 of 61
1
1.1
Name
Organisation
Project Team/Development Team
Company
SAP AG SAP UK SAP AG SAP AG
Project Role(s) / Comments

[Author] [Product Manager] [Software Developer] [Information Developer]
Gordon Rennie Maureen Gregory Gordon Rennie Lee Roberts-Baldwin
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
Page 6 of 61
2
2.1
Absence Evaluation Terminology

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).
Page 8 of 61
3
3.1
Absence Evaluation Configuration (The Basics)

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 1. Weekly Entitlements 2. Part-Day absences not allowed iv. Adoption 1. Weekly Entitlements 2. Part-Day absences not allowed 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.
Page 10 of 61
4.1
4.1.1
Scheme Definition
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 This should be used by ALL customers. 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 This should be used by ALL customers. 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.
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 WERKS BTRTL PERSG PERSK MOLGA TRFAR TRFGB TRFGR TRFST Company Code Personnel Area Personnel Subarea Employee Group Employee Subgroup Country Grouping Pay Scale Type Pay Scale Area Pay Scale Group Pay Scale Level
4.2.2
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.
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 Version: 2.0 Date: January 2004 Page 16 of 61
The absence start date 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) A calendar date (DD.MM) The absence start date The absence start date (Absence start date) (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 2 12 84 Years Months Weeks 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.
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, 0 5 months Sick 1 6 23 months Sick 2 24 35 months Sick 3 36 999 months Sick 4,
but your sickness rules are based on:

then you can define one scheme broken down as follows:
Page 18 of 61
0 5 months Sick 1 & Mat 1 6 11 months Sick 2 & Mat 1 12 23 months Sick 2 & Mat 2 24 35 months Sick 3 & Mat 2 36 999 months Sick 4 & Mat 2
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.
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.
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 b) Rollback c) Multiplier Scheme Rules (V_T5GPBS23_CL) How Far Bck/Fwd Rules (V_T5GPBS21) 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: 1) Without a Non-Qualifying Rule 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: 1) Without a Non-Qualifying Rule 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.
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 Part-Payment Day Non-Qualifying Day Waiting Days Non-Payment Days Nil-Pay Day Scheme Rules Part Day Rules Non-Qualifying Rules From Where Rules Non-payment Rules Scheme Constants V_T5GPBS23_CL V_T5GPBS25 V_T5GPBS22 V_T5GPBS20 V_T5GPBS26 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 rules is to use the Scheme Overview pushbutton.
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 your rules is to use the Scheme Overview pushbutton.
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.
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 your rules is to use the Scheme Overview pushbutton.
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.
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 rules is to use the Scheme Overview pushbutton.
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 rules is to use the Scheme Overview pushbutton. 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
5
5.1
Absence Evaluation Configuration (Part Days)

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 2 3 4 5 6 C 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
5.2.1
Activating Absence Subtype Part-Day Processing

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.
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 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.
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

Payroll, Reporting, Master Data (PA30)
6.2.1
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 HRPSG ABSRP ABSCH C W F = Full, C = Condensed & S = Summary Report X = Errors & Band Changes (W = X + Warnings) Feature 4) can be activated or de-activated by a table T77S0 constant: 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 ABSMN 12 N = Processing limit in months
6.2.5
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.
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
8
8.1
Absence Evaluation Configuration (Complexities)

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: 00 01 99 GM X No Linking Continuous Linking Interval of 1 99 days allowed 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.
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.
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 b. 2 a. EH b. LH c. 01 ... 12. Absence Start Day-by-Day Through Absence Earliest Hire Latest Hire (before absence) Employee Date Infotype 0041 (Day.Month)
2) Employee Anniversary (Public Sector)
3) Calendar Anniversary (Public Sector 1) a. DD.MM 4) Absence Recording a. DD.MM.YYYY (Day.Month.Year) 5) Employee Start Date a. EH b. LH c. 01 ... 12. 6) Calendar Anniversary a. DD.MM a. EH b. LH c. 01 ... 12. (Day.Month) Earliest Hire Latest Hire (before absence) Employee Date Infotype 0041 (Day.Month) 7) Employee Anniversary Earliest Hire Latest Hire (before absence) Employee Date Infotype 0041
8) Calendar Anniversary (Public Sector 2) a. DD.MM There are major differences between these options, but the most widely used option is Actual Absence (1/1).
8.2.2.1
Actual Absence
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.
The check window is defined by the current absence that is being processed.
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: 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 calendar 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. 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. For example, if an absence starts on 01.01.2003 and the calendar anniversary is on 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. 3) 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 calendar 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. 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.
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) 5) Non-Working Days or Holidays (Class 2) 6) Non-Working Days or Holidays (Class 3) 7) Non-Working Days or Holidays (Class 4) 8) Non-Working Days or Holidays (Class 5) 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.
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.
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.
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).
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.
Page 47 of 61
10
10.1
Appendix 2
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.
Page 48 of 61
10.2
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 034 035
Message Class HRPSGB_ABS

Rollback Method 1 only supports Parameters 1, 2 Rollback Methods 2 and 5 only support Parameters EH, LH and IT0041 Dates Rollback Method 3 only supports Parameters for the format DD.MM Rollback Method 4 only supports Parameters for the format DD.MM.YYYY Checking Linking for 'Related Absences Only' MUST have a Linking Method Waiting Days to 'serve' must have a Valuation Rule for Waiting Days Valuation Rule for Waiting Days must have Waiting Days to 'serve' Linking Method for Waiting Days must have Waiting Days to 'serve' Enter all four fields to attach a Period Work Schedule Rule (or none) Specify Non-Qualifying Days with a 'PWS rule' OR 'Emp Rel days' NOT both Valuation rule is required, if Non-Qualifying days are specified Valuation rule is NOT allowed, if Non-Qualifying days are NOT specified Waiting Day val. rule does not exist in customising (Table T5GPBS27) Absence evaluation scheme does not exist in customising (Table T556E) Absence subtype category does not exist in customising (Table T5A4P) Enter BOTH absence subtype category and valuation rule (or neither) Fill whole line correctly (absence category and valuation class empty). Fill only one of 'extension in days' or 'reduction in days'. Fill either of 'extension in days' or 'reduction in days'. Valuation rule is required, if Non-Payment days are specified Valuation rule is NOT allowed, if Non-Payment days are NOT specified Personnel Work Schedule rule does not exist in customising (Table T508A) Abs. Eval. Scheme rule does not exist in customising (Table T556G) Time Unit/Measurement does not exist in customising (Table T538A) How Far Bck/Fwd rule does not exist in customising (Table T5GPBS21) From Where rule does not exist in customising (Table T5GPBS20) Non-qualifying Days rule does not exist in customising (Table T5GPBS22) Rollback Time Unit does not exist in customising (Table T5GPBS28) Entitlement Time Unit does not exist in customising (Table T5GPBS28) Multiplier Time Unit does not exist in customising (Table T5GPBS28) First character of an absence grouping must be an 'S', 'M', or '.' Offsetting Wage Type is ONLY for SMP-able or SSP-able abs. grouping Valuation rule does not exist in customising (Table T554L) Complete Day val. rule does not exist in customising (Table T5GPBS27) Version: 2.0 Date: January 2004 Page 49 of 61
036 037 038 039 040 041 042 043 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077
Part Day val. rule does not exist in customising (Table T5GPBS27) Non-Qualifying val. rule does not exist in customising (Table T5GPBS27) Non-Payment val. rule does not exist in customising (Table T5GPBS27) Nil Pay Day val. rule does not exist in customising (Table T5GPBS27) Lieu Days processing is NOT allowed unless 'Working Days Only' qualify Enter both fields for Lieu Days processing or neither. Limiting rule does not exist in customising (Table T5GPBS30) Override the Scheme or an extend/reduce an Absence Payment Band. Part Day Valuation Rule &2 not in customising (T5GPBS25) ( &1 ) Error in Customer Exit 'LEN' for Time Unit &1 Non-Qualifying Day Rule &2 not in customising (T5GPBS22) ( &1 / &3 ) Non-Qualifying Day Rule &2 customising incomplete (T5GPBS22) ( &1 / &3 ) Personnel Work Schedule Rule not valid during absence ( &1 &2 &3 &4 ) Employee's Personnel Shift Plan is invalid on &1 Check Window End Rule &2 not in customising (T5GPBS20) ( &1 / &3 ) Unsupported Combination Of Rollback Method &1 and Parameter &2 Insufficient Employee Data for Rollback Method &1 with Parameter &2 Check Window Start Rule &2 not in customising (T5GPBS21) ( &1 / &3 ) Absence Collision: &1 has more than 1 day's entitlement, check absences Error in Customer Exit 'ENT' for Check Period &1 to &2 on &3 Valuation Rule &1 has no offsetting Wage Type at &2 (Table T554C) Error in Customer Exit 'NIL' for Absence Subtype &1 Part Day processing failed. Absence record '&1' missing from table AB Part Day processing failed. NOT a part day Valuation Rule &2 ( AB &1 ) Part Day Valuation Rule &2 not in customising (T5GPBS25) (AB &1 ) Non-Payment Day Rule customising incomplete (T5GPBS26) ( &1 &2 &3 &4 ) Rollback Period Units 'R??' are reserved by SAP, use 'Z??' instead of &1 Entitlement Units 'E??' are reserved by SAP, use 'Z??' instead of &1 Error in Customer Exit 'MTH' for Rollback Method &1 & Parameter &2 No record exists for &1 and &2 in Personnel Area/Subarea (Table T001P) No record exists for &1 and &2 in Employee Groups/Subgroups (Table T503) No record exists for &1 &2 and &3 in Attendance and Absence Types (T554S) Employee has no Org. Assignment on &1 (Infotype 0001) Employee has no Planned Working Time on &1 (Infotype 0007) No customising exists for End Rules (T5GPBS20) No customising exists for Start Rules (T5GPBS21) Version: 2.0 Date: January 2004 Page 50 of 61
078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113
No customising exists for Non-Qualifying Day Rules (T5GPBS22) No customising exists for Absence Evaluation Scheme Rules (T5GPBS23) Maximum part day absence splits exceeded on &1 ( caused by Part Day &2 ) Maximum part day absence splits reach on &1 ( data lost for Part Day &2 ) Entitlement Used (issued on &1): &2 of '&3' for '&4' absence The feature GLOSS passes back &1 which is not supported (1-8 only) Checking AUTOMATIC absence splitting in Payroll (Re: Abs. Eval. Scheme) Checking MANUAL absence splitting in Absence Entry (Re:Abs. Eval. Scheme) Checking MANUAL absence splitting in Absence Entry (Re: Bespoke Report) No AUTOMATIC splitting of this absence will occur in Payroll No MANUAL splitting of this absence is necessary (Re: Abs. Eval. Scheme) No MANUAL splitting of this absence is necessary (Re: Bespoke Report) Employee &1 is not attached to a scheme. Employee has no Basic Payments on &1 (Infotype 0008) No Employee Group/Subgroup exist for &1 &2 (Table T503) No Standard Working Hours exist for &1 &2 &3 &4 (Table T510I) No Scheme Switches exist for &1 &2 &3 (Table T5GPBS29) Employee has no Maternity Details between &1 and &2 (Infotype 0088) Shift Worker requires EntWeek Time Unit indicator set (Table T5GPBS29) Seniority Time Unit &1 is NOT defined in customising (Table T5GPBS24) Previous Service from Date Specifications (IT041) requires a Date Type. Date Type &1, to calculate Previous Service, does not exist (Table T548Y) Employee has no Date Specification in Infotype 0041 for Date Type &1 Limit Rule &2 not in customising (T5GPBS30) ( &1 / &3 ) Payment Band Changed from '&1' to '&2' on &3 for '&4' absence Val. Rule &1 ( &2 / &3 ) is not allowed a Counting Class or a Wage Type The employee's PS Grouping changes from &1 to &2 on &3. Seniority/Age "As At Date" is missing. Feature GLOSS or GAGES incorrect Seniority/Age "As At Date" &1 must be in the format "DD.MM" Employee has no Date of Birth at &1 (Infotype 0002) Age Calculation Type &1 is NOT supported (Check FEATURE GAGES) Employee changes Absence Scheme during absence (on &1 from &2 to &3) Offsetting wage type &1 not in payroll table &2, check customising in IMG Offsetting Wage Type &1 does not have the correct valuation basis on &2 Employee has many Go Live dates; The Latest &1 will be used. Employee has absences overlapping their LATEST Go Live date &1. Version: 2.0 Date: January 2004 Page 51 of 61
114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130
Go Live date &1 is NOT in the date range selected &2 - &3 BOTH Absence Grouping & Payment Band are MANDATORY (T5GPBS31 &1 &2 &3 ) Non-Payment Rule has no UNPAID Valuation Cls for &1 on &2. (&3) Activate Unpaid OMP Dates to enter Paid Payment Band/Unpaid Payment Band Enter BOTH Paid Payment Band 1 and Unpaid Payment Band 1 Enter BOTH Paid Payment Band &1 and Unpaid Payment Band &1 (or neither) Fill earlier gaps before Paid Payment Band &1 and Unpaid Payment Band &1 Entitlement Amount, &1 days, exceeds possible expected life span! Entitlement Limit rules 1 and 2 cannot be the same. Go Live Date &1 is not in the format YYYYMMDD (Feature GLIVE) Conversion not possible; GPNAB still active (T77S0: HRPSG/GPNAB) Conversion not necessary; Part Day processing is not active (T5GPBS29) MPP Start Date not entered yet; Earliest MPP Start Date used (IT0088) Internal Error: During generation of payroll structure COVER on &1 ENTWEEKS must have a rule specified in T5GPBS29 (See Note 541144) EXACT Part Day Processing is obsolete T5GPBS29 (See Note 541144) Scheme &1 has overlapping scheme rules (View Cluster V_T5GPBS23_CL)
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
T538A
Time Units
Via transaction SM31, copy time units from client 000 in the following order: 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 12 13 14 15 16 17 18 19 20 21 22 23 24 100% Sickness 50% Sickness 100% Maternity 50% Maternity 100% Paternity 100% Adoption 100% Ind. Injury Non Qual Sickness Non Qual Maternity Non Qual Ind. Injury Non Pay Sickness Non Pay Maternity Non Pay Ind. Injury Waiting Sickness Version: 2.0 Date: January 2004 Page 54 of 61
25 26 27 28 29 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 25 26 27 28 29
Nil Pay (Default) 100% Sickness 50% Sickness PRT PRT
100% Ind. Injury PRT Nil Pay (Default)PRT 100% Sickness 50% Sickness 100% Maternity 50% Maternity 100% Paternity 100% Adoption 100% Ind. Injury Non Qual Sickness Non Qual Maternity Non Qual Ind. Injury Non Pay Sickness Non Pay Maternity Non Pay Ind. Injury Waiting Sickness Nil-Pay (Default) Nil-Pay (Default) 100% Sickness 50% Sickness 1 Complete Payment Day 1 Complete Payment Day 1 Complete Payment Day 1 Complete Payment Day 1 Complete Payment Day 1 Complete Payment Day 1 Complete Payment Day 2 Non Qualifying Day 2 Non Qualifying Day 2 Non Qualifying Day 5 Non Payment Day 5 Non Payment Day 5 Non Payment Day 3 Waiting Day 1 Complete Payment Day 6 Nil Pay Day PRT 4 Part Payment Day PRT 4 Part Payment Day
T5GPBS27
100% Ind. Injury PRT 4 Part Payment Day Nil-Pay (Default) PRT 4 Part Payment Day 26 100% Sickness 27 50% Sickness PRT PRT
T5GPBS25 (if necessary for Part Day processing) 11 100% Sickness 12 50% Sickness 17 100% Ind. Injury 25 Nil Pay (Default) T554E 10 20 21 22 Paid Absences Unpaid Absences Unpaid Sickness Unpaid Maternity Version: 2.0 Date: January 2004 Page 55 of 61
28 100% Ind. Injury PRT 29 Nil Pay (Default)PRT
23 T554C
Unpaid Industrial Injury
T554R (none pre-delivered for OxP) 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 12 Paid Absences I Unpaid 100,00 100,00 AH BPsplit Unpaid 50,00 Unpaid 50,00 100,00 AH BPsplit Unpaid 100,00 I 100,00 AH BPsplit Unpaid 50,00 Unpaid 50,00 100,00 AH BPsplit Unpaid 100,00 I 100,00 AH BPsplit Unpaid 100,00 I 100,00 AH BPsplit Unpaid 100,00 I 100,00 AH Bpsplit Unpaid 100,00 100,00 AH BPsplit Unpaid 100,00 100,00 AH BPsplit I I OSFL OSP 100% 50% Sickness 10 21 13 Paid Absences Unpaid Sickness
OSHF OSP 50% 100% Maternity 10 14 Paid Absences OMFL OMP 100% 50% Maternity 10 22 15 Paid Absences
Unpaid Maternity
OMHF OMP 50% 100% Paternity 10 16 Paid Absences OPFL OPP 100% 100% Adoption 10 17 Paid Absences OAFL OAP 100% 100% Ind. Injury 10 OIFL 18 21 ONIL 19 22 ONIL 20 Paid Absences OIP 100%
Non Qual Sickness Unpaid Sickness Nil Pay I
Non Qual Maternity Unpaid Maternity Nil Pay I
Non Qual Ind. Injury Version: 2.0 Date: January 2004 Page 56 of 61
23 21 22 23 24 21 22 23 21 25
Unpaid Industrial Injury Unpaid 100,00 Unpaid Sickness Unpaid Maternity Unpaid 100,00 Unpaid 100,00
Non Pay Sickness Non Pay Maternity Non Pay Ind. Injury Unpaid Industrial Injury Unpaid 100,00 Unpaid Sickness Unpaid 100,00 I 100,00 AH BPsplit Waiting Sickness OSWT OSP Waiting Day Nil Pay (Default) 20 ONIL Unpaid Absences Nil Pay PRT Time I PRT Time I Time I Time I I Unpaid 100,00 100,00 AH BPsplit
26 27 28 29
100% Sickness PCR GORD 50% Sickness PCR GORD PCR GORD PCR GORD
100% Ind. Injury PRT Nil Pay (Default)PRT
11.2.2
T538A 001 010 011 012 013 A11 E11 M11 P11 R10 R12
Time Units
Via transaction SM31, copy time units from client 000 in the following order: Hours Days Weeks Months Years Ado week Ent week Mat week Pat week Cal Day Cal Mth Version: 2.0 Date: January 2004 Page 57 of 61
R13 S10 S11 S12 S13 001 010 011 012 013 A11 E11 M11 P11 R10 R12 R13 S10 S11 S12 S13 001 010 011 012 013 A11 M11 P11 S10 S11 S12 S13
Cal Year Sen Day Sen Week Sen Mth Sen Year Hours Days Weeks Months Years Ado week Ent week Mat week Pat week Cal Day Cal Mth Cal Year Sen Day Sen Week Sen Mth Sen Year Hours Days Weeks Months Years Ado week Mat week Pat week Sen Day Sen Week Sen Mth Sen Year 1/8 of a day in an "Hour" 1 day in an "Day" 7 days in a "Week" 30 Days in a "Month" 365 Days in a "Year" Payment Days in a "Adp Week" Payment Days in a "Mat Week" Payment Days in a "Pat Week" Seniority Band for "Days" Seniority Band for "Weeks" Seniority Band for "Months" Seniority Band for "Years" Rollback Rollback Rollback Multiplier Multiplier Multiplier Multiplier 0.125000 1.000000 7.000000 30.000000 365.000000 1.000000 1.000000 1.000000 1.000000 7.000000 30.000000 365.000000 Entitlement Entitlement Entitlement Entitlement Entitlement Entitlement Entitlement Entitlement Entitlement Multiplier Multiplier Multiplier Multiplier Multiplier Multiplier Multiplier Multiplier
T5GPBS28
T5GPBS24
Page 58 of 61
11.2.3 Absence Groupings

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

Via transaction SM31, copy reference periods from client 000 in the following order: T5GPBS20 1 2 3 4 5 6 7 Absence Start Date Method 1 Method 1 Method 2 Method 2 Method 3 Method 4 2004 SAP AG Neurottstr. 16 D-69190 Walldorf Absence Day-By-Day (No Lnk) (No Lnk) Parameter 1 Parameter 2 Parameter EH Parameter LH Parameter 01.01 (No Lnk) Parameter 01.01.1990 Version: 2.0 Date: January 2004 Page 59 of 61
Anniversary:First Hire(No Lnk) Anniversary:Last Hire(No Lnk) Calendar Date Jan 1st (No Lnk) Go Live Date 1989
Start Date:First Hire (No Lnk)
Method 5 8 Method 5 T5GPBS21 1 2 3 4 5 6 7
Parameter EH Parameter LH (No Lnk) Calendar Years Calendar Years Calendar Years Calendar Years Calendar Years Calendar Years Calendar Days (No Lnk) (No Lnk) (No Lnk) (No Lnk) (No Lnk)
Start Date:Last Hire (No Lnk)
1 Calendar Year Amount 1 Amount 2 Amount 3 Amount 4 Amount 5 Amount 6 Amount 0 2 Calendar Years 3 Calendar Years 4 Calendar Years 5 Calendar Years 6 Calendar Years
Rollback Unit Rollback Unit Rollback Unit Rollback Unit Rollback Unit Rollback Unit Rollback Unit
Period Not Extended (No Lnk)
11.2.5 Non-qualifying Rules

Via transaction SM31, copy non-qualifying rules from client 000: T5GPBS22 1 2 3 Non-Working(Sick) Employee Employee Employee 1 2 1 Payment Band 18 Payment Band 19 Payment Band 20 Before MPP(Mat.) Non-Working(Ind.)
11.2.6 Schemes
Via transaction SM31, copy schemes from client 000 in the following order: T556E 08CASUAL 08SALARY 08WAGES Employees paid casual payments Employees paid salaries Employees paid wages Version: 2.0 Date: January 2004 Page 60 of 61 08NOSCHEME No Entitlements
T5GPBS29 08CASUAL Employees paid casual payments 3 Nil Pay 25 Nil Pay 25 4 4 Nil Pay 25 Nil Pay 25 No Part Days or Part Timers No Part Days or Part Timers No Part Days or Part Timers No Part Days or Part Timers Entweeks Entweeks 08SALARY 08WAGES Entweeks Entweeks
08NOSCHEME No Entitlements Employees paid salaries Employees paid wages
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.
Page 61 of 61

AbsenceEvalConfig - Doc-Sap Time Managment

Diunggah oleh

Informasi Dokumen

Judul Asli

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

AbsenceEvalConfig - Doc-Sap Time Managment

Diunggah oleh

Hak Cipta:

Format Tersedia

Version: 2.

0 Date: January 2004 Release: 46B onwards Author: Gordon Rennie

Absence Evaluation Configuration

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

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

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

Absence Evaluation Configuration OxP Configuration Explained

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

Absence Evaluation Configuration OxP Configuration Explained

Project Role(s) / Comments

Gordon Rennie Maureen Gregory Gordon Rennie Lee Roberts-Baldwin

The OxP solution has been delivered in 46B onwards

Important Note for Readers

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Terminology

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

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

Absence Evaluation Configuration OxP Configuration Explained

Absence Evaluation Configuration (The Basics)

Absence Evaluation Configuration (The Detail)

Absence Evaluation Configuration OxP Configuration Explained

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

Absence Evaluation Configuration OxP Configuration Explained

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

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

Absence Evaluation Configuration OxP Configuration Explained

Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_CVR)

Infotype Absence Scheme Override (0572)

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Version: 2.0 Date: January 2004

Absence Evaluation Configuration OxP Configuration Explained

Scheme Rules Based on Age & Seniority

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

2004 SAP AG Neurottstr. 16 D-69190 Walldorf

Absence Evaluation Configuration OxP Configuration Explained