← На главную

При работе с системой СЭДО (Социальный электронный документооборот) пользователи 1С:ЗУП 3.1 часто сталкиваются с ошибкой ERR_PR_1029. Сообщение сопровождается пояснением: «Значение поля ... недопустимо для редактирования». Эта ошибка может возникать при отправке ответов на запросы СФР (бывший ФСС) по разным видам пособий: единовременному пособию при рождении ребенка, ежемесячному пособию по уходу за ребенком или по обычным больничным листам.

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

Природа возникновения ошибки ERR_PR_1029

Прежде всего, важно понимать, что ошибка ERR_PR_1029 генерируется на стороне сервера СФР, а не в самой программе 1С. Логика СФР строится на принципе «эталонных данных». Когда фонд присылает вам «Входящий запрос для расчета пособия» (тип сообщения 100), в нем уже содержатся сведения, которые есть в базе фонда (данные ЗАГС, СНИЛС ребенка, коды нетрудоспособности).

Если в документе Ответ на запрос СФР для расчета пособия (тип сообщения 101) вы меняете эти данные, сервер фонда отклоняет документ. С точки зрения системы, вы пытаетесь отредактировать поля, которые в данной итерации обмена считаются константами. Рассмотрим основные сценарии, когда это происходит.

Сценарий 1: Ошибки в сведениях о рождении ребенка (birthInfo)

Чаще всего ошибка возникает в полях birthInfo.zagsAct.num или birthInfo.zagsAct.cert.num. Разберем основные причины:

1. Несоответствие раскладки клавиатуры. Проанализируем типичную ситуацию: серия свидетельства о рождении содержит римские цифры. Многие пользователи вводят их русскими буквами (например, «I-АН» вводится как «Ш-АН») или арабскими цифрами. Система СФР ожидает строго латинские символы для римских цифр.
2. Лишние символы. Посмотрим, нет ли в номере актовой записи знака «№», лишних пробелов или тире, которых не было во входящем запросе.
3. Неполные данные. Иногда входящий запрос приходит с заполненным актом ЗАГС, но пустым номером свидетельства. Если вы дозаполняете свидетельство, фонд может выдать ошибку, так как считает это «редактированием» набора данных.

Решение:

В документе Ответ на запрос проверьте серию свидетельства. Если там указана единица «1», замените её на заглавную латинскую «I». Если указана буква «Х», убедитесь, что это английская «X». По опыту пользователей, замена кириллических и цифровых символов на латинские в 90% случаев решает проблему с полями birthInfo.

Сценарий 2: Ошибки в данных о заработке у других страхователей

Встречается ошибка в поле benefit5Approve.assignmentParams.twoPrevYearsInsurers. Это происходит при оформлении пособия по уходу за ребенком до 1,5 лет — для контроля есть мониторинг сотрудников в отпусках по уходу за ребенком. Ошибка означает, что фонд уже имеет сведения о доходах сотрудника у других работодателей и не позволяет вам менять этот признак в ответе.

Решение:

Для исправления этой конкретной ошибки фирма «1С» выпустила специальный патч EF_70080106. Рассмотрим порядок действий:

1. Перейдем в раздел Администрирование — Обслуживание — Обновление программы — Установленные исправления (патчи).
2. Убедимся, что патч EF_70080106 (или более свежий кумулятивный патч) установлен.
3. Если патча нет, загрузим его через сервис интернет-поддержки или установим вручную.

Сценарий 3: Расхождение СНИЛС или кодов нетрудоспособности

Если ошибка указывает на birthInfo.snils или elnInfo.code, это означает критическое расхождение. Например, если СНИЛС ребенка в вашей базе отличается от того, что указан в базе фонда. Выясним причину: возможно, во входящем запросе данные были ошибочны.

Решение:

Если данные во входящем запросе действительно неверны, вы не сможете их просто исправить в ответе — пригодится массовая отмена ошибочных изменений в 1С. В такой ситуации рекомендуется:

1. Зайти в документ Входящий запрос, нажать кнопку Еще — Разрешить редактирование объекта.
2. Привести данные в соответствие с теми, что требует фонд (даже если они кажутся вам странными), чтобы «протолкнуть» документ.
3. Если данные в фонде в корне неверны (ошибка в фамилии или СНИЛС), сотруднику необходимо обратиться в СФР для корректировки своих персональных данных.

Общий технический алгоритм исправления

Если вы столкнулись с ошибкой ERR_PR_1029, выполните следующие шаги вместе с нами:

Шаг 1. Сопоставление данных.

Откройте одновременно Входящий запрос СФР и ваш Ответ на запрос. Проверьте посимвольно все поля, упомянутые в ошибке. Помните, что пробел в конце строки — это тоже символ, который вызывает ошибку редактирования.

Шаг 2. Пересоздание документа.

Иногда документ Ответ на запрос «запоминает» историю изменений внутри своих реквизитов — поможет фиксация истории изменений документов и сравнение версий. Попробуем следующий метод: пометим текущий ответ на удаление и создадим новый строго на основании входящего запроса. Постарайтесь не использовать кнопку Разрешить редактирование без крайней необходимости.

Шаг 3. Использование патчей и обновлений.

Механизмы СЭДО постоянно меняются. Проверьте версию вашей конфигурации. Для корректной работы с актуальными требованиями СФР 2024 года версия 1С:ЗУП должна быть не ниже 3.1.27.193 или 3.1.29.21. Проверьте наличие установленных патчей:

• EF_70080106 (для пособий по уходу за ребенком);
• EF_70080007 (для единовременных пособий).

Что делать, если ничего не помогает?

Проанализируем ситуацию, когда данные верны, патчи стоят, но СФР упорно возвращает ошибку ERR_PR_1029 — поможет автоматическое отслеживание ошибок СЭДО и уведомление ответственных. Это может быть признаком технического сбоя на шлюзе самого фонда. В этом случае у работодателя есть запасной вариант.

Рассмотрим «план Б»: отправка сведений старым способом через Реестр прямых выплат. Хотя СФР настаивает на использовании СЭДО, в случае технических ошибок на их стороне они принимают реестры (тип сообщения 109 «Инициация выплаты»). Как отмечают эксперты на семинарах, «в любом непонятном случае отправляйте реестр», чтобы не нарушить сроки выплаты пособия сотруднику.

Подведем итог. Ошибка ERR_PR_1029 — это сигнал о том, что нарушена целостность данных между вашей базой 1С и базой СФР. Внимательная проверка раскладки символов в сериях документов и своевременная установка исправлений 1С позволяют успешно решить эту проблему.