Разработка сайта логистической компании на 1С-Битрикс

Грузоотправитель приходит на сайт с одной задачей: узнать стоимость перевозки, оформить заявку, отследить груз. Если калькулятор не считает, трекинг не показывает статус, а для повторной отправки нужно заново заполнять 12 полей — клиент уходит к конкуренту с нормальным личным кабинетом. Мы разрабатываем сайты логистических компаний на 1С-Битрикс, и 10+ лет опыта позволяют нам избежать этих ошибок. Свяжитесь с нами, чтобы обсудить архитектуру вашего проекта.

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

Как устроен каталог услуг?

Логистическая компания предлагает не один продукт, а матрицу услуг: FTL (полная загрузка), LTL (сборный груз), warehousing, таможенное оформление, last-mile доставка. Каждый тип имеет свои параметры — ограничения по весу, габаритам, температурному режиму, географии.

Структура данных:

• Инфоблок «Услуги» — разделы: Автоперевозки, Морские, Железнодорожные, Авиа, Складские услуги, Таможня
• Highload-блок «Типы транспорта» — справочник: тент, рефрижератор, контейнер 20', контейнер 40', изотерм. Поля: UF_NAME, UF_CAPACITY_KG, UF_VOLUME_M3, UF_PHOTO, UF_DESCRIPTION
• Highload-блок «Маршруты» — пары город-город с привязкой к типам перевозок. Поля: UF_FROM_CITY, UF_TO_CITY, UF_TRANSPORT_TYPE, UF_TRANSIT_DAYS, UF_ACTIVE
• Highload-блок «Ограничения груза» — максимальный вес, габариты, запрещённые категории по типу транспорта

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

Для SEO критичны страницы вида «[тип перевозки] + [маршрут]»: «Автоперевозки Москва — Новосибирск», «Сборные грузы из Китая». Эти страницы генерируются из связки инфоблока услуг и Highload-блока маршрутов через кастомный компонент. URL строится по шаблону /uslugi/{service-code}/{from}-{to}/, ЧПУ настраивается через CIBlockElement::GetList с фильтром по свойствам ROUTE_FROM и ROUTE_TO.

Как реализовать калькулятор стоимости перевозки?

Калькулятор — причина, по которой 70% посетителей приходят на сайт логистической компании. Не форма «оставьте заявку, мы перезвоним», а реальный расчёт: откуда, куда, что везём, сколько стоит. Если калькулятор не даёт цену — посетитель не становится лидом.

Архитектура калькулятора состоит из трёх слоёв.

Слой 1 — фронтенд: мультишаговая форма. Шаг 1: откуда → куда (автокомплит городов через AJAX, данные из Highload-блока «Города» или внешний API — Yandex.Geocoder). Шаг 2: параметры груза — вес, объём (Д×Ш×В), количество мест, тип упаковки, температурный режим. Шаг 3: дополнительные опции — страхование, таможенное оформление, доставка до двери. Шаг 4: результат — стоимость, срок, доступные виды транспорта.

Форма реализуется как React-компонент или vanilla JS с пошаговой навигацией. Каждый шаг — AJAX-валидация на сервере. Автокомплит городов — отдельный endpoint /api/cities/suggest/?q=Моск, который ищет по b_hlbd_cities (Highload-блок) через DataManager::getList() с фильтром ['%UF_NAME' => $query].

Слой 2 — расчёт расстояния. Тарифы зависят от расстояния. Два подхода:

Подход A — предрассчитанная матрица расстояний в Highload-блоке DistanceMatrix. Поля: UF_FROM_CITY_ID, UF_TO_CITY_ID, UF_DISTANCE_KM, UF_TRANSIT_HOURS. При 500 городах — 250К записей, вполне подъёмно. Плюс: мгновенный ответ, не зависит от внешних API. Минус: нужно пересчитывать при добавлении городов.

