NexTool Solutions

Документы, которые нужно подписать, до сих пор ходят по электронной почте и WhatsApp — без прослеживаемости, без понятного статуса и в полном отрыве от заявок, из которых они появились. Модуль Digital Signature от NexTool вместе с Autentique переносит этот процесс внутрь GLPI.

Проблема

Договоры на оказание услуг, акты приёмки, разрешения на доступ, протоколы и соглашения о расторжении рождаются из процесса, который уже зарегистрирован в заявке. Но подписание происходит вне её: кто-то экспортирует PDF, отправляет по почте, напоминает клиенту в WhatsApp и через несколько дней пытается вспомнить, куда сохранил подписанную версию. Стандартный GLPI хранит файл (вкладка «Документы», таблица glpi_documents) и связывает его с заявкой, но не имеет никакого понятия о подписи: не знает, кто должен подписать, подписал ли уже, и не хранит доказательный след. Когда кто-то спрашивает «этот договор подписан?», ответ по-прежнему — искать в почте и надеяться, что нужное вложение ещё там.

Стандартный GLPI и Digital Signature с Autentique

Стоит разделить то, что GLPI делает сам, и то, что добавляет интеграция. Ядро GLPI отлично прикрепляет файлы и ведёт их версии, но электронная подпись никогда не входила в его задачи:

Как это работает

Модуль Digital Signature интегрирует GLPI с платформой электронной подписи Autentique (одним из четырёх провайдеров модуля, наряду с DocuSeal, DocuSign и TOTVS Assinatura Eletrônica) и собирает всё на вкладке Digital Signature внутри заявки. На основе уже прикреплённого документа вы формируете конверт для подписи, не переключаясь между системами:

• Отправка прямо из заявки — уже прикреплённый PDF уходит на подпись без копирования файлов между системами. Также можно отправить шаблон компании, заполненный данными заявки, наряд-заказ (с модулем Order Service) или PDF, загруженный на месте.
• Несколько подписантов с ролями — добавьте столько, сколько нужно, с разными действиями: Подписать, Утвердить, Засвидетельствовать, Признать или Подтвердить получение.
• Порядок подписания — определите, подписывают ли подписанты последовательно или одновременно, в соответствии с процессом организации.
• Отслеживание в реальном времени — статус каждого подписанта обновляется через вебхук, без обращения к панели Autentique.
• Скачивание подписанного документа — после последней подписи итоговый PDF доступен прямо в заявке.
• Дополнительная аутентификация — требование документа, удостоверяющего личность, и проверка по SMS, в зависимости от критичности документа и тарифа учётной записи.
• Режим sandbox — тестовая среда для проверки процесса без начисления оплаты на платформе.

Как модуль взаимодействует с Autentique

API Autentique построен на GraphQL. При отправке документа модуль формирует mutation, аналогичную этой, прикрепляя PDF из заявки и список подписантов с действием каждого:

# A API da Autentique é GraphQL. Ao enviar um documento do chamado,
# o módulo monta uma mutation como esta (o PDF vai anexado ao request):
mutation CriarDocumento($doc: DocumentInput!, $signers: [SignerInput!]!, $arquivo: Upload!) {
  createDocument(sandbox: false, document: $doc, signers: $signers, file: $arquivo) {
    id
    name
    signatures {
      public_id
      email
      action { name }
      link { short_link }
    }
  }
}

# Variáveis, montadas a partir da aba Assinatura Digital do chamado:
# {
#   "doc":     { "name": "Contrato de prestação de serviços - Chamado #1042" },
#   "signers": [
#     { "email": "[email protected]", "action": "SIGN"    },
#     { "email": "[email protected]",  "action": "APPROVE" }
#   ]
# }

