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

Бухгалтер 1С v8.3 (Обычные формы) 1С:Зарплата и Управление Персоналом Налоговый учет
← На главную

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

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

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

---

Выясняем техническую причину: почему НДФЛ разбивается на строки?

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

Записи в этих регистрах хранятся в строгом разрезе трех ключевых реквизитов:

  1. Физическое лицо (конкретный сотрудник).
  2. Код дохода (например, 2000 для оклада, 2012 для отпускных, 2300 для больничных, 2002 для премий).
  3. Дата фактического получения дохода. Это важнейший реквизит, из-за которого и происходит большинство сбоев.

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

В конце месяца создается документ НачислениеЗарплатыСотрудникамОрганизаций. При его расчете система заново анализирует ВСЕ доходы сотрудника за месяц и производит полный перерасчет налога. Если алгоритм программы обнаруживает нестыковку по датам получения дохода или кодам между межрасчетным документом и финальным расчетом зарплаты, он пытается «выровнять» учет в регистрах:

  1. Программа делает сторнирующую (минусовую) строку на «старую» дату получения дохода, аннулируя первоначальный расчет из межрасчета.
  2. Программа добавляет положительную строку на «новую» (правильную с точки зрения алгоритма) дату получения дохода.

Если бы эти суммы относились к одной и той же дате получения дохода, они бы просто взаимно уничтожили друг друга («схлопнулись»), и вы увидели бы стандартную единую строку налога. Но поскольку даты или коды доходов различаются, программа вынуждена выводить обе строки отдельно. Это и приводит к порче отчета 6-НДФЛ.

---

Почему ручные правки на вкладке «НДФЛ» — это ловушка?

Рассмотрим типичную ошибку пользователя. Бухгалтер видит две строки (например, -650 рублей на 17.01.2018 и 4550 рублей на 31.01.2018) и решает просто удалить строку с минусом, а во второй строке прописать итоговые 3900 рублей. Отчет 6-НДФЛ за текущий квартал после этого действительно может заполниться красиво.

Однако при расчете зарплаты за следующий месяц (февраль) эти минусы возвращаются снова, причем часто с январскими датами. Почему так происходит?

Проанализируем ситуацию: программа рассчитывает налог на основе фактического состояния регистров накопления, а не текстовых строк в ваших прошлых документах. Своей ручной правкой вы скорректировали лишь визуальное отражение налога в конкретном документе, но не закрыли «ошибку» в регистрах. Для алгоритма 1С январское расхождение по датам так и осталось нерешенным. Поэтому в феврале программа снова видит эту нестыковку за прошлый период и опять пытается ее выровнять автоматическим сторнированием. Получается замкнутый круг, выбраться из которого ручными корректировками начислений невозможно.

---

Анализ конкретных ситуаций: Премии и Больничные листы

Ситуация 1. Начисление премии (Сообщения 0–4)

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

Решение проблемы: Для премий необходимо использовать специализированные коды доходов (например, 2002 или 4800). Для этих кодов датой получения дохода является день фактической выплаты на руки, а не последний день месяца. После изменения кода дохода в настройках начисления и перепроведения документов даты сошлись, и надобность в сторнировании отпала.

Ситуация 2. Начисление по больничному листу (Сообщение 6)

Сотруднику начислили больничный. В документе указана планируемая дата выплаты — 14.01.2018. Программа исчислила налог на эту дату. В конце месяца при начислении зарплаты программа сторнирует этот налог с даты 14.01.2018 и переносит его на дату выплаты зарплаты.

Выясним причину: это происходит из-за нарушения последовательности проведения документов или несовпадения плановых и фактических дат. Если на момент расчета финальной зарплаты за январь в системе не был проведен (или был проведен некорректно) документ выплаты больничного (ЗарплатаКВыплатеОрганизаций), программа считает, что доход 14 января фактически выплачен не был. Алгоритм принимает решение перенести дату получения этого дохода на день выплаты основной зарплаты, создавая сторнирующую и начислительную строки.

---

Три золотых правила для полного устранения «минусов» по НДФЛ

Чтобы избежать появления отрицательных строк и гарантировать идеальное заполнение отчетов 6-НДФЛ, следуйте выверенной методике работы в ЗУП 2.5.

Шаг 1. Соблюдайте строгую хронологию и контролируйте даты

При работе с межрасчетными выплатами (отпуска, больничные, материальная помощь, премии) всегда контролируйте три ключевые даты, которые должны строго соответствовать друг другу:

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

Если вы планируете выдать больничный или премию не отдельно в межрасчет, а вместе с будущей зарплатой (например, 10-го числа следующего месяца), то в документе начисления больничного сразу устанавливайте планируемую дату выплаты равной 10-му числу следующего месяца. Тогда программа не будет пытаться сторнировать налог в текущем месяце.

Шаг 2. Настройте учетную политику по НДФЛ

Проанализируем важную настройку программы, которая часто становится первопричиной хаоса в регистрах. Перейдите в параметры учета вашей информационной базы на вкладку «НДФЛ».

Найдите и снимите флажок При начислении НДФЛ принимать исчисленный налог к учету как удержанный.

Если этот флажок включен, программа пытается автоматически признавать налог удержанным непосредственно в момент его расчета (в документах начисления). При малейшем сдвиге дат выплаты или перерасчетах это приводит к мгновенной рассинхронизации регистров исчисленного и удержанного налога, порождая бесконечные минусовые строки. Снятие этого флажка заставит программу регистрировать удержание налога строго в момент проведения платежных документов (выплаты зарплаты), что соответствует требованиям Налогового кодекса РФ.

Шаг 3. Исправьте прошлые ошибки документом «Корректировка учета по НДФЛ»

Что делать, если в прошлых периодах вы уже совершили множество ручных правок, регистры «поплыли», и минусы ежемесячно преследуют вас? Нам нужно принудительно обнулить зависшие некорректные остатки в базах данных программы.

Для этого в ЗУП 2.5 предусмотрен специальный инструмент:

  1. Перейдите в меню «Расчет зарплаты по организациям» — «Налоги и взносы» и создайте документ КорректировкаУчетаПоНДФЛСтраховыхВзносов.
  2. Этот документ делает прямые записи в регистры накопления в обход стандартных документов начисления.
  3. На вкладках, соответствующих регистрам по НДФЛ (например, НДФЛ расчеты с бюджетом), введите корректирующие записи.
  4. Для исправления «зависшего» минуса введите две строки по проблемному сотруднику:
    • Первая строка: вид движения «Расход» (или сторно) на ошибочную дату и ошибочный код дохода, чтобы обнулить неверный остаток.
    • Вторая строка: вид движения «Приход» на верную дату получения дохода и правильный код.
  5. Проведите документ корректировки. После этого регистры очистятся, и при расчете зарплаты за следующий месяц программа больше не будет генерировать сторнирующие строки за прошлые периоды.

Используя эти методы, мы сможем восстановить идеальный порядок в налоговом учете 1С:ЗУП 2.5 и обеспечить быстрое, корректное и полностью автоматическое заполнение отчетности по форме 6-НДФЛ.

← На главную