Подход B — расчёт через внешний API в реальном времени. Yandex.Routing API (router.route()) или Google Distance Matrix API. Запрос: две точки → расстояние в км + время в пути. Кэширование результата в Highload-блок: если пара город-город уже рассчитана — берём из кэша, иначе — API-запрос + сохранение. TTL кэша — 30 дней.

// Получение расстояния с кэшированием
class DistanceService
{
    public static function getDistance(int $fromCityId, int $toCityId): array
    {
        // Проверяем кэш в Highload-блоке
        $cached = DistanceMatrixTable::getList([
            'filter' => [
                'UF_FROM_CITY_ID' => $fromCityId,
                'UF_TO_CITY_ID' => $toCityId,
                '>UF_CACHED_AT' => date('Y-m-d', strtotime('-30 days'))
            ]
        ])->fetch();

        if ($cached) {
            return [
                'distance_km' => $cached['UF_DISTANCE_KM'],
                'transit_hours' => $cached['UF_TRANSIT_HOURS']
            ];
        }

        // Запрос к Yandex.Routing API
        $result = YandexRoutingClient::route(
            Cities::getCoordinates($fromCityId),
            Cities::getCoordinates($toCityId)
        );

        // Сохраняем в кэш
        DistanceMatrixTable::add([
            'UF_FROM_CITY_ID' => $fromCityId,
            'UF_TO_CITY_ID' => $toCityId,
            'UF_DISTANCE_KM' => $result['distance'],
            'UF_TRANSIT_HOURS' => $result['duration'],
            'UF_CACHED_AT' => new DateTime()
        ]);

        return $result;
    }
}

Слой 3 — тарификация. Тарифы хранятся в Highload-блоке Tariffs со структурой:

Формула расчёта для LTL: max(distance_km * rate_per_km, min_rate) * weight_coeff * volume_coeff + insurance + customs_fee. Для FTL — проще: фиксированная ставка за км × расстояние, без весовых коэффициентов (машина целиком).

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

Результат калькулятора возвращается JSON-ответом:

{
  "variants": [
    {
      "transport": "Тент 20т",
      "service": "FTL",
      "price": 45000,
      "currency": "RUB",
      "transit_days": 3,
      "distance_km": 1800
    },
    {
      "transport": "Сборный груз",
      "service": "LTL",
      "price": 12500,
      "currency": "RUB",
      "transit_days": 7,
      "distance_km": 1800
    }
  ]
}

Под результатом — кнопка «Оформить заявку», которая переносит все параметры расчёта в форму заказа. Пользователю не нужно вводить данные повторно.

Почему трекинг груза критичен для возврата клиентов?

Трекинг — вторая причина, по которой клиенты возвращаются на сайт. Поле ввода трекинг-номера на главной странице, результат — цепочка статусов с датами и текущее местоположение на карте.

Источник данных — 1С:TMS или 1С:Логистика. Интеграция через REST API документацию: 1С отправляет обновления статуса через POST /rest/logistics.shipment.updateStatus с полями tracking_number, status_code, location, timestamp. Битрикс хранит статусы в Highload-блоке ShipmentStatuses.

На фронте — AJAX-запрос по трекинг-номеру. Ответ содержит массив статусов (принят, на складе, в пути, на таможне, доставлен) и координаты последнего известного местоположения для отображения на карте через Yandex.Maps.

Обновление в реальном времени — через polling каждые 60 секунд или WebSocket, если объём трафика оправдывает сложность.

Как настроить B2B-кабинет для логистической компании?

Личный кабинет для корпоративных клиентов — то, что отличает серьёзную логистическую компанию от «сайта-визитки с калькулятором». Это не просто история заказов, а полноценный рабочий инструмент логиста.

Авторизация и роли. Компания-клиент регистрируется как юрлицо. Внутри компании — несколько пользователей с разными ролями. Реализация через группы пользователей Битрикса (CGroup) и кастомные поля:

• Администратор компании — видит все заказы, управляет пользователями, скачивает документы, видит финансы
• Логист — создаёт заказы, отслеживает статусы, скачивает ТТН и CMR
• Бухгалтер — доступ только к документам: счета, акты, счета-фактуры

