Skip to end of metadata
Go to start of metadata

Symptom

This document describes the details and the inner workings of the new XNAB based absence processing solution for the Italian Payroll.

As a prerequisite basic understanding of absence processing, time management and payroll is assumed.

Solution


Cluster tables

The following contains a brief overview of the data structures involved in the absence processing.

ClusterRI

ClusterRI contains basically payroll results.

The tables relevant for absence processing in the payroll results are:

1.       AB: In this table all the information regarding the absence is stored. It is based on structure PC20I. The field ABZNR is the pointer of the absence (i.e. a number identifying each absence uniquely in a payroll run);

2.       RT: This table contains all wage-types regarding the payment of the absence. These wage-types are created through customizing and linked to the absence via T554C. For every wage-type is supposed to be found the number (ANZHL) with the time of the absence (days/hours), the amount per unit (BETPE) with the amount of the valuation basis that was used to valuate this wage-type and the amount (BETRG) with the amount paid for this absence. Some wage-types regarding the tolerance period (number of days of the month) are also stored in the RT table (field ‘ANZHL’).

It can be properly displayed with the report RPCLSTRI.

Cluster B2

The table involved in the absence calculation is the table ZL. The time wage-types in table ZL are generated either:

1.       by report RPTIME00 for customers with effective TM. In this case table ZL is imported in the payroll after the IMPRT B2;

2.       by payroll function DAYPR for customers without effective Time Management. In this case table ZL is created in the subschema TC00/TC04 in the DAYPR procedure;

3.       by both RPTIME00 and DAYPR.. It may occur that RPTIME00 has not processed yet all days of the current month when the payroll is run (for example on the 20th of the month). In this case the first part of the month is processed by the RPTIME00 while the second part is done in the DAYPR.

Cluster B2 can be viewed with report RPCLSTB2.

Cluster PC

Cluster PC contains tables with information on the results of absence processing. The main change here with XNAB is that table NCALE is not used anymore and that COVER is used instead.

The cluster PC contains the following tables:

1.       PCALI: international table for the old solution. It can be viewed with report RPCLSTPC;

2.       NCALE: national table for the old solution. The old solution used these fields to store all information regarding the absences, read by reports CUD and 770. It can be viewed with report RPCLPCI0;

3.       COVER: table for the new solution, written by function XNAB. Report RPCLPCI0 has been enhanced to view it. The structure and the relevant fields of table COVER are listed below.

Table COVER and structure PTM_MARKTAB_15

Table COVER is based on structure PTM_MARKTAB_15. These fields contain vital information about the treatment of the absences, written by XNAB and read by report CUD and throughout the absences payroll schema. Writing on table COVER is often referred to as "marking" table COVER. Also a COVER record can be called "mark".


Field

Data Element

Type

Length

Note

CDATE

DATUM

DATS

8

Date

AWART

AWART

CHAR

4

Attendance or Absence Type

OBEGD

OBEGD

DATS

8

Old start date

OENDD

OENDD

DATS

8

Old end date

KENN1

KENN1

DEC

2

Indicator for Subsequent Illness

KENN2

KENN2

DEC

2

Indicator for repeated illness

MODIF

MODIF

CHAR

2

Ee's grouping for absence evaluation (MOD0A)

SUBRU

P15_SUBRU

CHAR

4

Subrule

DAYAB

NUMC4

NUMC

4

Number of the day within the absence

DAYEV

NUMC4

NUMC

4

Number of the day within the event (relapses included)

KLBE1

BEWKL

NUMC

2

Primary rule (default of T554S)

KLBE2

BEWKL

NUMC

2

Secondary (valuation) rule (determined by XNAB)

GRASI

P15_GRASI

CHAR

2

INPS / INAIL grade (roughly equivalent to the “percento indennizzo)

GRAER

P15_GRAER

CHAR

2

Employer grade (roughly equivalent to the “percento integrazione”)

PROLE

P15_TYPET

CHAR

1

Simple or prolonged tolerance/tolerance
(S = simple
P = Prolungato
L = Licenziabile
I = con Indennizzo
N = senza indennizzo )

LNGTH

P15_LNGTH

CHAR

1

Short, long or very long event
( B Breve per metalmeccanici (non superiore a 5 giorni)
L Lungo per metalmeccanici (superiore a 3 mesi)
M Molto lungo per metalmeccanici (superiore al comporto breve) )

DOUBL

P15_DOUBL

CHAR

1

Day counting double
1                       Giorno singolo
2                       Giorno doppio

BONUS

P15_BONUS

CHAR

1

Hospital or illness bonus
O                      Bonus ospedale
M                     Bonus malattia4

MOABW

MOABW

NUMC

2

Subgroup grouping for absences

TPEVE

P15_TPEVE

NUMC

2

Type of event (see appendix for values)

OKEN1

P15_KENN1

DEC

2

Indicator for Subsequent Illness

OKEN2

P15_KENN2

DEC

2

Indicator for repeated illness

ABZNR

ABZNR

RAW

1

Absence split 

RESTP

P15_RESTP

CHAR

1

Restoring period has been passed  (ripristino diritto integrazione al 100%, contratto gomma)

OBJPS

OBJPS

CHAR

2

Child number (Identifier of a certain child used to connect absences related to motherhood to the child)

TFIRE

P15_TFIRE

CHAR

1

Lost right to preserve the job

OTHER

P15_OTHER

CHAR

41

SAP reserved mark space for future development

CUSTO

CHAR20

CHAR

20

Customer reserved field

DOCNR

PTM_DOCNR

NUMC

20

Document number for time data

FRACTION

ABWTG

DEC

6

Attendance and Absence Days

COVUNIT

PTM_COVUNIT

CHAR

3

Unit for Absence in Coverage History

SEQNO

COV_SEQ

NUMC

5

Sequence Number of Coverage History Table (by Day)

structure PTM_MARKTAB_15


Field CDATE tells the date the COVER record refers to. A record refers therefore to a period not longer than a single day.

Nevertheless there can be several records for the same day, as in the case of multiple half day absences on the same day.

Field AWART tells the kind of absence that generated that record (it is basically the same as field SUBTY (giustificativo) from infotype 2001).

OBEGD and OENDD are the original dates of the infotype 2001, from which the record is derived.

KENN1 and KENN2 come from that infotype too. OKEN1 and OKEN2 are copies of KENN1 and KENN2. See below the chapter about the conversion tool from old to the new solution.

MODIF is the absence modifier, MOABW the absence modifier and SUBRU the subrule of the employee when the record was written.

DAYAB is the number of the day within the absence, i.e. the infotype 2001, while DAYEV is the number of the day within the event i.e. the set of all episodes of an event, i.e. an absence and all the relapses referring to that original absence through fields KENN1 and KENN2.

KLBE1 is the default (so called “primary”) valuation rule for the kind of absence (from field T554S-KLBEW). This is used as starting point to determine the splitting rule (see below). (Please notice that field KLBE1 from table T554S is reserved for absence processing and cannot be used in other ways.)

KLBE2 is the derived (or secondary) valuation rule. This is actually used as valuation rule for the absence linked to the COVER record.

TPEVE is the type of event linked to the current AWART. TPEVE identifies the “Type” of absence, i.e. if it is an illness, an accident, a parental leave or whatever.

GRASI and GRAER are the indemnity and integration grade (see below). They are used to derive the secondary rule from the primary rule.

The metal workers (and rubber industry) collective agreement needs some information which is stored in the following fields:

o   PROLE tells the type of tolerance an employee is entitled to. It can be 'S' (simple, "semplice" or "breve"), 'P' (extended, "prolungato") for metal workers; 'I' (indemnified, "indennizzato"), "N" (not indemnified, "non indennizzato") for rubber industry workers. The default is 'S';

o   LNGTH tells if the current day belongs to a short ('B', "breve"), normal (blank), long ('L') or very long ('M', "molto lungo") event;

o   DOUBL is 1 unless the day weighs double. In this case is equal 2. A double day belongs necessarily to a short event;

o   BONUS is 'O' ("ospedale") or 'M' ("malattia") if respectively a hospital or illness bonus is granted on the current day;

o   TFIRE is flagged if the employee has surpassed his tolerance and may be fired.

RESTP is flagged when an employee has been present long enough to have his integration quotas restored. See below chapter about tolerance parameter RP.

ABZNR is a pointer to table AB of cluster RI. This is the way COVER records are linked to absence records.

OBJPS is the child number the absence refers to. To have it filled, absences need to be input through infotype 0080.

OTHER is a field not used yet but reserved to SAP that may break it up further in the future.

CUSTO is a field not used yet but reserved to the customer.


Customizing tables

The new solution uses the following new Italian customizing tables:

1.       T5ITIE, for Italy specific absence attributes;

2.       T5ITI8, for the generation of valuation bases;

3.       T5ITIV, for hourly leaves splitting rule;

4.       T5ITI9, for daily leaves, fixed-length intervals splitting rule;

5.       T5ITIQ, for secondary rule determination;

6.       T5ITIU, T5ITIR, T5ITIT, for daily leaves, tolerance based splitting rules.

Other useful customizing tables will be summarized after a thorough description of the Italian ones.

Primary key fields

The primary key of tables T5ITIU, T5ITIT, T5ITIR, T5ITI9, T5ITI8 contains some or all the fields described in the following table:


MODIF
(free customizing)

KLBEW
(free customizing)

SUBRU
(free customizing)

PAYER

SCAGL
(seniority)

10
(metal workers)

10
(illness)

1
(only for employees
having SUBRU 1)

DL
("datore di lavoro",
employer)

036
(less or equal
than 36 months)

10

10

1

DL

072
(between 36
and 72 months)

10

10

1

DL

999
(more than 72 months)

10

10

0
(for employees
having all SUBRU)

PS
("previdenza sociale",
social insurance)

999
(seniority does
not matter)

21
(telecom clerks)

40
(work accident)

0
(for employees having
all SUBRU‘s but 1)

AI
("assicurazione infortuni",
accident insurance)

999
(seniority does
not matter)

21

40

1
(only for employees
having SUBRU 1)

AI

999
(seniority does
not matter)

Generic table customizing


Field MODIF is an absence management modifier set at run-time by function MOD with rule IMOD (see below). MODIF has no check table.

Employees with the same MODIF can have different SUBRU. The SUBRU for an employee is determined via feature SUBRU. Value 0 is a wildcard for field SUBRU in the customizing tables, i.e. customizing referring to SUBRU 0 is valid for any employee for whom there is no customizing matching exactly his SUBRU. For example, employees with MODIF 10 have either SUBRU 1, 2 or 3. If there are only 2 records in a table, one for SUBRU 1 and the other for SUBRU 0, the first record is only valid for employees having SUBRU equals 1, and the second is valid for employees having SUBRU equals 2 or 3.

Field KLBEW is the splitting rule, equals to the default valuation rule of the absence.

Field PAYER has fixed values DL, PS, AI. For a given protected event there are payments made at most by the employer and of either the social insurance or the accident insurance.

Field SCAGL contains the upper limit of a seniority interval.

General purpose tables

Types of events: table T5ITIE

In table T5ITIE  each absence type is assigned to an event type. Event types are defined by SAP in domain P15_TPEVE. See appendix.

Event types are linked to boxes of section 3 of report CUD. These links are not customizable.

The admission to hospital (ospedalizzazione) can be inferred only by the type of event.

In case of relapse the system tests the type of event to decide whether to recover the original valuation basis or not.

Tables T554S and T5ITIE.

Table T5ITIE represents an extension of table T554S.

It is required that view V_T5ITIE is used  in order to delimit entries in T554S, as long as those entries are relevant for absence processing. Please do not use other views of T554S to delimit these tables.

Valuation bases and gros/net percentages: table T5ITI8

Table T5ITI8 stores information about:

1.       valuation bases (fields from WTDAB to WTMOB) to be generated via function ITASS called with first parameter BASE;

