Переход на проактивную схему выплат и объединение фондов в СФР принесли множество технических сложностей при обмене через СЭДО. Одной из самых частых и болезненных проблем является ситуация, когда больничный лист закрыт, в сторонних операторах (Контур, СБИС) входящий запрос виден, а в 1С — тишина. Документы не приходят, статус обмена не обновляется, или возникают ошибки 404/500/504.
В этой статье мы подробно разберем причины такого поведения и предложим несколько проверенных решений, от простых пользовательских действий до программных правок кода (актуально для УПП). Мы проанализируем ситуацию с точки зрения механизмов работы серверов СФР и специфики платформы 1С.
Самая распространенная причина, почему 1С "не видит" новые сообщения, заключается в механизме работы сервера СЭДО. Сервер отдает сообщения последовательно. У каждого страхователя есть невидимый "курсор" (указатель), который отмечает последнее полученное сообщение.
Если ваша организация использует параллельно и 1С, и стороннего оператора (например, Контур или СБИС) с настроенным автообменом, происходит следующее:
Решение: Принудительная загрузка за период
Чтобы заставить 1С получить сообщения, которые уже были помечены как "прочитанные" другим оператором, необходимо использовать функцию повторного получения данных за конкретный период.
Давайте выполним следующие действия:
Важный нюанс! Не пытайтесь загрузить сообщения за большой интервал (месяц или неделю). Серверы СФР часто работают нестабильно, и большой запрос приведет к зависанию 1С или ошибке таймаута.
Мы рекомендуем устанавливать период, равный одному конкретному дню (например, дате закрытия больничного). Если сообщений много, делайте паузы между запросами в 5–10 минут, чтобы избежать временной блокировки по IP (ошибка 403 или 429).
Иногда СФР не присылает запрос, потому что в их базе данных нет актуальной связки "Физлицо — Страхователь". Это часто случается, если сотрудник был принят недавно, или по нему давно не было больничных.
Решение: Отправка сведений о застрахованном лице
Попробуйте принудительно инициировать процесс идентификации:
Как показывает практика, часто через несколько часов (или на следующий день) после принятия сведений, СФР "просыпается" и присылает зависший входящий запрос по больничному.
В начале 2023 и 2024 годов наблюдались массовые проблемы с форматами обмена. Ошибки с кодами 500 (Internal Server Error) и 404 часто связаны не с отсутствием связи, а с некорректной обработкой ответа от сервера внутри самой 1С.
Решение: Установка исправлений (патчей)
Если вы используете типовую конфигурацию (ЗУП 3.1), обязательно проверьте наличие неустановленных исправлений.
EF_....Для пользователей ЗГУ (Зарплата и кадры государственного учреждения) патчи могут выходить с задержкой относительно коммерческой ЗУП. В этом случае необходимо мониторить сайт релизов 1С.
Иногда бухгалтеры ждут входящий запрос по больничному листу продолжительностью 1, 2 или 3 дня. Однако запрос не приходит.
Разъяснение:
Согласно законодательству, первые три дня временной нетрудоспособности оплачиваются за счет средств работодателя. Фонд в этой выплате не участвует. Следовательно, СФР не формирует входящий запрос (тип сообщения 100 — запрос недостающих сведений), так как ему не нужны сведения для выплаты.
В этом случае вам придет только сообщение об изменении статуса ЭЛН (тип 111) со статусом "Закрыт медицинской организацией". На основании этого сообщения (номера ЭЛН) вы рассчитываете больничный в 1С и выплачиваете его своими силами. Ждать входящего запроса не нужно.
Пользователи конфигурации "Управление производственным предприятием" (УПП) столкнулись со специфической ошибкой, когда документ создается, но остается пустым, или обмен прерывается.
При анализе кода выяснилось, что в модуле менеджера документа ВходящийЗапросФССДляРасчетаПособия происходит некорректное сравнение версий спецификации. Переменная ВерсияЧисломБыло может иметь тип Строка, а ВерсияЧисломСтало — Число. Платформа 1С не позволяет сравнивать строку с числом операторами "больше/меньше".
Как исправить код:
Необходимо найти процедуру ПоднятьВерсиюСпецификации в модуле менеджера документа и привести типы к единообразию. Рассмотрим правильный вариант кода:
Процедура ПоднятьВерсиюСпецификации(Документ, Версия)
// Получаем текущее значение и сразу преобразуем в число, используя ту же функцию, что и для новой версии
СтрокаВерсии = ОбщегоНазначенияЗК.ЗначениеСвойства(Документ, "ВерсияСпецификации");
ВерсияЧисломБыло = ЭлектронныйДокументооборотСФСС.ВерсияЧислом(СтрокаВерсии);
ВерсияЧисломСтало = ЭлектронныйДокументооборотСФСС.ВерсияЧислом(Версия);
// Теперь сравниваем два числа
Если ВерсияЧисломБыло = Неопределено Или ВерсияЧисломБыло < ВерсияЧисломСтало Тогда
Документ.Вставить("ВерсияСпецификации", Версия);
Документ.Вставить("ВерсияСпецификацииЧислом", ВерсияЧисломСтало);
КонецЕсли;
КонецПроцедуры
Или, как временное решение, обернуть блок сравнения в конструкцию Попытка ... Исключение, однако это не устраняет причину, а лишь скрывает ошибку.
Если вышеперечисленные методы не помогли, проверим еще несколько технических моментов:
ВходящиеСообщенияСЭДОФСС, но не могут сформировать документ ВходящийЗапросФСС из-за нехватки прав (RLS). Попробуйте выполнить обмен под пользователем с полными правами.Входящие сообщения СЭДО ФСС. Если записи там есть, но они не обработаны, проблема на стороне логики 1С (патчи, сопоставление физлиц), а не связи с сервером.