How we automated the verification of electronic sick leave certificates

We are constantly opening new stores, the number of employees is increasing. Accordingly, the number of sick leaves is growing, and processing them manually is becoming less and less effective. We calculated that processing 1 sick leave took an HR specialist about 20-30 minutes of work! And we realized that this process needs to be accelerated many times over. Looking ahead – as a result of the automation carried out, employees do not participate at all in the process of processing 90% of sick leaves, and only exceptional cases are considered manually. In total, we process about 1,500 sick leaves monthly.

How we started processing data

The whole scheme consists of several stages:

  • Loading information about notifications from the Social Fund of Russia (SFR) into the internal Fix Price database.

  • Formation of absence.

  • Formation of an electronic sick leave certificate (ESC).

  • Formation of a sick leave certificate (SL).

  • Sending information to the SFR to ensure the calculation and payment of sick leave by the state.

I would like to draw attention to the fact that this process is automated: the system itself checks and records sick leave certificates in the accounting department to send the corresponding amounts of money to employees.

The most interesting thing here is how the reception and verification of data from the SFR is implemented. And here I will note that the serial version of BOSS-HR provides the ability to contact the SFR services to obtain data on sick leaves. However, for us it turned out to be inconvenient that all operations must be initiated

user from the BOSS-HR interface. Therefore, in order to facilitate the work of users and minimize the involvement of employees in checking and paying sick leaves, it was decided to automate the processes that are performed manually. And we managed to achieve full automation of these processes. And I will tell you about the technical implementation now.

How it works

The serial version of BOSS-HR cannot run individual sets of procedures and functions in the background. Therefore, we organized a dedicated server for the background launch of the BOSS-HR session and created a separate technical user with limited rights to work with the background mode. Then we installed the organization's certificates (the employee who has the right to sign on behalf of the organization), as well as the FSS certificates for the electronic sick leave.

On the terminal server, a task was created in the Windows Task Scheduler under the technical user. It is opened from the menu StartComputer management. A task has been created in the Task Scheduler. Loading notifications about changes to the electronic sick leave certificate. The task runs the file cmdlocated in a directory on the desktop. Cmd file boss_start_boss_tech_load_SEDO has the following appearance:

An x-procedure was developed that allows running serial/custom functionality in the background, and based on the results, makes a mailing and closes the module.