2.       wage-types in input to the valuation bases (from WTGLA to WTTNA) used by function ITASS - BASE;

3.       standard number of days for the generation of valuation bases (GGCOR and GGCOM) used by function ITASS - BASE;

4.       coefficients for hospedalization reduction (RIDO1 and RIDO2) used by function ITASS - AGGI;

5.       percentages for gross/net adjustment (PERNE and PERLO) used by function ITASS - NELO;

6.       wage-types for INPS refund and net integration (WTIAD and WTRAZ) used by function ITASS - NELO.


Field

Key

Type

Length

Dec

Data Element

Check Table/Ref.

Note

MANDT

X

CLNT

3

 

MANDT

T000

 

MOLGA

X

CHAR

2

 

MOLGA

T500L

 

MODIF

X

CHAR

2

 

MODIF

 

 

KLBEW

X

NUMC

2

 

BEWKL

T554L

 

ENDDA

X

DATS

8

 

ENDDA

 

 

BEGDA

X

DATS

8

 

BEGDA

 

 

GGCOR

 

NUMC

2

 

P15_GGCOR

 

Days for extra payments

GGCOM

 

NUMC

2

 

P15_GGCOM

 

Normal days

PERNE

 

DEC

6

3

P15_PERNE

 

% Net

PERLO

 

DEC

6

3

P15_PERLO

 

% Gross

WTGLA

 

CHAR

4

 

P15_WTGLA

T512W

Worked days

WTGFS

 

CHAR

4

 

P15_WTGFS

T512W

Holiday days

WTGFR

 

CHAR

4

 

P15_WTGFR

T512W

Days off

WTGPR

 

CHAR

4

 

P15_WTGPR

T512W

‚Permessi’

WTGAR

 

CHAR

4

 

P15_WTGAR

T512W

Days of paid absence

WTGSG

 

CHAR

4

 

P15_WTGSG

T512W

6th days

WTGNR

 

CHAR

4

 

P15_WTGNR

T512W

Not paid days

WTPOR

 

CHAR

4

 

P15_WTPOR

T512W

Hourly rate

WTRBA

 

CHAR

4

 

P15_WTRBA

T512W

Basic pay

WTVCO

 

CHAR

4

 

P15_WTVCO

T512W

Variable pay

WTVCT

 

CHAR

4

 

P15_WTVCT

T512W

Variable pay

WTRT1

 

CHAR

4

 

P15_WTRT1

T512W

Extra payment1

WTRT2

 

CHAR

4

 

P15_WTRT2

T512W

Extra pay 2

WTRT3

 

CHAR

4

 

P15_WTRT3

T512W

Extra pay 3

WTRT4

 

CHAR

4

 

P15_WTRT4

T512W

Extra pay 4

WTTNA

 

CHAR

4

 

P15_WTTNA

T512W

New hired

WTDAB

 

CHAR

4

 

P15_WTDAB

T512W

Daily Basis

WTEXB

 

CHAR

4

 

P15_WTEXB

T512W

Extra Basis

WTMOB

 

CHAR

4

 

P15_WTMOB

T512W

Monthly Basis

WTIAD

 

CHAR

4

 

P15_WTIAD

T512W

INPS refund

WTRAZ

 

CHAR

4

 

P15_WTRAZ

T512W

Net integration

RIDO1

 

DEC

6

3

P15_RIDUN

 

Numerator of reduction coefficient

RIDO2

 

DECE

6

3

P15_RIDUD

 

Denominator of reduction coefficient

Table T5ITI8: structure


Customizing could look as follows.

KLBEW

KLBEW
description

MODIF

type of
contract

type of
employee

GGCOR

GGCOM

Indemnity

WTDAB

WTDAB

WTDAB

10

illness

12

metal

clerks

/

/

no

/

/

/

10

illness

10

metal

workers month

25

26

yes

/010

/E10

/M10

 

 

11

 

workers hour

25

 

yes

/010

/E10

/M10

30

comp.mat.

12

 

clerks

30

30

yes

/030

/E30

/M30

 

 

10

 

workers month

25

26

yes

/030

/E30

/M30

 

 

11

 

workers hour

25

 

yes

/030

/E30

/M30

31

opt.mat.

12

 

clerks

/

30

yes

/031

/E31

/M31

 

 

10

 

workers month

/

26

yes

/031

/E31

/M31

 

 

11

 

workers hour

/

 

yes

/031

/E31

/M31

10

illness

22

trade

clerks

30

30

yes

/010

/E10

/M10

 

 

20

 

workers month

25

26

yes

/010

/E10

/M10

 

 

21

 

workers hour

25

 

yes

/010

/E10

/M10

30

comp.mat.

22

 

clerks

30

30

yes

/030

/E30

/M30

 

 

20

 

workers month

25

26

yes

/030

/E30

/M30

 

 

21

 

workers hour

25

 

yes

/030

/E30

/M30

31

opt.mat.

22

 

clerks

/

30

yes

/031

/E31

/M31

 

 

20

 

workers month

/

26

yes

/031

/E31

/M31

 

 

21

 

workers hour

/

 

yes

/031

/E31

/M31

 Table T5ITI8: customizing


The first record has been deleted because for clerks with metal worker contract indemnity is paid by the social insurance and therefore there is no need of determining a valuation basis.

The valuation basis for the employer is the hourly rate which is anyway generated by rules I010 and I013. Field WTPOR is hidden in the view because no further information about this valuation basis is needed.


Table T5ITI8 is similar to table T5ITI2 of the old solution based on function INAB. The primary key of table T5ITI8 comprehends also the primary valuation rule and modifier MODIF and allows greater flexibility: different groups of employees and different absences can have different valuation bases and gross/net percentages.


In the following chapters the tolerance for the rubber industry collective agreement will be considered and some tables will be customized to handle some peculiar feature of this collective agreement. Since the standard customizing is only an example, though complete and consequent, the collective agreement for the rubber industry and for the trade workers will share the same MODIF's 20, 21, 22.


How the fields in table T5ITI8 are used in the generation of valuation basis.

The formula used for the generation of valuation bases is the following:

Valuation basis = A/B + C/D.

Where

·         ‘B’ is the sum of the number (ANZHL) of the wage-types from table ZL customized in fields

T5ITI8-wtgfr Giorni ferie

T5ITI8-wtgfs Giorni festivi

T5ITI8-wtgla Giorni lavorati

T5ITI8-wtgpr Permessi retribuiti

T5ITI8-wtgar Assenze retribuite

T5ITI8-wtgsg Seste giornate

If B determined from ZL is empty then B is read from the field T5ITI8-ggcom


·         ‘D’ is determined from field T5ITI8-ggcor.


·         ‘A’ is determined from the sum of the amount of the wage-types in fields T5ITI8-wtrba T5ITI8-wtvco, T5ITI8-wtvct and T5ITI8-wttna.


·         ‘C’ is determined by  the sum of the amount (BETRG) of wage-types in fields T5ITI8-wtrt1, T5ITI8-wtrt2, T5ITI8-wtrt3 and T5ITI8-wtrt4.



Wage-type specified in field WTDAB is generated with the following value:

‘A/B + C/D’

Wage-type specified in field WTEXB is generated with the following value:

‘C’

Wage-type specified in field WTMOB is generated with the following value:

‘A’


The wage-types for the generation of the valuation bases are read out of table ORT in the current payroll period. In the case of employees hired during the month (i.e. no previous payroll period) the wage-types are read out of the current months table RT.

It is important to note that the legal requirement is to use the wage-types of the previous month for the generation of the valuation basis. This is performed not by generating in month i the valuation basis for month i+1, but instead in month i, the valuation basis for the same month i are generated based on wage-types coming from month i – 1 (thus from table ORT).

Another important comment on valuation basis generation is that all valuation bases for the MODIF A of the employee being processed are generated, even if the employee has no absence in that month. This is needed because in some cases a wage-type from a previous month is needed (typically for maternity), and if the valuation is not generated in each month regardless of absences in that month no correct processing of the absence can occur.

Splitting rules

Splitting rules for hourly leaves: table T5ITIV

This table has been designed on the requirements for breast feeding but it can be used in all cases in which we need to define a daily threshold for a leave, like for the parental leaves.


Field

Key

Type

Length

Dec

Data Element

Check Table/Ref.

Note

MANDT

X

CLNT

3

 

MANDT

T000

 

MOABW

X

CHAR

2

 

MOABW

T554S

 

AWART

X

CHAR

2

 

AWART

 

 

ENDDA

X

DATS

8

 

ENDDA

 

 

BEGDA

 

DATS

8

 

BEGDA

 

 

KLBEW

 

NUMC

2

 

BEWKL

T554L

Valuation rule

HALR1

 

DEC

2

 

P15_HALLR

 

Minimum paid absence hours

HALR2

 

DEC

2

 

P15_HALLR

 

Maximum paid absence hours

HMINA

 

DEC

2

 

P15_HMINA

 

Minimum working hours for a full time employee

KLBEW2

 

NUMC

2

 

BEWKL

T554L

New rule for employee working less than HMINA hours a day

Fig.5: Table T5ITIV: structure


For the breast feeding there is the possibility to define 2 different thresholds, referring to a full-time and to a part-time employee.


MOABW

AWART

 

KLBEW

HALR1

HALR2

HMINA

KLBEW2

PK

PK

 

 

 

 

 

 

15

0800

breast feeding

50

1

2

6

51

Table T5ITIV: customizing


If the employee works not more than 6 hours a day (checked in her Personal Shift Plan) she is entitled to 1 hour's leave. If she works longer than 6 hours, she may take a 2 hours' leave.

If the employee requests a too long breast feeding leave, the exceeding hours are not paid. This actually means that there is a split of the absence: paid hours in the first interval, not paid hours in the second. These two intervals lead to two COVER records and then to two AB records. The valuation rule for the first record is 50, which must be consistently customized to generate a payment wage-type. The valuation rule for the second record is KLBEW2 and should generate no payment wage-types.

Table T5ITIV checks a limit of hours within a single day. This table has been modelled on the breast-feeding and has therefore two limits (one for a full-time employee, the other for part-time employee) and a threshold number of working hours to determine which employee can be considered full-time. For other kind of absences (like those with TPEVE 2 and 6) you may set the same value for both cases (full- and part-time) and any threshold number of working hours.

Hourly parental leaves

All hourly parental leaves, i.e. parental leaves for handicapped child or employee and for breast feeding (TPEVE 2, 6, 50) must be customized in table T5ITIV (look column Table of event types table in the appendix).

The switch from hourly (TPEVE 4) to daily leaves (TPEVE 3) in the same month and the check on the alternative either hourly or daily leave is not implemented, and is left to the end user, or to custom checks on infotype 2001.

Parental leaves referring to the same child are linked through field OBJPS of infotype 2001. This field is only filled if infotype 2001 is entered via infotype 0080.

Important Notice on hourly leaves

In order to process hourly leaves it is mandatory to maintain view V_T556M too. Otherwise the hourly leave is not processed. This holds also for hourly illnesses, parental leaves etc.

Regarding hourly illnesses some comment is required for the “comporto” processing. Comporto counters are usually customized in working days. With hourly illnesses there will be fractions of working days added and removed from tolerance counters. The fraction will be taken out of field ABWTG  from infotype 2001.  The fraction used for each day will be stored in field DYFRC of table COVER. The field ABWGT in infotype 2001 is filled with the ratio between Absence hours and the number of hours the employee should have worked on that day (field psp-stdaz). A user exit (see paragraph “user exits”) is provided in order to adjust the absences fraction of day.

Fixed-length intervals splitting rules for daily leaves: table T5ITI9

After function RAB the absence from P2001 are transferred into table AB. Every record of AB is processed in function PAB according to its valuation rule (KLBEW) via table T554C. An AB record must be split in so many records as different valuations are required for this absence.

The daily payment in case of illness or work accident is not always the same for all days of the absence. This means that the valuation rule (KLBEW) can vary during the same absence. Therefore we talk of a primary valuation rule (RULMA), which is the default rule for that kind of absence (AWART) set on table T554S, and of secondary rules (SRULE) derived from the first.

