Integration Definition

In this option are defined in which events will be sent the normal hours, day and night hours for the monthly and in which events will be calculated the DSR and the form that will be calculated for the payroll.

General

Generate Admitted in the Period
Indicate whether or not employee events in the period should be generated.

Example:

• Period from 21.08.2000 to 20.09.2000.
• Collaborator admitted on 23.09.2000.

This contributor will have no days calculated in the competence of September, but the system will calculate the hours of the day 23 day 9/30/2000.

Generate Dismissed in the Period
Indicate whether the employee events dismissed in the period should be generated or not.

Normal Daytime Hours Event
and Event Night Standard Hours Enter the event code for normal daytime / night time.

Separate Monthly DSR Notify "S" If employees pass holders should have the DSR calculated in DSR event or notify "N" for which DSR hours are considered as normal.

Recalculate Previous Months
Inform if the company uses routine for recalculation of previous months.

When is marked "S" in this field will be enabled the following options:

• "Calculations> Integration> Recalculation": The Recalculation routine works in the same way as the Event Generation routine, but writes the data to another table (R044REC) and can generate different values ​​as the changes are made after the events for Folha;
• "Calculations> Integration> Generate Differences": The Generate Differences routine is used to compare the differences between the standard calculation (which was for Sheet), which is in the R044MOV table, and what was recalculated (R044REC). This routine compares what has been calculated and recalculated in previous months and writes the differences in another table (R044FEC) only in the current calculation.

Example:

1. For the calculation of the Calculation from 01/11/00 to 30/11/00. The company generated the integration until November 11, 2000, projecting the hours until November 30, 2000;
2. In the second figure, the company recalculated the integration, generating the events until November 30, 2000;
3. In the calculation of December the company generated the difference of the calculation of November.

First Week Rule This rule is used to check the days prior to the beginning of the current period to DSR or similar specific calculations.

And there is the rule of first week registered, the control of point and Cafeteria will return in days to find the latest DSR of the previous period. From there it will run this rule. Are used the same variables of the Generation Period rule.

Generation Period Rule
Enter the code for the rule to be executed in generating, calculating variables that can be used by integration.

This rule is executed once for each day, every day, for each employee. Runs after the first week, and in some cases may have the same code.

Rule Period Projection
It is a rule that will be enforced in all days of the period. The projected period starts at the start date of the Sheet Period and goes through the date reported in the "Generate" option.

Is performed after the rule of the period, and in a few days you can run the two rules, if there is overlap between the period of Investigation and the period.

Final Calculation Rule
Enter the code for the rule to be executed in generating, calculating and adjusting the values of the events. This rule is executed once for each employee, after all other rules. Usually this rule gets calculated variables in the first week, rules generation and Projection Period, to launch events.

Events To generate a report automatically after the Integration calculation, enter the name of the template in this field.

Example:

HRIN004.GER. When performing the Integration calculation, it is necessary to enter 'S' in the field Generate report. This way, when the calculation is finished the report opens on the screen.

Recalculation Report Events Sheet
To generate a report automatically after the Recalculation of Integration, enter the name of the template in this field.

Example:

HRIN005.GER. When performing the Integration recalculation it is necessary to inform "S" in the field Generate report. This way, when the recalculation is finished the report opens on the screen.

Generate Differences in Recalculation
Informed "S" in this field, the batch job will compare the differences between the standard calculus (which was for sheet) which is in the R044MOV table, and what was recalculated (table R044REC).

Differences will be recorded in the table R044FEC with the active calculation code at the time of execution of the routine. The generated differences can be found in Calculations> Integration> Queries> Recalculation, informing "P" in the field Type or listed on report through the HRIN006.GER template.

To send the differences that are in the R044FEC table for the sheet, you must use the import and export. If the value of an event of the R044MOV table is greater than the value of the same event in the R044REC table, the difference generated will be negative.

Integrate with success pending

• "N - No": check if the employee has a pending status with the status "Pending with employee", "Expired" or "Pending with manager";
• "S - Yes": the employee will be integrated without any validation.

Integrate with unchecked days

