Конструктор документов: готовая платформа или своя разработка

Менеджер открывает пустой договор, копирует в него данные клиента из карточки, руками правит реквизиты и номер, сохраняет файл в общую папку. Через месяц уже никто не скажет, какая версия ушла заказчику и почему в одном из подписанных договоров стоит прошлогодняя цена. Конструктор документов снимает этот ручной труд: документ собирается из шаблона и данных, которые в компании уже есть. Остаётся один вопрос - покупать готовое, обходиться шаблонами внутри своей системы или заказывать разработку.

Коротко: документов немного и они типовые - хватает шаблонов и готового сервиса генерации. Если шаблонов много, поля берутся из CRM, а нужны свои правила нумерации и согласования - это отдельная разработка, и начинается она с перечня документов.

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

Что такое конструктор документов

Коротко: это связка «шаблон плюс данные плюс правила», которая на выходе даёт готовый документ. Текстовый редактор или папка с файлами - про другое.

Шаблон - это заготовка с местами под данные: договор, коммерческое предложение, счёт, акт, приложение. Он хранится отдельно от документа, и его можно поправить, не трогая уже выпущенные файлы. Данные подставляются из того, что в компании уже введено: название и реквизиты клиента - из справочника, сумма и состав - из сделки. Правила задают то, что при ручной сборке ломается чаще всего: нумерацию, дату, кто выпускает документ и кто согласует нестандартные условия. Готовый документ сохраняется с номером и привязкой к клиенту или сделке, и его находят поиском.

Отличие от папки с шаблонами простое. В папке лежит файл, который человек заполняет руками, и после сохранения уже не понять, что в нём меняли. Конструктор собирает документ из данных и фиксирует, из чего он собран.

Что решить до заказа

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

Приходить к подрядчику с фразой «хочу конструктор документов» рано. Разговор станет предметным, если у вас есть ответы на несколько вопросов.

1. Какие документы нужно собирать. Конкретный перечень: договор оказания услуг, счёт, акт, коммерческое предложение, дополнительное соглашение. «Все документы» - это не ответ. Разные документы могут требовать разной логики.
2. Откуда берутся значения для полей. Что уже есть в CRM или заявке, а что придётся вводить руками при сборке. Каждое поле имеет один источник - или его подтверждает человек.
3. Как нумеруются документы. Сквозная нумерация по годам, по подразделениям, с префиксом. Что происходит с номером, если документ удалили или перевыпустили.
4. Кто согласует нестандартное. Типовой договор уходит клиенту сразу, а условия с отсрочкой или штрафами должен кто-то проверить. Правило согласования закладывают в систему, иначе все документы пойдут в обход.
5. Как живут версии шаблонов. Кто имеет право менять шаблон, и что при этом происходит с уже выпущенными документами.
6. В каких форматах нужен выход. DOCX для правок, PDF для отправки, оба сразу. От формата зависит, кто сможет поправить документ после выпуска.
7. Что делать с уже существующими документами. Перетаскивать ли старые договоры в новую систему или начать с новых.

Ответы на эти семь вопросов подрядчик и берёт в оценку. По ним видно объём работ.

Готовый сервис, шаблоны в своей системе или своя разработка?

Коротко: типовые документы закрывает готовый сервис или встроенные шаблоны CRM. Свои правила, много шаблонов и данные из разных систем - это разработка.

Путей три, и они отличаются тем, сколько правил система берёт на себя.

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

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

Связку шаблонов с вашими данными и правилами делаем по фиксированной цене и сроку: заявка на сайте, состав работ и смета обычно за 24 часа.

Когда готовый сервис не подходит

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

Есть несколько признаков, при которых готовое решение честно не справится.

Свои правила. Нумерация со своим префиксом, скидка выше порога идёт на согласование, часть документов выпускается только после оплаты. Чем больше таких условий, тем меньше их помещается в готовый сервис.

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

Данные из нескольких источников. Цена и состав - из сделки, реквизиты - из справочника клиентов, условия - из отдельной таблицы. Готовый сервис обычно видит один источник.

Массовая генерация. Нужно выпустить сотню однотипных документов по списку клиентов - рассылка акций, типовые приложения. Ручная сборка тут не работает.

Документ уходит дальше в учёт. Выпущенный документ должен попасть в другую систему и стать основанием для платежа или отгрузки. Здесь начинается интеграция.

Что спросить у поставщика до покупки

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

Подписку потом не отменить задним числом, поэтому вопросы задают заранее.

1. Можно ли загрузить свой шаблон со своим оформлением, или только готовые формы сервиса.
2. Как сервис получает данные - из вашей CRM через интеграцию, импортом таблицы или вы вводите руками.
3. Кто задаёт правила нумерации: вы сами или сервис диктует свой формат.
4. Что происходит с выпущенным документом, если шаблон потом изменили. Открывается ли старый файл в прежнем виде.
5. Какие форматы на выходе и можно ли получить DOCX для правок, или сервис отдаёт только PDF.
6. Как работает согласование: есть ли роль проверяющего и журнал, кто что согласовал.
7. Что входит в поддержку и что считается сбоем. Ответ «напишите, разберёмся» - не ответ.
8. Как забрать свои данные, если решите уйти с сервиса. Документы и шаблоны нужно выгружать в понятном формате.

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