Привязка пользователя к компании — через кастомное поле UF_COMPANY_ID в b_user. Проверка доступа — middleware в init.php, который при каждом запросе к /personal/ проверяет группу пользователя и UF_COMPANY_ID.

Функциональность кабинета:

История заказов — список всех перевозок компании с фильтрацией по дате, статусу, направлению. Данные из Highload-блока Orders с полями: UF_ORDER_NUMBER, UF_COMPANY_ID, UF_FROM_CITY, UF_TO_CITY, UF_STATUS, UF_CARGO_DESCRIPTION, UF_WEIGHT, UF_VOLUME, UF_PRICE, UF_CREATED_AT. Пагинация через bitrix:system.pagenavigation, фильтрация — AJAX.

Документооборот — каждый заказ содержит набор документов: ТТН, CMR, инвойс, упаковочный лист, страховой полис. Файлы хранятся как множественное свойство типа «Файл» в привязке к заказу. Скачивание — через кастомный контроллер, который проверяет принадлежность документа к компании пользователя перед отдачей файла. Никаких прямых ссылок на /upload/ — только авторизованный доступ.

// Проверка доступа к документу
class DocumentController extends Controller
{
    public function download(int $orderId, int $fileId): Response
    {
        $user = $GLOBALS['USER'];
        $order = OrdersTable::getById($orderId)->fetch();

        if ($order['UF_COMPANY_ID'] !== $user->getUfCompanyId()) {
            throw new AccessDeniedException();
        }

        $file = CFile::GetFileArray($fileId);
        return new BinaryFileResponse($file['SRC']);
    }
}

Шаблоны повторных отправок. Постоянный клиент отправляет одни и те же грузы по одним и тем же маршрутам. Логист сохраняет заказ как шаблон, в следующий раз — выбирает шаблон, меняет дату, подтверждает. Шаблоны — отдельный Highload-блок ShipmentTemplates с полями, дублирующими структуру заказа, плюс UF_TEMPLATE_NAME и UF_COMPANY_ID.

Финансовый раздел — баланс взаиморасчётов, выставленные счета, история оплат. Данные синхронизируются из 1С через REST API по расписанию (каждые 15 минут) или по событию.

Интеграция с 1С:TMS

Синхронизация заказов между сайтом и 1С:TMS (или 1С:Управление автотранспортом) — двусторонняя:

• Сайт → 1С: новый заказ с сайта отправляется в 1С через REST API. Endpoint на стороне 1С принимает JSON с параметрами заказа, создаёт документ «Заявка на перевозку»
• 1С → Сайт: изменение статуса в 1С триггерит webhook на Битрикс. Обработчик обновляет UF_STATUS в Highload-блоке Orders и отправляет email/SMS клиенту

Формат обмена — JSON через HTTP REST. XML-обмен через CommerceML для логистики избыточен — это формат торговли, не перевозок.

Карта покрытия и автопарк

Интерактивная карта — Yandex.Maps с кастомным слоем. Маркеры складов и хабов из Highload-блока Warehouses (поля: UF_NAME, UF_ADDRESS, UF_COORDINATES, UF_TYPE, UF_PHOTO). Линии маршрутов между хабами — ymaps.Polyline с данными из Highload-блока маршрутов. Клик по хабу — балун с адресом, графиком работы, доступными услугами.

Автопарк — инфоблок с типами транспорта. Карточка машины: фото, грузоподъёмность, объём кузова, тип (тент, рефрижератор, контейнеровоз). Вывод через bitrix:news.list с кастомным шаблоном — сетка карточек с иконками характеристик.

API для партнёров

REST API для интеграции с системами партнёров: экспедиторов, маркетплейсов, ERP-систем клиентов. Endpoints:

• POST /api/v1/orders/create — создание заказа
• GET /api/v1/orders/{id}/status — статус заказа
• GET /api/v1/tracking/{number} — трекинг
• POST /api/v1/calculate — расчёт стоимости