• "N - No": verifies if the employee has any day of the period that has not been verified yet;
• "S - Yes": the employee will be integrated without any validation.

Event Overtime Bank of Hours
Enter the overtime event code for calculation integration.

Event Hours Compensated Bank of Hours
Enter the missing-time event code for calculation integration.

With this configuration of the overtime and missed events for integration, the time bank information is sent to the sheet which, consequently, meets the requirements of eSocial.

In the first month of the compulsory use of eSocial, when there is balance in the bank of hours, it is necessary to send it to the corresponding events, extras or faults. After this month, the sending will be made of the total amount of overtime and negative (only one of the events will be generated, with the difference between the positive and negative hours).

Example:

• Opening balance: -20: 00
• Positive hours: 10:00
• Negative hours: 05:00

When it is the first month of eSocial, 15:00 negative will be generated. In a normal month will be generated 05:00.

• Initial Balance: +20: 00
• Positive hours: 05:00
• Negative hours: 30:00

When it is the first month of eSocial, 5:00 negative will be generated. In a normal month will generate 25:00 negative.

WPRP

Event Pagto. Daytime DSR
Tell where event code will be calculated the day DSR.

Event Pagto. DSR Night
Tell where event code will be calculated the DSR. If the company does not differentiate the DSR's night day enter the same code of the previous data.

Event Day DSR Loss Tell where event code will be calculated the hours of lost DSR diurnal.

Event Night DSR Loss Tell where event code will be calculated the time DSR loss at night.

If the company didn't differentiate DSR loss of daytime nocturnal, enter the same code of the previous data.

Reflex Event Overtime on DSR Inform the code of the event in which the Reflection of Extras on DSR hours will be generated, which must be previously registered in Tables> Events> Registration, informing in the tab Base the codes of the Extra Hours events that should generate the reflection.

The formula used by the system to calculate this event is as follows: Reflection = ((HE * VC) / HT) * HDSR, where:

• HE: Number of Extra Hours.
• VC: Event Calculation Value (reported in field Value Calculation in Tables> Events> Registration).
• HT: Number of Work Hours.
• HDSR: Number of DSR Hours.

Example:

• Collaborator with work 190: 40, 29:20 DSR and 2:00 pm overtime with 100%.
• Converting hours to minutes: 11440 working minutes, 1760 minutes of DSR and 120 minutes of extras with 100%.
• Then apply the percentage on the extras: 120 + 100% = 240 minutes.
• Finally, the formula applies: (240/11440) * 1760 = 36.92.
• Converting the result to hours: 00:36.

Thus, the event of Reflex of Extras on DSR will be generated with the reference 00:36.

Event fine DSR day payment Enter the code for the daytime DSR fine payment event.

Event payment fine night DSR Enter the code for the night DSR fine event payment.

Calculation of Mixed DSR
Refer to the Time and Cafeteria Control how to calculate the hours of DSR when timetables diurnal, nocturnal and/or mixed in the same week.

For the calculation of the Proportional and the largest, the Time and Cafeteria Control seeks the daylight hours and at night, as the time registered on the day. Are not considered cleared situations.

Night Converter for DSR Calculation
Valid option when the DSR is Proportional or the highest.

If it is informed "S", performs the conversion of the night hours only to calculate the apportionment of DSR (proportional) or to check if there are more daylight hours or at night (in the case).

Calculate DSR as Scale Tell how to calculate the DSR event.

• "S - Yes": the calculation of the DSR event will be done according to the amount of DSR's (time 9999) reported on the employee scale;
• "N - No": The DSR event will be calculated according to the number of Sundays in the period.

Pay DSR of Last Week Indicate how the company treats the payment discount of DSR when the developer lacks the last week of the period, being the day of DSR is in the next period.

Example:

The period ends on a Wednesday. The developer lack on Tuesday and the Chief determines that he will lose the DSR of the week. In this case there are two options, discounting the DSR in this period (Current option) or cash in the following period (option).

Holiday loss will be incurred in the fault period, along with loss of DSR.

In the next period, if it has not been done in the past integration, it will not be lost, since it should have already been discounted for the system. That is, for the system, the holiday loss has the same behavior as the loss of DSR, check the field Pay DSR of Last Week in the definition of integration, "DSR" tab.

