Интеграция 1С-Битрикс с сервисами оптимизации маршрутов

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Интеграция 1С-Битрикс с сервисами оптимизации маршрутов
Средний
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    830
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1075

Каждый день диспетчер тратит 2-3 часа на ручное планирование маршрутов. Курьеры не успевают доставить все заказы в срок, повторные выезды увеличивают расходы на топливо. Интеграция 1С-Битрикс с API сервисов оптимизации маршрутов решает эти проблемы: алгоритмы находят оптимальный маршрут за секунды, учитывая пробки, временные окна и загрузку автомобиля. Наша команда выполнила 30+ таких интеграций для бизнеса от 1 до 100 машин. Опыт показывает, что после внедрения время планирования сокращается до 10 минут, а пробег — на 15-25%. Гарантируем стабильную работу интеграции на всех этапах.

Задача оптимизации маршрутов (Vehicle Routing Problem, VRP) — NP-трудная, согласно Wikipedia. На практике справляются коммерческие сервисы: Яндекс.Маршрутизация, Route4Me, Routific, OptimoRoute. Они обрабатывают 10 000 точек за секунды — в 10 раз быстрее самописных решений. Бесплатный OR-Tools от Google тоже даёт отличные результаты. Мы интегрируем любой из них в вашу CRM на Битрикс через универсальный адаптер. Сертифицированные инженеры подберут подходящий сервис под ваш бюджет.

Проблемы, которые решаем

  • Долгое ручное планирование: логист тратит 2-3 часа утром. Автоматизация сокращает это до 10 минут.
  • Перегруженные маршруты: без оптимизации курьер проезжает лишние 50 км в день. Оптимизатор снижает пробег на 15-25%, экономя затраты на топливо.
  • Ошибки геокодирования: если адрес не преобразован в координаты, машина едет не туда. Мы геокодируем при импорте заказа, используя свежие базы.

Экономия времени диспетчера — 2 часа в день. Снижение затрат на логистику — до 25%.

Как выбрать сервис оптимизации под бизнес?

Сервис Особенности Модель оплаты
Яндекс.Маршрутизация Российская инфраструктура, хорошая геокодинговая база Запросы + склад курьеров
Route4Me Гибкий API, временные окна, мультидепо Подписка
Routific Простое API, подходит для малого автопарка Подписка от 5 машин
OptimoRoute Приоритеты, компетенции водителей Подписка
OR-Tools Бесплатный, self-hosted, требует Python-сервер Свои серверы

Выбор зависит от числа машин и объёма заказов. Для 1-3 машин — Routific или Яндекс, для 10+ — Route4Me с мультидепо. Мы помогаем подобрать вариант.

Архитектура интеграции

Цикл работы:

  1. Утром агент собирает заказы на сегодня со статусом «К доставке» из b_sale_order.
  2. Формирует список точек с адресами, координатами и временными окнами.
  3. Отправляет запрос в API оптимизатора.
  4. Сохраняет маршруты в bl_delivery_routes.
  5. Назначает водителей через CRM или вручную.
  6. При завершении доставки вебхук от оптимизатора обновляет статусы заказов.
Кейс: автоматизация для сети доставкиДля сети из 15 машин с мультидепо интегрировали Route4Me. Время планирования сократилось с 3 часов до 15 минут, пробег — на 20%. Клиент получил карту маршрутов в админке и автоматические уведомления клиентам.

Почему интеграция через адаптер — надёжный способ?

Реализуем паттерн адаптер — один интерфейс, несколько реализаций:

interface RouteOptimizerInterface
{
    public function optimize(array $depot, array $vehicles, array $orders): array;
}

class YandexRouteOptimizer implements RouteOptimizerInterface
{
    public function optimize(array $depot, array $vehicles, array $orders): array
    {
        $payload = [
            'depot'    => $depot,
            'vehicles' => $vehicles,
            'orders'   => array_map(fn($o) => [
                'id'           => (string)$o['order_id'],
                'point'        => ['lat' => $o['lat'], 'lon' => $o['lon']],
                'time_window'  => [$o['time_from'], $o['time_to']],
                'service_duration' => 300,
            ], $orders),
        ];

        $http = new \Bitrix\Main\Web\HttpClient();
        $http->setHeader('Content-Type', 'application/json');
        $http->setHeader('X-Ya-Courier-Request-Id', uniqid());

        $response = $http->post(
            'https://courier.yandex.ru/api/v1/companies/' . $this->companyId . '/routes',
            json_encode($payload)
        );

        return json_decode($response, true);
    }
}