Авторизация — API-ключ в заголовке X-Api-Key. Ключи генерируются в админке, привязаны к компании-партнёру. Rate limiting — 100 запросов в минуту через middleware.

Этапы и сроки

Сроки не включают настройку обмена на стороне 1С — это отдельный проект со стороны 1С-разработчика, который идёт параллельно.

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

• Документация: описание архитектуры, схема данных, инструкция по обновлению тарифов
• Доступы: исходный код, доступ к админке, репозиторий
• Обучение: обучение менеджеров работе с административной панелью (до 4 часов)
• Поддержка: гарантийная поддержка 1 месяц после запуска

Наш опыт — 10+ лет в разработке на 1С-Битрикс и 50+ проектов для логистических компаний. Используя Битрикс, мы сокращаем время запуска сайта в 2 раза по сравнению с самописными решениями. Получите консультацию или закажите разработку сайта логистической компании на 1С-Битрикс — рассчитаем стоимость и сроки за 1 рабочий день.

Как правильно проектировать инфоблоки?

Мы видим десятки проектов, где неправильная структура инфоблоков превращает сайт в тормоз. Типичный сценарий: заказчик просит «каталог товаров». Разработчик создаёт один инфоблок catalog, закидывает туда 15 свойств. Через полгода — 40 свойств, 8 из которых используются только для одной категории. Фильтр тормозит, таблица b_iblock_element_property разрослась до миллионов строк, CIBlockElement::GetList выполняется 3 секунды. Последствия — падение конверсии, потеря клиентов, дополнительные затраты на оптимизацию. В одном проекте после рефакторинга каталога время генерации страницы снизилось с 4,2 до 0,8 секунды, а стоимость поддержки сократилась на 250 000 рублей в год — за счёт устранения избыточных запросов и агентов.

Наш подход: проектируем инфоблоки до первой строки кода. Отдельные инфоблоки под сущности (товары, категории, бренды), свойства-справочники через highload-блоки, торговые предложения для SKU. Это закладывает производительность на годы вперёд. Если хотите получить предварительный аудит вашей схемы инфоблоков — свяжитесь с нами, разберём типовые ошибки и дадим рекомендации бесплатно.

Почему 1С-Битрикс выгоднее альтернатив?

Выбор CMS диктуется не предпочтениями, а бизнес-задачами. Вот ключевые аргументы:

• Нативный обмен с 1С — модуль catalog.import.1c обеспечивает двусторонний обмен товарами, ценами, остатками и заказами через CommerceML. Без сторонних модулей. Это в 5 раз быстрее, чем разработка собственного обмена на OpenCart или WordPress. Подробнее о формате — в Wikipedia. Экономия на интеграции составляет в среднем 150 000–300 000 рублей по сравнению с кастомными решениями.
• Проактивная защита — модуль security включает WAF, контроль целостности файлов, защиту от SQL-инъекций, двухфакторную аутентификацию. Для проектов с требованиями ФСТЭК — сертифицированное решение.
• Модульная архитектура — подключаем только нужные модули: iblock, catalog, sale, search. Меньше модулей — меньше запросов к БД на каждый хит.
• Регулярные патчи — вендор выпускает security-патчи, закрывая уязвимости быстрее, чем open-source проекты (среднее время исправления CVE — 2 недели). Официальная документация по модулям — dev.1c-bitrix.ru.

Что дают HL-блоки и как мы ускоряем каталог

Highload-блоки — это альтернатива расширенным свойствам инфоблоков, когда список значений может расти до тысяч записей. Типичный пример: производители, страны, цвета. Если хранить их как свойства-списки в инфоблоке, каждая фильтрация вызывает полное сканирование таблицы b_iblock_property_enum. С HL-блоками выборка идёт по индексу — время ответа фильтра снижается с 1–2 секунд до 50 мс. Мы используем HLB компонент и кастомные запросы через Bitrix\Highloadblock\DataManager. Это особенно критично для каталогов с 100 000+ товарами.

