Переход с устаревшей конфигурации «1С:Зарплата и управление персоналом 2.5» на современную редакцию 3.1 часто сопровождается трудностями, особенно когда речь заходит о подготовке регламентированной отчетности по форме 6-НДФЛ. В ЗУП 2.5 многие операции можно было скорректировать вручную в самом отчете или закрыть глаза на мелкие нестыковки в датах. В ЗУП 3.1 учет НДФЛ стал жестким, системным и полностью зависимым от хронологии проведения документов.
Проанализируем типичную ситуацию: программа при заполнении 6-НДФЛ (особенно раздела 2) начинает вести себя непредсказуемо, «подтягивая» в ведомости за текущий месяц доходы прошлых периодов (например, выплаченные ранее отпускные или больничные листы) и создавая в регистрах пугающие записи со знаками плюс и минус. Выясним, почему это происходит и как победить эту проблему раз и навсегда.
Когда мы открываем движения документа Ведомость в кассу или Ведомость в банк и видим там странные парные записи со знаком плюс и минус на одну и ту же сумму дохода с пометкой «Устаревшая дата выплаты», первая реакция бухгалтера — запустить тестирование и исправление базы данных или начать массово перепроводить документы. Однако это не помогает. Разберемся в механизме работы программы.
В ЗУП 3.1 учет доходов для целей исчисления НДФЛ ведется в разрезе дат их фактического получения. Для таких начислений, как отпуска, больничные листы, материальная помощь и другие межрасчетные выплаты, датой получения дохода считается день его фактической выплаты. Когда мы проводим документ Отпуск, программа еще не знает точную дату, когда сотрудник физически получит деньги. Она ориентируется на поле Дата выплаты (планируемая дата), указанное на вкладке «Основное» или внизу документа. Программа делает предварительную запись в регистр накопления Учет доходов для исчисления НДФЛ с этой планируемой датой.
Когда же дело доходит до выплаты, мы создаем документ Ведомость. И если дата ведомости (или фактическая дата выплаты в ней) отличается от той, что была запланирована в документе Отпуск, программа вынуждена скорректировать учет. Она делает техническую запись в регистрах Учет доходов для исчисления НДФЛ и Расчеты налогоплательщиков с бюджетом по НДФЛ:
Схематично этот алгоритм корректировки в регистрах можно представить следующим кодом, который отражает внутреннюю логику работы движений программы:
Процедура КорректировкаДатыВыплатыДохода(ДокументСсылка, ФактическаяДатаВыплаты)
ТаблицаРегистра = РегистрыНакопления.УчетДоходовДляИсчисленияНДФЛ.СоздатьНаборЗаписей();
// Получаем плановые данные из документа-начисления
ПлановыеДанные = ПолучитьПлановыеДанные(ДокументСсылка);
Если ПлановыеДанные.ПлановаяДатаВыплаты <> ФактическаяДатаВыплаты Тогда
// Сторнируем доход на плановую дату
НоваяСтрокаСторно = ТаблицаРегистра.Добавить();
НоваяСтрокаСторно.ВидДвижения = ВидДвиженияНакопления.Расход;
НоваяСтрокаСторно.Период = ПлановыеДанные.ПлановаяДатаВыплаты;
НоваяСтрокаСторно.СуммаДохода = ПлановыеДанные.Сумма;
// Начисляем доход на фактическую дату
НоваяСтрокаНовая = ТаблицаРегистра.Добавить();
НоваяСтрокаНовая.ВидДвижения = ВидДвиженияНакопления.Приход;
НоваяСтрокаНовая.Период = ФактическаяДатаВыплаты;
НоваяСтрокаНовая.СуммаДохода = ПлановыеДанные.Сумма;
НоваяСтрокаНовая.УточнениеДаты = "Устаревшая дата выплаты";
КонецЕсли;
ТаблицаРегистра.Записать();
КонецПроцедуры
Эти движения абсолютно нормальны и необходимы программе для того, чтобы налог попал в 6-НДФЛ именно в тот период, в который была совершена фактическая выплата. Однако, если между документами возникает серьезный временной разрыв или документы проводятся в неверной последовательности, этот механизм дает сбой, приводя к хаосу во втором разделе формы 6-НДФЛ.
Одной из самых частых ошибок пользователей является ручная правка сумм в ведомостях. Посмотрим на структуру документа Ведомость. На первый взгляд табличная часть проста: сотрудник, сумма к выплате, НДФЛ к удержанию. Но за этой видимой простотой скрывается сложная многомерная структура.
В графах К выплате и НДФЛ к перечислению каждая ячейка на самом деле является «двойной». Если мы дважды кликнем по сумме в строке сотрудника, откроется скрытое диалоговое окно расшифровки. В этой расшифровке сумма детально распределена по следующим аналитическим разрезам:
Документ-основание (например, конкретный документ Отпуск или Начисление зарплаты и взносов).Период регистрации.Статья финансирования и Статья расходов.Категория дохода для целей НДФЛ.Когда бухгалтер правит сумму выплаты или налога прямо в табличной части ведомости (в видимом поле), программа пытается автоматически распределить измененную сумму по внутренним строкам расшифровки. Очень часто это распределение происходит некорректно: программа может «привязать» удержанный НДФЛ не к тому начислению, уменьшить сумму по одному документу-основанию и перебросить остаток на другой. В результате в регистрах учета НДФЛ (таких как Расчеты налогоплательщиков с бюджетом по НДФЛ) ломается связь между исчисленным и удержанным налогом. При заполнении 6-НДФЛ это приводит к тому, что налог зависает как неудержанный, удваивается или распределяется на неверные даты выплаты.
Важное правило работы с ведомостями: Никогда не редактируйте суммы к выплате и НДФЛ поверх табличной части! Если требуется скорректировать сумму, обязательно заходите внутрь строки (в расшифровку) и вносите изменения там. Если данные изменились в первичном документе-начислении, не перебивайте их руками в ведомости, а используйте кнопку Обновить налог или полностью перезаполняйте ведомость через стандартные механизмы заполнения.
Рассмотрим детальный пошаговый алгоритм, как исправить ситуацию, когда ведомости начинают путать даты и «тянуть» прошлые отпускные, нарушая заполнение 6-НДФЛ:
Ведомость, которой выплачивались отпускные, а также последующие ведомости на выплату аванса и зарплаты по этому сотруднику за текущий месяц.Отпуск (или Больничный лист). Обращаем внимание на реквизит Дата выплаты. Она должна строго совпадать с той датой, которой фактически будет проведена ведомость на выплату. Если они отличаются — меняем дату выплаты в документе Отпуск на фактическую.Отпуск необходимо пересчитать (если это требуется) и провести заново. Это обновит планируемые записи в регистрах НДФЛ.Ведомость. Меняем ее дату на ту фактическую дату, которую мы указали в документе Отпуск. Нажимаем кнопку Заполнить или заходим в расшифровку строки сотрудника и нажимаем Обновить налог. Убеждаемся, что в скрытых ячейках расшифровки сумма выплаты и НДФЛ привязались именно к нашему скорректированному документу Отпуск. Проводим ведомость.На крупных предприятиях с численностью сотрудников в сотни и тысячи человек ручное изменение дат в документах-начислениях может стать серьезной проблемой. Изменение планируемой даты выплаты в проведенном документе Отпуск может спровоцировать автоматический перерасчет НДФЛ по всей организации, что приведет к блокировке работы базы и появлению сотен записей в регистре перерасчетов.
Для обхода этой проблемы используем встроенную обработку Групповое изменение реквизитов. Рассмотрим, как безопасно скорректировать планируемые даты выплат:
Групповое изменение реквизитов (меню «Администрирование» — «Обслуживание» — «Корректировка данных»).Отпуск.Дата выплаты (или Планируемая дата выплаты).В попытках избавиться от назойливых напоминаний программы о необходимости пересчитать прошлые периоды, некоторые пользователи прибегают к радикальному методу — полной очистке регистра сведений Перерасчеты (раздел «Зарплата» — «Сервис» — «Перерасчеты»). Делать этого категорически нельзя!
Проанализируем, почему этот регистр так важен. Механизм перерасчетов в ЗУП 3.1 — это интеллектуальная система слежения. Когда мы меняем кадровые данные, исправляем документы задним числом или правим даты выплат, программа фиксирует эти изменения в регистре Перерасчеты. Она понимает, что данные прошлого периода изменились, и при расчете очередной зарплаты или среднего заработка в будущем программа обратится к этому регистру и произведет необходимые доначисления или сторнирования.
Если мы бездумно очистим этот регистр, то программа потеряет историю изменений. При последующем расчете отпусков, командировок или больничных листов система не увидит корректировок прошлых периодов. Это неизбежно приведет к систематическому занижению или завышению сумм среднего заработка у сотрудников. Нарушится баланс взаиморасчетов, который потом придется восстанавливать вручную.
Вместо удаления записей из перерасчетов, их необходимо правильно отрабатывать. Если перерасчет действительно необходим, нужно создать документ Доначисление, перерасчет в текущем периоде. Если же запись в регистре перерасчетов появилась из-за ошибочных действий (например, вы случайно зашли в закрытый период и перепровели документ без изменений), то такую запись можно точечно удалить из списка перерасчетов, но делать это нужно осознанно и только после детального анализа причин ее появления.
Подведем итоги. Автоматическое заполнение 6-НДФЛ в 1С:ЗУП 3.1 — это не миф, а реальность. Главный секрет успеха кроется в соблюдении строгой хронологии документов, абсолютном совпадении плановых дат выплат в начислениях с фактическими датами в ведомостях и полном отказе от ручных правок поверх табличных частей документов выплаты. Используя описанные нами методики, вы сможете навести порядок в учете НДФЛ и формировать отчетность без ручного вмешательства.