absenceevalconfig_doc-sap time managment

Absence Evaluation Configuration

Absence Evaluation Configuration OxP Configuration Explained

Version: 2.0Date: January 2004Release: 46B onwardsAuthor: Gordon Rennie

Absence Evaluation

Configuration

OxP Configuration Explained

History

Version(starting with 1.0)Status (Draft/Review copy/ Released)Date(DD.MM.YY)

[1.0][Draft][14.12.03]

[2.0][Final][26.01.04]

Contents

61Organisation

61.1Project Team/Development Team

61.2Project Plan

61.3Development Requests

61.4Important Note for Readers

72Absence Evaluation Terminology

72.1Absence Evaluation

72.2Absence Evaluation Schemes

82.3The Reference Period

82.4The Payroll Structure COVER

93Absence Evaluation Configuration (The Basics)

93.1Legislative Rules

93.2Employers Rules

93.3SAP Rules

94Absence Evaluation Configuration (The Detail)

114.1Scheme Definition

114.1.1Planning the number of schemes that you will need

114.1.2When an employees scheme is derived

114.1.3Moving Between Schemes

124.1.4Defining your schemes

154.2Scheme Attachment

154.2.1Feature COVER

154.2.2Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_CVR)

154.2.3Infotype Absence Scheme Override (0572)

164.3Scheme Rules Based on Age & Seniority

164.3.1Age Calculation

164.3.2Seniority Calculation

184.4Defining your Scheme Rules

184.4.1Scheme Rules

184.4.1.1Minimise the number of schemes

186 23 months Sick 2

194.4.1.2No Gaps and No Overlaps

194.4.1.3Exclusive Range Ends

204.4.1.4Period of Validity

214.4.2Entitlement Bands

214.4.2.1Entitlement Amount

214.4.2.1.1Entitlement Time Units

234.4.2.2Absence Grouping

244.4.2.2.1What does Exact Absence Grouping Only mean

244.4.2.2.2How is an Absence Grouping attached to an absence subtype?

244.4.2.3Payment Band

254.4.2.3.1Ordering Payment Bands

254.4.2.4Reference Period

254.4.2.5Non-Qualifying Days

264.4.2.6Warning Period

274.5Checking your Scheme Rules

285Absence Evaluation Configuration (Part Days)

285.1Activating Scheme Part-Day Processing

285.1.1Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_MIN)

285.2Activating Absence Subtype Part-Day Processing

285.2.1GPNAB

295.2.2XNAB

295.3Part Day Payroll Processing

295.3.1XNAB

295.3.2GPNAB

295.3.3Complete & Part Day Payment Bands

316Absence Evaluation Configuration (Activation)

316.1.1Absence Evaluation via XNAB

316.1.2Absence Evaluation via GPNAB

326.1.3Why should I use GPNAB, when XNAB is available?

326.2Absence Evaluation simulation

326.2.1Absence Evaluation during payroll

326.2.2Absence Evaluation during reporting

326.2.3Absence Evaluation during Master Data

336.2.4MP200000 Screen 2008

336.2.5Testing your implementation

347Absence Evaluation Configuration (Payment)

347.1Updating Counting Classes

347.2Creating Wage Types

347.3Part-Period Factoring

358Absence Evaluation Configuration (Complexities)

358.1Linking Absences

368.2Reference Periods

368.2.1Normal Definitions

378.2.2From Where Rules

378.2.2.1Actual Absence

388.2.2.2Employee Anniversary

388.2.2.3Calendar Anniversary

398.2.2.4Absence Recording

398.2.2.5Customer-Specific

398.2.3How Far Back/Forward Rules

408.3Waiting Days

418.4Non-Qualifying Rules

418.4.1By Default

418.4.2Employee-Based

438.5Entitlement Limits

448.5.1Using the Entitlement Limit Fields

448.5.2Defining an Entitlement Limit

448.5.3Overriding an Entitlement Limit

459Appendix 1

459.1Non-payment Days

459.2Public Holidays

459.2.1Public Holidays that reduce entitlement

459.2.2Public Holidays that do not reduce entitlement

469.3OxP Processed and Held in Hours

469.4Customer-Specific Time Units

469.5Customer-Specific Rollback Methods

469.6Customer-Specific Linking

469.7Customer-Specific Entitlements

4810Appendix 2

4810.1OxP Messages

4910.2Message Class HRPSGB_ABS

5311Appendix 3