A main transition schema from primary to secondary rule is the fixed-length intervals splitting of an absence. This schema can be implemented in table T5ITI9.


Field

Key

Type

Length

Data Element

Note

MANDT

X

CLNT

3

MANDT

Client

MODIF

X

CHAR

2

MODIF

Modifier

RULMA

X

CHAR

2

BLKEW

Primary valuation rule: splitting rule

SUBRU

X

CHAR

4

P15_SUBRU

Sub rule:
0 (wildcard)

PAYER

X

CHAR

2

P15_PAYER

Payer:
PS (INPS),
AI (INAIL),
DL (employer)

SCAGL

X

NUMC

2

P15_SCAGLI

Seniority in months

LIMIT

X

NUMC

4

P15_LIMMA

Limit day

ENDDA

X

DATS

8

ENDDA

 

BEGDA

 

DATS

8

BEGDA

 

COFLD

 

CHAR

10

FDNAME

Name of the field of table COVER to be marked

COVAL

 

CHAR

2

P15_GRADE

Marking value for the field of table COVER chosen above

SRULE

 

CHAR

2

BLKEW

Secondary rule

UNIMI

 

CHAR

1

P15_UNILI

Unit of measure of limit. Only days

UNIMS

 

CHAR

1

P15_UNIMS

Unit of measure of seniority. Hidden in the view since it can only be months.

 Table T5ITI9: structure


In case of some absences, if the employee requests a leave longer than allowed, the time exceeding the limit is not paid. This can be seen as the splitting of the absence into a first interval during which the employee is paid, and a second one during which he is not paid. So all absences could be considered absences during which the evaluation rule changes. For most absences the last interval is not paid (like for the illness after the 180th day, or for maternity after a year from the birth, …).

Field LIMIT contains the values of the extremes of the intervals produced by the splitting procedure. The last interval could be open, since typically laws and regulations state that after the nth day of absence there is no indemnity paid. In this case LIMIT should be the highest possible number, e.g. 9999.

In some cases the last interval is not open. This means that the employee's leave may not exceed a certain number of days, not even if he is not paid in the last interval. The last interval can be closed setting in field LIMIT a value less than 9999. If the absence is longer than this number of days, the splitting procedure cannot find the interval for the exceeding days and issues an error message.


To make all new tables more flexible field SUBRU (subrule) has been added. Each employee has a value for SUBRU set by feature SUBRU, depending on the employee's contract and employer's regulations. Tables can be customized with SUBRU equals 0, which is a wildcard: if there are no records with the current employee's SUBRU, record with SUBRU 0 can be used. Therefore SUBRU 0 can be used as a splitting criterium depending on laws and not on company-specific rules.

Table T5ITI9 says both how to split the absence (field LIMIT), how to mark table COVER (fields COFLD, COVAL), and, if possible, what rule to use for the evaluation (field SRULE). Though, table T5ITI9 does not contain indemnity or integration percentages. These percentages are implied by the customizing of tables T554C and T512W (view V_512W_B): a secondary rule generates wage-types, wage-types have a valuation basis and a percentage.


Most times (e.g.: illness) secondary rule cannot be set via T5ITI9 because two splitting criteria must be combined (see below table T5ITIQ). Table T5ITI9 determines anyway table COVER marking.

Marking is flexible since users may define what field should be marked with what value. In the standard customizing, fields used to mark after splitting are GRASI (social insurance indemnity grade) and GRAER (employer integration grade). The values used to mark these two fields are 1, 2, 3, … They have no special meaning. They are only a way to differentiate the days they refer to.

So GRASI's value is 1 for the first 3 days of illness (“Carenza”), 2 until the 20th, 3 afterwards. As explained below (see table T5ITIR), there is also a grade 4 for the illness days after the 180th in a year. For illness, since the secondary rule is not set, the grade determines the indemnity percentage (through tables T5ITIQ, T554C and T512W) but a percentage does not determine univocally a grade. For example the first INPS indemnity grade for illness implies 0 percent but 0 percent does not imply grade 1 since it is also the percentage for grade 4. Wage-types implied by grade 1 and 4 must be customized and can also be the same.


The standard customizing for social insurance splitting criterium for illness looks as follows.


RULMA

 

SUBRU

PAYER

SCAGLI

LIMIT

COFLD

COVAL

SRULE

Percentage
(in table T512W)

PK

 

PK

PK

PK

PK

 

 

 

 

10

illness

0

PS

999

3

GRASI

1

 

0

10

illness

0

PS

999

20

GRASI

2

 

50

10

illness

0

PS

999

9999

GRASI

3

 

66

 Table T5ITI9: customizing


Example.

For example in this table XNAB can be instructed to split a simple hypotetical absence X into 2 parts. The first five days valuated with rule 01 and the remaining days with rule 02 (field SRULE).

A real world example of this simple kind of splitting is represented by the rules for splitting  “Infortuni” (work accidents).

Here the indennizzo/integrazione situation is the following:


Giorni

Indennizzo

Integrazione

Regola

1

0

100%

40

2-4

0

60%

41

5-90

60%

0

42

91-9999

75%

0

43


This can be easily represented with table T5ITI9 as follows:


RULMA

 

SUBRU

PAYER

SCAGLI

LIMIT

COFLD

COVAL

SRULE

40

Accident

0

PS

999

1

GRASI

 

40

40

Accident

0

PS

999

4

GRASI

 

41

40

Accident

0

PS

999

90

GRASI

 

42

40

Accident

0

PS

999

9999

GRASI

 

43

 Table T5ITI9: customizing for work accident.


It is assumed that rules 40, 41, 42 and 43 in table T554C contain wage-types customized with the appropriate percentages. Each rule will contain both SI and employer wage-types.


Tables T554C and T512W must be consistently customized.


KLBEW

LGA01

LGA02

40

MIA3

MIA0

41

MIA3

MIA1

42

MIA4

MIA2

43

MIA5

MIA2

 Table T554C: customizing


LGART

GVPRO

MIA0

100

MIA1

60

MIA2

0

MIA3

0

MIA4

60

MIA5

75

 Table T512W: customizing

 
Parental leaves

As they refer to a particular child, parental leaves must be entered through infotype 0080. Field OBJPS, whenever full, is used to link absences. The limits set on table T5ITI9 for maternity are compared with the day number of the whole event (field COVER-DAYEV), which is obtained joining all absences with the same event type (TPEVE), absence modifier (MODIF), splitting rule (KLBEW) and same OBJPS.

If the parental leave can be taken only once (i.e. maternity, TPEVE 1, 7, 30, 31, 32, 33), episodes of absences are already easily linked via OBJPS. Also other parental leaves related to children must be entered via infotype 0080 and are bound to the child via field OBJPS.


Infotype 0080 is necessary not only to link the absence to a child but also to check the child age. To do that it is important to customize table T554M.


Regarding parental leaves, not all checks are automatic:

1)      the maternity absence is equal to 5 months if the baby is born within the delivery date, but it can be more than 5 months if the baby is born after the delivery date. The infotype 2001 must be manually changed to handle this case.

2)      Optional maternity: the mother can use it only after the obligatory maternity, the  father immediately after the baby is born; the optional maternity is 6 months long at most for the mother, 7 months at most for the father; the leave taken by the father and that taken by the mother cannot exceed 11 months.

Those checks are not implemented in XNAB, and must be checked manually before entering the absences, or using appropriate check user exits (for example pbas00001) when entering the infotype 2001 records.


Determination of the secondary rule: table T5ITIQ

If for example one marking is set via T5ITI9 and one via T5ITIR, the right valuation rule can be set only combining the two criteria. Table T5ITIQ has the purpose to cross (incrociare) GRASI and GRAER to get the right secondary valuation rule.


Field

Key

Type

Length

Data Element

Note

MANDT

X

CLNT

3

MANDT

Client

MODIF

X

CHAR

2

MODIF

 

KLBEW

X

CHAR

2

BLKEW

Primary rule

SUBRU

X

CHAR

4

P15_SUBRU

Sub rule:
0 (wildcard)

GRAER

X

CHAR

2

P15_GRAER

Integration grade

GRASI

X

CHAR

2

P15_GRASI

Indemnity grade

ENDDA

X

DATS

8

ENDDA

 

BEGDA

 

DATS

8

BEGDA

 

SRULE

 

CHAR

2

BLKEW

Secondary rule

SRULH

 

CHAR

2

BLKEW

Secondary rule in case of hospital bonus

SRULI

 

CHAR

2

BLKEW

Secondary rule in case of illness bonus

 Table T5ITIQ: structure


T5ITIQ-GRAER, T5ITIQ-GRASI are based on similar domain with the fixed values 1, 2, 3, 4, 5.


For illness, field GRAER and, in some cases, GRASI are set via tolerance calculation. So in the standard customizing, table T5ITIQ is used to determine the valuation rule.


KLBEW

 

SUBRU

GRAER

GRASI

SRULE

SRULH

SRULI

PK

 

PK

PK

PK

 

 

 

10

illness

1

1

1

10

19

22

10

illness

1

1

2

11

20

23

10

illness

1

1

3

12

21

24

10

illness

1

1

4

25

28

29

10

illness

1

2

1

13

 

 

10

illness

1

2

2

14

 

 

10

illness

1

2

3

15

 

 

10

illness

1

2

4

26

 

 

10

illness

1

3

1

16

 

 

10

illness

1

3

2

17

 

 

10

illness

1

3

3

18

 

 

10

illness

1

3

4

27

 

 

 Table T5ITIQ: customizing


All combinations of one of the three integration percentages with one of the three indemnity percentages are possible.


KLBEW

 

LGA01

LGA02

10

Mal. 100 az, 0 INPS 

MI50

MI71

11

Mal. 100 az, 50 INPS

MI46

MI71

12

Mal. 100 az, 66 INPS

MI47

MI71

13

Mal. 50 az, 0 INPS  

MI50

MI72

14

Mal. 50 az, 50 INPS 

MI46

MI72

15

Mal. 50 az, 66 INPS 

MI47

MI72

16

Mal. 0 az, 0 INPS   

MI50

MI73

17

Mal. 0 az, 50 INPS  

MI46

MI73

18

Mal. 0 az, 66 INPS  

MI47

MI73

Table T554C: customizing


LGART

GVPRO

MI46

50

MI47

66,67

MI50

0

MI71

100

MI72

50

MI73

0

 Table T512W: customizing


The collective agreement for metal workers grants bonuses. A bonus is the extension of the period with 100% integration if some particular conditions occur. There are two types of bonuses, i.e. two types of reasons to extend the 100%  integration period: for long illness and for admission into hospital.

Bonuses are managed via table T5ITIT. In case of bonus the integration percentage is 100% (as it would be in case of normal 100% integration) but different wage-types must be generated to track the amount of paid bonus. Therefore the valuation rule in case of bonus must be different than that for normal 100% integration. This is the reason why columns SRULH and SRULI are empty in case of work accident and full for illness.


Tolerance (“Comporto”)

The splitting criterium for the employer integration of illness is very complicated due to the tolerance.

According to the tolerance mechanism, the integration for an illness is determined considering the employee's absences in the last 36 months (36 is the number of months stated in the metal workers collective agreement but other contracts can have other parameters). In this time window the number of days with 100% integration and those with 50% integration cannot exceed given limits. An employee is first paid a 100% integration until he reaches the maximum. Then he is paid a 50% integration until he reaches the maximum. Then he is not paid at all (and in a general case he can be even fired). Since the window is sliding, some old absence can exit the time window and the entitlement to 100% or 50% integration could be then restored. This mechanism implies the impossibility to determine the percentage of integration during an absence without knowing the whole history of the employee's absences.


Tolerances: table T5ITIU

Table T5ITIU is a kind of entity tables for tolerances.


Field

Key

Type

Length

Data Element

Note