Поле action напрямую соответствует ролям, которые вы выбираете на вкладке: SIGN (Подписать), APPROVE (Утвердить), SIGN_AS_A_WITNESS (Засвидетельствовать), RECOGNIZE (Признать) и ACKNOWLEDGE_RECEIPT (Подтвердить получение). Возвращаемый для каждой подписи public_id — это идентификатор, который связывает подписанта с заявкой в последующих событиях.

Вебхук и что мы узнали в ходе сопровождения

Отправка — только половина работы. Элемент, на котором держится прослеживаемость, — это вебхук: при каждом событии (подписал, утвердил, отклонил, просмотрел) Autentique отправляет POST в GLPI, и вкладка заявки обновляется сама. Эксплуатируя это у клиентов, мы уже потратили время на диагностику трёх нюансов:

• Самая частая ошибка не в GLPI, а в Autentique. Тот, кто забыл зарегистрировать URL вебхука в панели платформы, видит, что документ отправляется и подписывается как обычно, но статус так и не возвращается — и в поддержку приходит заявка «почему GLPI не показывает, что документ подписан?».
• Вебхуки повторяются. Если Autentique не получает быстрый ответ 200, она повторно отправляет то же событие. Без идемпотентности одно и то же «подписал» попадает в историю дважды. Поэтому обработка идентифицирует событие по public_id подписи, а не по порядку поступления.
• Организация документа. При записи подписанного PDF обратно в заявку, которая находится в дочерней организации, GLPI требует, чтобы документ принадлежал той же организации, что и заявка; иначе связь Document_Item молча не создаётся, и файл «подписан, но пропал». При записи итогового документа модуль наследует организацию заявки.

И перед выходом в продакшен мы всегда проверяем, что sandbox выключен. Если оставить его включённым, платформа принимает процесс, не создавая подписи с реальной юридической силой, — худший вид ложноположительного результата в юридическом процессе, потому что всё кажется рабочим, пока кому-то не понадобится действительный документ.

Как включить

1. Установите или обновите NexTool в вашем GLPI 11.
2. Откройте NexTool > Модули.
3. Включите модуль Digital Signature и на вкладке Интеграции — раздел Autentique.
4. Укажите токен API Autentique и секрет вебхука.
5. Зарегистрируйте URL вебхука в панели Autentique.
6. Прогоните один документ в режиме sandbox от начала до конца, прежде чем запускать в продакшене.

Кому подходит — и когда не использовать

Модуль подходит ИТ-отделам и операционным командам, которые управляют договорами на оказание услуг, условиями использования систем, разрешениями на доступ и любыми документами, требующими подписи с доказательной силой, — особенно тем, кто уже использует Autentique и хочет устранить разрыв между подписью и заявкой, из которой она возникла.

Когда не использовать:

• Если вам нужна только подпись на экране при очном обслуживании, без внешней платформы и без оплаты за документ, лучше подойдёт подпись на экране в модуле Order Service.
• Если документ требует квалифицированной подписи с сертификатом ICP-Brasil (A1/A3) — некоторые регулируемые акты этого требуют, — усиленной подписи может быть недостаточно; заранее проверьте юридическое требование. С платным тарифом Autentique модуль также может требовать, чтобы подписанты подписывали сертификатом ICP-Brasil (квалифицированная подпись).
• Если в компании стандартизирована другая платформа, проверьте, входит ли она в число тех, что модуль также поддерживает (DocuSeal, DocuSign и TOTVS Assinatura Eletrônica); за их пределами модуль неприменим.
• Если документ не возникает ни из какой записи GLPI (заявка, договор, актив, поставщик и другие), интеграция не даёт прослеживаемости, которая является её главной ценностью.

Совместимость

• GLPI: 11.0+
• Тариф: Лицензируемый
• Плагин: NexTool 6.16.0 или выше

Следующий шаг

Autentique — один из провайдеров модуля Digital Signature, входящего в NexTool — экосистему модулей для расширения GLPI без доработок кода. Свяжитесь с командой, чтобы получить демонстрацию для вашего сценария.

Проверено командой NexTool Solutions.