Этот текст написан в Сообществе, в нем сохранены авторский стиль и орфография
Компания ProSMD поставляет оборудование для автоматизации монтажа печатных плат. Когда количество коммерческих предложений стало расти, менеджеры столкнулись с рутинной задачей: каждый документ приходилось собирать вручную.
Для простого товара достаточно указать название и цену, но в случае с промышленным оборудованием клиенту нужны технические характеристики, описание возможностей, дополнительные материалы и условия поставки.
О Сообщнике Про
SEO в диджитал-агентстве. Специализируюсь на комплексном продвижении: от тех. аудитов и семантики до стратегий роста. Провожу кластеризацию, готовлю ТЗ и линкбилдинг.
Это новый раздел Журнала, где можно пройти верификацию и вести свой профессиональный блог.
До автоматизации менеджеры собирали такие предложения вручную в PowerPoint. Характеристики переносили из каталога, затем правили описание, добавляли таблицы и прикладывали счет. Для того чтобы создать коммерческое предложение, могло уйти несколько часов.
У этого процесса была еще одна проблема: характеристики оборудования формируют инженеры, и менеджеру не нужно их редактировать. При ручной сборке всегда остается риск случайно изменить цифру или перенести в предложение устаревшие данные.
Мы решили перенести весь процесс в административную часть сайта на «1С-Битрикс»: менеджер выбирает оборудование из каталога, добавляет информацию для конкретного клиента и получает готовое коммерческое предложение в едином формате.
Почему мы не взяли готовый модуль для разработки коммерческих предложений в «1С-Битрикс»
Сначала мы посмотрели существующие решения для коммерческих предложений.
Для простого интернет-магазина их возможностей обычно достаточно: выбрать товар, цену, количество и получить документ. В нашем случае структура была сложнее.
Нам нужно было одновременно решить несколько задач:
- брать характеристики оборудования непосредственно из каталога и запрещать менеджеру их изменять;
- оставлять возможность дописывать индивидуальное описание товара;
- добавлять к предложению таблицу сертификации с произвольными столбцами;
- прикреплять готовый счет;
- разграничивать права менеджера и администратора;
- формировать публичную страницу предложения;
- получать PDF, который повторяет содержимое этой страницы;
- сохранять старые предложения и при необходимости копировать их.
Попытка приспособить типовой модуль под эту структуру потребовала бы большого количества переделок. Поэтому мы решили сделать отдельный модуль под конкретный бизнес-процесс.
Сначала повторили привычный сценарий менеджера по заполнению КП
Одна из ошибок в автоматизации — заставить сотрудника работать так, как удобно системе. Мы старались сделать наоборот: сначала разобрали существующую последовательность действий, а затем перенесли ее в интерфейс.
Менеджер начинает с каталога оборудования и отмечает позиции, которые должны войти в предложение. После выбора они попадают в отдельный список, где можно изменить порядок или удалить лишнее.

После выбора товаров менеджер переходит к заполнению самого предложения. Мы разделили форму на несколько блоков, потому что данные внутри документа имеют разное происхождение.
Часть информации в КП мы вообще запретили редактировать
Первый блок — данные самого менеджера. Имя, телефон и электронная почта подставляются автоматически. Рядом указывается компания, для которой готовится предложение.
Дальше идут общие данные документа: заголовок, описание и условия. Здесь мы оставили HTML-редактор Bitrix, чтобы можно было создавать списки, ссылки и обычное форматирование текста прямо в административной панели.
Самая важная часть — товары.
Название, изображение, ссылка и технические характеристики автоматически подтягиваются из карточки оборудования в каталоге. Эти характеристики менеджер изменить не может.
Логика здесь простая: если инженер уже внес в каталог правильную мощность, размеры или другие параметры оборудования, нет смысла заново переписывать их в коммерческое предложение. Чем меньше ручного переноса данных, тем меньше вероятность ошибки.
При этом индивидуальное описание мы оставили редактируемым. Для одного заказчика может быть важно сделать акцент на производительности, для другого — на конкретном сценарии применения оборудования.

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


