В ЗУП не приходит входящий запрос СФР: получение по UUID

Если в ЗУП не приходит входящий запрос СФР, я сначала выясняю, создано ли само сообщение. Когда в ответе фонда уже указан его UUID, можно проверить получение именно этого запроса, а не повторять отправку документов наугад.

Когда подходит получение запроса по UUID

Речь о ситуации, когда после отправки исходящего сообщения появляется ERR_PR_1067: проактивный процесс закрыт, но в тексте ответа есть сведения о другом процессе и идентификатор входящего сообщения. В журнале ЗУП нужного запроса при этом нет.

В сентябрьском случае 2026 года адресное получение по UUID позволило загрузить отсутствующий входящий запрос. Это не универсальное исправление ERR_PR_1067: если нужное сообщение не создано или его идентификатор неизвестен, описанный способ не заменяет выяснение причины отказа.

Что я проверяю перед загрузкой

Сохраняю текст ответа фонда и отделяю UUID входящего сообщения от номера ЭЛН и номера проактивного процесса. Для поиска нужен именно идентификатор сообщения. Также проверяю, к какой организации оно относится.

Для обмена после перехода на ЕЦП важен релиз конфигурации. Поддержка нового обмена появилась в ЗУП 3.1.38.92; дата перехода в описании релиза — 21 сентября 2026 года. У входящего запроса тип 100 сменился на 10010, у ответа — 101 на 10110. Это номера типов сообщений, а не значения, которые нужно вручную исправлять в базе.

Как получить отсутствующий входящий запрос СФР

Сначала я использую обычную загрузку за нужный период: в списке «Входящие запросы СФР для расчета пособий» открываю «Еще» и выбираю «Получить сообщения за период».

Если запрос не появился, но его UUID известен, перехожу к адресному получению:

1. Открываю через функции для технического специалиста регистр «Входящие сообщения СЭДО».
2. Ищу запись по UUID нужного входящего сообщения и проверяю организацию.
3. В найденной записи выбираю «Еще» → «Получить с сервера СЭДО».
4. Если записи нет, предусмотренный документацией вариант — создать её, заполнить «Организация» и «Идентификатор», затем вызвать ту же команду получения. Чужую запись для этого не перезаписываю.

Не удаляю регистр целиком и не меняю вручную состояние процесса. Эти действия не относятся к получению сообщения по идентификатору.

Как проверить результат

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

Полученный запрос ещё не означает, что ответ на него принят фондом. После подготовки и отправки ответа отдельно проверяю результат обмена. Если отказ уже связан с emailAddress, это другая ошибка заполнения ответа СЭДО.

Для меня здесь главный ориентир — UUID конкретного входящего сообщения. Он позволяет проверить адресное получение, но не даёт оснований обещать исправление любого закрытого процесса или успешную выплату пособия.