MANDT

X

CLNT

3

MANDT

Client

MODIF

X

CHAR

2

MODIF

 

KLBEW

X

CHAR

4

BLKEW

 

SUBRU

X

CHAR

2

P15_SUBRU

Subrule (0 is a wildcard)

PAYER

X

CHAR

2

P15_PAYER

Payer:
PS (INPS),
AI (INAIL),
DL (employer)

ENDDA

X

DATS

8

ENDDA

 

BEGDA

 

DATS

8

BEGDA

 

WIWID

 

CHAR

4

P15_TIWIN

Time window width

WITYP

 

CHAR

1

P15_WITYP

Time window type:
I  (incrementing yearly)
F  (rigid)

DIVIS

 

CHAR

1

P15_DIVIS

Not used

MAXIN

 

CHAR

4

GGBON

Not used

MEKEN

 

CHAR

1

P15_MEKEN

Flagged if the tolerance prevails over other splitting rules that set the same field of table COVER.

UNIMW

 

CHAR

1

P15_UNIMW

Unit of meausure of time window:
M (months),
G (days).

UNIMA

 

CHAR

1

P15_UNIMA

Not used

 

 

 

 

 

 

 

Table T5ITIU: structure


For each MODIF, KLBEW, SUBRU and PAYER, a time window can be defined with a certain width (WIWID) and a certain type. Windows of type F (fixed-length) moves rigidly on the time axis. Windows of type I increment their size every day. The reset moment is by default January the 1st.

Since the same field of table COVER can be marked with many concurrent criteria (at most 2 defined in table T5ITI9 and 2 in table T5ITIR, see below), field MEKEN states which tolerance (if any) has the highest priority to mark that COVER field.


MODIF

KLBEW

SUBRU

 

PAYER

WIWID

UNIMW

WITYP

MEKEN

10

10

0

illness

PS

12

M

I

X

10

10

0

illness

DL

36

M

F

 

20

10

0

illness

PS

12

M

I

X

20

10

0

illness

DL

36

M

F

 

 Table T5ITIU: customizing

Tolerance quotas: table T5ITIR

The maximum number of integration days (or tolerance quotas) is stored in table T5ITIR.

Field

Key

Type

Length

Data Element

Note

MANDT

X

CLNT

3

MANDT

Client

MODIF

X

CHAR

2

MODIF

Modif

KLBEW

X

CHAR

2

BLKEW

Rule

SUBRU

X

CHAR

4

P15_SUBRU

Sub rule:
0 (wildcard)

PAYER

X

CHAR

2

P15_PAYER

Payer:
PS (INPS),
AI (INAIL),
DL (employer)

SCAGL

X

NUMC

2

P15_SCAGLI

Seniority

TYPET

X

CHAR

1

P15_TYPET

Tolerance type:
S (simple),
P (prolonged)

SEQNR

X

NUMC

3

P15_SEQUE

Progressive no.

ENDDA

X

DATS

8

ENDDA

Endda

BEGDA

 

DATS

8

BEGDA

Begda

GGMAX

 

NUMC

4

P15_MAXGG

Limit day

COFLD

 

CHAR

10

FDNAME

Name of the field in table COVER

COVAL

 

CHAR

2

P15_GRADE

Value of the field in table COVER

WTCNT

 

CHAR

4

LGART

Name of the counter  wage-type

SRULE

 

CHAR

2

BLKEW

Secondary rule

UNIMS

 

CHAR

1

P15_UNIMS

Unit of meausure of seniority.
Only months.

UNIMX

 

CHAR

1

P15_UNIMX

Unit of measure of GGMAX.
Only days and months.

Table T5ITIR: structure


This table is similar to table T5ITI9 but instead of field LIMIT (right extreme of the split intervals) there is field GGMAX (maximum number of days for a certain integration). The hierarchy among quotas is defined in field SEQNR. For example, a metal worker is entitled to some days with 100% integration and some other days with 50% integration. He first consumes the 100% integration days and only then the 50% ones.


In case of tolerance, when assigning a day an integration percentage the number of already paid days with 100% integration must be checked. Therefore counter wage-types are needed to store the number of days with 100% integration and with 50% integration already granted. These counters must be compared with the maximum number of integration days (field GGMAX) and increased if an integration day can still be granted. The generation of the wage-type must be performed by function PAB. So counter wage-types must be customized in table T554C.

Metal workers collective agreement

The metalworkers collective agreement also states different number of integration days depending on the seniority and different types of tolerance (simple -S- and extended or prolonged -P-). In order to enter all this data, the primary key of T5ITIR comprehends fields tolerance type (TYPET) and seniority (SCAGL). The table is read with the current absence rule, the current employee's modifier, seniority  and subrule, and with the type of tolerance stored in field PROLE of the current COVER record.

See below table T5ITIT to understand how an employee has the tolerance extended.


MODIF

RULE

 

SUBRU

PAYER

SCAGLI

TYPET

SEQNR

GGMAX

UNIMX

COFLD

COVAL

WTCNT

PK

PK

 

PK

PK

PK

PK

PK

 

 

 

 

 

10

10

illness

01

DL

36

S

1

60

G

GRAER

1

MY71

10

10

illness

01

DL

36

S

2

120

G

GRAER

2

MY72

10

10

illness

01

DL

36

S

3

9999

G

GRAER

3

 

10

10

illness

01

DL

36

P

1

90

G

GRAER

1

MY71

10

10

illness

01

DL

36

P

2

180

G

GRAER

2

MY72

10

10

illness

01

DL

36

P

3

9999

G

GRAER

3

 

10

10

illness

01

DL

72

S

1

90

G

GRAER

1

MY71

10

10

illness

01

DL

72

S

2

180

G

GRAER

2

MY72

10

10

illness

01

DL

72

S

3

9999

G

GRAER

3

 

10

10

illness

01

DL

72

P

1

135

G

GRAER

1

MY71

10

10

illness

01

DL

72

P

2

270

G

GRAER

2

MY72

10

10

illness

01

DL

72

P

3

9999

G

GRAER

3

 

10

10

illness

01

DL

999

S

1

120

G

GRAER

1

MY71

10

10

illness

01

DL

999

S

2

240

G

GRAER

2

MY72

10

10

illness

01

DL

999

S

3

9999

G

GRAER

3

 

10

10

illness

01

DL

999

P

1

180

G

GRAER

1

MY71

10

10

illness

01

DL

999

P

2

360

G

GRAER

2

MY72

10

10

illness

01

DL

999

P

3

9999

G

GRAER

3

 

 Table T5ITIR: customizing

INPS illness indemnity

INPS indemnity cannot be paid for more than 180 days a year. The last interval of INPS indemnity for illness already insures that there are no more than 180 paid days if an employee had only a long (more than 180 days) absence. But it is not so if there are many short absences.
This is a kind of tolerance, like the one of the national collective agreement of the metal workers for illness. Also in this case we need a counter (MY49) of the days already indemnified by INPS.


MODIF

RULE

 

SUBRU

PAYER

SCAGLI

TYPET

SEQNR

GGMAX

UNIMX

COFLD

COVAL

WTCNT

PK

PK

 

PK

PK

PK

PK

PK

 

 

 

 

 

10

10

illness

01

PS

999

S

1

180

G

GRASI

 

MY49

10

10

illness

01

PS

999

S

2

9999

G

GRASI

4

 

 Table T5ITIR: customizing


The value blank in COVAL means that the value already present in field GRASI should not be overwritten. On the contrary the value 4 in the last row must overwrite any value already written in COVER field GRASI.

Rubber industry collective agreement

Table T5ITIR can be used to customize also the rubber industry collective agreement (contratto "Gomma").


For the workers the agreement states:

§  for seniority less than 3 years:

o   100% integration for 3 months if there is any indemnity paid by INPS (i.e. there are less than 180 illness days in the year);

o   no integration afterwards if there is still an indemnity paid by INPS;

o   50% integration if there is no indemnity paid by INPS and while the employee keeps the right not to be fired (6 months);

§  for seniority between 3 and 6 years:

o   100% integration for 4 months if there is any indemnity paid by INPS (i.e. there are less than 180 illness days in the year);

o   no integration afterwards if there is still an indemnity paid by INPS;

o   50% integration if there is no indemnity paid by INPS and while the employee keeps the right not to be fired (9 months);

§  for seniority bigger than 6 years:

o   100% integration for 5 months if there is any indemnity paid by INPS (i.e. there are less than 180 illness days in the year);

o   no integration afterwards if there is still an indemnity paid by INPS;

o   50% integration if there is no indemnity paid by INPS and while the employee keeps the right not to be fired (12 months).


For the clerks the agreement states:

§  for seniority less than 3 years:

o   100% integration for 3 months if there is any indemnity paid by INPS (i.e. there are less than 180 illness days in the year);

o   66,66% integration afterwards if there is still an indemnity paid by INPS;

o   50% integration if there is no indemnity paid by INPS and while the employee keeps the right not to be fired (6 months);

§  for seniority between 3 and 6 years:

o   100% integration for 4 months if there is any indemnity paid by INPS (i.e. there are less than 180 illness days in the year);

o   66,66% integration afterwards if there is still an indemnity paid by INPS;

o   50% integration if there is no indemnity paid by INPS and while the employee keeps the right not to be fired (9 months);

§  for seniority bigger than 6 years:

o   100% integration for 5 months if there is any indemnity paid by INPS (i.e. there are less than 180 illness days in the year);

o   66,66% integration afterwards if there is still an indemnity paid by INPS;

o   50% integration if there is no indemnity paid by INPS and while the employee keeps the right not to be fired (12 months).


Please refer to the following section about table T5ITIT to see how the type of tolerance can be set to I (tolerance when the employee still receives an indemnity by INPS), N (tolerance when the employee receives no indemnity by INPS) and L (surpassed tolerance when the employee may be fired for having been ill too long). If tolerance type is I, then a worker (MODIF 20) with a seniority less than 36 months receives a 100% integration for the first 3 months (SEQNR 1) and afterwards (SEQNR 3) no integration. (There is no problem in leaving gaps in the sequence of SEQNR.) If he has surpassed the employer tolerance limit (TYPET I), he receives no integration (WTCNT, MY73). If he receives no INPS indemnity (TYPET N) and has not surpassed the employer tolerance yet, then he receives a 50% integration.



The COVER markings must be consistent with integrations generated by the valuation rules. So tables T512W and T554C must be customized consistently. The following table is a memo for the percentages and the counters used.


GRAER

percentuale di integrazione

Wage-type counter

1

100

MY71

4

66,66

MY74

3

0

MY73

2

50

MY72

 grades, percentages and counters

Leave for handicapped employee and blood donation

The tolerance tables cannot be used in case of maternity and other parental leaves because these absences are always linked to a particular child (via field OBJPS) and a counter for each child should be considered in table CRT, which is not possible.

In case of handicapped employee (TPEVE 5) and blood donation (TPEVE 70) only one counter is needed and, therefore, tolerance tables can be used.


Special parameters for tolerance: table T5ITIT

Some parameters for tolerance still need to be customized. Since their variety is very large a specially flexible customizing method has been implemented.

A tolerance parameter usually depends on the same factors as the other tolerance tables:

§  employees grouping (MODIF);

§  splitting rule (KLBEW);

§  subrule (SUBRU);

§  seniority (SCAGL);

and usually needs the following attributes:

§  an algorythm and an execution order in all cases;

§  a limit (number of days, times, months, …) and a counter to be compared with the limit in most cases;

§  a qualifying period (in a given time unit) in some cases.

So instead of a large number of columns of a more traditional customizing table, there will be a table with a limited number of columns but a large number of records.

Each parameter and the connected function have different meanings. The function should be called by the program detecting its parameter name that could be an abbreviation (like EB for short event).

With this table it is possible to implement and take into account also complex “Comporto” rules, that cannot be easily represented with rules in other tables such as T5ITIR.


Field

Key

Type

Length

Data Element

Note

