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

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:

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.

Table T5ITI8: structure

Customizing could look as follows.

 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.

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.

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.

 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.

 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:

This can be easily represented with table T5ITI9 as follows:

 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.

 Table T554C: customizing

 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.

 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.

 Table T5ITIQ: customizing

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

Table T554C: customizing

 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.

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.

 Table T5ITIU: customizing

Tolerance quotas: table T5ITIR

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

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.

 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.

 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.

 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.

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.

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:

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:

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:

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:

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:

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.

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:

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:

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:

ADJUST_DETERMINED_MARKS

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

Parameters:

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:

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.

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