If "A" is set, the DSR and Holiday discount will occur within the current month.

Example:

Period: 16/09 to 15/10

Missed on 10/14

If the field Loses DSR of Last Week is marked with option "A", the absence of the 14/10 will cause the holiday loss of 20/10 and the DSR of 22/09 to occur.

Pay holiday on day off Indicate whether the company considers the holiday occurred on day off (9996) as DSR or not.

Paying a Holiday on a Compensated Day
Indicate whether the company considers the holiday to be cleared (time 9998) as DSR or not.

Consider Faults for Holiday Loss Please inform us if any shortages will cause the loss of the holiday:

• "1 - Do not Consider": faults occurring do not interfere in the loss of the holiday;
• "2 - Faults Before": when there is fault before the holiday the employee will not be entitled to receive the holiday;
• "3 - Faults After": when there is shortage after the holiday the employee will not be entitled to receive the holiday;
• "4 - Faults Before and After": when there are absences in the week, before or after the holiday, the employee will not receive the hours corresponding to the holiday.
  Exemplo:

  Período de competência: 01/06 a 30/09

  Período de apuração : 01/06 a 30/09

  Data	Situações
  01/09	Trabalho
  02/09	Falta
  03/09	Trabalho
  04/09	Trabalho
  05/09	Trabalho
  06/09	DSR
  07/09	Feriado
  08/09	Trabalho
  09/09	Trabalho
  10/09	Falta
  11/09	Trabalho
  12/09	Trabalho
  13/09	DSR

  Neste cenário, se houver integração até o dia 11/09, considerando o campo Gerar Até Término Última Semana com a opção "S - Sim", da tela Geração de Eventos (FRGEREVE), serão gerados no evento de perda de DSR nos dias 06/09, 07/09 e 13/09.

Example 1:

Competence: 06/01/2016 to 06/30/2016

Trial: 05/16/2016 to 06/15/2016

Event: 4 - DSR Payment

Design: S.

 

Calculation of the developer:

05/05/2016 - 9997 - Holiday

05/27/2016 - Work

05/28/2016 - Fouls

05/05/2016 - 9999 - DSR

In this scenario, the DSR will only be discounted on 05/29/2016, since the holiday of 05/26/2016 is not considered by the system due to event 4 to consider only as of 01/06/2016.

Example 2:

Competence: 06/01/2016 to 06/30/2016

Trial: 05/16/2016 to 06/15/2016

Event: 4 - DSR Payment

Design: N.

 

Calculation of the developer:

05/05/2016 - 9997 - Holiday

05/27/2016 - Work

05/28/2016 - Fouls

05/05/2016 - 9999 - DSR

In this scenario, the DSR of 05/29/2016 and the holiday of 05/26/2016 will be deducted because, with the option Designate marked N, event 4 considered the days as of 05/16/2016

Consider Holiday Hours When meeting a holiday, the Point Control and Dining may consider the DSR hours reported on the employee's scale or the hours scheduled for work on the day.

Discounting Followed Dsrs
Determine whether the DSRs followed should be discounted regardless of the type of employee scale.

Discounting only from relay scales Determine whether the DSRs followed should be discounted only on relay scales previously determined through the Scale Classes screen (FR006CLE). Disabled when Discounting Followed Dsrs is set to "N - No".

Example:

Deduct WPRPs in a row

Option N - No

1. Access the Integration Definition screen on the DSR tab.
2. In the field Discounting DSRs in a row select the option N - No so that the discount of the DSRs in a row will not occur.
3. The field Discounting only from relay scales Comes by default N - No and disabled when the field Discounting DSRs in a row you also have the option N - No.

Option S - Yes

1. Access the Integration Definition screen on the DSR tab.
2. In the field Discounting DSRs in a row select the option S - Yes so that the DSRs in a row can be discounted.
3. The field Discounting only from relay scales comes by default as N - No and is valid only when using relay scale.

Discounting DSRs followed by a relay scale

Option N - No