MANDT

X

CLNT

3

MANDT

Client

MODIF

X

CHAR

2

MODIF

 

KLBEW

X

CHAR

4

BLKEW

Primary rule

SUBRU

X

CHAR

4

P15_SUBRU

Subrule:
0 (wildcard)

PAYER

X

CHAR

2

P15_PAYER

Payer

PARAM

X

CHAR

2

P15_VARBL

Name of the parameter

SCAGL

X

NUMC

2

P15_SCAGLI

Seniority grade

ENDDA

X

DATS

8

ENDDA

Endda

BEGDA

 

DATS

8

BEGDA

Begda

LIMIT

 

NUMC

4

P15_LIMIP

Limit

UNIM1

 

CHAR

1

P15_UNIM

Unit of measure of LIMIT:  only
V (times),
G (days),
M (months)

QUAPE

 

NUMC

4

P15_QUAPE

Qualifying period in days

WTCNT

 

CHAR

4

LGART

Name of the counter wage-type

FUNAM

 

CHAR

30

FUNCNAME

Function module to be called

ORDES

 

NUMC

2

P15_ORDES

Execution sequence number

UNIMS

 

CHAR

1

P15_UNIMS

Unit of meausure of seniority.
Only months

UNIMQ

 

CHAR

1

P15_UNIMQ

Unit of measure of QUAPE.
Only days and months.

Table T5ITIT: structure


For example, analysing the tolerance for metal workers, you can notice that the following features are excluded from tables T5ITIR and T5ITIU:

§  check of the number of short events;

§  check of the number of long events;

§  check of the number of very long events;

§  check the eligibility of the illness / hospital bonus and the number of already granted days with illness / hospital bonus;

§  check the total number of illness days.


The content should look as follows.


MODIF

KLBEW

SUBRU

PARAM

description

SCAGLI

LIMIT

UNIM1

QUAPE

UNIMQ

WTCNT

FUNAM

ORDES

10

10

01

EB

short event

999

7

V

5

G

MY90

HR_IT_XNAB_EB

10

10

10

01

EL

long event

999

2

V

90

G

MY95

HR_IT_XNAB_EL

31

10

10

01

EM

very long event

36

1

V

120

G

MY96

HR_IT_XNAB_EM

21

10

10

01

EM

very long event

72

1

V

270

G

MY96

HR_IT_XNAB_EM

21

10

10

01

EM

very long event

999

1

V

360

G

MY96

HR_IT_XNAB_EM

21

10

10

01

IL

very long event
maximum
interruption

999

0

M

 

 

 

HR_IT_XNAB_IM

30

10

10

01

IM

very long event
maximum
interruption

999

2

M

 

 

 

HR_IT_XNAB_IM

20

10

10

01

BM

illness bonus

36

60

G

21

G

MY94

HR_IT_XNAB_BM

92

10

10

01

BO

hospital bonus

36

60

G

10

G

MY93

HR_IT_XNAB_BO

91

10

10

01

BM

illness bonus

72

75

G

21

G

MY94

HR_IT_XNAB_BM

92

10

10

01

BO

hospital bonus

72

75

G

10

G

MY93

HR_IT_XNAB_BO

91

10

10

01

BM

illness bonus

999

90

G

21

G

MY94

HR_IT_XNAB_BM

92

10

10

01

BO

hospital bonus

999

90

G

10

G

MY93

HR_IT_XNAB_BO

91

10

10

01

BB

bonus sum

999

120

G

 

 

 

HR_IT_XNAB_BB

90

10

10

01

CS

simple tolerance

36

6

M

 

 

MY97

HR_IT_XNAB_CS

40

10

10

01

CP

extended tolerance

36

9

M

 

 

MY97

HR_IT_XNAB_CP

41

10

10

01

CS

simple tolerance

72

9

M

 

 

MY97

HR_IT_XNAB_CS

40

10

10

01

CP

extended tolerance

72

405

G

 

 

MY97

HR_IT_XNAB_CP

41

10

10

01

CS

simple tolerance

999

12

M

 

 

MY97

HR_IT_XNAB_CS

40

10

10

01

CP

extended tolerance

999

18

M

 

 

MY97

HR_IT_XNAB_CP

41

10

10

01

AS

simple tolerance

36

5

M

 

 

MY97

HR_IT_XNAB_AS

50

10

10

01

AP

extended tolerance

36

8

M

 

 

MY97

HR_IT_XNAB_AP

51

10

10

01

AS

simple tolerance

72

8

M

 

 

MY97

HR_IT_XNAB_AS

50

10

10

01

AP

extended tolerance

72

13

M

 

 

MY97

HR_IT_XNAB_AP

51

10

10

01

AS

simple tolerance

999

11

M

 

 

MY97

HR_IT_XNAB_AS

50

10

10

01

AP

extended tolerance

999

17

M

 

 

MY97

HR_IT_XNAB_AP

51

20

10

01

RP

restoring period for
100% integration
entitlement

999

4

M

 

 

MY65

HR_IT_XNAB_RP

05

20

10

01

SI

checks if there is
indemnity paid by
social insurance

999

180

G

 

 

MY49

HR_IT_XNAB_SI

60

Table T5ITIT: customizing


Each line must be read in a different way, since the real meaning of the parameters depend on the function module used to handle them. Anyway you cannot use any function module with any parameter. For example the way parameter BM is treated (number of already granted illness bonus days) has nothing to do with the way parameter EB is treated (the number of short events in the time window).

Every parameter must be used with the function, whose name ends with the parameter name. All the function modules in the table above are supplied in the standard.

Customers may add their own parameters and write the functions to treat them, or may write other functions to treat the standard parameters. Customers may create any parameter whose first character is a number. Functions written by customers must have the same interface as the other standard function modules quoted in the table above.


Tolerance parameters must be as flexible as possible. Therefore no check is performed on the name (there is no entity table or domain behind it).


The customizing above must be read as follows.

Parameter EB: short events

For the metal worker contract (MODIF 10) a short event is an event not longer than 5 days (QUAPE). If it occurs more than 7 times (LIMIT) in the sliding time window of 36 months (look table T5ITIU) the days belonging to the following short events are counted as double, i.e. they decrease the quota of integration days with double velocity. Counter MY90 stores the number of short events in the sliding time window and is used when we have to check if we exceed the limit.

Function HR_IT_XNAB_EB:

1.       checks if the current absence is a short event;

2.       if so increases counter;

3.       checks if the counter exceeds the limit;

4.       if so sets flag COVER-DOUBL.

This flag implies that each illness day will count as double and will reduce not by one but by two units the amount of the still available integration days. This reduction is not performed in function HR_IT_XNAB_EB but in another point of the standard calculation (see below: XNAB  function description).

Parameters EM, IM, EL, IL: long and very long events

A long event is characterized by a length greater than 90 days (QUAPE). If it happens more than 2 times (LIMIT) in the time window, the employee is entitled to have tolerance extended.

Function HR_IT_XNAB_EL:

1.       checks if the current absence is a long event;

2.       if so increases counter;

3.       checks if the counter exceeds the limit;

4.       if so sets COVER-PROLE to 'P' ("prolungato", while default is 'S', "semplice").

A very long event is characterized by a length grater than a limit depending on the employees' seniority. A very long event may be interrupted (parameter IM: "interruzione di evento molto lungo") but still considered very long if the interruption lasts not longer than 2 months (LIMIT).

Function HR_IT_XNAB_IM only reads the value of  the maximum allowed interruption and must run before HR_IT_XNAB_EM.

Function HR_IT_XNAB_EM makes the same steps as HR_IT_XNAB_EL but in step 1:

a.       also considers if the current absence is an episode of an event;

b.      if so, if the distance between the current and the previous episode is short enough to consider them jointly;

c.       if so, the length of the two episodes are summed up and the sum is compared with the qualifying period.

As a matter of fact, function HR_IT_XNAB_EM and HR_IT_XNAB_EL are using the same subroutine. So, though not required by metal workers contract, if needed by a customer, parameter IL (interruption of long event) could be used. In the standard customizing is not there and therefore has been striked through in the table above.

Functions HR_IT_XNAB_EM and HR_IT_XNAB_EL rely on the fact that absences belonging to the same “evento lungo” or “evento molto lungo” are connected via the KENN1/KENN2 fields in infotype 2001. In addition they require that there is only one infotype 2001 record with each event/part of event.

As long as this fits the requirements these two functions can be used as described above. If it is required to have one of the absences involved in a long or very long event to be split across several infotype 2001 records, than the function module HR_IT_XNAB_ELM can be used. This function module does not require KENN1 and KENN2 to connect the events, nor does it rely on the fact that the events correspond to only one infotype 2001 record.

So for example if an employee becomes ill and sends a certificate for one month and only afterwards he sends another certificate with another month and after that another month, as long as the infotype 2001 records corresponding to those 3 certificates are adjacent (i.e. there is no day in between the records, or stated differently, one record ends exactly the day before the begin of the next record), then they will be considered by function HR_IT_XNAB_ELM as one Long Event. The same holds for the “very long event”: this is one event with at most one single interruption not longer than two months. In order to use function HR_IT_XNAB_ELM, simple replace each occurrence of HR_IT_XNAB_EL and HR_IT_XNAB_EM with HR_IT_XNAB_ELM in table T5ITIT. The rest of the customizing must remain unchanged.

Parameters CS, CP, AS, AP: tolerance limits

Tolerance means not only the number of days with 100% integration and the number of days with 50% integration, but also the maximum number of absence days for illness tolerated by the employer. The tolerance can be simple or extended. The extended tolerance implies a higher maximum and a higher number of 100% and 50% integration days and is therefore more favourable for the employee. This maximum and these numbers of days depend not only on the kind of tolerance but also on the employee's seniority.

As seen when long and very long events were discussed, the tolerance is simple by default but can be extended if there are either at least 2 long events or at least one very long event in the time window. 

Function HR_IT_XNAB_CS:

1.       checks if COVER-PROLE is equals 'S';

2.       if so, checks if counter MY97 (which contains the number of the illness days in the time window) exceeds the limit (e.g. 6 months for the lowest seniority);

3.       if so, a warning is issued telling that the employee may be fired; furthermore field COVER-TFIRE is set to true ('X').

Function HR_IT_XNAB_CP works as function HR_IT_XNAB_CS, but checks if COVER-PROLE is equals 'P'.

It is now evident that processing order matters. Functions HR_IT_XNAB_EL and HR_IT_XNAB_EM must run before HR_IT_XNAB_CS  and HR_IT_XNAB_CP to set field PROLE.


Parameters AS, AP are very similar to CS, CP. They should be customized as shorter tolerance limits used to issue the warning that the employee could reach the tolerance limit during the next month. If there were not this warning, the error message issued by parameters CS and CP are too late, as they mean that an employee has already surpassed his tolerance limit (maybe at the beginning of the month) but he has not been fired yet and a payroll has run also in the current month.

Parameters AS and AP need to have a lower sequence number (ORDES) than parameters CS and CP, since it surpassing parameter CS (CP) surely implies surpassing AS (AP) but not the other way round.


For the rubber industry collective agreement, field COVER-TFIRE is important since it steers the processing of parameter SI (see below).


Parameters BB, BM, BO: bonuses


Function HR_IT_XNAB_BO checks if the employee has been sent to hospital for at least 10 days. This is done by checking the TPEVE and the length of the current illness. If so the employee is entitled to use his hospital bonus. This is a number of extra days with 100% integration depending on the seniority. The function compares this number with counter MY93, which contains the hospital bonus days already used in the time window. If there are bonus days still available then the function writes 'O' in field COVER-BONUS.

If the hospital bonus has not been used for the current illness then HR_IT_XNAB_BM checks if the employee has been ill for at least 21 days. This is done by checking the TPEVE of the current illness. If so, then the employee is entitled to use his illness bonus. This is a number of extra days with 100% integration depending on the seniority. The function compares this number with counter MY94, which contains the illness bonus days already used in the time window. If there are bonus days still available then the function writes 'M' in field COVER-BONUS.