5311.1Dependencies between OxP-delivered table entries

5311.1.1Payment Bands

5311.1.2Time Units

5311.1.3Absence Groupings

5311.1.4Reference Periods

5311.1.5Non-Qualifying Rules

5411.1.6Schemes

5411.1.7Scheme Rules

5411.1.8Non-Payment Rules

5411.1.9Entitlement Limit Rules

5411.2OxP delivered table entries

5411.2.1Payment Bands

5711.2.2Time Units

5911.2.3Absence Groupings

5911.2.4Reference Periods

6011.2.5Non-qualifying Rules

6011.2.6Schemes

6111.2.7Scheme Rules

1 Organisation

1.1 Project Team/Development TeamNameCompanyProject Role(s) / Comments

Gordon RennieSAP AG[Author]

Maureen GregorySAP UK[Product Manager]

Gordon RennieSAP AG[Software Developer]

Lee Roberts-BaldwinSAP AG[Information Developer]

1.2 Project Plan

The OxP solution has been delivered in 46B onwards

1.3 Development Requests

There have been no particular Development Requests regarding Absence Payment documentation or guidance for customising Absence Payments. However, there are an increasingly substantial number of OSS messages as more customers try to use the new functionality that made the creation of this document desirable.

1.4 Important Note for Readers

This document is one of a series of three describing statutory (SxP) and occupational (OxP) absences in greater detail. SAP strongly recommends that you also consult the other documents in this series:

Absence Evaluation DTO: OxP Data-Take-On

Paying SxP and OxP: Payment and Offsetting Explained

2 Absence Evaluation Terminology2.1 Absence Evaluation

Absence Evaluation is SAP terminology for a customer operating an Occupational Sickness/Maternity/Adoption/Paternity Scheme (collectively known as OxP) to control the payment of their employees while they are absent from work due to a Sickness, Maternity, Adoption or Paternity absence .

2.2 Absence Evaluation SchemesAbsence 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 RuleAn 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 RuleAn 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 RuleAn 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 RuleAn 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 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 COVERThe 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).

3 Absence Evaluation Configuration (The Basics)3.1 Legislative RulesThere 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 RulesThe 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 RulesThe 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.4 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.

The business rules necessary for absence processing in Payroll GB breakdown as follows:

1) Employee-Group-Specific

i. Employee Groups (Company Code, Location)

ii. Pay Frequency (Calendar days, Working Days, Working Hours)

iii. Contract Type (Permanent, Fixed-Term, Casual)

2) Employee-Specific

i. Age

ii. Seniority

3) Absence-Specific

i. Sickness

1. Monthly, Weekly, Daily or Hourly entitlements

2. Part-Day absences are allowed

ii. Maternity

1. Weekly Entitlements

2. Part-Day absences not allowed

iii. Paternity



iv. Adoption



It is important to realise that although your business rules will usually be broken down into these three levels, this does not mean that your schemes should be broken down to this level. For instance, scheme rules will tend to vary as above, but there is no reason to create four different schemes for the four absences that will apply for one specific employee group. Normally, one scheme per employee group will suffice.

The rules that are age- or seniority-specific are always catered for within a scheme. There is no need to differentiate at scheme level when this is possible within a scheme.

4.1 Scheme Definition4.1.1 Planning the number of schemes that you will needIt 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 derivedAn 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 SchemesIf 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.

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 schemesDefine 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 ProcessingThis 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 part- day 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 ProcessingThis should be used by ALL customers.

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

4.2 Scheme AttachmentAfter 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

Company Code

WERKSPersonnel Area

BTRTL

Personnel Subarea

PERSG

Employee Group

PERSK

Employee Subgroup

MOLGACountry Grouping

TRFAR

Pay Scale Type

TRFGB

Pay Scale Area

TRFGR

Pay Scale Group

TRFST

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.

4.3 Scheme Rules Based on Age & SeniorityThe 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 CalculationHow 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 CalculationHow 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 re-employment.

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


The start of the Maternity Pay Period (MPP) (GB Maternity)

The Expected Date of Birth (GB Maternity)

The Expected Week of Childbirth/Confinement (EWC) (GB Maternity)

The Qualifying Week (QW) (GB Maternity)

A calendar date (DD.MM) (Absence start date)

A calendar date (DD.MM) (Absence day being processed)


(exclusive continuous linking)


(continuous linking)

The 11th Week before the EWC (GB Maternity)

