В процессе ведения кадрового учета в программе 1С:Зарплата и управление персоналом 3.1 нередко возникают ситуации, когда кадровое мероприятие (прием, перевод или увольнение) было зарегистрировано ошибочно. Если сведения уже поданы в Социальный фонд России (СФР, ранее ПФР), механизм исправления понятен: формируется отменяющая форма. Однако, если ошибка обнаружена до момента отправки отчета, а период, в котором создан первичный документ, уже закрыт для редактирования, перед пользователем встает задача: как убрать это мероприятие из очереди на отправку, не открывая период и не удаляя первичные документы.
В данной статье мы разберем механизмы работы программы с мероприятиями трудовой деятельности, выясним, почему записи могут «тяжело» уходить из отчетов, и рассмотрим пошагово способы решения этой проблемы.
Для начала проанализируем, как программа понимает, что нужно включить запись в отчет СЗВ-ТД (ныне подраздел 1.1 формы ЕФС-1). Когда в кадровом документе, например, Прием на работу, установлен флаг «Отразить в трудовой книжке», при проведении создается запись в регистре сведений Мероприятия трудовой деятельности.
Каждая такая запись имеет уникальный идентификатор — UUID (GUID). Именно по этому идентификатору система в дальнейшем будет связывать прямые записи с отменяющими. Если мы просто создадим новый документ отмены, программа должна найти исходный UUID, чтобы «аннулировать» его. Рассмотрим подробнее, как это происходит в разных сценариях.
Проанализируем штатный функционал, который предназначен именно для корректировки сведений без изменения первичных кадровых документов. Рассмотрим последовательность действий:
В актуальных версиях программы (начиная с 3.1.23 и выше) реализован интеллектуальный алгоритм заполнения. Если в регистре присутствуют две записи по одному и тому же мероприятию (прямая и отменяющая) и ни одна из них ранее не фиксировалась в принятом отчете, то при автоматическом заполнении формы ЕФС-1 программа просто проигнорирует обе строки. Произойдет так называемое «схлопывание».
Важный нюанс: Если после проведения «Регистрации трудовой деятельности» мероприятие все равно попадает в отчет, проверим соответствие идентификаторов. Это можно сделать через консоль запросов или просмотрев движения документа. Если UUID отменяющей записи не совпадает с UUID исходной (например, если запись была создана вручную кнопкой «Добавить», а не «Отменить»), автоматического скрытия не произойдет.
Бывают ситуации, когда из-за технических сбоев или особенностей кастомизации базы «схлопывание» не происходит, и в отчет тянутся сразу две строки: основная и отменяющая. В этом случае применим проверенный метод «скрытия» данных через фиктивную отправку.
Разберем этот метод по шагам:
Выясним, что произошло в системе: программа сделала записи в регистры о том, что данные мероприятия успешно переданы. Теперь при формировании реального отчета за текущий период эти ошибочные записи больше не будут предлагаться к заполнению, так как они помечены как «сданные».
Преимущество метода: Мы не правим документы закрытого периода, не меняем UUID и сохраняем историю действий в системе. Если в будущем нам действительно понадобится отменить эти данные (уже официально), мы сможем это сделать стандартным образом, так как база будет «думать», что данные были поданы ранее.
Рассмотрим ситуацию, когда период еще открыт или вы готовы его открыть для кратковременной правки. Самый простой способ исключить мероприятие из очереди на отправку — это снять флаг «Отразить в трудовой книжке» непосредственно в кадровом документе (Прием, Перевод, Увольнение).
Посмотрим на техническую сторону этого действия:
При снятии флага и проведении документа запись из регистра МероприятияТрудовойДеятельности удаляется полностью. Мероприятие исчезает из всех алгоритмов формирования отчетности, как будто его и не было.
Однако помните: если по этому мероприятию уже был создан (но не отправлен) документ ЕФС-1/СЗВ-ТД, его нужно предварительно перезаполнить или удалить, иначе ссылка на удаленное мероприятие может вызвать ошибку при открытии отчета.
Если записи продолжают «преследовать» ваши отчеты, проанализируем состояние регистров вручную. Для этого воспользуемся инструментом «Универсальный отчет» (Администрирование — Обслуживание — Отчеты и обработки):
Сотрудник, Мероприятие, Дата мероприятия, Дата регистрации, Идентификатор, Сведения приняты в ПФР (флаг).Проанализируем результат. Если вы видите запись, у которой флаг Сведения приняты в ПФР равен Ложь, и при этом у нее нет парной записи с таким же Идентификатор и признаком Отмена, то эта запись всегда будет попадать в новый отчет. Именно здесь вы сможете увидеть «зависшие» дубли, которые часто возникают при многократном переименовании организации или при технических ошибках переноса данных.
Посмотрим на еще один важный аспект. Если в периоде между созданием ошибочного мероприятия и его текущей отменой произошло переименование организации, автоматическая отмена может работать некорректно. Система может не сопоставить записи из-за разных данных о работодателе.
В этом случае в документе Регистрация трудовой деятельности необходимо вручную проверить, чтобы данные в отменяющей строке соответствовали тем данным, которые были в первичной записи (наименование организации, регистрационный номер).
Подведем итоги. Для отмены не поданных сведений в 1С:ЗУП 3.1 мы рекомендуем следующий алгоритм:
Таким образом, вы сможете поддерживать чистоту кадровой отчетности без необходимости корректировки данных в закрытых периодах, что особенно критично для крупных организаций с численностью сотрудников более 1000 человек, где любая правка прошлого периода может повлечь за собой перерасчеты налогов и взносов.