При работе с кадровой отчетностью в 1С:Зарплата и управление персоналом (ЗУП) пользователи часто сталкиваются с ситуацией, когда мероприятие, которое уже было передано в СФР, снова и снова попадает в новый отчет ЕФС-1. Это происходит после внесения правок в первичные документы (Прием, Перевод, Увольнение) задним числом. Проблема осложняется тем, что даже после удаления лишней строки из отчета вручную, она возвращается при следующем заполнении. Рассмотрим подробно, почему это происходит и как правильно «вылечить» базу данных.
Для понимания сути проблемы разберем техническую сторону вопроса. Каждое кадровое мероприятие в 1С имеет уникальный идентификатор — UUID (или GUID). Когда мы создаем отчет ЕФС-1 и помечаем его как «Принят в фонд», программа фиксирует этот UUID в специальном регистре «переданных» записей. Таким образом 1С понимает: мероприятие с этим кодом уже числится в базе СФР.
Проанализируем типичную ошибку: бухгалтер открывает старый документ «Прием на работу», меняет в нем, например, способ отражения или тариф, и нажимает «Провести». Если в документе не снята галочка «Отразить в трудовой книжке», программа может попытаться перезаписать мероприятие. В зависимости от версии конфигурации и характера изменений, 1С либо создает новое мероприятие с новым UUID, либо оставляет старое, но считает его «измененным».
Если программа видит расхождение между тем, что записано в регистре переданных мероприятий, и тем, что находится в актуальном документе, она автоматически добавляет записи в новый отчет. Это может быть либо дубль, либо пара строк: «минус» (отмена старой записи) и «плюс» (новая корректная запись). Если пользователь удаляет эти строки вручную в документе ЕФС-1, он не решает проблему, а лишь маскирует ее, оставляя «мусор» в регистрах.
Рассмотрим самый действенный, но требующий внимательности способ — работу с регистрами сведений через «Функции для технического специалиста» (ранее «Все функции»). Для этой задачи есть очистка технических регистров через Перенос данных.
Для исправления ситуации нам необходимо проанализировать три основных регистра:
МероприятияТрудовойДеятельности — здесь хранятся все мероприятия, которые программа считает актуальными.МероприятияТрудовойДеятельностиПереданные — здесь фиксируются данные, которые уже ушли в отчеты со статусом «Принят».МероприятияТрудовойДеятельностиПрочие — вспомогательный регистр, где часто зависают «фантомные» записи (см. обработка устранения фантомных записей в ЗУП) при некорректном перепроведении.Пошаговый алгоритм действий:
МероприятияТрудовойДеятельности. Установим отбор по конкретному сотруднику. Посмотрим на колонку ИдентификаторМероприятия.МероприятияТрудовойДеятельностиПереданные. Здесь мы должны увидеть ту запись, которая была реально отправлена в фонд 01.12.2025 (согласно нашему примеру).МероприятияТрудовойДеятельностиПрочие. Как показывает практика, именно здесь чаще всего кроется причина дублей. Если в этом регистре висит запись по нашему сотруднику, которая ссылается на отмененное или измененное мероприятие, ее необходимо удалить вручную — для этого подойдёт обработка ручного редактирования записей регистров сведений.Если вы опасаетесь напрямую редактировать регистры, воспользуемся штатным механизмом исправления — документом РегистрацияТрудовойДеятельности. Он предназначен специально для корректировки ошибок в ЭТК без изменения первичных документов.
Разберем, как это сделать правильно:
UUID, который был ранее передан.Регистрации и заполнения ЕФС-1, эти записи схлопнутся.Выясним причину, по которой нельзя просто удалять строки из отчета. СФР ведет учет по идентификаторам. Если вы отправите новую запись без отмены старой (с тем же или другим UUID), в электронной трудовой книжке сотрудника на сайте Госуслуг появится две записи о приеме на работу. Это создаст огромные проблемы сотруднику при назначении пенсии или расчете больничных в будущем.
Посмотрим на пример кода (логики), по которой 1С собирает данные в отчет:
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| Мероприятия.Сотрудник,
| Мероприятия.ИдентификаторМероприятия КАК ИД,
| Мероприятия.ВидМероприятия
|ИЗ
| РегистрСведений.МероприятияТрудовойДеятельности КАК Мероприятия
|ЛЕВОЕ СОЕДИНЕНИЕ
| РегистрСведений.МероприятияТрудовойДеятельностиПереданные КАК Переданные
|ПО Мероприятия.ИдентификаторМероприятия = Переданные.ИдентификаторМероприятия
|ГДЕ
| Переданные.ИдентификаторМероприятия ЕСТЬ NULL";
Этот упрощенный пример показывает: в отчет попадает всё то, что есть в актуальных мероприятиях, но чего еще нет в «Переданных». Если после перепроведения документа UUID изменился, то старый UUID остается в «Переданных», а новый попадает в отчет как свежее мероприятие. В итоге — дубль.
Чтобы избежать «стандартной ситуации», когда перепроводят задним числом документы с включенным флажком ЭТК, придерживайтесь следующих правил:
Проанализировав ситуацию, можно сделать вывод: в случае возникновения дублей, самым быстрым способом решения является проверка и очистка регистра МероприятияТрудовойДеятельностиПрочие и сверка UUID в основных регистрах мероприятий. Это гарантирует чистоту данных как в вашей базе, так и в системе Социального фонда — для этого подойдёт очистка регистров от устаревших записей и мусора.