← На главную

При переходе на электронные листки нетрудоспособности (ЭЛН) и систему Социального электронного документооборота (СЭДО) перед организациями часто возникает задача: как организовать работу группы расчетчиков, если подпись руководителя или ответственного лица выпущена в единственном экземпляре? Разберем подробно, как правильно настроить электронный документооборот, лицензирование криптопровайдера и работу с ЭЦП в программах 1С.

Организация работы расчетчиков с ЭЛН и варианты использования ЭЦП

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

Для реализации такой схемы подходят следующие варианты архитектуры:

1. Серверная подпись и шифрование в 1С (наиболее оптимальный вариант). Сертификат электронной подписи и криптопровайдер устанавливаются непосредственно на сервер приложений 1С. В этом случае все расчетчики могут считывать данные ЭЛН и отправлять запросы в фонд прямо со своих рабочих мест без физического наличия токена на каждом компьютере.
2. Использование машиночитаемых доверенностей (МЧД) и личных ЭП. Каждому расчетчику оформляется личная квалифицированная электронная подпись физического лица, а в 1С регистрируется МЧД с соответствующими полномочиями для обмена сведениями по ЭЛН и пособиям.
3. Копирование сертификата на локальные ПК. Если закрытый ключ сертификата не защищен от экспорта, контейнер закрытого ключа можно скопировать в системный реестр на локальные компьютеры сотрудников. Однако этот способ требует покупки локальных лицензий CryptoPro для каждого рабочего места и менее безопасен с точки зрения контроля доступа.

Серверная настройка криптографии в 1С

Проанализируем техническую реализацию серверной подписи в клиент-серверном режиме работы 1С:Предприятия. Данный подход избавляет от необходимости дублировать ключи и устанавливать программу КриптоПро CSP на каждый пользовательский компьютер.

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

1. Установим криптопровайдер (например, CryptoPro CSP) непосредственно на сервер приложений 1С.
2. Приобретем и активируем серверную лицензию КриптоПро CSP. Это полностью закрывает вопрос лицензирования криптопровайдера для всех пользователей базы данных.
3. Установим сертификат электронной подписи и контейнер закрытого ключа на сервере. Предоставим права доступа к контейнеру для учетной записи ОС, от имени которой запущен Агент сервера 1С:Предприятия.
4. Перейдем в программе 1С в раздел Администрирование — Электронная подпись и шифрование.
5. Включим флаги Подписывать на сервере и Проверять подписи и сертификаты на сервере.

После этого расчетчики смогут запрашивать данные больничных листов по их номерам непосредственно из интерфейса 1С — подписание и расшифровка входящих сообщений фонда будут выполняться силами сервера 1С.

Прямой обмен с фондом через СЭДО и сторонние программы ЭДО

Выясним, обязательна ли подписка на сторонние сервисы сдачи отчетности или подключение 1С-Отчетность для работы с больничными.

В типовых конфигурациях (например, 1С:Зарплата и Управление Персоналом или 1С:Бухгалтерия) обмен с СФР (ФСС) по схеме СЭДО встроен по умолчанию и выполняется напрямую. Наличие сервиса 1С-Отчетность или сторонних операторов (Контур, Такском и др.) не является строгим требованием для получения и отправки ЭЛН.

Прямой обмен через 1С работает следующим образом:

1. 1С отправляет запрос на получение данных больничного листа напрямую на серверы фонда, используя установленный сертификат подписи.
2. Фонд возвращает зашифрованный ответ. Для его успешной расшифровки на сервере или рабочем месте должны быть установлены актуальные корневые сертификаты УЦ и сертификат ключа шифрования самого фонда (СФР).
3. Расчетчик получает заполненный больничный лист в базе 1С.
4. После расчета пособия сформированный ответ на запрос сведений отправляется напрямую в СФР без промежуточной выгрузки файлов на диск.

Подключение внешних операторов ЭДО или использование личного кабинета фонда требуется только в качестве резервного канала на случай технических сбоев прямого обмена СЭДО.