При расчете отпускных или больничных в программе «1С:Зарплата и управление персоналом 3.1» пользователи иногда сталкиваются с аномалией: количество отработанных дней за прошлые периоды (например, за предыдущий год) увеличивается ровно в два раза. Это приводит к занижению среднего заработка и, как следствие, к неправильному расчету суммы к выплате. Давайте проанализируем внутренние механизмы программы, выясним причины такого поведения системы и разберем пошаговый алгоритм устранения проблемы.
Для начала разберем, как 1С:ЗУП 3.1 собирает данные о времени для расчета среднего заработка. В отличие от старых версий программ, здесь данные не вычисляются «на лету» непосредственно из документов начисления зарплаты в момент создания документа Отпуск. Вместо этого программа использует вспомогательные регистры, в которые данные записываются при проведении первичных документов.
Основная сложность заключается в том, что система обращается сразу к нескольким источникам данных и суммирует их. Рассмотрим ключевые объекты:
ДанныеОВремениДляРасчетаСреднегоОбщий: Это основной «поставщик» информации. Сюда попадают данные автоматически при проведении документов Начисление зарплаты и взносов. Если вы работаете в базе с самого начала, все данные за 2023 и 2024 годы должны находиться именно здесь.Данные О Времени Для Расчета Общего Среднего Заработка (корректировка): Данный регистр предназначен для хранения ручных правок. Когда расчетчик в документе Отпуск нажимает на значок «карандаша» и правит дни вручную, информация сохраняется именно в этот регистр.Важный нюанс: Программный код системы при расчете среднего заработка выполняет запрос, который объединяет записи из обоих регистров. Если одна и та же информация (например, 22 отработанных дня за май 2023 года) присутствует и в регистре накопления, и в регистре сведений «Корректировка», программа сложит 22 + 22 и получит 44 дня. Это и есть причина задвоения.
Проанализируем ситуацию, когда проблема проявляется только за определенный период (например, за 2023 год), в то время как за 2024 год все считается верно. Чаще всего это происходит после использования сторонних обработок для переноса данных или при некорректном использовании документов Перенос данных.
Многие инструменты миграции данных записывают сведения о времени сразу в два места «для надежности» или по ошибке алгоритма. Поскольку 2024 год формировался уже естественным путем (через начисление зарплаты), в нем записи есть только в основном регистре накопления. А за 2023 год записи остались и в основном регистре, и в корректирующем, который был заполнен при переносе.
Прежде чем приступать к удалению данных, нам необходимо убедиться, что причина именно в этом. Выполним следующие действия:
Данные о времени для расчета среднего (общий). Отфильтруем записи по проблемному сотруднику за 2023 год. Убедимся, что там есть корректные записи.Данные о времени для расчета общего среднего заработка (корректировка). Если вы видите там те же самые месяцы и те же данные о днях — причина подтверждена.Проверим также документ Обновить данные для среднего заработка. Рассмотрим, почему он не помогает в данной ситуации. Эта обработка пересчитывает Регистр накопления, но она никогда не трогает Регистр сведений (корректировка), так как система считает записи в нем «приоритетными ручными изменениями», которые нельзя удалять без участия пользователя.
Рассмотрим несколько способов удаления лишних записей из регистра ДанныеОВремениДляРасчетаСреднегоОбщийКорректировка.
Способ А: Через документ «Перенос данных»
Если данные за 2023 год попали в базу через типовой перенос, скорее всего, в системе есть документы Перенос данных с кодом ЗП_СЗ или аналогичным (через него же зачастую выполняется корректировка регистров зарплаты к выплате). Проанализируем эти документы:
Способ Б: Групповое изменение реквизитов или корректировка движений документа
Если записей много и они не привязаны к конкретному регистратору, воспользуемся стандартной обработкой — также есть готовый инструмент для безопасной очистки регистров ЗУП.
Данные о времени для расчета общего среднего заработка (корректировка).Способ В: Программная очистка (для администраторов)
Если стандартные средства выдают ошибку или записей слишком много, мы можем написать небольшую обработку. Рассмотрим пример кода, который очистит набор записей по конкретному условию:
// Пример программной очистки регистра сведений
Процедура ОчиститьРегистрКорректировкиСреднего()
НаборЗаписей = РегистрыСведений.ДанныеОВремениДляРасчетаОбщегоСреднегоЗаработкаКорректировка.СоздатьНаборЗаписей();
// Устанавливаем фильтр по периоду, если нужно очистить конкретный год
НачалоПериода = '20230101000000';
КонецПериода = '20231231235959';
// Если записи независимые, используем отбор, если подчинены регистратору - очищаем через регистратор
// В данном случае рассмотрим вариант полной очистки за период через замену набора
НаборЗаписей.Отбор.Период.Установить(НачалоПериода, КонецПериода);
// Записываем пустой набор, тем самым удаляя старые данные
НаборЗаписей.Записать(Истина);
Сообщить("Очистка регистра корректировки за 2023 год завершена успешно.");
КонецПроцедуры
После того как регистр корректировки будет очищен, выполним следующие действия для фиксации результата:
Отпуск (здесь также можно использовать дополнительные печатные формы для ЗУП 3.1), в котором наблюдалось задвоение — задачу решит автоматический перерасчет отпускных в 1С:ЗУП.Чтобы в будущем не столкнуться с подобными ошибками, проанализируем правила работы с данными среднего заработка:
Обновить данные для среднего заработка (раздел Зарплата — Сервис) после массовых корректировок прошлых периодов, но помните, что она работает только с регистром накопления.Таким образом, мы выяснили, что корень проблемы кроется в архитектурной особенности 1С:ЗУП 3.1 — суммировании основного и корректирующего регистров. Удаление дублирующих записей из корректирующего регистра сведений является единственным верным способом восстановить корректный расчет отпускных.