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

В системе согласования документов одобрение должно относиться к тому комплекту, который видел согласующий. Если после его решения заменили файл, новый комплект ждёт согласования. Агенты могут дописать это правило в коде, но сначала владелец процесса должен определить, какие изменения создают новую версию.

Связку Яндекс Диска со сделкой проверяют по версии файла и правам доступа.

Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.

Своего клиентского кейса такой доработки у нас нет. Ниже приёмочный пример с версиями А и Б, требования к коду и опыт разработки нашей машины агентов. Это способ проверить заказ, а не обещание экономии отдела.

В приёмочном примере руководитель одобрил версию А договора. Затем автор поменял сумму и загрузил файл под прежним именем. Если карточка всё ещё показывает «согласовано» и разрешает отправку, система переносит решение на содержимое, которого руководитель не видел.

Поэтому доработка начинается с предмета согласования: основной файл, приложения и значимые поля карточки. Такой комплект получает неизменяемый идентификатор версии. Нельзя переписать содержимое А на месте и сохранить её идентификатор: тогда ссылка в старом решении станет ложной.

Это не новая функция для всего рынка. В официальной справке ELMA описан выбор версии при отправке на согласование; Согласиум описывает хранение файлов и версий. Заказывая код, сначала проверьте, умеет ли ваша действующая система связать решение с комплектом и запретить его незаметную подмену.

В нашем примере после изменения суммы появляется версия Б. Решение руководителя по А остаётся в истории, но не даёт права отправить Б. Пользователь видит причину повторного согласования и различия между комплектами, а не просто исчезнувшую зелёную отметку.

Проверять версию нужно и при принятии решения. Согласующий мог открыть А, уйти на встречу и нажать «одобрить», когда уже появилась Б. Сервер должен отклонить запоздалую попытку с объяснением: комплект изменился, откройте текущую версию.

Перед отправкой проверка повторяется: все необходимые решения относятся к отправляемому комплекту. Система фиксирует именно этот комплект для передачи, чтобы между проверкой и отправкой не подменили файлы. Выключенная кнопка в интерфейсе не защищает от другого приложения или прямого запроса к серверу.

Отсутствие согласующего не должно превращать маршрут в тупик. Но фразы «у заместителя те же права» недостаточно: нужны основание замещения, срок и область полномочий. Разрешение согласовать один тип документов не обязано распространяться на остальные.

В предлагаемой доработке сохраняются фактический участник и тот, кого он замещает. Если срок полномочий истёк до нажатия кнопки, сервер не принимает решение. Уведомление, пришедшее вчера, не продлевает доступ сегодня.

Уже принятое решение заместителя не стирают, когда основной участник вернулся. Его судьбу определяет записанное правило процесса: например, действительное на момент решения одобрение сохраняется, а будущие задачи возвращаются основному участнику. Передача роли сама по себе не создаёт одобрения новой версии.

В задаче для агента лучше описать событие и ожидаемый результат: «После замены приложения создаётся новая версия, отправка ждёт повторного согласования». Просьба «сделать систему согласования с ИИ» оставляет без ответа, что покупать и как это принимать.

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

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

Приёмка должна включать отказ, который система обязана выдать. В примере с А и Б недостаточно увидеть, что кнопка поменяла цвет. Приёмщик пытается отправить Б со старыми решениями, а система объясняет отказ и сохраняет след попытки.

Разработчик предъявляет воспроизводимые проверки, а заказчик подтверждает бизнес-правило на тех же вымышленных документах. Повторный щелчок не создаёт второе решение; отзыв полномочия закрывает следующую попытку; изменение обязательных участников не оставляет старый маршрут разрешением на новый.

Так граница ответственности за ошибки становится предметной: владелец утвердил правило, инженер реализовал его, приёмщик проверил нарушение. Нужны код, сценарии и результат проверки, а не только заверение агента «всё готово».

На карте нашей машины видно, как связаны правила, задачи, код, проверки и выпуск vibecoding.ru. Инженер принимает работу агентов. Это доказательство того, что у разработки есть управляемый процесс; клиентского результата согласования эта карта не показывает.

В нашей машине случались ошибки на той же границе разрешений и проверок. Агент мог прочитать разрешение на бриф как разрешение на отдельный шаг; зелёная проверка могла не охватывать фактический ответ сервера. Такие записи полезнее обещания, что агент всегда правильно поймёт инструкцию.

Урок «Одиннадцать шагов одной задачи» в курсе агентной разработки посвящён процессу выполнения задачи. Переносить в согласование нужно принцип: правило задаётся явно, результат проверяется, выпуск имеет свою приёмку. Скорость работы отдела после такой доработки пока остаётся вопросом для замера.

Наличие проблемы ещё не означает, что нужна новая СЭД. Попросите ответственного показать в действующей системе пример А и Б: какую версию видел участник, что случилось после правки и какой файл разрешено отправить. Если всё решается настройкой маршрута и прав, отдельная разработка может не понадобиться.

Если правило отсутствует, предмет заказа можно ограничить: версии комплекта, связь решений с версией, замещение и повторное согласование. Для старых записей без известной версии заранее задают порядок перехода. Нельзя молча пометить все текущие файлы одобренными, потому что у карточек сохранился прежний статус.

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

Если нужно обсудить маршрут согласования, следующий шаг ведёт к услугам и записи на звонок. Подготовьте вымышленные версии А и Б, описание текущей системы и правило, которое она сейчас нарушает. Так разговор начнётся с проверяемой доработки.

Подписка «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Это цена подписки на один продукт и один поток работы, не расчёт полной стоимости системы согласования. Объём кода маршрута с фиксацией версии, замещением и повторным одобрением после правки уточняют по действующей системе; распознавание документов и юридические советы в этот заказ не входят.

Принимайте результат по примеру из начала статьи: после изменения А появилась Б, старое решение осталось в истории, а Б нельзя отправить до нового согласования. Затем проверьте замещение и попытку из старой вкладки. Если это воспроизводится, вы купили работающие ограничения, а не только новый экран.

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

2. После правки создавайте новую версию. Старое одобрение сохраняйте в истории и не переносите на новый комплект автоматически.

3. Для замещения задайте основание, область и срок. Записывайте имя того, кто фактически принял решение.

4. Принимайте доработку попыткой отправить изменённый комплект со старыми решениями. Проверьте также старую вкладку и истёкшие полномочия.

5. После выпуска наблюдайте отказы отправки и ожидания повторного решения. Возвращайте эти данные владельцу процесса для уточнения правил.