> ## Documentation Index
> Fetch the complete documentation index at: https://docs.yume.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Подписание документов

> Три способа подписания документа — вручную, по SMS-коду и через ЕГОВ/ЭЦП — с журналом аудита каждого перехода статуса.

Полный перечень полей — в [глоссарии подписания](/ru/logic/documents/signing-glossary).

## Логика

Подписание документа строится вокруг трёх связанных сущностей:

* **Подписант** — сторона, которая должна поставить подпись: компания-арендодатель или клиент. Для пары «компания + клиент» подписант создаётся один раз и переиспользуется на всех документах этой компании.
* **Подпись документа** — запрос на подписание конкретного документа конкретным подписантом: хранит выбранный способ подписания, список разрешённых способов, публичный UUID (для ссылки клиенту) и текущий статус. На один документ не может быть двух подписей от одного подписанта.
* **Этап подписания** — запись в журнале истории: каждый раз, когда статус подписи меняется, создаётся новая запись этапа. Исключение — автоматическое создание подписи для компании при первом обращении к сценарию ЕГОВ (см. ниже): она сразу создаётся со статусом «Готов к подписанию» без записи этапа.

<Note>
  При создании записи этапа поле «статус до» всегда перезаписывается тем статусом, который был у подписи на момент сохранения, независимо от того, что передал вызывающий сценарий.
</Note>

**Статусы подписи:** Черновик → Готов к подписанию → Просматривается / На подтверждении → Подписан (либо Отклонён на любом этапе).

**Способы подписания:** вручную (сотрудник сам отмечает обе стороны), по SMS-коду (клиент вводит одноразовый код) и через ЕГОВ/ЭЦП (мобильное приложение или загрузка файла с электронной подписью, проверка через сервис НУЦ).

<Info>
  Список разрешённых для подписи способов хранится на самой подписи и проверяется сервером: если способ в него не входит, операция отклоняется с ошибкой «Недопустимый способ подписания». Проверка стоит в четырёх точках — отправка SMS сотрудником, запрос кода клиентом, подтверждение кода и оба пути ЕГОВ/ЭЦП (мобильное приложение и загрузка файла с ЭЦП).

  Ручное подписание сотрудником этот список намеренно не проверяет: по умолчанию в нём стоят только «ЕГОВ/ЭЦП» и «По SMS-коду», поэтому проверка запретила бы ручное подписание по всем ранее созданным подписям.
</Info>

### Добавление подписанта и подготовка к подписанию

Сотрудник компании добавляет клиента как подписанта к документу: ищется (или создаётся, с синхронизацией актуальных данных) подписант, проверяется отсутствие дубликата подписи для этой пары, создаётся подпись со статусом «Черновик» с первой записью этапа, запускается фоновая перегенерация файлов.

Аналогично сотрудник может получить/создать подписанта-компанию — при первом обращении она создаётся автоматически со статусом «Готов к подписанию» и способом «ЕГОВ/ЭЦП», в обход обычного механизма этапов.

Удаление подписи разрешено только пока она не в статусе «Подписан» — попытка удалить уже подписанную подпись просто игнорируется.

### Способ 1: ручное подписание сотрудником

Одно действие сотрудника подписывает документ сразу за обе стороны — типичный сценарий, когда стороны подписали бумажный экземпляр:

1. Для документа находятся или создаются подписант-компания и подписант-клиент.
2. Для каждого находится или создаётся подпись со способом «Вручную»; если создаётся заново — сразу присваивается статус «Подписан».
3. Если подпись уже была в статусе «Подписан» — операция отклоняется («Компания/Клиент уже подписал этот документ.»).
4. Если подпись была в любом другом статусе — она принудительно переводится в «Подписан».

При ручном подписании итоговый файл документа не создаётся — фоновая перегенерация для этого способа не запускается.

<Warning>
  Ручное подписание не проверяет, каким способом планировалось подписывать документ изначально — оно всегда переводит обе подписи сразу в статус «Подписан», даже если ранее подпись была, например, отклонена.
</Warning>

### Способ 2: подписание по SMS-коду

Сотрудник запускает отправку SMS: способу присваивается значение «По SMS-коду», статус переходит в «Готов к подписанию», клиенту приходит SMS со ссылкой (по UUID подписи). Ошибка провайдера отклоняет операцию.

Кто платит за оба сообщения подписания (ссылку и код) и может ли отправка быть заблокирована — определяет режим биллинга подписания, назначенный компании: в режиме «за SMS» сообщения списываются с SMS-баланса компании, в режиме «за документ» они бесплатны, но отправка блокируется, если в пакетах подписей не осталось ни одного слота. Подробнее — в [«Пакеты, баланс и квоты подписи»](/ru/logic/documents/packages).

**Клиентский цикл:**

