В релизе 1С:Зарплата и Управление Персоналом 3.1.30.81 (и последующих) многие пользователи столкнулись с проблемой «чудных» расчетов НДФЛ. Проблема проявляется в возникновении необъяснимых разниц между налогом в авансе и окончательном расчете, появлении «фантомных» записей в регистрах доходов с датами из прошлых периодов (например, сторно за май в октябрьском документе) и удвоении налоговой базы. Рассмотрим подробнее причины этого поведения и разберем по шагам алгоритм исправления ситуации.
Корень проблемы кроется в реализации положений Федерального закона от 12.07.2024 № 176-ФЗ. Согласно новым правилам, с 2025 года вводится прогрессивная шкала НДФЛ, однако для выплат по районным коэффициентам (РК) и северным надбавкам (СН) сохраняется особый порядок: они будут облагаться по ставке 13% (или 15% свыше 5 млн руб.) независимо от основной налоговой базы. Чтобы программа могла корректно применять эти правила в будущем, фирма «1С» уже сейчас начала разделять доходы на разные категории.
Проанализируем ситуацию: когда вы обновляете программу в середине месяца, начисления за первую половину (аванс) могут быть зафиксированы по старой категории («Оплата труда»), а итоговое начисление зарплаты — уже по новой («Районные, северные надбавки»). Программа видит это как изменение вида дохода и пытается сделать пересчет («вытеснение») нарастающим итогом с начала года, что и порождает странные сторно-записи.
Выясним причину нестыковок в категориях. В 2024 году код дохода для РК и СН официально остается 2000, но внутренняя категория в 1С должна измениться. Если вы столкнулись с ошибками, выполним следующие действия:
EF_60015510). Установим актуальные патчи через раздел «Обслуживание» — «Обновление программы» — «Установка исправлений».Рассмотрим, почему простое перепроведение документа «Начисление зарплаты и взносов» часто не помогает. Проблема в том, что в регистры уже попали записи по «старой» категории из документа начисления за первую половину месяца. Посмотрим на алгоритм исправления:
Если в регистрах учета доходов для НДФЛ все еще присутствуют записи с датами прошлых периодов (например, майские сторно при расчете октября), это может означать, что не завершены фоновые процессы обновления данных. Проанализируем состояние программы через раздел «Обслуживание» — «Результаты обновления программы». Найдем там «Отложенные обработчики».
Для корректного расчета среднего заработка в будущем (с учетом разделения РК/СН) программа должна заполнить новый регистр ДанныеДляРасчетаСреднегоЗаработкаПоНачислениям. В коде конфигурации это выглядит так:
Процедура ЗарегистрироватьОбработчикиОбновления(Обработчики) Экспорт
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "3.1.31.52";
Обработчик.РежимВыполнения = "Отложенно";
Обработчик.Процедура = "УчетСреднегоЗаработка.ЗаполнитьДанныеДляРасчетаОбщегоСреднегоЗаработкаПоНачислениям";
Обработчик.Комментарий = "Заполнение регистра 'Данные для расчета среднего заработка по начислениям'.";
КонецПроцедуры
Важно: пока этот обработчик не завершит свою работу на всей базе данных, расчеты, связанные с РК и СН, могут вести себя непредсказуемо. Рекомендуется дождаться окончания выполнения всех отложенных заданий.
Разберем, как подготовить формулы расчетов к новым правилам. В программе появился «Помощник перехода на новые начисления оплаты по среднему». Он автоматически изменяет формулы для отпусков и командировок, выделяя доли РК и СН. Посмотрим на пример новой формулы отпуска:
?((СреднийЗаработокИндексируемый * Коэф + СреднийЗаработокНеиндексируемый) * Дни > УчитыватьМРОТ * МРОТ,
((СреднийЗаработокИндексируемый * Коэф + СреднийЗаработокНеиндексируемый) -
(СреднийЗаработокИндексируемыйРК * Коэф + СреднийЗаработокНеиндексируемыйРК) -
(СреднийЗаработокИндексируемыйСН * Коэф + СреднийЗаработокНеиндексируемыйСН)) * Дни,
УчитыватьМРОТ * МРОТ) / Дни * КоличествоДнейОтпуска
Эта сложная конструкция необходима для того, чтобы в 2025 году программа могла «растроить» отпускные на три строки: основная часть (прогрессивная шкала), доля РК (ставка 13%) и доля СН (ставка 13%).
Подводя итог, отметим, что «чудные» расчеты — это не всегда ошибка релиза, а часто следствие незаконченного перехода данных из старой модели учета НДФЛ в новую. Чтобы минимизировать проблемы: