Ошибка с типом сообщения 14

1. Добрый день! В тексте сообщения указана ошибка:

   E_SEDO_3220 — Реквизиты из запроса не соответствуют реквизитам из сертификата. Так же, не приложена машиночитаемая доверенность. Полномочия не подтверждены

   Для её исправления необходимо проверить:

   1. Проверить реквизиты Страхователя-отправителя запроса и реквизиты в сертификате, которым подписан данный запрос — реквизиты должны совпадать

   Как проверить:
   — Страхователь-отправитель указан в XML-запросе в теге: recipientid(это РегНомер ФСС\СФР) — для типа взаимодействия «Страхователь» (interactionType=2)
   org (это реквизиты ОГРН\ОГРНИП\КПП\ИНН\СНИЛС) — для типа взаимодействия «Организация» (interactionType=3)
   — Открыть сертификат (вкладка «Состав»- блок «Субъект»), которым подписан запрос и сравнить с реквизитами Страхователя-отправителя

   2. если данные в п.1 не совпали, то система СЭДО начинает искать в XML-запросе блок Object с информацией о номере МЧД (блок Object должен быть сформирован по Спецификации).
   По указанному номеру МЧД происходит проверка реквизитов в МЧД в блоке «Владелец» и сравнивает с реквизитами Страхователя-отправителя указанного в XML-запросе в теге recipientid — реквизиты должны совпадать.

   МЧД выдается Уполномоченному на подписание и отправку запросов за Страхователя.
   В МЧД так же проверяются полномочия на отправку запроса СЭДО (FSS_000009-Страхователь.СЭДО) и полномочия на передаваемый тип сообщения для ФК (у каждого типа сообщения СЭДО свой код полномочия, если в классификаторе МЧД нет такого полномочия, то запрос с использованием МЧД нельзя подписывать).

   Похоже, что МЧД был сформирован некорректно.

   3. если проверка не пройдена по пунктам 1 и 2, отбивается ошибка, что реквизиты не совпадают, нет полномочия или МЧД не найдена.

   Проверка реквизитов зависит от типа Страхователя-отправителя:
   ЮЛ — ОГРН\ИНН\КПП
   ИП — ОГРНИП\ИНН\СНИЛС
   ФЛ — СНИЛС\ИНН\Рег.номер
   ЮЛ иностран. представительств — ИНН\КПП

2. Елена, добрый день!
   Да дело в том, что ошибка ранее не возникала, получалось/отправлялось отлично все.
   ЭЦП физлица (токен) действующий, МЧД тоже (Полномочия FSS_000000, у нас у всех такие полномочия, у других таких ошибок нет)
   Ну вроде ничего не изменилось

3. Разработчики СЭДО говорят, что в 99% случаев данная ошибка связана с тем, что владелец сообщения не приложил доверенность, поэтому проверка реквизитов завершается ошибкой.
   Можно посмотреть по идентификатором сообщений в регистре сведений Входящие сообщения СЭДО СФР (бывш. ФСС), какой тип сообщения прошел с ошибкой. И может быть позже он отправился без неё.
   Чтобы перейти в регистр нужно нажать Shift+F11 и указать ссылку:

   e1cib/list/РегистрСведений.ВходящиеСообщенияСЭДОФСС

   Далее нажать «Перейти»

   1. Елена, добрый день!
      Разработчики СЭДО говорят, что ошибка связана с тем, что владелец сообщения не приложил доверенность…
      Просто мы уже который год работаем и не было таких проблем. Работает связка ЭЦП физлица (токен, флешка с действующим периодом действия) и МЧД тоже действующая.
      Вы пишите, что разработчики СФР ответили про то, что запрос подписан ФЛ со СНИЛС (17…) и ИНН (25…). Такого пользователя вообще нет в ЗУПе, кто бы мог что то попытаться отправить или получить.

      Может вообще проигнорировать ошибку эту, но может сбой какой был. Но смущает тут в сообщении еще какой то срок действия указан 01.07

      Я думаю, может вообще проигнорировать эту ошибку, ну может сбой какой

4. Уточнила у разработчиков СФР информацию по идентификатору, они пишут:

   Ваш запрос подписан сертификатом ФЛ:
   СНИЛС = 17…
   ИНН = 25…

   При это запрос отправляется от лица организации с реквизитами:
   ИНН = 7709…
   КПП = 7706…
   ОГРН = 102…

   Запросы от лица организации подписываются сертификатом ЮЛ.

   Если запрос отправляет уполномоченный, ему должна быть выдана МЧД и указана при отправке запроса

5. Добрый день! Могла быть такая ситуация: что в настройках программы меняли сертификат и ошибочно указали другой, затем исправили, но в этот момент запустился обмен по СЭДО, поэтому появилась ошибка.
   Ошибку можно игнорировать, но при условии, что по идентификаторам, указанным в сообщении обмен прошел корректно. Т.е. все документы отправлены и получены.

6. По идентификаторам указанным в сообщении лишь одна строка появляется при поиске, именно строка с ошибкой 14. Как еще можно определить в каких документах указан этот идентификатор непонятно

7. Если по идентификатору 25b7f2e9-4a09-43bd-a3f2-268f77437583 тоже нет записей, то скорее всего с ошибочной подписью был отправлен запрос сообщений. Т.е. кто-то просто нажал Получить из ФСС и программа отправила запрос сообщений на сервер, а в ответ вернулась ошибка.

Комментарии закрыты.