Маршрутизация · практический гайд
Маршрутизация договоров, КП, счетов и спецификаций
Как построить маршруты договоров, коммерческих предложений, счетов и спецификаций: вход, роли, версии, ИИ-проверки, SLA и решение человека.
Короткий ответ
Маршрутизация документов — это набор правил, который связывает событие на входе, вид и версию документа, обязательные проверки, ответственные роли, сроки и финальное решение. Для договора, КП, счёта и спецификации нужны разные ветви, но они могут работать в одном процессном контуре и обмениваться статусами с действующими системами.
01
Почему одного универсального маршрута недостаточно
У договора, коммерческого предложения, счёта и спецификации разная бизнес-цель. Договор фиксирует обязательства, КП — предлагаемые условия, спецификация — состав поставки или работ, счёт — основание и сумму платежа. Одинаковая цепочка согласующих либо создаёт лишние этапы, либо пропускает важную проверку.
Общим должен быть не список участников, а способ управления процессом: документ получает устойчивый идентификатор, версия связывается с решениями, этап имеет владельца и SLA, а возврат содержит причину и следующий шаг.
- тип документа определяет шаблон и обязательные поля;
- сумма, отклонение или риск подключают дополнительные роли;
- новая версия запускает только необходимые повторные проверки;
- финальный статус возвращается в систему-источник.
02
Чем различаются маршруты четырёх документов
Для договора важны версия текста, юридические замечания, полномочия и связь с будущим подписанием. Для КП — цена, скидка, срок действия и возврат результата в сделку. Для счёта — комплектность основания, реквизиты, сумма и готовность к оплате. Для спецификации — связь с договором, позиции, объёмы и согласованная редакция.
Маршрут строится от финального решения назад. Сначала определяется, какой статус нужен бизнесу и кто имеет право его подтвердить. Затем добавляются обязательные данные, проверки и условия, при которых подключается каждая роль.
03
Как связать документы в один управляемый комплект
Документы одного обязательства не должны существовать как независимые файлы. Счёт можно связать с договором и актуальной спецификацией, а КП — со сделкой и версией условий, на основе которой появился договор. Связь хранит идентификаторы и источники значений, а не только названия файлов.
ИИ может извлечь сумму, даты, реквизиты и позиции, затем показать расхождения между связанными документами. Если значение критично, человек видит оба источника и подтверждает допустимость. Переопределение автоматической проверки остаётся в журнале.
- идентификатор исходного процесса или сделки;
- связи между договором, КП, счётом и спецификацией;
- актуальная версия каждого документа;
- источник и владелец критичного значения.
04
Как спроектировать первый маршрут и проверить результат
Для пилота выбирают один тип документа и один наблюдаемый поток. Команда описывает фактический вход, роли, исключения, причины возврата и момент финального решения. До настройки фиксируются исходное время цикла, доля нарушенных SLA, число версий и ручных вопросов о статусе.
Пилот должен пройти не только идеальный сценарий, но и неполный комплект, новую версию, отказ участника и временную ошибку интеграции. Масштабирование на другие документы начинается после того, как результат измерен на сопоставимом объёме и владельцы процесса приняли новый порядок работы.
Сравнение
Что меняется по типу документа
| Документ | Ключевая проверка | Типовые роли | Финальный результат |
|---|---|---|---|
| Договор | Версия, реквизиты и отклонения условий | Инициатор, юрист, финансы, руководитель | Согласованная версия для подписания |
| Коммерческое предложение | Цена, скидка и срок действия | Продажи, финансы, руководитель | Версия, готовая к отправке клиенту |
| Счёт | Основание, сумма, реквизиты и комплектность | Инициатор, финансы, бюджетный владелец | Подтверждённая готовность к оплате |
| Спецификация | Позиции, объёмы и связь с договором | Инициатор, операционная и финансовая роли | Согласованная редакция комплекта |
Контекст продукта
Версия, источник и связанные данные
Роли, сроки, возвраты и правила
Подтверждение человека и журнал
Частые вопросы
Коротко о спорных местах.
Нужно ли делать отдельную систему для каждого вида документа?
Нет. В одном процессном контуре можно использовать разные шаблоны маршрутов, наборы полей и правила подключения ролей. Общими остаются версии, SLA, журнал и модель полномочий.
Можно ли запускать юридическую и финансовую проверки параллельно?
Да, если их решения независимы и заранее определено, как объединяется результат, что происходит при возврате и какие проверки повторяются после новой версии.
ИИ сам выбирает согласующих?
ИИ может предложить тип документа и извлечь значения для правила, но список ролей, пороги и полномочия утверждает компания. Спорный случай направляется человеку.
Как не дублировать документы между АА.Докс, CRM и ERP?
Нужно заранее определить систему-источник для файла и каждого справочника, использовать устойчивые идентификаторы и возвращать ссылку со статусом вместо неконтролируемых копий.
Методика и границы
Материал описывает проектный подход АА.Докс и не является юридической консультацией или универсальным регламентом. Термины на рынке пересекаются; окончательные роли, требования к подписи, хранению и безопасности определяются процессом и правилами конкретной компании.
Продолжить чтение