Как исправить ошибку заполнения категории дохода по НДФЛ и предотвратить перерасчет налога в 1С:ЗУП 3.1?

При переходе на новые релизы конфигурации «Зарплата и управление персоналом» (в частности, начиная с версии 3.1.4) разработчиками было введено новое измерение КатегорияДохода (перечисление КатегорииДоходовНДФЛ) в регистрах накопления СведенияОДоходахПоНДФЛ и РасчетыНалогоплательщиковСБюджетомПоНДФЛ. Это потребовалось для раздельного учета исчисления и удержания налога по различным кодам доходов и ставкам согласно требованиям законодательства.

Однако в процедурах обновления на реальных информационных базах может возникать ситуация, когда измерение в регистре доходов заполняется корректно, а в регистре расчетов с бюджетом по НДФЛ остается пустым или принимает значение по умолчанию ОплатаТруда (например, для договоров ГПХ, где должны быть «Прочие доходы от трудовой деятельности»). В результате при очередном начислении зарплаты программа видит нестыковку аналитики между доходом и налогом, сторнирует налог с начала года и начисляет его заново. Рассмотрим подробно причины ошибки и практические способы её устранения.

Анализ причины ошибки в общем модуле

Выясним причину некорректного поведения. Процедура заполнения нового измерения для регистра РасчетыНалогоплательщиковСБюджетомПоНДФЛ расположена в общем модуле УчетФактическиПолученныхДоходов в процедуре ЗаполнитьКатегориюДоходаВИсчисленномНДФЛ.

Проанализируем структуру запроса, формирующего выборку для обновления данных:

"ВЫБРАТЬ
РасчетыНалогоплательщиковСБюджетомПоНДФЛ.Регистратор КАК Регистратор,
    РасчетыНалогоплательщиковСБюджетомПоНДФЛ.НомерСтроки КАК НомерСтроки,
    КатегорииДоходов.КатегорияДохода КАК КатегорияДохода,
    КатегорииДоходов.СуммаДохода КАК СуммаДохода,
    РасчетыНалогоплательщиковСБюджетомПоНДФЛ.*
ИЗ
"

Посмотрим на конструкцию выборки: при соединении таблиц в запросе выбираются все поля через РасчетыНалогоплательщиковСБюджетомПоНДФЛ.*. Так как в самом регистре расчетов поле КатегорияДохода уже существует (и содержит NULL до заполнения), платформа переименовывает поле из соединяемой таблицы КатегорииДоходов в псевдоним КатегорияДохода1.

Далее в типовом коде обработки выборки выполняется следующий блок:

Запись = НаборЗаписей.Добавить();
ЗаполнитьЗначенияСвойств(Запись, ВременныйНабор[0]);
Если Не ЗначениеЗаполнено(Запись.КатегорияДохода) Тогда
    Запись.КатегорияДохода = Перечисления.КатегорииДоходовНДФЛ.ОплатаТруда;
КонецЕсли;

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

Способ 1. Корректировка кода процедуры обновления

Если обновление конфигурации выполняется вручную или через расширение, разберем по шагам исправление алгоритма обработки выборки.

Заменим проверку заполненности категории дохода в процедуре ЗаполнитьКатегориюДоходаВИсчисленномНДФЛ на проверку наличия значения в поле КатегорияДохода1, пришедшем из исходных данных:

Если Не ЗначениеЗаполнено(Запись.КатегорияДохода) Тогда
    Если ЗначениеЗаполнено(Выборка.КатегорияДохода1) Тогда
        Запись.КатегорияДохода = Выборка.КатегорияДохода1;
    Иначе
        Запись.КатегорияДохода = Перечисления.КатегорииДоходовНДФЛ.ОплатаТруда;
    КонецЕсли;
КонецЕсли;

После внесения этого исправления регламентная процедура отложенного обновления корректно перенесет аналитику по доходам (включая выплаты по договорам ГПХ и материальную помощь) в движения исчисленного налога.

Способ 2. Программная корректировка движений без перепроведения документов

Важно: Массовое перепроведение документов расчетного периода за прошлые месяцы крайне нежелательно, так как оно может привести к смещению дат получения доходов, непредвиденным перерасчетам стандартных налоговых вычетов и изменению сданной отчетности по форме 6-НДФЛ.

Для исправления уже поврежденных данных в рабочей базе оптимально использовать программную перезапись наборов записей регистров с установленным флагом ОбменДанными.Загрузка = Истина.

Рассмотрим пример точечной обработки регистра накопления СведенияОДоходахНДФЛ:

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

Для Каждого Доход Из ДоходыНДФЛ Цикл
    Если Не ЗначениеЗаполнено(Доход.КатегорияДохода) Тогда
        // Устанавливаем необходимую категорию дохода, например, ОплатаТруда
        Доход.КатегорияДохода = Перечисления.КатегорииДоходовНДФЛ.ОплатаТруда;
    КонецЕсли;    
КонецЦикла;    

ДоходыНДФЛ.Записать();

По аналогии выполняется выравнивание аналитики для регистра РасчетыНалогоплательщиковСБюджетомПоНДФЛ. Запись наборов данных следует выполнять порциями в разрезе отдельных регистраторов, чтобы избежать длительных блокировок таблиц СУБД.

Способ 3. Ручное выравнивание с помощью документа «Операция учета НДФЛ»

Если расхождения зафиксированы по единичным сотрудникам и вмешательство в закрытые периоды через код нежелательно, разберем порядок корректировки штатными средствами программы:

1. Создаем документ ОперацияУчетаНДФЛ в текущем расчетном периоде.
2. На закладке «Доходы» вводим две строки: сторнирующую со старой (неверной) категорией дохода и положительную с правильной категорией.
3. На закладке «Исчислено по 13% (30%) кроме дивидендов» зеркально переносим суммы исчисленного налога между категориями дохода.
4. Проводим документ и проверяем результаты с помощью отчета Анализ НДФЛ по документам-основаниям с группировкой по измерению Категория дохода.

После выравнивания категорий между доходами и исчисленным налогом механизм автоматического сторнирования в очередных документах НачислениеЗарплаты перестанет формировать избыточные перерасчеты за предыдущие периоды года.