Как исправить ошибки при сдаче ЕФС-1 подраздела 1.1 по договору ГПХ в 1С:ЗУП, если СФР сообщает о неучтенных или ранее учтенных мероприятиях?

← На главную

При отправке сведений о трудовой деятельности по договорам гражданско-правового характера (подраздел 1.1 формы ЕФС-1, бывшая форма СЗВ-ТД) пользователи нередко сталкиваются с цепочкой отказов со стороны Социального фонда России (СФР). Типичный сценарий: первый отчет отклонен из-за отсутствия обязательного реквизита, отправка отмены и новых строк вызывает ошибку о ненайденных исходных данных, а следующая попытка сообщает, что мероприятие с таким GUID уже учтено. Разберем по шагам, почему возникает эта коллизия, как работает валидация на шлюзе СФР и как правильно зафиксировать корректное состояние учета в программе 1С:Зарплата и управление персоналом.

Выясним причину цепочки ошибок и логику проверок СФР

Проанализируем структуру обмена данными и типичные ответы фонда на каждом этапе отправки:

Ошибка отсутствия кода договора: для кадровых мероприятий с кодами 9 («НАЧАЛО ДОГОВОРА ГПХ») и 10 («КОНЕЦ ДОГОВОРА ГПХ») альбом форматов СФР требует обязательного наличия не только тега КодВФпоОКЗ, но и текстового тега КодВФ (значения: ДГПХ, ДАВТ, ДОИП, ИЗЛД, ЛДПИ, ДГПХФЛНС, ДАВТФЛНС). Если тег отсутствует, фонд возвращает ошибку, и запись на индивидуальный лицевой счет (ИЛС) не вносится.
Ошибка «Не найдены исходные сведения для отменяемого мероприятия»: если в ответ на первый отказ в программе сформировать корректировку, 1С регистрирует блок МероприятиеОтменяемое со старым UUID и блок Мероприятие с новым UUID. Поскольку в базе СФР исходный UUID не был записан из-за первой ошибки, отменить его невозможно.
Построчный прием и статус «Документ принят частично»: форматно-логический контроль СФР проверяет каждое мероприятие независимо. При получении пакета с отменой несуществующего события и новым исходным событием фонд отклоняет отмену, но успешно принимает и записывает новое исходное мероприятие. Протокол получает статус частичного приема.
Ошибка «Ранее учтено мероприятие с таким же GUID»: если пользователь, посчитав частичный прием за полный отказ, повторно отправляет те же самые новые мероприятия с теми же UUID, система фонда блокирует их регистрацию проверкой уникальности идентификаторов.

Проанализируем состояние идентификаторов в файлах выгрузки

Посмотрим на реальный пример фрагментов XML, иллюстрирующий поведение системы. В первой попытке были выгружены мероприятия без классификатора договора:


<Мероприятие>
    <ЕФС8:UUID>9309df2f-7924-408f-9d1d-90f4fea29056</ЕФС8:UUID>
    <ЕФС8:Дата>2023-08-01</ЕФС8:Дата>
    <ЕФС8:Вид>9</ЕФС8:Вид>
    <ЕФС8:КодВФпоОКЗ>4415.2</ЕФС8:КодВФпоОКЗ>
</Мероприятие>

Фонд полностью отклонил этот пакет. Во второй отправке были включены отменяющие блоки и новые исходные блоки с правильным тегом КодВФ:


<МероприятиеОтменяемое>
    <ЕФС8:UUID>9309df2f-7924-408f-9d1d-90f4fea29056</ЕФС8:UUID>
    <ЕФС8:Вид>9</ЕФС8:Вид>
</МероприятиеОтменяемое>
<Мероприятие>
    <ЕФС8:UUID>1601074f-1b37-4ce4-a20d-8cbffdf1b293</ЕФС8:UUID>
    <ЕФС8:Дата>2023-08-01</ЕФС8:Дата>
    <ЕФС8:Вид>9</ЕФС8:Вид>
    <ЕФС8:КодВФ>ДГПХ</ЕФС8:КодВФ>
    <ЕФС8:КодВФпоОКЗ>4415.2</ЕФС8:КодВФпоОКЗ>
</Мероприятие>

В этом пакете блок МероприятиеОтменяемое вызвал протокольное замечание, но блок Мероприятие с идентификатором 1601074f-1b37-4ce4-a20d-8cbffdf1b293 был успешно помещен в кондуит СФР. Третья отправка с этим же UUID закономерно вернула ошибку дублирования идентификатора.

Как проверить, что именно зафиксировано в СФР

Прежде чем вносить изменения в базу данных, необходимо точно убедиться, какие данные приняты фондом:

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

Порядок синхронизации данных в 1С:ЗУП

Когда выяснилось, что правильные мероприятия приняты фондом из частично подтвержденного пакета, основная задача — исключить рассинхронизацию информационной базы и учетной системы фонда. Рассмотрим шаги для безопасного приведения данных в порядок.

Фиксация статуса сдачи в исходном документе: откроем второй документ «Сведения о трудовой деятельности, СЗВ-ТД» (или подраздел 1.1 ЕФС-1), в котором содержались корректные идентификаторы. Если отчет не перешел в статус «Сдан» автоматически, переведем состояние вручную. Для этого в документе устанавливаем флаг Документ принят в СФР (ранее ПФР). При проведении документа в таком статусе программа формирует записи в регистре сведений Мероприятия трудовой деятельности переданные, привязывая принятые UUID к кадровому событию. Это предотвратит повторное попадание мероприятий в новые отчеты.
Отказ от ручной «чистки» регистров через служебные функции: прямое удаление записей из регистров сведений Мероприятия трудовой деятельности, Мероприятия трудовой деятельности переданные и Мероприятия трудовой деятельности прочие через меню «Функции для технического специалиста» крайне не рекомендуется. Нарушение ссылочной целостности ключей записей приведет к фатальным ошибкам при последующих попытках изменить или отменить кадровые события этого сотрудника.
Использование внешних инструментов диагностики от 1С: для анализа состояния кадровых цепочек и UUID рекомендуется использовать специализированные отчеты и обработки с диска ИТС, такие как ПроверкаМероприятийТрудовойДеятельности.erf и Исправление идентификаторов трудовой деятельности. Они позволяют наглядно сопоставить идентификаторы кадровых документов с переданными в фонд пакетами без риска повреждения таблиц базы данных.
Правила будущих корректировок: если по принятому договору ГПХ в дальнейшем потребуется передать изменение или отмену, нельзя удалять исходные документы и формировать новые. В документе Регистрация трудовой деятельности при отмене должно фигурировать именно то событие, идентификатор которого был зафиксирован фондом (в приведенном примере — 1601074f-1b37-4ce4-a20d-8cbffdf1b293). В противном случае фонд снова вернет ошибку отсутствия исходных сведений.