1. **Открытие ссылки** переводит статус в «Просматривается» (если подпись ещё не подписана и не отклонена).
2. **Запрос кода** сначала проверяет номер телефона подписанта и отправляет SMS с одноразовым 4-значным кодом, а сам код становится годным только после того, как отправку приняли: при неверном формате телефона или отказе провайдера статус и запись этапа откатываются и годного кода не остаётся. Успешный запрос переводит статус в «На подтверждении», код действует 2 минуты.
3. **Подтверждение кода** переводит статус в «Подписан», аннулирует код и запускает фоновую перегенерацию файлов. Неверный код или несколько неверных попыток отклоняют/аннулируют код.

<Note>
  Код привязан к конкретной подписи: код, полученный по другой подписи того же документа или в другом сценарии подтверждения телефона, для подписания не подойдёт.
</Note>

<Info>
  Ссылку с кодом можно запрашивать повторно без ограничения по времени между запросами — в отличие от большинства других одноразовых кодов в системе, здесь нет паузы между повторными отправками.
</Info>

### Способ 3: подписание через ЕГОВ / ЭЦП

Два независимых пути к одному результату (файл с ЭЦП, статус «Подписан»):

* **Через мобильное приложение ЕГОВ.** Приложение запрашивает описание документа (название, срок действия приглашения — 14 дней, реквизиты компании), затем сам файл (если уже есть файл с ЭЦП от предыдущего подписанта — отдаётся именно он, чтобы новая подпись добавлялась поверх). После подписания система проверяет подпись через НУЦ, сохраняет файл и список сертификатов, создаёт этап перехода в «Подписан» (без данных об IP/устройстве — этот шаг выполняет само приложение) и запускает фоновую перегенерацию.
* **Прямая загрузка файла с ЭЦП** — тот же механизм без мобильного приложения: файл проверяется через НУЦ, сохраняется как итоговый файл со списком сертификатов, создаётся этап перехода, отправляется веб-уведомление.

<Warning>
  Фоновая перегенерация файлов документа запускается только при завершении подписания по SMS-коду и при подписании через мобильное приложение ЕГОВ. При ручном подписании файл вообще не создаётся, а при прямой загрузке файла с ЭЦП обновляется только сам файл с подписью.
</Warning>

### Когда документ считается подписанным

Документ автоматически помечается как подписанный, когда одновременно выполняются два условия: минимум две подписи и все они в статусе «Подписан». Пересчитывается автоматически при каждом изменении статуса любой подписи. При переходе в подписанное состояние компании отправляется уведомление.

<Tip>
  Если у документа только одна подпись, он никогда не будет автоматически помечен как подписанный, даже если эта единственная подпись в статусе «Подписан».
</Tip>

### Списание из пакета документов и метаданные аудита

Расходуется ли на документ слот из купленного пакета подписей, зависит от режима биллинга подписания, назначенного компании платформой: в режиме «за SMS» пакеты не расходуются вообще, в режиме «за документ» подписание списывает **один** слот на документ, независимо от того, сколько у него подписантов. Если пакетов с остатком нет — списание просто не происходит, подписание всё равно завершается успешно. Подробности — в [«Пакеты, баланс и квоты подписи»](/ru/logic/documents/packages).

При большинстве переходов статуса в запись этапа сохраняются метаданные того, кто выполнил действие: IP-адрес, ОС, браузер и тип устройства. Исключение — подтверждение через мобильное приложение ЕГОВ: там в журнал попадают только данные сертификата.

## Особенности поведения

* При ручном подписании обеими сторонами не проверяется предыдущий способ или статус существующей подписи (кроме случая «уже подписана») — подпись в любом другом статусе, включая «Отклонён», принудительно переводится в «Подписан».
* Ручное подписание — единственный способ, который не сверяется со списком разрешённых способов подписания: сотрудник может подписать документ вручную, даже если ручное подписание в списке не разрешено.
* Запрос SMS-кода подтверждения не имеет паузы между повторными запросами — клиент может запрашивать новый код сколько угодно раз подряд.
* Проверка остатка пакета (в режиме «за документ») стоит на отправке ссылки сотрудником, запросе кода, подтверждении кода и загрузке файла с ЭЦП. Ручное подписание и подтверждение через мобильное приложение ЕГОВ нулевым остатком не блокируются: они списывают слот, если остаток есть, и подписывают документ бесплатно, если его нет.
* Автоматическое создание подписи для компании при первом обращении к сценарию ЕГОВ устанавливает статус «Готов к подписанию» напрямую, в обход механизма записи этапа — для этого перехода в журнале не остаётся никакой записи.
* Реквизиты компании, которые показываются клиенту в приглашении ЕГОВ, при отсутствии соответствующих настроек компании подставляются значениями по умолчанию, совпадающими с реквизитами самой Yume Cloud.
* Публичная страница документа определяет, чью подпись пометить как «Просматривается», строго по совпадению ссылки конкретной подписи; ссылка по идентификатору документа (а не подписи) не запускает этот переход.
* Статус «Отклонён» определён в системе, но ни один из способов подписания фактически не переводит подпись в этот статус.