С начала 2024 года многие пользователи и разработчики систем на базе 1С:Управление производственным предприятием (УПП) столкнулись с неприятной проблемой: при расчете заработной платы и материальной выгоды по займам сотрудников НДФЛ начал исчисляться дважды. Сумма материальной выгоды корректно облагается по ставке 35%, но эта же сумма ошибочно попадает в базу для расчета основного налога по ставке 13% (или 15%). Проанализируем ситуацию и разберем по шагам, как решить эту проблему программно или с помощью обновлений.
Для понимания причин вспомним налоговое законодательство. В период с 2021 по 2023 год в России действовал мораторий на налогообложение материальной выгоды от экономии на процентах по займам (п. 90 ст. 217 НК РФ). С 1 января 2024 года этот мораторий прекратил свое действие, и доходы в виде матвыгоды снова стали облагаться НДФЛ. Программные механизмы 1С:УПП, которые долгое время «отдыхали» от этого функционала, оказались не полностью готовы к изменениям в алгоритмах учета НДФЛ, принятых за эти три года (в частности, к учету НДФЛ по прогрессивной шкале и новым правилам определения даты дохода).
Выясним причину задвоения: система видит доход с кодом 4500 (или аналогичным), рассчитывает с него 35% налога в модуле расчета займов, а затем, при расчете общего НДФЛ в документе Начисление зарплаты, не исключает эту сумму из совокупной налоговой базы, облагая ее еще раз по ставке 13%.
Самый правильный и рекомендуемый способ — это обновление конфигурации до актуального релиза. Разработчики из фирмы «1С» признали ошибку и выпустили исправление. Проанализируем историю релизов:
Если ваша организация имеет возможность обновиться, это решит проблему автоматически. В этом релизе были внесены изменения в механизмы формирования налоговой базы, которые корректно разделяют доходы, облагаемые по разным ставкам, предотвращая их пересечение.
Если по каким-то причинам вы не можете оперативно обновить конфигурацию (например, она сильно кастомизирована), проблему можно решить внесением изменений в программный код. Рассмотрим, где именно скрывается ошибка. Нам необходимо скорректировать запрос, который собирает данные для расчета НДФЛ.
Разберем конкретный пример правки. Нам потребуется общий модуль ПроведениеРасчетов. Найдем в нем функцию, отвечающую за формирование временных таблиц для расчета налога (ориентировочно в районе 5800-й строки, в зависимости от вашего релиза).
Необходимо добавить условие, которое будет принудительно ограничивать выборку данных по ставке. В строке формирования условий запроса добавим проверку на ставку 13% для определенных оборотов:
// Фрагмент кода в общем модуле ПроведениеРасчетов
// Добавляем условие фильтрации по ставке в запрос
"| И Обороты.КодДохода.СтавкаНалогообложенияРезидента = ЗНАЧЕНИЕ(Перечисление.НДФЛСтавкиНалогообложенияРезидента.Ставка13)"
Эта правка позволяет системе четко отделить доходы, которые должны облагаться по ставке 13%, от доходов по материальной выгоде (35%). После внесения изменений необходимо перепровести документы Начисление зарплаты сотрудникам за январь.
Рассмотрим еще один технический вариант, который использовали некоторые специалисты. Он заключается в корректировке функции УсловиеОблагаемостиУНалоговогоАгента_ в том же общем модуле ПроведениеРасчетов. Суть метода заключается в искусственном смещении проверки даты действия моратория, чтобы алгоритм корректно определял 2024 год как период, когда налог должен исчисляться в обычном (но не двойном) режиме. Однако этот метод считается менее универсальным, чем правка запроса в Решении 2.
Если у вас небольшое количество сотрудников с займами и нужно срочно сдать отчетность или выплатить зарплату, можно прибегнуть к ручной корректировке документов Начисление зарплаты сотрудникам. Посмотрим, как это сделать правильно:
НДФЛ расчеты с бюджетом. При ручном удалении строк в документе записи в регистрах должны обновиться. Если вы правите уже проведенный документ, обязательно убедитесь, что «лишние» движения по ставке 13% исчезли из регистров, иначе ошибка перекочует в отчет 6-НДФЛ.Проанализируем последствия ручной правки: в феврале система может попытаться «доначислить» удаленный в январе налог, так как расчет НДФЛ ведется нарастающим итогом. Поэтому ручные правки в УПП — это всегда риск, требующий ежемесячного контроля до момента установки исправленного релиза.
Разберем ситуацию с отчетностью. Задвоение налога напрямую влияет на заполнение Раздела 1 и Раздела 2 формы 6-НДФЛ. Если налог завышен в регистрах, он попадет в строки исчисленного налога некорректно. Кроме того, обратите внимание на дату получения дохода. С 2024 года матвыгода признается доходом строго на последнее число каждого месяца. В 1С:УПП важно, чтобы документ Начисление зарплаты был датирован последним числом месяца, чтобы записи в регистре НДФЛ расчеты с бюджетом сформировались верной датой. Если вы видите расхождения в сроках перечисления (например, налог попадает не в тот период в Разделе 1), проверьте крайний срок уплаты в регистрах — иногда ручная корректировка даты выплаты в документе помогает «подтянуть» данные в нужную ячейку отчета.
Резюмируем: наиболее эффективным и безопасным методом является обновление до релиза 1.3.225.1. Если обновление невозможно, используйте программную вставку в запрос модуля ПроведениеРасчетов, чтобы явно разделить налоговые базы по ставкам 13% и 35%.