Also here the order of execution matters, since HR_IT_XNAB_BM must follow HR_IT_XNAB_BO. We could also create  a single function with the whole intelligence and both records in the interface.


BB is the parameter for the maximum number of total days for illness and hospital bonus, i.e. the sum of days with hospital bonus and of days with illness bonus must be less than the value in field LIMIT for parameter BB.


Parameters RP, SI: parameters for rubber industry collective agreement

In the case of  the contract for rubber workers this table allows to customize the"restoring period" (parameter RP) , i.e.  the  minimum period without absences after which the amount of days with full integration is restored to its full original level.

MY65 is the counter containing the days since the last absence. This counter is increased by 1 every day, decreased by 1 only on absence days and reset when a new absence begins. If its value is greater than 4 months at the beginning of an absence, then all counter storing numbers of integration days are reset as well.


Function parameter HR_IT_XNAB_SI (SI means surpassing indemnity, "superamento indennizzo") sets field COVER-TYPET values 'N' (not indemnified), 'I' (indemnified) and 'L' ("licenziabile", with surpassed tolerance). If COVER-TFIRE is set to true ('X'), then COVER-TYPET must be 'L'.


The default value for COVER-PROLE is 'S'. Function HR_IT_XNAB_CS must be performed before this field is modified by HR_IT_XNAB_SI. Therefore the processing sequence number (ORDES) for parameter SI must be higher than CS or CP.


Counter MY49 is the same as the one used to count the indemnified days. Since wage-type is customized in table T5ITIR (see above) for illness (KLBEW 10) and the social insurance (PAYER PS), it must be increased like all other counters wage-types via function PAB. Therefore INPS tolerance (tables T5ITIU, T5ITIR) must be checked before employer tolerance. The order of the tolerances is not modifiable through customizing like the order of the parameters of a certain tolerance.

Parameter PF, NR: parameter for comporto window prolongation in case of “Aspettativa

Some contracts require that the time window of the “comporto” is prolonged by the number of days of “aspettativa” (one particular type of  non paid absences in the Italian payroll) that occur in the time window itself. This means that if an employee has a time window of 3 years and takes one month aspettativa, then the time window will become 3 years and one month.

In order to hold such a requirement into account it is necessary to use the parameter “NR” (“Non Retribuito” roughly equivalent to “aspettativa”) and “PF” (Prolungamento finestra).

Days of aspettativa must be counted by means of a line in table T5ITIT with parameter NR.

The situation is summarized in the following table:

MODIF

KLBEW

PAYER

PARAM

WTCNT

FUNAM

ORDES


30


1


DL


NR


MY60


HR_IT_XNAB_NR


4

30

1

DL

PF

MY60

HR_IT_XNAB_DUMMY

3

30

8

DL

NR

MY60

HR_IT_XNAB_NR

2

30

8

DL

PF

MY60

HR_IT_XNAB_DUMMY

1

The effect of those entries is to count all days of the events with KLBEW 1 and 8 into counter MY60. For each couple MODIF/KLBEW the orders must be set so that PF is executed first and NR comes immediately after the PF for the same MODIF/KLBEW couple.

They represent aspettativa, and the counter represents the days of aspettativa in the time window.

Parameter NR takes care of decreasing the counter wage-type as soon as days of the events of aspettativa exit the time window. Entering days (in XNAB) must be counted by increasing the counter wage-type via function PAB.

TIP. The aspettativa rules are usually very simple. One entry in table T5ITI9, stating a processing rule for T554C is usually enough. In T554C then the counter wage-type can be customized, along with other wage-types possibly needed.

Parameter PF has a dummy comporto function, because its function is far from trivial, and is hard coded in the function ITASS FITE. The DUMMY function simply does nothing. The real processing happens in ITASS FITE.

Each comporto subject to window prolongation due to aspettativa must have a line in T5ITIT with parameter PF (also the Aspettativa itself, thus the PF for KLBEW 1 and 8!) as shown in the following table:

MODIF

KLBEW

PAYER

PARAM

WTCNT

FUNAM

ORDES


30


10


DL


AS


MY67


HR_IT_XNAB_AS


30

30

10

DL

CS

MY67

HR_IT_XNAB_CS

20

30

10

DL

PF

MY60

HR_IT_XNAB_NR

5

Each MODIF/KLBEW couple affected by window prolongation must have one line “PF” with the lowest execution order of all parameter for the same MODIF/KLBEW couple.

The execution order for this PF line must however be higher than the execution order of the PF/NR lines for the events representing aspettativa (in our example KLBEW 1 and 8).

The effect of those lines for KLBEW 10 is that in function ITASS FITE, before processing the eventual exit of any day of absence with KLBEW 10 the time window of the comporto is prolonged by the number of days stored in wage-type MY60. So if MY60 holds 30 days and the window length is 1096 days than the time window will be 1126 days.


The window length is “blocked” in XNAB as soon as an aspettativa event is detected. As soon as the last aspettativa day of a given event entered the time window, then the time window is prolonged by aspettativa (if customized accordingly see above) and the exiting of days will continue exactly where it stopped before the start of the aspettativa event.

The detection of aspettativa in XNAB happens via the tipo evento (TPEVE from table T5ITIE).

Aspettativa must have TPEVE “09”!

In ITASS FITE when an aspettativa day exits the time window then the time window is decreased by the total length of the aspettativa event at once. Therefore the first day being processed after the exit of the first day of an aspettativa event will be the first day right after the end of the aspettativa event itself.

Units of measure for limits and qualifying period

The units of measure of the limit and of the qualifying period (fields UNIMI and UNIMQ) are partly checked on the view and partly run-time during the payroll execution.

The checks on the view are reported in the table describing the structure of table T5ITIT: UNIMI must be either G (days), M (months) or V (number of times).

The checks in the payroll depend on the parameter itself. The full compatibility table follows:


Parameter

Admitted units of measure
for limit (UNIMI)

Admitted units of measure
for qualifying period (UNIMQ)

EB

V

G

EL, EM,

V

G, M

IM

G, M

this parameter has no qualifying period

CS, CP, AS, AP

G, M

this parameter has no qualifying period

BO, BM, BB

G, M

G

RP

G, M

this parameter has no qualifying period

SI

G, M

this parameter has no qualifying period

Unit of measure compatibility table for special tolerance parameters

Parameters order

Even for the standard parameters, field ORDES can be freely assigned but their priority must be as shown below (A > B means A must have lower ORDES than B).


PF > NR > RP > EB > IM > EM > IL > EL > CS > CP > AS > AP > SI > BB > BO > BM


The comporto processing engine in XNAB

XNAB features a new comporto (tolerance) processing engine. This engine is responsible for the processing  of tables T5ITIR and T5ITIT. The processing of T5ITIR is rather simple, and it has been described extensively in the previous paragraphs. The processing of table T5ITIT (also already described) however might require some further knowledge on the comporto engine, and its relation to the XNAB payroll schema.

Absences in XNAB are processed day by day.

For each absence day, each relevant “comporto window” in table T5ITIU is processed. The comporto windows relevant for a given absence of a given employee are determined by the employees modif-mod0A and by the default (primary) valuation rule of the absence subtype in table T554S (KLBE1).

For each relevant comporto window all comporto parameters relevant for the employee (modif), absence (KLBEW) and comporto window (PAYER (INPS, INAIL…)) are read out of table T5ITIT.


Each relevant comporto parameter (roughly a line in table T5ITIT) is processed by calling a function module (in field FUNAM). These function modules have a fixed interface and they can change the following:

·         Table IT from payroll;

·         Table COUNTERS from payroll;

·         The cover record for this absence day;

·         Structure with tolerance information (double days bonus tolerance type).

A typical function will check the tolerance, for example if the employee is entitles to 20 days absence paid 100% per year; then the function will read the counter, check it and if the employee is entitled to those 100% integration days it will then update the counter table, if needed  generate the counter wage-type, and set the field GRAER in table cover (p_s_mark) with the integration grade corresponding to 100% via the rule specified in T5ITIQ.  A detailed description of all functions and their actions has been given above.


From the above description it emerges that basically XNAB uses “counters” to keep track of the history of absences for a given employee. Those counters are wage-type whose cumulations are read from table CRT and put into payroll table COUNTERS.

When an event happens on a certain day then the counters that are relevant for that event are checked, rules are applied in order to:

a) decide what valuation rule to use (via field GRAER/GRASI and table T5ITIQ);

b) update the counter table;

c) change the tolerance structure for this tolerance window.

While the first two steps are intuitive, the last one is not trivial.

In order to satisfy complex requirements coming mainly from Metalmeccanici contract, but also Rubber and other contracts, it is necessary to provide a way to change the valuation of absence days in a vary radical way.

For Metalmeccanici in some situations there is a change in all tolerance limits (switch from comporto semplice to comporto prolungato). In table T5ITIT the comporto type is a key field and a change in the comporto type can be used to switch to a totally different set of tolerance rules.

So for example during processing of an illness the engine realizes that there is a very long event.

The function HR_IT_XNAB_ELM sets the field “prole” in the tolerance structure to ‘P’ instead of ‘S’.

From this point on all further processing will happen using the tolerance parameters with key PROLE equal ‘P’.

This hold also for other values/situations. A list can be found in the description of each comporto function module above.


In the same way that counters are generated by XNAB, some means must be provided for making the days “exit” the comporto time window. In fact the tolerance rules usually state that the history of absences for an employee must be kept for a given time frame (for example 3 years). In this example after 3 years an event happened, the corresponding comporto counters must be reset as if the event never happened. This is performed by function ITASS FITE.

So first in function ITASS FITE a check is performed if there are any events (cover records) existing in the comporto time window. If there are any, then the function module in table T5ITIT field FUNAM is called again. Here the task of the function module is to reset counters in order to make the event “exit” in the time window. This typically involves generating a wage-type in order to adjust the counter and is fairly simple.




How to write a comporto function module


Writing comporto function modules is a relatively simple process once the comporto processing is clear, and if a detailed analysis of the problem to be solved has been made.

In order to get started with a new special comporto function, it is recommended to copy an existing one, in order to get the right interface.

Each comporto function has two processing steps:

1) The function can be called by payroll function ITASS FITE with parameter p_func equal c_fite. This happens when a day exits the comporto time window. In this case the function module is called in order to perform whatever action is required. Typically this will be increasing a counter, but can also be some other action. For example if a day of bonus malattia exits the time window then the right to the bonus is incremented again.

2) The function can be called by XNAB during the normal processing of absence days with p_func equal c_XNAB. The purpose here is to determine the new value of the counter, possibly generate the counter wage-type and if needed set fields in table cover.


Whenever possible it is recommended to use function PAB and table T554C for the generation of counter wage-types.


In order to generate wage-types please use form gen_wt in function group HRPAYIT_COV.

In order to update counters please use form  XNAB_cumul_counters in function group HRPAYIT_COV.

In order to set cover fields please change the parameter p_s_mark directly.


N.B. Special caution is required in the coding. It is necessary to consider that by changing the IT table for example, it is possible to completely alter the payroll results for a given employee!


It can be useful to look at the coding for the existing comporto function modules provided in function group HRPAYIT_COV.


The following table describes the interface of  a comporto processing function module:


Parameter name

Type

Description

Valid

P_S_PARAM

T5ITIT

The record of table t5itit that originates this comporto parameter

XNAB

P_S_AB

PC20I

The AB (absence) record that is being processed

XNAB

P_FUNC

T52B8-FUNCO

C_FITE if the function is being calld out of function ITASS FITE
C_XNAB if the function is called by XNAB

Both

P_S_DAY

PITCO_S_DAY_ATTRIBS

Structure with information on the current day
  pernr (CID)
  cdate (date of the day being processed)
  endev (flag = c_true if this is the last day of the event)
  tpeve (tipo evento from table t5itie for this event)

Fite

