В процессе работы с программой 1С:Зарплата и управление персоналом 3.1 (особенно в версиях ветки 3.1.5) пользователи часто сталкиваются с неприятной ситуацией: при создании документа Начисление зарплаты и взносов за текущий месяц на закладке "Перерасчеты" внезапно появляются строки с доначислением оклада за прошлые периоды. При этом никаких явных исправлений или документов-отклонений (больничных, отпусков) за этот период не вводилось.
Ситуация осложняется тем, что программа может не формировать сторнирующую (отрицательную) строку, а просто добавлять сумму начисления вторым слоем, что приводит к завышению фонда оплаты труда и неверным взаиморасчетам. В этой статье мы подробно разберем, почему возникает этот эффект "фантомных" перерасчетов и как привести учет в порядок.
Прежде всего, проанализируем, как система 1С понимает, что сотруднику нужно что-то пересчитать. В программе реализован механизм очереди перерасчетов. Любое действие пользователя, которое потенциально может повлиять на результат расчета зарплаты в прошлом, фиксируется в специальном регистре сведений Очередь перерасчетов.
Рассмотрим типичные триггеры, которые заставляют программу "думать", что июль (как в примере автора) требует пересчета в сентябре:
Кадровый перевод или Прием на работу и просто нажал "Провести и закрыть", система помечает этот период как требующий анализа.Графики работы, который назначен сотруднику, программа инициирует перерасчет по всем сотрудникам этого графика с даты изменения или даже с начала года.Первое, что нам необходимо сделать — это убедиться, что записи в очереди действительно лишние. В программе 1С:ЗУП 3.1 для этого предусмотрено специальное рабочее место.
Перейдем в раздел Зарплата — Сервис — Перерасчеты. В этом окне мы увидим список всех сотрудников, по которым система зарегистрировала необходимость пересчета. Проанализируем таблицу:
После этого, если мы вернемся в документ Начисление зарплаты и взносов и нажмем "Пересчитать", закладка с перерасчетами должна очиститься.
Посмотрим на ситуацию более глубоко, как это сделал автор темы. Если в виртуальной таблице Фактический период действия наблюдается задвоение записей (пересечение периодов), это означает нарушение логики работы механизма вытеснения.
В норме, если вводится новое начисление за тот же период, старое должно быть "вытеснено" (сторнировано). Если сторно-строка не появляется, а начисление идет "сверху", это может быть признаком повреждения уникальных идентификаторов записей в регистрах расчета Основные начисления.
В таких случаях рекомендуется:
Индивидуальных графиков. В версии 3.1.5 была замечена ошибка: если индивидуальный график вводился после расчета зарплаты, система могла "потерять" связь с первичным начислением.Выясним причину, почему именно в версии 3.1.5 эта проблема стояла наиболее остро. В этот период компания 1С активно перерабатывала движок расчета зарплаты для повышения производительности. В программном коде функции СоздатьДвиженияПоПерерасчетам существовала недоработка, которая при определенных условиях (например, при совпадении определенных аналитик подразделений) некорректно формировала коллекцию сторнируемых записей.
Проанализируем программный аспект. Система использует механизм, который можно упрощенно представить так:
// Пример логики определения необходимости перерасчета (упрощенно)
ЗаписиОчереди = РегистрыСведений.ОчередьПерерасчетов.Выбрать(ФильтрПоСотруднику);
Пока ЗаписиОчереди.Следующий() Цикл
Если Не ПроверитьАктуальностьДанных(ЗаписиОчереди.Период) Тогда
ДобавитьВТаблицуНачисления(ЗаписиОчереди.Сотрудник, ЗаписиОчереди.Период);
// ОШИБКА 3.1.5: Иногда здесь пропускалась генерация сторно-записей
КонецЕсли;
КонецЦикла;
Именно поэтому лучшим стратегическим решением будет обновление конфигурации до версии 3.1.7 или выше, где алгоритмы сопоставления периодов регистрации и периодов действия были существенно исправлены.
Подводя итог нашему разбору, выделим основные правила борьбы с лишними перерасчетами:
Применяя эти шаги, мы сможем добиться чистоты в учете и избежать ошибок при формировании отчетности и выплат сотрудникам.