The start of the Adoption Pay Period (APP) (GB Adoption)

The Matching Week (MW) (GB Adoption)

The start of the Paternity Pay Period (PPP) (GB Paternity)

The QW/MW (GB Paternity)

The type of calculation used between these two dates can be a simple duration or a comprehensive Seniority Calculation (See the IMG section under Personnel Administration -> Evaluation Basis -> Calculation of Employment Period.)These three sets of options are defined using the feature GLOSS, but the most commonly used setting will be CBE, as follows:

C: The start date is defined by the international functionality of the feature ENTRY to derive the employees hire date.

B: The end date is defined by the absence start date.

E: The calculation is simply the number of days, weeks, months & years between the start and end date.

Example for Feature GLOSS

An employee is hired on 01.06.2003 and takes sickness absence on 24.08.2003. If CBE has been customised, then the employees seniority is:

0 Years

2 Months

12 Weeks

84 Days

Note that the 23 days beyond the two month anniversary in August have no effect. The employee has only been employee for two whole months not three months. (The 2.74 months are not rounded up.)

So seniority ranges (and age ranges) must be defined as inclusive for the start and exclusive for the end. So this employee would fall into a 0 2 month seniority range and not the following 3 6 month range.

4.4 Defining your Scheme Rules

The View Cluster provided to maintain your scheme rules is V_T5GPBS23_CL, accessed via transaction SM34.

The rules are attached to a scheme at two levels:

1) Scheme Rule

i. Age Range

ii. Seniority Range

iii. Date Range

2) Entitlement Bands

i. Entitlement Amount

ii. Absence Grouping

iii. Payment Band

iv. Reference Period

v. Non-Qualifying Days

4.4.1 Scheme Rules

The first and higher level for attaching rules to your schemes is based on a one-to-many relationship. The rule number field simply supports the one to many relationship. It does not imply an order in which the scheme rules must be applied. All rules will be applied, but only the rule that has the matching Age, Seniority and Date Range will be processed.

Each scheme can have many ranges of seniority and age.

4.4.1.1 Minimise the number of schemes

It is important to realise that these scheme rules will need to incorporate all your various seniority (and age) ranges for the entire scheme.

Therefore, if your Maternity rules are based on:

0 11 months Mat 1

12 999 months Mat 2,

but your sickness rules are based on:

0 5 months Sick 1

6 23 months Sick 2

24 35 months Sick 3

36 999 months Sick 4,

then you can define one scheme broken down as follows:

0 5 months Sick 1 & Mat 1





There is NO need to have two separate schemes.

4.4.1.2 No Gaps and No Overlaps

The available time units are DAYS, WEEKS, MONTHS and YEARS. You can only mix time units DAYS and WEEKS. You cannot mix MONTHS and YEARS because there are situations where gaps and overlaps will appear. Therefore, choose one time unit for all your ranges. If you do have overlapping ranges, then an employee who has an overlap and is absent during that overlapping period will receive the following error message during infotype 2001 and payroll processing:

Absence Collision: &1 has more than 1 days entitlement, check absences

This message can also occur if you have overlapping absences, though this will be a much rarer cause of the problem. The message implies that more than one complete day of entitlement is being used due to overlapping rules or overlapping absences.

4.4.1.3 Exclusive Range Ends

The seniority and age ranges have a start and an end. The start is very simple to understand, the end is not so simple. Due to the nature of the seniority/age calculations, the ranges cannot overlap and should not include the upper limit.

Example

If your rules state in the first 12 months of employment an employee will receive.

Then most people would translate this to a range of 0 12 months and probably the next range would run from 12 - ??? months. But these two ranges overlap. An employee with 12 months seniority will receive both sets of entitlements. The range should be defined as:

0 11 months and

12 - ??? months

This will mean that in the first year of service the employee will be in the first range, and from then on they will be in the second range.

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.

4.4.2 Entitlement Bands

The second and lower level for attaching rules to your schemes is also based on a one-to-many relationship. The sequence number field simply supports the one-to-many relationship. It does not imply an order in which the Entitlement Band will be processed.

Each seniority, age and date range can have many entitlement bands. An entitlement band is an amount of entitlement for a specific type of absence (i.e. Maternity) that will be paid at a specific payment rate (Full-Pay), that will have a specific reference period that checked for already used entitlements and may have non-qualifying days. Optionally, a warning period can also be assigned to each Entitlement Band.

