При работе в программе 1С:Зарплата и Управление Персоналом 3.1 пользователи часто сталкиваются с ситуацией, когда при создании документа «Отпуск» или при «Начислении резервов отпусков» система некорректно определяет расчетный период для среднего заработка. Вместо стандартных 12 предшествующих месяцев программа автоматически подставляет только текущий месяц, что приводит к нулевому или заниженному результату расчета, если в текущем месяце еще нет начислений.
Разберем детально, почему это происходит, как диагностировать проблему и какими способами можно восстановить корректную работу системы.
Для начала проанализируем, как 1С определяет, за какой период нужно собирать данные. По закону расчетный период — это 12 календарных месяцев, предшествующих месяцу начала события. Однако программа делает важную проверку: она анализирует стаж сотрудника в данной организации. Если сотрудник принят недавно, период будет сокращен до даты приема.
Проблема заключается в том, что 1С ориентируется не только на дату в документе Прием на работу, но и на актуальные записи в специальном регистре сведений Состояния сотрудников. Если в этом регистре происходит разрыв или данные по какой-то причине «слетают», алгоритм расчета среднего заработка перестает «видеть» стаж сотрудника до даты этого разрыва. Система ошибочно полагает, что сотрудник только что приступил к работе, и устанавливает период расчета равным текущему месяцу.
Если мы столкнулись с подобным поведением системы, первым делом необходимо проверить состояние данных в регистрах. Рассмотрим, как это сделать по шагам:
Состояния сотрудников.В нормальной ситуации записи должны идти непрерывной цепочкой с даты приема. Если мы видим, что записи за прошлые годы отсутствуют или после какой-то даты состояние «Работа» прерывается и возобновляется только в текущем месяце, мы нашли причину сбоя. Программа «отсекает» все периоды до ближайшей найденной записи о состоянии.
Выясним причину, по которой данные могут исчезнуть. Как показывает практика эксплуатации ЗУП 3.1, основными факторами являются:
Прием на работу или документов кадрового изменения. Даже если потом документ был проведен снова, в некоторых релизах это могло привести к некорректному обновлению движений в регистре.Перенос данных. При попытке перепровести старые кадровые приказы в новой базе эти «ручные» записи могут конфликтовать с новыми движениями.Рассмотрим несколько вариантов исправления ситуации, от простых к более сложным.
Самый простой и зачастую самый эффективный метод — это заставить систему заново сформировать записи в регистрах. Для этого:
Прием на работу по сотруднику.Состояния сотрудников. Обычно этого достаточно, чтобы восстановить цепочку состояний.Если проблема массовая и затронула десятки или сотни сотрудников, перепроводить каждый документ вручную неудобно. В этом случае мы можем воспользоваться обработкой «Групповое изменение реквизитов»:
Прием на работу.Если стандартное перепроведение не помогает, можно воспользоваться небольшим фрагментом кода для принудительной записи состояния. Посмотрим на пример кода, который можно запустить во внешней обработке:
МенеджерЗаписи = РегистрыСведений.СостоянияСотрудников.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Сотрудник = СсылкаНаСотрудника;
МенеджерЗаписи.Организация = СсылкаНаОрганизацию;
МенеджерЗаписи.Период = ДатаПриема;
МенеджерЗаписи.Состояние = Перечисления.СостоянияСотрудника.Работа;
МенеджерЗаписи.Записать();
Этот код принудительно создаст запись о начале работы сотрудника, что позволит алгоритму расчета среднего «зацепиться» за нужную дату стажа.
Проанализируем ситуацию с документом Начисление резервов отпусков. В отличие от обычного отпуска, расчет резервов производится массово по всей организации. Если у части сотрудников «слетели» состояния, вы заметите, что по ним суммы резерва будут подозрительно маленькими или нулевыми.
Важный нюанс: программа при расчете резервов очень чувствительна к дате актуальности. Если в настройках расчета резервов стоит «Текущий месяц», а запись в регистре Состояния сотрудников датирована, например, первым числом текущего месяца, программа может проигнорировать весь прошлый год. Всегда проверяйте, чтобы дата записи в регистре была строго равна дате приема на работу.
Чтобы избежать подобных проблем в будущем, рекомендуем придерживаться следующих правил:
Таким образом, автоматическое сокращение периода расчета среднего заработка в ЗУП 3.1 — это не ошибка в алгоритме расчета самого среднего, а следствие отсутствия данных о непрерывном стаже в регистре Состояния сотрудников. Восстановление этих данных через перепроведение документов полностью решает проблему.