← На главную

С 2025 года вступают в силу изменения в расчете НДФЛ, касающиеся прогрессивной шкалы налогообложения. Особое внимание уделяется доходам сотрудников в районах Крайнего Севера и приравненных к ним местностях. Для северных надбавок (РК и СН) действует льготный порог в 5 млн рублей, тогда как для основной базы — 2.4 млн рублей.

В связи с этим в конфигурации «1С:Зарплата и Управление Персоналом» (ЗУП 3.1) произошли серьезные архитектурные изменения. Многие специалисты столкнулись с вопросом: зачем программа требует заполнения новых регистров и использует их при расчете, если в учетной политике принято решение не выделять РК и СН из среднего заработка? Разберем эту ситуацию подробно, проанализируем технические причины и методические риски.

Архитектурные изменения в регистрах среднего заработка

Прежде всего, давайте разберемся, какие изменения произошли в структуре хранения данных. Исторически в ЗУП 3.1 использовались следующие регистры накопления для расчета среднего:

• ДанныеОНачисленияхДляРасчетаСреднегоЗаработкаОбщий
• ДанныеОНачисленияхДляРасчетаСреднегоЗаработкаФСС

В этих регистрах суммы хранились в разрезе видов заработка (общий, премии и т.д.), но без детальной привязки к конкретным начислениям в том виде, который требуется для гибкого анализа структуры дохода.

Для поддержки требований НК РФ с 2025 года разработчики внедрили новые регистры:

• ДанныеДляРасчетаСреднегоЗаработкаПоНачислениям
• ДанныеДляРасчетаСреднегоЗаработкаПоНачислениямФСС

Эти новые объекты учитывают суммы доходов для расчета среднего в разрезе конкретных начислений. Это позволяет системе в любой момент времени "развернуть" сумму среднего заработка и понять, какая часть в ней приходится на оклад, какая на премию, а какая — на Районный Коэффициент и Северную Надбавку.

Почему используются новые регистры при отключенной настройке?

Рассмотрим ситуацию, с которой сталкиваются многие администраторы баз данных 1С. В учетной политике организации принимается решение: «Не выделять РК и СН из среднего заработка». Логика пользователя такова: если мы не делим базу, то расчет должен идти "по-старому", и новые тяжелые регистры нам не нужны.

Однако на практике, при проведении начисления (например, отпуска) в 2025 году, программа обращается именно к регистру ДанныеДляРасчетаСреднегоЗаработкаПоНачислениям. Если данные там отсутствуют или не заполнены обработчиками обновления, расчет может быть некорректным или пустым.

Причины такого поведения системы:

1. Унификация механизма расчета. Разработчики 1С перевели механизм расчета среднего заработка на новые рельсы глобально. Поддержка двух параллельных веток кода (одна читает старые регистры, другая — новые) была бы нерациональной и чреватой ошибками. Поэтому чтение данных переключено на новые регистры безальтернативно для актуальных релизов.
2. Потенциальная смена настроек. Даже если сегодня вы решили не выделять РК/СН, завтра законодательство или позиция вашей бухгалтерии могут измениться. Система должна хранить данные в максимально детализированном виде, чтобы обеспечить возможность перерасчета или изменения методологии без повторного перепроведения всех документов прошлых лет.
3. Отчетность 6-НДФЛ. Новая структура данных необходима не только для расчета самого налога, но и для корректного заполнения отчетности, где требуется разделение налоговых баз по разным КБК.

Таким образом, заполнение новых регистров (ДанныеДляРасчетаСреднегоЗаработкаПоНачислениям) является обязательным техническим требованием обновления, независимо от того, какую галочку вы поставили в настройках учетной политики по НДФЛ.

Проблема длительного обновления и способы решения

Переход на новые регистры требует обработки огромного массива данных за прошлые периоды (обычно с 2018 года или как минимум за расчетный период). На больших базах (особенно КОРП с тысячами сотрудников) это вызывает серьезные проблемы с производительностью.

Симптомы:

• Фоновое задание обновления работает сутками (24-50 часов).
• Блокировки таблиц при работе пользователей.

Рассмотрим рекомендации по оптимизации этого процесса:

1. Многопоточная обработка
Если типовой однопоточный обработчик не справляется, целесообразно использовать (или написать) внешнюю обработку, которая будет формировать записи в новых регистрах в несколько потоков. Это позволяет сократить время обновления в разы (например, с 50 до 10 часов).

2. Выборочное заполнение (с осторожностью)
Если в вашей базе ведется учет по нескольким организациям, и в некоторых из них точно нет и не будет северных надбавок, можно ограничить глубину пересчета. Однако, учитывая глобальный переход на новые регистры, самым безопасным вариантом остается полное заполнение.

Обратите внимание: прерывать или игнорировать этот обработчик нельзя. Если регистры останутся пустыми, расчет отпускных и командировок в 2025 году перестанет работать корректно.

Методический аспект: риски решения "Не выделять"

В ходе обсуждения часто возникает вопрос о правомерности отказа от выделения РК и СН из среднего заработка. Проанализируем риски.

Согласно п. 6.2 ст. 210 НК РФ (в редакции с 2025 года), льготная ставка 13% до 5 млн руб. применяется к доходам, получаемым за работу в районах Крайнего Севера, в части, относящейся к РК и СН.

Если организация решает не выделять эту часть в среднем заработке (отпускные, командировочные), то вся сумма таких выплат попадает в основную налоговую базу. Для основной базы порог повышения ставки составляет 2.4 млн руб. (против 5 млн для северных).

Пример рискованной ситуации:

Сотрудник имеет годовой доход 4 млн рублей (включая РК и СН).
1. Если РК/СН выделяются в среднем заработке: весь доход облагается по ставке 13%, так как он ниже 5 млн.
2. Если РК/СН не выделяются: часть дохода (отпускные) попадает в базу с лимитом 2.4 млн. В результате сотрудник заплатит 15% с суммы превышения над 2.4 млн, хотя мог бы заплатить 13%.

Это создает риск претензий со стороны работников из-за излишне удержанного налога и потенциальных трудовых споров. Поэтому техническое решение "не выделять" должно быть подкреплено серьезным юридическим обоснованием.

Резюме

1. Переход на регистры ДанныеДляРасчетаСреднегоЗаработкаПоНачислениям в ЗУП 3.1 необратим и обязателен.
2. Настройка "Выделять РК и СН" влияет только на алгоритм распределения сумм по налоговым базам в момент начисления, но не на источник данных для расчета среднего.
3. Обработчики обновления данных необходимо выполнить полностью. На больших объемах рекомендуется планировать технологическое окно или использовать инструменты для многопоточного заполнения.