There is also one other type of rule that can be attached to an entitlement band (Entitlement Limit rules), but this is not widely used and is discussed in Appendix 1.

4.4.2.1 Entitlement Amount

The Entitlement Amount defines the maximum amount of entitlement that can be received during the reference period.

The amount field is very simple to understand. The time units are not so simple.

4.4.2.1.1 Entitlement Time Units

In some cases, because your business rules state that entitlements should be defined in one time unit, this does not mean that you should actually use that time unit. Some time units seem suitable in theory, but are impractical.

The time units used in OxP configuration are defined in table T538A, but are filtered for specific use during the OxP configuration in table T5GPBS28.

The uses available are;

a) Entitlement

Scheme Rules (V_T5GPBS23_CL)

b) Rollback

How Far Bck/Fwd Rules (V_T5GPBS21)

c) Multiplier

Multipliers (V_T5GPBS24)

The recommended time units used for entitlement are Weeks (011) and Entweeks (E11). The possible time units are:

1. Weeks (011)

The number of calendar days in a week is a mathematical certainty. This makes comprehension very simple for the business as whole. It is important that Weeks (011) are used:

1) Without a Non-Qualifying Rule

2) For employees paid on a calendar day basis

If weeks are used with a Non-Qualifying Rule, then the whole principle of what a week stands for has been changed. A week will become employee-specific, depending on which days qualify or do not qualify.

EXAMPLE

An employee is given 5 weeks entitlement and their 5 working days per week reduce that entitlement. If a colleague has the same entitlement, as they do a very similar task, but only works 4 days a week, then either their entitlement will have to be adjusted using the Part 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:


2) For employees that are paid on a calendar day basis

5. Hours (001)

Hours (001) can be used in conjunction with feature GENTT set to X and the multiplier set to 0.041666. This give a close approximation to an accurate solution, but even this remains problematic:

a) Minor rounding issues will appear as the multiplier should really be 0.041666 recurring, not 0.041666 exactly.

b) Using hours necessarily implies that you must set up scheme rules for groups of employees based on the number of hours that they work in a week. This will necessitate a very large number of schemes, as you will have to cater for all the different work schedules that an employee may have.

c) Employees who are substituted by other colleagues with a different work pattern, or employees who change their work schedule require a complete recalculation of their entitlements.

Also, hourly entitlements can be catered for accurately by having employees Entweeks configured as a multiple of the number of Planned Working Hours.

6. Months (012)

Months (012) can be used with the multiplier set to 30.00000 or 31.00000, but even this will produce problems. The definition of 30 or 31 days in a month is not practical.

How does someone without any technical business knowledge know how many days there are in a month?

Months (012) can be used with minimal side effects as long as you use Calendar Days for part period factoring and absence payments in payroll. If you are using working days for part period factoring and absence payments in payroll, then Months (012) has exactly the same problem as Weeks (011) (see above).

It is important that Months (012) are used:


2) For employees that are paid on a calendar day basis

4.4.2.2 Absence Grouping

An Absence Grouping defines which absence subtypes will reduce this entitlement band.

The absence groupings are defined in table T5A4P. The SAP-delivered groupings are GG, .M, MM, PP, .S and SS. The first character is used for SxP and the second character is used for OxP. For an absence to reduce the entitlement of the same absence grouping, the second character must exactly match. The Exact Absence Grouping Only checkbox deals with whether or not the first character has to match as well as the second. This is discussed in the next section.

If you need to create your own absence groupings, then ensure that you do not use G, M, P or S as the first character, as this will imply that the absence is subject to SAP, SMP, SPP or SSP respectively.

The simplest way to check that the Absence Groupings have been set consistently across all your rules is to use the Scheme Overview pushbutton.

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 non-smp-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 DayScheme Rules V_T5GPBS23_CL

Part-Payment Day Part Day Rules V_T5GPBS25

Non-Qualifying DayNon-Qualifying Rules V_T5GPBS22

Waiting DaysFrom Where Rules V_T5GPBS20

Non-Payment DaysNon-payment Rules V_T5GPBS26

Nil-Pay DayScheme Constants V_T5GPBS29

How the payment bands will actually effect payroll is defined in table T554C.

It is important to realise that one Payment Band can be used for many employee groups ( Weekly and Monthly paid). The Absence Modifier (Modifier 0A in table MODIF) can vary the payroll customising for each specific grouping. The payment band should only be broken down into Absence type and Payment type.