В конце менеджер прикладывает счет и дополнительный текст
Последний блок нужен для информации, которая относится именно к этой сделке: условий оплаты, сроков поставки или других договоренностей.
Туда же можно прикрепить счет в PDF.
После сохранения коммерческое предложение появляется в общем списке. Его можно снова открыть, отредактировать или использовать как основу для нового документа.
Последний вариант оказался важным на практике. Если два клиента интересуются похожим комплектом оборудования, менеджеру не приходится заново собирать весь документ. Он копирует существующее предложение и меняет только нужные части.
Почему мы не стали хранить все предложение одной большой записью
На этом этапе появилась архитектурная проблема.
Коммерческое предложение состоит из нескольких сущностей:
- клиента;
- менеджера;
- общих текстовых блоков;
- выбранных товаров;
- индивидуальных описаний этих товаров;
- характеристик;
- сравнительной таблицы;
- вложений;
- публичной ссылки;
- PDF-версии.
Можно было сохранить все это одним большим набором данных. Для первой версии это было бы быстрее, но дальше такую структуру сложнее поддерживать.
Поэтому для хранения использовали highload-блоки Bitrix.
Само коммерческое предложение хранится отдельно, а входящие в него товары — в связанном highload-блоке. Благодаря этому одно предложение может содержать несколько товарных позиций, и у каждой остаются собственные данные.
Так мы разделили основную сущность и ее состав.
Для нас это было одним из самых важных решений в проекте. Интерфейс можно переделать сравнительно быстро. Ошибочная структура данных начинает мешать каждый раз, когда появляется новая функция.
Для каждого предложения сделали отдельную публичную ссылку
После сохранения система создает для документа уникальную публичную страницу.
На ней отображаются:
- данные менеджера;
- информация о клиенте;
- заголовок и описание;
- выбранное оборудование;
- индивидуальные описания;
- технические характеристики;
- сравнительная таблица;
- дополнительные материалы;
- прикрепленный файл.
Менеджеру остается отправить клиенту ссылку.
Это удобно в ситуациях, когда человек не хочет получать очередное вложение по почте или нужно быстро посмотреть предложение с телефона.
При этом возможность получить обычный документ мы тоже сохранили.

С PDF оказалось сложнее, чем с обычной страницей
Отдельно пришлось реализовать генерацию PDF.
На первый взгляд задача выглядит просто: есть HTML-страница — нужно сохранить ее как документ. Но итоговый файл должен корректно воспроизводить довольно сложную структуру: товары, изображения, таблицы характеристик, текстовые блоки и дополнительную информацию.
Кроме того, к коммерческому предложению иногда уже прикреплен отдельный PDF со счетом.
В таком случае система добавляет страницы счета внутрь итогового документа. Если вложение имеет другой формат, оно остается отдельным вложением или ссылкой.
В итоге у клиента есть несколько вариантов: открыть публичную страницу, скачать PDF или распечатать документ.
Менеджерам не нужен доступ ко всей административной панели
Еще одна задача возникла из-за того, что модуль находится внутри административной части сайта.
Обычному менеджеру совершенно не нужны настройки сайта, инфоблоки и технические разделы Bitrix. Чем больше элементов он видит, тем выше вероятность случайно изменить то, что менять не нужно.
Поэтому мы ограничили интерфейс для этой роли.
Менеджер видит только раздел, связанный с коммерческими предложениями. Администратор при этом сохраняет полный доступ ко всему сайту.
По сути, внутри стандартной административной панели получился небольшой специализированный кабинет.
Это решение оказалось полезно не только с точки зрения безопасности. Интерфейс стал проще: сотруднику не приходится каждый раз искать нужный пункт среди десятков технических разделов.
Самое сложное — архитектура проекта
Основная сложность проекта была в архитектуре.
Во время создания предложения есть временные данные: например, подборка товаров, которую менеджер еще меняет.
После сохранения появляются постоянные сущности: само предложение, связанные с ним товары, индивидуальные описания, таблица, вложения и публичная версия.
К этому добавляются генерация PDF и ограничения доступа.
Нам нужно было определить, какие данные можно получать из каталога каждый раз, какие нужно сохранять внутри предложения и что произойдет, если через месяц характеристика товара в каталоге изменится.
Отдельного внимания потребовал PDF: его структура должна соответствовать публичной версии и корректно работать с таблицами, изображениями и прикрепленным счетом.
Именно здесь большая часть работы была связана уже не с внешним видом формы, а с тем, как разные части системы связаны между собой.
Что изменилось после запуска
После внедрения менеджеру больше не нужно собирать коммерческое предложение в PowerPoint и вручную переносить характеристики оборудования.
Теперь процесс выглядит так:
- менеджер выбирает товары из каталога;
- система подтягивает характеристики;
- менеджер добавляет информацию для конкретного заказчика;
- при необходимости формирует сравнительную таблицу;
- прикрепляет счет;
- сохраняет документ;
- отправляет клиенту ссылку или PDF.
Подготовка одного предложения, которая раньше занимала несколько часов, сократилась до нескольких минут.
Все документы теперь собираются в одном формате, а характеристики берутся непосредственно из каталога. Сохраненное предложение можно скопировать и быстро адаптировать под другого заказчика.
Главный вывод из этого проекта для нас — автоматизировать стоит сам процесс, а не только финальную операцию «сделать PDF». Если бы мы просто автоматизировали верстку документа, менеджеру все равно пришлось бы вручную собирать характеристики, искать товары и переносить данные.
В нашем случае основную экономию времени дала связка каталога, структуры предложения, хранения данных и генерации готового документа.












