← На главную
При обновлении конфигурации «1С:Зарплата и Управление Персоналом» (версия 3.1) с релизов ветки 3.1.3 на 3.1.4 и более новые пользователи часто сталкиваются с масштабными перерасчетами НДФЛ за прошлые периоды. Налог рассчитывается с начала года нарастающим итогом, поэтому изменения алгоритмов в новых релизах могут привеести к появлению ошибочных сторнирующих и приходных записей. Разберем по шагам, как правильно организовать переход и проверить данные.
Причины возникновения ошибок при обновлении на релиз 3.1.4
Проанализируем технические причины, по которым после обновления происходят сбои в расчете налога:
- Уточнение даты получения дохода: В программе изменилась логика учета незарплатных доходов (отпускные, больничные и др.). При проведении платежных ведомостей система автоматически переносит исчисленный НДФЛ с предполагаемой даты выплаты на фактическую дату из ведомости. В результате в регистрах появляются парные плюс/минус движения на разные даты.
- Введение аналитики «Категория дохода»: Появление новой обязательной аналитики требует распределения исторических данных. Если в базе присутствуют переносы из версии 2.5 или ручные корректировки, автоматическое перераспределение за прошлые периоды может исказить суммы удержанного налога.
Шаг 1. Тестирование обновления на локальной копии
Категорически не рекомендуется обновлять рабочую базу без предварительной проверки. Выполним подготовку по следующему алгоритму:
- Создадим полную резервную копию рабочей базы данных.
- Восстановим копию на локальном компьютере или тестовом сервере.
- Выполним обновление тестовой базы. Рекомендуется обновляться сразу до исправленных релизов (ветка 3.1.5 и выше), минуя первые сборки 3.1.4.
Шаг 2. Проверка корректности НДФЛ после обновления
Выясним, испортились ли данные по налогу после установки обновления. Для этого проверим движения в регистрах накопления и аналитических отчетах:
- Сформируем отчет «Подробный анализ учета НДФЛ» за прошлый и текущий налоговые периоды. Сверим полученные результаты с отчетом «Сводная справка 2-НДФЛ».
- Найдем в базе документы выплаты зарплаты в целом по организации (без указания конкретного подразделения). На таких документах новые алгоритмы чаще всего дают сбои.
- Перепроведем тестовую ведомость на выплату и проанализируем новые движения по регистрам
Учет доходов для исчисления НДФЛ и Расчеты налогоплательщиков с бюджетом по НДФЛ. Если в регистрах образуются перекосы по датам или отрицательные остатки, требуется ручная коррекция.
Шаг 3. Защита закрытых периодов и разделение учета
Рассмотрим меры, которые позволят защитить сданную отчетность от случайных перерасчетов:
- Установка даты запрета изменения: Перед обновлением рабочей базы обязательно зафиксируем прошлый период строгой датой запрета редактирования. Это не позволит программе пересчитывать начисления прошлых месяцев при проведении новых ведомостей.
- Запрет на массовое перепроведение: Не выполняем групповое перепроведение документов начислений и выплат за прошлые годы после обновления конфигурации.
- Разделение баз при необходимости: Если исправление прошлых периодов требует слишком больших трудозатрат, сохраним исходную базу версии 3.1.3 в качестве архива для сдачи отчетности, а учет нового года продолжим вести в обновленной базе.
Шаг 4. Способы исправления обнаруженных расхождений
Разберем инструменты для устранения ошибок, если данные все же исказились:
- Документ «Операция учета НДФЛ»: Для корректировки остатков в регистрах без снятия запрета редактирования с прошлых периодов создадим этот документ и зафиксируем правильные суммы на вкладках «Доходы» и «Удержано по всем ставкам».
- Корректировка документов «Перенос данных»: Если база формировалась переносом из ZUP 2.5, проверим заполнение аналитики категорий доходов в документах
Перенос данных за предыдущие периоды.
- Корректировка настроек отчетов: В разделе «Настройка» — «Дополнительные настройки» можно переключить вариант вывода выплат в зарплатных отчетах по дате выплаты (по данным бухучета), чтобы исключить «виртуальные» долги в расчетных листках.