The simplest way to check that the Payment Bands have been set consistently across all your rules is to use the Scheme Overview pushbutton.

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.

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/5th of the SSP weekly rate, whereas 1/5th 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 non-qualifying 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.

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.

5 Absence Evaluation Configuration (Part Days)5.1 Activating Scheme Part-Day Processing

In the GPNAB and XNAB solutions, a Part-Day absence will ONLY be processed if Part-Day processing has been activated for that employees scheme (V_T5GPBS29).

Part Days Not Allowed

1Half Day if AB [Inc. Breaks] >= (PSP [Inc. Breaks] / 2)

2Half Day if AB [Inc. Breaks] >= (PSP [Exc. Breaks] / 2)

3Half Day if AB [Exc. Breaks] >= (PSP [Inc. Breaks] / 2)

4Half Day if AB [Exc. Breaks] >= (PSP [Exc. Breaks] / 2)

5Elapsed Hours AB [Inc. Breaks]

6Elapsed Hours AB [Exc. Breaks]

CCustomer-Specific (Customer Exit)

Part Days Not Allowed will be the option selected by most customers. This implies that the absence will not be processed by GPNAB or XNAB, but instead will be paid according to the valuation rule that is attached in table T554S. It is important that you decide (as a default) how these days should be paid in these cases. Normally, they will not reduce Part Period Factoring or generate any Payment Wage Types and so will, in fact, be ignored by the payroll for the most part.

Options 1-4 above are a variation on the same theme. If you are absent for more than a half day, but less than a whole day, then you will reduce your entitlements by a day and receive a day payment.

Options 5-6 are for customers wishing to process absences in exact hours. Generally, choosing the second of these two is more sensible, as this option would only be used for employees paid on an hourly basis and this would normally be a working hours basis (excluding breaks).

Option C is covered in the next section

5.1.1 Customer Exit (EXIT_SAPLHRGPBS_OSP_OMP_MIN)

In the GPNAB and XNAB solutions, it is possible to define how a Part Day should be treated. There are six pre-delivered options as described in 5.1, but a customer exit has also been provided to allow customers to provide any solution they wish. If you wish to use the customer exit provided, then use option C and code the exit as you require.

5.2 Activating Absence Subtype Part-Day Processing

5.2.1 GPNAB

In the GPNAB solution, any absence subtype will be processed if a Part-Day absence has been entered using that absence subtype. The maximum and minimum duration fields on table T554S already control whether or not a Part-Day absence can be entered using a specific subtype.

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

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.

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

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

HRPSGABSRP

CF = Full, C = Condensed & S = Summary Report

Feature 4) can be activated or de-activated by a table T77S0 constant:

HRPSGABSCH

WX = Errors & Band Changes (W = X + Warnings)

As part of GBSXP phase II, open-ended absences will be possible. However, during the processing of OxP is it sensible that an open-ended absence is not processed indefinitely. For this reason, a limit to the processing (in months) can be defined by a table T77S0 constant:

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

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

8 Absence Evaluation Configuration (Complexities)8.1 Linking Absences

The OxP solution supports many kinds of absence linking. Where it can be specified as a field on a table, then the full range of options can be applied, (T5GPBS20 and T5GPBS21). Where the linking option has to be specified as part of another option (for example, feature GLOSS), the options have been split to include the various options that were thought desirable. If the five options listed below do not include your required linking option, then raise a development request stating the kind of linking you wish to use and in which circumstances. The five linking options are:

No Linking

00

Continuous Linking

01 99 Interval of 1 99 days allowed

GM

GB Maternity: Link if from the same MATB1

X

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.

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.

8.2.2 From Where Rules

There are ten supported methods for defining Where From rules. Each can have a parameter set that will further determine how the method will actually define the end of the check window:

1) Actual Absence

a. 1

Absence Startb. 2

Day-by-Day Through Absence

2) Employee Anniversary (Public Sector)

a. EHEarliest Hire

b. LHLatest Hire (before absence)

c. 01 ... 12.Employee Date Infotype 0041

3) Calendar Anniversary (Public Sector 1)

a. DD.MM (Day.Month)

4) Absence Recording

a. DD.MM.YYYY(Day.Month.Year)

5) Employee Start Date

a. EH Earliest Hire

b. LHLatest Hire (before absence)


6) Calendar Anniversary


7) Employee Anniversary

a. EHEarliest Hire

b. LH Latest Hire (before absence)