class Route4MeOptimizer implements RouteOptimizerInterface
{
    public function optimize(array $depot, array $vehicles, array $orders): array
    {
        // Route4Me-специфичная логика
    }
}

Конкретная реализация выбирается через фабричный метод, конфигурируется в b_option.

Преобразование данных заказа

Ключевой момент — корректное преобразование данных Битрикс в формат API оптимизатора. Адрес нужно геокодировать в координаты (если не сделано при заказе), временные окна — конвертировать в формат оптимизатора. Данные о товарах могут импортироваться через CommerceML, что упрощает загрузку веса и объёма.

function buildOrderPoint(\Bitrix\Sale\Order $order): array
{
    $props = $order->getPropertyCollection();

    return [
        'order_id' => $order->getId(),
        'lat'      => (float)$props->getItemByOrderPropertyCode('LAT')?->getValue(),
        'lon'      => (float)$props->getItemByOrderPropertyCode('LON')?->getValue(),
        'time_from' => $this->toUnix($props->getItemByOrderPropertyCode('DELIVERY_TIME_FROM')?->getValue()),
        'time_to'   => $this->toUnix($props->getItemByOrderPropertyCode('DELIVERY_TIME_TO')?->getValue()),
        'weight_kg' => $this->getBasketWeight($order->getBasket()),
        'volume_m3' => $this->getBasketVolume($order->getBasket()),
        'priority'  => (int)$props->getItemByOrderPropertyCode('DELIVERY_PRIORITY')?->getValue(),
    ];
}

Сохранение и отображение маршрутов

Структура таблицы bl_delivery_routes:

route_id        — ID маршрута от оптимизатора
route_date      — дата доставки
vehicle_id      — ID транспортного средства
driver_id       — CRM-контакт водителя
stops_json      — JSONB упорядоченный список остановок
total_distance  — общий пробег в км
estimated_time  — предполагаемое время в минутах
status          — planned / in_progress / completed
created_at

Маршрут отображается на карте в административном разделе через Яндекс.Карты API или Leaflet.js. Водителю — ссылка с waypoints.

Обновление статусов заказов

По завершении доставки в точке оптимизатор (или водитель через мобильное приложение) отправляет событие. Вебхук Битрикс обновляет статус конкретного заказа:

// /bitrix/route_webhook.php
$data = json_decode(file_get_contents('php://input'), true);

foreach ($data['completed_stops'] as $stop) {
    $order = \Bitrix\Sale\Order::load((int)$stop['order_id']);
    if ($order) {
        $order->setField('STATUS_ID', 'F');
        $order->save();
        // Отправка письма клиенту о доставке
    }
}

Сроки выполнения по масштабу

Масштаб Особенности Сроки
Малый (1–3 машины) Один адаптер, ручное назначение водителей 3–5 дней
Средний (5–20 машин) Автоназначение, карта маршрутов, вебхуки статусов 8–12 дней
Крупный (20+ машин) Мультидепо, компетенции водителей, реалтайм-трекинг 20–35 дней

Что входит в работу

  • Разработка интерфейса RouteOptimizerInterface с адаптерами под ваши сервисы (1-3 дня на первый адаптер)
  • Настройка агента сборки заказов и отправки в оптимизатор утром рабочего дня
  • Создание таблицы bl_delivery_routes с хранением маршрутов и статусов
  • Реализация карты маршрутов в административном разделе
  • Настройка вебхука обновления статусов заказов при выполнении доставки
  • Документация по архитектуре и обучение логистов (1-2 часа)
  • Поддержка 30 дней после сдачи

Интеграция выполняется под ключ. Оценим ваш проект за 1 день. Для заказа интеграции свяжитесь с нами — поможем настроить автоматизацию доставки.

80% сайтов на Битрикс тормозят из-за одной таблицы

b_iblock_element_property — EAV-структура, где каждая строка хранит одно значение одного свойства одного элемента. Каталог в 50 000 товаров с 30 свойствами даёт 1,5 млн строк. Умный фильтр делает JOIN этой таблицы с b_iblock_element по пяти свойствам — и MySQL уходит в full table scan на 3–5 секунд.