I will give the code here
if suserid = 'ХХХХХХХХ\хххххххх'
or suserid = 'ХХХХХХХХ\хххххххх'
or suserid = 'ХХХХХХХХ\хххххххх'
then
{
    if suserid = 'ХХХХХХХХ\хххххххх'
    or suserid = 'ХХХХХХХХ\хххххххх'
    then {Local @@id_firm = ХХХХ -- Автозагрузка только БП
    if suserid = 'ХХХХХХХХ\хххххххх'
    then {Local @@id_firm = хххх -- Автозагрузка БП Казахстан
    --Загрузка уведомлений об изменениях ЭЛН
    execute user_sedo_111_load;
    --Загрузка информации о жизненных событиях
    execute user_sedo_109_load;
    --Запрос сведений о заработной плате
    execute user_sedo_320_load;
    --Извещения ПВСО
    execute user_sedo_10_load;
    --Загрузка запросов недостающих сведений
    execute user_sedo_100_load;
    --Рассылка на почту о результатах
    exec [dbo].[user_send_mail_load_SEDO] @@id_firm;
    Let _usr_task_kill := 'taskkill /f /im rpexec.exe';
    ERROROFF;
    system _usr_task_kill, wait;
    ERRORON;
};

After loading the ELN from the Social Insurance Fund or automatically loading the ELN from the Social Insurance Fund, it is necessary to check the intersection of the received ELN with absences. To do this, take the ELN period and check all employee absences in the BOSS-HR absence log for intersection with the ELN period. The system finds out whether there are vacations, business trips, or other absences during this period. Depending on the type of absence and the type of ELN, further actions are performed with the ELN.

If there are any overlaps with absences or the employee is dismissed, then the following status is set in the electronic sick leave:

  • Any other absences, except for NN (absences for unexplained reasons) – Auto-rejection.

  • Business trips – Auto-rejection.

  • Maternity leave or child care leave until 1.5 or 3 years of age — Refusal. Decree.

  • The employee was fired – Refusal. Dismissed..

If a request for missing information is made for this sick leave certificate, then a flag is set for it Refusal to pay:

The mailing is then sent to recipients in various departments of the company.

Also, before the automatic creation of a sick leave certificate, a number of checks are performed:

  • availability of sick leave for this electronic sick leave certificate (it already exists);

  • the selected ELN indicates the number of the previous ELN, but it is missing;

  • The sick leave certificate is not closed (with status code 010, 020, 040, 050);

  • it was not possible to determine the type of sick leave based on the code from the sick leave certificate;

  • could not find a relative if the sick leave is to care for a sick child/family member.

If the ELN does not pass the checks, then the sick leave is not created, and a mailing is sent with the reason for the refusal to create the sick leave. If the ELN passes all the checks, then the sick leave is created, and the following actions are automatically performed in the database:

  • Creation of a BL in case of employee absences.

  • Re-check for overlapping absences (other absences, business trips, vacations).

  • ELN status changes to status BL created.

  • The BOSS-HR timesheet is issued for the sick leave period. If the timesheet or part of the timesheet included in the sick leave period is closed, the timesheet is opened, issued and closed again.

  • Mailing is carried out according to statuses.

If a vacation was extended due to sick leave, a mailing with information about the vacation extension is also sent.

Now I will show you the implementation of the development clearly:

And now about how automated checks are performed. In total, checks are performed on 22 points:

  1. Checking sick leave with the type “Temporary disability” and “Injury” (including industrial accident) according to the list of entries in the module.

  2. Checking the fields “from date” and “to date” for a match with the field “Release from work” in the personal record.

  3. Checking payment dates for sick leave.

  4. Checking the employee's insurance periods for interruption.

  5. The entries in the employment history correspond to the periods of the employee's insurance experience.

  6. The percentage of payment corresponds to the insurance period at the time of verification.

  7. The calculation conditions must be empty.

  8. Form H-1 act.

  9. Checking the issue date.

  10. The “Primary” (Not a duplicate) checkbox is mandatory; there should not be a “Duplicate” flag.

  11. Reason for incapacity 01 for the sick leave type “Temporary incapacity” and 02 for the sick leave type “Injury”.

  12. LN part 1 is not filled in.

  13. In LN part 2, the marks about violation of the regime are not filled in.

  14. Not filled in by ITU Bureau.

  15. Check the “Start working on” date against a number of conditions.

  16. Checking the doctor's job title for the words “PEDIA / feld / stom” (any letter case). If the doctor's job title contains “feld” or “stom”, then the LN from date to date should contain no more than 10 days in total for all periods (10 days is acceptable). If 11 or more, then an error.

  17. In LN part 3 the doctor’s full name should not be empty.

  18. If in LN part 3 “from the date” of the top line “to the date” of the very last line is more than 15 days (16 or more), then the line “PREV VK” and FULL NAME must be filled in the last of the filled lines.

  19. Checking the fields “Was in hospital until” and “Period from date”. For example, if “Period from date” is 11/21/2023, then the issue date can be either 11/21/2023 or 11/20/2023.

  20. The employee/individual does not have a calculation characteristic.

  21. The employee is not in the “Absent” department.

For example, this is what the ITU Bureau's check of filling in fields looks like:

I will also provide part of the code of the stored SQL procedure for checking the BL in terms of checking the length of service

Percentage of payment based on length of service:

IF @code_ill <> 37 begin
    IF @out_date < @FromD begin
        set @bl_proc = 60
    end
    else begin
        -- Стаж
        declare @stag_yy_ int = 0;
        SELECT
        @stag_yy_ = dbo.pr_fn_calc_staj_tot(ISNULL((SELECT TOP 1 id_tot FROM
vpr_wk_total WHERE sname="ст_Страховой"),0), @auto_card, @FromD,'Y')
        IF @stag_yy_ < 5 begin set @bl_proc = 60 end
        IF @stag_yy_ >= 5 begin set @bl_proc = 80 end
        IF @stag_yy_ >= 8 begin set @bl_proc = 100 end
    end
    if @percent <> @bl_proc
    begin
        set @txt_err = @txt_err + ' ' +'Процент оплаты БЛ не соотвествует стажу.'
        set @bit_err = 1
    end
end
else begin --@code_ill = 37 --HRS-4032
    IF @out_date < @FromD
    begin
        set @txt_err = @txt_err + ' ' +'БЛ по уходу после увольнения не оплачивается.'
        set @bit_err = 1
    end
    else begin
        if @percent <> 100
        begin
            set @txt_err = @txt_err + ' ' +'Процент оплаты БЛ по уходу до 7 лет не равен
100%.'
            set @bit_err = 1
        end
    end
end

Experience checks:

declare @stag_TD int = 0,
        @stag_strah int = 0;
--Количество дней стажа из истории трудовой деятельности
select @stag_TD = sum (dd)
from (
    --история трудовой деятельности
    select
    date_start,date_finish, DATEDIFF(day,date_start,date_finish)+1 as dd
    --pr_wk_his.*
    from pr_wk_his
    left join card on card.auto_card = pr_wk_his.auto_card
    where
    id_pfr_vidwork = 1
    and card.auto_card = @auto_card
    union all
    --приемы и увольнения по основному месту работы
    select
    in_date,
    out_date,
    DATEDIFF(day,in_date, (case when out_date="2099-01-01" then @FromD else out_date
end))+1 --на дату начала БЛ
    from people
    left join card on card.auto_card = people.auto_card
    left join pr_current on pr_current.pid=people.pid and @FromD between date_trans
and date_depart
    left join structs on structs.struct_code = pr_current.code_struct_name
    left join setup on setup.id_firm = people.id_firm
    where
    people.sovm <>2
    and card.auto_card = @auto_card
) a
--Количестово дней страхового стажа из стажей сотрудника
select @stag_strah = sum (dd)
from (
    select
    PR_WK_TOTALS_I.date_b,
    PR_WK_TOTALS_I.date_e,
    DATEDIFF(day,date_b,(case when date_e="2099-01-01" then @FromD else date_e end))+1 as dd --на дату начала БЛ
    from PR_WK_TOTALS_I
    left join card on card.auto_card = PR_WK_TOTALS_I.auto_card
    where card.auto_card = @auto_card
    and vpr_wk_total_id_tot = 8 --страховой
) a
if @stag_TD <> @stag_strah
begin
    set @txt_err = @txt_err + ' ' +' Количество дней стажа из истории трудовой деятельности не соответствует страховому стажу'
    set @bit_err = 1
end

Checking for overlapping insurance periods:

if exists (
        SELECT top 1 1
    FROM PR_WK_TOTALS_I I1
    join pr_wk_totals_i I2 (nolock) on I1.id_tot_i<>I2.id_tot_i and I1.auto_card =
I2.auto_card and I1.vpr_wk_total_id_tot = I2.vpr_wk_total_id_tot
    where
    I1.vpr_wk_total_id_tot = 8
    AND (I1.date_e >= I2.date_b and I1.date_b <= I2.date_e)
    and I1.auto_card = @auto_card
) begin
    set @txt_err = @txt_err + ' ' +'Периоды страхового стажа пересекаются'
    set @bit_err = 1
end

To track the status of automatic processing of BL, an interface has been created for HR and accounting staff:

The checks are divided into 2 groups: preliminary and at the time of acceptance for calculation of the sick leave.

  • If the BL has not passed at least one preliminary check, the message text is presented in the BL check log, and work with the BL is stopped. Responsible users are notified.

  • If the preliminary checks have passed without errors, checks for errors in accepting the BL for calculation are launched.

  • If no errors were found, the BL is transferred to the “for calculation in the current month” state, accruals are generated and the amounts are included in the next salary calculation.

What is important is that the development also allowed us to reduce the time it takes for the state to pay for sick leave.

Usually, when closing a sick leave in a medical institution, the sick leave data is sent to the SFR, and the procedures in the depths of the SFR “understand” that there is not enough data to correctly calculate the amounts of sick leave and SFR. Usually, this takes one day, and a notification of the missing information is sent to the employer. At the same time, this notification has a deadline (3 days), within which it is necessary to prepare and send the missing information to the SFR.

If the employer overlooked, forgot, or delayed sending the missing information, payment by the SFR is delayed for the corresponding period.

The implementation of our process allows us to proactively, immediately after receiving information that the BL is closed, generate information on missing data and send it from the SFR.

This allowed us to reduce the time it takes for the state to pay for sick leave to 24 hours, which has a positive impact on the loyalty of our employees and reduces the number of questions from them.

Conclusion

If previously the accounting and HR staff spent up to 1 hour on one BL (including correspondence by mail between department employees and managers), now they manually check only individual BL cases, the checks of which are algorithmically complex or the BL is a unique case. But less than 10% of all BLs in the company are checked manually.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *