Кейс: поиск и заказ запчастей у 5 поставщиков прямо из Битрикс24

Сеть автосервисов из 4 СТО в Санкт-Петербурге работает с 5 поставщиками автозапчастей. Раньше мастера и менеджеры вручную обходили 5 личных кабинетов и сверяли цены и сроки по каждому артикулу. Мы встроили поиск всех поставщиков прямо в карточку сделки Битрикс24 — с маршрутизацией по СТО, фильтрами и автозаказом.

Задача

У клиента 4 точки СТО. У каждой — свой набор аккаунтов в 5 системах поставщиков: Rossko, AutoEuro, EuroAuto, Berg и Автоконтинент. Это 20 личных кабинетов с разными ключами, адресами доставки и реквизитами.

Сделка в Битрикс24 — это работа по автомобилю клиента, заведённая на конкретного мастера. Мастер привязан к одному из СТО. Чтобы заказать деталь под ремонт, менеджер должен:

1. Найти артикул у каждого из 5 поставщиков и сравнить цены и сроки.
2. Понять, к какому СТО относится мастер сделки.
3. Зайти в нужный личный кабинет именно этого СТО, оформить заказ на правильный адрес и реквизиты.

В реальности это превращалось в 10–15 минут на каждую сделку, ошибки в выборе адреса доставки и регулярные двойные заказы — когда менеджер забывал, что уже отправил заявку, и оформлял повторно.

Что мешало

• 5 поставщиков с принципиально разными API: где-то SOAP, где-то REST/JSON, где-то Basic Auth, где-то Bearer token, у каждого — свой формат полей и ошибок.
• 20 пар «СТО × поставщик»: у одного и того же поставщика для каждого из 4 СТО — отдельный аккаунт со своими ключами, адресом и реквизитами.
• Ручной выбор аккаунта: ничто не подсказывало менеджеру, в какой кабинет заходить — приходилось помнить или сверяться с табличкой.
• Нет единого пространства поиска: сравнивать цены приходилось переключаясь между вкладками браузера.

Что сделали

Развернули локальное приложение Битрикс24 — отдельная вкладка в карточке сделки. Из неё менеджер делает всё в одном окне.

Поиск у 5 поставщиков из карточки сделки

Менеджер вводит артикул и одним запросом получает предложения сразу от всех поставщиков. Внутри приложение параллельно ходит:

• Rossko — SOAP-метод GetSearch, по найденному предложению дёргаем GetCheckout для оформления.
• AutoEuro — REST v2: сначала /search_brands/, затем /search_items/ по найденным парам бренд+код.
• EuroAuto — WHLS API с Bearer-токеном: /products/manufacturers/codes + /offers/products/manufacturers/{id}/{type}.
• Berg — REST POST /ordering/get_stock.json, авторизация через заголовок X-Berg-API-Key.
• Автоконтинент — REST v1 с Basic Auth: search/part и search/price.

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

Маршрутизация «Мастер → СТО»

Самое интересное — никаких ручных переключателей «откуда заказываем». Логика построена так:

1. В сделке есть пользовательское поле «Мастер» (привязка к смарт-процессу мастеров).
2. В отдельном смарт-процессе «Точки» каждое СТО привязано к списку своих мастеров.
3. Приложение по полю «Мастер» в сделке находит соответствующее СТО, подгружает его набор аккаунтов и адресов.
4. Поиск идёт только по аккаунтам этого СТО, а заказ оформляется на его реквизиты и адрес доставки.

Менеджер не выбирает «откуда» — это вычисляется автоматически. На уровне бэкенда дополнительно стоит проверка: даже если кто-то попытается оформить заказ через предложение другого СТО, бэкенд это поймает и отклонит. Защита от человеческой ошибки.

Фильтры, сортировка и пагинация

Один артикул может вернуть 200+ предложений (особенно у Rossko и AutoEuro). Чтобы не листать простыни, в UI:

• Фильтры по диапазону: цена «от–до», минимальное наличие, максимальный срок доставки в днях.
• Сортировка кликом по заголовку столбца: цена, наличие, срок — стрелки переключают направление.
• Пагинация: сначала показываем 20 предложений, дальше «Показать ещё 20» — корзина всегда близко.

Корзина и автозаказ

Менеджер кладёт нужные предложения в корзину прямо во вкладке. Когда нажимает «Оформить»:

• Заказы группируются по поставщикам.
• К каждому поставщику уходит запрос на оформление через его API: Rossko GetCheckout, AutoEuro /create_order/, EuroAuto POST /orders/offers/{offer_id}, Berg POST /ordering/place_order.json, Автоконтинент через корзину basket/add + basket/order.
• Адрес доставки, способ оплаты, реквизиты подставляются из конфига СТО — менеджер ничего не выбирает.
• Каждый успешный заказ фиксируется в смарт-процессе «Заказанные детали» и привязывается к сделке. История по сделке — на одном экране.

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

Что получилось

• Поиск артикула — секунды вместо 10–15 минут ручного обхода.
• Ноль ошибок «не тот аккаунт» и «не тот адрес» — СТО определяется по полю сделки, выбрать чужой невозможно.
• Двойные заказы исчезли: история заказов привязана к сделке, видна сразу.
• Прозрачная сравнимость: в одном списке предложения от 5 поставщиков с одинаковой структурой полей.
• Один интерфейс для менеджера — больше не нужно переключаться между 5 вкладками браузера и сверяться с табличкой «какой логин у какого СТО».

Стек и архитектура

• Локальное приложение Битрикс24 (вкладка CRM_DEAL_DETAIL_TAB), бэкенд на PHP, фронт — нативный JS без сборки.
• Интеграции: SOAP (Rossko), REST/JSON (AutoEuro, EuroAuto, Berg, Автоконтинент). Авторизация — кастомный заголовок, Basic Auth, Bearer-токен — у каждого своё, изолировано в отдельных адаптерах.
• Маршрутизация на уровне приложения: смарт-процесс «Точки» (entityTypeId 1062) хранит связки СТО ↔ мастера, поле «Мастер» в сделке используется как ключ.
• Заказы пишутся в отдельный смарт-процесс «Заказанные детали», который привязан к сделке.
• Конфиги аккаунтов (ключи, адреса, реквизиты) лежат на сервере в отдельном файле, не уходят в Git.

Что под капотом для каждого поставщика

Где ещё это работает

Подход переносится на любую сферу, где у бизнеса есть несколько поставщиков с API и несколько точек/филиалов с разными аккаунтами:

• Сети автосервисов, СТО, шинных центров.
• Розница автозапчастей с несколькими точками.
• Дистрибьюторские сети с несколькими складами.
• Сервисные компании, у которых каждый филиал работает с собственным набором подрядчиков.
• Любая мультибрендовая закупка, где менеджер вынужден держать в голове 5–10 личных кабинетов.

Главный приём — не интегрировать каждого поставщика отдельной кнопкой, а свести их в единый список предложений, и автоматизировать выбор аккаунта/адреса по контексту сделки. Менеджер видит «деталь» — и не должен думать, у кого она лежит и в каком кабинете её заказать.