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