При переходе с программы 1С:Зарплата и управление персоналом 2.5 на версию 3.1 пользователи часто сталкиваются с ситуацией, когда в документе Начисление зарплаты и взносов программа автоматически заполняет период работы сотрудника за весь месяц, игнорируя реальную дату его приема (например, если сотрудник вышел на работу в середине месяца). Разберем по шагам, почему это происходит, как работает механизм переноса данных и какие действия необходимо предпринять для корректного учета.
Проанализируем ситуацию: вы выполнили перенос данных на 01.01.2019. В новой базе сформировался документ Начальная штатная расстановка, в котором указана фактическая дата приема сотрудника — 07.12.2018. Однако при попытке начислить зарплату за декабрь 2018 года в ЗУП 3 программа упорно ставит период с 01.12 по 31.12. Почему так происходит?
Выясним причину: документ Начальная штатная расстановка является техническим «снимком» состояния системы на дату начала эксплуатации (в нашем случае на 01.01.2019). Программа воспринимает его как информацию о том, что на 1 января сотрудник уже числится в штате с определенными плановыми начислениями. Если мы пытаемся сделать расчет за декабрь (месяц, предшествующий дате переноса), ЗУП 3 не видит регистрационного события приема на работу в декабре, так как полноценный документ Прием на работу за этот период в системе отсутствует. Программа просто берет данные о том, что сотрудник «есть», и заполняет весь календарный месяц.
Рассмотрим основной методологический подход, который рекомендует фирма «1С». Если вы выбрали дату переноса 1 января, это означает следующее:
Ведомость на выплату зарплаты за декабрь. Сама сумма задолженности перед сотрудником попадет в ведомость из документа Перенос данных с типом регистра Взаиморасчеты с сотрудниками.Важный нюанс: Если вы все же хотите рассчитывать декабрь в новой программе, перенос данных необходимо было делать на 01.12.2018. В этом случае данные за прошлые периоды (для среднего) перенеслись бы по ноябрь включительно, а декабрь стал бы первым «рабочим» месяцем в новой базе.
Если по каким-то причинам вам критически важно произвести расчет именно в ЗУП 3 и именно за период до даты переноса, проанализируем техническую возможность корректировки. Программа берет дату из поля «Дата приема» в Начальной штатной расстановке. Однако, как мы выяснили, для алгоритмов расчета зарплаты этого недостаточно.
Посмотрим на пример исправления ситуации:
Начальная штатная расстановка, в который попал данный сотрудник.Прием на работу датой 07.12.2018.Прием на работу укажите все плановые начисления и графики.После создания «настоящего» документа приема, Начисление зарплаты за декабрь увидит ограничение периода и рассчитает сумму только за фактически отработанные дни с 7 по 31 число.
Разберем еще один аспект. В некоторых релизах (в частности, упоминалась ветка 3.1.8) наблюдалась программная ошибка заполнения периодов в документах начисления за периоды «до переноса». В современных релизах эта проблема минимизирована, но важно понимать, как данные хранятся в регистрах.
При переносе данных формируется документ Перенос данных (обычно с кодом ПНР — приемы, начисления, расстановка). Данные о дате приема записываются в регистр сведений Основные данные контракта сотрудника. Проанализируем этот регистр:
// Внутренняя логика программы проверяет:
ДатаНачалаУчета = ПараметрыУчета.ДатаНачалаЭксплуатации;
Если ДатаНачисления < ДатаНачалаУчета Тогда
// Программа может игнорировать записи из регистров переноса
// и требовать наличия фактического документа ПриемНаРаботу
КонецЕсли;
Если вы столкнулись с такой проблемой, самым надежным способом будет не «бороться» с периодом в начислении, а строго следовать правилу: расчетный листок за месяц до перехода должен формироваться в старой базе. В новой базе мы начинаем учет «с чистого листа», используя данные Переноса данных только для формирования отчетности и расчета среднего заработка в будущем.
Рассмотрим ситуацию с отчетностью, которая также обсуждалась в теме. Часто бухгалтеры боятся, что если начислить зарплату в ЗУП 2.5, то в ЗУП 3 не соберется отчет 2-НДФЛ за прошедший год. Это верное опасение.
Рекомендация по отчетности: Годовую отчетность по НДФЛ и страховым взносам за год, предшествующий переходу, всегда рекомендуется сдавать из старой базы. Даже если в новой версии 1С:ЗУП 3 появилась новая форма отчета, разработчики обычно выпускают обновление и для ЗУП 2.5 (в рамках поддержки перехода), чтобы пользователи могли корректно закрыть год там, где велся учет помесячно.
Если же вы решите перенести данные на 1 декабря, чтобы «видеть» декабрь в новой базе, приготовьтесь к тому, что вам придется вручную выверять НДФЛ исчисленный, удержанный и перечисленный, так как при переносе эти данные часто требуют ручной донастройки в документах Перенос данных (регистры Расчеты налогоплательщиков с бюджетом по НДФЛ).
Подведем итог. Чтобы исправить ситуацию с неправильным периодом работы:
Начальная штатная расстановка. Дата в колонке «Дата приема» должна строго соответствовать фактическому выходу на работу.Прием на работу.Помните, что ЗУП 3.1 гораздо строже относится к последовательности событий, чем старая версия 2.5, поэтому корректность дат в документах переноса — залог правильного расчета налогов и среднего заработка в будущем.