Откуда берутся данные для полей

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

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

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

Как не перезаписать старый документ и не потерять версию шаблона

Коротко: выпущенный документ неизменен, шаблон версионируется отдельно, право менять шаблон есть не у всех.

Две вещи ломают учёт документов тише всего.

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

Версия шаблона. Когда шаблонов десятки, нужна история: кто, когда и что менял. Иначе менеджер незаметно поправит условия в общем шаблоне, и следующий клиент получит договор с чужой скидкой. Право менять шаблон лучше дать одному-двум людям, а изменения записывать.

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

Подпись и персональные данные: что учесть

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

Два требования легко упустить, а потом переделывать.

Электронная подпись. Документ можно подписать простой, усиленной неквалифицированной или усиленной квалифицированной подписью, и для разных случаев подходит разная. С 1 сентября 2024 года сотрудник подписывает электронные документы от имени компании только со своей подписью и машиночитаемой доверенностью - файлом, который подтверждает его право подписи и передаётся вместе с документом. Без доверенности подпись сотрудника могут не признать. От вида подписи зависит и то, в каком формате собирать и хранить документ, поэтому это проговаривают с подрядчиком заранее.

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

Как принять работу у подрядчика

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

Приёмка проверяет, что система делает именно обещанное. Осмотра демонстрации недостаточно, поэтому идите по списку.

• Эталонный документ. Возьмите один документ и сравните сборку с эталоном, который подготовили заранее: поля, формулировки, оформление совпадают.
• Все поля заполнены. Ни одного пустого места, ни одного «X» или «__» в готовом файле.
• Данные верные. Сумма и реквизиты совпадают с данными системы. Память менеджера тут не источник.
• Старый документ неизменен. Поменяйте шаблон, откройте ранее выпущенный документ: он должен остаться прежним.
• Нумерация идёт по правилу. Выпустите несколько документов подряд и проверьте, что номера идут так, как задумано.
• Форматы на выходе. DOCX открывается и правится, PDF отправляется, оба содержат одно и то же.
• Нестандартный случай. Договор со скидкой выше порога уходит на согласование, прежде чем попасть к клиенту.
• Массовая генерация. Соберите документы по списку и убедитесь, что каждый получил свои данные, и ни один не получил чужие.

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

Что двигает смету

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

Цена конструктора складывается из нескольких частей, и понять, что двигает смету, полезно до разговора.

• Число шаблонов и их сложность. Один типовой договор и десять форм с приложениями - разный объём.
• Источники данных. Каждая система, из которой берутся поля, - отдельная интеграция и отдельная проверка.
• Свои правила. Чем больше нестандартных условий - согласований, порогов, исключений, - тем больше проектирования.
• Версии и права. История шаблонов, роли и журнал - часть работы, без которой система быстро расходится с реальностью.
• Подпись и форматы. Виды электронной подписи и набор выходных форматов тоже входят в объём.
• Обучение и запуск. Менеджеров нужно научить собирать документы, а старые - аккуратно перевести.

В ответе на заявку просите состав: какие документы входят, из каких систем берутся данные, что считается результатом. Одной суммы для проверки мало.

Частые ошибки

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

• Не назначают ответственного за систему. Шаблоны и правила нужно кому-то вести, иначе через месяц система устаревает.
• Забывают решить судьбу старых документов. Переносить весь архив дорого, а без правила «что делать с прежними договорами» менеджеры остаются в двух мирах.
• Не обучают менеджеров. Люди возвращаются к старой папке с шаблонами, потому что новая кнопка непривычна.
• Не договариваются о поддержке. Через полгода меняется форма договора - и непонятно, кто правит шаблон и сколько это стоит.
• Пробуют сразу на боевых документах. Новую сборку безопаснее обкатать на одном типе документов, а потом переносить остальные.

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

Источники

• ГОСТ Р 7.0.97-2025, организационно-распорядительная документация: требования к оформлению документов (приказ Росстандарта от 26.06.2025 № 622-ст, взамен ГОСТ Р 7.0.97-2016, действует с 18.08.2025) - карточка стандарта.
• Федеральный закон № 152-ФЗ «О персональных данных» - текст.
• Федеральный закон № 63-ФЗ «Об электронной подписи» - текст.
• Сервис ФНС России для создания и проверки машиночитаемой доверенности - сервис.
• ФНС России: с 1 сентября 2024 года представителям для подписания электронных документов нужны личная подпись и МЧД - разъяснение.
• Как устроен конструктор документов: определение и назначение - разбор.

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