8) Calendar Anniversary (Public Sector 2)


There are major differences between these options, but the most widely used option is Actual Absence (1/1).

8.2.2.1 Actual Absence

The check window is defined by the current absence that is being processed.

Parameter set to 1

The check window includes all the days in the current absence up to the day that is currently being processed. In this way, the check window is a fixed length on the first day of the absence (defined by the How Far Bck/Fwd rule), but increases one day at a time as the next day is processed.

Parameter set to 2

The check window only includes the days in the current absence up to the day (if a How Far Bck/Fwd rule goes back that far). In this way, the check window is a fixed length, but moves forward one day at a time as the next day is processed. (This option should only be used if your rules require a moving/rolling check window where the employee will receive additional entitlements as earlier absences drop out of the check window as it moves forward.)

8.2.2.2 Employee Anniversary

The employee anniversary date (DD.MM.YYYY) can be defined for the employee based on their first hiring action, their most recent hiring action or by a specific date type stored on their infotype 0041 record. This means that the DD.MM can be defined quite simply, but the YYYY still needs to be defined.

Normally, there is no need to have a How Far Bck/Fwd rule that extends the check window as the window will start on the anniversary date and end on the day of the absence that is being processed. This is the simplest way to define an Entitlement Year based on the employees specific hire date to define when the Entitlement Year starts and ends.

There are two ways to choose which employee anniversary date to use:

1) Use the start date of the absence

The entitlement year is fixed using the start date of the absence.

For example, if an absence starts on 01.01.2003 and the employee anniversary is on 01.05.2003, then even if the absence lasts for five months, the entitlement year will still start from 01.05.2002 and run until the end of the absence.

2) Use the day of the absence that is being processed

The entitlement year is fixed using the day of the absence that is being processed.

For example, if an absence starts on 01.01.2003 and the employee anniversary is on 01.05.2003 then for the days of the absence before 01.05.2003, then the entitlement year will still start from 01.05.2002. However, if the absence lasts for five months, then for the days of the absence on or after 01.05.2003, the entitlement year will still start from 01.05.2003 and run until the end of the absence.

8.2.2.3 Calendar Anniversary

The calendar anniversary date (DD.MM.YYYY) is defined using the parameter, so the DD.MM can be decided quite simply, but the YYYY still needs to be decided.

Normally, there is no need to have a How Far Bck/Fwd rule that extends the check window as the window will start on the anniversary date and end on the day of the absence that is being processed. This is the simplest way to define an Entitlement Year based on a specific calendar date to define when the Entitlement Year starts and ends.

There are three ways to choose which calendar anniversary date to use:



For example, if an absence starts on 01.01.2003 and the calendar anniversary is on 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 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.



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

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.

8.4 Non-Qualifying Rules

Non-Qualifying Days do not reduce entitlement.

If you intend to use a Non-Qualifying rule and process those Non-Qualifying days as actually receiving payment, then you will need a non-qualifying rule per payment band to ensure that the employees payment changes when their band changes.

EXAMPLE

If your business rules are such that Public Holidays do not reduce entitlement, but do receive payment, then the By Default option can be used to implement these rules exactly. It is important to have a rule per entitlement payment band (For example, 100% and 50%).

Non-Qualifying Days are defined at two possible levels (T5GPBS22):

1) By Default: Non-Qualifying days for all employees in the scheme

2) Employee-Based: Non-Qualifying days for just one employee

8.4.1 By Default

These Non-Qualifying Days are based on a Period Work Schedule rule.

The Period Work Schedule rule should not be attached to any employee via infotype 0007, although obviously it could be. However, it is designed to be used by the scheme and not for any individual employee.

1) Any Public Holiday will be a Non-Qualifying day

2) Any Non-Public Holiday will be a Non-Qualifying day if it is a non-working day (that is, there are no planned start or end times).

8.4.2 Employee-Based

These Non-Qualifying Days can be based on any of the following options:

1) Non-Working Days

2) Days before MMP Start Date

3) Non-Working Days or Holidays (All Classes)

4) Non-Working Days or Holidays (Class 1)





9) Days before APP Start Date

0)Days before PPP Start Date

A)MatWeek 1: Non-Payment days in OMP week

B)MatWeek 2: Non-Payment days in SMP week

C)AdpWeek 1: Non-Payment days in OAP week

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.

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.

EXAMPLEThe 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, AND2) 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 no

absenceevalconfig_doc-sap time managment

Documents