Beton CRM: приложение для заявок на бетонном заводе с интеграцией Bitrix24 и 1С

Исходная задача

На проекте уже была самописная 1С, в которой вели управленческий контур и производство. Параллельно начали внедрять Bitrix24, чтобы менеджеры не работали напрямую в 1С и оформляли заявки в CRM.

На первом этапе настроили интеграцию между Bitrix24 и 1С: контрагенты и номенклатура подтягивались в CRM, а заявки после проверки оператором уходили в 1С на производство.

Где начались сложности

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

• клиент;
• завод;
• дилер.

При этом каталог по сути был общий, но сценарии отличались. Одни позиции совпадали, другие зависели от типа заявки, доставки и сопутствующих товаров. В Bitrix24 это нельзя было аккуратно показать типовыми средствами.

Дополнительно возникла вторая проблема: менеджеры и дилеры продолжали дублировать работу. Заявка оформлялась в Bitrix24, а потом та же информация отдельно отправлялась в чаты и мессенджеры, чтобы завод точно увидел заказ и подтвердил его.

Почему стандартный сценарий не подошёл

Для офисных сотрудников этот процесс ещё можно было терпеть. Но для дилеров и менеджеров, которые работают с объекта, мобильный сценарий оказался неудобным.

Под нужды проекта в Bitrix24 был добавлен кастомный тип поля для выбора номенклатуры. На десктопе он работал, а в мобильной версии Bitrix24 не отображался. В результате именно та часть интерфейса, которая была критична для оформления заявки, оказывалась недоступной на телефоне.

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

Что сделали

Вместо попытки дальше усложнять интерфейс Bitrix24 разработали отдельное веб-приложение для менеджеров и дилеров. Оно стало внешним рабочим контуром вокруг Bitrix24 и 1С.

Стек проекта:

• FastAPI;
• Vue;
• PostgreSQL.

Как устроили работу с формами

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

Это позволило не зашивать каждое изменение в код и упростило дальнейшую донастройку со стороны клиента.

Как решили поиск по контрагентам и номенклатуре

Сначала поиск работал напрямую через API Bitrix24. Для первой итерации этого хватало, но под нагрузкой такой сценарий начал тормозить и слишком зависел от внешнего сервиса.

Поэтому поиск вынесли в локальный контур. Подключили Elasticsearch и настроили регламентное обновление данных примерно каждые 20-30 минут. После этого поиск по контрагентам, номенклатуре и истории заявок стал работать локально и заметно быстрее.

Как выстроили процесс обработки заявки

После оформления в приложении заявка создаётся в Bitrix24 на стадии квалификации. Оператор получает задачу, проверяет состав заявки и после подтверждения переводит её дальше в производство. Затем данные уходят в 1С.

Если в заявке происходят изменения, система снова возвращает её на проверку и создаёт новую задачу оператору. При этом оператор видит не просто факт изменения, а конкретно что именно было изменено. Это сокращает ручную проверку и убирает необходимость повторно просматривать всю заявку.

Что ещё добавили

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

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

Что получили в итоге

В проекте сформировались три синхронизированных контура:

• 1С;
• Bitrix24;
• отдельное приложение для оформления и отслеживания заявок.

Такой подход позволил разделить роли и при этом сохранить связанность процессов между CRM, приложением и производственным контуром.

Практический эффект для бизнеса

• Убрали чаты и мессенджеры как основной рабочий канал согласования заявок.
• Дали дилерам и менеджерам нормальный мобильный сценарий оформления заказа с телефона.
• Сократили ручную валидацию заявок с 6 операторов до 2.
• Упростили настройку форм за счёт редактора и привязки к полям Bitrix24.
• Сделали изменения в заявках прозрачными для операторов, чтобы не проверять весь документ заново.
• Добавили сценарий периодических заявок для клиентов с регулярными отгрузками.

Что важно отметить

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

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