1. Access the Integration Definition screen on the DSR tab.
2. In the field Discounting DSRs in a row select the option N - No so that DSRs will not be discounted in normal and relay scales.
3. The field Discounting only from relay scales Comes by default N - No and disabled when the field Discounting DSRs in a row you also have the option N - No.

Note

The field option Relay Scale, of the Scale Classes screen, independent for the operation of the function of not discounting DSRs in a row.

Option S - Yes

1. Go to the Scale Classes screen.
2. In the field Relay Scale select the option S - Yes. And confirm that in the scale register (FR006ESC) you have this class selected.
3. Access the Integration Definition screen on the DSR tab.
4. In the field Discounting DSRs in a row select the option S - Yes so that the DSRs can be discounted in normal and relay scales.
5. In the field Discounting only from relay scales select the option S - Yes for DSRs to be discounted only on relay scales.

DSR loss

Defines the situations in which the DSR will be lost. If these situations are cleared and exceed the limits established in this guide, the system will generate in the Integration the Day or Night DSR loss events defined in Calculations> Integration> Settings, DSR tab. You can enter up to 100 situations in the grid.

Situation
Code of the situations that cause the loss of DSR.

Code and Description (Miss Cmp)
This is related to the data type and quantity. Indicate the period in which this situation must occur for the DSR is lost.

Code and Description (Threshold Limit)
Indicate if this situation causes loss of the DSR only when it is complete or for some amount of hours, within the period indicated in Description (Miss Cmp).

• "H - Hours": loses if there is more than the value entered in the given quantity;
• "I - Integral": loses if all the period informed in Description (Miss Cmp);
• "O - Occurrence": loses if occurs more than the amount reported.

Lim. Hours
Enter the amount that the employee must have within the period indicated in the absence competence, above which the DSR will be lost.

This information is requested only when the type is "H" or "the". In the case of occurrences, if report "1", the developer should take over a week. When informed "0" the DSR loss is generated normally.

Example:

The employee must lose the DSR if there is more than 02:00 hours a week. In this case please note:

• Fault competence = S
• Type = H
• Quantity = 02:00

 

The developer must lose the DSR if the situation occurs more than 02 times a week, regardless of the hours. In this case please note:

• Fault competence = S
• Type = O
• Quantity = 02

Note

When the boundary type is set to monthly, it works in parallel with the other boundary types.

 

Example:

 

Definitions:

Situation	Cmp. Lack	Tip. Limit	Lim. Hours
15 - Fouls	D	(I)	00:00
103 - Delay	M	H	00:00

 

Situations of the employee in the calculation period:

12/09/2015 - Fouls

10/12/2015 - Delay

 

Days with DSR in the period:

12/13/2015

12/20/2015

 

In this case, the two DSRs will be lost because there was a full fault that caused the DSR loss on 12/13/2015 and a delay in the month that resulted in the loss on 12/20/2015.

Holidays Faults

Defines the situations that can cause missed leave to lose vacation through the integration calculation. You can report up to 100 situations in the grid.

This option may only be used when there is more than one occurrence of a particular situation in the period in question. That is, if the employee has a delay in the period, it is not considered as a fault to accumulate in the calculation of the loss of vacations, but if the employee has five delays in the period, then the system should generate a absence of absence, which will count for loss of vacation.

Another possibility is when you want to generate a fault for the loss of vacation only if the sum of the hours of the situation is greater than the limit set.

Example:

It is desired to generate the missed holiday loss only if the sum of the period's delay hours is greater than 08:00 hours.

In the case of full absences, if a missed day is already considered to accumulate for the calculation of the loss of vacation days, it is recommended to use the field Lose holiday, in the register of the situation.

Situation Away Missing Holidays
Please state the code of the situation with which you will be removed from the holiday absence. The calculation of integration will generate a removal with this situation.

Limit of Hours Enter the hours limit for a foul for vacation. In the generation of the hours for the sheet, the system will generate a day of loss for holidays on the date where the balance reaches this limit.

Occurrence Limit Enter the limit of occurrences (times) for a foul for vacation. In the generation of the hours for the sheet, the system will generate a day of loss for holidays on the date where the balance reaches this limit.

Grid Situations Missing Holidays

Veja também:

• Calculations of Integration