При работе с конфигурацией Зарплата и управление персоналом 3.1 (КОРП) программисты и аналитики часто сталкиваются с неочевидным поведением системы в регистре расчетов. Одной из таких особенностей является привязка начислений по больничному листу (БЛ) к графику сотрудника (чаще всего это 40-часовая пятидневная рабочая неделя), несмотря на то, что фактически пособие по нетрудоспособности рассчитывается и выплачивается за календарные дни. В этой статье мы подробно разберем, зачем это сделано, какие проблемы это создает при расчете доплат до среднего заработка и как эти проблемы решить.
Рассмотрим, как устроена работа 1С:Предприятия с записями регистра расчета. Для любого начисления в системе важен период его действия. В ЗУП 3.1 реализован мощный механизм вытеснения. Если сотрудник уходит на больничный, его плановое начисление (например, «Оплата по окладу») должно быть уменьшено на количество дней болезни.
Выясним причину, по которой 1С использует график сотрудника (пятидневку) для записей БЛ. Чтобы «Оплата по окладу», которая рассчитывается по пятидневке, была корректно вытеснена «Больничным листом», периоды этих начислений должны «общаться» на одном языке — то есть использовать один и тот же график или, как минимум, соотноситься по рабочим часам. Если бы для БЛ в регистре расчетов был указан календарь всех дней, механизм автоматического сторнирования и перерасчета основных начислений работал бы некорректно, так как база для определения «прогулянных» рабочих часов была бы размыта календарными выходными.
Проанализируем ситуацию, когда на предприятии принята доплата по больничному листу (например, до фактического оклада или до определенного лимита). Основная сложность возникает, когда доплата вводится не за весь период больничного, а только за его часть, или если показатели доплаты меняются внутри периода БЛ.
Проблема заключается в работе платформенного метода БазаНачисления. Посмотрим на пример:
Если мы попытаемся рассчитать доплату только за один день — за 12.07.2020 (воскресенье), система обратится к базе (сумме БЛ) за этот конкретный день. Поскольку по графику БЛ (пятидневке) воскресенье является выходным днем (0 часов), платформа посчитает, что доля базы за этот день равна 0 рублей. В итоге доплата будет рассчитана неверно, так как система «не видит» начисленных за этот день 500 рублей из-за специфики графика в РР.
И наоборот: если мы берем доплату за 10.07.2020 (пятница), система может подтянуть в базу гораздо большую сумму, так как на этот рабочий день ляжет распределение суммы БЛ пропорционально рабочему времени графика пятидневки.
Разберем несколько способов, как можно обойти данное ограничение платформы и типовой конфигурации.
Вместо того чтобы полагаться на стандартный механизм РасчетнаяБаза, который в данном случае работает некорректно, мы можем использовать предопределенные показатели среднего заработка. Рассмотрим вариант настройки формулы доплаты:
Макс(Оклад / НормаДней * ВремяВДнях - (СреднедневнойЗаработокФСС * ВремяВДнях), 0)
В данном случае мы используем показатель СреднедневнойЗаработокФСС, который берется напрямую из данных расчета больничного, и умножаем его на количество дней периода доплаты. Это позволяет избежать привязки к графику в регистре расчетов и оперировать «чистыми» данными среднего заработка.
Если доплата должна строго зависеть от суммы, зафиксированной в регистре расчетов (например, если были ручные корректировки в документе «Больничный лист»), нам придется обеспечить совпадение периодов. Рассмотрим алгоритм действий:
Как показывает практика, автоматизировать расчет сложных доплат, зависящих от грейдов, стажа или плановых показателей, эффективнее всего через документ Разовое начисление. Выясним преимущества этого метода:
Для реализации программного получения корректной базы за произвольный период можно использовать следующий подход в запросе:
ВЫБРАТЬ
СУММА(Начисления.Результат) КАК СуммаБЛ,
Начисления.Сотрудник
ИЗ
РегистрРасчета.Начисления КАК Начисления
ГДЕ
Начисления.ВидРасчета В (&СписокВидовРасчетаБЛ)
И Начисления.ПериодРегистрации = &Период
И Начисления.Сотрудник = &Сотрудник
И Начисления.ПериодДействияНачало <= &КонецПериодаДоплаты
И Начисления.ПериодДействияКонец >= &НачалоПериодаДоплаты
ГРУППИРОВАТЬ ПО
Начисления.Сотрудник
В данном примере мы не используем виртуальную таблицу БазаНачисления, а обращаемся к реальной таблице регистра, что позволяет нам самостоятельно определить логику распределения суммы по дням (например, равномерно по календарным дням), проигнорировав «пятидневку», указанную в графике записи.
Подводя итог, можно сказать, что указание пятидневного графика для больничных листов в ЗУП 3.1 — это необходимое зло, продиктованное архитектурой механизма вытеснения. Для типовых задач (оплата самого БЛ) это не создает проблем. Однако при внедрении кастомных доплат до среднего заработка или оклада, разработчику необходимо помнить, что стандартная РасчетнаяБаза будет возвращать искаженные данные для выходных дней. Наиболее стабильным решением является использование прямых показателей среднего заработка в формулах или расчет суммы доплаты внешними инструментами (обработками заполнения) с последующей фиксацией результата в документе.