В практике работы бухгалтера и расчетчика периодически возникают нестандартные ситуации, которые вскрывают внутренние ограничения или программные ошибки в типовых конфигурациях. Одной из таких проблем является расчет компенсации отпуска при увольнении сотрудника, работавшего по срочному трудовому договору (до двух месяцев), если дата его приема пришлась на выходной день (например, воскресенье). В данной статье мы подробно разберем, почему 1С:Зарплата и Управление Персоналом 3.1 отказывается считать средний заработок в таких случаях, и как это исправить программным путем.
Согласно статье 291 ТК РФ, работникам, заключившим трудовой договор на срок до двух месяцев, компенсация отпуска при увольнении выплачивается из расчета двух рабочих дней за месяц работы. Проанализируем стандартную ситуацию: сотрудник принимается на работу 30 апреля (воскресенье) по срочному договору до середины мая. При увольнении программа корректно определяет стаж для отпуска (более половины месяца — 17 дней, что округляется до полного месяца) и назначает 2 рабочих дня компенсации.
Однако при попытке рассчитать сумму компенсации возникает системная ошибка. Для «Основного отпуска» по срочному договору используется способ расчета «по шестидневке» (согласно Постановлению № 922). Если за весь расчетный период (в нашем примере это 30 апреля) у сотрудника не было рабочих дней по графику шестидневки, делитель в формуле превращается в ноль. Программа выдает сообщение о невозможности расчета среднего заработка, хотя начисления за этот день (например, двойная оплата в выходной) в базе присутствуют.
Проанализируем методику, заложенную разработчиками. Для проверки необходимости изменения расчетного периода или оценки наличия отработанного времени программа обращается к регистру сведений СостоянияСотрудников. Логика системы строится на предположении, что если в регистре нет записей об отсутствии (болезни, отпуска, командировки), то сотрудник работал.
Однако методисты не учли ситуацию с выходными днями. Если сотрудник принят в воскресенье, то по графику шестидневной рабочей недели этот день является выходным (0 рабочих часов). Программа видит начисленную зарплату за 30 апреля, но при попытке определить количество отработанных дней по шестидневке получает «0». В результате возникает противоречие: база для расчета есть, а дней для деления — нет. Ситуация усугубляется тем, что в форме ввода данных для расчета среднего заработка часто заблокирована возможность выбора текущего месяца в качестве конца периода, что не позволяет вручную «подтянуть» данные мая.
Для решения проблемы на уровне кода необходимо внести изменения в общую форму, отвечающую за сбор данных для среднего заработка. Рассмотрим шаги по локализации и исправлению ошибки.
Разберем по шагам процесс внесения правок:
ВводДанныхДляРасчетаСреднегоЗаработкаОбщий.ПериодДоНачалаСобытияИсключаетсяИзРасчетаСреднегоЗаработка.
// Исходный код с ошибкой:
ПериодДоНачалаСобытияИсключаетсяИзРасчетаСреднегоЗаработка = ДанныеСостояний.Количество() = 0;
Проблема заключается в жесткой привязке к количеству записей в таблице состояний. Если записей нет, программа считает, что данных для расчета нет вообще, и блокирует корректное определение периода. Рассмотрим исправленный вариант, который рекомендуют опытные разработчики:
// Исправленный код:
// Убираем условие "= 0", чтобы алгоритм не блокировал расчет при отсутствии специфических состояний
ПериодДоНачалаСобытияИсключаетсяИзРасчетаСреднегоЗаработка = ДанныеСостояний.Количество();
Данная правка позволяет системе более гибко определять границы расчетного периода, особенно в случаях, когда работа велась только в выходные дни, которые не фиксируются в РС СостоянияСотрудников как особые периоды.
Как отмечают эксперты, методически более правильно анализировать не состояния сотрудника, а фактически отработанное время. Для этого следует обращаться к регистру накопления ДанныеОВремениДляРасчетаСреднегоОбщий. Рассмотрим, почему это важно.
В этом регистре содержатся данные, которые уже собраны системой для расчета: количество дней по пятидневке, шестидневке и календарных дней. Если мы проанализируем ситуацию с нашим сотрудником, то увидим следующее:
Для исправления ситуации без правки кода (если вы пользователь или бухгалтер) можно прибегнуть к ручной корректировке в документе увольнения:
Интересно заметить, что для «Северных» и «Вредных» отпусков проблема часто не возникает. Выясним причину этого различия. У данных видов отпуска в настройках указан способ расчета «В календарных днях». Для них расчетный период всегда делится на коэффициент 29.3 (среднемесячное число календарных дней).
Посмотрим на пример: за 30 апреля сотрудник получил 3000 рублей.
Для календарных дней формула будет: 3000 / (1 день / 30 дней месяца * 29.3). Делитель не равен нулю, расчет проходит успешно.
Для рабочих дней (основной отпуск по срочному договору) формула: 3000 / (количество рабочих дней по календарю шестидневки). Поскольку в апреле это был единственный день и он выходной, мы получаем 3000 / 0, что и вызывает ошибку в 1С:ЗУП.
Ситуация, когда сотрудник принимается в выходной день по краткосрочному договору, является «краевым случаем» для алгоритмов 1С. Фирма 1С редко меняет базовую методику проверки периодов через регистр состояний, поэтому пользователям приходится либо вносить точечные правки в код, либо использовать ручные корректировки.
Резюмируем наши действия:
ОбщаяФорма.ВводДанныхДляРасчетаСреднегоЗаработкаОбщий, чтобы снять ограничение на проверку количества состояний.Понимание того, как программа взаимодействует с регистрами ДанныеОВремениДляРасчетаСреднегоОбщий и СостоянияСотрудников, позволяет эффективно диагностировать и устранять подобные ошибки расчета, обеспечивая соблюдение законодательства и прав сотрудников на получение компенсации при увольнении.