P_S_CNT_LIST

PITCO_S_CNT_LIST

Structure with the parameter being processed (fields are the same as in table t5itit/t5itir)

Fite

P_S_TOLERANCE

PITCO_S_TOLER_ATTRIBS

Attributes of the tolerance window
  pernr (CID)
  doubl double day
  prole tolerance type
  restp restoring period (gomma)
  bonus (ospedale or malattia)
  molga

XNAB

P_S_MARK

PTM_MARKTAB_15

The record of table cover for this day

Both

P_TAB_COUNTERS

PITCO_TAB_COUNTERS

Table with all counters update only with XNAB_update_counters

XNAB

P_VALUE

PC207-ANZHL

To be set when p_func = c_fite The value will be used to adjust (i.e. added) the counter being processed. So if the counter must be decremented by one the p_value must be set to -1

Fite

P_TAB_ERROR

PITCO_TAB_ERROR

Table with errors/warning or information. The structure is similar to T100

Both

P_TAB_IT

PITCO_TAB_PC207

IT table from payroll. Wage-types can be read, or generated via form gen_wt

Both


Customizingorder

These and some other tables should be customized, through the respective view, in the following order, which reflects the foreign keys and make data input easier:

  1. V_T554L: declare the primary rules;

2.       T554S: assign each absence a primary rule;

3.       V_T554M: maternity constraints;

4.       V_T556E: define rule groups;

5.       V_T556G: define rules;

6.       V_T5ITIE: assign each absence a TPEVE;

  1. V_T5ITI8: define wage-types to build valuation bases;

8.       V_T5ITIU: define tolerances;

9.       V_T5ITIR: define tolerance quotas;

10.   V_T5ITIT: define special parameters for tolerance;

11.   V_T5ITI9: define fixed_width splitting intervals;

12.   V_T5ITIQ: determine secondary rules;

  1. V_T556M: define partial day absences;

14.   V_T5ITIV: determine secondary rules;

15.   V_512W_B: assign wage-types to a valuation base;

16.   V_T554L: declare secondary rules;

17.   V_T554C: define wage-types to be generated by absences.

The international tables T556E and T556G must be customized with at least a record (see the standard customizing) and provide a basic marking possibility, which is unfortunately unadequate for Italy.

All hourly leaves that could lead to an intraday splitting must be declared in table T556M.


 

Infotype 2001

In the INAB solution infotype 0407 was required to enter relapses, which can actually be entered also in infotype 2001 using dynpro 2002 (see image below) or 2008, since infotype 2001 has its own fields KENN1 and KENN2. In addition the use of infotype 0407 has always been source of misunderstandings and errors. The reason for this is that often infotype 0407 was not maintained or vice versa somehow records in infotype 0407 existed without a corresponding infotype 2001 records.

Considering the scarce need of such a double maintainance, infotype 0407 is no longer used for XNAB.


Dynpro 2002 for infotype 2001


The use of the “standard” dynpros of infotype 2001 requires however some customizing, in order to  adapt them to the specific needs. It can be easily noticed that some fields in figure are not needed. They can be hidden via T588M. In addition some custom requirements might arise regarding checks on the “collegamenti” fields (KENN1-2) or on special situations (for example not more than n days for a given subtype in one month).

Those checks are not implemented in the standard, but they can easily be implemented in the user exits in master data (for ex. PBAS00001).


Dynpros can be assigned to absences through view V_T554S. Some event types (TPEVE) require specific dynpros.


Process

The new payroll schema

The schema should look as follows.


Subschema IT01 is a switch between new and old solution. Feature COVGL (COVER going live), which contains the date of the productive start of the new solution, is tested in function ITASS INDA. If that date is passed, schema IT02 containing the new solution based on XNAB is called. Otherwise schema IT00, old schema containing INAB, is called.

 

switch between INAB and XNAB


When executing a retrocalculation, results produced via IT00 will be produced again with IT00.


New subschemas IT11, IT12, IT13, IT14, IT15 and IT16 contain the steps already present in the old solution. The new steps have been concentrated in schema IT02.

Setting the absence modifier MODIF: function MOD, rule IMOD

Rule IMOD sets all modifiers of structure MODIF. The one used in the absence calculation is the MODIF-MOD0A, always simply called MODIF.

Most Italian and international customizing tables are read with field MODIF.

To allow maximum flexibility MODIF could depend on many employee's attributes. To reproduce the customizing of the old solution, the pay scale variables (TRFAR, TRFGB, ...) can be taken into account. The schema behind the standard customizing is explained in the table below:


PERSK

TRFKZ

ABART

TRFAR

INPS
illness
indemnity

Illness tolerance

MODIF-
MOD0A

I1 (manager)

1

2 (periodic payments)

04 (metal)

no

no

13

I1

1

2

05 (trade)

no

no

13

I2 (quadro)

2

2

04

no

yes

12

I3 (clerk)

3

2

04

no

yes

12

I3

3

2

05

yes

no

22

I4 (equiparato)

4

2

05

yes

no

22

I5 (worker monthly)

5

3 (salaried ee)

04

yes

yes

10

I5

5

3

05

yes

no

20

I6 (worker hourly)

6

1 (hourly earners)

04

yes

yes

11

I6

6

1

05

yes

no

21

absence modifiers MODIF


If there were a special TRFAR for managers, MODIF could be directly derived from TRFAR and ABART.


Updating tolerance counters: function ITASS FITE

At the beginning of this step, employee's SUBRU is determined via a feature.

The main purpose of this step is to move forward the tolerance time window, monitor the absence days exiting the time window and update the tolerance counters. This step must be before XNAB in the schema. During XNAB, when comparing the value of counters MY71, MY72, … with the maximum number of integration days, those counters must contain only absence days actually lying in the time window.

The time window moves forward day by day.

Function ITASS FITE runs every month even if there are no absences. The function reads table T5ITIU with the MODIF of the current employee and all KLBEW's, since all counters must be updated all the months.

For example, the following records are selected.


MODIF

KLBEW

SUBRU

 

PAYER

WIWID

UNIMW

WITYP

MEKEN

10

10

0

illness

PS

12

M

I

X

10

10

0

illness

DL

36

M

F

 

Table T5ITIU: customizing


The INPS tolerance can be ignored since time windows of type I (increasing yearly) do not have a fixed size and the corresponding counters can be reset in predefined places. The time window for illness for INPS and its counters, for example, are always reset at the beginning of the first payroll of the year (not at the end of the last payroll of the year, since the counters in December CRT must contain the totals for the whole year).

Only the record referring to the illness for the employer is processed. The counters to be updated are read from tables T5ITIR and T5ITIT entered with key MODIF 10, KLBEW 10, PAYER ER and the employee's seniority (for example 50 months).



Counters MY71 and MY72 are used for each type of tolerance and seniority, because the employee may change tolerance type and increase seniority but his history is still contained in the same wage-types.



Function ITASS FITE reads from the CRT the values of all these counters and builds table COUNTERS. Table COUNTERS is an internal table of the payroll. It can be seen in the output of function ITASS FITE and XNAB.

Although the time window for INPS illness tolerance is of type I and no day exits the window, counter MY49 is also monitored in table COUNTERS and updated in function XNAB




Splitting the absence: function XNAB

After function RAB converts infotype 2001 into internal table AB, function XNAB splits the absence into days or fraction of days in two steps:

1.       marks table COVER;

2.       splits AB records and sets the valuation rule on each AB record.

Function XNAB is an international function with Italian country exits, i.e. Italian function modules that implements the Italian absence splitting logic. Step 1. is performed by function module HR_COV_DETERMINE_MARK_15. Step 2. by HR_COV_ENRICH_AB_15. See in the appendix the entire call stack and read XNAB documentation if you want to implement the user exits.

Before step 1. and 2., function HR_COV_CHECK_AB_15 intercepts all absences without TPEVE set since they do not require refinement through XNAB. Otherwise they would be processed by HR_COV_ENRICH_AB_15 and be split in single days.

Marking table COVER: function module HR_COV_DETERMINE_MARK_15

To mark table COVER, function XNAB:

  1. loops over the absences (AB records);
  2. loops then over the days of each absence;
  3. processes the single absence day;
    1. sets field COVER-DAYEV building the whole chain of episodes belonging to the same event using fields AB-OBJPS,AB-KENN1 and AB-KENN2;
    2. uses the Italian customizing tables in the following order:

1.T5ITI9: fixed-size intervals;

2.T5ITIU: tolerances (first INPS, then employer). For each tolerance found:

a.T5ITIT: special parameters;

b.T5ITIR: tolerance quotas;

3.T5ITIQ: determination of secondary rule for daily leaves;

4.T5ITIV: determination of secondary rule for hourly leaves.


Splitting daily absences: tables T5ITI9, T5ITIU, T5ITIT, T5ITIR, T5ITIQ

Firstly, table T5ITI9 is read with the KLBEW of the current AB record and the MODIF, SUBRU and seniority of the current employee. If nothing has been found SUBRU 0 is used to read the table.

For example, MODIF equals 10, SUBRU equals 1, KLBEW equals 10 (illness) and seniority equals 2 years (see customizing reported above for table T5ITI9).

Each illness and its relapses constitute an absence that has to be split in those intervals. Therefore the fixed-size interval upper limit (field T5ITI9-LIMIT) is compared with field COVER-DAYEV and not with COVER-DAYAB. This is also the reason why parental leaves and leave for handicapped employee must be linked via OBJPS or KENN1 and KENN2 (see above).
With the information of table T5ITI9 field COVER-GRASI is filled with indemnity grades 1, 2 or 3.

 

Generation of valuation basis

Rules ITBx

These are rules based on PORT and PIT. SAP should only deliver some sample rules.

WT13 - WT16 are time wage-types containing number of days. They are generated by RPTIME00 or by DAYPR. Therefore the rules generating the valuation basis must be placed after function ZLIT.

Integration will be still based on /001. For indemnities the following evaluation basis have been introduced:

§  /030, for INPS indemnity in case of illness;

§  /031, for INPS indemnity in case of maternity;

§  /032, for INAIL indemnity in case of work accident.

These evaluation basis are derived in a regular way from the payroll results of the previous month through cycles ITB1, ITB5, ITB9.
If there is no previous month, then they are derived from the wage-types in table IT. This involves the following steps:

§  ITB2, ITB6, ITBA store in a variable the evaluation basis calculated via PORT, i.e. on the wage-types of table ORT;

§  ITB3, ITB7, ITBB check if the variable is greater than 0;

§  ITB4, ITB8, ITBC calculate the basis from the wage-types in table IT. They are equal to ITB1, ITB5, ITB6 but for the ADDWT * statement, whitout which in the PIT we would lost the wage-types we sum in the basis.

ABART of valuation basis built by ITB1, ITB5, ITB6, is *. This is due to the fact that wage-types used to build the evaluation basis (MINP, /RQ1, …) are stored in the RT table with ABART *. Wage-types to be evaluated in rule I015 have ABART different than * but could be succesfully evaluated by I015 only if they have the same ABART. So we must correct the ABART of the evaluation basis. This could be done in several ways.

We could store in RT the wage-types with the right ABART before we perform an ELIMI split on them. The payroll would then continue using the wage-types in IT as it does now.

PIT ITBD corrects the abart using operation WPALL.

Function ITASS BASE

Valuation basis could also be built via function ITASS BASE. This function reads table T5ITI8 for all the absences of the month and generates the needed wage-types, as described above in the paragraph related to table T5ITI8.

Valuation base for relapses: function ITASS RICA

If fields OBJPS or KENN1 and KENN2 are full a chain of episodes referring to the same event can be built. This is not useful to check the limits of table T5ITI9 (see above function XNAB) but also to recover the valuation base of the first episode of the chain. Events of type (TPEVE) 7, 32, 33 and 34 are excluded since they are unpaid and must refer to the month they lay in.

