Кнопка «создать договор» выглядит простой: взять клиента, сумму и товары, подставить в шаблон. Сложности начинаются, когда у клиента несколько юридических лиц, подписывает другой человек, а в карточке остались реквизиты прошлого счёта. Автоматизация ускорит и правильное действие, и ошибку. Поэтому проектировать нужно не только создание файла, но и условия, при которых оно разрешено.
Ниже — практическая схема для Битрикс24. Она помогает отделить возможности генератора документов от дополнительных проверок и обработки данных, которые могут потребовать настройки либо отдельного приложения.
Какие данные нельзя выбирать по принципу «первое найденное» #
Контакт, компания и реквизиты выполняют разные роли. Контакт может быть менеджером закупок, но не подписантом. У организации могут быть несколько банковских счетов. Собственная компания продавца тоже выбирается отдельно: один портал иногда обслуживает несколько юридических лиц.
Перед генерацией определяют обе стороны, применяемые реквизиты, подписанта, основание его полномочий и шаблон. Если однозначного выбора нет, интерфейс должен попросить сотрудника принять решение. Подставлять случайный связанный контакт опасно, даже если его ФИО записано полностью.
Полезно составить карту источников: откуда берутся название, ИНН, адрес, банковские сведения, должность и сумма. Для каждого поля указывают обязательность и правило проверки. Так становится видно, какие данные CRM уже хранит, а каких в рабочем процессе вообще не собирают.
Когда достаточно штатного генератора #
Если нужные значения есть в CRM и логика шаблона покрывает документ, начинают со штатных возможностей. Не стоит создавать внешний сервис только ради переноса пары полей. Сначала проверяют шаблон на нескольких сделках и выясняют, какие ограничения действительно мешают.
Для программного создания предусмотрен crm.documentgenerator.document.add : документ формируется по шаблону для выбранного CRM-объекта. Дополнительные значения передаются предусмотренными параметрами; состав доступных полей нужно проверять для конкретного документа. Методы и порядок работы описаны в официальной документации .
Отдельная обработка появляется, когда требуется сложное преобразование данных, нестандартная таблица или согласование нескольких источников. Но результат такой обработки не следует считать юридически проверенным текстом. Формулировки договора и применимость шаблона утверждаются ответственными специалистами компании.
Склонение ФИО: небольшая функция с заметными исключениями #
Для оборота «в лице» может понадобиться другая форма имени, чем для адресного блока. Исходное ФИО при этом должно оставаться неизменным. Лучше хранить или вычислять производные формы отдельно, иначе исправление одной фразы испортит карточку контакта и другие документы.
Алгоритм должен учитывать неоднозначные и несклоняемые имена. Если результат нельзя определить уверенно, сотрудник видит исходную запись и предложенную форму, а затем подтверждает её или исправляет. Важно различать исправление данных человека и разовую редактуру конкретного документа.
Для проверки собирают примеры, характерные для клиентской базы: составные фамилии, отсутствие отчества, иностранные имена, инициалы и ошибки в исходной записи. Успешный тест на одном типовом ФИО ничего не говорит о работе на остальных данных. Если используется внешний сервис, отдельно определяют, какие сведения ему передаются.
Сумма прописью и расчётные значения #
Сумму для документа берут из утверждённого расчёта. Если приложение отдельно пересчитывает товары, а CRM показывает другой итог, сотрудник не сможет понять, какое значение отправится в договор. Нужно определить единый источник и правила округления.
Валюта, копейки, скидки и налоговые параметры должны обрабатываться явно. Не следует копировать из примера одну ставку и использовать её для всех организаций. Правила расчёта предоставляет и утверждает заказчик; приложение воспроизводит их на согласованных контрольных примерах.
Проверка связывает числовую сумму, её текстовое представление и валюту. Изменение цены после согласования должно создавать основание для новой версии, а не менять только цифры, оставляя старую пропись. Это особенно важно, когда документ содержит сумму в нескольких местах.
Почему перед генерацией нужна проверка готовности #
Обязательное поле в карточке — полезный, но недостаточный механизм. Поле может быть заполнено пробелом, устаревшими сведениями или значением из другой организации. Перед созданием файла проверяют именно условия выбранного вида договора.
- — Определены стороны и нужные реквизиты каждой из них.
- — Выбран подписант и заполнены необходимые сведения о нём.
- — Согласованы состав, сумма и условия, используемые в документе.
- — Выбрана действующая версия шаблона для этого сценария.
- — Нет неразрешённых ошибок преобразования данных.
Сообщение об отказе должно подсказывать действие: «выберите банковский счёт покупателя» или «подтвердите форму ФИО». Если можно продолжить с предупреждением, такое решение фиксируется отдельно, вместе с ответственным. Прятать исключение в техническом журнале неудобно для сотрудника, который готовит договор.
Версия договора и последующие изменения сделки #
Созданный документ связан с состоянием данных на момент генерации. После отправки клиенту это особенно важно: изменение адреса в справочнике не должно лишать компанию возможности восстановить, какие сведения стояли в конкретном договоре.
Для процесса сохраняют идентификатор документа, версию шаблона, существенные исходные значения и статус согласования. Если сделка изменилась, система показывает, какие данные разошлись. Новый документ не подменяет старый без понятного действия пользователя и истории.
Генерация файла, внутреннее согласование и подписание — разные этапы. Если требуется работа с замечаниями, версиями и маршрутами, полезно отдельно спроектировать автоматизацию согласования договоров . Одна кнопка формирования DOCX или PDF не закрывает весь процесс.
Как проверить результат на пилоте #
Берут несколько договоров с разными сторонами и условиями. Для каждого сравнивают исходные значения, сформированный файл и ожидаемый результат. Проверяют длинные названия, пустые необязательные поля, переносы строк и таблицы на нескольких страницах.
Затем проверяют исключения: нет подписанта, есть два набора реквизитов, сделка изменилась во время подготовки, сотрудник нажал кнопку повторно. Наконец, открывают старый документ после изменения карточки компании. Приёмка должна подтвердить и содержание, и возможность объяснить происхождение файла.
Поможем настроить подготовку договоров из сделки #
Если реквизиты приходится переносить вручную и каждый договор проверяется заново, обратитесь в NetLab. Разберём ваши шаблоны, источники реквизитов и порядок согласования, поможем настроить формирование документов в Битрикс24 и проверку данных перед отправкой. Обсудить автоматизацию договоров .