Наш опыт показывает: без вмешательства в эту таблицу ускорение сайта невозможно. Мы берёмся за проекты, где скорость загрузки упала до 8–10 секунд, и возвращаем TTFB < 200 мс за 1–2 недели. Оптимизация скорости сайта начинается с аудита slow-запросов и заканчивается комплексной перестройкой инфраструктуры под ключ.

[Свяжитесь с нами для аудита] — мы определим узкие места за 2 часа и предложим конкретный план.

Серверная оптимизация

Nginx. Не просто «включили gzip». Конкретно:

  • gzip_comp_level 4-5 — выше бессмысленно, CPU сжирает больше, чем экономит трафик;
  • brotli on с brotli_static on — для предварительно сжатых файлов;
  • HTTP/2 с http2_max_concurrent_streams 128;
  • fastcgi_cache для PHP-ответов — кэширование на уровне Nginx, минуя PHP-FPM;
  • worker_processes auto, worker_connections под количество одновременных соединений.

PHP-FPM. Выбор между pm = dynamic и pm = static — не академический:

  • Static: фиксированное количество воркеров, без overhead на форк — для выделенных серверов с предсказуемой нагрузкой.
  • Dynamic: экономит RAM при низком трафике. pm.max_children считаем как (доступная RAM - RAM для MySQL/Redis) / средний расход на процесс.
  • OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшене (перезагрузка PHP-FPM при деплое).

MySQL/MariaDB. Главное узкое место почти всегда:

  • slow_query_log с порогом 0.5 сек — каждый запрос разбираем через EXPLAIN.
  • innodb_buffer_pool_size = 70–80% доступной RAM на выделенном сервере.
  • Составные индексы для фасетного поиска: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
  • OPTIMIZE TABLE b_iblock_element_property после массовых операций.

Как настроить кэширование на три уровня?

Управляемый кэш компонентов. TTL настраиваем для каждого компонента отдельно. Каталог — 3600 сек, новостная лента — 300 сек, баннеры — 86400. Одинаковый TTL везде — гарантия либо устаревших данных, либо бесполезного кэша.

Композитный кэш. Технология bitrix:composite — Nginx отдаёт готовый HTML из файла, PHP не запускается. Динамические зоны (корзина, авторизация) подгружаются AJAX-запросом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Но: не все компоненты совместимы, $APPLICATION->ShowPanel() и прямой вывод через echo ломают композит. Проверяем каждую страницу через панель «Производительность → Композитный сайт».

Сравнение: композитный кэш быстрее управляемого в 10–20 раз по времени первого байта. Официальная документация Битрикс по композитному кэшу: Bitrix Composite.

Memcached / Redis. Переносим кэш из файловой системы:

  • Сессии → Redis (session.save_handler = redis) — быстрее файлов в 10–50×, плюс работа в кластере.
  • Кэш компонентов → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
  • Кэш ORM-запросов — чтобы одинаковые GetList() не нагружали MySQL на каждом хите.

Почему стандартных настроек MySQL недостаточно?

Индексы. Составные для фасетного поиска. Покрывающие для частых выборок — MySQL отвечает из индекса, не обращаясь к данным. Частичные индексы (MariaDB) для фильтрации по ACTIVE = 'Y'. Аудит неиспользуемых индексов — каждый замедляет INSERT/UPDATE.

Партиционирование. Для таблиц с миллионами строк: b_stat_session, b_search_content_stem, Highload-блоки с историей. Партиция по дате — запрос «заказы за месяц» не сканирует данные за три года.

Реальный кейс: каталог 200 000 товаров, 50 свойств. Фильтр по 10 свойствам занимал 12 секунд. После создания составных индексов по (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) и партиционирования b_iblock_element_property по IBLOCK_ID время выполнения упало до 0,3 секунды. Нагрузка на MySQL снизилась в 40 раз.

Очистка. В любой базе за год-два накапливается: устаревший поисковый индекс, просроченные записи в b_cache_tag, история b_iblock_element_prop_s*, логи в b_event_log на гигабайты. Настраиваем регулярную очистку через агенты.

