Логика
Подписание документа строится вокруг трёх связанных сущностей:- Подписант — сторона, которая должна поставить подпись: компания-арендодатель или клиент. Для пары «компания + клиент» подписант создаётся один раз и переиспользуется на всех документах этой компании.
- Подпись документа — запрос на подписание конкретного документа конкретным подписантом: хранит выбранный способ подписания, список разрешённых способов, публичный UUID (для ссылки клиенту) и текущий статус. На один документ не может быть двух подписей от одного подписанта.
- Этап подписания — запись в журнале истории: каждый раз, когда статус подписи меняется, создаётся новая запись этапа. Исключение — автоматическое создание подписи для компании при первом обращении к сценарию ЕГОВ (см. ниже): она сразу создаётся со статусом «Готов к подписанию» без записи этапа.
При создании записи этапа поле «статус до» всегда перезаписывается тем статусом, который был у подписи на момент сохранения, независимо от того, что передал вызывающий сценарий.
Список разрешённых для подписи способов хранится на самой подписи и проверяется сервером: если способ в него не входит, операция отклоняется с ошибкой «Недопустимый способ подписания». Проверка стоит в четырёх точках — отправка SMS сотрудником, запрос кода клиентом, подтверждение кода и оба пути ЕГОВ/ЭЦП (мобильное приложение и загрузка файла с ЭЦП).Ручное подписание сотрудником этот список намеренно не проверяет: по умолчанию в нём стоят только «ЕГОВ/ЭЦП» и «По SMS-коду», поэтому проверка запретила бы ручное подписание по всем ранее созданным подписям.
Добавление подписанта и подготовка к подписанию
Сотрудник компании добавляет клиента как подписанта к документу: ищется (или создаётся, с синхронизацией актуальных данных) подписант, проверяется отсутствие дубликата подписи для этой пары, создаётся подпись со статусом «Черновик» с первой записью этапа, запускается фоновая перегенерация файлов. Аналогично сотрудник может получить/создать подписанта-компанию — при первом обращении она создаётся автоматически со статусом «Готов к подписанию» и способом «ЕГОВ/ЭЦП», в обход обычного механизма этапов. Удаление подписи разрешено только пока она не в статусе «Подписан» — попытка удалить уже подписанную подпись просто игнорируется.Способ 1: ручное подписание сотрудником
Одно действие сотрудника подписывает документ сразу за обе стороны — типичный сценарий, когда стороны подписали бумажный экземпляр:- Для документа находятся или создаются подписант-компания и подписант-клиент.
- Для каждого находится или создаётся подпись со способом «Вручную»; если создаётся заново — сразу присваивается статус «Подписан».
- Если подпись уже была в статусе «Подписан» — операция отклоняется («Компания/Клиент уже подписал этот документ.»).
- Если подпись была в любом другом статусе — она принудительно переводится в «Подписан».
Способ 2: подписание по SMS-коду
Сотрудник запускает отправку SMS: способу присваивается значение «По SMS-коду», статус переходит в «Готов к подписанию», клиенту приходит SMS со ссылкой (по UUID подписи). Ошибка провайдера отклоняет операцию. Кто платит за оба сообщения подписания (ссылку и код) и может ли отправка быть заблокирована — определяет режим биллинга подписания, назначенный компании: в режиме «за SMS» сообщения списываются с SMS-баланса компании, в режиме «за документ» они бесплатны, но отправка блокируется, если в пакетах подписей не осталось ни одного слота. Подробнее — в «Пакеты, баланс и квоты подписи». Клиентский цикл:- Открытие ссылки переводит статус в «Просматривается» (если подпись ещё не подписана и не отклонена).
- Запрос кода сначала проверяет номер телефона подписанта и отправляет SMS с одноразовым 4-значным кодом, а сам код становится годным только после того, как отправку приняли: при неверном формате телефона или отказе провайдера статус и запись этапа откатываются и годного кода не остаётся. Успешный запрос переводит статус в «На подтверждении», код действует 2 минуты.
- Подтверждение кода переводит статус в «Подписан», аннулирует код и запускает фоновую перегенерацию файлов. Неверный код или несколько неверных попыток отклоняют/аннулируют код.
Код привязан к конкретной подписи: код, полученный по другой подписи того же документа или в другом сценарии подтверждения телефона, для подписания не подойдёт.
Ссылку с кодом можно запрашивать повторно без ограничения по времени между запросами — в отличие от большинства других одноразовых кодов в системе, здесь нет паузы между повторными отправками.
Способ 3: подписание через ЕГОВ / ЭЦП
Два независимых пути к одному результату (файл с ЭЦП, статус «Подписан»):- Через мобильное приложение ЕГОВ. Приложение запрашивает описание документа (название, срок действия приглашения — 14 дней, реквизиты компании), затем сам файл (если уже есть файл с ЭЦП от предыдущего подписанта — отдаётся именно он, чтобы новая подпись добавлялась поверх). После подписания система проверяет подпись через НУЦ, сохраняет файл и список сертификатов, создаёт этап перехода в «Подписан» (без данных об IP/устройстве — этот шаг выполняет само приложение) и запускает фоновую перегенерацию.
- Прямая загрузка файла с ЭЦП — тот же механизм без мобильного приложения: файл проверяется через НУЦ, сохраняется как итоговый файл со списком сертификатов, создаётся этап перехода, отправляется веб-уведомление.
Когда документ считается подписанным
Документ автоматически помечается как подписанный, когда одновременно выполняются два условия: минимум две подписи и все они в статусе «Подписан». Пересчитывается автоматически при каждом изменении статуса любой подписи. При переходе в подписанное состояние компании отправляется уведомление.Списание из пакета документов и метаданные аудита
Расходуется ли на документ слот из купленного пакета подписей, зависит от режима биллинга подписания, назначенного компании платформой: в режиме «за SMS» пакеты не расходуются вообще, в режиме «за документ» подписание списывает один слот на документ, независимо от того, сколько у него подписантов. Если пакетов с остатком нет — списание просто не происходит, подписание всё равно завершается успешно. Подробности — в «Пакеты, баланс и квоты подписи». При большинстве переходов статуса в запись этапа сохраняются метаданные того, кто выполнил действие: IP-адрес, ОС, браузер и тип устройства. Исключение — подтверждение через мобильное приложение ЕГОВ: там в журнал попадают только данные сертификата.Особенности поведения
- При ручном подписании обеими сторонами не проверяется предыдущий способ или статус существующей подписи (кроме случая «уже подписана») — подпись в любом другом статусе, включая «Отклонён», принудительно переводится в «Подписан».
- Ручное подписание — единственный способ, который не сверяется со списком разрешённых способов подписания: сотрудник может подписать документ вручную, даже если ручное подписание в списке не разрешено.
- Запрос SMS-кода подтверждения не имеет паузы между повторными запросами — клиент может запрашивать новый код сколько угодно раз подряд.
- Проверка остатка пакета (в режиме «за документ») стоит на отправке ссылки сотрудником, запросе кода, подтверждении кода и загрузке файла с ЭЦП. Ручное подписание и подтверждение через мобильное приложение ЕГОВ нулевым остатком не блокируются: они списывают слот, если остаток есть, и подписывают документ бесплатно, если его нет.
- Автоматическое создание подписи для компании при первом обращении к сценарию ЕГОВ устанавливает статус «Готов к подписанию» напрямую, в обход механизма записи этапа — для этого перехода в журнале не остаётся никакой записи.
- Реквизиты компании, которые показываются клиенту в приглашении ЕГОВ, при отсутствии соответствующих настроек компании подставляются значениями по умолчанию, совпадающими с реквизитами самой Yume Cloud.
- Публичная страница документа определяет, чью подпись пометить как «Просматривается», строго по совпадению ссылки конкретной подписи; ссылка по идентификатору документа (а не подписи) не запускает этот переход.
- Статус «Отклонён» определён в системе, но ни один из способов подписания фактически не переводит подпись в этот статус.