Special processing is provided for maternity (optional and compulsory): here the valuation basis is determined basing on the last month where the employee has worked, even in case of switch from compulsory to optional maternity and from maternity  “anticipata” to obbligatoria. In all cases it is required that the maternity has TPEVE 30 for compulsory and “anticipata” and 31 for optional maternity.

Reduced payments preparation: function ITASS VOSE

Annual report CUD could get easier if wage-types containing the reduced payments of each week were already available.

During ITASS VOSE, for each single week in the current payroll month:

§  worked hours (/MOL from table ZL) are summed up into wage-type /EMO;

§  overtime (/STR from table ZL) are summed up into wage-type /EST;

§  holidays (field STDAZ of table PSP in days with FTKLA <> '0') are summed up into wage-type /EFE;

§  hours referring to not protect absences (field STDAZ of table PSP in absence days with empty event type, TPEVE) are summed up into wage-type /ENP.

Integration hours have already been generated by PAB. They will be summed up on a weekly base in the CUD section 3 itself.

The sum of all these wage-types is the value of box38 of  part C of CUD.

These numbers of hours must be multiplied by an hourly basis (like /001). We assume that PIT I015 itself is used for the evaluation. Therefore ITASS VOSE must be placed before PIT I015.

Gross/net adjustment: function ITASS NELO

Function ITASS with first parameter NELO should comprehend the following steps:

1.       loop over table IT;

2.       check processing class 70 for each wage-type;

3.       if processing class 70 equals 1 then the wage-type is an indemnity;

4.       if processing class 70 equals 2 then the wage-type is an integration;

5.       all indemnities on one side and all integrations on the other side are summed up;

6.       the net/gross operation is performed:
(integrations * t5iti8-perne - indemnities) * t5iti8-perlo;

7.       if the result is positive, then wage-type T5ITI8-WTIAD (MI58, which must have processing class 70 equals 6) is generated, which is the net amount paid to the employee;

8.       if the result is negative, then wage-type T5ITI8-WTRAZ (MI59, which must have processing class 70 equals 7) is generated, which represents the debt of the social  insurance to the employer.

Gross/net adjustment is not performed for each single day but for days that originally belonged to the same infotype 2001.

Last adjustments: function ITASS AGGI

If the day counts double (this happens when too many short events occur, see below) the counter wage-type (MY71, MY72, MY93, MY94) generated on that day via PAB should be equal 2 and not 1. The number (ANZHL) of the counter wage-types need to be duplicated after the valuation. To do that we must be able to recognize the counter wage-types via a processing class (i.e. processing class 70, value '3').


Function ITASS AGGI also multiplies by 2/5 the amount of indemnity, if the employee is at hospital and there are no family members dependent on him.


Contract dependent limitation to integrazione: function ITASS PLAF

Function ITASS PLAF uses table T5ITIG to put a limit to the integration paid by the company in one month.

For some contracts the employeer pays only up to n hours/days of integration in one month. If for some reason the employee has more than this number of hours then they are not paid anymore. The limits are in table t5itig. On the other hand if the employee is absent the whole month (illness starting before the begin and ending after the end of the month (including the start/end days of the month) and the integration is less then the limit in t5itig then additional integration days/hours are added in order to have the integration equal to the limit in t5itig. In other words if integration is above the t5itig limit then integration is clipped to the limit and only a number of hours/days equal to the limit in t5itig are generated. If the absence covers the whole month then always the same number of integration hours/days are generated equal to the limit in t5itig.

In order to disable these checks it is sufficient not to have a t5itig record relevant for this employee or to have a record where the fields HCONV or GGCON are 0.


The addition/reduction of the hours/days occurs changing the integration wage-types (based on processing class 70 values 2 and 5 (integrazione and integrazione no nettiz.) ) related with ABZNR to the AB records with the same OBEGD/OENDD (thus belonging to the same absence in 2001).


Cluster PC Viewer

Cluster PC viewer RPCLPCI0 has been enhanced to display also table COVER.

In addition the display has been improved. Now all selected cluster entries are listed in an ALV list for each person. It is then possible to select the desired clusters among the listed ones, and to show them yet  in another ALV list. The result is that it is simply possible to get the COVER or the sezione 3 or any of the join views for sezione 3 in a list for many employees with indication of the CID (employee). This is useful for reporting purposes, as the ALV list can be exported easily to excel and there easily manipulated.


RPCLPCI0 new pushbuttons

When clicking on button 1 function module HR_IT_WRITE_COVER is called. All fields of table COVER, the name of the day and the INPS week number are displayed in an ALV. The structure of this view is P15_COVER.


table COVER display





User Exits.

User exits are provided in order to allow an easy implementation of custom requirements, without having to make “modifications” to the SAP standard coding.


ADJUST_MARK_MAPPING: during the NCALE to COVER conversion the COVER mark can be changed.

ADJUST_VALUATION_BASES: the valuation basis produced by ITASS BASE can be changed here.

ADJUST_SENIORITY_CALCULATION: the seniority of the employee can be determined here in a custom way.

ADJUST_DETERMINED_MARKS: after the processing of each absence day this method is called in order to allow adjustments to the marking or/and to allow special processing.

ADJUST_DAY_FRACTION: in case of hourly absence the day fraction can be changed with this user exit. The day fraction is  a number representing the amount of absence on that day, usually the ratio between absence hours and hours the employee should have worked.



ADJUST_MARK_MAPPING

In this user exit the cover mark determined from the NCALE (INAB) mark can be adjusted. The standard coding in function HR_COV_MAP_MARK_15 takes most cases into account, but adjustements might be needed.

Parameters:

Parameter

Description

P_PERNR

CID/Personnel number

CHECK_DATE

The date fo the current day

AB

The AB record corresponding to the current absence

PSP

The personnel shift pülan for the current day

WPBP

WPBP record for the current absence

I0000

Table with infotype 0

I0001

Table with infotype 1

I0002

Table with infotype 2

I0004

Table with infotype 4

I0007

Table with infotype 7

I0008

Table with infotype 8

I0016

Table with infotype 16

I0041

Table with infotype 41

I2001

Table with infotype 2001

PCALI

Record of NCALE to be converted

P0407

Record of infotype 407 corresponding to the current absence (not always filled)

T503

Record of table T503 for the current CID

T001P

Record of table T001P for the current CID

Mark_15

The COVER mark corresponding to the current day

P_error_tab

Table with errors (structure like T100)




ADJUST_VALUATION_BASES

With this method valuation bases can be adjusted after the processing loop in T5ITI8. This method can also be used to load valuation basis at the startup of XNAB or in special situations where a known  valuation basis needs to be used. The purpose is to insert the valuation basis wage-types into table  PT_IT.

Parameters:

Parameter

Description

PERNR

CID

PT_ORT

ORT table from payroll

PT_T5ITI8

Table with T5ITI8 records

PT_AB

TableAB from payroll

P_MODIFA

Absence modificator for current employee (MODIF-MOD0A)

PT_P0001

Infotype 1 table

PT_ZL

ZL table from payroll

PT_WPBP

WPBP table from payroll

P_BEGDA

Begin datum (aper-begda from payroll)

P_ENDDA

End datum (aper-endda from payroll)

PT_IT

Table IT from Payroll: here set/change the valuation basis

PT_ERROR

Table with error (structure similar to T100)

P_ERROR

Error flag: 0 means OK. Non zero means error


ADJUST_SENIORITY_CALCULATION

This BADI method is called from function HR_COV_DETEMINE_MARK_15. Its purpose is to allow a custom determination of the seniority of an employee, for the purpose of reading the absence customizing dependent on the seniority.

For example seniority can be stored in infotype 0041 or in custom (Z) field in infotype 0016.

The standard seniority calculation reads infotype 0016, field EINDT otherwise it guesses seniority from the begin date of the first infotype 0001 record of the employee.


In order to change the determined seniority simply set field p_s_key-scagl with the months of seniority.

TIP. The seniority is the difference between entry date and current day. To transform this into month the form “trans_days_in_months” in the function group HRPAYIT_COV can be used.

Parameters:

Parameter

Description

P_S_MARK

The current cover record (field cdate hold the current date)

P_S_AB

AB record related to this day

P_TAB_P0001

Table with infotype 0001

P_PERNR

CID

P_S_KEY

Structure with key for reading customizing . Fill fields SCAGL with the month of seniority



ADJUST_DETERMINED_MARKS

This method allows to change any marking for any absence being processed by XNAB (HR_COV_DETERMINE_MARK_15).

Parameters:

Parameter

Description

P_PERNR              

CID

CHECK_DATE           

Current date

AB  

AB record of the absence this day belong to

I556G    

Record of table T556G (usually unused)

PSP 

Personnel shift plan for that day

WPBP  

WPBP record for the current absence

MODIF                

Table with modifs from payroll

MOLGA   

MOLGA

PSP_TAB              

Table with personnel shift plan

P_SUBRU              

Subru field as determined by readinf feature SUBRU

MARK_15              

The mark for the current day

FRACTION_MARK_TAB    

The table with fraction marks for this day

CURR_ABZNR           

The current ABZNR (absence pointer)

P_TAB_IT             

The IT table from payroll


ADJUST_DAY_FRACTION

This method allows to change the mark for a given day, at the stage of the determination of the fraction of the day on which the employee is absent. The default is read from field IT2001-ABWTG, and is determined by the ratio of the absence hours and the hours the employee should have worked.

The field in the mark_15 parameter to set is the DYFRC.

Parameters:

Parameter

Description

P_PERNR              

CID

CHECK_DATE           

Current date

AB  

AB record of the absence this day belong to

PSP 

Personnel shift plan for that day

WPBP  

WPBP record for the current absence

MODIF                

Table with modifs from payroll

MOLGA   

MOLGA

PSP_TAB              

Table with personnel shift plan

P_SUBRU              

Subru field as determined by readinf feature SUBRU

MARK_15              

The mark for the current day

 

 

 

 



In case of custom requirements that cannot be implemented in one of the above mentioned BADI methods please contact SAP support. Additional methods, if needed and if their introduction benefits the whole absence processing, can be added.

Processing class 70

Values of processing class 70 are the following. The table also shows where they are used.


Value

Meaning

Standard customizing

Payroll function

Annual reporting

1

Indemnity to be
gros-adjusted

MI46, MI47, ...

ITASS NELO

CUD

2

Integration to be
net-adjusted

MI71, MI72,
MI93, MI94, ...

ITASS NELO

CUD

3

Counters to be doubled

MY71, MY72,
MY93, MY94, …

ITASS AGGI

 

4

Indemnity not to be
gros-adjusted

 

 

CUD

5

Integration not to be
net-adjusted

 

 

CUD

6

Result of the gros/net
adjustment if positive

MI58

ITASS NELO

 

7

Result of the gros/net
adjustment if negative

MI59

ITASS NELO

 

8

Other tolerance counters
to be reset when
parameter RP is used

MY97

XNAB (Function module
HR_IT_XNAB_RP)

 

processing value 70


Customizing tables

These and some other tables should be customized, through the respective view, in the following order, which reflects the foreign keys and make data input easier:

  1. V_T554L: declare the primary rules;

2.       T554S: assign each absence a primary rule;

3.       V_T554M: maternity constraints;

4.       V_T556E: define rule groups;

5.       V_T556G: define rules;

6.       V_T5ITIE: assign each absence a TPEVE;

  1. V_T5ITI8: define wage-types to build valuation bases;

8.       V_T5ITIU: define tolerances;

9.       V_T5ITIR: define tolerance quotas;

10.   V_T5ITIT: define special parameters for tolerance;

11.   V_T5ITI9: define fixed_width splitting intervals;

12.   V_T5ITIQ: determine secondary rules;

  1. V_T556M: define partial day absences;

14.   V_T5ITIV: determine secondary rules;



15.   V_512W_B: assign wage-types a valuation base;

16.   V_T554L: declare secondary rules;

17.   V_T554C: define wage-types to be generated by absences.





Notes

Please, read also the following notes:

·         386736

·         715581


  • No labels