Партиционирование также решает проблему с параллельными запросами при обмене с 1С через CommerceML. Подробнее: MySQL Partitioning Documentation.

Фронтенд

Изображения — 60–80% веса страницы:

  • WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация;
  • srcset + sizes — не грузим 3000px картинку в блок 400px;
  • loading="lazy" для всего ниже первого экрана;
  • AVIF — ещё 20–30% экономии vs WebP (подробнее: WebP).

CSS/JS:

  • Встроенный модуль Битрикс: объединение и минификация через «Настройки → Оптимизация CSS/JS»;
  • PurgeCSS / UnCSS — на типичном Битрикс-проекте 60–70% CSS не используются;
  • defer / async для некритичного JS;
  • Critical CSS инлайном в <head> для мгновенного FCP.

Шрифты:

  • <link rel="preload" as="font" crossorigin> для основного шрифта;
  • font-display: swap — текст виден сразу;
  • Subsetting через pyftsubset — вырезаем кириллицу + латиницу, файл уменьшается в 3–5 раз.

CDN

Cloudflare, BunnyCDN, AWS CloudFront или российские (Selectel CDN, VK Cloud CDN).

  • Статика (CSS, JS, изображения, шрифты) — через CDN.
  • Правила кэширования: Cache-Control: public, max-age=31536000, immutable для файлов с хешем.
  • Оптимизация изображений на лету (imgproxy, Cloudflare Polish) без нагрузки на origin.

Зачем нужно нагрузочное тестирование?

Не синтетические бенчмарки, а реальные сценарии:

  • k6 / wrk — имитация маршрутов: каталог → фильтрация → карточка → корзина → оформление.
  • Метрики: RPS, время ответа (p50, p95, p99), процент ошибок.
  • Xdebug (callgrind) или Blackfire — профилирование PHP, поиск узких мест.

Результат тестирования — объективная картина, где реально тормозит, а не где «кажется». После оптимизации прогоняем повторно — фиксируем улучшения.

Результаты

Метрика До После
TTFB 800–2000 мс 50–200 мс
Полная загрузка 4–8 сек 1.5–2.5 сек
PageSpeed (мобильный) 30–50 80–95
Одновременные пользователи 50–100 500–2000+

Что входит в работу?

  1. Аудит текущей производительности — анализ slow-запросов, профилирование PHP, проверка кэширования, CDN, серверных настроек.
  2. Настройка серверной части — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
  3. Оптимизация кэширования — управляемый кэш, композитный сайт, настройка TTL, тегированное кэширование.
  4. Работа с БД — создание индексов, партиционирование, очистка, реорганизация EAV-таблиц.
  5. Фронтенд — изображения (WebP/AVIF), CSS/JS (минификация, deferred), шрифты (preload, subsetting).
  6. CDN — подключение, настройка правил кэширования.
  7. Нагрузочное тестирование — сценарии реальных пользователей, отчёт по метрикам.
  8. Документация — описание всех изменений, рекомендации по дальнейшему обслуживанию.
  9. Гарантия — поддержка в течение 1 месяца после сдачи.

Мониторинг

Без мониторинга через полгода всё деградирует. Новый модуль, нерасчищенные логи, изменение в шаблоне — и скорость вернулась к исходной.

  • web-vitals API — Real User Monitoring от реальных посетителей.
  • Synthetic monitoring — Pingdom, UptimeRobot, регулярные проверки из разных локаций.
  • Алерты — TTFB > 500 мс или LCP > 3 сек → уведомление.

Сроки и стоимость

Тип работ Сроки
Базовая оптимизация (кэш, изображения, минификация) 2–3 дня
Оптимизация БД (индексы, slow queries, настройка) 3–5 дней
Серверная инфраструктура (Nginx, PHP-FPM, Redis) 2–3 дня
Комплексная (сервер + БД + фронтенд + CDN) 1–3 недели
Нагрузочное тестирование и профилирование 2–3 дня
Кластерная архитектура (балансировка, репликация) 1–2 недели

Стоимость рассчитывается индивидуально после аудита. [Получите консультацию по вашему проекту] — оценим текущее состояние и предложим план ускорения с конкретными сроками и бюджетом. Мы — команда с 10+ годами опыта в Битрикс, выполнили более 200 проектов по оптимизации скорости сайта.