Как исправить ошибку «Ошибка при получении информации о подписи» в 1С:ЗУП при обмене с СЭДО ФСС (СФР)?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом Налоговый учет
← На главную

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

В данной статье мы подробно разберем, почему возникает этот сбой, проанализируем технические причины и выработаем пошаговый алгоритм действий для восстановления работоспособности обмена с СФР (бывший ФСС).

Выясним причину возникновения ошибки

Прежде чем приступать к активным действиям, нам необходимо понять природу проблемы. Анализ показывает, что корень ошибки чаще всего кроется не в локальной базе пользователя, а во взаимодействии между 1С и шлюзами СФР. Рассмотрим основные факторы:

  1. Некорректный ответ сервера СФР: Сервер ведомства возвращает XML-пакет, в котором отсутствует блок с электронной подписью или он сформирован не полностью. Программа 1С, не находя необходимых данных для проверки подлинности сообщения, выдает стандартную ошибку.
  2. Высокая нагрузка на шлюзы СЭДО: В периоды массовой сдачи отчетности или подтверждения больничных листов серверы СФР могут работать нестабильно, обрывая сессию до завершения передачи всех метаданных подписи.
  3. Несоответствие алгоритмов криптографии: Обновления на стороне серверов СФР могут требовать более свежих версий криптопровайдеров или специфических настроек защищенного соединения TLS.
  4. Программные недоработки в конфигурации: Определенные релизы 1С требуют установки специальных патчей (исправлений) для корректной обработки изменившихся форматов ответов СЭДО.

Шаг 1. Проверка обновлений и установка патчей

Первым делом проанализируем состояние нашей конфигурации. Опыт использования версии 3.1.24.310 показывает, что стандартного обновления релиза может быть недостаточно. Разработчики 1С оперативно выпускают микро-исправления (патчи), которые не требуют полного обновления программы, но критически важны для СЭДО.

Рассмотрим порядок установки патчей:

  1. Перейдем в раздел Администрирование — Обслуживание — Обновление программы.
  2. Выберем пункт Установка обновлений и исправлений (патчей).
  3. Убедимся, что установлены все доступные исправления, особенно те, в описании которых фигурирует СЭДО или ФСС (например, патчи серии EF_90035544).

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

Шаг 2. Анализ состояния сертификатов и цепочек доверия

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

Проверим наличие следующих компонентов в хранилище сертификатов «Доверенные корневые центры сертификации»:

Помните, что с 2023 года ФСС и ПФР объединились в СФР, и сертификаты шлюзов были обновлены. Убедитесь, что в настройках обмена 1С выбраны актуальные сертификаты ведомства.

Шаг 3. Настройка криптопровайдера и параметров TLS

Разберем ситуацию, связанную с работой КриптоПро CSP. Начиная с платформы 1С:Предприятие 8.3.22, механизмы работы с защищенными соединениями претерпели изменения. Иногда возникает конфликт между встроенными средствами платформы и установленным криптопровайдером.

Для устранения этой причины рекомендуем выполнить следующие действия:

  1. Обновим КриптоПро CSP до актуальной версии (рекомендуется 5.0 R2 или R3). Старые версии могут некорректно обрабатывать новые алгоритмы ГОСТ, используемые в СЭДО.
  2. Проверим настройки TLS. В некоторых случаях помогает отключение или, наоборот, принудительное включение использования TLS 1.2 в настройках криптопровайдера.
  3. Если используется клиент-серверный вариант работы, убедимся, что криптопровайдер установлен именно на сервере 1С под учетной записью, от которой запущен сервис 1C:Enterprise 8.3 Server Agent.

Шаг 4. Работа с очередью сообщений и очистка кэша СЭДО

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

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

Иногда помогает временное «забывание» проблемных идентификаторов. Рассмотрим пример кода, который (в упрощенном виде) иллюстрирует логику поиска таких записей:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Состояния.ИдентификаторСообщения,
    |   Состояния.Состояние
    |ИЗ
    |   РегистрСведений.СостоянияСообщенийСЭДОФСС КАК Состояния
    |ГДЕ
    |   Состояния.Состояние = ЗНАЧЕНИЕ(Перечисление.СостоянияСообщенийСЭДО.Ошибка)";

Результат = Запрос.Выполнить().Выгрузить();
// Далее возможна очистка или повторная инициализация статусов

Важно: Любые прямые манипуляции с регистрами следует проводить только после создания резервной копии базы данных!

Шаг 5. Исключение влияния сетевых экранов и антивирусов

Проанализируем влияние сетевого окружения. Антивирусное ПО с функциями веб-экрана или прокси-серверы часто перехватывают HTTP-трафик для проверки на лету. Поскольку подпись сообщения в ответе от СФР обычно располагается в конце пакета, агрессивная фильтрация трафика может приводить к «обрезанию» или модификации данных.

Выясним, не блокируется ли трафик:

  1. Добавим адреса серверов СФР (домены *.fss.ru и *.sfr.gov.ru) в список исключений антивируса.
  2. В настройках прокси-сервера (если он используется) разрешим передачу данных без изменения для указанных узлов.
  3. Проверим настройки брандмауэра на сервере 1С — порты для обмена по HTTPS (443) должны быть открыты.

Шаг 6. Стратегия повторных запросов

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

Также стоит попробовать изменить период запроса. Вместо получения данных «за период» (например, за неделю), попробуйте запрашивать данные за каждый день отдельно. Это снизит объем передаваемых данных в одном пакете и уменьшит вероятность разрыва соединения до передачи информации о подписи.

Заключение

Подводя итог, отметим, что ошибка «Ошибка при получении информации о подписи» чаще всего является следствием технического сбоя на шлюзе СФР. Мы рекомендуем действовать последовательно: сначала исключить программные ошибки 1С путем установки всех доступных патчей, затем проверить актуальность сертификатов и версии КриптоПро. Если эти меры не помогают, следует переждать период пиковой нагрузки на серверы ведомства и повторить попытку обмена позже.

← На главную