Из нашей практики — проект интернет-магазина с 500 000 товаров. Стандартный фильтр по бренду выполнялся 4 секунды. Сервер не выдерживал нагрузку в 50 одновременных запросов — страницы падали. Мы перевели справочник брендов в HL-блок, добавили тегированное кэширование на 15 минут и настроили агент для сброса кэша при изменении. После доработки время фильтрации составило 120 мс, средний LCP страницы — 1,8 секунды. Проект работает стабильно без сбоев.

Что входит в разработку сайта на 1С-Битрикс

Каждый проект включает полный комплект документации и артефактов, исключающий потерю знаний после передачи.

• Техническое задание — user stories, диаграммы инфоблоков, схемы интеграций.
• Исходный код в Git — с историей коммитов, тегами релизов, правилами ветвления.
• Административная документация — описание кастомных компонентов, инструкции по разворачиванию, перечень агентов и событий.
• Обучение сотрудников — до 3 часов вебинара: панель управления, работа с заказами, настройка цен. Записываем, чтобы можно было пересмотреть.
• Доступ к staging на время разработки — тестируете сами до деплоя на продуктив.
• Гарантийная поддержка — исправление ошибок кода в течение 30 дней после запуска. Постгарантийные абонентские пакеты с SLA (реакция 2 часа, решение 8 часов).

Наш процесс и технологии

Стек: вёрстка mobile-first, тестируем на физических устройствах (iPhone, iPad, Android). Используем BrowserStack для Safari на iOS. Производительность — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаем композитный сайт (composite), CDN, тегированное кэширование, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерация sitemap.xml модулем seo, canonical и hreflang для мультиязычных версий. robots.txt закрываем /bitrix/ от индексации. CI/CD — Git, автодеплой через GitLab CI, staging. Миграции базы — модуль sprint.migration с версионированием.

Процесс работы:

1. Аналитика — изучаем конкурентов, собираем требования, рисуем прототипы в Figma. На выходе — ТЗ с user stories.
2. Дизайн — UI/UX с дизайн-системой. Компоненты переиспользуются.
3. Разработка — пишем компоненты с кастомными шаблонами в local/templates/. Бизнес-логику выносим в модули local/modules/.
4. Тестирование — функциональное, кроссбраузерное, нагрузочное (до 1000 запросов). Критичные баги исправляем до запуска.
5. Запуск — деплой на прод, мониторинг через UptimeRobot, алерты в Telegram. Устраняем первые 48 часов.

Интеграции, мультиязычность и редизайн

• Полная локализация через языковые файлы lang/ и механизм SITE_ID. hreflang для каждой версии. Региональные версии с разными ценами и контентом — определение по IP (main.geo) или ручной выбор. Мультидоменность — единое управление несколькими доменами.

• Редизайн без потери позиций: аудит производительности (PageSpeed, WebPageTest), SEO (Screaming Frog). Новый шаблон в local/templates/ с сохранением URL-структуры. 301-редиректы только если URL меняется существенно. Обновление ядра, переход на D7 ORM, реструктуризация инфоблоков, миграция через sprint.migration с Git.

Гарантия и поддержка

Мы работаем с 1С-Битрикс 12+ лет, реализовали 500+ проектов. В штате сертифицированные разработчики. Фиксированная стоимость в договоре — без сюрпризов. Гарантийный период покрывает ошибки кода. После — абонентские пакеты с SLA (время реакции — 2 часа, решение — 8 часов). Мониторинг доступности 24/7, алерты в Telegram. Получите консультацию и предварительный расчёт: свяжитесь с нами через форму на сайте или напишите в чат — ответим в течение часа. Закажите разработку под ключ — мы спроектируем инфоблоки, интегрируем 1С и разгоним каталог. Если уже есть сайт на другой CMS — закажите аудит производительности и миграцию на Битрикс.